Enfoques de entregas tradicionales basados en modelos cascada tienen sus orígenes en la década de los años setenta. También conocidos como modelo secuencial de procesos. Donde, el inicio de una etapa del proyecto depende exclusivamente del cierre de la etapa anterior.

Este tipo de metodología funciona muy bien en ámbitos rígidos y estables. De hecho su origen yace en ingenierías como la civil y mecánica. En estos entornos los cambios suelen ser traumáticos, por el alto costo que implica asumirlos.

Por esta razón, las metodologías tradicionales de gestión de proyectos se han especializado en la prevención y mitigación de riesgos que impacten el alcance y planeación. A esto se debe que se les referencie bajo el término de modelos predictivos.

Dado que en este contexto los cambios se hacen prácticamente imposibles de ejecutar. Se requiere de mayor esfuerzo y calidad en las etapas tempranas del proyecto. Un mal levantamiento de información o de los requisitos del cliente, puede implicar la construcción de un producto totalmente diferente al esperado.

En 1970 Winston W. Royce, publicó un paper haciendo crítica sobre la forma como se desarrollaban programas de computadora. Argumentando que no era suficiente construir en fases una tras otra asumiendo que la etapa anterior finaliza correctamente sin errores.

Además, en cada nueva fase había aprendizaje sobre cosas que no se habían tenido en cuenta. Este feedback se debía considerar como un input de las etapas anteriores, ocasionando replanteamientos en el diseño e incluso los requerimientos, y como consecuencia obteniendo un ciclo infinito.

Este paper fue malinterpretado por la industria. Royce nunca defendió, ni se refirió a esto como un método eficaz, el proponía trabajar de una forma diferente, mediante un esquema incremental. Esta forma de construir productos se adoptó en la ingeniería de software, desarrollando por fases secuenciales, sin ningún tipo de feedback entre cada una de estas, para evitar el problema del ciclo infinito.

Royce representó el modelo de fases secuenciales con los siguiente 7 pasos:

  • Requerimientos de sistema
  • Requerimientos de software
  • Análisis
  • Diseño del programa
  • Programación
  • Pruebas, y
  • Operación

Este modelo posteriormente fue denominado por Barry Boehm como modelo en Cascada o Waterfall.

En 1994 The Standish Group publica The CHAOS Report. Un informe con el resultado del estudio realizado a diferentes proyectos de software. Donde solo el 16% de los proyectos analizados se consideraban exitosos.

Las principales causas de que el 84% de proyectos restantes fueran cancelados o desafiantes, eran requerimientos cambiantes y falta de involucramiento de los usuarios del sistema.

Esto impulsa una nueva forma de trabajo en la industria, con ciclos de entregas más cortos y participación activa de los clientes. Los primeros pasos se originan con un paper en 1986 de Nonaka y Takeuchi: The New New Product Development Game.

En este paper, Nonaka y Takeuchi cuentan su experiencia construyendo productos innovadores. Basado en esto, en 1990 Jeff Sutherland y Ken Schwaber crean un marco de trabajo que nombraron Scrum y divulgaron en 1995.

Paralelo a esto, se desarrollaron nuevas metodologías, marcos de trabajo y prácticas ágiles. Entre las principales tenemos XP, FDD, Crystal. En el año 2001 todas estas propuestas coincidieron en lo que se conocería como el Agile Manifesto.

Hasta esa fecha a estas metodologías se le conocían como Blandas, Livianas o Ligeras, en contrapartida a las metodologías “pesadas” como cascada y otros modelos predictivos. Solo hasta el 2001 recibirían el nombre de metodologías ágiles, y el Agile Manifesto se consolidó como la piedra angular de este movimiento.

Algunas de las principales características que diferencian las metodologías ágiles de las predictivas son:

The CHAOS Report desde 1994 publica anualmente sus estudios sobre la visión general del estado de más de 50.000 proyectos de diferentes características. Para el 2015 se presentó un comparativo sobre el resultado de proyectos que se trabajaron bajo prácticas ágiles vs cascada.

En el desarrollo de software existe una tendencia creciente a la adopción de prácticas ágiles. Es evidente que por la naturaleza volátil de los requisitos y la velocidad en que evolucionan los mercados asociados a la tecnología, se requiere de tiempos de reacción más cortosEn este contexto, las metodologías ágiles resultan ser más efectivas.

Esto no quiere decir que proyectos que trabajen modelos predictivos o en cascada sean peores o estén condenados al fracaso. Estos tienen muy buenos resultados en contextos más estables y predecibles, donde la necesidad de cambio no es muy frecuente.

REFERENCIAS

ÚLTIMAS PUBLICACIONES EN EL BLOG


  • Mejora la productividad de tu equipo con la gestión del Work in Progress (WIP)

    Mejora la productividad de tu equipo con la gestión del Work in Progress (WIP)

  • Los equipos ágiles requieren profesionales conscientes ¿lo eres?

    Los equipos ágiles requieren profesionales conscientes ¿lo eres?

  • Guía para realizar retrospectivas ágiles efectivas

    Guía para realizar retrospectivas ágiles efectivas