Waterfall

Waterfall ejecuta un proyecto como una secuencia ordenada de fases: reunir todos los requisitos, luego diseñar todo el sistema, luego construirlo, luego probarlo, luego desplegarlo. Cada fase produce un documento aprobado y termina antes de que empiece la siguiente. El atractivo es obvio: conoces el plan, el coste y la fecha por adelantado, y todos están de acuerdo antes de escribir una línea de código.

Aún encaja legítimamente en cierto trabajo. Cuando el alcance es genuinamente fijo y bien entendido, cuando un regulador exige documentación y trazabilidad por adelantado, o cuando construyes hardware donde no puedes iterar barato después de cortar el metal, las fases secuenciales son el modelo honesto. Fingir que un proyecto así es “ágil” solo esconde el plan en lugar de eliminarlo.

Falla gravemente en el descubrimiento de producto. La suposición fatal es que puedes especificar el producto correcto por adelantado, antes de que ningún usuario lo haya tocado. Casi nunca puedes. Para cuando termina la fase de construcción, los requisitos reunidos meses antes son en parte erróneos, y Waterfall no tiene una forma barata de descubrirlo hasta la fase de prueba, cuando cambiar cualquier cosa es caro. Obtienes un producto que coincide con la especificación y se salta la necesidad.

La distinción honesta respecto a Agile: Waterfall concentra todas las decisiones al principio y apuesta a que son correctas. Agile reparte las decisiones a lo largo del trabajo y apuesta a que la retroalimentación temprana atrapará las equivocadas. Para cualquier cosa donde aún no sepas exactamente qué construir, esa apuesta favorece a Agile. Para cualquier cosa donde la respuesta sea genuinamente conocida y fija, la previsibilidad de Waterfall es una virtud, no un defecto.