Los problemas que surgen durante una iteración no son "bugs", y sólo el Dueño del Producto tiene el derecho a llamar a algo un "bug". Más aún, un equipo ágil sano no debería tener necesidad de usar un Bug Tracker (esas herramientas bonitas para el seguimiento de bugs). De hecho, hasta podría resultar contraproducente...
¿Qué es un bug en ágil?
La pregunta inicial sería: ¿cómo se gestionan en el tiempo los bugs en un contexto ágil? La respuesta corta es que deberían existir tan pocos bugs que no tendría sentido gestionarlos en el tiempo. Después de todo, si sólo tenemos 2 bugs, ¿cuánto tiempo vamos a gastar discutiendo sobre si arregarlos o no?
Al leer esto muchos pueden pensar: "Si claro. Obviamente no estás viviendo en el mundo real". Todos vivimos en el mundo real. De en serio. El problema, creo, radica en la definición de bug. ¿Cuándo un bug se tiene que contar como un bug?
En un contexto Ágil, definimos a un bug como un compartamiento en una historia "Terminada" que no cumple con las expectativas válidas del Dueño del Producto.
Hay mucha ambigüedad en esta oración, así que aclaremos un poco.
Comencemos con el Dueño del Producto. No todos los equipos Ágiles usan este término. Entonces, una definición de Dueño del Producto: aquella persona en la organización que es responsable de definir lo que el software tiene que hacer. Esta persona puede ser un Analista de Negocio, un Gerente de Producto, u otros.
Esta persona no está en el equipo de implementación. Si, los programadores y los testers pueden tener opiniones sobre lo que es un bug y lo que no es un bug. El equipo de implementación puede aconsejar al Dueño del Producto. Pero el Dueño del Producto es quien decide.
Esta persona tampoco es el usuario final o el cliente. Cuando el usuario final o los clientes encuentran problemas, los escuchamos. El Dueño del Producto considera sus opiniones y preferencias y necesidades. Pero es el Dueño del Producto quien decide en última instancia si el cliente encontró algo que viola alguna expectativa válida del sistema.
Todo esto es un montón de responsabilidad para el Dueño del Producto, pero es allí a donde pertenece esta responsabilidad. Definir lo que el software debería hacer y no debería hacer es una decisión de negocio, y no técnica.
Las expectativas del Dueño del Producto
Hablando de expectativas, produndicemos un poquito más acá.
Cuando el Dueño del Producto define historias, tiene expectativas sobre cómo va a verse la historia cuando esté terminada. El equipo de implementación colabora con el Dueño del Producto en articular estas expectativas en la forma de Pruebas de Aceptación o Criterios de Aceptación.
Es facil ver si el software viola alguna de estas expectativas explícitas. Sin embargo, las expectativas implícitas son más dificil. Y el Dueño del Producto también va a tener expectativas implícitas que son perfectamente válidas. No hay forma de capturar todos los detalles de cada expectativa en una Prueba de Aceptación.
Más aún, hay algunas expectativas que no pueden ser capturadas completamente. El Dueño del Producto podría decir: "Nunca deben perderse datos, ni tampoco se puede perder el trabajo del usuario", o "Nunca debe ponerse en peligro la seguridad del usuario". No es posible crear un conjunto de Pruebas de Aceptación que cubran todas las posibilidades. Así que le prestamos atención tanto a las Pruebas de Aceptación como al espíritu que las motiva a existir, y usamos Pruebas Exploratorias para buscar condiciones imprevistas en los cuales el sistema pueda fallar.
La definición de Terminado
Por última, hablemos de la "Historia Terminada". "Terminado" signifca implementado, probado, integrado, explorado, y listo para entregar o desplegar. "Terminado" no significa sólamente que algo ya está programado; "Terminado" significa completo, finalizado, listo.
Antes de declarar a una historia como "Terminada", si encontramos algo que viola las expectativas del Dueño del Producto, lo arreglamos. No discutimos sobre eso, no debatimos ni lo replanificamos, simplemente lo arreglamos. Esto es lo que significa tener cero tolerancia a los bugs. Así es como mantenemos una base de código limpia, maleable y mantenible. Así evitamos acumular deuda técnica. No toleramos las "ventanas rotas" en nuestro código. Y nos aseguramos que existan una o más pruebas automatizadas que cubran el mismo caso de manera que el problema no vuelva a aparecer. Nunca.
Y como vamos arreglando los temas a medida que los encontramos, no necesitamos ponerle un nombre a estas cosas. No necesitamos priorizarlas. No necesitamos hacer un seguimiento en un Bug Tracker. Simplemente las tratamos de forma inmediata.
Lo que es un bug, y lo que no
En este punto alguien podría preguntar, "¿Pero no necesitamos hacer un seguimiento del historia de las cosas que arreglamos? ¿No queremos tener métricas de esto? ". Y la respuesta sería "¿Para qué? Lo encontramos, lo arreglamos, y le agregamos una prueba. ¿Qué valor de negocio podría tener el mantener un registro de esto? Nuestro proceso obviamente funciona, así que analizar datos no va a generar mejoras concretas".
Si en algún momento no estamos seguros sobre si algo viola una expectativa del Dueño del Producto, le preguntamos. No inventamos, no adivinamos. Le mostramos al Dueño del Producto. El Dueño del producto va a decir alguna de estas tres cosas: "Ops, eso es un problema", o "Eso está fuera del alcance de la historia, lo voy a agregar al Backlog", o "¡Buenísimo! Está funcionando tal cual lo quería". Si el Dueño del Producto dice que es un problema, lo arreglamos.
Si el Dueño del Producto dice "Técnicamente es un bug, pero prefiero tener más características en vez de arreglar ese bug, así que hagan una nota y déjenlo para el futuro", en este caso le decimos al Dueño del Producto que esto pertence al backlog. Y le explicamos que no es un bug porque no viola su expectativa actual sobre el comportamiento del software.
Registrando bugs sólo para cubrirse
Alguien más podría decir: "Pero aunque el Dueño del Producto diga que no es un problema, ¿no deberíamos registrarlo?". En general el motivo para querer mantener un registro de lo que no arreglamos es cubrirnos las espaldas, de manera que cuando el Dueño del Producto venga y diga "¡Hey! ¿Cómo no se dieron cuenta de esto?", podamos mostrarle la base de datos de bugs y decirle "Lo encontramos y nos dijo que no lo arreglaramos. Ja, ja ja". Si un equipo Ágil necesita mantener registros para "cubrirse", entonces tiene otros problemas que ningun Bug Tracker le va a resolver.
Más aún, hay un alto costo por mantener este tipo de registros.
Muchos equipos tradicionales tienen bases de datos de bugs repletas de bugs que nunca se van a arreglar. Suelen ser cosas que fueron informadas por personas del equipo (usualmente testers), y que se priorizaron como "arreglos cosméticos" o de "baja prioridad".
Esta colección de temas de baja prioridad nunca van a agregar valor: nunca se hace nada con esta información. Y sin embargo vamos manteniendo todos estos datos de entrega a entrega, con la idea equivocada de que tiene valor hacer un seguimiento de cada pequeña cosas que se encuentra (¡aunque al negocio simplemente no le importe!).
La base de datos se convierte más en una manta de seguridad que en un valor para el proyecto. Se gastan horas y horas discutiendo temas, haciendo listas de temas a arreglar, y actualizando la severidad y prioridad, sólo para deshacer todo el trabajo cuando aparezca el próximo bug crítico o la próxima característica fundamental. Si todo esto les resulta familiar, es momento de admitirlo: toda esa información en el bug tracker no ayuda a hacer avanzar al proyecto. Dejen de usarlo. Cuesta más de lo que ayuda.
Bugs en ágil
Entonces, ¿cómo reportamos bugs en un contexto ágil?
Luego de que la historia está Terminada y Aceptada, podemos encontrar circunstancias en las cuales la historia terminada no cumple con las expectativas del Dueño del Produco. Es sólo ahí que tenemos un bug.
Si estamos haciendo las cosas bien, no deberían ocurrir muchas de estas cosas. No tiene sentido hacer un seguimiento de los bugs en un hermoso bug traker si sólo vamos a tener 5 temas abiertos en un momento dado. El Dueño del Producto va a priorizar estos arreglos junto al resto de los elementos en el Backlog del Producto, y el equipo seguirá avanzando.
Si no estamos haciendo las cosas bien, podemos encontrarnos con una cantidad enorme de defectos por todos lados. Ahí es cuando nos daremos cuenta que tenemos un problema real con nuestro proceso. En vez de gastar tiempo en intentar gestionar todos estos bugs, debemos mirar al proceso completo y encontrar lo que está causando todos esos bugs. Hay que detener la causa de los bugs, en vez de intentar gestionarlos.