¿Qué es la metodología ágil? Explicación del desarrollo de software moderno

Hoy en día, todas las organizaciones de tecnología parecen practicar la metodología ágil para el desarrollo de software, o una versión de la misma. O al menos creen que sí. Tanto si es nuevo en el desarrollo de aplicaciones ágiles como si aprendió desarrollo de software hace décadas utilizando la metodología de desarrollo de software en cascada, hoy su trabajo está al menos influenciado por la metodología ágil.

Pero, ¿qué es la metodología ágil y cómo se debe practicar en el desarrollo de software? ¿En qué se diferencia el desarrollo ágil de la cascada en la práctica? ¿Qué es el ciclo de vida de desarrollo de software ágil o SDLC ágil? ¿Y qué es scrum ágil frente a Kanban y otros modelos ágiles? 

Agile se lanzó formalmente en 2001 cuando 17 tecnólogos redactaron el Manifiesto Agile. Escribieron cuatro principios fundamentales para la gestión ágil de proyectos, con el objetivo de desarrollar un mejor software:

  • Individuos e interacciones sobre procesos y herramientas
  • Software de trabajo sobre documentación completa
  • Colaboración con el cliente sobre la negociación de contratos
  • Responde al cambio sobre el siguiente plan

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

Los veteranos como yo recuerdan los días en que la metodología en cascada era el estándar de oro para el desarrollo de software. El proceso de desarrollo de software requería una gran cantidad de documentación antes de que comenzara la codificación. Alguien, generalmente el analista de negocios, primero escribió un documento de requisitos comerciales que capturaba todo lo que el negocio necesitaba en la aplicación. Estos documentos de requisitos comerciales eran largos y detallaban todo: estrategia general, especificaciones funcionales integrales y diseños de interfaz de usuario visual.

Los tecnólogos tomaron el documento de requisitos comerciales y desarrollaron su propio documento de requisitos técnicos. Este documento definió 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.

Este proceso de desarrollo de software en cascada finalmente iniciaría la codificación, luego la integración y finalmente la prueba antes de que una aplicación se considerara lista para producción. Todo el proceso podría llevar fácilmente un par de años.

Se esperaba que los desarrolladores supiéramos "la especificación", como se llamaba a la documentación completa, tan bien como los autores de los documentos, y a menudo nos reprendían si olvidábamos implementar correctamente un detalle clave descrito en la página 77 de un 200- documento de página.

En aquel entonces, el desarrollo de software en sí tampoco era fácil. Muchas herramientas de desarrollo requerían capacitación especializada, y no existían ni los componentes de software comercial o de código abierto, las API ni los servicios web que existen en la actualidad. Tuvimos que desarrollar cosas de bajo nivel, como abrir conexiones de bases de datos y multiproceso de nuestro procesamiento de datos.

Incluso para las aplicaciones básicas, los equipos eran grandes y las herramientas de comunicación limitadas. Nuestras especificaciones técnicas fueron las que nos alinearon y las aprovechamos como la Biblia. Si cambiaba un requisito, sometíamos a los líderes empresariales a un largo proceso de revisión y firmaba porque comunicar los cambios a todo el equipo y corregir el código era caro.

Dado que el software se desarrolló sobre la base de la arquitectura técnica, los artefactos de nivel inferior se desarrollaron primero y los artefactos dependientes después. Las tareas se asignaban por habilidad, y era común que los ingenieros de bases de datos construyeran las tablas y otros artefactos de la base de datos primero, seguidos por los desarrolladores de aplicaciones que codificaban la funcionalidad y la lógica empresarial, y finalmente se superponía la interfaz de usuario. Pasaron meses antes de que alguien viera que la aplicación funcionaba y, para entonces, las partes interesadas se estaban poniendo ansiosas y, a menudo, más inteligentes sobre lo que realmente querían. ¡No es de extrañar que implementar cambios fuera tan costoso!

No todo lo que puso frente a los usuarios funcionó como se esperaba. A veces, los usuarios no usarían una función en absoluto. Otras veces, una capacidad tuvo mucho éxito pero requirió reingeniería para soportar la escalabilidad y el rendimiento necesarios. En el mundo de las cascadas, solo aprendió estas cosas después de que se implementó el software, después de un largo ciclo de desarrollo.

Vídeo relacionado: Cómo funciona realmente la metodología ágil

Todo el mundo parece estar hablando de desarrollo de software ágil, pero muchas organizaciones no tienen una idea clara de cómo funciona el proceso. Mire este video de cinco minutos para ponerse al día rápidamente.

El pivote hacia el desarrollo de software ágil

