Gestionar la complejidad con Scrum

En la tercera parte de esta serie sobre la complejidad del desarrollo de software, muestro por que gestionar la complejidad con Scrum. ¡Ya no puedes decir que usas Scrum porque es lo que hacen los demás!

Autores como Dave Snowden o Nils Pfläging son las voces que dicen que hay que aceptar la realidad y trabajar en métodos de gestión de la complejidad
A pesar de los esfuerzos de la industria para elaborar modelos que respondan a la necesidad de entender de manera sencilla el desarrollo de software, éste pertenece al dominio de lo complejo. En pocas palabras, esto significa que cuando desarrollamos software desconocemos más de lo que conocemos, y los modelos existentes parten de la premisa de que el pasado permite predecir el futuro.

Cuando desarrollamos software, generalmente nuestro conocimiento de la tecnología es limitado principalmente por dos motivos: Tener un conocimiento y dominio absoluto de las 50 o 100 tecnologías que se usan en un proyecto es muy difícil y en segundo lugar, éstas cambian tan constantemente que es virtualmente imposible seguir el ritmo de todas las innovaciones a la vez. Eso hace que el grado de duda sobre las herramientas sea muy alto. Por ello surge la necesidad de gestionar la complejidad con scrum.

Además, cuando desarrollamos proyectos de software lo normal es que los requerimientos no estén del todo claros, ya que estos emergen conforme avanzamos en el desarrollo del proyecto. Si a priori podemos pensar que necesitamos tal o cual característica en nuestro software, puede que descubramos tiempo después que la implementación de una solución a un problema concreto no cumple con las expectativas que esperábamos.

Scrum y los proyectos de desarrollo de software

Es habitual la frustración en los proyectos de desarrollo de software. Y cuanto más grandes, más ineficientes. Por eso Agile tiene cuatro veces más probabilidad de éxito que waterfall en grandes proyectos, evitando unas tasas de fracaso que en ocasiones superan el 75%. Esto es, de cada euro que invertimos en un proyecto, 75 céntimos son inútiles. El enfoque tradicional de gestión de proyectos de software, en el que se escriben inicialmente todos los requerimientos y se trabaja en fases para desarrollar un proyecto, resulta inútil cuando a mitad de un proyecto descubrimos que aquello que estamos desarrollando no soluciona nada. La toma de decisiones en entornos complejos es una herramienta fundamental para saber qué hacer en estos casos.

La industria ha intentado durante muchos años insistir en que el desarrollo de software es algo simple, y no podría estar más equivocada.
En este contexto surgen las metodologías ágiles de desarrollo de software. Su filosofía se basa en el manifiesto ágil, una declaración que invita a reflexionar sobre el cómo se acometen proyectos de software y a cambiar nuestro enfoque sobre la necesidad de herramientas de gestión adecuadas para estas situaciones. Unos años antes de esto, creado por Ken Schwaber y Jeff Sutherland, como herramienta que facilita gestionar la complejidad con scrum en entornos de desarrollo de software.

La premisa de Scrum es sencilla. Basándonos en ciclos cortos de desarrollo y retroalimentación, así cómo promoviendo la transparencia y las oportunidades de inspección y adaptación, podemos alejarnos de la frontera del caos y así gestionar proyectos complejos con métodos simples.