¿Cuál es el flujo de trabajo de errores en su equipo ágil / Scrum?

9

Aquí está el nuestro: - Si el error está relacionado con una historia en el sprint actual, lo arreglamos. - Si el error no está relacionado con una historia en el sprint actual y no es crítico, se envía al propietario del producto para su priorización. - Si el error no está relacionado con una historia en el sprint y es crítico, lo solucionamos.

— usuario11347
fuente

Buena pregunta, pero la ampliaría para preguntar también qué pasa con el proceso que funciona bien y qué no ... ¿Qué cambiarían?

— Walter

¿Quién informa sobre estos errores: desarrolladores o control de calidad? ¿Cuándo lanzas el código al control de calidad, al final de un sprint o durante el mismo? Si este último responde a ambas preguntas, entonces obtendrá predominantemente errores relacionados con historias que se hicieron en el sprint anterior, creo, y si no, no. La distribución que tenga podría colorear su proceso de error.

— Tom Anderson

7

Todo lo relacionado con el trabajo en el sprint actual es fijo, ni siquiera los consideramos errores y no los escribimos como tales. Solo consideramos que algo es un error si es parte de algo que ya consideramos Hecho.

Cuando surge un nuevo error, lo agregamos al trabajo atrasado y nuestros grupos de interés lo priorizan. Si tenemos tiempo restante en un sprint, tendemos a abordar errores más fáciles que pueden tener menor prioridad, pero que es algo que podemos completar en el tiempo restante.

— Jason
fuente

2

¿Cómo se rastrea que existe el error? Digamos que la persona A encuentra el error y la persona B corrige el error. ¿No pones algo en el tablero de tareas?

— user11347

2

Siempre pensé que un error es solo una historia que ya tiene una prueba fallida, por lo tanto, está mejor definida que el primer borrador típico de historias para características.

Entonces, si está convencido de que los errores son historias, las trata como lo haría con otras historias en lo que respecta a estimaciones y prioridades.

— Tom Willis
fuente

"un error es solo una historia que ya tiene una prueba fallida", ¡eso es genial!

— ianmayo

2

Creo que la mejor manera de abordar esto es determinar qué es lo que realmente desea considerar un error primero.

Muchos desarrolladores no considerarán que algo que no funciona como está previsto actualmente no es un error, porque honestamente no es un error. Si actualmente está trabajando en algo y todavía tiene defectos, entonces el error específico no está completo, por lo que no hay un defecto real. Lo inverso se aplica al trabajo completado, si ha determinado que algo está completo y listo para la prueba / lanzamiento / producción y luego encuentra un defecto en el código o uso, entonces definitivamente tiene un error.

Mi empresa utiliza la siguiente metodología para determinar cuándo se debe corregir un error:

Si el error es crítico, se agrega al sprint actual relacionado con ese producto, con la prioridad adecuada. Por lo general, planeamos en aproximadamente un 10% de tiempo extra para permitir esto en un sprint, así como también tener las cosas adicionales que realmente no planeamos completar, pero si no tenemos errores o algo se completó más rápido de lo que esperábamos, entonces podemos completar.

Si un error no es crítico, simplemente lo agregamos al trabajo atrasado y normalmente lo completamos en el próximo sprint.

Por qué este es el flujo ideal, hay una filtración obvia, y a veces las cosas que no son 'críticas' desde una perspectiva de programación pueden necesitar completarse de inmediato si la gerencia decide que debe completarse antes de lo que pensamos que debería ser. terminado.

Por otro lado, creo que lo mejor que puedes hacer es elegir una estructura y luego quedarte con ella. Algunas de las mayores pérdidas para la productividad comienzan a ocurrir cuando comienzas a hacer cosas sin estructura. Una vez que comienzas a degradar tu estructura, es muy fácil que vaya cuesta abajo.

Eso puede haber respondido demasiado a su pregunta, pero esos son solo mis pensamientos sobre cómo se deben manejar estas cosas.

— msarchet
fuente

1

Hacemos trabajo de defectos en curso. Similar a su configuración, si hay un problema crítico relacionado con el trabajo actual, lo arreglamos como parte del trabajo. Después de todo, no puedo llamar a una historia "hecha" si hay un defecto relacionado con ella.

Para otros errores, generalmente los corregimos según lo permita el tiempo. Si hay problemas urgentes, retiramos algunas historias y dedicamos tiempo a la corrección de errores antes de volver al trabajo normal de las funciones.

— Adam Lear
fuente

1

Los errores encontrados durante el Sprint son solo parte del desarrollo.

Los errores encontrados después del final del Sprint entran en el Backlog del producto. Nunca discutimos con los usuarios si algo es un error o una mejora o un cambio. Si el usuario quiere llamarlo un error, entonces está bien, pero aún entra en el PB como cualquier otro trabajo nuevo.

— Dave
fuente