El origen de Scrum
Scrum está basado en un estudio realizado durante los años 80 por investigadores de la universidad de Harvard tras analizar cómo desarrollaban los productos equipos de alto rendimiento en empresas como Canon, Honda o HP entre otras.
En este estudio compararon la nueva forma de trabajo en equipo con el avance de formación de los jugadores de Rugby, donde la línea de ataque se pasa el balón de unos a otros hace hacer un “touchdown”, de ahí deriva el nombre de Scrum que significa melé (jugada de rugby).
En el año 95 Ken Schwaber y Jeff Sutherland presentaron Scrum en una conferencia internacional sobre software en EEUU, como un marco de reglas para el desarrollo de software basado en el estudio de Harvard. Marco que habían utilizado ellos para entre otros casos, desarrollar el lenguaje de programación Delphi (muchos de vosotros quizás conozcáis).
Como veis no se trata de una moda pasajera, su origen es anterior incluso al manifiesto agile de 2001 y a diferencia de una creencia popular, Scrum no es una metodología, es un framework simple que agrupa buenas prácticas que ayudan a resolver problemas complejos y a su vez hacer equipos más eficientes.
Roles de Scrum
En Scrum hay 3 roles principales que definen distintas responsabilidades de quienes participan en el proyecto:
- Product Owner (PO): Dueño del producto, es la principal voz del cliente y el responsable del éxito del producto.
- Scrum Master(SM): Responsable del proceso, de que todos conozcan y apliquen Scrum de la manera más eficiente posible. Remueve impedimentos y ayuda al equipo para que logre su mayor rendimiento.
- Development Team (Equipo): Equipo de desarrollo auto-organizado y multidisciplinar, se responsabiliza de la calidad de aquello que estamos construyendo.
¿Cómo construimos un producto con Scrum?
Lo primero de todo, repartimos en partes el producto detallado por niveles en un artefacto conocido como Product Backlog (PBL). Es una lista de deseos de lo que queremos que tenga el producto priorizada por el PO.
¿Cómo comienza el equipo a construir el producto?
Existe una reunión de planificación dónde el PO detalla al Equipo la estrategia a seguir. Le dice al equipo: Señores en este tiempo quiero construir esto, esto y esto otro, porque es el valor del producto que más me importa.
El equipo lo escucha , le hacen preguntas y cuando han llegado a entender qué quiere el PO, razonan entre sí mediante un pequeño debate técnico para a grandes rasgos, aclarar como implementarlo, con el objetivo de aclarar no el detalle, sino el tamaño y así poder estimar el esfuerzo que les llevará.
Como es un proceso donde se genera debate y puede ser a ratos complicado de entenderse, el SM hace de moderador, vela por el tiempo y les ayuda a ponerse de acuerdo.
De esta reunión sale un acuerdo detallado en un artefacto conocido como Sprint Backlog que va a servir como guía y recordatorio durante todo el Sprint. El Sprint es un slot de tiempo corto donde el Equipo trabajará hasta el último día que es cuando tendrá un producto potencialmente entregable.
¿Cómo se verifica si el equipo habrá hecho un buen trabajo o no acorde a lo establecido?
Hay un momento especial que se llama Sprint Review donde los mismos personajes que estaban en la planificación del Sprint y prometieron unas cosas, explicitaron una intención, vuelven a reunirse para comprobar.
El equipo dice: Sr. PO esto es lo que hemos entendido que había que hacer y el PO dice: esto bien, esto no, esto otro si y además lo podemos desplegar. Y el ciclo se repite.
Fuente: Libro, Métodos ágiles y Scrum
Ahora bien durante el Sprint, aunque es corto, ocurren cosas por el camino. Diariamente el equipo de reúne para sincronizarse y chequear si el camino seguido es el adecuado. Entre los miembros del equipo se cuentan: ayer hice esto, hoy haré esto otro. ¿Por qué se cuentan estas cosas? Para buscar complicidad, sinergias de trabajo y si hay impedimentos trasladarlos al SM para que los resuelva.
A su vez el PO prepara el terreno del Product Backlog para los siguientes Sprints. Aunque el foco del Equipo durante el Sprint está en construir el producto, el PO junto con la ayuda del Equipo se toman un tiempo de refinamiento del Product Backlog para poner el ojo hacia adelante y así poder para preparar la planificación de los siguientes Sprints.
Después de cada ciclo, el Equipo se para por un tiempo para reflexionar sobre el proceso de construcción junto con la ayuda del SM con la intención de encontrar puntos de mejora.
Y esto es Scrum, una manera ágil de trabajar!
