¿Cuántos errores abiertos tienes en tu backlog? ¿100? ¿1000?
¿Y cuánto tiempo han estado ahí? ¿Semana? ¿Mes? ¿Años?
¿Por qué sucede esto? ¿No hay tiempo? ¿Hay que hacer tareas más prioritarias? "Ahora implementaremos todas las características urgentes y luego definitivamente habrá tiempo para resolver los errores"?

… Algunos utilizan la Política de Cero Errores, otros tienen una buena cultura de trabajo con los errores (actualizan puntualmente el backlog, revisan los errores al cambiar la funcionalidad, etc.), y hay quienes forman magos que escriben sin errores en absoluto (poco probable, pero tal vez eso también ocurra).

Hoy les contaré sobre nuestra solución para limpiar el backlog de errores: el proyecto "Buglandia".

¿Cómo comenzó todo?

Al revisar nuevamente el cada vez mayor backlog de errores abiertos, llegamos a un punto de ebullición. No podíamos seguir así, decidimos reducirlo a toda costa. La idea es obvia, pero ¿cómo hacerlo? Coincidimos en que la forma más efectiva sería realizar un evento parecido a un hackathon: desprender a los equipos de las tareas cotidianas y dedicar 1 día laboral solo a tratar errores.

Redactamos un reglamento, lanzamos un llamamiento y comenzamos a esperar. Había preocupaciones de que habría pocos interesados, muy pocos, pero el resultado superó nuestras expectativas: se inscribieron 8 equipos (aunque, en el último momento, 3 se retiraron). Se asignó un día laboral completo el viernes, se reservó una gran sala de reuniones. Los almuerzos se organizaron en la cafetería de la oficina, y añadimos galletas para los refrigerios.

Implementación

En la mañana del día X, reunimos a todos los interesados en la sala de reuniones y realizamos un breve briefing.

Reglas principales:

• en un equipo luchan de 2 a 5 personas, al menos una de ellas debe ser QA;
• los errores deben ser cerrados por un miembro del equipo según todos los estándares de producción internos;
• cada equipo debe tener al menos un error cerrado que requiera correcciones en el código;
• solo se pueden corregir errores antiguos (fecha de creación del error < fecha de inicio de Buglandia - 1 mes);
• se otorgan puntos (de 3 a 10) por errores corregidos dependiendo de su criticidad (para evitar trampas, no se puede cambiar la criticidad después de anunciar la fecha de Buglandia);
• se otorga 1 punto por cerrar errores obsoletos o no reproducibles;
• el cumplimiento de todas las reglas es supervisado por el equipo de auditoría, que anula puntos por errores reabiertos.

Otros detalles

• No limitamos a nadie en la elección de la ubicación: se podía quedarnos en el lugar de trabajo o sentarse todos juntos en la sala de reuniones, donde no había distracciones y se sentía la intensidad de la competencia.

• Para mantener el espíritu competitivo, se proyectó una tabla de clasificación en una gran pantalla, y en el canal de Slack se realizaba una transmisión de texto constante del combate. Se utilizó un leaderboard que se actualizaba a través de webhooks para contar los puntos.

Leaderboard

• El cumplimiento de todas las reglas fue supervisado por un equipo de auditoría (por experiencia, con 1-2 personas es suficiente).
• Una hora después de finalizar la Bug Party, se anunciaron los resultados verificados.
  Los ganadores recibieron un certificado de regalo para un bar, y todos los participantes obtuvieron un recuerdo (llaveros con "bugs").

Resultados

En los últimos seis meses, hemos realizado ya tres Bug Parties. ¿Qué hemos logrado al final?

• El número promedio de equipos es 5.
• El número promedio de bugs procesados es 103.
• El número promedio de bugs no actuales/no reproducibles es del 57% (y este desecho siempre fue una molestia y asustaba por su cantidad).

Momento del anuncio de resultados

Y ahora la respuesta a la pregunta más espinosa que todos aman hacer: "¿Cuántos bugs nuevos han surgido?".
Respuesta: no más del 2% de todos los procesados.

Opiniones

Después de realizar la Bug Party, recogimos opiniones de los participantes. Aquí están las respuestas a la pregunta "¿Qué fue lo que más te gustó en el proceso de participación?"

• ¡Es genial repasar el backlog con esa motivación! Normalmente, es un proceso muy aburrido, hay que hacerlo periódicamente).
• Emoción, galletas.
• Es la oportunidad esperada de corregir esos pequeños detalles que no son críticos, pero que se desean solucionar.
• Me gustó que por fin pudimos arreglar bugs antiguos y molestos fuera del sprint; nunca hay tiempo para esto ya que siempre hay tareas de mayor prioridad. Logramos reunir a todos los necesarios en un mismo lugar (por ejemplo, había un DBA en nuestro equipo), discutimos colectivamente la relevancia de los bugs planteados y la posibilidad técnica de corregirlos.

Conclusión

La Bug Party no es una panacea, pero es una opción viable para reducir el backlog de bugs (en diferentes equipos entre un 10% y un 50%) en solo un día. Este evento tuvo éxito gracias a los motivados participantes, quienes se preocupan por el producto y el bienestar de nuestros usuarios.

¡Saludos a todos y que haya menos errores!

Fuente: habr.com