2
Reportando al final de cada iteración
Posted by David Doctor
on
martes, mayo 26, 2009
in
informes,
release burndown chart,
reporting,
SCRUM
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.
|
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.
|
Entradas
