Waterfall vs. Agile

Luego de leer y releer bastante sobre ambas métodologías, Waterfall y Agile, no puedo dejar de ver que Waterfall es una metodología hecha y pensada para la industria manufacturera (recuerdo haber escuchado una explicación en una facultad, poniendo de ejemplo la fabricación de submarinos), donde el producto final no cambia - ni puede cambiar, ni va a cambiar nunca - ni un ápice fuera del diseño aceptado, en ningun momento del ciclo de producción.

Por otra parte, Waterfall tuvo su auge en el siglo XX, en un momento en que "programar" una computadora significaba literalmente modificar su ensamblado físico. Luego de eso, "programar" pasó a ser trabajar con tarjetas perforadas, que más o menos implicaba una similar inamovilidad práctica. Es decir, era físicamente (sino económicamente), imposible desviarse del diseño aceptado (la 2da. etapa de Waterfall).

Al instante en que las computadoras pasaron a ser - realmente- programables vía software, Waterfall empezó a tener problemas, aunque más no fuera el que algun programador detectaba que un algoritmo codeado no iba a funcionar realmente > la idea de volver atrás y rehacer sistemáticamente todo de vuelta (tal como lo exige el modelo para que todo funcione bien), era impensable.

Avance rápido al presente, usar Waterfall hoy es casi sinónimo de tener problemas al desarrollar software, el grueso de los proyectos fallidos de desarrollo, comerciales, inhouse, son en general, el relato largo, tedioso y lamentable de cómo a X persona/grupo/cliente se le ocurrió modificar requerimientos ya aceptados y luego intentó - infructuosamente - "empujarlos" dentro del ciclo de desarrollo basado en Waterfall (contraviniendo impúdicamente la noción de volver a la etapa de diseño).

Ágile no tiene tanta historia, pero la casuística es a la inversa, un mínimo de proyectos planteados desde metodologías ágiles falla, pero en gral. funcionan muy bien. Los que fallan, suelen implicar severas infracciones a las nociones más básicas de las metodologías ágiles (no tener mecanismos de testing exhaustivo en pie por ejemplo, se lleva las palmas como causa de fallos, según entiendo).


Me pregunto, en un desarrollo del siglo XXI (hoy):

1) Waterfall, la metodología de desarrollo en Cascada, ¿sirve hoy en día?


2) ¿Es viable o realista hacer desarrollos usando Cascada?


3) Replanteo la 2),


a) ¿Se le puede pedir a un cliente interno/externo que no añada más requerimientos - ninguno - al software luego de terminado el relevamiento inicial?


b) ¿Está garantizado que no van a pedir o intentar "empujar", "insertar" nuevos requerimientos?


4) ¿Cuanto dinero y/o recursos puede costar el "empeñarse" en usar Cascada, cuando el cliente interno/externo insiste y no para de agregar requerimientos?


5) ¿Cuanto dinero y/o recursos se puede ahorrar al utilizar metodologías Agiles para desarrollos en los cuales el cliente interno/externo introduce constantemente modificaciones a los requerimientos?

Opiniones?


Links:
http://es.wikipedia.org/wiki/Desarrollo_en_cascada
http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software