¿Deberías usar Scrum para todos tus proyectos?

Dependiendo del nivel de su complejidad se puede orientar el enfoque de desarrollo de nuestro producto bajo cascada o con metodologías ágiles como Scrum.

Un sistema tiene como objetivo entregar valor al entorno que le rodea. Para ello parte de una serie de inputs que convierte en valor entregando una serie de outputs. Si nos enfocamos en el entorno de proyectos TI, es el cliente el que recibe ese valor en forma de outputs. Por lo que se puede concluir que el propio cliente forma parte del entorno. 

Por ejemplo: imagina una máquina de café, se mete la cápsula, se le da al botón y se obtiene un café. Los inputs son la cápsula y el darle al botón, el output el café y lo bien que sabe cuando se toma. 

En el ámbito TI, los outputs son las funcionalidades que ofrece el sistema desarrollado y que cubren las necesidades como clientes del mismo. Por lo tanto, se asume que un sistema incluye todo aquello necesario para construir, operar y recibir los beneficios del propio sistema.

A menudo en el mundo del desarrollo de software se encuentran con la siguiente pregunta, más ahora con la moda del desarrollo ágil, ¿Scrum es siempre la mejor metodología para este proyecto? Como se ve en el diagrama de la parte superior del artículo, no siempre. Depende de la complejidad del sistema, y no hayq ue olvidar que hay muchas circunstancias que rodean al sistema y que afectan al mismo. No en vano llevamos muchos años desarrollando software prácticamente sólo en cascada y hemos tenido todos muchos y grandes éxitos.

Como fórmula de base podemos partir de la siguiente:

• Sistemas simples: incertidumbre respecto a "qué" construir y "cómo" construirlo muy baja. Para este tipo de sistemas la gestión clásica en cascada es ideal para optimizar la construcción de la solución de forma completa.
• Sistemas complicados: en estos sistemas la incertidumbre de "qué" y/o "cómo" construir tiene peso, pero es manejable. Scrum podría emplearse, pero no sería la forma más eficiente de construir, una gestión de proyectos clásica en casada sería una excelente forma de trabajo ya que la solución puede identificarse completa al principio.
• Sistemas complejos: es cuando la incertidumbre del "qué" y/o del "cómo" construir es alta, cuando somos capaces de entender las consecuencias de nuestras decisiones, pero no las interacciones entre estas consecuencias. Los resultados se vuelven impredecibles y no podemos identificar una solución al principio, solo podemos examinar los resultados y adaptarnos. En este tipo de sistemas, en los que se requieren niveles altos de creatividad, innovación, interacción y comunicación, Scrum, con sus ciclos de inspección y adaptación, es un marco de construcción ideal.
• Sistemas caóticos: más allá de los rezos y las plegarias, un enfoque con Scrum de ciclos muy cortos ( 1 semana ) y una buena gestión de las colas de WIP ( Work in Progress ) podrían ayudar a salir del entuerto.

En definitiva, la respuesta a si se debe usar esta nueva metodología ágil en todos los proyectos a partir de ahora, es tajantemente no. Por mucho que nos sintamos cómodos con estas metodologías, las metodologías tradicionales aportan mucho en ciertos ámbitos y tipologías de proyecto. No hay que dar la espalda y ser racional a la hora de escoger qué metodología usar para nuestro próximo proyecto.