martes, 15 de abril de 2014

Reporte de defectos (bugs) en Scrum

Una pregunta muy frecuente en los equipos que están implementando Scrum es si tienen que seguir usando una herramienta de seguimiento de defectos, y si lo uso que deberían registrar en la misma.

Veamos primero la respuesta revolucionaria y después una respuesta evolutiva. 
Y luego el análisis en cuanto al momento en que se detecta.

Nota: en todos los casos que comentamos, la importancia o prioridad de los bugs se debe acordar en el Scrum Team (Dev Team + Product Owner + Scrum Master), teniendo la última palabra el PO basado en el impacto en el negocio.

Revolución: Hay una sola lista de pendientes

El backlog contiene todo lo que hay que construir. No hacemos diferencia entre bug y funcionalidad nueva.
Un bug que provoca que las pruebas automáticas estén en rojo (falla alguna de las pruebas) debe corregirse en el momento o esa funcionalidad debe quitarse (o desactivarse).
Si encontramos un bug durante la prueba exploratoria que es crítico, agregamos una prueba automática que lo evidencie. 
Todo otro bug se considera un cambio a una funcionalidad existente y se prioriza junto con otras funcionalidades.

Evolución (orgánico): Lista de bugs

El Product Owner dispone de varias fuentes: pedidos de los clientes, ideas propias de nueva funcionalidad, y un lista de los bugs que persisten en el producto. Cuando se planifica el sprint, se consideran los bugs más complejos como nuevos requerimientos, y los chicos se agrupan en paquetes de corrección. En ocasiones se define un tiempo fijo que se dedicará a corrección de todos los bugs que se puedan.

Caso bug detectado en una historia que se está desarrollando

  • Primera opción, corregirlo dentro del sprint como parte del desarrollo de la historia
  • ¿Y qué pasa si no llegamos con todo lo comprometido? 
    • Recortar la funcionalidad para que ese bug no sea relevante y agregar una historia con esa funcionalidad recortada. 
    • Si es muy grave, quitar la funcionalidad correspondiente y la historia queda sin hacer. Quizás pueda resolverse e el próximo sprint.
    • El bug es poco importante como para hacer alguna de las anteriores: si no es importante ahora, ¿cuándo lo será? Podemos registrarlo en una herramienta o tiralo a la basura, si aparece alguien a quien le importe, lo pedirá. Esta última es la forma más realista en el largo plazo. Las listas interminables acumuladas de bugs son un consumo de tiempo y esfuerzo de todo el equipo.

Caso bug detectado luego de liberada una historia

Hay varias alternativas:
  • Se maneja como una historia de usuario (si es grande)
  • Se agrega a las lista de ideas a revisar en el refinamiento de backlog, tanto para estimar como para evaluar la prioridad. Luego del análisis, se carga en el backlog / lista de bug si se quiere corregir en los próximos sprints, o se descarta.
  • Se corrige a medida que aparecen. El equipo debe manejar el impacto en cuanto a cambio de alcance. Por ejemplo: tener un tiempo fijo dedicado en el sprint para corrección de bugs. O poner un límite de bugs abiertos (por ejemplo 10) y se debe detener el desarrollo de nueva funcionalidad hasta tanto se corrijan los bugs que hay en exceso. 

¡Espero este breve recorrido te ayude!
Publicar un comentario en la entrada