Subtarea temprana al comienzo de cada sprint

Me uní a un nuevo equipo que está usando Agile / Scrum, y su proceso de desarrollo es el siguiente:

1) los desarrolladores revisan cada historia antes de cada sprint para asegurarse de que no se pierda nada crítico. Hay un estado formal para eso en el flujo de trabajo.

2) durante el inicio del Sprint, todo el equipo realiza una estimación (planificación del póker) sobre cuántos puntos de historia costaría cada historia.

3) finalmente, inmediatamente después de que comience cada sprint, se requiere que cada desarrollador desglose ansiosamente todas las historias asignadas en subtareas con estimaciones de tiempo (en lugar de subtareas antes de comenzar cada historia).

El argumento principal para el último paso es que ayuda a descubrir si la implementación de una historia tomaría más tiempo de lo anticipado y advierte a scrum master sobre los riesgos potenciales de los plazos de sprint faltantes.

Sin embargo, esto me parece contraproducente, principalmente debido a las siguientes razones:

• Si el objetivo es proporcionar una estimación aproximada, los puntos de la historia (paso 2) es lo que hace el trabajo. De lo contrario, ¿por qué molestarse con los puntos de la historia? - solo haga subtareas desde el principio.
• Si el objetivo es proporcionar estimaciones precisas, este es un claro ejemplo de lo que se describe en Interruptores de tareas humanas considerados perjudiciales . Este, creo, es especialmente el caso de los desarrolladores nuevos que se unen a equipos existentes en grandes proyectos donde comprender lo que hay que hacer puede llevar hasta el 50% del tiempo. Se requiere que entre en detalles de la historia # 1, luego la historia # 2, # 3, etc., etc.

También me dicen que tal práctica es "por el libro" y ni siquiera estoy destinado a discutir esto. ¿Alguien puede proporcionar una referencia a dicha práctica, si esto está claramente definido en las biblias de Scrum y / o tal vez proporcionar alguna información adicional?

Esto no es diferente a cómo ejecutamos algunos de nuestros procesos scrum. Nosotros

1. Estimar historias cerca de la parte superior de la cartera de pedidos en "puntos de historia"
2. Seleccionar / explicar historias basadas en los puntos de la historia que creemos que "compensarán" el sprint
3. Desglosar las historias en tareas técnicas más detalladas.
4. Estime las tareas técnicas y compárelas con la estimación original de los puntos de la historia (sabemos aproximadamente a cuánto tiempo de desarrollo equivale normalmente un punto de la historia)

¡Pero lo que quieres saber es por qué estimamos dos veces!

• Hacemos una estimación aproximada (basada en la historia) porque nos gusta poder hacer predicciones sobre lo que podría ser en el próximo sprint, y tal vez incluso el siguiente. En última instancia, la gerencia debe poder comunicarse con el cliente acerca de las escalas de tiempo probables, por lo que si no tenemos esta estimación de escala gruesa, la planificación a largo plazo es prácticamente imposible.
• Obviamente, esto significa que hacemos estimaciones aproximadas para algo más que el sprint actual. Debido a que no hay garantía de que el orden de la cartera de pedidos no cambiará para el próximo sprint, no queremos invertir el tiempo en hacer desgloses de tareas y estimaciones a pequeña escala hasta que sean necesarias.
• Desglosamos la tarea para asegurarnos de que todas las tareas se hayan enumerado y que las historias se puedan trabajar en paralelo más fácilmente.
• Hacemos estimaciones a escala fina (basadas en la tarea) porque esto nos da un gráfico de quemado mucho más uniforme (particularmente donde no hay una manera fácil de separar una gran historia en "características" viables).
• Debido a que hacemos ambas cosas, actúan como controles de cordura entre sí, una discrepancia salvaje indica que necesitamos un error en algún lugar que necesitamos identificar. Este es un subproducto útil, pero no es la razón en sí misma por la que estimamos "dos veces".

Al releer su pregunta y comentario, veo que hay algunas diferencias entre nuestro flujo de trabajo y el suyo.

• Hacemos desgloses como equipo , encontramos que aunque la sobrecarga es mayor, la discusión técnica que obtenemos de esto a menudo es muy valiosa y puede detectar deficiencias en nuestra historia. Cuando tenemos disparidad de experiencia, conocimiento o habilidad, esta discusión también es donde aquellos con más pueden ayudar a aquellos con menos (muy útil con los nuevos empleados).
• Hacemos estimaciones a nivel de tarea como equipo , una de las razones por las que funciona la "planificación del póker" se debe al fenómeno de "sabiduría de las multitudes". , por lo que la sobrecarga es insignificante.

