Scrum Burndown Patterns [cerrado]

StackOverflow https://stackoverflow.com/questions/213214

  •  03-07-2019
  •  | 
  •  

Pregunta

Estoy en un equipo de 10 personas que trabaja en una gran base de código heredado con un propietario de producto menos que ideal. Nuestro trabajo acumulado está en muy mal estado y las grandes epopeyas frecuentemente han estado rompiendo nuestros sprints. El equipo también tiene problemas con su definición de finalizado: algunos miembros escriben la prueba de unidad religiosamente, otros no, a veces según el tiempo disponible.

Por lo tanto, he estado viendo algunos patrones de quemado interesantes, y me pregunto qué patrones están viendo los demás y qué significan.

Patrón 1: 

#
# # 
# # #  
# # # #     
# # # # #   
# # # # # #
# # # # # # #
  • Explicación positiva: " Todo bien. "
  • Explicación negativa: "Demasiado bueno para ser verdad". ¿Qué está realmente pasando? & Quot;

Patrón 2: 

#
#
# #
# #     
# # #   # 
# # #   # #
# # # # # # #
  • Explicación positiva: " Esto fue mucho más fácil de lo que pensábamos, vamos a ver más historias. "
  • Explicación negativa: ??

Patrón 3: 

#
# # # #
# # # #  
# # # #     
# # # # #   
# # # # # #
# # # # # # #
  • Explicación positiva: " No estoy seguro de este trabajo al principio, luego resulta más fácil de lo que pensábamos. "
  • Explicación negativa: " No hay suficiente progreso, dejemos de escribir pruebas unitarias para 'hacerlas' a tiempo '"
¿Fue útil?

Solución

Esto se reconoce en nuestra oficina como " ¡Ah, mierda! Me olvidé de eso. & Quot; burndown: 

    # # #
    # # # #
    # # # # #
    # # # # # #
#   # # # # # #
# # # # # # # #
# # # # # # # #

Otros consejos

El patrón 2 en el lado negativo es " no se estimó demasiado bien " ;.

Aquí hay algunos gráficos de quemado que he usado. Ignore las imágenes de fondo: están ahí solo para entretener a las personas con las que trabajo y, de lo contrario, no tienen nada que ver con nuestro trabajo. texto alternativo http://www.atalasoft.com/cs/ photos / techtalkgallery / images / 16157 / 425x285.aspx

Me encanta este gráfico. Es muy típico que un buen gráfico comencemos un poco lentamente a medida que eliminamos otras tareas, nos apoyamos en el trabajo, nos interrumpimos por otras cosas y presionamos para terminar.

texto alternativo http://www.atalasoft.com /cs/photos/techtalkgallery/images/16155/425x262.aspx

En este gráfico, comenzamos de manera constante y luego despegamos, terminamos antes de tiempo.

alt text http://www.atalasoft.com /cs/photos/techtalkgallery/images/16156/425x264.aspx

En esta tabla puede ver que comenzamos con mucha frecuencia y luego una tarea que parecía fácil resultó ser terriblemente difícil. Creo que terminamos deteniendo este sprint y construyendo uno nuevo.

Un problema con las quemaduras es que los cambios en el alcance se mezclan con el progreso contra el alcance.

En su ejemplo 2, una posible explicación es ... Santo humo, probablemente no debería haber esperado hasta el final de la iteración para comenzar esta historia / tarea arriesgada ... ¡es mucho más esfuerzo del que esperaba!

En el ejemplo 3, es posible que haya agregado el alcance temprano o haya descubierto que el trabajo es más esfuerzo del esperado (p. ej., la tarea se estima en 4 horas un día, luego 4 horas después de 8 horas de trabajo y el descubrimiento de que la tarea es mucho) más difícil).

Prefiero las quemaduras a las quemaduras por este motivo ... desasocia los cambios de alcance del progreso en dos líneas: un alcance y un trabajo restante, para que pueda ver el impacto del cambio de alcance con mayor claridad.

Mi punto de vista es no tomarse los gráficos de burndown demasiado en serio. Son un indicador. Al final, se trata de si completaste una historia o no.

¿Tiene retrospectivas efectivas al final de sus sprints?

¿Se siguen las acciones retrospectivas?

Si encuentra que la gente no escribe pruebas de unidad religiosamente, hágales hacerlo (si ese es el estándar de su equipo). Póngase de acuerdo en una definición común de hecho y apéguese a ella. Consulte la definición de hecho

Tener un proceso ágil como SCRUM requiere inspección y adaptación constantes.

Para mí, parece que hay problemas, pero su equipo no está abordando esos problemas. Si el propietario del producto no es el ideal, los problemas relacionados con esto deberían aparecer en sus retrospectivas para que pueda evitarlo en el próximo sprint.

si tienes epopeyas, siempre puedes desglosarlas, volver a priorizarlas y volver a planificarlas.

Aquí a menudo es así: 

#####
#######
########
#########
#########
#########
##########

Positivo: Entrega a tiempo.

Negativo: los elementos de la lista de pedidos demasiado grandes o demasiados elementos de la lista de pedidos comenzaron al mismo tiempo desde el principio.

Aquí hay uno que no he visto aquí todavía. Sucedió en nuestro último sprint. 

#
##
###
#####
#############
##################
###################
####################

Es el " hicimos un progreso mejor de lo esperado en nuestras primeras tareas, luego pensamos que estábamos por delante, aflojados, luego tuvimos que esforzarnos al máximo o arriesgarnos a deslizar una característica. "

Lección aprendida: las quemaduras son excelentes para rastrear esfuerzos pasados, pero no son necesariamente representativos de tu progreso futuro.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top