Como íbamos diciendo…

Una gallina le dice a un cerdo: Eh, ¿por qué no montamos un restaurante?

El cerdo le responde: Me parece bien, ¿qué nombre le ponemos?

A lo que la gallina contesta:  ¿Qué te parece “Huevos con jamón”?

Y el cerdo le replica: No me gusta. Tú sólo estarías involucrada mientras que yo estaría comprometido…

Este chiste, de tan mal gusto, viene a reflejar una distinción evidente dentro de aquellas personas relacionadas con el desarrollo del software. Imaginemos por ejemplo un usuario de la aplicación: ¿desempeña alguna labor dentro del desarrollo del software? No. Y sin embargo, debe tenerse en cuenta a la hora de realizar el software que se va a desarrollar para él. En definitiva: está involucrado pero no está comprometido.

En 1986, los profesores de Empresariales Hirotaka Takeuchi e Ikujiro Nonaka, propusieron un modelo de desarrollo de procesos que presentaba una alternativa al modelo de entonces. Haciendo una comparación con el mundo de los deportes:

• En el fútbol, el entrenador y los jugadores se reúnen antes de empezar la primera parte para poner en común la estrategia que van a seguir a lo largo del partido. Una vez empezado el partido, los jugadores no vuelven a reunirse para discutir sobre tácticas hasta el descanso, en donde pondrán en común la forma en la que van a abordar la segunda parte en su totalidad (exceptuando mensajes muy esporádicos enviados desde el banquillo por el entrenador ^^).  En resumen, decisiones estratégicas que afectan a periodos de tiempo amplios y largos intervalos temporales entre reuniones estratégicas.

• En el rugby, en cambio, los jugadores intentan avanzar yardas en sucesivos intentos (también llamados downs u oportunidades). Entre cada uno de estos intentos, los jugadores se reúnen formando una piña para poner en común la estrategia que van a seguir. En esa toma de decisiones, plantean la táctica únicamente para este down (¡ya decidiremos lo de más adelante cuando veamos los resultados de este intento!). En resumen: decisiones muy específicas para intervalos cortos y reuniónes frecuentes para tomar esas decisiones.

Precisamente en 1991, Peter DeGrace y Leslie Hulet Stahl, llamaron a este modelo de procesos Scrum, que es el nombre que tiene el pelotón de jugadores que se forma tras cada interrupción en un partido de rugby. El eje principal de esta metodología de procesos (y de muchas otras metodologías agile) está en realizar un desarrollo iterativo e incremental.

Iterativo, porque se segmenta el tiempo en sprints, o periodos fijos de tiempo (normalmente entre 1 y 4 semanas). En cada uno de estos periodos o iteraciones, se crea un producto de software que puede ser probado por el cliente. No importa que empiece siendo un producto con funcionalidad pobre, ya que queremos que sea…

Incremental, porque en cada sprint vamos incrementando la funcionalidad del producto.
Este modelo se contrapone al modelo clásico de desarrollo del software (ver Waterfall o diseño en cascada), donde existe un solo ciclo en el que se realiza una fase de análisis previo, una segunda fase de diseño y una fase final de implementación.

En palabras de Henrik Kniberg, el modelo clásico de desarrollo de software se asemeja a disparar a una diana utilizando el proyectil de un cañón. Gastaríamos bastante tiempo inicialmente en elaborar complejos cálculos para calcular la trayectoria y la inclinación a la que tenemos que colocar el cañón. Una vez realizada este análisis previo, encenderíamos la mecha y cruzaríamos los dedos.

¿Pero esto funcionaría en el mundo real? El problema es que el entorno del desarrollo de software no es perfecto. ¿Qué ocurre si sopla el viento durante la trayectoria del proyectil? ¿Y si el cañón tiene un defecto en el calibrado? ¿Qué ocurre si la diana se mueve de su posición original?

Muchos han intentado cambiar estas variables del mundo del software, pero se ha demostrado que es un entorno catastrófico cambiante y cuanto antes nos demos cuenta de eso, mejor. Sabemos que ahí fuera, en el mundo real, los servidores se caen, las conexiones se pierden, los programadores enferman y los campos electromagnéticos destrozan pulverizan nuestros discos duros.

Con esta metáfora, el modelo de Scrum se asemejaría más a un misil inteligente, el cual lanzaríamos sin hacer muchos cálculos, ya que el propio proyectil sabe cambiar su trayectoria mientras va volando en ruta. Ese es el camino de Scrum y del desarrollo ágil: el poder revisar el desarrollo de forma frecuente, continuada e incremental.

Para conseguir esta utopía necesidad, Scrum propone dos tipos de roles: roles cerdo (comprometidos con el proyecto) y roles gallina (involucrados con el proyecto):

Roles cerdo:

• Product Owner:  responsable de que el desarrollo iterativo del producto va cumpliendo las necesidades del cliente.
• Equipo de desarrollo: el equipo encargado de desarrollar el producto
• Scrum Master: encargado de que el proceso Scrum se realiza correctamente.

Roles gallina:

• Usuarios de la aplicación
• Clientes
• Managers

En el próximo capítulo hablaremos en profundidad de cada uno de estos roles y de su importancia en Scrum…