2

Reportando al final de cada iteración

Posted by David Doctor on martes, mayo 26, 2009 in , , ,
Leyendo lo que Roberto nos dice en su post "Preparados para ser ágiles" me ha venido a la cabeza algún que otro problemilla que hemos sufrido en proyectos cuando algún director, al finalizar un sprint, pregunta: y bien, ¿cómo va el avance del proyecto? ¿qué tal ha ido esta iteración? quiero un pequeño informe para ir tomando decisiones. Mi respuesta inicial fue: lo mejor que puedes hacer es acercarte al panel de tareas, echarle un vistazo al burndown chart y al release burndown chart, con esto podrás contestar todas tus preguntas.

Esta respuesta te puede servir por primera vez pero al final te siguen pidiendo, iteración tras iteración, alguna forma menos pesada (para ellos) de tener datos, al final yo pensaba: "ya estamos volviendo a la burrocracia innecesaria. Esto no es nada ágil, si la información está ¿por qué tenemos que reproducirla en otro formato?"

Finalmente, después de leer un buen libro (Agile estimating and planning) tome prestada una pequeña idea de Mike Cohn presentando al final de cada sprint un resumen.

Os muestro un ejemplo donde he eliminado algunos datos "confidenciales" con algún borrón que otro ;-)


La primera sección comienza con una explicación del contexto del sprint: indicamos fecha de inicio, fin, número de días laborables y el personal que ha participado.

Si os fijáis en la última tabla se ponen días planificados vs. días trabajados, mostrará si una persona estuvo al 100% asignada, si estuvo enferma, etc. esto ayudará a dar explicaciones de qué ocurrió en la iteración.





La siguiente sección mostrarán gráficos muy útiles: burn down chart y un gráfico de barras de la velocidad de las últimas iteraciones, junto con la media.


Finalmente, siempre siempre me gusta poner una valoración del sprint donde indicaremos que historias de usuario fueron incluidas y los puntos que realmente han ganado.


Si os digo la verdad este tipo de informes, que a mi me llevaban 40 minutos, ayudó a la dirección de la empresa a ver un estado del proyecto y a mi mismo para tener datos históricos del equipo que en el futuro nos ayudaría a mejorar. Y vosotros, ¿usáis algo parecido? sería muy interesante si alguien comparte su experiencia.

|

2 Comments


Nosotros usamos algo parecido, pero mucho más sencillo. En nuestro caso basta porque toda la dirección (incl. el CEO) asiste a la mayoría de las demos. Tampoco es necesario reportar horas dedicadas a ese proyecto porque no hay otros. Ventajas de una empresa pequeña.

Detalles en http://jordionsoftware.blogspot.com/2009/10/simple-metrics-for-scrum.html


En mi caso, el autonombrado "Scrum Master" nos exigía que al terminar cada tarea, introduzcamos las horas ocupadas en esta tarea. De esta manera el podía dar su "informe de horas" con una suma en Excel. Esto afectó mi productividad, ya que antes tomaba una tarea tras otra, sin importarme el reloj, sino más bien tener bien controlado lo que iba a hacer cada día.
Con este invento, tenía que pararme a pensar ¿fueron 2 horas o 4? ¿Los 40 minutos de Skype con el cliente son parte de esta tarea o debo crear otra? ¿Si estas 2 tareas suman 6 horas, estuve perdiendo el tiempo el resto del día? Si hacemos mas de 8 horas al día, ¿las próximas semanas nos exigirán lo mismo?
Y la verdad es que antes de aplicar este control nos iba muchísimo mejor con los clientes. Bueno, terminé yéndome a otro curro por que sentía que con esto el equipo había perdido toda su capacidad de autogestionarse

Publicar un comentario