martes, 23 de marzo de 2010

Tratando con Bugs en Scrum

¿Se deben o no se deben estimar los BUGS usando Scrum? Nos preguntábamos hace unos días en el trabajo esta cuestión, sin llegar a tener claro cual debe ser el enfoque a utilizar para introducirlos de manera fluida en el ciclo de Scrum.

Durante mucho tiempo he defendido la idea de que los Bugs debían ser tratados cómo si fueran nuevas historias de usuario, , añadiendolos al backlog y realizando su correspondiente priorización y estimación en Puntos Historia. Esto funciona razonablemente bien si los Bugs detectados no son los suficientemente críticos cómo para poder esperar al siguiente Sprint para corregirlos, pero no es un buen método cuando los Bugs tienen que ser arreglados ya.

Además este enfoque presentaba algunos problemas teóricos relacionados con la metodología, a saber:

  • Estimación de un bug, implica contabilizar dos veces el mismo trabajo (uno cuando se estima la historia, y otro cuando se estima el trabajo para arreglar lo que se ha hecho mal en la historia)
  • Estimación en Scrum se utiliza para contabilizar el valor (relativo) que cada funcionalidad aporta al cliente, cómo los Bugs no aportan valor (más allà de solucionar un error cometido por nosotros mismos) no deberian estimarse.

En cambio, creo que el enfoque correcto (o el que a mi me gusta más) es el de tratar los Bugs como “tareas adicionales” dentro de la historia donde se ha generado.

Usando este enfoque, la estimación de la historia no varía, pero si que variará el tiempo dedicado a finalizarla, poniendo de relieve el impacto de los mismos en aquellas historias donde se producen y consiguiendo que la velocidad del equipo no sea un dato falseado (hacer muchos puntos en cada Sprint, pero teniendo que arreglar muchas de las historias en el/las siguiente/s iteraciones). Cómo consecuencia de esto, al tener más consciencia sobre el impacto de los Bugs en las historias implementadas, se puede lograr una disminución importante en los defectos de futuras iteraciones.

¿Cuál os parece a vosotros el enfoque mas adecuado? ¿Qué otro tipo de enfoque utilizáis para tratar los defectos ? Espero vuestros comentarios y aportes.


8 comentarios:

Joserra dijo...

Creo que lo mejor es no contar los bugs en la planificación. Se planifica aquello que crea valor al cliente, las historias de usuario
Este enfoque tiene de bueno que si hay muchos bugs, baja tu velocidad, por que tienes mucha deuda técnica.

Si no tienes bugs, puedes dedicar todo el tiempo a avanzar en cosas que aumentan la velocidad. Si tienes bugs, habrá tiempo que dediques a corregirlos y tu velocidad se resentirá.

Si ves que tras cada sprint tu velocidad va bajando, averigua si es por que dedicas demasiado tiempo a bugs, y planteaté el por qué. Reducir la creación de bugs es una manera genial para aumentar la velocidad de un equipo.

Joserra dijo...

Cr

vgaltes dijo...

Yo también creo que los bugs no se deben contar como historias, ni incluso como tareas adicionales. Simplemente es algo que te fastidia tu sprint y que debes intentar minimizar.

Pq imaginemos que en el sprint anterior tenemos una historia que ahora le detectamos un bug. Si tratamos los bugs como tareas adicionales a la historia, en el siguiente sprint tenemos que poner la historia, no? Como afecta esto al burndown? Con cuantos puntos estimamos esto?

JASOSA dijo...

Primero de todo, gracias por los comentarios.

En segundo lugar, estoy de acuerdo en que la situación ideal es no tener bugs, pero por muy buenas prácticas de ingenieria que tengas, y por muy buenos que sean los desarrolladores que forman tu equipos,
es muy probable que se cuele algún bug. Y en ese caso, que haces con el? Simplemente lo ignoras? Planificas el siguiente Sprint sin tenerlo en cuenta? Se cierran las historias en las que has detectado algún bug? Que hay que hacer según tu en el caso que comentas Vicenç?

vgaltes dijo...

Pues ya sabes qué es un tema que siempre me ha dado dolores de cabeza y que no tengo claro como hacerlo. Si me tengo que tirar a la piscina digo que si que cerraría la historia. Si te fijas por ejemplo en el TFS los bugs los pone como un ente separado y, como dice joserrra, no aportan valor al cliente. Si el bug hace que la historia realmente no funcione, lo que se tendría que revisar son las condiciones de aceptación de la misma.

Lo que ahora no tengo claro es lo que dice joserra no contar los bugs en el burndown. Creo que si que los contaria, pq sino no vas a saber cuantos puedes solucionar. Una cosa es la velocidad del equipo y otra es que parte de esa velocidad se dedica a entregar valor.

Vaya lio, no?

Joserra dijo...

No es lio! ;)
Si cuentas los bugs como velocidad, cuando te llegue el siguiente proyecto y te pregunten para cuando puede estar, tu estimación de velocidad será falsa si has incluido los bugs.

No digo que no controles el tiempo de bugs, debes saber que % de tu tiempo se dedica a ellos, así sabrás qué posibilidades además tienes de mejorar en tu velocidad.

Si los planificas en tu burn-down, puede ser que hagas unas gráficas impresionantes, todo la planificación estimada que se cumple, pero en realidad estás corrigiendo bugs. Eso debería repecutir bajo mi punto de vista en una mala velocidad de desarrollo.

JASOSA dijo...

OK, entonces los bugs no quedan reflejados en el burndow, es simplemente tiempo que se "pierde" respecto a la entrega de valor al cliente (repercutiendo en nuestra velocidad) ¿Es así?

vgaltes dijo...

¿Y si te preguntan para cuando estará acabado el bug que dices?

Entiendo entonces que en tu estimación, de todo tu tiempo pones un factor de foco que será el que dediques a nuevas historias y que será del que harás el burndown y el resto de tiempo para bugs, no?