Combien de bugs ouverts avez-vous dans votre backlog ? 100 ? 1000 ?
Depuis combien de temps y sont-ils ? Une semaine ? Un mois ? Des années ?
Pourquoi cela se produit-il ? Manque de temps ? Faut-il prioriser d'autres tâches ? « On va d'abord réaliser toutes les fonctionnalités urgentes, et ensuite on aura du temps pour régler les bugs » ?

… Certains utilisent une Politique Zéro Bug, d'autres ont une bonne culture de gestion des bugs (ils actualisent le backlog en temps voulu, réexaminent les erreurs lors des modifications de fonctionnalité, etc.), et certains forment des magiciens qui écrivent sans bugs (peu probable, mais cela arrive peut-être).

Aujourd'hui, je vais vous parler de notre solution pour nettoyer le backlog des bugs — le projet « Bug City ».

Comment tout a commencé ?

En regardant encore une fois le backlog croissant des bugs ouverts, nous sommes arrivés à un point de non-retour. Il était impossible de continuer ainsi, nous avons décidé de le réduire à tout prix. L'idée est évidente, mais comment procéder ? Nous avons convenu que le moyen le plus efficace serait d'organiser un événement semblable à un hackathon : éloigner les équipes de leurs tâches quotidiennes et consacrer une journée de travail uniquement à la résolution des bugs.

Nous avons rédigé un règlement, lancé un appel et commencé à attendre. Nous avions des craintes que peu de personnes s'inscrivent, très peu, mais les résultats ont dépassé nos attentes : huit équipes se sont inscrites (en vérité, trois ont renoncé à la dernière minute). Nous avons dédié une journée entière à l'événement vendredi, réservé une grande salle de réunion. Les déjeuners ont été organisés via la cafétéria du bureau, et nous avons ajouté des biscuits pour les collations.

Mise en œuvre

Le matin du jour J, nous avons rassemblé tous les intéressés dans la salle de réunion et ont effectué un bref briefing.

Les règles principales :

• dans chaque équipe, de 2 à 5 personnes s'affrontent, dont au moins une est QA ;
• les bugs doivent être fermés par un membre de l'équipe selon toutes les normes de production internes ;
• chaque équipe doit avoir au moins un bug fermé nécessitant des corrections dans le code ;
• seuls les anciens bugs peuvent être corrigés (date de création du bug < date de début de Bug City - 1 mois) ;
• des points (de 3 à 10) sont attribués pour les bugs corrigés, selon leur criticité (pour éviter la tricherie, il est interdit de changer la criticité après l'annonce de la date de Bug City) ;
• pour la fermeture de bugs non pertinents et non reproductibles, 1 point est attribué ;
• la conformité à toutes les règles est surveillée par l'équipe d'audit, qui annule les points pour les bugs réouverts.

D'autres détails

• Nous n'avons limité personne dans le choix de l'emplacement : on pouvait rester à son poste ou s'asseoir tous ensemble dans une salle de réunion où les gens n'étaient pas distraits et la passion était palpable.

• Pour soutenir l'esprit de compétition, un tableau de classement a été affiché sur grand écran, et une diffusion textuelle du combat se déroulait en permanence dans le canal Slack. Pour le comptage des points, nous avons utilisé un leaderboard qui était mis à jour via des webhooks.

Leaderboard

• Une équipe d'audit veillait au respect de toutes les règles (en théorie, 1 à 2 personnes suffisent pour cela).
• Une heure après la fin de la Bugathon, les résultats vérifiés ont été annoncés.
  Les gagnants ont reçu un bon d'achat pour un bar, et tous les participants ont reçu un souvenir mémorable (porte-clés avec des « bugs »).

Résultats

Au cours des six derniers mois, nous avons déjà organisé trois Bugathons. Que avons-nous donc obtenu au final ?

• Le nombre moyen d'équipes - 5.
• Le nombre moyen de bugs traités - 103.
• Le nombre moyen de bugs non pertinents/non reproductibles - 57% (et cet encombrement, il était toujours là et effrayait par son volume).

Moment de l'annonce des résultats

Et maintenant, la réponse à la question la plus épineuse que tout le monde adore poser : « Combien de nouveaux bugs avez-vous plantés ? »
Réponse : pas plus de 2% de tous les bugs traités.

Avis

Après la Bugathon, nous avons recueilli des retours des participants. Voici les réponses à la question « Qu'est-ce que vous avez le plus aimé dans le processus de participation ? » :

• C'est vraiment génial de parcourir le backlog avec une telle motivation ! D'habitude, c'est un processus très ennuyeux, il faudrait faire cela régulièrement).
• Excitation, biscuits.
• C'est une occasion très attendue de corriger ces petits détails qui ne sont pas critiques, mais qu'on a envie de modifier.
• J'ai aimé le fait qu'on puisse enfin corriger de vieux bugs ennuyeux en dehors des sprints, car on n'a jamais le temps pour ceux-ci étant donné que des tâches de priorité plus élevée seront toujours là. Nous avons pu rassembler toutes les personnes nécessaires au même endroit (il y avait par exemple un DBA dans notre équipe), nous avons discuté collectivement de la pertinence des bugs signalés et de la possibilité technique de les corriger.

Conclusion

La Bugathon n'est pas une panacée, mais c'est une option tout à fait viable pour réduire le backlog de bugs (dans différentes équipes de 10 à 50%) en seulement un jour. Cet événement a décollé grâce à des membres motivés qui se soucient du produit et du bonheur de nos utilisateurs.

Je souhaite à tous le meilleur et moins de bugs !

Source : habr.com