Ágil frente a cascada

• Los requisitos detallados del producto y la documentación permiten a los nuevos programadores incorporarse rápida y fácilmente.
• La documentación proporciona un alcance claro para el proyecto, lo que permite a los gerentes de proyecto comunicar presupuestos, cronogramas e hitos clave a las partes interesadas.

• A los clientes les puede resultar difícil describir todos sus requisitos al comienzo del proyecto, lo que genera lagunas en la documentación.
• La mínima colaboración del cliente durante el proceso de desarrollo puede generar cambios costosos si el producto no cumple con las expectativas.
• Los evaluadores informan problemas y errores más adelante en el proceso, lo que podría haber informado una arquitectura de programa alternativa.

A diferencia del desarrollo en cascada, ágil se define por su enfoque iterativo de la gestión de proyectos. En lugar de redactar largos requisitos del proyecto desde el principio, un equipo ágil divide el producto en características específicas y aborda cada una de ellas bajo una restricción de tiempo específica, conocida como sprint.

La gestión ágil de proyectos requiere un equipo multifuncional y autoorganizado que normalmente consta de cinco a nueve miembros. Juntos, desarrollan una pieza de software viable durante cada sprint, que se combina con otro código funcional de iteraciones anteriores. Al final del cronograma del sprint, el equipo demuestra su trabajo a los stakeholders para recibir retroalimentación, lo que les permite ser flexibles en su enfoque del desarrollo de software. Dado que el equipo tiene acceso a feedback frecuente, puede adaptar la hoja de ruta del producto durante el ciclo de vida del desarrollo para garantizar que la funcionalidad realmente satisfaga las expectativas del usuario. En un enfoque en cascada, la participación del cliente suele coincidir con la entrega del producto final, lo que puede ser costoso cuando los requisitos se malinterpretan o documentan incorrectamente.

Hubo 17 personas que encontraron que el sistema de gestión de proyectos en cascada era muy ineficaz y, en 2001, sus ideas en torno al proceso de desarrollo de software culminaron en un trabajo conocido como el" Manifiesto ágil ". Este documento destaca valores y principios específicos para priorizar dentro de los flujos de trabajo de desarrollo de software, y ha producido una serie de infraestructuras ágiles populares, como Scrum, Kanban, Desarrollo impulsado por características (FDD) y Programación extrema. Desde entonces, el desarrollo ágil de software ha aumentado en popularidad, especialmente en comparación con el modelo en cascada.

Inspirado en el juego de rugby, el scrum ágil enfatiza el trabajo en equipo para cumplir con los entregables, de manera similar a la forma en que los delanteros deben trabajar juntos en un scrum para obtener posesión de una pelota de rugby. El conjunto de habilidades del equipo ágil de scrum varía, pero generalmente incluyen los siguientes roles:

• Propietario del producto: este miembro del equipo representa las necesidades tanto del cliente como de la empresa. Al elaborar historias de usuarios, el equipo puede comprender cómo una solicitud de característica puede ayudar a resolver un problema específico, y estas historias formulan la acumulación de tareas que el equipo debe abordar. Esta persona también prioriza las historias por su valor para el cliente, lo que, en teoría, debería traducirse en valor para el negocio. Si bien el propietario del producto dirige al equipo de esta manera, no establece plazos ni instruye al equipo sobre cómo debe entregarse el trabajo.
• Scrum master: este miembro del equipo facilita el proceso general de desarrollo ágil. Al igual que un gerente de proyecto, esta persona mantiene al equipo enfocado en la tarea, asegurando que el equipo permanezca enfocado durante el proyecto. También pueden actuar como una parte neutral para mediar en los desacuerdos entre los miembros del equipo. Por ejemplo, los miembros del equipo pueden estar en desacuerdo sobre cuánto asumir en un sprint determinado. Los propietarios de productos, en particular, pueden presionar a los equipos para que se comprometan con más de lo que pueden entregar dentro de un plazo determinado. En estos casos, los scrum masters pueden recordar a los miembros del equipo el alcance de su función en el equipo.

Los otros miembros del equipo de un equipo ágil pueden variar, pero suelen incluir usuarios de una variedad de disciplinas, como diseño, analytics, control de calidad y desarrollo. Estas personas colaboran para decidir cuánto trabajo asumir y cómo lo completarán.

Las metodologías ágiles también se definen por las formas en que el equipo se une. Hay reuniones específicas que ayudan a facilitar el flujo de trabajo en todo el equipo. Algunos de ellos incluyen los siguientes:

• Planificación del sprint: durante esta reunión, el equipo se reúne para determinar qué historias formarán parte del sprint actual. El propietario del producto priorizará las historias de usuario, pero el resto del equipo deberá acordar cuántas y qué historias de usuario pueden completar durante ese período de tiempo establecido.
• Reunión diaria: estas breves reuniones también se conocen como scrums diarios. Durante estos registros, cada miembro del equipo comunica su progreso individual, como las tareas completadas, las próximas y cualquier bloqueador o dependencias que pueden provocar retrasos.
• Demostración: esta reunión muestra el software de trabajo que el equipo completó en el transcurso del sprint, que puede variar entre incrementos de dos a cuatro semanas. El propietario del producto determinará si una historia de usuario cumple con la definición de "hecho". De lo contrario, la cartera de productos puede arreglarse para tener en cuenta cualquier cosa que falte. Esta es también una oportunidad para que el equipo se presente a los stakeholders para obtener feedback.
• Retrospectiva: este tiempo está reservado para la introspección del equipo, donde el equipo identifica cómo podría mejorar su flujo de trabajo para lograr mejores resultados en el futuro

• El diseño del equipo facilita una mayor colaboración.
• El desarrollo de productos adopta un enfoque de diseño adaptativo.
• Dado que el código se prueba con cada iteración en la fase de desarrollo, los defectos del código pueden informar el diseño futuro del software.
• Tiende a generar una mayor satisfacción del cliente, ya que la retroalimentación frecuente conduce a una mayor priorización de las necesidades del cliente.
• Permite la integración continua, ya que cada característica es su propia pieza de software viable.
• Este tipo de desarrollo de software esbelto puede reducir los costos, ya que hay menos riesgo de desalineación entre el cliente y el producto.

• Un enfoque ágil puede carecer de documentación completa. Esto dificulta la incorporación de nuevos desarrolladores, los plazos de los proyectos a los stakeholders y proporcionar estimaciones de costos precisas.
• Puede ser difícil a escala.

Si bien los equipos de desarrollo han tenido éxito con cualquiera de los dos enfoques de gestión de proyectos, ciertamente hay más impulso en torno a los procesos ágiles. No es difícil ver por qué cuando observamos los beneficios que puede ofrecer a las empresas hoy en día. Si bien hay una serie de herramientas de gestión de proyectos que pueden ayudar a los equipos a realizar un seguimiento del progreso, IBM también puede proporcionar sistemas que permitan a los desarrolladores codificar de una manera más ágil.