Olvídese de Agile un minuto, piense en lo que se entiende por "cascada".
Hay una fase de requisitos, en la que todos intentan averiguar QUÉ problemas debe resolver el producto final. La gente discute sobre esto por un tiempo, y luego todos firman un conjunto de requisitos. En este punto, se define su alcance, se firman los contratos y el cliente puede desviarse y esperar a que encuentre un producto que resuelva esos requisitos definidos.
A continuación hay una (o quizás dos) fases de diseño. Los diseñadores (que pueden o no ser los desarrolladores) discuten sobre CÓMO el sistema debe unirse para cumplir con los requisitos aprobados. Pueden surgir problemas si no comprenden del todo un requisito, lo que puede significar que tienen que volver al cliente, potencialmente reabrir la fase de requisitos (y obtener otra ronda de firmas) o al menos poner en marcha la gestión de cambios . A menudo, los diseñadores simplemente hacen su mejor suposición. Pueden proponer un modelo de datos lógico y muchos UML que describan un nuevo sistema y cómo debería funcionar. Luego lo firman.
Ahora los desarrolladores pueden comenzar a codificar, según el diseño aprobado. Pueden surgir problemas si no comprenden completamente el diseño, lo que puede significar que tienen que volver al diseñador, potencialmente reabrir la fase de diseño (y obtener otra ronda de aprobaciones) o al menos poner en marcha la gestión del cambio. . A su vez, los diseñadores pueden darse cuenta de que la confusión realmente se remonta a los requisitos, lo que significa que tienen que reabrir las discusiones sobre los requisitos, las aprobaciones y una mayor gestión del cambio. A menudo, los programadores (que tienen una fecha límite inminente) simplemente hacen su mejor suposición. Hacen lo que pueden para crear código funcional. Luego lo lanzan a prueba.
Ahora se inicia la fase de prueba del sistema. Los probadores prueban según su comprensión de los requisitos y el diseño, y registran lo que perciben como defectos en un sistema de gestión de seguimiento / cambio de errores, lo que hace que los desarrolladores comiencen a desarrollar nuevamente, a menos que vean el problema como un defecto de diseño, que lo devuelve al diseño, etc. Finalmente, las pruebas del sistema pasan y se cierran.
Finalmente, el cliente regresa y realiza pruebas de aceptación del usuario en el nuevo sistema. Aquí es donde deciden si la solución que probaron los probadores, los desarrolladores desarrollaron y los diseñadores diseñaron es realmente lo que quieren. Si no es así, posiblemente tenga que volver a la fase de diseño o incluso volver a visitar los requisitos.
La idea detrás de la cascada es que es difícil (y muy indeseable) regresar una vez que se completa una fase. Generalmente, diferentes personas están involucradas en diferentes fases, por lo que hay múltiples transferencias, cada una de las cuales presenta un gran riesgo de mala interpretación y pérdida de información. También hay una brecha significativa entre cuándo los clientes dicen lo que quieren y cuándo ven lo que se ha construido, en cuyo momento los requisitos reales pueden haber cambiado.
Las metodologías ágiles se centran en una fuerte comunicación y cooperación entre todas las partes interesadas. El principio "Colaboración del cliente sobre la negociación del contrato" significa que no debería tener que pasar por una serie de firmas y transferencias, sino que simplemente debe trabajar junto con el cliente, cada iteración determina los requisitos para una pieza del rompecabezas e inmediatamente formando pruebas, un diseño y un código de trabajo, con todos los jugadores comunicándose lo más directamente posible (eliminando costos y riesgos de traspaso). El cliente puede comprobar rápidamente el código de trabajo, eliminando los riesgos de retraso. Todas las actividades suceden en un remolino colaborativo, no en un flujo descendente.
Para obtener una excelente visión general de lo que intentan hacer las metodologías ágiles, recomiendo el Desarrollo de software ágil de Allistair Cockburn : El juego cooperativo .