¿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 para elementos urgentes 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 carril 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.

¿Qué tiene que ver Scrum con la melé de rugby?

Jugadores en melé (foto cortesía de Peter Dean)

La melé es un término de origen francés, scrum en inglés, que representa una jugada de rugby en la que dos equipos compactos se empujan mutuamente para disputarse la posesión del balón. Los miembros de cada equipo están fuertemente compenetrados y se adaptan en conjunto, como una unidad, a la jugada.

En 1986 Hirotaka Takeuchi e Ikujiro Nonaka realizaron un estudio sobre procesos de desarrollo muy exitosos utilizados en ciertos productos en Japón. Se trataba de productos que partían de requisitos muy generales y que afrontaban equipos reducidos y multidisciplinares. El estudio comparaba la forma de trabajo de estos equipos con la colaboración entre los jugadores de rugby y su formación de scrum. Takeuchi y Nonaka lo llamaron un enfoque de "rugby", "donde un equipo intenta recorrer toda la distancia como una unidad, pasando el balón hacia atrás y adelante".

Equipo de Scrum

En 1993, usando este estudio como base, Jeff Sutherland creó el proceso Scrum para el desarrollo de software adoptando la analogía con los equipos de rugby, y finalmente trabajó con Ken Schwaber para formalizar la primera versión de Scrum en la OOPSLA'95 (Object-Oriented Programming, Systems, Languages & Applications).

Destacar también que el grupo de cada equipo para la melé de rugby ha de estar formado por un mínimo de cinco y un máximo de ocho jugadores en tres líneas, y que en Scrum se recomienda que un equipo tenga entre 3 y 9 miembros, ya que más allá de 9 resulta difícil mantener la comunicación directa, primordial para mantener la Agilidad.

¿Cómo actuar en caso de equipos que varían a lo largo de los sprints por la necesidad de adquisición y liberación de especialistas?

Especialista técnico de AS/400

Este sería el caso en que se requieran especialistas en momentos puntuales para determinadas tareas, como por ejemplo expertos en un tema muy concreto como maquetadores, analistas o técnicos de sistemas como en el caso de un técnico de AS/400 de la imagen de la derecha ;-). Esta situación suscita otras preguntas como ¿invitamos a los especialistas a la reunión de planificación del sprint? ¿Forman estos parte del equipo?...

Scrum implica un cambio de chip en todos los miembros del equipo, cambio que se puede resumir en "vamos todos a la una". Un equipo multidisciplinar es clave, debe incorporar a los especialistas que hagan falta para los diferentes aspectos del proyecto y con mentalidad colaborativa y de interés por todo lo que les rodea. Recordemos que se autogestionan, por tanto un maquetador o un experto será el especialista en su campo, pero como estos sienten que forman parte de un equipo con un objetivo único y que el producto resultante es como "un hijo suyo", no les importa hacer tareas que no son de su especialidad. Son personas tipo "T" que simplemente suman.

Scrum es una forma excelente de difundir el know-how, tanto técnico como funcional. Hay una máxima que funciona, que es "never change a winnig team", y Scrum crea justamente equipos ganadores. Entendido esto, evidentemente el equipo puede variar, un maquetador podría no hacer falta a partir del tercer sprint... aunque este es un mal ejemplo, ya que para crear un incremento que funcione, la maqueta ya es parte previa de cada incremento de producto, y el producto estará presente en todo el proyecto. Un analista hará falta siempre, ya que el producto está en constante rediseño, y un especialista posiblemente también, ya que el producto se va construyendo al mismo tiempo que se modifican y aparecen nuevos requisitos.

Es importantísimo dejar de la lado la idea de grupos de trabajo con especialistas en una tecnología y dedicados a tareas de especialista. Lo importante es el equipo, formado por especialistas, si, pero por personas con actitud de sumar al equipo y de arremangarse para lo que haga falta. Yo he hecho entrevistas a muchos candidatos, y más que buscar a personas mastersdeluniverso, para mí lo importante es una buena base técnica y "buen rollo" para integrarse al equipo. Una necesidad técnica nueva se soluciona muy fácilmente: con un curso a la persona adecuada. Construir un equipo con personas comprometidas y con la actitud adecuada es lo difícil.

A todo esto puede aparecer una tarea "atípica" e infrecuente, no habitual en el proyecto y tampoco en los proyectos de la empresa. Un buen planteamiento sería considerarla como un servicio externo, como una adquisición con un coste y una fecha de entrega que debería ser adecuada para la integración en el sprint correspondiente. En este caso la realización de la tarea es cosa del especialista, un proveedor freelance subcontratado para ese trabajo concreto.

Off-the-record mencionar que esta forma de gestionar a un especialista es la ideal para incorporar temporalmente a un gurú. Estos suelen ser tipos algo freakys y con esta manera de gestionarlo, en que estos no forman parte de equipo, se evita que resten. Es recomendable también que un miembro del equipo adquiera el conocimiento, aunque sea de forma superficial, de la solución al problema que ha requerido la intervención del especialista.