lunes, 25 de agosto de 2014

¿Cómo gestionar un bug que se ha detectado en la fase de pruebas usando un tablero Kanban con incremento continuo?

Los bugs forman parte del software
En Scrum simplemente se incorporaría el bug a la pila del producto, probablemente para tratarlo en el siguiente sprint. El caso de Kanban, gestionando incremento continuo y regulado por límites WIP, es distinto.

Dependiendo de la crititicidad del bug, este entraría en el backlog o pila de entrada del tablero, o, en caso de existir, en el carril "expedite".

La solución ideal es que bugs críticos entren en un carril de nado especial denominado "expedite", este tiene la característica de aumentar el límite WIP de todas las columnas de estado, usualmente en un +1. En cuanto un miembro del equipo queda libre se pone a trabajar en el bug, este tiene prioridad sobre las demás tareas. Adicionalmente se puede relacionar el bug con la tarea/historia/petición que lo ha puesto sobre la mesa.
Tablero Kanban con carril expedite y visualización de la petición que lo ha detectado
Si se tratara de un bug no crítico o no tuviéramos carril "expedite", este debería de entrar como tarea en la columna "in process" si el WIP de esta lo permitiese, sino en la columna de "backlog", y si el WIP de "backlog" tampoco lo permitiese consideraría aplazar la corrección del bug para más adelante, o sacar una tarea del backlog para colocar esta. Sería un error dejar el bug en "testing", no le corresponde ya, o ponerla en la columna "in process" o "backlog" cuando el WIP no lo permite, rompería el flujo de trabajo que trata de regular el tablero, estando este perfectamente regulado podrían aparecer de nuevo cuellos de botella y tiempos muertos.

No hay comentarios:

Publicar un comentario