miércoles, 21 de marzo de 2012

Desarrollo en Cascada (II)

En la primera parte de este post, hablábamos de metodologías en cascada, las definíamos, y veíamos que tenían una cierta razón de ser, al menos en un contexto y situación concretos. Vimos también que se produjo un cambio, y que por una serie de motivos, esta metodología cayó en desgracia. Vamos a recuperar las ventajas e inconvenientes del modelo en cascada para entenderla mejor, y por tanto, llegar a entender el origen del resto de metodologías:

Ventajas del ciclo de vida en Cascada

Aunque muchos no estarán de acuerdo, este proceso tiene sus ventajas y tal y como vamos a ver, es de cajón. Para más información, consultar aquí (INTECO, Marzo 2009 "Metodologías y Ciclos de Vida"). ¿Qué ocurre, que ahora va a resultar que queremos recuperar la metodología de desarrollo en cascada? No, en absoluto. Simplemente recordar, razonar y demostrar, que a pesar de las críticas radicales y muchas veces infundadas, existen motivos para que todavía se use hoy en día. Otra cosa bien diferente, es que los proyectos en que se esté usando, por desgracia, no tengan las características adecuadas a esta metodología.
  • El modelo en cascada puede ser apropiado, en general, para proyectos estables (especialmente los proyectos con requisitos no cambiantes) y donde es posible y probable que los diseñadores predigan totalmente áreas de problema del sistema y produzcan un diseño correcto antes de que empiece la implementación.
  • Funciona bien para proyectos pequeños donde los requisitos están bien entendidos.
  • Es un modelo en el que todo está bien organizado y no se mezclan las fases. Es simple y fácil de usar.
  • Debido a la rigidez del modelo es fácil de gestionar ya que cada fase tiene entregables

Inconvenientes del ciclo de vida en Cascada

  • En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso. Observación: el que no se siga una secuencia lineal, no es culpa del modelo, sino del responsable de adoptarlo. Existen variantes del modelo (hablaremos de ellas otro día), mejor adaptadas a según qué tipos de proyectos, así como otros modelos iterativos o ágiles que pueden ser utilizados de forma separada o combinada.
  • Un cliente, no suele establecer al principio todos los requisitos necesarios. Esto provoca que el modelo no se ajuste al gran número de nuevos requisitos y cambios en otros requisitos existentes, que se van a producir. Sí, vale, pero hay que matizar que la culpa no es del cliente. Un buen analista debe llegar a conocer el negocio del cliente, y debe extraer sus necesidades. Si nos tenemos que basar en lo que nos cuenta el cliente de forma exclusiva, estamos listos (y además, estamos pagando innecesariamente un analista).
  • Los resultados y/o mejoras no son visibles progresivamente, el producto se ve cuando ya está finalizado, lo cual provoca una gran inseguridad por parte del cliente que quiere ir viendo los avances en el producto. Esto pasa en todas las metodologías y ciclos de vida. Para eso existen prototipos, maquetas, y la documentación que se crea en las fases previas a la construcción. Además, existe la irracional creencia de que se está trabajando para el cliente final, cuando en realidad, también hay que tener en cuenta que el cliente de cada fase es el responsable de la fase posterior. Por ejemplo, es posible que el diseño técnico lo cree una empresa externa, y el desarrollo lo haga una tercera, las pruebas una cuarta, etc, etc.
  • Existen requisitos que no se hayan tomado en cuenta desde el principio. Correcto. Siendo puristas, el ciclo de vida en cascada es imposible de llevar a la práctica. Pero para eso existen los procesos de gestión del cambio. Y no nos engañemos, TODOS los proyectos tienen cambios durante su ejecución. Y por mucho que hagamos prototipos, por mucho que usemos metodologías ágiles, por mucho que iteremos....ES IMPOSIBLE evitar que tras 20 iteraciones, 1 año de trabajo, de repente aparezcan N requisitos nuevos o cambios en los existentes. ¿Y qué queremos decir con esto? Sencillamente que la solución NO ES cambiar de metodología. LA SOLUCION ES aplicar la metodología que mejor se adapte a la situación del proyecto, realizar una toma de requisitos adecuada y adaptada, y definir y seguir un buen proceso de gestión de cambios.
  • Muchas veces se considera un modelo pobre para proyectos complejos, largos, y por supuesto en aquellos en los que los requisitos tengan un riesgo de moderado a alto de cambiar. Genera altas cantidades de riesgos e incertidumbres. Efectivamente, aunque no es porque el modelo sea erróneo. Simplemente, si en un proyecto de 4 años, dedicamos 1 año a la toma de requisitos y análisis, es muy probable que tras ese año (si como se indica, hay muchos cambios), el resultado no se corresponda con la nueva realidad. Pero no nos engañemos, si no se tiene involucración del cliente, un modelo supuestamente adecuado, como sería el desarrollo ágil (SCRUM, XP,LEAN...), nos llevaría aquí también al desastre. Sin el feedback del cliente, cada sprint estaría construyendo una solución totalmente errónea, y todo el tiempo invertido en cada sprint estaría echado abajo cada poco tiempo.
¿Por qué empezó a fallar la metodología en cascada?

Esto casi lo vamos a dejar para un tercer post. Y no porque el modelo en cascada lo requiera. En sí, no lo merece: es obsoleto, ineficaz, innecesariamente simple... Sin embargo, si no entendemos lo ocurrido con este modelo, no vamos a entender qué modelos aplicar en nuestros desarrollos y qué riesgos existen en caso de adoptar uno u otro. Esto me recuerda esa frase típica de película:
"Para forjar nuestro futuro, no podemos ignorar nuestro pasado"

No hay comentarios:

Publicar un comentario