|
 Este artículo explica tres prácticas ágiles de estimación y planificación:
- El gráfico burn-up o gráfico de producto, para mostrar en un vistazo el plan general de desarrollo del producto. A partir de la velocidad del equipo y las estimaciones previstas en la pila del producto, representa las fechas o sprints en los que se irá terminando cada versión.
- El gráfico burn-down o gráfico de avance, para monitorizar el ritmo de trabajo del sprint.
- La estimación de póker, para conducir reuniones con estimación de tareas por juicio de expertos: en su concepción original y para estimación sobre sucesiónd e Fibonacci.
Es un texto del curso de métricas ágiles de Open Knowledge de ScrumManager. 
Gráfico para mostrar en un vistazo, y de forma simple plan general de desarrollo del producto, y la evolución prevista.
Es un diagrama cartesiano que representa en el eje de ordenadas el trabajo estimado para desarrollar el producto, y en el de abcisas las fechas de finalización de los sprints previstos. 
Ejemplo:
Representación del plan del producto, a partir de los temas previstos en el product backlog.
Convenciones empleadas por el equipo de este ejemplo: - Unidad para medición de trabajo: tiempo ideal
- Tiene previsto realizar sprints de duración fija mensual
- El equipo está formado por 4 personas, y viene desarrollando una velocidad de 300 puntos por sprint (300 horas ideales de trabajo)
La figura anterior representa la situación actual del product backlog: el propietario del producto tiene previsto cerrar la versión 1.0 al disponer de los cuatro primeros temas, y su estimación inicial de trabajo para llevarlos a cabo es de 950 puntos. La versión 1.2 incluirá 3 temas más que, según la estimación inicial, supondrán unos 750 puntos de trabajo. Y están también trazados los temas con los que piensa cerrar la versión 1.3 que se prevén con 850 puntos más de trabajo. Para representar el plan del producto con un “Burn-Up”, se representan, con los fondos de escala apropiados: Eje X = Fechas de los sprints previstos
Eje Y = Puntos de trabajo 
A continuación se traza en el gráfico la línea de velocidad prevista. Siguiendo con el ejemplo, la línea roja de la imagen representa la velocidad de 300 puntos por sprint. También puede resultar útil esbozar una estimación optimista y otra pesimista para tener la visión de una holgura de fechas aceptable. 
La proyección sobre X del punto de la línea de velocidad correspondiente al esfuerzo previsto para una versión del proyecto, marca la fecha o sprint en el que previsiblemente estará realizada. Es el gráfico que actualiza el equipo en las reuniones de seguimiento del sprint, para comprobar el ritmo de avance del trabajo, y detectar desde el primer momento si el ritmo es el previsto, o puede verse comprometida la entrega prevista al final de sprint.
La estrategia ágil para el seguimiento de los proyectos se basa en: - Medir el esfuerzo que falta, no el realizado.
- Seguimiento muy cercano (diario a ser posible)
Y en este gráfico toman forma los dos principios:
- En el eje Y se registra el trabajo que aún falta por realizar
- Se actualiza a diario
El equipo dispone en la pila de tareas o sprint backlog de la lista de trabajos que va a realizar durante el sprint, y en cada uno figura el esfuerzo pendiente. Esto es, el primer día, en la pila de tareas figura para cada tarea el esfuerzo que se ha estimado, puesto que aún no se ha trabajado en ninguna de ellas. Día a día, cada miembro del equipo actualiza en la pila del producto el tiempo que le queda a las tareas en las que va trabajando, hasta que se terminan y van quedando a 0 los tiempos pendientes. La figura siguiente muestra un ejemplo de sprint backlog en el sexto día del sprint: las tareas terminadas ya no tienen esfuerzo pendiente, y del esfuerzo total previsto para el sprint: 276 puntos (A), en el momento actual quedan 110 (B). 
Con esta información de la pila del sprint (sprint backlog) se actualiza el gráfico poniendo cada día el esfuerzo pendiente total de todas las tareas que aún no se han terminado. 
El avance ideal de un sprint estaría representado por la diagonal que reduce el esfuerzo pendiente de forma continua y gradual hasta terminarlo en el último día del sprint: 
Las gráficas de diagonal perfecta no son lo habitual, y la siguiente imagen es un ejemplo de un patrón de avance más normal.  El siguiente sería el aspecto de la gráfica en un “sprint sub-estimado”  La estimación que realizó el equipo en la reunión de inicio del sprint es inferior al esfuerzo real que están requiriendo las tareas. Y el siguiente sería el patrón de gráfica de un “sprint sobre-estimado”. 
Es una práctica ágil, que resulta útil para conducir las reuniones en las que el equipo estima el esfuerzo y la duración de tareas.
Para evitar en estos casos las discusiones dilatadas que no terminan de dar conclusiones concretas, James Grening ideó este juego de planificación como ayuda para conducir la reunión. El modelo inicial de James Grening consta de 8 cartas con los números representados en siguiente figura, porque James lo ideó para las estimaciones de versión en Extreme Programming, con equipos que emplean como unidad de esfuerzo: días de trabajo de cada par de programadores y trabajan con tareas de tamaño máximo de 10 días.  El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la estimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzo estimado.
Cuando se considera que éste es mayor de 10 horas (o del tamaño máximo considerado por el equipo para una tarea), se levanta la carta “infinito”
Cada equipo u organización puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se va a estimar.
Lo relevante no es el número de cartas, la unidad de medida empleada, o si el tamaño máximo de tarea debe ser 5, 7 ó 10 días, sino trabajar con el modelo más apropiado al equipo, respetando los principios siguientes: - No definir tareas demasiado grandes, porque dificulta la precisión de las estimaciones y la identificación de riesgos. Un criterio válido, si el equipo no dispone de experiencia previa, es descomponer en otras menores las que tengan una duración mayor de 7 días ideales de trabajo.
- No definir tareas con duraciones inferiores a medio día ideal de trabajo.
- Utilizar al misma unidad de medida (story points, días, horas…) en todos los gráficos y backlogs.
Variante: sucesión de Fibonacci
Basado en el hecho de que al aumentar el tamaño de las tareas, aumenta también el margen de error, se ha desarrollado una variante que consiste en emplear sólo números de la sucesión de Fibonacci para realizar las estimaciones, de forma que:
- El juego de cartas está compuesto por números de la sucesión de Fibonacci.
- La estimación no se realiza levantando varias cartas para componer la cifra exacta, sino poniendo boca arriba la carta con la cifra más aproximada a la estimación.
Para estimar tareas puede ser válido un juego de cartas como éste:  Si se quiere emplear la planificación de póker para estimar requisitos a nivel de producto o de versión (funcionalidades, temas…) además de usarlo al nivel de tareas de sprint, se pueden añadir cartas al juego para permitir estimaciones de mayor tamaño (34, 55, 89, 144…)
Es frecuente emplear una carta con un símbolo de duda o interrogación para indicar que, por las razones que sean, no se puede precisar una estimación.
También es posible incluir otra carta con alguna imagen alusiva, para indicar que se necesita un descanso.
Funcionamiento - Cada participante de la reunión tiene un juego de cartas.
- Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que se va a estimar) el cliente, moderador o propietario del producto expone la descripción empleando un tiempo máximo.
- Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las posibles preguntas del equipo.
- Cada participarte selecciona la carta o cartas que representan su estimación y las separa del resto, boca a bajo.
- Cuando todos han hecho su selección, se muestran boca arriba.
- Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido para estimar, la tarea debe dividirse en sub-tareas de menor tamaño.
- Si las estimaciones resultan muy dispares, el moderador, con su criterio de gestión, y basándose en las características del proyecto, equipo, reunión, nº de elementos pendientes de evaluar… puede optar por:
- Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es necesario tanto tiempo?, y ¿por qué crees que es necesario tan poco tiempo?. Tras escuchar las razones, repetir la estimación.
- Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan quedado pendientes.
- Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de las funcionalidades resultantes.
- Tomar la estimación menor, mayor, o la media.
Este protocolo de reunión evita los largos atascos de análisis circulares en ping-pong entre diversas opciones de implementación, hace participar a todos los asistentes, reduce el cuarto de hora o la media hora de tiempo de estimación de una funcionalidad, a escasos minutos, consigue alcanzar consensos sin discusiones, y además... resulta divertido y dinamiza la reunión.
 |
Descargar artículo en formato PDF
RSS de los comentarios
