¿Cómo abordar la quema de tareas scrum cuando las tareas involucran a múltiples personas?

12

En mi empresa, una sola tarea nunca puede ser completada por un individuo. Habrá una persona separada para el control de calidad y la revisión de código en cada tarea. Lo que esto significa es que cada individuo dará sus estimaciones, por tarea, en cuanto a cuánto tiempo llevará completar.

El problema es, ¿cómo debo acercarme a quemar? Si agrego las horas juntas, suponga la siguiente estimación:

10 horas - Tiempo de desarrollo

4 horas - QA

4 horas - Revisión del código.

Estimación de tarea = 18 horas

Al final de cada día, pido que la tarea se actualice con "cuánto tiempo queda hasta que esté terminada". Sin embargo, cada persona generalmente solo piensa en su parte. ¿Deberían marcar el esfuerzo restante y luego AGREGAR las estimaciones de esfuerzo a eso? ¿Cómo están haciendo esto?

ACTUALIZAR

Para ayudar a aclarar algunas cosas, en mi organización cada tarea dentro de una historia requiere 3 personas.

  1. Alguien para desarrollar la tarea. (hacer pruebas unitarias, ect ...)
  2. Un especialista en control de calidad para revisar la tarea (principalmente realizan pruebas de integración y regresión)
  3. Un líder técnico para hacer la revisión del código.

No creo que haya un camino equivocado o un camino correcto, pero este es nuestro camino ... y eso no va a cambiar. Trabajamos en equipo para completar incluso el nivel más pequeño de una historia siempre que sea posible. En realidad, no puede probar si algo funciona hasta que se complete el desarrollo, y tampoco puede revisar la calidad del código ... así que lo mejor que puede hacer es dividir las cosas en pequeños segmentos lógicos para que se pueda probar la funcionalidad mínima. revisado lo antes posible en el proceso.

Mi pregunta para aquellos que trabajan de esta manera sería cómo grabar una "tarea" cuando se configuran de esta manera. A menos que una Tarea tenga sus propias subtareas (que JIRA no permite) ... No estoy seguro de la mejor manera de realizar un seguimiento diario de "lo que queda".

AgileMan
fuente
8
¿Podría describir cuál es su proceso? Nunca usamos horas en nuestra planificación de Scrum, y nunca informamos las horas restantes. Las tareas se hacen cuando se hacen.
dcaswell
1
@ user814064: Buen punto. Cada vez que he visto equipos que estiman cada tarea, siempre se equivocan. A veces por un factor de 1/10 y más.
Arseni Mourzenko
Este proceso es nuevo para mí. En el pasado, hemos estado quemando la tarea cuando estaba completa. SIN EMBARGO, estoy tratando de alentar a las personas a mejorar su estimación. Podemos mirar hacia atrás en nuestras estimaciones y compararlas con las reales y, con suerte, aprender de ellas. Puede ser un esfuerzo infructuoso, pero es algo que quiero que los equipos prueben por un tiempo.
AgileMan 01 de
Es un poco difícil explicar por qué no deberías hacer esto en los pocos caracteres que puedes escribir aquí. La estimación es exactamente lo que su nombre implica: es vago, es una cifra aproximada y no se puede mejorar en ninguna forma significativa y equilibrada de costo-esfuerzo. Después de todo, se llama "estimar", no "calcular". Le aconsejaría que lea las publicaciones de Neil Killick en #NoEstimates: neilkillick.com/2013/01/31/…
Stefan Billiet

Respuestas:

14

Eso son 3 tareas, no una.

Puede ser una característica / historia, pero son tres tareas. Una sola persona puede completar una tarea en un tiempo finito.