Inventado en 1970, la metodología en cascada fue revolucionaria porque trajo disciplina al desarrollo de software para garantizar que hubiera una especificación clara a seguir. Se basó en el método de fabricación en cascada derivado de las innovaciones de la línea de montaje de 1913 de Henry Ford, que proporcionaba certeza en cada paso del proceso de producción para garantizar que el producto final coincidiera con lo que se especificó en primer lugar.

Cuando la metodología en cascada llegó al mundo del software, los sistemas informáticos y sus aplicaciones eran típicamente complejos y monolíticos, lo que requería una disciplina y un resultado claro para entregar. Los requisitos también cambiaron lentamente en comparación con la actualidad, por lo que los esfuerzos a gran escala fueron menos problemáticos. De hecho, los sistemas se construyeron bajo el supuesto de que no cambiarían sino que serían perpetuos acorazados. Los plazos de varios años eran habituales no solo 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 un talón de Aquiles en la era de Internet, donde se requería velocidad y flexibilidad.

La metodología de desarrollo de software comenzó a cambiar cuando los desarrolladores comenzaron a trabajar en aplicaciones de Internet. Gran parte del trabajo inicial se realizó en nuevas empresas donde los equipos eran más pequeños, estaban ubicados y, a menudo, no tenían antecedentes tradicionales de informática. Hubo presiones financieras y competitivas para llevar sitios web, aplicaciones y nuevas capacidades al mercado más rápido. Las herramientas y plataformas de desarrollo cambiaron rápidamente en respuesta.

Esto llevó a muchos de los que trabajamos en startups a cuestionar la metodología en cascada y buscar 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. Seguimos debatiendo cambios en los requisitos, pero estábamos más abiertos a la experimentación y a la adaptación a las necesidades del usuario final. Nuestras organizaciones estaban menos estructuradas y nuestras aplicaciones eran menos complejas que los sistemas heredados empresariales, por lo que estábamos mucho más abiertos a crear aplicaciones que a comprarlas. Más importante aún, estábamos tratando de hacer crecer los negocios, por lo que cuando nuestros usuarios nos dijeron que algo no estaba funcionando, la mayoría de las veces elegimos escucharlos.

Nuestras habilidades y nuestra capacidad para innovar se volvieron estratégicamente importantes. Podrías recaudar todo el dinero que quisieras, pero no podrías atraer a desarrolladores de software talentosos capaces de trabajar con tecnologías de Internet que cambian rápidamente si los trataras como codificadores subordinados que siguen servilmente "las especificaciones". Rechazamos que los gerentes de proyecto vinieran con cronogramas de extremo a extremo que describieran lo que deberíamos desarrollar, cuándo deberían enviarse las aplicaciones y, a veces, incluso cómo estructurar el código. Fuimos terribles al cumplir con los cronogramas de tres y seis meses que los gerentes de proyectos en cascada redactaron y actualizaron incesantemente.

En cambio, comenzamos a decirles cómo se debían diseñar las aplicaciones de Internet y entregamos resultados en un cronograma que diseñamos iterativamente. Resulta que no fuimos tan malos en entregar lo que dijimos que haríamos cuando nos comprometimos a hacerlo en intervalos pequeños, de una a cuatro semanas.

En 2001, un grupo de desarrolladores de software con experiencia se reunió y se dio cuenta de que estaban practicando colectivamente el desarrollo de software de manera diferente a la metodología clásica en cascada. Y no todos estaban en startups. Este grupo, que incluía a luminarias tecnológicas Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber y Jeff Sutherland, elaboró ​​el Manifiesto Agile que documentó sus creencias compartidas sobre cómo debería funcionar un proceso de desarrollo de software moderno. Hicieron hincapié en la colaboración sobre la documentación, la autoorganización en lugar de las prácticas de gestión rígidas y la capacidad de gestionar el cambio constante en lugar de encerrarse en un proceso de desarrollo en cascada rígido.

De esos principios nació la metodología ágil para el desarrollo de software.

Los roles en la metodología ágil

Un proceso de desarrollo de software ágil siempre comienza por definir a los usuarios y documentar una declaración de visión sobre un alcance de problemas, oportunidades y valores que deben abordarse. El propietario del producto captura esta visión y trabaja con un equipo (o equipos) multidisciplinario para cumplir con esta visión. Estos son los roles en ese proceso.

Usuario

Los procesos ágiles siempre comienzan pensando en el usuario o cliente. Hoy en día, a menudo los definimos con personas de usuario para ilustrar diferentes roles en un flujo de trabajo que el software está respaldando o diferentes tipos de necesidades y comportamientos del cliente.

Dueño del producto

