Se denomina anomalía o "bug" a un defecto de diseño en un programa informático que causa un mal funcionamiento del sistema. Estas palabras pueden referirse indistintamente a la consecuencia del problema (cuando es descrito por un Product Owner o Product Manager) y a la causa técnica del problema (cuando es tratado por los desarrolladores).
Es difícil evitar completamente las anomalías; cuanto más complejo es un proyecto, mayor es la probabilidad de que un error escape de la vigilancia de los desarrolladores y probadores. La realización sistemática de pruebas unitarias y de extremo a extremo permite limitar la aparición de errores. Del mismo modo, la escritura de pruebas de aceptación específicas para cada historia de usuario también lo permite.
Cuando se descubre un bug, ya sea durante un sprint o después de validar una historia de usuario, es importante materializarlo en forma de una nota (preferiblemente de color llamativo) en un tablero kanban y/o mediante un ticket en una herramienta como JIRA.
La gravedad de una anomalía varía: algunas resultan en errores de visualización, mientras que otras hacen que todo el sistema falle. En cualquier caso, corregir los bugs lleva tiempo. La priorización entre corregir las anomalías y desarrollar una nueva historia de usuario recae en el PO.
La mayoría de los Product Owners y coaches ágiles consideran que no se deben estimar los bugs:
- El "costo" de un bug radica principalmente en una fase de análisis del problema y no en un desarrollo correctivo. Es difícil evaluar la duración de esta fase de antemano.
- Si se estimaran los bugs, el tiempo dedicado a corregirlos afectaría positivamente a la velocidad del equipo. Sin embargo, el objetivo es minimizar el número de bugs; de esta manera, se enfoca en el valor del cliente (contenido en las user stories).
- Para algunos "pequeños" bugs, el tiempo dedicado a estimarlos sería desproporcionado en comparación con el tiempo necesario para corregirlos.
Aun así, el PO prioriza los bugs según su criticidad y puede acordar con los desarrolladores acotar el tiempo para resolverlos.
Puede ser interesante seguir un indicador del número promedio de anomalías detectadas por historia validada; de esta manera, se mide la relevancia de las pruebas unitarias y de extremo a extremo realizadas, la calidad del desarrollo y también la rigurosidad del equipo de pruebas.
Para saber más: Descarga nuestro libro Las Claves del Product Management
