¿Se deben de estimar los bugs?

Bug de software - cortesía de Pixabay

Esta cuestión genera mucho debate ya que solemos considerar los bugs como algo negativo, algo que asociamos a un error humano y que tiene coste para la empresa, y en ambientes tradicionales hasta pueden ser elemento de penalización.

La perspectiva ágil de los bugs es entender en primer lugar que no existe software libre de bugs, y que estos son desperdicio que supone una oportunidad de aprendizaje para la mejora continua de la construcción del software. Debemos de ir a la causa raíz del bug, probablemente esté relacionado con un impedimento sistémico, y resolverla con técnicas como XP, formación, coaching o técnicas de DevOps.

Veamos lo que nos dice la Scrum.org al respecto de la gestión de bugs: "A menos que su empresa tenga una guía específica sobre la corrección de bugs, representan trabajo a realizar, y el Propietario del Producto debe incluirlos y priorizarlos en la pila del producto. Hay dos excepciones; si el trabajo para corregir el bug es menor que el trabajo para registrarlo, y si el bug es tan crítico que sería negligente dejarlo sin corregir".

A esto podemos añadir:

• Si el bug se descubre durante el sprint y se refiere a una historia de usuario de la pila de sprint en curso, este se corrige directamente. La corrección del bug forma parte del trabajo del sprint, probablemente el incremento no se pueda considerar hecho y por tanto no sería potencialmente desplegable en producción.
• Si el bug se descubre fuera del sprint, viene de una historia de usuario de otro sprint, entonces, tal como nos dice la Scrum.org "si el bug es menor que el trabajo para registrarlo o si el error es tan crítico que sería negligente dejarlo sin reparar" se corrige directamente.
• Si el bug se descubre fuera del sprint, quizá hasta ya esté en producción, y no es crítico, y por tanto se resolverá en un sprint futuro este debe de incluirse en la pila del producto como historia técnica.

Para concluir, si el bug ha generado un elemento en la pila de producto, no importa si es un bug o un cambio funcional recientemente identificado, este debe de ser estimado para que el Propietario del Producto lo priorice adecuadamente y el equipo de desarrollo pueda planificar el sprint en donde se vaya a corregir.

Una empresa puede tener una política específica para la corrección de bugs. Es habitual la reserva de capacidad, o capacity allocation, en la que se reserva un porcentaje de tiempo de los sprints para corregir bugs y otras historias técnicas. En este caso no se estiman los bugs, éstos se priorizan adecuadamente y se corrigen tantos bugs como sea posible en el sprint durante ese timebox .