Pages Menu
Categories Menu

Posted by on Oct 30, 2013 in General | 11 comments

Cómo gestionar bugs e incidencias en un proyecto ágil

Cuando aquí hablo de bugs, me refiero a bugs o incidencias que derivan de versiones del software ya puestas en producción, bugs que no están englobados en el ámbito del sprint actual, tareas no planificadas que surgen del día a día de la gestión de un desarrollo software.

El manejo de este tipo de incidencias, tan típicas, suele ser un quebradero de cabeza para muchos equipos que trabajan de manera ágil, porque mantienen una pila de tareas que han derivado de las historias de usuario a implementar en un sprint o iteración, y de pronto se ven en la necesidad de incorporar tareas no planificadas, pero que urgentemente hay que solucionar. Si esta terminología te suena a Chino, lee primero Scrum para Dummies o cómo sorevivir a una planificación ágil.

No te voy a dar una solución mágica a ese problema, porque no la hay, ni con agilidad ni sin ella, pero si quiero comentarte las estrategias más típicas que me he encontrado para gestionar los bugs.

Normalmente, hay dos grandes estrategias, con sus pros, contras, fans y detractores: 1) gestionar los bugs con el product backlog y el sprint blacklog o 2) crear un backlog específico para bugs.

1 – Gestionar los bugs con el product backlog y el sprint blacklog

Según esta estrategia, normalmente se procede de la siguiente manera:

– Si el bug no es bloqueante o urgente, se añade al product backlog, así el product owner decidirá su prioridad y en qué iteración resolverlo.

– Si el error es bloqueante, se añade como una nueva tarea en el sprint backlog (en el sprint actual) y se empieza a trabajar en él. Esto implica que alguna historia de usuario planificada para el sprint backlog debe volver al product backlog o que alguna tarea no se va a poder realizar.

Es recomendable que cuando añadas nuevas tareas relacionadas con los bugs, marcarlas de forma diferente a las tareas planificadas, para que sean fáciles de distinguir.

2 – Crear un backlog solo para bugs

Hay quien argumenta que la situación ideal es poner directamente los bugs en el product backlog, pero hay quien prefiere tener dos backlogs:

– Un product backlog de funcionalidades.

– Un backlog de bugs.

El product owner debe priorizar los dos backlog, decidiendo qué se implementará durante el sprint, conformándose así el sprint backlog. Si el bug es urgente, entraría, como en el caso anterior, directamente al sprint backlog  modificándolo, aunque sea en mitad de un sprint.

Si quieres leer mas, te dejo estos enlaces…

http://www.scrumalliance.org/community/articles/2013/october/dealing-with-legacy-bugs-in-scrum-the-buglog!

http://www.mountaingoatsoftware.com/blog/bugs-on-the-product-backlog

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

11 Comments

  1. ¿Qué opinas de una alternativa distinta como por ejemplo el sprint se planifique para el 80% del tiempo del equipo y que haya 20% por ejemplo flexible para los bugs?
    Si no hay bugs… (cosa muy poco probable) adelantaría trabajo del sprint.
    Si los hay, y los habrá, habrá un tiempo que se destinará dentro de la iteración a la solución cuánto antes del bug.
    En la filosofía Lean, se evitan los defectos, y cuanto antes.

    Me gustaría saber tu opinión sobre esta idea.

    Un saludo, y gracias por tus posts.

    • Hola,

      Me parece buena idea, teniendo en cuenta que hay que tener buen ojo pasa saber cuanto y cuando hacerlo y que la empresa respete ese 20% cosa muchas veces difícil… Además, debeira haber un % en cada Sprint para cosas no planificadas ddirectamente desde las HU, como p.e., refactorizar.

      Saludos

      • Ok, gracias Javier.

  2. Otro forma, que hemos usado en mi empresa y que nos ha ido bien es un parecida a la opción 1 que comentas pero además definiendo una «bolsa de horas» o digamos una capacidad máxima por sprint para acometer las incidencias y/o bug de las aplicaciones en uso. Esta capacidad se monitoriza durante todo el sprint y te ayuda a evitar posibles impedimentos y/o re-planificaciones del sprint backlog.

    Es verdad que no es infalible y siempre en un sprint cabe la posibilidad de haber cubierto la capacidad y que llegue una nueva incidencia «super ultra urgente» y no queda más remedio que incluirla (over capacity), y allí algo debe salir (como comentas en la opción 2 ) o algo no se terminará.

    Otro cosa, es que hay un «encargado» en el equipo que se encarga de resolver todas las incidencias en un sprint para evitar que todo el equipo se desenfoque del trabajo «principal» y reducir el impacto de estos imprevistos. Este encargado rota cada sprint.

  3. Yo he probado todas las opciones que comentas aquí y la verdad es que creo que depende bastante del tamaño del equipo. Por mi experiencia, en equipos pequeños funciona bien el tener una «bolsa de bugs» con un montón de bugs de las que los developers puedan ir sacando bugs según vayan acabando sus tareas (o si necesitan «un respiro» de una tarea larga y complicada). Sobre el tamaño de la bolsa y su peso lo mejor es adaptarla al sprint en concreto: tamaño de las historias de usuario, vacaciones, días festivos…
    Para equipos grandes creo que depende un poco de la velocidad del equipo. En los proyectos en los que he estado he visto que equipos que hace muchos «puntos» en un sprint suelen ser muy reacios a arreglar bugs y que los equipos con pocos puntos suelen ser bastante receptivos a arreglar bugs. Lo único que he visto que funciona en este caso es añadir los bugs como «historias» y que los developers los consideren parte del sprint.
    De los temidos Hotfix y «esto no lo he roto yo, por qué tengo que arreglarlo» hablamos otro día 😀

  4. Buenas

    En mi empresa tenemos sprints de un mes. La primera semana la dedicamos solamente a correctivo. Ahí se hace una entrega a testing con la funcionalidad del sprint anterior más el correctivo de este, liberando una nueva versión del producto cada mes.

    Si hay más bugs de los que se puedan solucionar en esa semana, esperan al siguiente mes. Si hay menos, el tiempo disponible se aprovecha para el evolutivo.

    La prioridad de los bugs nos la imponen desde fuera, según razones técnicas y económicas de proyectos.

    Saludos

  5. Hola, buena noche

    Quisiera conocer las mejores prácticas de manejo de equipos de mantenimiento y de bugs(incidencias), en los escenarios que luego de los desarrollos de software por los equipos scrum(proyectos), y su estabilización, estos son entregados a equipos aparte de mantenimientos.

    Cuál ha sido la experiencia con este esquema y recomendaciones?.

    Gracias.

  6. Solo se esta mostrando alternativas para un equipo que adopto Scrum, pero si hablamos de equipos ágiles, fácilmente ya estarían jugando con Kanban o alguna otra herramienta que les permita ver el lead time, pues considero importante tener esta métrica cuando estas en producción es importante tener ese dato,

  7. Creo que aquí sólo se está hablando de equipos que adoptaron Scrum, pero si fuese un equipo ágil, fácilmente estos ya estarían jugando con otras técnicas como Kanban y , para así poder tener claramente el Lead Time, métrica que considero muy importante después de salir a producción.

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This