---

¿Tuviste que planificar todo el proyecto antes de comprenderlo? ¡Puede que te sorprenda!

Sin Scrum, nuestros equipos habían desarrollado y entregado productos de software y hardware completamente equivocados que no respondían a las necesidades del cliente.

En algunos momentos de nuestra vida profesional, empresas externas nos impusieron cómo debíamos desarrollar nuestros productos o servicios de software.

Modelo de madurez de capacidades (CMM), ISO 9001:2008 y otras variantes intentaban ayudar a nuestras empresas a garantizar que desarrolláramos el software adecuado de la manera adecuada.

Su grado de éxito queda fuera del alcance de este libro. El libro pretende centrarse en el proceso y las ventajas del marco Scrum, en lugar de criticar procedimientos prácticamente desaparecidos.

No obstante, debo añadir que estos marcos de mejora de procesos anteriores al marco Scrum de ingeniería de software recomendaban un enfoque por fases. Proponían lo que llamábamos el modelo de ingeniería de software en cascada.

Con el modelo en cascada, cada proyecto de software debía comenzar con el análisis de requisitos, en el que intentábamos comprender lo que el cliente necesitaba y deseaba.

Después diseñábamos esos requisitos, los implementábamos, los probábamos o verificábamos y los manteníamos en nuestros entornos de producción de software. Finalmente llegábamos al final del ciclo de vida de la ingeniería de software.

¡Sin embargo, la realidad era muy distinta!

La metodología en cascada frente al marco Scrum

Fases del modelo clásico de desarrollo de software en cascada

Los efectos negativos de los retrasos imprevistos en una fase del modelo de ingeniería de software en cascada afectaban inevitablemente a las fases posteriores.

Los estudios han mostrado que, en más del 80% de los proyectos de software fallidos analizados, el uso de la metodología en cascada fue uno de los factores cruciales del fracaso. ¿Pero por qué?

Como muestra el lado izquierdo, al utilizar la metodología en cascada existe una secuencia estricta de fases. Cada fase debe completarse antes de comenzar la siguiente. Volver atrás suele ser difícil, costoso, frustrante para el equipo y lento.

El calendario se planifica al inicio. Solo se entrega un producto listo para su lanzamiento al final del proyecto. Si una fase se retrasa, todas las demás también lo hacen.

Para evitarlo, los directores de proyectos en cascada intentan anticipar todas las posibilidades. En una de las primeras fases procuran definir los requisitos con el máximo detalle y exhaustividad. Sin embargo, definirlos al comienzo suele ser complicado y muchos cambian, o deberían cambiar, a lo largo del proyecto.

Los estudios han mostrado que, en proyectos más grandes y complejos, alrededor del 60% de los requisitos iniciales cambia durante el proyecto. Otros se implementan tal como se definieron, aunque algunos no son realmente necesarios para el cliente. Así consumen tiempo y dinero que podrían dedicarse a funcionalidades de mayor valor añadido.

La división en fases obliga a estimar cada una por separado. El problema es que muchas de ellas no son realmente independientes, sino que trabajan conjuntamente y en paralelo.

Por ejemplo, nadie puede suponer razonablemente que el desarrollo termina antes de comenzar las pruebas. Y, sin embargo, así funcionaba lamentablemente la metodología en cascada.

La metodología en cascada puede utilizarse para desarrollar proyectos de software pequeños y sencillos. Pero para proyectos más grandes y complejos, este enfoque resulta muy arriesgado, si no insensato. Suele ser más costoso y siempre menos eficiente que el marco Scrum de desarrollo y entrega de software.

Así era la vida antes del marco Scrum. Enviar el software de un equipo a otro, sin la orientación de profesionales con habilidades de Scrum, volvía nuestro trabajo burocrático, complejo e improductivo.

Al final no solo sufría el producto: la motivación de los empleados y su compromiso con la misión de la organización quedaban completamente dañados.