Jesús Ramírez Guerrero

Actualmente estoy trabajando en una empresa donde, no se aplica una metodología Scrum, pero sí una planificación de Sprint. Un problema que he contemplado es conseguir aplicar esta metodología y cómo hacer frente a la tarea de corrección de errores (Bugs Fixing) aplicando Scrum.

Henrik Kniberg en su muy buen libro de «Scrum y XP desde las trincheras» se enumeran algunas ideas para de lidiar con este problema:

• El PO (Product Owner) decide la mayoría de los desarrollos y establece la prioridad (en Jira por ejemplo), los lleva a la reunión de planificación de Sprint , y los pone en el Dashboard, junto con las otras historias.
• El PO crea la historias que se refieren a los elementos de Jira para corrección de errores, por ejemplo: «Corregir los errores de informes Backoffice más críticos, ej: TTOOSUP-1245 , TTOOSUP-1451, TTOOSUP-5635, etc» .
• La corrección de errores se considerará como fuera de la carrera , es decir, el equipo mantiene un factor de enfoque lo suficientemente bajo ( por ejemplo 50 % ) para asegurarse de que tienen tiempo para corregir errores . Es simplemente supone que el equipo va a gastar una cierta cantidad de tiempo cada Sprint para corregir errores reportados en Jira.

Como hemos avanzado, estas son las ideas que da Henrik, pero ¿esto es realmente algo que necesita ser decidido por proyecto o existen mejores soluciones? ¿Cómo se maneja esto y se aplica en un proyecto con una cierta «estabilidad» en la resolución de sus proyectos?

Estas son unas preguntas muy buenas y para empezar, se me ocurren algunas observaciones en lo que respecta a los diferentes enfoques a este problema: +

• El tratamiento de todos los errores igualmente con elementos de trabajo pendiente, puede sonar como una buena idea en teoría (trabajo en un solo lugar ), pero no funciona bien en la práctica . Los errores son por lo general de bajo nivel y más numerosos, por lo que si se crea una historia de usuario individual para cada fallo, entonces las historias «reales» (nuevos desarrollos) quedan a la sombra y parecen menos prioritarios pronto.
• Tiempo explícito reservado en cada Sprint parala corrección de errores, está bien si se hace de una manera que sea visible para PO.
• Los errores deben mencionarse durante el Daily Meeting, y podría llevarse igualmente durante el Sprint Backlog para mejora en futuras planificaciones. De lo contrario, el PO no va a ser consciente de lo que está pasando en el proyecto ni el tiempo consumido en todas las tareas, incluido el Bug Fixing.
• Poner todo el retraso acumulado en la herramienta de seguimiento de errores (ej: Jira) conduce lleva a una sobrecarga de tiempo en el uso de estas herramientas, además la mayoría de los gestores de fallos no están diseñados con Scrum en mente y su uso para este propósito pueden ser costoso en cuanto a tiempo para cada Bug.

La posible solución más satisfactoria era poner un solo User Case los llamados «Bugs» en cada Sprint. Tal historia puede dividirse ya sea en tareas de bajo nivel que describen un error en particular (si se conoce durante la planificación ) o meta-tareas que reservan un número determinado de horas para la solución general de Bug. De esta manera el PO tiene visibilidad en el proceso y el gráfico de Burndown que refleja el progreso.

Debemos asegurarnos de corregir todos los errores referidos contra el Sprint actual antes de que haya terminado a fin de considerar el Sprint como finalizado, pero ojo, a veces el manejo de Bugs nos impide cerrar el 100% de ellos, por lo que podría ser conveniente fijar un porcentaje de ellos para considerar el fin de Sprint.

Trataremos de profundizar más aún en este tema en futuras entradas, gracias por vuestra lectura y ¡compartid!.