Comparación: gestión de proyectos ágil y en cascada

Los primeros en adoptar el desarrollo ágil solían ser pequeños equipos independientes que trabajaban en proyectos pequeños e independientes. Demostraron que el modelo ágil funcionaba, para regocijo de los desarrolladores de software de todo el mundo y mejora de sus condiciones. Resultó que, para la mayoría de los equipos, el modelo de desarrollo en cascada no era tan eficaz para el desarrollo de software como sí lo era la gestión de proyectos ágil.

Debido a la popularidad de la gestión de proyectos ágil, cada vez más organizaciones escalan la metodología ágil más allá de equipos y proyectos individuales, para aplicarla a programas enteros. La metodología ágil se ha extendido incluso más allá de los equipos de desarrollo, y ahora la utilizan en equipos de TI, marketing y desarrollo empresarial, entre otros.

El modelo de gestión de proyectos en cascada implica una secuencia de ejecuciones claramente definida, con proyectos que no pasan de fase hasta que la anterior recibe la aprobación final. Una vez finalizada una fase, puede ser difícil y costoso revisar una etapa anterior. Los equipos ágiles pueden seguir una secuencia similar, pero lo hacen en incrementos más pequeños con ciclos de feedback regulares.

El modelo de gestión de proyectos en cascada sigue un enfoque lineal y secuencial. Funciona bien para trabajos que implican procesos predecibles y recurrentes, pero puede dejar a los equipos de desarrollo en mala posici´ón ante los imprevistos y sin la posibilidad de adaptarse más rápido que la competencia.

Cualquier incumplimiento de plazos o cambio en el alcance durante un proyecto en cascada puede tener un gran impacto en las versiones posteriores. Además, puede resultar difícil resolver la deuda técnica o corregir errores si el equipo tiene que centrarse en desarrollar funciones nuevas y avanzar por las distintas etapas del proyecto.

Abajo hemos incluido una imagen con un proyecto en cascada estándar, dividido en bloques de tiempo estrictos. Este modelo fomenta una mentalidad de "máximo aprovechamiento" que anima a desarrolladores, propietarios de productos y partes interesadas a solicitar la mayor cantidad de tiempo posible en cada periodo de tiempo, ya que puede que no haya oportunidad de iterar en el futuro. Por lo general, los equipos que utilizan el modelo en cascada intentan controlar la corrupción del alcance a través del llamado "control de cambios", por el cual aceptan que no debe modificarse el plan original.

El modelo en cascada puede agravar algunas de las dificultades habituales del desarrollo de productos:

• Impedimentos y gestión de dependencias: los estilos tradicionales de gestión de proyectos suelen crear "rutas críticas" que impiden que el proyecto avance hasta que se resuelva una incidencia que lo bloquea.
• Dificultad para obtener el feedback de los usuarios y validar los productos: por si fuera poco, los clientes finales no pueden interactuar con el producto hasta que no esté del todo completo. Esto tiene como consecuencia que los problemas importantes relacionados con el diseño del producto y el código no se descubren hasta la publicación.

Ventajas del modelo en cascada

• Requiere menos coordinación debido a que los procesos son secuenciales, con fases claramente definidas.
• Tener claramente definidas las fases del proyecto ayuda a definir con precisión las dependencias del trabajo.
• El coste del proyecto se puede estimar una vez definidos los requisitos.
• Permite centrarse mejor en la documentación de diseños y requisitos.
• La fase de diseño es más metódica y estructurada, antes de escribir cualquier software.

Inconvenientes del modelo en cascada

• Es más difícil dividir y compartir el trabajo debido a que las secuencias de fases son más estrictas y los equipos están más especializados.
• Hay riesgo de pérdida de tiempo debido a retrasos y contratiempos durante las transiciones de fase a fase.
• Supone tener en cuenta requisitos de contratación adicionales para configurar equipos de fase especializados, mientras que la metodología ágil fomenta equipos más multifuncionales.
• Más sobrecarga de comunicación durante la entrega entre transiciones de fase.
• Es posible que la propiedad y la implicación en el producto no sean tan sólidas como las que ofrece la metodología ágil, ya que la atención se centra en la fase actual.

