¿Puedo dividir una historia vertical en tareas horizontales?

Mi equipo y yo estamos implementando Scrum en nuestro proyecto. Estamos en la fase de dividir las historias de usuario en tareas para asignar a cada desarrollador.

Entiendo el concepto de Slicing the Cake donde una historia de usuario representa una porción vertical que cruza todas las capas tecnológicas (es decir, desde la interfaz de usuario hasta el middleware y la base de datos).

Sin embargo, cuando divido mi historia de usuario vertical en tareas, se divide en capas horizontales. Así que termino asignando una tarea de capa horizontal para cada desarrollador: un desarrollador trabajaría en la parte de la historia de la interfaz de usuario, otro en el middleware y un tercero en la base de datos. Por lo tanto, al hacerlo, siento que estoy rompiendo el concepto de corte vertical.

¿Por qué asigna tareas al equipo, en lugar de alentarlos a colaborar en el trabajo?
@ToddA.Jacobs, ¿qué quieres decir? Por lo que entendí en Scrum, primero asigno un grupo de desarrolladores en una historia de usuario para que colaboren juntos. Pero luego, divido la historia en tareas, y aquí estoy confundido sobre cómo los desarrolladores deberían trabajar en una historia pero en diferentes tareas al mismo tiempo.
No. Los Equipos Scrum se autoorganizan . Está luchando con la implementación porque está tratando de hacer el trabajo que el equipo debería estar haciendo por sí mismo.

Respuestas (3)

Respuesta corta: las tareas son para que el equipo organice su trabajo como mejor les parezca. Si eso significa dividirlo en front-end, middleware y base de datos, está bien. Esto es en realidad una parte normal de la progresión de los equipos multifuncionales.

El hecho de que hayamos puesto a personas con todas las habilidades en el mismo equipo no significa que de repente conozcan esas otras habilidades. Entonces comienzan con un desglose horizontal como este y probablemente aún aíslan ciertos tipos de tareas con el individuo más hábil en esa cosa. Por lo general, bastante pronto al trabajar de esta manera, el equipo se encontrará en una situación en la que hay demasiadas tareas del tipo X para el miembro del equipo que generalmente las hace y alguien más tendrá que intervenir y ayudar, generalmente con algunos de las tareas más fáciles. Con el tiempo, las personas obtendrán un conjunto de habilidades más amplio y comenzarán a ver lugares donde dividir las tareas en capas horizontales ya no parece la mejor manera.

El gran escollo a tener en cuenta es que si el equipo termina en esa situación y en lugar de intervenir para ayudarse mutuamente, el resto del equipo pasa a nuevos elementos pendientes y usted termina con una pila de elementos pendientes que simplemente tiene un tipo de tarea en él. Veo esto más comúnmente con las tareas de prueba, pero ocasionalmente también aparece en otros tipos.

Enfatizaría la parte sobre el equipo organizando su trabajo, no es el trabajo de una sola persona dividir las historias en tareas.
@Erik, ¿podría dar más detalles sobre la parte "el equipo organiza su trabajo"? ¿Significa eso, por ejemplo, que cada desarrollador elegirá en qué tarea trabajará? y ¿una tarea debe ser realizada por un solo desarrollador o se puede compartir una tarea con varios desarrolladores?
@nader significa que el equipo dividirá las historias en tareas y luego decidirá cómo completarán esas tareas. Ya sea que trabajen en ellos por separado o juntos, depende de ellos, cualquier forma que encuentren de manera más efectiva los ayuda a completarlos. (Técnicamente, incluso depende de ellos si quieren dividirlos en tareas. El equipo está a cargo de hacer el trabajo).
@Erik Sí, y el equipo también está 'a cargo' de inspeccionar si su 'forma encontrada' actual continúa siendo la forma más efectiva de garantizar resultados para los usuarios. Y el OP (asumiendo el rol de Scrum Master) está 'a cargo' de hacer que el equipo rinda cuentas por hacerlo.

Descubrí con mis equipos que la parte difícil es dividir las historias correctamente, no las tareas, y considero que este recurso es invaluable:

https://agileforall.com/resources/how-to-split-a-user-story/

  1. Prepare la historia de entrada: ¿Es independiente, negociable, valiosa, estimable, pequeña, comprobable?
  2. Aplique uno de los patrones de división: por ejemplo, variaciones de interfaz, variaciones de reglas comerciales, etc.
  3. Evalúe la división: ¿son de tamaño similar?

Una vez que tenga grandes historias pequeñas e independientes, dividir estas historias en tareas técnicas es totalmente opcional y a algunos desarrolladores les gusta hacerlo y otros no necesitan hacerlo.

El punto que estoy tratando de hacer es más bien reducir las historias y preocuparme menos por las tareas técnicas. Ciertamente no necesita asignar tareas técnicas a diferentes desarrolladores.

Los desarrolladores deberían extraer 'historias' individualmente o en parejas y luego averiguar qué se debe hacer y si quieren capturar cosas a medida que avanzan las tareas.

Las rebanadas verticales se descomponen en tareas que son específicas de cada dominio y naturalmente horizontales. Está utilizando este concepto ágil correctamente: ¡BOOM!

Lo único que sugeriría sería considerar dejar que el equipo elija en qué tareas trabajar. Esto ayudará a su equipo a ser más informado, más efectivo, más satisfecho y definitivamente más ágil.

No es necesario descomponer las historias en tareas horizontales; parece ser una preferencia común, pero no un requisito.
¿Puedo dividir una historia vertical en tareas horizontales?
RespuestasAquíPolítica de privacidad1y, 0v