Breve historia de la metodología ágil

Hoy en día, todas las organizaciones tecnológicas parecen practicar alguna versión de la metodología ágil. O, al menos, creen que lo hacen. Tanto si eres nuevo en el desarrollo de software como si empezaste hace décadas, tu trabajo actual está al menos influenciado por los métodos ágiles.

Pero, ¿qué es ágil y cómo incorporan los desarrolladores y las organizaciones las metodologías ágiles? Este artículo es una breve historia del desarrollo ágil y de cómo se diferencia de la clásica metodología en cascada. Hablaré de las diferencias entre los métodos ágiles y los de cascada en la práctica, y explicaré por qué los ágiles se adaptan mucho mejor a la forma de trabajar de los desarrolladores y los equipos, especialmente en los entornos de desarrollo actuales.

Antes de lo ágil: la metodología en cascada

Los veteranos como yo recuerdan cuando la metodología en cascada era el estándar de oro para el desarrollo de software. El uso del método de cascada requería una gran cantidad de documentación por adelantado, antes de empezar a codificar. Normalmente, el proceso comenzaba con un analista de negocio que escribía un documento de requisitos comerciales que recogía lo que la empresa necesitaba de la aplicación. Estos documentos eran largos y detallados, y contenían todo tipo de información, desde la estrategia general hasta las especificaciones funcionales completas y los diseños de la interfaz de usuario.

Los tecnólogos utilizaban el documento de requisitos empresariales para desarrollar un documento de requisitos técnicos. Este documento definía la arquitectura de la aplicación, las estructuras de datos, los diseños funcionales orientados a objetos, las interfaces de usuario y otros requisitos no funcionales.

Una vez completados los documentos de requisitos empresariales y técnicos, los desarrolladores iniciaban la codificación, luego la integración y finalmente las pruebas. Todo esto tenía que hacerse antes de que una aplicación se considerara lista para la producción. Todo el proceso podía durar fácilmente un par de años.

La metodología en cascada en la práctica

La documentación utilizada para la metodología en cascada se llamaba "la especificación", y se esperaba que los desarrolladores la conocieran tan bien como sus autores. Podían reprenderte por no haber implementado correctamente un detalle clave, por ejemplo, señalado en la página 77 de un documento de 200 páginas.

Las herramientas de desarrollo de software también requerían una formación especializada, y no había tantas herramientas entre las que elegir. Desarrollamos nosotros mismos todas las cosas de bajo nivel, como la apertura de conexiones a bases de datos y el procesamiento multihilo de nuestros datos.

Incluso para las aplicaciones básicas, los equipos eran grandes y las herramientas de comunicación eran limitadas. Nuestras especificaciones técnicas nos alineaban, y las aprovechábamos como la Biblia. Si un requisito cambiaba, sometíamos a los responsables de la empresa a un largo proceso de revisión y aprobación. Comunicar los cambios a todo el equipo y corregir el código eran procedimientos costosos.

Como el software se desarrollaba sobre la base de la arquitectura técnica, los artefactos de nivel inferior se desarrollaban primero y los artefactos dependientes venían después. Las tareas se asignaban por competencias, y era habitual que los ingenieros de bases de datos construyeran primero las tablas y otros artefactos de bases de datos. Los desarrolladores de aplicaciones codificaban la funcionalidad y la lógica empresarial a continuación, y la interfaz de usuario se superponía en último lugar. Pasaban meses antes de que alguien viera la aplicación funcionando. Para entonces, las partes interesadas solían ponerse nerviosas, y a menudo eran más inteligentes en cuanto a lo que realmente querían. No es de extrañar que la aplicación de los cambios fuera tan cara.

Al final, no todo lo que se ponía delante de los usuarios funcionaba como se esperaba. A veces, no utilizaban una función en absoluto. Otras veces, una funcionalidad tenía mucho éxito pero requería una reingeniería para soportar la escalabilidad y el rendimiento. En el mundo de la cascada, estas cosas (los fallos) sólo se sabían después de que el software se desplegara, tras un largo ciclo de desarrollo.

Pros y contras de la metodología en cascada

Inventada en 1970, la metodología en cascada fue revolucionaria porque aportó disciplina al desarrollo de software y garantizó la existencia de una especificación clara a seguir. Se basaba en el método de fabricación en cascada, derivado de las innovaciones de la cadena de montaje de Henry Ford en 1913, que proporcionaba seguridad sobre cada paso del proceso de producción. El método de cascada pretendía garantizar que el producto final coincidiera con lo que se había especificado en un principio.

Cuando los equipos de software empezaron a adoptar la metodología en cascada, los sistemas informáticos y sus aplicaciones solían ser complejos y monolíticos, lo que exigía disciplina y resultados claros para su entrega. Los requisitos también cambiaban lentamente en comparación con la actualidad, por lo que los esfuerzos a gran escala eran menos problemáticos. De hecho, los sistemas se construían asumiendo que no cambiarían, sino que serían acorazados perpetuos. Los plazos de varios años eran habituales no sólo en el desarrollo de software, sino también en la fabricación y otras actividades empresariales. Pero la rigidez de la cascada se convirtió en su perdición cuando entramos en la era de Internet, y la velocidad y la flexibilidad se valoraron más.

El giro hacia los métodos ágiles

