Siguiendo con el modelo cascada 'waterfall'

Un proyecto (según por ejemplo el PMBOK) es esfuerzo temporal destinado a crear un único producto, servicio o resultado.Teniendo como premisa partir de un alcance, un tiempo, un presupuesto previamente establecidos.  

La gestión del proyecto engloba los perfiles, teorías y técnicas relativas a organizar el trabajo del equipo con el objetivo de cumplir con los objetivos esperados del proyecto.

Siguiendo el punto de vista tradicional, el modelo de cascada o waterfall, definido por Royce en 1970 y adoptado como estándar por la indústria durante muchos años,se define una relación de fases o tareas secuenciales que dan lugar al product final. Esta relación de actividades puede variar en función del producto, e "idealmente" cada fase es completada previamente al inicio de la siguiente.

Como evolución de esta visión inicial, existe el modelo iterativo/incremental, que plantea la ejecución de múltiples proyectos siguiendo el proyecto cascada y que vayan mejorando e incrementando la relación de funcionalidades de la versión anterior. Con el objetivo de liberar versiones completamente funcionales.

La realidad es que, aunque este modelo funciona satisfactoriamente en el mundo de la Ingeniería tradicional, dentro del ámbito del desarrollo software presenta dificultades y no podemos concluir que su aplicación sea exitosa.

Si tenemos en cuentra algunas métricas de referencia, tan solo el 16% de los proyectos software finalizan en plazo y en coste previsto, datos absolutamente alejados de la realidad en la ingeniería tradicional.

Los principales factores que motivan esta situación son:

• Falta de input de los usuarios o stakeholders (promotores)
• Requisitos o especificaciones incompletas 
• Cambios de requisitos o especificaciones fuera de las fases previstas para dicha función

El desarrollo software es un negocio con un elevado grado de incertidumbre que genera un constante flujo de cambios. Y además, los productos software son únicos, con mínimos ejemplos análogos a partir de dónde obtener referencias que ayuden a estimar el progreso. Sin olvidar que hablamos de un contexto con herramientas, lenguajes que están en continuo cambio y evolución.

Dando un punto y aparte, la propuesta del modelo en cascada, nos lleva a obtener una versión visible , o usable, del producto en las últimas fases del desarrollo, impidiendo una validación por parte de los usuarios (Uno de los factores de fracaso anteriormente enumerados)

Durante las primeras fases del modelo en cascada, se genera documentación, tanto interna para el equipo, como externa para el cliente, respondiendo a las fases de Especificación y Diseño del producto (propio de la Ingeniería del Software / i.e. UML) La realidad, lamentablemente, es que por más procedural que sea la documentación, son de difícil comprensión, poco representativas del producto final en comparación a lo que puede suponer un prototipo. Dificultando nuevamente la recogida de feed-back por parte del usuario o principales stakeholders del proyecto.

Este feedback suele llegar en fases muy avanzadas del proyecto, cuando la afectación sobre el alcance, el calendario y el presupuesto es inevitable. Podriamos llegar a concluir que este elevado riesgo no está cubierto por el modelo.

Recibir esa relación de cambios en esas fases del proyecto, incurre en procesos de "gestión del cambio" acordada con el cliente analizando la variación con respecto a la linea base original del proyecto. Estos procesos no suelen ser beneficiosos ... negativa percepción por parte del cliente, necesidad de redacción de nuevos contratos, negociación de los mismos ... en resumen, pese a proteger al proveedor de software, implican cierto parálisis. 

Cómo digo es realmente una protección para los proveedores software, y es por ello que se dedican no pocos esfuerzos a su gestión ... aunque la realidad es que el control de cambios, utilizando por ejemplo matrices de trazabilidad o conceptos similares, además de susamente engorroso, no dan más que una falsa sensación de control.

Lo realmente importante sería dar relevancia, la relevancia que se merece, a la inevitable incertidumbre con la que vivimos. Quizá sea esa la mayor de las debilidades del model tradicional. Ignorando no solo la incertidumbre, si no la inexistencia de cambios derivados de la "evolución" de la visión, necesidades y opiniones del cliente.

Otro punto importante, y de elevado riesgo, del modelo tradicional, es la elevada cantidad de documentación exigida, tal y como hemos comentado con anterioridad. No solo la cantidad, si no la sobrevaloración de la misma. Esta documentación no tiene sólo como objetivo ayudar a garantizar la comprensión de alcance del cliente (que tal y como hemos analizado anteriormente parece no ser la mejor vía), si no también atacar a riesgos críticos del ciclo de vida del desarrollo software cómo son la rotación de recursos o la capacidad de minimizar la curva de aprendizaje de nuevos recursos.

Pero, ¿realmente es así? Realmente ese volumen de documentación exigida,compensa los beneficios por la supuesta reducción de la curva de aprendizaje... es, si más no discutible.

Me declaro un absoluto defensor de alguna de esa documentación, durante muchos años he luchado en compañías para que implanten herramientas de comunicación interna y apoyen la evangelización del equipo en la utilización de productos como wiki, confluence o similares ... 

Aunque, perder a un recurso clave del proyecto y, creer que la documentación será suficiente cómo para que un suceso de ese alcance no te haga temblar... sería engañarnos.

En resumen, podemos concluir que el modelo tradicional ofrece multitud de problemas y que modelos como el Agile Development o el User-Center Design intentan minimizar.

Veamos en los siguientes artículos, ¿realmente lo consiguen?

Saludos,