La metodología ágil se empezó a adoptar en equipos de software, que pasaron del tradicional modelo secuencial en cascada a un método que permitía recoger feedback y hacer ajustes de forma continua a lo largo del ciclo de vida de desarrollo.

La gestión de proyectos ágil adopta un enfoque iterativo de desarrollo, ya que crea varios pasos incrementales con intervalos de feedback regulares. Este modelo promueve la adaptabilidad, ya que un equipo puede hacer ajustes a lo largo del proceso de desarrollo del producto, en lugar de tener que limitarse a una trayectoria lineal. También permite realizar publicaciones regulares y de gran impacto para que los equipos puedan lograr una serie de victorias a lo largo del tiempo.

Las publicaciones iterativas permiten al equipo hacer lo siguiente:

• Adaptarse a los cambios, como requisitos nuevos o impedimentos que bloquean parte del trabajo.
• Recoger el feedback de las partes interesadas durante el proceso y hacer ajustes a la hora de iterar sin el estrés que causan los plazos de entrega.
• Crear relaciones y conexiones entre personas con funciones diferentes para que puedan colaborar y comunicarse de forma eficaz.

La metodología ágil permite a los equipos adaptarse mejor a los inevitables cambios que se producen durante un proyecto.

Una ventaja aún mayor es que los conjuntos de aptitudes se comparten en el equipo de software. De este modo, se añade una mayor flexibilidad al trabajo en todas las partes de la base de código del equipo y no se malgasta tiempo ni esfuerzo si cambia la orientación del proyecto. Para saber más acerca de todo esto, lee nuestro artículo sobre crear grandes equipos ágiles.

• Un proyecto ágil se segmenta en una serie de pasos incrementales que incluyen intervalos de feedback regulares.
• Cada requisito del proyecto se divide en fragmentos más pequeños, que luego se priorizan según su importancia.
• Promueve la colaboración, especialmente con el cliente.
• Permite hacer ajustes en intervalos regulares para conseguir que se satisfagan las necesidades del cliente.
• Integra la planificación con la ejecución, lo que permite al equipo responder de forma eficaz a los cambios de requisitos.

Ventajas de la gestión de proyectos ágil

• Ciclos de feedback más rápidos.
• Los problemas se identifican más temprano.
• Mayor potencial de satisfacción del cliente.
• El tiempo de salida al mercado mejora drásticamente.
• Mayor visibilidad y responsabilidad.
• Los equipos dedicados mejoran la productividad con el tiempo.
• Priorización flexible centrada en la entrega de valor.

Inconvenientes de la metodología ágil

• Es posible que las dependencias críticas entre proyectos y rutas no estén tan claramente definidas como con el modelo en cascada.
• Coste extra de la curva de aprendizaje organizativa.
• Implementar una ejecución verdaderamente ágil con una canalización de implementación continua supone muchas dependencias técnicas y costes de ingeniería.

Pasarse a la metodología ágil puede ser todo un reto, especialmente si el equipo o la organización se basa en un modelo de gestión de proyectos más tradicional. Para adoptar prácticas ágiles, puede ser necesario realizar cambios en los procesos, sobre todo si se quiere adoptar el modelo DevOps, que implica que los equipos de desarrollo y de operaciones colaboren estrechamente para desarrollar y mantener el software. Al implementar principios de metodología ágil, el equipo y las partes interesadas deben tener en cuenta dos conceptos importantes:

• La atención del propietario del producto debe centrarse en optimizar el valor de los resultados del equipo. Además, debe ayudar al equipo a priorizar el trabajo más importante.
• El equipo de desarrollo solo puede aceptar trabajo si tiene la capacidad de hacerlo. El propietario del producto no debe imponer el trabajo al equipo ni obligarle a comprometerse con plazos arbitrarios. El equipo de desarrollo se asigna trabajo del backlog del programa cuando puede aceptar más trabajo.