El desarrollo de software empezó a cambiar cuando los desarrolladores comenzaron a trabajar en aplicaciones de Internet. Gran parte del trabajo inicial se realizó en empresas emergentes en las que los equipos eran más pequeños, estaban ubicados en el mismo lugar y, a menudo, no tenían formación informática tradicional. Había presiones financieras y competitivas para sacar al mercado sitios web, aplicaciones y nuevas capacidades con mayor rapidez. Las herramientas y plataformas de desarrollo cambiaron rápidamente como respuesta.

Esto hizo que muchos de los que trabajábamos en startups cuestionáramos la metodología de cascada y buscáramos formas de ser más eficientes. No podíamos permitirnos hacer toda la documentación detallada por adelantado y necesitábamos un proceso más iterativo y colaborativo. Seguíamos debatiendo los cambios en los requisitos, pero estábamos más abiertos a la experimentación y a la adaptación de nuestro software en función de los comentarios de los usuarios. Nuestras organizaciones estaban menos estructuradas y nuestras aplicaciones eran menos complejas que los sistemas heredados de las empresas, por lo que estábamos más abiertos a construir en lugar de comprar aplicaciones. Y lo que es más importante, tratábamos de hacer crecer los negocios, así que cuando los usuarios nos decían que algo no funcionaba, normalmente les escuchábamos.

Tener las habilidades y capacidades para innovar se convirtió en algo estratégicamente importante. Podías recaudar todo el dinero que quisieras, pero no podías atraer a desarrolladores de software con talento, capaces de trabajar con tecnologías de Internet que cambiaban rápidamente, y luego obligarles a seguir "las especificaciones". Los desarrolladores rechazaban a los gestores de proyectos que les dirigían con calendarios integrales que describían lo que debíamos desarrollar, cuándo debían enviarse las aplicaciones y, a veces, incluso cómo estructurar el código. Nos costó mucho cumplir los calendarios de tres y seis meses que nuestros gestores de proyectos redactaban y actualizaban incesantemente.

En lugar de ello, empezamos a decirles cómo debían diseñarse las aplicaciones de Internet, y entregamos los resultados en un calendario que elaboramos de forma iterativa. Resulta que no éramos tan malos entregando lo que decíamos que haríamos cuando nos comprometíamos a hacerlo en intervalos de una a cuatro semanas.

En 2001, un grupo de desarrolladores de software experimentados se dieron cuenta de que estaban practicando colectivamente el desarrollo de software de forma diferente a la metodología clásica en cascada. Y no todos ellos estaban en startups. Este grupo —que incluía a luminarias de la tecnología como Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber y Jeff Sutherland— elaboró el Manifiesto Ágil que documentaba sus creencias compartidas sobre cómo debería funcionar un proceso de desarrollo de software moderno. Hicieron hincapié en la colaboración por encima de la documentación, en la autoorganización en lugar de en las prácticas rígidas de gestión y en la capacidad de gestionar el cambio constante en lugar de encerrarse en un proceso rígido de desarrollo en cascada.

De estos principios nació la metodología ágil de desarrollo de software.

Por qué el desarrollo ágil ofrece un mejor software

Cuando se toma el conjunto de principios ágiles, se implementa en un marco ágil, se aprovechan las herramientas de colaboración y se adoptan prácticas de desarrollo ágil, normalmente se obtienen aplicaciones de mejor calidad y más rápidas de desarrollar. También se obtienen mejores métodos técnicos, es decir, higiene.

La razón principal es que la agilidad está diseñada para la flexibilidad y la adaptabilidad. No es necesario definir todas las respuestas por adelantado, como se hace en el método de cascada. En su lugar, divide el problema en componentes digeribles que luego se desarrollan y prueban con los usuarios. Si algo no funciona bien o como se esperaba, o si el esfuerzo revela algo que no se había tenido en cuenta, se puede adaptar el esfuerzo y retomar el camino rápidamente, o incluso cambiar de vía si es necesario. Agile permite que cada miembro del equipo contribuya a la solución y exige que cada uno asuma la responsabilidad personal de su trabajo.

Los principios, marcos y prácticas ágiles están diseñados para las condiciones de funcionamiento actuales. Agile suele dar prioridad al desarrollo iterativo y al aprovechamiento de los comentarios para mejorar la aplicación y el proceso de desarrollo. Tanto la iteración como la retroalimentación se adaptan bien al mundo actual, en el que se opera de forma más inteligente y rápida.

El desarrollo ágil también fomenta la mejora continua. Imagina que Microsoft dejara de desarrollar Windows después de la versión 3.1, o que Google dejara de mejorar sus algoritmos de búsqueda en 2002. El software necesita constantemente ser actualizado, soportado y mejorado; la metodología ágil establece tanto una mentalidad como un proceso para esa mejora continua.

Por último, el desarrollo ágil da lugar a un mejor software porque los miembros de los equipos ágiles suelen ser más productivos y felices. Los ingenieros tienen voz y voto sobre la cantidad de trabajo que asumen, y están orgullosos de mostrar sus resultados. A los propietarios del producto les gusta ver su visión expresada en el software antes y poder cambiar las prioridades en función de los últimos conocimientos. A los usuarios les gusta obtener un software que haga lo que realmente necesitan que haga.

Hoy en día, las empresas necesitan un alto nivel de competencia de software para ofrecer experiencias digitales excepcionales en un mundo hipercompetitivo. Y necesitan atraer y mantener grandes talentos para construir un gran software. El desarrollo ágil ayuda a las empresas a hacer ambas cosas.