Continuemos con nuestra serie sobre SCRUM… tratando el tema de los sprints.

Para ponernos en situación, diremos que el sprint de SCRUM es más o menos lo mismo que la iteración en XP, aunque salvando ciertas distancias.

Podemos definir al sprint como el periodo de tiempo que tiene el equipo de desarrollo para implementar, documentar y probar un conjunto de nuevas funcionalidades (a este conjunto se le suele llamar “incremento”). Al finalizar el sprint, debemos tener una versión lista, empaquetada y con un bonito lazo rojo para entregar a cualquier cliente.

El sprint se divide en tres fases más o menos típicas:

1. - Planificación: una reunión del product owner junto con el equipo de desarrollo para:

• Marcar la duración el sprint: no debería durar nunca más de un mes, con la finalidad de no alargar lo que nunca no se debe ir retrasando: las entregas periódicas. En nuestro caso intentamos hacer sprints de 1-2 semanas, aunque con “trampa”, porque no estamos sacando versiones entregables, sino versiones internas (les falta documentación, pruebas más exhaustivas, etc.). Nuestra asignatura pendiente es hacer sprints “de verdad” de unas 3-4 semanas (quizá con algún cierre intermedio a modo de checkpoint). Tranquilo Juan, estamos en ello (:

• Elegir la funcionalidad a implementar: el product owner irá extrayendo distintas historias de usuario del producto backlog y proponiéndolas al equipo de desarrollo. En ese momento, el equipo puede detectar posibles dependencias entre funcionalidades. En cualquier caso, el equipo de desarrollo estimará en horas de trabajo las funcionalidades a implementar. Por ejemplo:
  
  - Product owner (PO): Bueno, creo que durante este sprint deberíamos tener listo el sistema de deshacer/rehacer para el editor de niveles
  - Equipo de desarrollo (ED): Veamos… la funcionalidad de deshacer/rehacer no es difícil, podemos aplicar una combinación del patrón Command y Memento y lo tendríamos más o menos resuelto. Creo que lo podemos dividir en las tareas: a) Crear clases Command para las distintas acciones del editor de niveles, b) crear la clase Memento para el nivel y c) dar un interfaz gráfico al usuario. Podemos estimarlo en 8, 5 y 6 horas respectivamente.
  - PO: De acuerdo, así que ya tenemos asignadas 19 horas del sprint… por otro lado me gustaría utilizar aceleración gráfica en los renderizadores de niveles... hemos detectado que en cuanto hay muchos objetos en la pantalla va lento.
  - ED: Uy uy... para el carro Manolo… eso ya lo intentamos para los renderizadores isométricos y nos dimos cuenta que antes hay que desacoplar el código … si no, el cambio es tan grande que no hay por donde cogerlo.
  - PO: Ah, vale, no tenía ni idea... o sea, que tenemos que refactorizar el código antes de implementar la aceleración?
  - ED: Sí, hay que crear nuevas clases y probar que los motores funcionen correctamente.
  - PO: Vale, ¿de cuanto estamos hablando?
  - ED: Pues por un lado hay que refactorizar 3 ó 4 clases y hacer las pruebas unitarias, así que un par de días. Y por el otro lado, hay que investigar el tema de la clase VolatileImage y aplicarlo a las clases de renderización, así que ponle otros dos días más.
  - PO: Vale, entonces tenemos 32 horas más, o sea: que tenemos 52 asignadas.
  - ED: OK, ¿algo más?
  - PO: Me temo que la parte de los renderizadores nos va a costar mucho tiempo probarla en todos los teléfonos móviles, así que dejamos 2 días para pruebas y otro más para actualizar la documentación de usuario, así que ya vamos justos de tiempo.
  - ED: Vale, pues se queda así.
  
  Todas las tareas que surjan para hacer durante el sprint se apuntan en una nueva hora de cálculo llamada “sprint backlog”. En esta hoja ya no apuntamos las funcionalidades a cubrir (historias de usuario), sino que las transformamos en tareas concretas (refactorizar X, investigar Y, etc.).
  En el sprint backlog iremos apuntando las horas que faltan para terminar las tareas (en este punto, quedan tantas horas como la estimación que hemos hecho).

2.- Implementación: una vez que tenemos el “sprint backlog” completado, podemos empezar el desarrollo. Se acuerda por ambas partes (product owner y equipo) que hasta que no se termine este sprint no se podrán “colar” nuevas funcionalidades. Si surge una nueva necesidad, se apuntará en el product backlog y en la planificación del próximo sprint se tendrá en cuenta.
Todos los días del sprint se hará una reunión (llamada “daily meeting”) del equipo para ir revisando cómo va el trabajo y actualizar el sprint backlog. El próximo día trataremos este tema.

3.- Revisión: una vez terminado el sprint, se reúnen el product owner, el equipo y cualquier persona interesada (por ejemplo gente de marketing, clientes, etc.) y se hace una demo informal de la nueva funcionalidad (llamada “incremento”). En esta revisión pueden surgir nuevas funcionalidades que serán apuntadas en el product backlog.

Por otro lado, se reúne el equipo de desarrollo consigo mismo, y saca dos conclusiones:

1. ¿Que nos ha ido bien y debemos repetir?
   
2. ¿Qué nos ha ido fatal y debemos mejorar?

Por ejemplo:
- Toñete: me da la sensación que en este sprint la hemos cagao con el tema de las pruebas de los nuevos renderizadores
- Juanín: sí, ha sido un infierno, pensé que no se acababa nunca.
- Toñete: en cuanto podamos deberíamos investigar cómo automatizarlo. Habrá cosas que no se puedan, pero seguro que hay alguna forma de automatizar aunque sólo sea una parte.
- Juanín: sí, lo apunto para colarlo en el próximo sprint.
- Toñete: por cierto, lo que sí que ha ido muy bien es el prototipo para probar lo de deshacer/rehacer
- Juanín: sí, menos mal que lo hicimos, porque yo no tenía ni idea como combinar los patrones Command y Memento. Una vez que tuve el prototipo, no fue más que aplicarlo al resto de casos.
- Toñete: pues para la próxima ya sabemos…

Bien, el próximo día hablaremos sobre cómo es el día a día de la implementación de un sprint y el "daily meeting".

Etiquetas: agile, SCRUM