últimamente he estado intentando crear una planilla en la cual pueda llevar el burndown para el equipo.
Todas las que he encontrado on-line dependen de que uno use la planilla para hacer el tracking, es decir, ingresar las historias, las estimaciones e ir cambiando los estados. Lo que necesito es simplemente una tabla donde poner el valor de el trabajo pendiente cada día y que me calcule la velocidad y me haga el gráfico, ya que el traking lo realizo mediante mantis.
Actualmente tengo la planilla casi lista, pero hoy me encontré con que mi calculo de velocidad, si bien era correcto, no era realista; me explico.
La velocidad es básicamente la cantidad de puntos de historia que se realizan por día. Al final del día ingreso en la planilla la cantidad de puntos que tenemos pendientes por realizar, la planilla saca la diferencia con el día anterior y con eso tengo la “velocidad instantanea” para ese día. Para obtener la velocidad real, hago un promedio de todas las velocidades instantáneas. Con esta velocidad promedio, realizo una recta y esta es la recta de la velocidad que se muestra en el gráfico. A este cálculo me gusta llamarlo velocidad promediada.
Otra forma de hacerlo es simplemente hacer una recta entre el primer día de la iteración y el último día (día de hoy), pero esto es demasiado sensible a las fluctuaciones de velocidad. A esta velocidad me gusta llamarla velocidad simple.
El problema es que de la primera forma, apesar que se obtiene una velocidad estable que se corrije adecuadamente al promedio de velocidad del equipo, al finalizar la iteración me está dando fechas de término en el pasado. Esto es porque estamos (por ejemplo) tres días antes de terminar, con una velocidad de 6 y 2 puntos pendientes hace 3 días (tenemos muchos bugs que mantar antes de tomar esa tarea de 2 puntos) el promedio en este caso no se ve muy afectado por las velocidades de cero estos últimos días y me dice que “debiera haber terminado hace rato segun nuestro promedio” lo que es cierto, pero no es lo real.
Entonces, mi idea para arreglar esto es corregir la velocidad colocandole un techo máximo que corresponda a la última velocidad simple. De esta forma la mayor velocidad posible es la simple, pero segun algunas simulaciones que he realizado esto parece inadecuado porque da proyecciones demasiado alarmistas al medio de la iteración.
¿Alguien tiene alguna solución a mi dilema? ya sea una formula de correccion de la velocidad o algo que corregir a nivel de proyecto para evitar estas situaciones (no vale que digan que evitemos hacer bugs!).
EDIT: Sería suficiente si me contaran cuál es la forma que tienen uds de calcular la velocidad, si es que han leido un libro al respecto o les han enseñado formalmente. Yo estoy dando palos de ciego inventando la rueda nuevamente.
All Shapado.com content and data are available under the
últimamente he estado intentando crear una planilla en la cual pueda llevar el burndown para el equipo.
Todas las que he encontrado on-line dependen de que uno use la planilla para hacer el tracking, es decir, ingresar las historias, las estimaciones e ir cambiando los estados. Lo que necesito es simplemente una tabla donde poner el valor de el trabajo pendiente cada día y que me calcule la velocidad y me haga el gráfico, ya que el traking lo realizo mediante mantis.
Actualmente tengo la planilla casi lista, pero hoy me encontré con que mi calculo de velocidad, si bien era correcto, no era realista; me explico.
La velocidad es básicamente la cantidad de puntos de historia que se realizan por día. Al final del día ingreso en la planilla la cantidad de puntos que tenemos pendientes por realizar, la planilla saca la diferencia con el día anterior y con eso tengo la “velocidad instantanea” para ese día. Para obtener la velocidad real, hago un promedio de todas las velocidades instantáneas. Con esta velocidad promedio, realizo una recta y esta es la recta de la velocidad que se muestra en el gráfico. A este cálculo me gusta llamarlo velocidad promediada.
Otra forma de hacerlo es simplemente hacer una recta entre el primer día de la iteración y el último día (día de hoy), pero esto es demasiado sensible a las fluctuaciones de velocidad. A esta velocidad me gusta llamarla velocidad simple.
El problema es que de la primera forma, apesar que se obtiene una velocidad estable que se corrije adecuadamente al promedio de velocidad del equipo, al finalizar la iteración me está dando fechas de término en el pasado. Esto es porque estamos (por ejemplo) tres días antes de terminar, con una velocidad de 6 y 2 puntos pendientes hace 3 días (tenemos muchos bugs que mantar antes de tomar esa tarea de 2 puntos) el promedio en este caso no se ve muy afectado por las velocidades de cero estos últimos días y me dice que “debiera haber terminado hace rato segun nuestro promedio” lo que es cierto, pero no es lo real.
Entonces, mi idea para arreglar esto es corregir la velocidad colocandole un techo máximo que corresponda a la última velocidad simple. De esta forma la mayor velocidad posible es la simple, pero segun algunas simulaciones que he realizado esto parece inadecuado porque da proyecciones demasiado alarmistas al medio de la iteración.
¿Alguien tiene alguna solución a mi dilema? ya sea una formula de correccion de la velocidad o algo que corregir a nivel de proyecto para evitar estas situaciones (no vale que digan que evitemos hacer bugs!).
EDIT: Sería suficiente si me contaran cuál es la forma que tienen uds de calcular la velocidad, si es que han leido un libro al respecto o les han enseñado formalmente. Yo estoy dando palos de ciego inventando la rueda nuevamente.