May 21
Nunca habíamos hecho planificación por poker, pero ya llevo dos a cuestas. No sé si el proceso es como debe o no, pero icescrum2, pone las siguientes limitaciones:
- Una historia de usuario no se puede meter en un sprint hasta que ha sido estimada
- Una historia de usuario no se puede partir en tareas hasta que ha sido metida en un sprint.
La verdad, es que no parece una medida lógica, ya que parece comúnmente aceptado que para estimar una cosa grande hay que partirla antes en cosas pequeñas.
Así, que con esta limitación, nuestro proceso es el siguiente:
- Se coge la primera historia de usuario del product backlog.
- Se habla de ella y se concreta lo más posible. Para ello los miembros van enumerando una posible lista de tareas a hacer que se apunta en papel. Por ejemplo, para que "el usuario pueda ver la lista de gurruños", hay que "pintar un JTable en la interface de usuario", "hacer una consulta a dos tablas de bd", "convertir los resultados de la consulta a un unico bean", etc.
- Cuando está claro, se echan las cartas para estimar la historia de usuario completa hasta llegar a un acuerdo. Es increible, pero incluso haciéndolo así hay a veces discrepancias y uno de los miembros dice 20 días mientras que otro dice 3, porque han entendido cosas totalmente distintas. Precisamente eso, aparte de la planificación, es una de las grandes ventajas de la planificación por poker: asegurarse que todos hemos entendido lo mismo.
- Se pone la estimación en icescrum, se mete la historia en el sprint y luego se añaden las tareas en papel. Para cada una de estas mini-tareas se apunta el tiempo estimado, esta vez siguiendo la estimación sólo del miembro experto en el tema (el que sabe de Swing, el que sabe de BD, etc). Se hace una comprobación aproximada de que la suma de las tareas da la estimación de la historia, pero sin ser estrictos.
- Se pasa a la siguiente historia de usuario.
Me queda la duda si cada una de las tareas debería usarse también con la planificación por poker, pero entiendo que el proceso se haría entonces muy largo. No es lo mismo hablar y estimar cinco, seis historias de usuario, que hacerlo con todo eso más diez o veinte tareas.
En fin, según vayamos viendo resultados en sucesivos sprints, iremos afinando el proceso.
May 21st, 2009 at 7:34 pm
Hola de nuevo, jeje. Nosotros hasta el anterior sprint estabamos utilizando una herramienta para el seguimiento que se llama agilo, que te permite dividir las historias en tareas y asignarles un valor a estas en horas. Despues de casi un año de hacerlo asi, hemos decidido que ya no vamos a estimar en horas las tareas, y que tampoco se van a sacara tareas, de las historias. Lo que hacemos ahora es intentar hacer historias mas pequeñas que tengan una valoracion puntos de 5 como mucho. De esta manera salen mas historias pero mas concretas.
La planificacion poker la hacemos al principio del lanzamiento, y tenemos 4 sprints por lanzamiento cada uno de 2 semanas. En sese momento planificamos los puntos de un numero suficiente (siempre siendo optimistas) de historias para esos 4 sprints. En este momento se priorizan tambien estas historias.
Despues establecida una velocidad en puntos de historia por sprint, la herramienta que utilizamos ahora, va metiendo las historias mas prioritarias en el sprint actual.
Otra cosa que hemos empezado a hacer, para sustituir el desglose en tareas, es establecer unos test de aceptacion, de tal manera que una historia no se considera acabada hasta que pase los test que se establezcan.
Bueno, con mi capacidad nula para explicarme, y que dentro de lo que cabe tambien soy muy novato en esto de lo agil, podria estar intentando explicarme durante un dia entero sobre el porque hemos considerado que para nosotros es la mejor solucion.
PD: En cualquier reunion diaria podemos incluir una historia, tanto al backlog sin estimar, como estimandola y colocandola en el sprint actual si es necesario. De esta menera cada lanzamiento tenemos una reunion mas extensa, pero despues va todo mucho mas “agil”. Se aceptan sugerencias para mejorar la formula jeje
Saludos
May 21st, 2009 at 7:45 pm
Hola Teban:
Una pequeña duda. Si las historias las medís por puntos y no hacéis tareas, ¿cómo sale el gráfico burndown chart? Supongo que a escalones, según se vayan cerrando historias ¿no?. ¿O aparte de los puntos, ponéis también días/horas estimados para terminar la historia?
Lo de los test de aceptación (¿automáticos?) supongo que es nuestro siguiente paso, pero teniendo en cuenta que mañana acaba nuestro primer sprint de una semana, supongo que debemos ir avanzando poco a poco. ¿Cuánto tiempo lleváis haciendo Scrum?. Hablas de más de un año y parece que el tema de los lanzamientos lo tenéis muy estudiado ….
Gracias y se bueno.
May 21st, 2009 at 7:58 pm
el grafico de burndown salia a escalones tambien antes, jeje. Creo que no nos hace falta ( o eso pienso hoy, lo mismo mañana volvemos al sistema anterior) poner los dias que hacen faltan. Son historias pequeñas que como mucho duran una semana, pero lo normal son de un dia o dos. Por eso en la reunion ya se ve lo que creemos que falta para acabar algo en concreto.
Los test son automaticos, en un servidor de integracion continua con hudson, ant, cvs, y ahora estamos tambien con convertura, para ver el porcentaje de codigo que esta probado (covertura es todavia nuevo para nosotros y todavia falta algun fleco).
Casi un año con scrum, pero al principio con tablas escel y un poco precario, en realidad intentandolo hacer bien 7 meses o asi
Mañana mas, deu
May 21st, 2009 at 7:59 pm
uy ese escel!!! si es que no son horas
May 22nd, 2009 at 5:18 am
hao,
Mmmm a mi no me parecen limitaciones, estoy aprendiendo scrum sobre la marcha y pues me parece que:
Un sprint ya tiene un intervalo de tiempo asignado, por ende no podemos meter en dicho sprint historias q aun no tienen estimado tiempo/costo.
En iceScrum las historias se pueden dividir si se considera necesario, y asignarlas a un grupo o Categoría que controla al 100% el productOwner.
Las historias son requerimientos desde el punto de vista del cliente (el productOwner es el que decide el destino de la historia), por ende deberían ser bloques tangibles para el productOwner, no muy detallas (a menos que el productOwner hable el mismo idioma que los desarrolladores)
que la fuerza este contigo
May 22nd, 2009 at 6:25 am
Hola Orlando:
No son limitaciones. Es simplemente que en el sprint planning nos obliga a apuntar previamente las tareas en un papel, ya que no podemos meterlas en icescrum puesto que la historia no está estimada (estamos haciéndolo precisamente partiendo en tareas). Me parece difícil estimar la historia sin enumerar previamente las tareas que deben realizarse, no por estimar cada tarea y luego sumar, sino por hacerse una idea lo más real posible de cuánto trabajo lleva esa historia.
Se bueno.