Steven A. Lowe
fuente
@ user814064: no es una suposición; el OP enumeró las estimaciones para cada tarea en la publicación
Steven A. Lowe
Debería haber sido más específico ... esto ya está a nivel de tarea. Por ejemplo, CADA tarea (la pequeña parte de la historia) necesita ser desarrollada, probada y revisada. Aunque la tarea fue realizada por un solo individuo ... otros pasarán tiempo para asegurar que se complete. Supongo que puede hacer que cada tarea tenga sus propias tareas ... pero no estoy seguro de cómo funcionaría.
AgileMan el
3
@AgileMan: en un mundo de sentido común, una tarea es una sola unidad de trabajo que puede realizar una sola persona, y tres tareas en serie de tres personas diferentes es un proyecto. En el mundo scrum ... es lo mismo. (por ejemplo, www.scrumalliance.org/community/articles/2007/march/glossary-of-scrum-terms#1129). Story-1-dev, Story-1-QA-review y Story-1-code-review son 3 tareas diferentes. Si debe modelar tareas de 3 partes, quizás serían apropiados 3 gráficos de carga diferentes;)
Steven A. Lowe
Si esto se necesita a nivel de tarea, realmente necesita trabajar en su definición de hecho y desglosar sus tareas. Debe ser un simple sí / no saber si una tarea se ha completado, no un proceso a través de varias personas.
SpoonerNZ
7

TL; DR

Está utilizando el quemado incorrectamente de varias maneras. Las tareas y las historias están hechas o no hechas; Al tratar de rastrear las desviaciones de las estimaciones de planificación basadas en el tiempo en su consumo, en realidad está volviendo a estimar su horario en lugar de estimar el producto restante del trabajo.

En Scrum, deberías medir el progreso hacia una Meta de Sprint en lugar de medir la casilla de tiempo del Sprint. Esto mantiene el enfoque en la capacidad del equipo y la entrega de características en lugar de en los ajustes continuos de programación.

Tareas vs. Historias

Estás combinando tareas e historias. Las historias comprenden todas las tareas requeridas para completar la historia según la "definición de hecho" de su equipo. La historia se considera 100% incompleta a menos que todas sus tareas estén completas. En Scrum, las historias siempre se estiman de alguna manera; con mayor frecuencia, se estiman en puntos de historia.

Las tareas son los pasos o hitos necesarios para completar la historia. Si bien cada tarea puede tener dependencias y requisitos previos, ciertamente puede decir que la revisión del código está completa o no, independientemente de las otras tareas.

Quemar

En Scrum, su gráfico de quemado muestra la cantidad de trabajo restante para el sprint o proyecto. Los gráficos reales de quemados a menudo tienen mesetas; en algunos casos, el gráfico puede incluso aumentar. Por ejemplo, en un sprint de una semana con dos historias por valor de 3 y 5 puntos, sus puntos de datos pueden verse así:

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

En este escenario idealista, comienzas con 8 puntos de historia. La historia de 3 puntos se completó el martes por la tarde, mientras que la historia de 5 puntos no se completó hasta el viernes. Los puntos de la historia no se deducen de la quema hasta que la historia cumpla con la definición de hecho. Si está utilizando las horas ideales en lugar de los puntos de la historia, lo único que cambia es su escala.

Time-Boxing

La práctica generalmente aceptada es garantizar que sus tareas se descompongan en trozos pequeños entre 1/2 día y 2 días. La variación de más de un día debe ser evidente a partir de los stand-ups diarios o el Sprint Backlog; no debería haber necesidad de realizar una extracción de estado formal.

También puede realizar un análisis estadístico en el gráfico de quemado para determinar si su sprint tiene una tendencia correcta. Las pequeñas desviaciones o mesetas son normales, pero si nadie está levantando bloqueadores en las paradas diarias, pero su quema parece estancada, eso generalmente es una señal de que el Backlog de Sprint ha sido mal estimado o hay un "trabajo invisible" que necesita ser explícito en su proceso.

CodeGnome
fuente
No creo que estemos totalmente de acuerdo. Claro, el gráfico de rendimiento mide el progreso hacia una meta de sprint ... pero lo hace midiendo el progreso en historias de sprint específicas. En general, puede elegir quemar una vez que una historia esté 100% completa, o puede quemar horas en cada historia cada día a medida que se completa el trabajo. Estoy tratando de hacer esto último ... pero me resulta difícil para los equipos hacerlo. Siento que su publicación se desvía de la pregunta que hice originalmente.
AgileMan
uno de los riesgos de no permitir una tarea a cerca de 100% es tener el 100% de sus tareas 99% hecho, que no significa nada en realidad está "hecho"
hanzolo
1
@AgileMan Le resulta "desafiante que lo hagan los equipos" porque está midiendo lo incorrecto. Sin duda, puede aplicar cualquier metodología que funcione para usted y su equipo, pero mantendré la afirmación de que medir las estimaciones originales: el tiempo transcurrido no es lo mismo que medir el producto de trabajo restante. Haga lo que funcione para su proyecto, pero no tenga miedo de cuestionar los supuestos que sustentan sus métricas actuales.
CodeGnome 01 de
@CodeGnome. Hay una simple falta de comunicación aquí. No estoy tratando de rastrear el "tiempo transcurrido". Estoy tratando de determinar el "tiempo restante". ¿Cuándo se realizará esta tarea? Eso es todo lo que estoy tratando de determinar. Sin embargo, dado que incluso la tarea más pequeña (generalmente) involucra a varias personas, el desafío es cómo determinar lo que queda de una manera simple y directa.
AgileMan el
4

¿Puedes definir la tarea de desarrollo como "terminada" antes de que QA haga su parte? ¿Puedes definir la revisión del código como "hecho" antes de que se complete el desarrollo? ¿Se puede "realizar" el control de calidad si la revisión de código y desarrollo no lo está?

Diría que debe agregar los tres elementos en una sola tarea y que las tres personas deben trabajar juntas en ella.

Scrum NO dice que ningún artículo sea responsabilidad de un miembro del equipo. Todo lo contrario: los elementos de registro de sprint son responsabilidad del EQUIPO. Si se necesitan tres personas para realizar una tarea, entonces eso es lo que se necesita.

Matthew Flynn
fuente
Tengo algunas dudas sobre esa sugerencia. Para mí, una tarea de desarrollo se puede hacer antes del control de calidad y la revisión del código, pero la revisión del código y el control de calidad (que son tareas individuales para ellos) probablemente produzcan nuevas tareas de desarrollo que se pueden "quemar" individualmente. Por supuesto, si "tarea" significa "implementar una historia de usuario completa", entonces tiene razón, pero ¿por qué la tarea será tan burda?
Doc Brown
@DocBrown: lo he hecho en ambos sentidos. Descubrí que decir que una tarea se realiza cuando no se ha verificado (revisión y prueba) no ha resultado útil para seguir el progreso. Poner a todos en el gancho para completar la tarea ayuda a mantener la urgencia para todos los involucrados.
Matthew Flynn
Obviamente, nada se "hace" hasta que haya pasado por el proceso de DoD. Sin embargo, las cosas pueden progresar hasta un punto en el que puede ser beneficioso ser revisado por otras partes. Tal como está actualmente, combino todo el "trabajo" requerido para cada pequeña tarea en una hora agregada como usted ha mencionado. El desafío es cuando una persona está tratando de informar lo que queda, por lo general tienen que dar cuenta de su parte y luego agregar las estimaciones de las otras personas en la parte superior ... por lo que es una gran cantidad de trabajo ocupado. Siento que hay una mejor manera.
AgileMan
3

No importa. Siempre y cuando sea relativamente consistente en todas las historias, su tabla de rendimiento seguirá funcionando de cualquier manera. Use la forma que sea más natural para que su equipo informe.

Mi equipo realmente hace una especie de híbrido, aunque no por acuerdo formal. Dedicamos 16 horas si creemos que una tarea tomará una persona dos días, pero si dos personas terminan trabajando juntas, no la cambiamos.

Después de la estimación inicial, informalmente se vuelve más de un porcentaje completo para nuestro equipo que las horas restantes. Si originalmente pensábamos que tomaría dos días, pero después de un día, creemos que solo está completo en un 25%, tomamos 4 de las 16 horas originales libres. Eso deja 12 horas donde técnicamente estamos estimando 24, porque probablemente deduciremos 4 horas por los 3 días restantes.

Al principio, eso me molestó como scrum master, pero por extraño que parezca, es una forma muy natural de hacer estimaciones, porque los desarrolladores realmente odian agregar horas a una estimación. Todo hace un promedio para hacer que la quema aún sea útil, y eso es lo importante.

Karl Bielefeldt
fuente
2

El tiempo restante de la tarea no importa mucho: no se puede entregar nada hasta que se complete toda la historia.

Si desea realizar un seguimiento de cuánto tiempo queda en una historia (en general) haciendo que la gente complete el tiempo restante en las tareas, luego divida las tareas por persona.

Eso dijo:

  • Las grandes tareas pueden ser una indicación de que sus historias son demasiado grandes. En este caso, la mejor solución es reducir el alcance y el tamaño de las historias, y si lo reduce lo suficiente, el seguimiento del tiempo restante en las tareas ya no importa (ya sea que estén hechas o no, suma de la estimación de las tareas no hechas es lo suficientemente granular).
  • SCRUM anima a todos a recoger lo que hay que hacer. Si está asignando tareas a personas (en lugar de roles), entonces potencialmente se está impidiendo entregar una historia, incluso si el desarrollador no está haciendo nada, porque el control de calidad tiene un cuello de botella.
ptyx
fuente
-1

Divida la tarea en varias tareas e ingréselas como tareas donde cada una es manejada por una persona diferente.

Tarea original: arreglar algo

Nuevas tareas: (hijo del padre de la tarea original)

  • Dev A - Solucionando el problema
  • Dev B - Ayudando a Dev A a solucionar el problema (es decir, programación de pares, revisión de código)
  • Dev A: desarrollador que prueba la solución con Dataset X
  • Dev B - dev probando la solución usando el conjunto de datos Y
Asim Ghaffar
fuente
pregunta establece que las subtareas no están permitidas
mosquito
Nunca quise decir una subtarea per se ... quiero decir dividir la tarea en tareas y hacer que todos sean hijos de una historia o error ... reformularé mi respuesta ...
Asim Ghaffar
romperlo de la manera que usted describió ya se ha sugerido y explicado en al menos dos respuestas anteriores (las más votadas en este momento): "Eso son 3 tareas, no una ..." "Están combinando tareas e historias ..."
mosquito