¿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.

¿1 punto de historia = 1 día ideal?

En charlas, foros y otros ambientes de discusión, hay debates sobre la unidad a utilizar para estimar el tamaño de las historias de usuario. XP, eXtreme Programming, por ejemplo, utiliza el punto de historia, y lo define como la cantidad de trabajo que se realiza en un día: 1 punto = 1 día ideal.

Realmente la unidad que se utilice es irrelevante. Lo que importa es que el equipo la conozca y la tenga interiorizada, signifique lo mismo para todos y que todo miembro sepa estimar con esa misma unidad.

Usar el tiempo, en el caso de XP los días, también es tema de debate, ya que en los proyectos medimos tamaño en unidad de tiempo, usualmente en horas/hombre o días/hombre. Algún comercial o jefe de proyecto podría, o bien de forma inconsciente o bien caer en la tentación de hacerlo conscientemente, condicionar al equipo en la estimación de las tareas. Cuantas veces nos han dicho al estimar "el proyecto han de ser tantas horas aproximadamente, por encima de eso el cliente no lo aceptará....". Por otro lado solemos caer en considerar la medida de trabajo "tiempo ideal" equivalente a la medida de tiempo real o duración, no es fácil entender que por ejemplo 4 horas de tiempo ideal se han realizado en 6 horas reales, aunque eso pueda ser una muy buena productividad.

Página de login, algo común a muchas aplicaciones

Lo ideal es que cada equipo defina el punto de historia como algo que le sea representativo, cualquier elemento con el que el equipo se sienta cómodo es válido; por ejemplo en pantallas maestro-detalle, en listados de 10 columnas y totales, páginas de login... Toda aplicación suele tener una página de login, por tanto es un buen referente común de los equipos para una unidad de tamaño. He trabajado con un cliente con una buena experiencia en que un punto de historia de partida fue media jornada y que consideró la jornada de 6 horas en tiempo ideal, por tanto razonablemente realizable en 8 horas reales.

Una vez hayamos empezado a rodar el punto de historia toma su significado, y probablemente no represente ese tiempo ideal con el que el equipo ha comenzado. Es momento de desacoplar, no mirar atrás, permitir que el sistema recalibre el punto de historia a lo que le llevado la mejora continua del marco de Scrum.

¿En qué poder apoyarse para registrar la evolución de los sprints de un proyecto?

Evolución de un sprint en forma de gif animado

Por diversos motivos puede ser interesante registrar como van evolucionando los sprints, ya sea por trazabilidad o por necesidad de reporting a una oficina de proyectos o directamente a la gerencia, como podría ser en caso de empresas de pequeña envergadura.

Tradicionalmente cogeríamos nuestros inventarios de tareas, con la situación diaria de las mismas, y las pondríamos sobre la mesa para responder a las peticiones y preguntas que nos harían. En el marco de Scrum podríamos pensar en el diagrama burndown, pero este es una representación gráfica de la evolución del trabajo dentro de un sprint dado, da información pero no de la evolución completa, puede ser útil, pero sería parcial.

Una solución simple y fácil de implementar es tomar una foto del tablero Kanban con una cámara digital todos los días. Quien tenga interés en la trazabilidad o analizar la evolución de los sprints tiene así una excelente fuente de información visual y diaria. Reportaríamos en base a una serie de fotografías que mostrarían la situación día a día.

Evolución de un sprint con fotografías periódicas

¿Si Kanban es para incremento continuo, quiere esto decir que no debe usarse Kanban cuando se aplica Scrum con incremento por sprints?

En ambos marcos ágiles, Scrum y Kanban, se utilizan tableros. Aunque existe el término de tablero Scrum o scrumboard, usualmente se habla en ambos casos de tableros Kanban, lo que puede llevar a confusión. Lo importante es que en ambos casos se usan tableros como gestión visual para irradiar la información sobre lo que haya en marcha, así como para visualizar el flujo o la evolución del sprint.

