Gestión de proyectos tradicional frente a ágil: Diferencias clave y explicación del triángulo de hierro

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.

Waterfall vs Agile Software Development

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:

Success Rate of Waterfall vs Agile Projects

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:

Cost of Change in Traditional vs Agile

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.

Iron Triangle in Agile vs Traditional Project Management

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.

Iron Triangle in Agile Context

Triángulo de Hierro en contexto ágil

 

Dejar una contestacion