Scrum: cómo trabajar en una historia a la vez

Fui nominado como scrum master en un nuevo equipo de scrum formado. Ya hemos hecho algunos sprints. Al principio traté de hacer que mi equipo trabajara en una historia a la vez. Pero no funcionó. Mi equipo tuvo dificultades para distribuir las tareas de manera que puedan trabajar simultáneamente en una historia. Tal vez estamos haciendo algo mal?

Por ejemplo: tenemos una historia para crear un nuevo diálogo. Creamos las siguientes tareas:

• Crear clases de modelo
• Leer datos del modelo de la base de datos
• Conecte clases de modelos con vista
• Implementar el manejo del diálogo
• Guardar datos al cerrar
• Documentación de prueba
• Descripción de la solución

¿Pueden realizar estas tareas más de una persona a la vez? Las tareas, más o menos, se basan entre sí. ¿O diseñamos las tareas de manera incorrecta?

¿Por qué debería todo el equipo trabajar en una sola historia?

¿Por qué no hacer historias lo suficientemente pequeñas (y lo suficientemente independientes) para que una persona (o mejor, un par que haga programación de pares) pueda trabajar en una sola historia? Este proceso también ayuda a definir mejor los requisitos y a pensar más sobre el problema y la implementación. Las estimaciones también pueden ser más precisas, pero no hay garantías aquí.

Si bien esto depende en gran medida del tamaño de la historia del usuario, en muchos casos solo se debe asignar un desarrollador a una historia para evitar que sus desarrolladores pisen los pies de los demás. Aunque las historias más grandes o muy complejas pueden requerir más desarrolladores, pero también es posible dividir esas historias en muchas historias más pequeñas que pueden asignarse individualmente.

Lo que generalmente hacemos es desglosar las historias en subtareas de desarrollo / infra / analista.

1. En general, todo lo que dura más de un día es una historia.

2. Una vez que las tareas se desglosan, uno o un máximo de dos desarrolladores trabajan en una historia, dependiendo del número de tareas disponibles. Por lo general es uno.

3. Registramos el tiempo dedicado y actualizamos la estimación restante al final del día antes de irnos o antes de que se levante.

4. Las subtareas se crean para cualquier problema nuevo que surja mientras se trabaja.

5. Una historia de más de 2 semanas de trabajo se considera una epopeya.

6. Una epopeya puede estar compuesta de muchas historias

Lo que quiere que haga su equipo se llama enjambre , pero no todos los elementos de la cartera pueden ser enjambrados por todo el equipo. El pensamiento común es que el enjambre requiere algunas condiciones previas:

• un equipo cruzado y funcional
• una historia no trivial
• Una definición de "hecho" que implica la participación de todo el equipo

Al dividir una historia en tareas, el equipo ya debe estar en modo de enjambre para que las tareas generadas sean compatibles con el enjambre y puedan involucrar a todo el equipo.

Pero tenga cuidado al usar enjambres con demasiada frecuencia o con demasiadas personas a la vez, ya que podría encontrarse con un problema de sobrecalentamiento, cuando puedan aparecer algunos conflictos entre los miembros del equipo, ya que son demasiados trabajando en el mismo elemento.

Es posible que desee leer Mike Cohn ¿Debería un equipo pulularse en un elemento de la lista de pedidos a la vez? o este artículo que escribí (ayer) que trata más específicamente de errores: enjambre o no enjambre

Una gran parte de SCRUM es que el equipo debería tomar este tipo de decisiones. La cartera de pedidos debe tener las historias de los usuarios con la suficiente información para que se generen tareas.

Si bien es posible forzar una historia de usuario en un elemento en el que todo el equipo puede trabajar simultáneamente, lo más importante es que el equipo elija los elementos para trabajar, defina las tareas para terminar la historia del usuario y utilice el soporte diario para ver si está en camino con el trabajo prometido.

El dolor que siente al tratar de trabajar en una sola historia a la vez debe ser reconocido por el equipo y en el sprint retrospectivo se deben plantear posibles soluciones. Averigua qué estás haciendo bien y qué cosas hay que mejorar.

Usando su ejemplo de la dificultad para distribuir tareas en las que se puede trabajar simultáneamente, una posible solución es asumir múltiples historias y entregar 3 o 4 elementos en un sprint. Dado que las tareas para esta historia de usuario se desarrollan una encima de la otra, será difícil distribuir el trabajo. Entonces, en lugar de luchar, abrazarlo.

Sus tareas, como se indica, parecen lo suficientemente "pequeñas" para ser distribuidas, pero existe cierto acoplamiento entre tareas como la de modelar los datos y recuperarlos de la base de datos.

Lo que sería posible es dividirlo en tres cosas principales en las que las personas pueden trabajar simultáneamente, con algo de trabajo / configuración adicional:

• Back-end (base de datos, modelo, etc.)
• Front-end (utilizando datos simulados)
• Pruebas (configuración de expectativas, escenario, etc.)

Las tareas que no se pueden dividir se pueden hacer por pares. Y, por supuesto, no hay nada intrínsecamente malo con más de una historia en progreso en cualquier punto; siempre y cuando cada miembro del equipo sepa lo que están haciendo los demás, y puedan ayudar cuando sea necesario (como en 'propiedad de código compartido').

Debes mantener a tu equipo enfocado, sí, pero al mismo tiempo debes mantener a todos ocupados y a todos involucrados.

Además, ¿qué tan grande es tu equipo? Esto también es un factor; es bastante difícil tener a diez personas trabajando en una historia, y si puedes, tu historia es muy, muy grande y debería dividirse (al igual que tu equipo).