Los estudios han demostrado que en más del 80% de los proyectos de software investigados y fallidos, el uso de la metodología Waterfall (Cascada) fue uno de los factores clave del fracaso. ¿Pero por qué?
Como se muestra arriba, al implementar la metodología en cascada existe una estricta cadena secuencial de las diferentes fases del proyecto. Se debe completar una fase previa antes de comenzar la siguiente fase. Volver atrás es, en la mayoría de los casos, difícil, costoso, frustrante para el equipo y requiere mucho tiempo.
El cronograma del proyecto se planifica desde el principio. Un producto liberable se entrega solo al final del cronograma del proyecto. Si una fase se retrasa, todas las demás fases también se retrasan.
Fases en el modelo clásico de desarrollo de software en cascada
Para evitar esto, los usuarios de la metodología en cascada normalmente tratan de anticipar todas las posibilidades de antemano. Esto significa que en una de las primeras fases del proyecto intentan definir todos los requisitos de la forma más detallada y completa posible. Sin embargo, la definición de requisitos en una fase tan temprana del proyecto suele ser muy difícil y, por lo tanto, muchos requisitos cambian (o deberían cambiar) a lo largo de la página
el proyecto. Los estudios han demostrado que en proyectos más grandes y complejos, alrededor del 60% de los requisitos iniciales se modifican a lo largo del proyecto. Otros requisitos se implementan según lo definido, pero no son realmente necesarios para el cliente y consumen un tiempo valioso que podría haberse utilizado mejor para implementar una funcionalidad con un mayor valor añadido para el cliente.
La separación en diferentes fases del proyecto obliga a los usuarios a estimar cada fase por separado. El problema es que la mayoría de estas fases normalmente no están separadas. Están trabajando juntos y en paralelo.
El enfoque en cascada para el desarrollo de software se puede utilizar para implementar proyectos pequeños y simples. Pero para proyectos más grandes y complejos, se puede decir que este enfoque es altamente arriesgado, a menudo más costoso y, en general, menos eficiente que el marco de gestión de proyectos Scrum.
