agile - procesos - reunion sprint scrum
¿Cuenta las horas invertidas en correcciones de errores para el scrum? (5)
En cada sprint tengo dos ''tareas'': una para los errores encontrados en el sprint actual (es decir, en el código no enviado) y otra para los problemas encontrados en cualquier otra cosa (cualquier versión enviada). Esto me ayuda a mantener un registro de cuánto tiempo se pierde (por desarrollador) corrigiendo errores.
Cualquier momento en que se registre en la última categoría se considera como desperdicio y es un objetivo clave para la reducción. El tiempo registrado en el primero se revisa para ver cómo se puede vincular más estrechamente con las características y los cambios que lo causaron.
No coloque estimaciones contra errores, en su lugar intente agregar ese tiempo a las estimaciones de pruebas unitarias / funcionales en función de las funciones en las que está trabajando.
Siéntase libre de adaptar cualquier modelo para adaptarlo a su equipo: debería existir una cultura de mejora continua en cualquier equipo de Scrum, y los desarrolladores deberían ser capaces de sugerir y probar mejoras a medida que aprenden Scrum.
Hola, soy nuevo en la metodología de scrum y estoy buscando ayuda para sentirme cómodo con el entorno y preguntándome si es necesario que haya un segmento para hacer un seguimiento de los desarrolladores y las horas de control de calidad dedicadas a las implementaciones, las correcciones de errores y las nuevas pruebas. Parece que podría tener un gran impacto en el gráfico.
La forma en que tiendo a manejar esto es mover la reparación de errores fuera del sprint. Así que un sprint de tres semanas podría ir seguido de la corrección de errores de una semana antes de la demostración / lanzamiento.
No es una solución ideal, ya que no se intenta estimar el número de errores que se corregirán en la fase de reparación de errores. Así que espero que otros den una mejor solución que yo.
Mi equipo admite una serie de aplicaciones heredadas, por lo que hay una gran cantidad de errores no planificados que se producen durante cada sprint. Adoptamos la siguiente práctica:
- Si el error es fácil / rápido de solucionar (un trazador de líneas, etc.), entonces simplemente corrígelo.
- Si el error no es trivial, y no es un bloqueador, agréguelo a la lista de espera.
- Si el error es un bloqueador, agregue una tarea (al sprint actual) para capturar el trabajo requerido para repararlo y empiece a trabajar en él. Esto requiere que se mueva algo más (desde el sprint actual) a la acumulación para tener en cuenta las nuevas horas porque el total de horas disponibles no ha cambiado.
Cuando agreguemos nuevas tareas de errores, las marcaremos de forma diferente a las tareas planificadas, de modo que sean fáciles de ver durante la revisión del sprint. A veces, el trabajo no planificado termina siendo> 50% de nuestro sprint, pero debido a que estamos presionando los elementos planificados para la acumulación, sabemos muy pronto que no estamos entregando este sprint que habíamos planeado.
Esto ha demostrado ser muy útil para nuestro equipo al tratar con aplicaciones heredadas en las que ninguno de nosotros está tan familiarizado o seguro con los sistemas como nos gustaría.
Creo que es difícil estimar el esfuerzo de corregir errores antes de que hayas diagnosticado el problema, y el diagnóstico es a menudo la mayor parte del tiempo que se gasta.
Si el volumen de tu error es bastante constante, simplemente dejaría que "salga en el lavado" contra la velocidad. Esto es lo que suelo hacer por los defectos de producción que afectan los objetivos de iteración de un equipo.
Si te das cuenta de que a mitad de la iteración te estás quedando atrás (p. Ej., Ves un gráfico de quemado que no parece interseccionar con tu línea de ámbito al final de la iteración) debido a problemas de errores, entonces puedes adaptar el alcance ( abandone la historia de menor prioridad) para acomodar el trabajo extra.
Los errores descubiertos durante el sprint, que pertenecen a ese sprint, deben corregirse automáticamente como si la tarea / historia no estuviera lista para empezar. Los errores que surgen de los sprints previos podrían ingresarse en una acumulación de errores y ser priorizados al igual que el retraso acumulado normal.
EDITAR: Me acabo de dar cuenta de que al mencionar el "error acumulado" me abro a los "múltiples atrasos", lo cual es una mala idea. Una mejor manera podría ser marcar la entrada en la lista de espera con una bandera de error o simplemente aceptarla como cualquier otra historia en la acumulación.
El número de errores graves que surgen en un sprint debe ser mínimo, ya que todo se ha probado antes y se ha entregado al propietario del proyecto al final del sprint.
En realidad, no debería afectar el gráfico, ya que se comprometerá a corregir una cierta cantidad de errores (por la elección del PO - algunos errores tienen menor prioridad que la nueva funcionalidad) y cuando los errores surgen de un sprint, la tarea realmente no se hizo así que está bien darse cuenta de eso y pasar el tiempo solucionándolo.
EDITAR: Realicé algo más: a veces trabajar en un equipo de scrum no siempre te protegerá de la realidad de tener que mantener otras aplicaciones, soporte, etc. Aunque esto realmente apesta y hace que la idea de estar en un equipo con un solo backlog y el enfoque no funciona, la realidad es a menudo que necesita reservar un número fijo de horas a la semana para soporte / mantenimiento. No aliente esto, pero si esta es la realidad, intente asignar a una sola persona (en rotación (es) que no se ponga triste) cada semana un número fijo de horas dedicadas a dicho rol de apoyo. De esta manera, sabes qué esperar ya que la velocidad es relativa, de alguna manera parecerá un impacto menor en los sprints.