El marco Scrum — Segunda edición

Este capítulo conserva el contexto histórico y práctico de la segunda edición. El temario de la tercera edición también está disponible en el índice que aparece a continuación.

---

¿Por qué puede fallar el modelo de desarrollo de software en cascada? - International Scrum Institute

Los estudios han mostrado que, en más del 80% de los proyectos de software fallidos investigados, el uso de la metodología en cascada fue uno de los principales factores del fracaso. ¿Por qué?

Fases del modelo clásico de desarrollo de software en cascada

Como se muestra arriba, la metodología en cascada establece una cadena estrictamente secuencial de fases del proyecto. Una fase debe completarse antes de comenzar la siguiente. Volver atrás suele resultar difícil, costoso, frustrante para el equipo y lento.

El calendario del proyecto se planifica al principio. Un producto entregable solo está disponible al final. Si una fase se retrasa, también se retrasan las demás.

Para evitarlo, quienes utilizan la metodología en cascada suelen intentar prever todas las posibilidades de antemano. Esto significa que, en una fase muy temprana del proyecto, intentan definir todos los requisitos con el máximo detalle y de la forma más completa posible. Sin embargo, definir los requisitos tan pronto suele ser muy difícil, por lo que muchos cambian o deberían cambiar durante el proyecto. Los estudios han mostrado que, en proyectos grandes y complejos, alrededor del 60% de los requisitos iniciales cambian a lo largo del trabajo. Otros se implementan según lo definido, pero el cliente no los necesita realmente y consumen un tiempo valioso que podría haberse dedicado a funcionalidades con mayor valor añadido.

La separación en fases obliga a estimar cada una por separado. El problema es que, normalmente, esas fases no están completamente separadas. En la práctica, las actividades suelen solaparse e influirse mutuamente.

El enfoque en cascada puede utilizarse en proyectos pequeños y sencillos. Sin embargo, en proyectos más grandes y complejos, resulta muy arriesgado, a menudo más costoso y generalmente menos eficiente que el marco Scrum.