Supongamos que el equipo de desarrollo está planificando el próximo Sprint. ¿Qué significa técnicamente que se agregue una historia de usuario al Sprint Backlog? ¿Se asigna a un desarrollador oa todo el equipo? (Si está asignado a todo el equipo de desarrollo, ¿cómo hacemos esto en Jira?)
Cuando el equipo planifica un sprint, extraen elementos de la cartera de productos o historias de usuarios de la parte superior de la cartera de pedidos y los introducen en su sprint. Las historias que seleccionaron para hacer ese sprint ahora forman el " sprint backlog ".
Ahora, en cuanto a la asignación de estas historias... depende .
Como parte de la planificación, los desarrolladores también pueden decidir quién hace qué. Jake podría asignarse la Historia 1, Jane podría asignarse la Historia 2, y así sucesivamente. Ese es un indicador visual de quién hace qué trabajo, pero en realidad no es obligatorio. El equipo es dueño de todas las historias, sin importar la persona que trabaje en ellas .
Por ejemplo, trabajé en un equipo donde no asignábamos las historias. Casi todos éramos desarrolladores completos, así que tomamos historias y trabajamos en ellas a medida que estuvimos disponibles. Sabíamos quién estaba trabajando en qué porque estábamos en la misma oficina, nos comunicábamos cuando tomamos cosas nuevas para trabajar y sincronizamos y planificamos nuestro trabajo durante el día. Entonces, las historias pasaban de TODO a IN PROGRESS sin asignarse a nadie. Jira no tiene ningún problema en hacer eso. La historia simplemente aparece como SIN ASIGNAR en Jira.
Así que depende de lo que quieras hacer. Si encuentra la información útil para ver, puede asignar una historia. Si no, el equipo aún sabrá cómo organizarse y hacer el trabajo.
La Guía Scrum de noviembre de 2020 dice:
El Sprint Backlog se compone del Sprint Goal (por qué), el conjunto de elementos del Product Backlog seleccionados para el Sprint (qué), así como un plan procesable para entregar el Incremento (cómo).
En esta definición, la unidad de trabajo no está definida. Es decir, el elemento de la cartera de productos puede no ser la unidad de trabajo realizada por uno o más miembros del equipo de desarrollo.
En mi experiencia, la mayoría de los equipos hacen una de dos cosas. Un enfoque común es que los elementos de la cartera de productos se asignen a uno o más miembros del equipo de desarrollo. El propio equipo decide cómo se asigna este trabajo, pero la señal de un equipo autoorganizado suele ser la autoasignación y un enfoque basado en la extracción. Otro enfoque es que un equipo descompone los elementos de la cartera de productos en subtareas y esas subtareas se asignan a los miembros del equipo de desarrollo. Una vez más, la autoasignación y el trabajo de extracción indican un equipo autoorganizado.
La "asignación" exacta depende de las prácticas del equipo y las herramientas. Prácticas como la programación en parejas y la programación en masa tienen dos o más personas trabajando en una sola unidad de trabajo, por lo que no hay un solo asignado. Sin embargo, incluso en estos casos, un equipo puede optar por decidir que una sola persona sea "propietaria" del trabajo y se identificaría como el cesionario. Las herramientas también son importantes, ya que las herramientas pueden tener limitaciones sobre quién puede ser cesionario. Por ejemplo, Jira solo permite una persona en el campo asignado, por lo que los equipos pueden dejarlo en blanco, crear cuentas de equipo o usar campos personalizados como solución alternativa.
En concreto, en Jira tienes varias opciones:
Depende del equipo crear el trabajo pendiente del sprint en función de los elementos del trabajo pendiente elegidos por el propietario del producto. Algunos equipos utilizan la planificación de sprints para asignar al menos algunos elementos a desarrolladores individuales, otros equipos adoptan un "sistema de extracción", lo que significa que los elementos no se asignan previamente y depende de cada individuo recoger los elementos del trabajo pendiente cuando tienen la capacidad. para hacerlo
En Jira, si desea que más de una persona trabaje en un problema, la forma más fácil es hacer que cada desarrollador cree sus propias subtareas separadas asignadas a sí mismo.
Una "historia" no se corresponde necesariamente 1:1 con una tarea de desarrollo. Debe determinar a partir de la historia qué se debe hacer y quién lo debe hacer para completarlo.
Ya que está preguntando sobre historias de usuarios, no tareas: una historia de usuario generalmente consta de varias tareas que pueden ser abordadas por diferentes miembros del equipo, a veces incluso diferentes oficios. Eso significa que, si bien puede asignar miembros del equipo a cualquiera de las tareas de la historia (aunque tampoco tiene que hacerlo), es más probable que la historia sea propiedad del equipo en su conjunto .
Puede haber excepciones, por supuesto. Por ejemplo, podría tener una historia de usuario compuesta completamente por tareas que solo puede resolver un especialista del equipo, por lo que podría tener sentido asignar la historia a esta persona para que sea visible.
Tenemos la propiedad de los componentes (hay un líder comercial y un líder de desarrollo para cada uno).
Personalmente, no automatizamos la asignación del ticket al líder de DEV, sino que lo automatizamos para asignarlo al líder comercial de acuerdo con el componente (el primer componente mencionado en el ticket, el cesionario responsable, está configurado en la configuración del Proyecto en JIRA).
Una vez que la historia está lista para el desarrollo, el líder de negocios/analista habitual la reasigna al líder de DEV adecuado (para deshacerse de la propiedad del código, hay una rotación de los líderes de DEV, por lo que nos referimos a una tabla específica sobre confluencia: es actualizado por el director del proyecto).
Es más relevante para nosotros, porque el líder comercial siempre conoce a la persona adecuada, ya que el líder comercial generalmente colabora con el líder DEV del componente en la estimación de LOE, propuestas al Cliente, etc.
Parece un poco sobrecargado, pero no lo es.
Como Bogdan ya mencionó: "el equipo es dueño de todas las historias", y el equipo también debería ser dueño de la manera de hacer esas historias. Me refiero a asignar previamente a un miembro individual o tirar cuando el progreso del sprint está bien.
Una práctica en mi equipo es que siempre tenemos un propietario individual a nivel de historia, incluso cuando participan varios miembros. El propietario estará a cargo (frente al equipo) de facilitar todas las subtareas y los miembros relevantes para completar la historia completa.
Bogdán