2010-09-01 12 views
6

Estamos pensando en pasar de Scrum a un estilo de desarrollo más Kanban, sin embargo, una cosa que no me queda clara es cómo supervisar el progreso en Kanban.¿Cómo realizo un seguimiento del progreso cuando uso Kanban?

He leído que el progreso puede medirse controlando el tiempo del ciclo de cada historia y luego presumiblemente aplicando esta vez al número de historias pendientes. Pero me parece que esto depende del tamaño y la complejidad de las historias, que podrían ser todas diferentes.

También he visto que se utilizan gráficos burndown, por lo que ¿habrá un gráfico para la versión completa? Como el retraso no es fijo (a diferencia de un sprint), ¿solo permitiría que se quemara/se agotara a medida que el pedido pendiente sea enmendado por el PO? Supongo que a medida que te acerques a liberar el retraso acumulado debería ser menos volátil, lo que te permite completar la tarea.

Después de pensarlo un poco más, creo que mi problema es que a nuestros gerentes les gusta la "ilusión" de control que trae consigo una gráfica burndown. Tienden a verlo (erróneamente en mi opinión) como un cronograma y, por lo tanto, pueden emitir juicios como que el proyecto está "a tiempo" o "retrasado" o lo que sea. No puedo ver cómo se replica en Kanban. Tal vez eso sea algo bueno.

+0

Pregunta de programación? – Select0r

+0

En lo que respecta a la gestión de un proyecto de programación, creo que está en consonancia con el tipo de preguntas formuladas en este sitio. –

Respuesta

3

Para un proyecto completo, la mejor forma de seguir el progreso es el Diagrama de Flujo Acumulativo. Obtenga más información sobre CFD en this presentation. También puede aprender de CFD sobre cosas como cuellos de botella, etc.

Para tareas específicas, realmente depende de su enfoque. Si tiene funciones pequeñas (como 1-2 días de desarrollo) en la placa Kanban, puede ver el estado directamente en la placa, ya que las funciones se mueven rápidamente a través del flujo de trabajo.

Si utiliza funciones más grandes, puede dividirlas en tareas más pequeñas. Esta es básicamente la forma en que trabajamos con nuestras características: para funciones más grandes (como 5-10 días de duración) las dividimos en tareas de desarrollo (sin embargo, no ponemos tareas de desarrollo en la placa). Entonces puedo decir que la tarea A tiene 3 de 4 tareas de desarrollo completadas, por lo que estamos bien. Además, estimamos la duración de las tareas de desarrollo para poder distinguir entre las tareas de una hora y las de ocho horas. Para las características pequeñas, tenemos solo una tarea de desarrollo que está desarrollando la función.

+0

Creo que mi problema es que a nuestros gerentes les gusta la 'ilusión' de control que trae consigo una gráfica burndown. Tienden a verlo (erróneamente en mi opinión) como un cronograma y, por lo tanto, pueden emitir juicios como que el proyecto está "a tiempo" o "retrasado" o lo que sea. No puedo ver cómo se replica en Kanban. Tal vez eso sea algo bueno. –

+0

CFD es una especie de gráfico de quemado. Muestra cuánto trabajo ya ha hecho. Ahora, si necesita verificarlo contra algún tipo de programa, simplemente trace una referencia, una línea ascendente a través del gráfico (que represente el ritmo esperado para completar las características) para ver si lo está haciendo mejor o peor de lo planeado. – pawelbrodzinski

+1

@Si Keep: ese es el punto con los gráficos de reducción: para ver si el equipo puede terminar razonablemente sus tareas durante el sprint actual. Para gráficos de sprints cruzados, recomiendo [tablas de quemado] (http://blog.workingsoftware.se/2010/09/burn-up-or-burn-down.html) –

Cuestiones relacionadas