Al hablar de bloqueadores en el tablero de Scrum, me di cuenta de que podríamos tener tareas interdependientes. Por ejemplo, el diseño de la base de datos depende de algunas actividades en el flujo de UX. O tal vez se dé cuenta más tarde de que un módulo requiere que otro módulo esté terminado.
En un caso ideal esto no debería suceder, pero nada es ideal. Imagínese si durante el Sprint el desarrollador A está trabajando en la Tarea 1, que depende de la finalización de la Tarea 2. La Tarea 2 es parte del mismo Sprint. Entonces, en tal caso, básicamente hemos reducido la cantidad de tareas paralelas en el Sprint.
En tal caso, ¿cómo debemos manejar la Tarea 1? ¿Debería eliminarlo de inmediato del tablero de Scrum y reemplazarlo con otra tarea? ¿O debería dejarlo en el Sprint, hasta que comience el próximo Sprint? ¿Qué pasa si hay más de una tarea como esta en el Sprint?
Creo que la pregunta que está haciendo apunta más a un problema con la forma en que divide sus historias/tareas/elementos de trabajo/lo que sea, y cómo se escriben. En lugar de tratar de resolver los síntomas de este problema, creo que tiene más sentido que intente abordar el problema de raíz aquí. Por supuesto, a veces hay dependencias técnicas entre las historias.
Escribir elementos de trabajo
Una de las partes más cruciales de Scrum es escribir historias de usuarios que se dividan verticalmente , no horizontalmente . En la práctica, esto significa que cada historia de usuario debe cubrir una funcionalidad completa, desde la base de datos hasta la interfaz de usuario. En general, debe evitar escribir elementos de trabajo separados para diferentes capas de la aplicación. Tener elementos de trabajo divididos verticalmente le permite estimar mejor en cuántas tareas puede trabajar en paralelo (por supuesto, respetando su límite WIP) y le brinda al equipo una mejor oportunidad de estimar lo que pueden hacer.
División de elementos de trabajo
Al dividir los elementos de trabajo en Scrum, Mike Cohn sugiere pensar en dividir las historias de 5 maneras (las he enumerado aquí en mi orden de preferencia, en lugar del orden en que él las enumera):
Notará que ninguno de estos métodos dice "separar el trabajo de la base de datos del trabajo de la capa API del trabajo de la interfaz de usuario". El corte horizontal en Scrum es un antipatrón y debe evitarse.
Dependencias técnicas entre pisos
Evitar los sonidos de corte horizontal, según su pregunta original, debería ayudar a su equipo a resolver el problema al que se enfrenta. Sin embargo, todos los equipos se enfrentan al problema de las dependencias técnicas entre historias. "Necesito crear usuarios antes de poder actualizarlos o eliminarlos", por ejemplo, si divide las diferentes funcionalidades de CRUD. En este caso, la estrategia más efectiva que he encontrado es simplemente hacerle saber a su propietario del producto que existen dependencias técnicas entre las diferentes historias de usuario y que él o ella debe priorizar en consecuencia.
¡Espero que esto ayude!
Su implementación de Scrum sufre de una serie de marcos antipatrones que se detallan a continuación en la sección Análisis . Estos problemas de proceso generalmente se pueden resolver a través de:
Las soluciones recomendadas se describen en detalle en la sección Recomendaciones que sigue al análisis.
Imagínese si durante el Sprint el desarrollador A está trabajando en la Tarea 1, que depende de la finalización de la Tarea 2. La Tarea 2 es parte del mismo Sprint. Entonces, en tal caso, básicamente hemos reducido la cantidad de tareas paralelas en el Sprint... [¿Debería] dejar que [la tarea] esté en el Sprint, hasta que comience el próximo Sprint?
Su pregunta, cuando se toma en su conjunto, expone una serie de olores de implementación del marco. Estos antipatrones incluyen:
También puede tener elementos de la cartera de productos que no cumplan con los criterios de INVEST .
En cualquier caso, al centrarse en la velocidad como una medida de lo bien que lo está haciendo el equipo de desarrollo, ha creado un problema X/Y en el que la capacidad del equipo para completar los puntos de la historia trabajando en paralelo se ha vuelto más importante que ofrecer un resultado cohesivo y coherente. objetivo orientado a características.
Asegúrese de que cada Sprint tenga un Sprint Goal global. Esto es en realidad un requisito del marco. La Guía Scrum dice:
El Sprint Goal es un objetivo establecido para el Sprint que se puede cumplir mediante la implementación de Product Backlog. Brinda orientación al Equipo de desarrollo sobre por qué está construyendo el Incremento. Se crea durante la reunión de Planificación de Sprint. El Sprint Goal le da al Equipo de Desarrollo cierta flexibilidad con respecto a la funcionalidad implementada dentro del Sprint. Los elementos del Product Backlog seleccionados ofrecen una función coherente, que puede ser el Sprint Goal. El Sprint Goal puede ser cualquier otra coherencia que haga que el Equipo de Desarrollo trabaje en conjunto en lugar de en iniciativas separadas.
A medida que el Equipo de Desarrollo trabaja, tiene en mente el Sprint Goal. Para satisfacer el Sprint Goal, implementa la funcionalidad y la tecnología. Si el trabajo resulta ser diferente de lo que esperaba el equipo de desarrollo, colaboran con el propietario del producto para negociar el alcance del Sprint Backlog dentro del Sprint.
Un Sprint que cumple con el Sprint Goal es un éxito, ya sea que se completen o no todas las historias y tareas programadas para el Sprint. Del mismo modo, un Sprint que no cumple con su Sprint Goal ha fallado, independientemente de si todas las historias y tareas se completaron o no según la Definición de Listo. Entonces, la única medida real del éxito de un Sprint es la finalización del Sprint Goal; el resto son solo métricas de asesoramiento.
¡Un equipo Scrum debe autoorganizarse, y la reunión de planificación de Sprint, el standup diario y otras reuniones ad hoc están ahí para permitir que el equipo administre las dependencias! Si el Scrum Master está definiendo dependencias y repartiendo el trabajo, eso es una violación de los valores y principios fundamentales de Scrum.
En su lugar, el equipo debe centrarse en cumplir el Sprint Goal. A menudo, esto se hace limitando el trabajo en curso, en lugar de crear tareas paralelas. Esto ayuda a garantizar que las historias se prioricen para el Sprint Goal y que todo el equipo trabaje en conjunto para llevar cada historia a la Definición de Listo lo más rápido posible. Dado que un elemento de la cartera de productos (por ejemplo, una historia de usuario) está terminado o no, no hay ningún beneficio para el equipo al completar las tareas en paralelo en lugar de pulular sobre las historias para terminarlas.
La Guía Scrum también dice:
- No se realizan cambios que puedan poner en peligro el Sprint Goal;
- Los objetivos de calidad no disminuyen; y,
- El alcance puede aclararse y renegociarse entre el propietario del producto y el equipo de desarrollo a medida que se aprende más.
Por lo tanto, no se permite sacar tareas o historias fuera del alcance sin la aprobación del propietario del producto, pero se pueden negociar cambios que aún cumplan con el Sprint Goal. Si las dependencias no se pueden afinar dentro de las pautas del marco, entonces el propietario del producto puede cancelar el Sprint y devolver el equipo a Sprint Planning .
La velocidad es una medida de la capacidad del equipo , no de la productividad. Por lo general, se usa para limitar la cantidad de trabajo que el equipo de desarrollo realiza en cada sprint durante la planificación del sprint. Como tal, las caídas en la velocidad a menudo identifican cuando las historias no se descomponen lo suficiente durante las reuniones de planificación, cuando violan los criterios de INVEST o cuando hay otros problemas de proceso involucrados.
Como corolario, una sola historia de usuario y sus tareas componentes nunca deben ser más grandes que un solo Sprint. Una de las razones es que tales historias son en realidad épicas que carecen de suficiente descomposición para ser estimadas con precisión. Otra razón es que todo el trabajo que está incompleto al final de un Sprint debe volver a colocarse en la Lista de pendientes del producto para que el Propietario del producto lo priorice, y luego se vuelva a estimar y planificar para un Sprint futuro (si sigue siendo relevante).
La guía aquí es dejar de centrarse en el esfuerzo invertido y, en su lugar, centrarse en las características entregadas. En marcos ágiles, un incremento de trabajo es la medida principal del éxito. Si lo está midiendo de otra manera, está violando los principios básicos del marco y es posible que deba volver a educar a su Equipo Scrum o a la alta gerencia sobre los principios fundamentales del marco.
Todd A. Jacobs