En estos días, después de haber pasado más de 24 horas en el último Sprint, sin descansar, donde comenté la experiencia de haber usado Scrum y XP en otro artículo, volvemos a la carga.
Esta vez, con dos semanas de Sprint, bastante más tiempo, podemos realizar algunas técnicas más para poder medir cuánto vamos a tardar realmente en terminar el proyecto que tenemos entre manos.
Para esto, hemos hecho uso de un gráfico burndown.
El gráfico de burndown se caracteriza por tener en su eje X el tiempo, solo los días laborables que se vayan a trabajar (sino el gráfico saldría algo extraño) y en el eje Y los puntos de tarea que se van a completar en el sprint.
Pila de Producto, Pila de Sprint y Puntos de Tarea
La pila de producto es la cantidad de características que nos piden que incorporemos a un producto software. Estas tareas son funcionales, generalmente.
La pila de sprint es una primera criba que se toma de la lista total de características, a modo de poder desarrollar una versión 0.1. Esto se realiza para que, al final del sprint, que no debe de ser un período de tiempo muy prolongado, se tenga algo palpable para el cliente (o dueño de producto) y pueda replantearse el resto de peticiones en función de lo que está viendo.
Los puntos de tarea son, en sí, la dificultad y el tiempo que se puede llegar a invertir en la tarea en sí. Es una unidad de medida relativa que no implica en sí tiempo, pero está bastante ligada a él.
Por ejemplo, si hacer un alta de cliente implica una sola consulta a base de datos y retornar el valor de resultado, esa tarea podemos estimar que tiene 1 punto. El caso de la modificación, implicaría tomar los datos, mostrarlos, tomar los cambios y hacerlos efectivos. Esa tarea se puede estimar en 2 ó 3 puntos. Ahora, hacer el balance de todos los clientes dados de alta y los ingresos que tuvieron en el año pasado, todo ello paginado… puede ser una tarea con una puntuación de 10, relativamente con respecto a las anteriores.
Datos en el gráfico de Burndown
El gráfico se traza para cada sprint. Se estima el tiempo que se puede o quiere tardar en realizar una serie de características. Al comenzar, el primer sprint, no se sabe la velocidad del grupo, realmente, por lo que se puede comenzar sin estimación precisa. Esto se va ajustando con el tiempo.
En principio, se comienza el trabajo, se comienzan a realizar tareas.
Al día siguiente, se hace revisión de las tareas acabadas y se apunta en el gráfico el día anterior y los puntos que se avanzó. El gráfico, al crearlo, se suele trazar una línea que cubre la diagonal de la esquina superior izquierda hasta la esquina inferior derecha. Si los puntos van cayendo sobre la línea, ya sabemos lo que se va a ir tardando en realizar el proyecto.
En caso de que los puntos vayan cayendo en el rectángulo superior, eso será indicio de que hay que eliminar historias. Si se mantiene siempre en el bloque inferior, se pueden agregar más historias.
Conclusiones
Después de un par de jornadas, se puede ver la velocidad del equipo y se tiene una percepción real de lo que se hace, lo que se tarda y las tareas que hay que ir acelerando o postergando para llegar a la fecha, sin necesidad de estar cerca de la fecha de entrega. Es, sin duda, uno de los mejores métodos de estimación de tiempos a corto plazo… para el sprint.
Hablaré en los próximos artículos sobre las estimaciones a largo plazo, gestión de hitos y más sobre la pila de producto.
) entre dos personas, una haciendo de piloto (al teclado) y otra haciendo de navegante (cabeza pensante).