Ya sea que seas un Master de Scrum, gerente de proyectos, Propietario del producto, miembro del equipo, o simplemente alguien tratando de responder: “¿Cómo se gestiona un proyecto de Ágil Scrum en el mundo real?” — este artículo definitivamente te proporcionará las respuestas que necesitas.
Gestión de proyectos tradicional
El enfoque tradicional de gestión de proyectos (modelo cascada) es lineal, donde todas las fases del proceso ocurren de forma secuencial. Este método se basa en herramientas predecibles y experiencias predecibles. Cada proyecto sigue el mismo ciclo de vida, que incluye las fases de viabilidad, planificación, diseño, construcción, pruebas, producción y soporte, como se muestra en la figura de abajo.

Desarrollo de software cascada frente a ágil
Todo el proyecto está previamente planificado sin espacio para cambios en los requisitos — al igual que la cascada, el PMBOK de PMI y PRINCE2 son rígidos y altamente controlados. Establecen fases distintas desde el inicio hasta el final y asumen que ya tienes todos los requisitos y la información que necesitas.
Este enfoque asume que el tiempo y el costo son variables, mientras que los requisitos son fijos — razón por la cual la gestión de proyectos tradicional a menudo tiene problemas con el presupuesto y los plazos.
Gestión de proyectos ágil
Mientras que los sistemas tradicionales se enfocan mucho en la planificación inicial, factores como el costo, el alcance y el tiempo son críticos. Por otro lado, el ágil enfatiza el trabajo en equipo, la colaboración con el cliente y la flexibilidad.
El ágil rechaza la gestión de proyectos tradicional como tediosa, restrictiva e inadecuada para el mundo moderno de ritmo acelerado. La gestión de proyectos ágil es iterativa, con el objetivo de integrar continuamente el feedback del usuario y lanzamientos constantes con cada iteración de desarrollo, como se muestra arriba. Cada resultado de tarea es un producto que vendes a los interesados. Los equipos y flujos de trabajo están estructurados en torno a crear algo directamente útil para el cliente.
¿Tradición o ágil – ¿cómo elegir?
Según el informe CHAOS de 2011 del grupo Standish, los proyectos ágiles tienen tres veces más éxito que los proyectos en cascada. La gráfica de abajo muestra los resultados específicos de los estudios realizados entre 2002 y 2012:

Tasa de éxito de proyectos en cascada frente a proyectos ágiles
Diferencias entre lo tradicional y lo ágil
La tabla de abajo resume muchas diferencias clave entre los modelos de gestión de proyectos Scrum y tradicional.
| Categoría | Tradicional | Ágil |
| Modelo de desarrollo | Secuencial (cascada) | Iterativo |
| Enfoque | Proceso | Personas |
| Estilo de gestión | Control | Facilitación |
| Involucramiento del cliente | Limitado a las fases de recopilación de requisitos y entrega | Involucramiento continuo y en el lugar |
| Estilo de trabajo del desarrollador | Trabaja de forma individual dentro del equipo | Programación colaborativa o en pareja |
| Tecnología | Cualquiera | Principalmente orientado a objetos |
| Características del producto | Todas las características incluidas | Las características más importantes primero |
| Pruebas | Al final del ciclo de desarrollo | Iterativo y/o orientado a pruebas |
| Documentación | Extensa | Solo cuando sea necesario |
Costo del cambio
Tradicionalmente, se evitan los cambios en los proyectos de software porque el costo aumenta significativamente más adelante en el proyecto. El desarrollo de software ágil reconoce que el cambio es inevitable y que invertir mucho en planificación previa es poco práctico. Esto se expresa claramente en uno de los cuatro valores del Manifiesto Ágil:
“Responder a los requisitos cambiantes en lugar de seguir un plan fijo.”
El enfoque ágil cuestiona esta idea y argumenta que el costo del cambio puede ser relativamente plano, como se muestra en la figura a continuación:

Costo del cambio en tradicional frente a ágil
Ágil frente a tradicional en el triángulo de hierro de gestión de proyectos
El éxito en la gestión de proyectos tradicionalmente se ha asociado con la capacidad de gestionar las restricciones de alcance, tiempo, costo y calidad, como se muestra en la figura a continuación. Este es un metáfora popular que sugiere que se espera que los gerentes de proyectos equilibren razonablemente estas restricciones.

Triángulo de hierro en ágil frente a gestión tradicional de proyectos
¿Cuál es el problema con el Triángulo de Hierro tradicional?
Por ejemplo, un proyecto puede completarse más rápido aumentando el presupuesto o reduciendo el alcance. Asimismo, ampliar el alcance generalmente requiere un aumento correspondiente en el presupuesto y el plazo. Reducir el presupuesto sin ajustar el plazo o el alcance conduce a una disminución de la calidad. Sin embargo, en la práctica, los intercambios entre las restricciones no siempre son factibles. Por ejemplo, invertir más fondos (y personas) en un proyecto con recursos abundantes puede ralentizar realmente el progreso. Además, en proyectos con bajo rendimiento, mejorar el presupuesto, el cronograma o el alcance sin afectar negativamente la calidad a menudo es imposible.
Por tanto, el Triángulo de Hierro tradicional es claramente insuficiente como modelo para el éxito del proyecto, ya que ignora dimensiones clave del éxito, incluyendo el impacto en los interesados, el aprendizaje y la satisfacción del usuario.
Triángulo de Hierro Ágil – Un cambio de paradigma
En el enfoque tradicional, el triángulo suele tener la forma de la figura de la izquierda que se muestra a continuación. Como puede ver, los requisitos del producto tienen un alcance fijo. Por lo tanto, para garantizar que el producto entregue todas las funciones requeridas, necesitamos flexibilidad en nuestros recursos (y presupuesto) y en el plazo (fecha límite). Si necesitamos absolutamente que el producto incluya toda la lista de funciones descritas en la especificación inicial de requisitos, podríamos necesitar retrasar la fecha de lanzamiento en varios meses o más.
En sentido ágil, hay un plazo fijo (en Scrum, esto se logra mediantetiempo limitado Sprintsy recursos fijos). Por lo tanto, cuando las cosas no salen según lo planeado, el alcance debe reducirse. Pero en ágil, garantizamos que incluso si debemos comprometernos en el alcance, aún entregamos los elementos de mayor prioridad delBacklog del Productopara maximizar el valor generado por el proyecto.

Triángulo de Hierro en contexto ágil