El proceso de desarrollo ágil en sí mismo comienza con alguien a quien se requiere que sea la voz del cliente, incluidas las partes interesadas internas. Esa persona extrae todos los conocimientos, ideas y comentarios para crear una visión del producto. Estas visiones de productos suelen ser breves y sencillas, pero, no obstante, pintan una imagen de quién es el cliente, qué valores se están abordando y una estrategia para abordarlos. Me imagino que la visión original de Google era algo así como "Facilitemos a cualquier persona con acceso a Internet la búsqueda de sitios web y páginas web relevantes con una interfaz simple basada en palabras clave y un algoritmo que clasifica las fuentes confiables más arriba en los resultados de búsqueda".

A esta persona la llamamos propietario del producto . Su responsabilidad es definir esta visión y luego trabajar con un equipo de desarrollo para hacerla realidad.

Para trabajar con el equipo de desarrollo, el propietario del producto divide la visión del producto en una serie de historias de usuarios que explican con más detalle quién es el usuario objetivo, qué problema se está resolviendo para ellos, por qué la solución es importante para ellos y qué restricciones y criterios de aceptación definen la solución. Estas historias de usuario son priorizadas por el propietario del producto, revisadas por el equipo para garantizar que tengan un entendimiento compartido sobre lo que se les pide.

Equipo de desarrollo de software

En ágil, el equipo de desarrollo y las responsabilidades de sus miembros difieren de las del desarrollo de software tradicional.

Los equipos son multidisciplinarios, compuestos por un grupo diverso de personas con las habilidades para hacer el trabajo. Debido a que el enfoque está en entregar software que funcione, el equipo tiene que completar aplicaciones funcionales de extremo a extremo. Por lo tanto, la base de datos, la lógica empresarial y la interfaz de usuario de parte de la aplicación se desarrollan y luego se muestran en una demostración, no toda la aplicación. Para hacer esto, los miembros del equipo deben colaborar. Se reúnen con frecuencia para asegurarse de que todos estén alineados con lo que están construyendo, quién está haciendo qué y exactamente cómo se está desarrollando el software.

Además de los desarrolladores, los equipos de desarrollo de software pueden incluir ingenieros de aseguramiento de la calidad (QA), otros ingenieros (como para bases de datos y sistemas de back-end), diseñadores y analistas, según el tipo de proyecto de software.

Scrum, Kanban y otros marcos ágiles

Muchos marcos ágiles que brindan detalles sobre procesos de desarrollo y prácticas de desarrollo ágiles, alineados con un ciclo de vida de desarrollo de software.

El marco ágil más popular se llama scrum . Se centra en una cadencia de entrega llamada sprint y estructuras de reunión que incluyen lo siguiente:

  • Planificación: donde se identifican las prioridades del sprint
  • Compromiso: donde el equipo revisa una lista o acumulación de historias de usuarios y decide cuánto trabajo se puede hacer durante la duración del sprint. 
  • Reuniones de pie diarias, para que los equipos puedan comunicar actualizaciones sobre su estado y estrategias de desarrollo)

Los Sprints terminan con una reunión de demostración en la que se muestra la funcionalidad al propietario del producto, seguida de una reunión retrospectiva en la que el equipo analiza qué salió bien y qué necesita mejorar en su proceso.

Muchas organizaciones emplean scrum masters o entrenadores para ayudar a los equipos a gestionar el proceso de scrum.

Aunque scrum domina, existen otros marcos ágiles:

  • Kanban funciona como un proceso de entrada y salida en el que el equipo extrae historias de usuarios de un tablero de entrada y las canaliza a través de un proceso de desarrollo por etapas hasta que se completan.
  • Algunas organizaciones adoptan un enfoque híbrido ágil y en cascada, utilizando procesos ágiles para nuevas aplicaciones y cascada para las heredadas.
  • También hay varios marcos que permiten a las organizaciones escalar la práctica a varios equipos.

Mientras que los marcos ágiles definen el proceso y la colaboración, las prácticas de desarrollo ágiles son específicas para abordar las tareas de desarrollo de software realizadas en alineación con un marco ágil.

Así por ejemplo:

  • Algunos equipos adoptan la programación por pares, en la que dos desarrolladores codifican juntos para impulsar un código de mayor calidad y permitir que los desarrolladores más experimentados sirvan de mentores a los más jóvenes.
  • Los equipos más avanzados adoptan el desarrollo y la automatización basados ​​en pruebas para garantizar que la funcionalidad subyacente proporcione los resultados esperados.
  • Muchos equipos también adoptan estándares técnicos para que la interpretación del desarrollador de una historia de usuario no conduzca solo a la funcionalidad deseada, sino que también cumpla con la seguridad, la calidad del código, las convenciones de nomenclatura y otros estándares técnicos.

Por qué la metodología ágil es mejor