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

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

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.

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.

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.

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.

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.

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.