Desarrollo en cascada (I)

Tenía yo este post ya desde hace tiempo atascado. Quería hablar del desarrollo en cascada desde el punto de vista de la experiencia, y compararlo con las metodologías más actuales.. Y por fin me pongo a ello. Ya había hablado de las ventajas y desventajas de las metodologías ágiles como SCRUM o XP, y me parecía injusto no ser ecuánime con el waterfall.

Este post no le va a gustar a mucha gente. Está de moda el agilismo. Admitámoslo. Así que cualquier comentario que no defienda ciegamente SCRUM y no ataque despiadadamente a CMMi, metodologías tradicionales, desarrollo en cascada...causa desasosiego en las mentes que sólo ven blanco y negro. Pero el mundo no es blanco ni negro.

En un artículo que he leído hacer poco, leo algo que yo ya hace años que vengo observando. Aproximadamente cada década surge una nueva "guerra de metodologías":

• En los 70 desarrollo estructurado vs tradicional
• En los 80 desarrollo dirigido por datos vs desarrollo tradicional
• En los 90 desarrollo orientado a objetos vs tradicional
• En los 2000 el desarrollo ágil vs tradicional (algunos prefieren enfrentarlo a CMMi)

Pero claro, para los programadores más jóvenes, que no han desarrollado en los 80 ni en los 90, para ellos sólo existe algo "anterior". Ellos no han vivido las otras metodologías ni formas de trabajar. Algunos lo han estudiado en la universidad y se atreven a hablar de ello, pero no han sido conscientes, porque no lo han usado en su día a día (hablo de técnicas y metodologías de las llamadas "tradicionales").

En un post anterior, ya hablamos de las desventajas de SCRUM y de las metodologías ágiles en general. ¿Que qué estoy diciendo? Pues que efectivamente, existen puntos débiles en estas técnicas, por el mero hecho de que se basan en suponer ciertas características y restricciones, lo cual supone a su vez un riesgo y debilidad para nuestro proyecto.

Y ahora ¿qué? ¿A defender la obsoleta y moribunda técnica de desarrollo en cascada? Pues ni obsoleta ni moribunda, pero no hay porqué defenderla, sino entenderla en su contexto. En el desarrollo de software, echo de menos dejar de usar este tipo de abjetivos subjetivos por otros más profesionales como "apropiada para esto" o "inadecuada para lo otro". Y no me refiero al "depende" que muchos listillos de turno utilizan para intentar quedar bien, aunque no tengan ni puñetera idea de lo que hablan.

¿En qué consiste la metodología en cascada?
Esta metodología propugna que cada fase del ciclo de vida (SDLC del inglés Software Development Life Cycle), no debe comenzar hasta que esté totalmente terminada la fase anterior. Por ejemplo, no empezaríamos a programar, hasta tener la fase anterior de diseño técnico completada. ¿Y cuándo estaría completada? Pues cuando esté completado el entregable final, en este caso, el documento de "Diseño Técnico".

¿Qué presupone la metodología en cascada?
Este tipo de desarrollo presupone que en cada fase debemos estar preparados para la fase siguiente, porque:

• El cliente quiere ver una documentación estable (tal vez no sea el cliente, sino una PMO que quiere coordinar varios proyectos que se producen a la vez).
• Otros proveedores quieren también ver una documentación estable, porque han de interactuar con nuestro desarrollo, bien consumiendo servicios, o siendo proveedores de servicios que consumimos nosotros, y por tanto, han de conocer nuestras necesidades (por escrito, claro, porque las palabras se las lleva el viento).
• Tenemos equipos bien diferenciados: los analistas funcionales son expertos en ese tema, tienen un coste alto, y por tanto, han de "usarse" al máximo en las fases donde su labor tiene máxima necesidad: en la toma de requisitos y análisis. Posteriormente, pasaremos a utilizar otro tipo de perfiles diferenciados, los analistas técnicos o diseñadores técnicos, especializados en aterrizar los análisis funcionales en un documento técnico. Finalmente, los programadores, especializados en seguir un documento técnico bien preparado, construyen el código....y así hasta el final.
• La metodología en cascada presupone también que los cambios son costosos, por lo que hay que definir al máximo la solución al principio. Un cambio se comporta como un bug: aleja a la solución final del objetivo deseado. Es por ello, que cuanto antes se identifiquen, mejor.

¿Cuál fue el origen de la metodología en cascada? La causa
Todo lo dicho en el apartado anterior, hizo que en los años 90 sobre todo, la forma de trabajo de las factorías de software y las consultoras, provocara que la especialización por un lado, y el hecho de contar con personal poco experimentado por otro, esta técnica fuera necesaria y efectiva. Ojo cuando digo efectiva, porque aquí de nuevo se tirarán de los pelos los que solo ven agilismo: los proyectos de software siempre han fallado. Lo que digo no es que esta técnica fuera perfecta, sino que para las condiciones existentes, era muy adecuada. El "poder", la iniciativa, no estaba en los programadores. Los programadores iban y venían en los equipos. Era normal tener equipos de 10 personas al inicio del proyecto, y que muy pocos de ellos llegaran a ver el final del proyecto. La rotación era muy alta.

Y hasta aquí la primera parte. Vemos el origen. Pero ¿qué falló? ¿Porqué la metodología waterfall nos llevó a hacer proyectos con retrasos y poca calidad? Eso lo veremos en el siguiente post.