Traiter ses bugs avec méthode, ça paie !

Christopher Parola
Feb 14, 2018 · 5 min read

Dans l’article Traiter ses bugs, essentiel mais pas si simple, je vous promettais de vous partager nos résultats. Les voilà ! :-)

Le contexte MeilleursAgents

Pour comprendre nos problématiques de gestion des bugs, un peu de contexte sur notre organisation et nos outils est nécessaire.

Au sein de MeilleursAgents, toutes les équipes (Opération, Marketing, Technique, Produit) peuvent remonter un bug en envoyant un mail à une adresse définie. Ces remontées de bugs créent des tickets dans notre outil de gestion de ticket, Jira.

Nous avons déjà testé plusieurs processus de gestion des bugs, pour arriver à la solution actuelle : le Gardien.

Le gardien est un Product Manager qui protège l’équipe en traitant tous les bugs entrant

Notre équipe technique / produit est organisée en Impact Team : une équipe ayant la responsabilité d’un objectif chiffré qu’elle doit faire évoluer en un trimestre.

En tant qu’équipe produit, notre objectif est d’être les plus réactifs possible sur les bugs, que ce soit en termes de communication (indiquer que nous l’avons bien pris en compte et la progression de sa résolution), de qualification (déterminer la criticité du bug) et de résolution (ou non : on peut aussi décider de ne pas le traiter).

La qualification

Nous voulons répondre à tous les bugs créés. La réponse n’est pas nécessairement longue. Un simple “bien reçu, on regarde et je reviens vers toi rapidement”, ou même “ceci n’est pas un bug” suffisent. On se doit de répondre rapidement, car une personne ayant remonté un bug doit savoir qu’il a bien été pris en compte, par exemple s’il y a besoin de le communiquer à un client.

Les différents types de bug (http://www.commitstrip.com/fr/2014/07/15/top-6-worst-bugs-ever/)

Qualifier l’urgence

La première étape est bien entendu de qualifier l’urgence du bug. Si le bug nécessite un arrêt de la production pour être résolu, on ne peut attendre 2h pour le constater. Le gardien des bugs doit donc accepter, pendant sa période de garde, d’être interrompu dans son quotidien par des signalements.

Nous utilisons Slack au sein de l’équipe produit/technique, ce qui permet très simplement d’activer les notifications uniquement sur le channel qui enverra une alerte pour tout nouveau bug créé. Cela permet de limiter les interruptions tout en garantissant un temps de traitement optimal.

Qualifier le type

Une fois l’urgence qualifiée vient le type de bug. Nous avons créé trois labels : qualified, doublon, not-a-bug, ce qui nous permet d’avoir un suivi du type de bug que nous manipulons, et également d’avoir des actions standards dans chacun des cas.

Qualified

Le bug est effectivement un bug (rappel de la définition que nous utilisons : Un bug, c’est un dysfonctionnement constaté en production.). Il a pu être constaté, voire même reproduit. Il ne restera plus qu’à l’intégrer au backlog et décider du moment où il sera traité.

Doublon

Le bug existe et a déjà été signalé par une autre personne. Nous allons donc fermer ce nouveau signalement, informer la personne que nous avons déjà le sujet dans les tuyaux, ajouter les informations complémentaires qui peuvent être utiles. N’oublions surtout pas qu’il faudra tenir au courant toutes les personnes l’ayant signalé.

Not-a-bug

Il ne s’agit tout simplement pas d’un bug. Il peut soit s’agir d’oubli d’activation d’options dans notre back-office, soit d’incompréhensions de ce que le produit fait. Ces signalements sont très intéressants d’un point de vue fonctionnel : l’utilisateur ne s’attendait tellement pas à ce comportement qu’il pense avoir trouvé un problème. Cela donne à réfléchir sur la fonctionnalité en question !

Attribution

Notre organisation en Impact Team nous contraint à nous poser la question de l’attribution des bugs : quelle équipe va interrompre sa recherche d’impact pour résoudre le problème ?

Mes collègues et moi entrain de décider qui va devoir traiter le bug

Dans le cas de problèmes urgents, pas de question à se poser : le développeur le plus qualifié pour investiguer et résoudre le bug va s’interrompre et le traiter au plus vite.

Dans le cas de problèmes non urgents, la question se pose différemment : est-ce que la résolution du bug en question est plus prioritaire que les User Stories prévues dans le backlog de Sprint de cette équipe ? Une simple synchronisation entre les Product Managers de chacune des équipes permet de prendre cette décision. N’ayant pour le moment que deux Impact Teams, le coût de synchronisation reste faible.

Cette façon de prioriser est une constante pour tous les “objets” qui doivent passer par notre flux de production, qu’il s’agisse de cadrage technique, tâche technique, User Stories et de bug.

Analyse et résultat

On ne peut améliorer que ce que l’on mesure : il est donc nécessaire d’analyser des indicateurs sur le traitement des bugs pour pouvoir continuer de nous améliorer.

L’ajout des labels ainsi que la mesure du temps de réponse et de traitement permis par Jira nous permettent cette analyse.

Après cette première expérimentation, nous estimons qu’en moyenne un Product Manager passe 15 minutes à traiter un signalement de bug, qu’il soit avéré ou non : on peut arriver à l’approximation que la gestion des bugs coûte une journée de travail au Gardien par sprint de deux semaines.

Nous avons constaté également que 50% des signalements de bugs n’en sont pas. Cela met en avant le besoin de centraliser et partager la connaissance en interne sur nos produits pour réduire ce volume. Nous travaillons en ce sens depuis plusieurs semaines, et allons poursuivre les efforts.

Enfin, nous sommes passés de 120 signalement de bugs ouverts à 26. Une soixantaine a été traitée simplement par fermeture de bugs restés ouverts ou non qualifiés depuis des mois. Quand aux autres, on peut attribuer leur résolution à la performance du nouveau système mis en place.

MeilleursAgents Engineering

MeilleursAgents Engineering Teams (Product, Web & Data Teams)

Christopher Parola

Written by

VP Product @MeilleursAgents. Product enthusiastic. Former-CEO of elCurator. Speaker on PM events.

MeilleursAgents Engineering

MeilleursAgents Engineering Teams (Product, Web & Data Teams)