La cuestión de la gestión de errores en la producción ha sido una gran característica en mi mente últimamente. Los Sprint no están destinados a tener ningún elemento agregado en ellos, pero para errores críticos , esto es simplemente inevitable.
¿Cómo se maneja este descanso en el sprint? ¿Simplemente le das a un sprint un porcentaje de "asignación" de tiempo, por lo que solo llenas el 80% del cronograma con elementos de sprint "por si acaso"?
Respuestas:
Si esto es crítico , debe manejarlo.
Para medir su impacto en el sprint, debe iniciar sesión.
Mira este radiador de información:
Hay una parte llamada " Elementos no planificados ". Pon tu error crítico allí. Como puede ver, existe el inverso con la parte " Siguiente " donde coloca más historias de usuarios de las planificadas en caso de que complete el sprint más rápido.
Hablará de ello en la revisión de sprint y / o la retrospectiva . El objetivo es encontrar la forma de limitarlos y también ajustar su velocidad en consecuencia.
Si usa la velocidad como un indicador de 'asignación' basado en el clima de ayer, se ajustará automáticamente para una cantidad promedio de trabajo extra cortando en sprints.
Si el problema de producción es causado por errores creados en sprints anteriores, está bien que el trabajo de reparación se reduzca a la velocidad del sprint actual. De esta manera, la velocidad del equipo se 'compensa' por los puntos que no deberían haber ganado previamente.
A veces no logras todos tus objetivos de sprint, lo superas ;-) La velocidad promediará a un número más bajo si sucede mucho.
Cualquier otra cosa no crítica se puede incluir en la cartera de pedidos para su inclusión normal en un sprint. Prefiero dar la máxima prioridad a los errores y que no cuenten para la velocidad.
Todo el tiempo necesario para solucionar y solucionar problemas de producción se incluye automáticamente en la velocidad del equipo. Solo toma tiempo para promediar, realmente no necesita una asignación por separado.
Trabajo en un equipo que realiza principalmente trabajos de desarrollo, pero que también es responsable de los sistemas complejos existentes. También hemos tenido este problema.
Básicamente, estimamos nuestros puntos en función de los últimos sprints y luego reservamos una cantidad de puntos para el trabajo de mantenimiento esperado. En caso de que ocurra una tarea de mantenimiento que exceda esto significativamente, como una interrupción importante, la agregamos como una historia de usuario y eliminamos una existente que aún no ha comenzado, para mantener el sprint del mismo tamaño. Si aparece un problema importante que es menos urgente, lo movemos al próximo sprint.
Sí, técnicamente esto no sigue a scrum. Pero la flexibilidad nos ha funcionado bien.
Hemos refinado este tiempo reservado preguntando al equipo en cada reunión de planificación si ven alguna razón para desviarse de la reserva estándar. Introdujimos esto después de hacer un cambio de oficina que nos llevó mucho más tiempo del que anticipamos, lo que llevó a que muchas historias no se terminaran.
Sin embargo, no se limite a cómo lo hace mi equipo o cualquier otro equipo. Elige algo y simplemente hazlo. No hay forma de garantizar que funcione bien para su equipo. Probar y evaluar en la retrospectiva. Si el equipo no está contento, intente algo diferente y evalúe nuevamente. Todos los equipos son diferentes, y sus necesidades y limitaciones también son diferentes.
Si se trata de un problema de producción crítico, entonces debería poder manejarlo directamente, la metodología de desarrollo elegida es irrelevante. Una revisión no está relacionada con un ciclo de lanzamiento regular (spints o de otro tipo).
Sugeriría arreglarlo en una rama de 'arreglo', basada en el código que se encuentra actualmente en producción.