Descubramos los mecanismos que usan los programas ágiles para organizar, ejecutar y estructurar el trabajo de forma iterativa.

La hoja de ruta describe cómo se desarrolla en el tiempo un producto o solución. En el desarrollo ágil, proporciona contexto muy útil para ayudar a los equipos a alcanzar objetivos tanto incrementales como a nivel de todo el proyecto. Las hojas de ruta están formadas por iniciativas, que son grandes áreas de funcionalidad, e incluyen cronogramas que indican cuándo estará disponible una función. A medida que el trabajo avanza y los equipos recaban nueva información, es normal que la hoja de ruta cambie para reflejarla, ya sea ligeramente o de forma más significativa. El objetivo es que la hoja de ruta siga centrada en las condiciones actuales que afectan al proyecto y en los objetivos a largo plazo, de modo que el equipo pueda trabajar eficazmente con las partes interesadas y seguir siendo competitivo.

Aquí puedes ver una hoja de ruta sencilla de un equipo de producto, con las iniciativas en recuadros y los plazos indicados por los marcadores de hitos en rojo.

Las iniciativas de la hoja de ruta se dividen en una serie de requisitos. Los requisitos ágiles son descripciones breves de la funcionalidad necesaria, en lugar de los documentos de 100 páginas que se asocian con los proyectos tradicionales. Evolucionan con el tiempo y aprovechan el entendimiento común que el equipo tiene del cliente y del producto deseado. Los requisitos ágiles siguen siendo lean mientras todo el equipo desarrolla un entendimiento común mediante la conversación y la colaboración constantes. Únicamente cuando la implementación está a punto de empezar, se concretan los pormenores con todo detalle.

El backlog define las prioridades del programa ágil. El equipo incluye todos los elementos de trabajo en el backlog: funcionalidades nuevas, bugs, mejoras, tareas técnicas o arquitectónicas, etc. El propietario del producto prioriza el trabajo del backlog para el equipo de ingenieros. Más adelante, el equipo de desarrollo utiliza el backlog priorizado como única fuente fiable para saber qué trabajo hay que hacer.

Los equipos ágiles progresan gracias a las métricas. Los límites del trabajo en curso hacen que el equipo y la empresa sigan concentrados en entregar el trabajo de la más alta prioridad. Gráficos como el de control o el diagrama de trabajo pendiente ayudan a que el equipo prevea su cadencia de entrega, y los diagramas de flujo continuo ayudan a identificar cuellos de botella. Estas métricas y artefactos hacen que todos se centren en los grandes objetivos e infunden confianza en la habilidad del equipo para entregar futuros trabajos.

Los procesos ágiles no pueden funcionar si no hay un alto nivel de confianza entre los miembros del equipo. Hace falta sinceridad para mantener conversaciones difíciles sobre lo que es conveniente para el programa y el producto. Puesto que las conversaciones tienen lugar a intervalos periódicos, las ideas y preocupaciones se expresan con regularidad. Esto significa que los miembros del equipo también tienen que confiar en las habilidades (y la disposición) de los demás para llevar a efecto las decisiones que se tomen durante esas conversaciones.

La gestión ágil de proyectos es un modelo innovador para todo tipo de proyectos, no solo los de software. Al proporcionar la flexibilidad para responder a los cambios durante el ciclo de vida del desarrollo, la metodología ágil permite a los equipos lanzar productos de mayor calidad que satisfagan las necesidades de los clientes. Además, motiva a los equipos; fomenta la responsabilidad, la innovación y la mejora continua; y permite responder a los cambios sin desbordarse. Y eso le viene de maravilla a cualquier programa.

Obtén más información sobre la gestión ágil de proyectos y consulta nuestra plantilla gratuita de gestión de proyectos. Además, sumérgete en la adopción de esta metodología con herramientas ágiles para equipos de software y aprende a comunicar cómo avanza el trabajo entre los distintos equipos.