Scrum, cómo manejar errores en el sprint y cómo estimar los errores en el tiempo

Question

Estoy trabajando en un proyecto de Scrum escribiendo código de firmware en C para un ASIC.

De vez en cuando tenemos errores realmente difíciles de encontrar. Pero, ¿cómo puedo estimar estos errores?

Siempre le digo al maestro de Scrum que no tengo la competencia para estimarlos porque realmente odio la estimación del tiempo de los errores.

¿Cómo manejan esto en sus proyectos de Scrum?

Answer 1

La estimación de errores es algo realmente difícil.Si puede hacerlo, es probable que ya tenga la solución y ya no sea realmente un error :) Por lo tanto, en lugar de tratar de estimarlos uno por uno, mi opción preferida es asignar un "tiempo de corrección de errores" durante el Sprint y para corregir los errores más importantes durante ese tiempo. Esta es una estrategia de mejor esfuerzo, solo arregla la mayor cantidad posible durante el tiempo asignado.

Answer 2

¿Qué hay de estimarlos en función del tiempo promedio dedicado a solucionar errores anteriores?

Answer 3

Estúrelos en semanas en lugar de horas.

Si su Scrum-master no entiende el problema con la estimación de errores del tiempo, su proyecto probablemente se beneficie de tener un Scrum-master con al menos un conocimiento de programación menor.

Answer 4

"Es difícil hacer predicciones, especialmente sobre el futuro".

A menos que haya analizado un error y stetched una solución, no se puede estimar. Esto es como hacer una reunión de planificación de melé sin conocer la acumulación de trabajo.

Puede usar estimaciones grandes para comunicar incertidumbre. Los datos históricos tienen un valor limitado. No ayuda mucho el único error a mano, incluso cuando la distribución del esfuerzo es la misma para los nuevos errores. Además, los nuevos errores pueden ser más fáciles o más difíciles en promedio.

Answer 5

Debería ser capaz de construir un historial de cuántos puntos de historia puede completar en una semana, en base a la estimación coherente de puntos de la historia. Esto también incluirá el tiempo de reparación de errores.

Por ejemplo, sabemos que podemos completar 20 puntos de historia en una semana, de los sprints anteriores. El desarrollo de esos 20 puntos puede completarse en 2 días, sin embargo, luego hay pruebas y corrección de errores. No calculamos los errores dev, ya que cada nueva historia debería tener un estimado que incluya aproximadamente el tiempo de reparación de errores. Los insectos vivos deben investigarse antes de la estimación, entonces debería ser posible estimar con precisión.

Answer 6

Pregunté Jeff Sutherland esto, y él me dijo que en PatientKeeper tienen una estimación fija de medio día para arreglar un error. Si la naturaleza de tus errores es que pueden ser bastante predecibles, de modo que puedas encontrar un promedio aproximado, supongo que esta es una estrategia justa.

Sin embargo, en la práctica, esto no siempre me funciona. A menudo es difícil entender cuál es el error y puede llevar más tiempo analizarlo que resolverlo. Esto a menudo hace que los errores sean altamente impredecibles y difíciles de estimar. Todas las tareas que incluya en su carrera deben analizarse, y los errores a menudo requieren más análisis que otras tareas.

Lo que hemos hecho en tales casos de errores "impredecibles" es asignar un tiempo fijo para averiguar cuál es el problema. P.ej. elegimos gastar un día (o x puntos) en profundizar en el error tratando de comprenderlo, y luego planeamos abordar la solución real para el próximo sprint. Sin embargo, si no es tiempo suficiente para resolverlo, no queremos perder más tiempo en el sprint actual, y tendremos que reconsiderarlo para el próximo. En algunos casos, el error puede ser muy crítico, y usted solo tiene que vivir con una estimación incierta.

Answer 7

Podemos clasificar error en "Yo sé dónde va mal tengo que actualizarlo", "Sé que este error está relacionado con este módulo y cualquier depuración algunos de estos archivos que puedo resolverlo", "No estoy seguro de por qué ha surgido este error". Podemos estimar en los primeros 2 casos en base a nuestra experiencia en ese proyecto. Pero estimar para el último caso es muy difícil.

Answer 8

Un enfoque que ha funcionado para mí es no tener errores en el primer lugar :)