En el caso de Scrum, caso iterativo, el tablero contiene todas las tareas del sprint, y durante el mismo progresan de columna de la pila de sprint a la columna de terminado. Con un vistazo al tablero se ve la situación global del sprint, tablero que suele incluir el gráfico burndown, que es propio de Scrum.

El caso de Kanban es distinto, se trata de incremento continuo. Continuamente entran elementos en la columna de tareas pendientes. En este caso la función principal del tablero es la de regular el flujo de trabajo. Eso se traduce en hacer que los elementos, tal como entren, se ejecuten lo antes posible, y progresen a la columna de terminado de la forma más optima posible, evitando cuellos de botella y tiempos de espera. Esta regulación se consigue ajustando el WIP (Work in Progress) de alguna o todas las columna del tablero. El WIP indica cuantos elementos pueden estar en una columna determinada a la vez. El ajuste del WIP dependerá de las formas de hacer cada empresa y puede requerir algunos meses de rodaje.

Ejemplo de tablero Kanban para desarrollo continuo con TDD - cortesía de Scrum Manager

La gran diferencia es la regulación, Kanban regula para que los elementos fluyan como en una balsa de aceite, mientras que en Scrum, representa la situación actual del sprint.

Para profundizar más en el tema recomiendo la lectura de "Kanban y Scrum - obteniendo lo mejor de ambos" de Henrik Kniberg & Mattias Skarin.

¿Pero cual es la diferencia a grandes rasgos entre metodología tradicional y ágil?

Para los que se interesan por primera vez por Scrum, que hayan navegado un poco por internet y que hayan decidido apuntarse al curso de ScrumManager, y para los que el concepto de Agilidad aún les es confuso, he preparado esta analogía que ayuda a aclarar los conceptos que hay detrás. Como se suele decir, más vale una imagen que mil palabras.

Todos hemos jugado con puzzles y legos, y todos hemos experimentado que son dos formas muy distintas de construir. En el caso del puzzle la imagen está totalmente definida, se sabe de antemano que se obtendrá, como el puente de la foto del ejemplo a la izquierda y cuya construcción se basa en colocar las piezas de forma que todas encajen. En el caso del legos solemos empezar por una construcción inicial, como una casa, y luego añadimos otras casas, vías, coches... y poco a poco se alza ante nosotros una ciudad, que no hemos diseñado de entrada, pero que es reflejo de La Ciudad que nos gusta.

Puzzle - Metodología tradicional

Las metodologías tradicionales, predictivas, son análogas al puzzle. El producto final está definido al 100% desde el principio, y el proyecto trata de construir la imagen a través de las piezas haciendo que encajen todas ellas y buscando la forma más optimizada de hacerlo. Es interesante observar que si introducimos una variación en el puzzle, buena parte del mismo se desmonta, y es muy costoso volver a construir piezas que encajen perfectamente dentro de este marco tan rígido. En los proyectos con metodologías tradicionales esto pasa de forma análoga, un cambio o una buena idea a mitad de proyecto puede convertirse en una pesadilla.

Lego - Método ágil

Los métodos ágiles, evolutivos, son análogos al lego. La construcción de la ciudad es incremental, un crecimiento evolutivo, empezamos por aquella casa o edificio que más nos gusta y por tanto más valor tiene para nosotros, aquel que es representativo de lo que queremos construir. Luego poco a poco vamos añadiendo aquí y allá, según lo que nos motive. Y si una casa no nos gusta, la cambiamos o desmontamos en el mismo momento, en el que se produce el cambio. No es costoso porque el conjunto no está acabado y si se introduce una modificación es sobre algo de lo que no tenemos una imagen final, por tanto simplemente modificamos y construimos hacia lo que realmente queremos. En los proyectos ágiles pasa de forma análoga, construimos por incrementos, y, sin saber de antemano cómo será el producto final, revisamos al final de cada iteración, y nos adaptamos para seguir construyendo por ahí donde marca el mercado, por ahí donde le damos más valor al producto.

Como curiosidad mencionar, que si preguntáis a la gente que os rodea, os daréis cuenta de que generalmente preferimos uno u otro juego antes que el otro, podríamos decir que somos puzzleistas o legolistas. :-)