En un principio se crearon los programadores y los proyectos, pero no había nada más que tinieblas y el espíritu del cliente cabreado planeaba por los departamentos.
Así que un buen día, dos tipos llamados Takeuchi y Nonaka dijeron: ¡Hágase el Scrum!
Y vieron los jefes de proyecto que era bueno, y volaron sombreros en algarabía.
Casi sin saberlo, se había inventado lo que iba a ser una de las implementaciones Agile más populares del planeta.
¿Qué aportó Scrum que lo diferenció del resto de formas de gestionar proyectos? En mi opinión dos aspectos básicos: transparencia con los clientes y ciclos de release periódicos y definidos.
En los otros sistemas de gestión que usé anteriormente (if any!) los proyectos se cargaban de una pesada losa de documentación que se llevaba casi la mitad de los costes disponibles y que el cliente debía firmar entre un mar inmenso de dudas (y de papeles).
Esta es la semilla de las frustraciones y lo que ha marginado a los proyectos de software hacia una de las experiencias más insatisfactorias que pueda sufrir el ser humano, junto a la de participar en juegos de azar y ponerse a dieta.
Tocar el producto desde el principio
Ver el producto mientras crece
(Foto: http://thegardenpalette.wordpress.com)
Este aspecto es el más valorado por el cliente, quien es ni más ni menos que el que nos paga.
La sensación de estar metido desde la “mórula”, la génesis de su proyecto, les hace ser más comprensivos con los posibles imprevistos que puedan ir surgiendo, amén de proporcionarles una infinita tranquilidad sobre su inversión.
Yo lo comparo con comprar por internet: pagas por algo que no has tocado, ni olido ni visto. ¿Quién no mira el tracking code para ver dónde está el paquete? Puede que esté parado en Berlín y lleve tres días, pero sabes que está ahí.
Con Scrum el futuro propietario del producto, el padre adoptivo, también sabe dónde está, y además también sabe cómo se va construyendo. Esto que parece nimio es nuestra revolución. ¡Estamos iniciando a un muggle a los rudimentos de la magia! Esta persona aprenderá que los programas no son “dar un botón y listo”, que tienen tanto de artesano como ese Murillo que tanto admira y que sabe que es único.
Será comprensivo (salvo Saurons) cuando le digamos que ese BotónVerdeQueSaltaYVuela que le prometimos es totalmente imposible, pero que intentaremos hacerlo de una manera parecida.
Lo que hay que hacer bien clarito
La gran herramienta de Scrum es el Product Backlog, que no es ni más ni menos que la lista de funcionalidades que debe realizar el software que vamos a empezar a hacer, perfectamente ordenada y documentada incluso a nivel de procesos.
Es la Herramienta, así con mayúsculas, y todo el mundo podrá verla y tocarla desde el principio.
Lo ideal es montarla como una Wiki, y que vaya evolucionando como el germen de la documentación del proyecto, ayudándolos de los resultados de los sprints y las actas de reunión.
Mantener al equipo centrado
Es común que haya interferencias externas (teléfono, propuestas de cambio, etc) que desconecten a los programadores de su tarea. Tarea dicho sea de paso que está mal reconocida y valorada. Programar es algo muy complejo y necesita una altísima carga de concentración y de eficiencia mental. Cualquier distracción hará que el desarrollador tenga que perder dicho estado de foco en la tarea y, después de 10 minutos al teléfono, tenga dificultades para saber qué estaba haciendo justo antes.
Concentrarse en las tareas evita errores
y facilita los objetivos (Foto: http://www.pce.uw.edu)
El Scrum Master es nuestro “papi”, que lo arregla todo todo, y que evita que tengamos que sufrir dichas distracciones y cuyo trabajo nunca es fácil, teniendo que manejar las situaciones con la maestría que les caracteriza.
Este rol es fundamental y, bajo mi punto de vista, es el más importante de todos. Era un rol que hacíamos los programadores habitualmente cuando llamaba el cliente para quejarse por algo o para preguntar qué tal iba el módulo ChachiOptimizador que le estábamos haciendo.
Objetivos cercanos y factibles
Los Sprints son eso: objetivos a realizar en un corto periodo de tiempo que incrementarán la funcionalidad del software.
Para los programadores este aspecto es magnífico porque nos permite saber qué tenemos que hacer (ojo a ese plural) para cumplir la planificación prevista.
Las tareas son concretas, divisibles por módulos y asignables libremente (en principio), y usando un Pomodoro todo parece más fácil, y lo mejor de todo es que ¡es trabajo en equipo!
Scrum Board de tareas domésticas (Foto:http://scrum4kids.blogspot.com)
Cualquier cambio o nueva característica habrá de respetar el Sprint. Nada de imprevistos durante ese tiempo cerrado e intocable, ya se planificará en la siguiente iteración.
Ah, y ojo con valorar dichas novedades en tiempo y dificultad sin contar con los que las tienen que hacer: en Scrum eso es ilegal.
Y nada de sofisticados sistemas: una pizarra, papeles y un reloj de cocina es lo único que vamos a necesitar. Con esto no habrá proyecto que se nos resista.
Esta es la revolución Scrum, y ha venido para quedarse, al menos en mi equipo.
Ha llegado la cordura a la gestión de proyectos.
Foto portada | www.martinalaimo.com