Combien de bugs ouverts avez-vous dans votre backlog ? 100 ? 1000 ?
Combien de temps restent-ils là ? Une semaine? Mois? Années?
Pourquoi cela arrive-t-il? Pas le temps? Avez-vous besoin d’effectuer davantage de tâches prioritaires ? « Maintenant, nous allons implémenter toutes les fonctionnalités urgentes, et ensuite nous aurons certainement le temps de régler les bugs » ?

... Certains utilisent une politique zéro bug, certains ont une culture bien développée de travail avec les bugs (ils mettent à jour le backlog en temps opportun, révisent les erreurs lorsque les fonctionnalités changent, etc.), et certains cultivent des assistants qui écrivent sans aucun bug. (peu probable, mais peut-être que cela arrive).

Aujourd'hui, je vais vous parler de notre solution pour nettoyer l'arriéré de bugs - le projet Bagodelnya.

Comment tout a commencé?

Une fois de plus, en examinant l’arriéré toujours croissant de bogues ouverts, nous avons atteint le point d’ébullition. Il était impossible de vivre ainsi plus longtemps, ils ont décidé de le réduire à tout prix. L’idée est évidente, mais comment faire ? Nous avons convenu que le moyen le plus efficace serait un événement similaire à un hackathon : éloignez les équipes des tâches quotidiennes et allouez 1 journée de travail à la gestion uniquement des bugs.

Ils écrivirent le règlement, appelèrent et commencèrent à attendre. On craignait qu'il y ait peu de candidats, très peu, mais le résultat a dépassé nos attentes - jusqu'à 8 équipes se sont inscrites (cependant, au dernier moment, 3 ont fusionné). Nous avons réservé une journée de travail entière le vendredi pour l'événement et réservé une grande salle de réunion. Des déjeuners ont été organisés à la cantine du bureau et des cookies ont été ajoutés pour les collations.

exécution

Le matin du jour X, tout le monde s'est réuni dans une salle de réunion et a tenu un bref briefing.

Les règles de base:

• une équipe est composée de 2 à 5 personnes, dont au moins une est responsable de l'assurance qualité ;
• les bugs doivent être résolus par un membre de l'équipe conformément à toutes les normes de production internes ;
• Chaque équipe doit avoir au moins un bug résolu qui nécessite des corrections dans le code ;
• Vous ne pouvez corriger que les anciens bugs (la date de création du bug < la date de début du bug house - 1 mois) ;
• pour les bugs corrigés, des points (de 3 à 10) sont attribués en fonction de la criticité (pour éviter la triche, la criticité ne peut plus être modifiée après l'annonce de la date du Bug Day) ;
• pour la fermeture de bogues non pertinents et irréproductibles, 1 point est attribué ;
• Le respect de toutes les règles est contrôlé par l'équipe d'audit, qui annule les points pour les bugs redécouverts.

Autres détails

• Nous n'avons limité personne dans le choix du lieu : ils pouvaient rester sur leur lieu de travail ou s'asseoir avec tout le monde lors d'une réunion où les gars n'étaient pas distraits et où les passions pouvaient se faire sentir.

• Pour maintenir l'esprit de compétition, un tableau de classement a été affiché sur grand écran et un texte de la bataille a été diffusé en permanence sur la chaîne Slack. Pour calculer les points, nous avons utilisé un classement mis à jour via des webhooks.

Classement

• Le respect de toutes les règles a été contrôlé par l'équipe d'audit (par expérience, 1 à 2 personnes suffisent pour cela).
• Une heure après la fin de Bagodelny, les résultats revérifiés ont été annoncés.
  Les gagnants ont reçu un chèque-cadeau au bar et tous les participants ont reçu un souvenir (porte-clés avec « bugs »).

résultats

Au cours des six derniers mois, nous avons déjà organisé trois hospices. Avec quoi avons-nous fini?

• Le nombre moyen d'équipes est de 5.
• Le nombre moyen de bugs traités est de 103.
• Le nombre moyen de bugs non pertinents/irreproductibles est de 57 % (et ces déchets étaient constamment une horreur et effrayaient par leur quantité).

Moment de l'annonce des résultats

Et maintenant, la réponse à la question la plus délicate que tout le monde aime poser : « Combien de nouveaux bugs avez-vous trouvés ?
Réponse : pas plus de 2 % de tous les produits traités.

Avis clients

Après le Bagodelen, nous avons recueilli les retours des participants. Voici les réponses à la question « Qu’est-ce qui vous a le plus plu dans le processus de participation ? » :

• C’est très cool de trier le retard avec une telle motivation ! Habituellement, c'est un processus très ennuyeux, cela doit être fait périodiquement).
• Excitation, cookies.
• C'est une opportunité tant attendue de corriger ces petites choses qui ne sont pas critiques, mais que vous souhaitez corriger.
• J'ai apprécié le fait que vous puissiez enfin corriger d'anciens bugs désagréables en dehors du sprint ; vous n'aurez jamais le temps de les résoudre car il y aura toujours des tâches avec une priorité plus élevée. Nous avons réussi à rassembler toutes les personnes nécessaires en un seul endroit (notre équipe avait un dba par exemple), et avons discuté collectivement de la pertinence des bugs identifiés et de la possibilité technique de les corriger.

Conclusion

Le bug shop n'est pas une panacée, mais c'est une option viable pour réduire l'arriéré de bugs (dans différentes équipes de 10 à 50 %) en une seule journée. Pour nous, cet événement n'a décollé que grâce à des gars motivés qui soutiennent le produit et se soucient du bonheur de nos utilisateurs.

Tout le meilleur et moins de bugs !

Source: habr.com