La forma en que esto funciona es que cuando se encuentra un error, fijándolo tiene prioridad sobre la aplicación historia. Las nuevas funciones solo se pueden agregar una vez que la funcionalidad existente funcione al 100%.

Por supuesto que clasificamos errores. Este enfoque de detener la cadena de producción solo se aplica a errores críticos. Los errores menos que críticos se tratan como historias de mejora de funciones, estimados y planificados en próximos sprints como cualquier otra historia.

La asignación de tiempo para la solución crítica de errores eventualmente se refleja en la velocidad de su equipo.

Answer 9

Calculamos para cada error un tiempo de análisis de 4h. También tenemos una priorización de errores. Los errores que son bloqueadores o críticos deben corregirse antes de que se implemente cualquier otro. Muchos errores para corregir resultados en historias implementadas más bajas. Pero tenemos un software tan robusto para las siguientes características.

Answer 10

Encuentro que realmente no se usa mucho para tratar de calcular errores. Solo prevenlos, búscalos, hazlos visibles (en tu tablero de tareas o lo que sea que uses), priorízalos y corrígelos. El tiempo que pases impactará la velocidad. Y es la velocidad lo que importa. La velocidad es el indicador de cuánto progreso puedes esperar en el próximo sprint (s).

Si está interesado en algunas métricas, use la cantidad de errores por sprint.

Answer 11

Hice un tipo similar de pregunta hace un tiempo y obtuve un poco de good responses.

Answer 12

El objetivo real es mitigar los riesgos asociados con errores; es decir, no dejar que se realice el cronograma. Muy a menudo, el equipo podrá identificar qué historias pueden crear los errores difíciles con anticipación. Entonces, una estrategia de mitigación es abordar esas historias primero, dando al equipo el mayor tiempo posible para enfrentar lo inesperado.

Answer 13

He escuchado la corrección de errores en comparación con la pesca. ¿Cuánto tiempo te tomará arreglar un error misterioso? ¿Cuánto tiempo tomará atrapar un pez? Puede intentar explicarlo al propietario de su producto en esos términos.

Answer 14

También puede considerar asignar un "contingente" para la reparación de errores durante el Sprint (10-20% del tiempo de confirmación) que utilizar una forma de Kanban para resolverlos. Eso significa que puede hablar con el Propietario del Producto y explicarle que los costos de reparación de errores están bajo control (ya que el contingente es su caja de tiempo) que empíricamente se ajustará en cada nueva iteración según lo que el equipo sienta que será la calidad del Producto. . El objetivo es, por supuesto, reducir el tiempo y promover la transparencia.El Propietario del Producto puede ayudar a priorizar un Bug Backlog poniendo encima los errores más valiosos, normalmente el valor de Retainment, para que la más alta prioridad sea probablemente reparada ... cuanto más alto mejor.

Trabajar con KanBan, significa que el equipo se sienta y mira el intervalo regular (después de la parada diaria es un buen momento) lo que está en la cola de errores, utiliza la experiencia de todos los miembros del equipo para averiguar dónde buscar y qué comprobar, que alguien (normalmente el emparejamiento es realmente bueno) toma el error. Cuando el contingente haya finalizado, el Equipo levantará la mano y hablará con el Propietario del Producto, quien deberá decidir si aún hay errores que deben corregirse, a costa de una historia o más, o puede esperar el próximo Sprint.

En general, la transparencia debería permitir al equipo de Scrum (incluye PO y SM) averiguar cuál es el costo de las soluciones y resolver qué hacer para equilibrar la calidad y la velocidad de entrega. Normalmente es una buena forma de establecer un diálogo con PO :-)

Answer 15

estoy totalmente de acuerdo con la respuesta de Pascal Thivent. en nuestro Sprint, generalmente seleccionaremos algunas tareas que se pueden adaptar si hay otras tareas más urgentes.

Cuando se produce un error, lo priorizamos y le damos importancia. si es de alta prioridad o gravedad, iremos a hacerlo y la tarea sin importancia en este Sprint volverá a la lista de espera.

si no hay errores o el error no es urgente, haremos todas las tareas de Sprint.

Si se han ejecutado muchos Sprints, puede haber estadísticas que muestran cuánto esfuerzo se ha gastado para corregir errores, obtener el esfuerzo promedio como punto de referencia para su próximo sprint es otra opción para usted.