Esta breve historia estará dedicada a cómo no caer en la trampa del control imaginario sobre el proceso de estimación de tareas para el próximo sprint. Debo decir de inmediato que los datos presentados a continuación son solo indicativos y los comentarios sobre la no utilización de los números de Fibonacci con el propósito de estimar aquí serán superfluos.
Nuestro equipo estaba formado por un analista, probador, diseñador y 2 desarrolladores, sin embargo, para mayor claridad, dejamos solo a los desarrolladores.
Comenzamos un nuevo sprint y procedemos sin problemas a la evaluación de las historias de los usuarios. Nada nuevo Adelante ...
La planificación se completa y los resultados se pueden ver arriba. Tomaron 3 historias de usuarios valoradas en 16, 20 y 37 puntos de historia, respectivamente. Total - 73.
Además, como cualquier equipo de desarrollo respetuoso que adora todas las delicias de trabajar en Scrum, agregamos estas calificaciones a Jira. Al mismo tiempo, presentamos solo estimaciones generales (o promedio, ¡incluso peor!) Para cada historia.
Dos semanas de trabajo sin quitar las manos del teclado y sin levantarse de la silla de oficina que ha sido tan querida durante años, puede contemplar la funcionalidad recién creada.
¿Pero cuál es el problema? El sprint ha terminado y vemos que el frente hizo todo como estaba planeado y no tendría tiempo para presionar una sola tecla, y la parte posterior fue más allá del sprint e hizo más tareas de las planificadas.
Y luego Scrum y XP del Trenches PM, que acaba de terminar de leer, aparece y dice: “¡¡Todo está claro !!! ¡Tendremos que llevar más puntos de construcción al próximo sprint y luego todo estará bien y ya no se me escapará ningún respaldo, llevándome con ellos!
Estamos planeando un nuevo sprint ...
Genial Tomó 10 storipoints más! ¡Ahora hemos calculado todo con seguridad!
Otras 2 semanas pasan volando rápidamente y es hora de hacer un balance.
Pero para pesar de todos, el sprint terminó de una manera completamente diferente de lo que nos gustaría.
Por alguna razón, la parte posterior nuevamente se adelantó, y el frente no tuvo tiempo de hacer lo que planearon (la posibilidad de que el frente sea solo un junio sin experiencia, y bajemos la parte posterior intocable de la tercera edad e imaginemos que se trata de una planificación incorrecta).
¡Otro sprint fue un fracaso! ¿Pero por qué, tomamos un poco más de storypots y eso, solo para buenos propósitos, para dar la cantidad de trabajo necesaria para el lado del servidor?
¿Cómo puede ser esto? La respuesta tiene que ver con el sistema de evaluación en sí. De vuelta a nuestros sprints.
Que vemos Resulta que tomando más puntos de tormenta en el nuevo sprint para cargar la parte posterior, simplemente cargamos la parte delantera.
Habiendo entendido esto, el primer pensamiento en la loca cabeza del primer ministro es descubrir cuántos puntos de la historia tomó el frente sobre sí mismo y cuánto respaldo. Pero mirar la calificación general en Jira simplemente no es posible, porque todo lo que puedes encontrar es la calificación general (bien o promedio) para cada historia, y recuerda quién da qué calificación ya no es posible.
Y luego la solución viene sola. Para regular con éxito la carga del equipo, es necesario mantener no solo un registro general en los puntos históricos, sino también un registro separado en el contexto de la carga en la parte delantera y trasera. Esto le permitirá encontrar la cantidad óptima de trabajo para cada área y confiar en ella para llenar el retraso del sprint. Hasta ahora, este enfoque no puede implementarse en Jira sin notas separadas en MS Excel, pero esto no significa que no deba usarse.
Estoy seguro de que los desarrolladores de Atlassian encontrarán una solución a este problema, pero por ahora, ¡simplemente no repitan nuestros errores!
PD Estas conclusiones son aplicables solo para el desarrollo de aplicaciones cliente-servidor, donde hay una clara separación de trabajo en el frente y el backend. Tal problema no debería surgir en el equipo de desarrolladores de Full-Stack, que inmediatamente evalúan el trabajo en dos direcciones.