A menudo oímos la pregunta – En Kanban, ¿qué debemos hacer si una historia de usuario en la columna de pruebas se encuentra con un error que necesita ser arreglado? Digamos que el flujo de trabajo es algo así «Todo -> Desarrollo -> Prueba -> Liberación» si una Historia de Usuario ha completado el Desarrollo y ha pasado a Prueba, y un tester encuentra un bug, ¿qué debemos hacer con esa Historia de Usuario? ¿Es correcto dejar esa Historia de Usuario en Prueba y el desarrollador debe detener su trabajo de desarrollo actual para arreglar este Defecto primero? Si es así, ¿significa esto que los desarrolladores deben ser interrumpidos todo el tiempo para solucionar los fallos encontrados en Test? ¿Es esto mejor que mover la Historia de Usuario que tiene el defecto de vuelta a la fase de Todo o de Desarrollo?
¿Registrar o no registrar una tarjeta de defectos?
Un desarrollador trabaja en una característica – que puede ser modelada como una historia de usuario o una mejora o una solicitud de cambio – y durante su ciclo de vida de desarrollo, los problemas o errores pueden ser encontrados durante varias etapas de pruebas (unidad, sistema, integración, etc.), así como las revisiones de código – y estos problemas pueden ser capturados / reportados como defectos o errores o problemas.
Sin entrar en los procesos específicos que pueden seguir los diferentes equipos, existen a grandes rasgos dos métodos para modelar esto en un tablero Kanban que los equipos utilizan.
La primera opción es que, dependiendo de la etapa en la que se haya notificado un problema o un error, la historia de usuario se devuelve a la etapa de trabajo más temprana (diseño en curso o desarrollo en curso, por ejemplo) y se vuelve a trabajar en ella para solucionar el problema o el error. Dependiendo de la naturaleza del defecto, la historia de usuario puede retroceder hasta la «etapa de preparación» o a una etapa intermedia como la de diseño o desarrollo, etc.
En este caso, no se registran tarjetas de defectos por separado. La historia de usuario se mueve hacia atrás según sea necesario, siempre que se encuentre una incidencia o un fallo en ella.
La segunda opción es que la historia de usuario se «bloquee» dondequiera que se haya notificado el problema o el fallo, y que se cree una nueva incidencia o un fallo como tarjeta y se trabaje en la fase más temprana en la que sea necesario (incluso, tal vez, en un carril de natación completamente separado con su propio flujo de trabajo para solucionar dichos problemas o fallos). En la imagen siguiente, las tarjetas con el cuadrado rojo representan las historias de usuario bloqueadas, que están vinculadas a sus defectos asociados.
¿Seguimiento del trabajo de repaso y del coste de la calidad?
El proceso típicamente favorecido es la segunda opción, ya que tiene las siguientes ventajas –
- Destaca y visualiza claramente las Historias de Usuario, que están bloqueadas debido a los defectos que se encuentran en ellas.
- Identifica y permite específicamente la «asignación» a la «demanda de fallos», y permite el análisis de esta demanda de fallos.
- Le permite modelar un flujo de trabajo/proceso diferente para la resolución de problemas/defectos si lo desea, en una vía de acceso separada, lo que ayuda a analizar el tiempo de ciclo (tiempo de resolución), el rendimiento y otras métricas que podrían ayudarle a establecer compromisos de SLA con sus clientes.
- Si su equipo se centra en la aplicación y el seguimiento de los límites de WIP, presiona a los desarrolladores para que resuelvan y cierren los defectos abiertos contra su nombre, ya que los elementos bloqueados también ocupan su límite de WIP.
Hay que asegurarse de que los desarrolladores sigan el proceso de vincular (asociar) las Historias a sus Defectos / Cuestiones (que un software Kanban como SwiftKanban permite con bastante facilidad) y también para desbloquear la Historia de Usuario cuando el Defecto se cierra, de modo que el límite WIP del desarrollador se abre para hacer el trabajo adicional.
¿Cómo se manejan las Historias de Usuario y los Defectos en vuelo? ¿Cómo se maneja la Historia de Usuario bloqueada? ¿Considera que forma parte del WIP del desarrollador? Mientras una Historia de Usuario está bloqueada, ¿debe permitir al Desarrollador trabajar en alguna otra Historia de Usuario – o centrarse en conseguir que esta primera historia de usuario se desbloquee y vuelva a funcionar para que haya un mínimo «bloqueo del flujo»? Mientras que usted y su equipo pueden haber tenido un proceso específico antes de adoptar Kanban, ¿cambió su proceso una vez que adoptó Kanban? ¿Ha repercutido en el rendimiento de su equipo? Sería estupendo que nos compartiera sus experiencias aquí.
También hay una muy buena entrada de blog escrita por el líder de pensamiento de Kanban, el Dr. Masa Maeda, sobre un tema relacionado que también podría estar interesado en mirar – Manejo de problemas de tickets con Kanban que trata del aspecto de la planificación de cada sprint y la inclusión de tickets (impulsados por interrupciones) junto con Historias de Usuario (planificadas).
Mahesh Singh
Co-founder, Sr. VP – Marketing