Parece que la razón por la cual su equipo realiza desgloses de tareas y estimaciones de tareas es para un quemado sin problemas, lo cual está bien, eso es parte de monitorear el progreso del sprint y permitir que su scrum-master detecte y resuelva problemas temprano. Si desea que esta información que tienen que hacer las averías y las estimaciones y que tienen que ver ellos primero.

En mi opinión, el cambio de tareas no es probable que sea un problema para usted aquí, no creo que desglosar diferentes tareas sea realmente un cambio de tarea en el mismo sentido que pasar de desarrollar una función a otra a mitad de camino es un cambio de tarea . Creo que obtener una comprensión de la "arquitectura" general del sprint es probablemente algo muy útil.

Sin embargo, creo que puede haber otros problemas que podría considerar. Como siempre con ágil, debe identificar un problema que tenga y proponer una solución , luego decidir si su solución funcionó en retrospectiva . Este es el quid de la construcción de una solución ágil que funcione para su empresa y su equipo. Entonces, algunos problemas que puede tener:

• Estás haciendo desgloses individualmente, entonces, ¿cómo están aprendiendo los miembros de tu equipo junior / inexperto de los miembros de tu equipo senior? Claro, probablemente puedan aprender todo por sí mismos, pero aprenderán más rápido si reciben orientación. ¿Los miembros del equipo junior tardan mucho en desglosar las cosas? ¿Están cometiendo errores o faltan cosas que le cuestan tiempo al equipo a largo plazo? Desglosar como equipo puede ayudar aquí.
• Estás haciendo estimaciones individualmente; lo mismo se aplica al primer punto, pero además, ¿son estas estimaciones menos precisas de lo que podrían ser?
• Parece que las tareas se asignan al comienzo del sprint, pero si este es el caso, ¿qué tan costoso es encontrarlo cuando tiene que cambiar la asignación? Si alguien se está quedando atrás o está enfermo, ¿qué tan fácil es para otra persona retomar sus tareas? ¿Tienen que pasar por los desgloses de tareas e intentar comprenderlos sin interrumpir al cesionario original? Si se desglosa y calcula en equipo, ¡todos deberían poder trabajar en todo!
• ¿Tus historias son demasiado grandes? Si el desglose toma el 50% del tiempo, las historias parecen estar muy involucradas, ¿tal vez pueden hacerse más pequeñas? Mantenemos nuestras historias dentro de 1 semana hombre de trabajo.
• ¿Son tus tareas demasiado pequeñas? Si pasa mucho tiempo haciendo listas de tareas, ¿tal vez está entrando en demasiados detalles? Tendemos a realizar tareas de entre 1 y 8 horas hombre de trabajo, de modo que en el transcurso de un día todos progresen para informar en la próxima parada diaria.

Si así es como su empresa quiere ejecutar su desarrollo y ha cerrado la discusión, sus opciones son limitadas, o al menos corre el riesgo de molestar a las personas.

Dado que el objetivo final de Agile es trabajar con un software de valor, puede intentar ofrecer ayuda midiendo la capacidad de su equipo para entregar (puntos entregados / estimados, errores en el sprint, número de pruebas, cobertura de código, tiempo de actividad, ventas generadas) lo que sea). Esté preparado para todos los resultados; puede ser que esta forma de trabajar funcione para ellos, incluso si no tiene sentido para usted. Si tiene razón, el desperdicio se hará evidente.

Tenga cuidado con el siguiente proceso por el bien del proceso: esto desperdicia tiempo y aún entrega productos pobres. Un buen equipo ágil experimenta, mide y aprende. La mejor manera de cambiar el comportamiento sin descender a la opinión es con decisiones basadas en evidencia.

Esta es también mi opinión. Le sugiero que pruebe por sí mismo y mida el resultado: vea lo que hice allí :)

Supongo que su Sprint Kickoff significa la reunión de planificación de Sprint. Creo que su Scrum Master malinterpretó cómo debería ser esta reunión. Usted no solo decide qué historias desarrollar, sino que también las prueba a su equipo según su definición de listas para asegurarse de que no se pierdan nada (generalmente usando INVEST ), y también subdivide esas historias en tareas. Para citar a Mike Cohn (uno de los fundadores de la Alianza Scrum);

La acumulación de sprint es la otra salida de la planificación de sprint. Una reserva de Sprint es una lista de los elementos de la cartera de productos que el equipo se compromete a entregar más la lista de tareas necesarias para entregar esos elementos de la cartera de productos. Cada tarea en el backlog de sprint también se suele estimar.

Entonces, desglosar historias y estimarlas es parte de la sesión de Planificación de Sprint; no después de que la sesión de planificación haya terminado y no individualmente.

Para proporcionar más información, nuestro flujo de trabajo durante la reunión de planificación de Sprint es el siguiente:

1. tomamos una historia desde la parte superior de la cartera de pedidos del producto y la dividimos en tareas. Como regla general, una tarea generalmente debería ser más pequeña que un día.

2. Estimamos la historia dadas las tareas que hemos deducido. Si la historia resulta grande, tratamos de dividir la historia en historias más pequeñas.

3. Enjuague y repita hasta llegar al total de puntos estimados

Al contrario de lo que dice Cohn, descubrí que no hay una necesidad real de estimar cada una de las tareas por separado, ya que se especifica que las tareas son más pequeñas que un día. Dado que las tareas son más pequeñas que un día de trabajo, puede notar fácilmente durante la Parada diaria cuando una tarea lleva más tiempo de lo esperado, ya que la persona que trabaja en la tarea específica dirá que todavía está trabajando en ella.

Durante el sprint, el equipo se abre paso a través de las historias y, al final, el equipo debe reflexionar sobre cuánto se hizo realmente. Para eso es la reunión retrospectiva de scrum. Si todavía hay historias sobre la mesa, puede deducir que su estimación fue demasiado optimista y actuar en consecuencia para el próximo sprint. Alternativamente, podrían haber ocurrido ciertos incidentes que afecten cuánto hizo, etc. Verá que las estimaciones mejoran con el tiempo cuando reflexiona sobre ellas.

"por el libro" - ese es tu problema. Te estás ahogando en más proceso del que hubieras tenido si estuvieras trabajando en cascadas.

No hay un 'libro' para Agile, solo existe el manifiesto ágil que dice "hacer cosas sin todos los gastos generales". Entonces, si está estimando tamaños y luego divide las historias en tareas para volver a estimarlas, entonces ese es un proceso innecesario que debe hacerse más eficiente: de esto se trata ágil. Scrum y todos los demás son realmente pautas de puntos de partida sobre cómo comenzar a hacer ágil. Mientras lo hace, debe identificar estos puntos que no tienen sentido o que no ayudan a su equipo a trabajar de manera más efectiva, y debe cambiarlos.

Sin embargo, algunas personas piensan que las formas de trabajo prohibidas deben escribirse en piedra y nunca desviarse de ellas, sin importar cuán estúpidas se vuelvan. Intentaría dividir las historias en tareas antes de la reunión de scrum: usted dice que los desarrolladores deben revisar cada historia, bueno, esta es la oportunidad de dividir al mismo tiempo como parte de la revisión. Luego puede declarar las tareas que componen la historia en la reunión de scrum (¡no les asigne tiempo!) Y dejar que las personas decidan qué tan grande es el paquete de trabajo de la historia, en función de esta información adicional contenida (que nunca es algo malo, la toma de decisiones informada es mucho mejor que las conjeturas, y solo se puede hacer cuando se tiene información para alimentar la toma de decisiones).

Después de la reunión, aún puede asignar tiempos a las tareas (aunque no veo el punto de esto, los sprints no se basan en el tiempo, sino en "cuánto espera hacer", que se mide en puntos de la historia , no el tiempo. Este es un problema común con scrum, los puntos no significan tiempo, pero hay que completar, digamos, 20 puntos por quincena, por lo tanto, 2 puntos = 1 día de trabajo. Se supone que es una suposición rápida de cuántas tareas poner en el sprint para que no estés sobrecargado ni con poco trabajo, no cuántos realmente se harán. Los mejores sprints son aquellos que tienen un par de tareas sobrantes, lo que muestra que estimaste perfectamente. retrasó completarlos al final, ninguno de los dos es productivo).

En resumen, imprima una copia del Manifiesto Ágil y la versión anti-ágil . Apuesto a que estás haciendo más anti que ágil. Scrum tiende a ser así. La única forma de solucionarlo es interactuar con su equipo y obtener la aceptación del cambio. No dejes que la gerencia te diga cómo va a trabajar tu equipo, eso tampoco es ágil, y eso estará escrito en The Book.

En algún momento durante cada Sprint, debe tener una reunión de refinamiento de la cartera de productos . En esta reunión, se asegura de que la parte superior de la Cartera de pedidos del producto se desglosa lo suficiente como para que los elementos de esa porción se agreguen a la siguiente Pila de Sprint.

Si el refinamiento de la cartera de productos se gestiona bien, la reunión de planificación de Sprint puede ser más eficiente. Idealmente, esto evitaría la necesidad de que los desarrolladores "rompan con entusiasmo" las historias después de que comience Sprint.

Si se agregan elementos de la Lista de reserva del producto a la Lista de reserva de Sprint antes de desglosarse lo suficiente como para realizar una estimación realista, será difícil tomar buenas decisiones sobre qué agregar al Sprint.