La gestion des bugs, c’est pas simple
… Sauf si on est un tant soit peu radical !
… Sauf si on est un tant soit peu radical !
Gérer les bugs, c’est compliqué.
D’abord parce qu’il faut que les rapports de bug tiennent la route. Et même si ça n’a rien de sorcier de réussir à remplir un bon rapport de bug, tout le monde n’est pas à l’aise avec l’exercice, et puis ça demande un certain effort. Bon, au final, ça dépend pas mal de qui remplit le rapport de bug. Plus vous vous ouvrez au monde, plus il y a de rapports pas terribles.
Ensuite parce qu’il faut les qualifier, les reproduire. Et souvent, ce n’est pas simple parce que c’est aléatoire, ou parce qu’on n’a pas la bonne configuration pour reproduire.
Et puis il faut juger de leur pertinence et de leur gravité. Et là, c’est le drame : grave ou pas grave ? En théorie c’est facile de répondre. En pratique, bah… Ca dépend. Mais de quoi ? De plein de choses, et aussi de la personne qui remplit le formulaire. Ainsi que de si elle est bien ou mal lunée aujourd’hui.
La personne qui a créé le ticket, ça rentre aussi en jeu pour déterminer la gravité d’un bug : si c’est le big boss qui a créé le ticket, clairement le bug sera plus grave. À l’inverse, si c’est le client qui l’a créé, alors ce sera moins grave.
C’est pas tout ça, mais il faut aussi le corriger le bug. Et là ça devient de plus en plus compliqué. Parce qu’on n’a pas le temps pour tous les corriger, déjà. Alors il faut choisir. Et qu’en plus de choisir entre les bugs, il faut mettre ça en perspective avec toutes les autres choses à faire. Parfois, on n’a même pas de temps du tout pour corriger les bugs.
Et moins on corrige les bugs, plus ils s’accumulent. Alors ça commence à devenir vraiment, vraiment compliqué parce qu’en plus, quand il y a un nouveau bug, il faut voir s’il n’existe pas déjà. Et le jour où on veut en corriger un, qu’est-ce que c’est compliqué de s’y retrouver parmi tous ces bugs.
En plus de ça il faut régulièrement faire le tour de cette montagne de bugs, non pas pour les corriger, mais juste pour les garder à jour. Parce que si on ne les garde pas à jour ils ne seront jamais corrigés mais ils continueront quand même de nous compliquer la vie. Sauf que de les garder à jour, ça prend un temps fou, par exemple pour simplement vérifier s’ils existent toujours. Et oui, car on les a peut-être corrigés sans le faire exprès. Ou alors leur gravité n’est plus la même, à nouveau pour tout un tas de raisons.
J’allais oublier de vous dire que cette montagne de bug était peut-être partagée entre plusieurs équipes qui travaillent de concert sur le même projet. Et alors là, on ne sait même plus qui doit faire quoi pour qualifier, investiguer ou corriger les bugs. Forcément, ça rend les choses encore plus compliquées.
Sans aucun doute, la gestion des bugs, c’est pas simple.
Et si on essayait… de ne tolérer aucun bug
Imaginons une équipe ou une entreprise où tous les bugs doivent être traités dès qu’ils sont trouvés.
Ici, la gestion des bugs est super simple : on ne les tolère tout simplement pas.
Tu trouves un bug ? Tu l’investigues immédiatement et si la correction est rapide, tu le corriges dans la foulée.
Si la correction est longue mais que de toutes façons le bug a été introduit par un développement en cours, alors cela empêche le développement d’être considéré comme terminé.
Enfin, dans les autres cas de figure, on priorise la correction du bug pour la prochaine itération. En première priorité, avant tout le reste.
Ca va vous sembler fou, mais ça tourne très bien comme ça. Je sais qu’on dit qu’un logiciel sans bug ça n’existe pas, mais en ce qui nous concerne de corriger tous les bugs qu’on trouve ça nous réussit bien.
Déjà parce que du coup on fait tout notre possible pour ne pas introduire de bug dans le code, vu qu’il faudra bien les corriger sinon.
Ensuite parce que comme ça les bugs ne créent aucun bruit ou presque. Notre base de bugs est quasiment toujours vide, c’est très facile de s’y retrouver. On ne perd pas de temps à tenir à jour les vieux bugs, ou à décider quel bug faut-il corriger.
Et si on essayait… de traiter les bugs comme une part du backlog produit
Imaginons une équipe ou une entreprise où les bugs sont traités comme n’importe quels éléments du backlog produit.
Faisons face à la réalité : il n’y a que deux types de bugs dans la vie, ceux que l’on va corriger, et ceux que l’on ne corrigera pas.
Les bugs importants, on les priorise dans les itérations futures comme n’importe quel élément du backlog produit.
Les autres bugs, on les ferme directement car on sait qu’on ne les corrigera pas. Du moins pas dans les 3 mois qui viennent, ce qui correspond à la profondeur du backlog produit.
Et si on a eu tort d’ignorer un bug ? On s’apaise l’esprit en se disant que si c’est important, ça reviendra à nouveau.
Résultat : les bugs font partie intégrante du backlog produit, avec un statut clair et interchangeable avec les User Stories. On fait d’ailleurs l’effort d’assigner une Business Value aux bugs qui permet de les comparer aux User Stories.
Comme avec les User Stories, où celles à venir nous rappellent tout ce qui manque sur le produit actuel, les bugs encore ouvert nous rappellent les limitations connues.
Et si on essayait… de piloter la gestion de bug par les logs utilisateurs
Imaginons une équipe ou une entreprise où les bugs sont uniquement générés en lien direct avec les logs utilisateurs.
Chez nous, pas de bug sans log utilisateur qui le met en valeur.
L’intérêt, c’est déjà qu’on a un paquet d’information sur le bug. La qualification est directe.
Et surtout, on sait directement combien d’utilisateurs sont touchés et à quelle fréquence. On sait même si c’est grave ou pas pour les utilisateurs en fonction de ce qu’ils faisaient. On sait aussi si les utilisateurs touchés sont ceux qui vont dépenser beaucoup d’argent dans notre service ou si ce sont plutôt des utilisateurs gratuits…
Donc en résumé, chez nous, un bug :
Est forcément bien formé car bourré d’informations et de logs
Est qualifié par définition
A une gravité très claire chiffrée en nombre d’utilisateurs impactés et en chiffre d’affaire potentiel perdu
Est rarement en doublon
Est tenu à jour via les nouveaux logs utilisateurs qui nous disent s’il est toujours présent ou non
Du coup, la correction des bugs se fait assez naturellement puisqu’on a une vision très claire de l’impact sur le produit et pour le business.
Quant aux bugs qu’on ne corrige pas, ils sont connus et bien répertoriés.
Bien sûr, tout cela nécessite une quantité de logs assez monstrueuse, ainsi que pas mal d’outillage pour pouvoir les utiliser efficaement… Mais maintenant qu’on y a goûté, difficile de revenir en arrière. Surtout que ça ne nous sert pas que pour remonter et qualifier les bugs : c’est une véritable mine d’or pour comprendre nos utilisateurs et optimiser la performance de notre produit. Est-ce que ça ne serait pas ça ce qu’on appelle être data-driven ?
Et si on essayait… de garder les produits petits
Imaginons une entreprise où les lignes de produit sont très bien délimitées, de sorte qu’ils ne sont gérés que par des équipes indépendantes les unes des autres.
Ah les bugs ! C’est la galère, pas vrai ? Ouais je crois que c’est comme ça partout…
Bon après je trouve qu’on ne s’en sort pas trop mal. Il faut dire qu’on a de la chance : notre produit est indépendant des autres. Du coup, quand il y a un bug sur notre produit, on sait que c’est à nous qu’il faut parler. C’est pas grave si on nous fournit un rapport de bug un peu bidon, on se parle et on s’en sort.
Comme on a une maîtrise de bout en bout de notre produit, on arrive assez bien à qualifier et prioriser les bugs. En fonction du bug, on décide entre nous s’il faut le corriger tout de suite ou plus tard.
Il y a toujours trop de bugs, c’est sûr 😃 mais ça va ça reste gérable, le produit n’est pas si énorme, donc forcément la base de bug est raisonnable. C’est logique. Ce qui fait que globalement on les connait tous, ces bugs. Dès qu’un nouveau bug arrive, on sait immédiatement si c’est un doublon ou pas. Quand on change un comportement fonctionnel, on pense immédiatement aux bugs existants pour vérifier si ça peut les corriger ou pas.
Si je résumais la situation, je dirais qu’on n’est pas très carré dans notre gestion des bugs mais comme on a la chance d’avoir un petit produit, alors la base de bugs reste gérable et on s’en sort bien comme ça.
Vous avez aimé cet article ? Montrez-le !
Merci d’applaudir 👏 et de partager cet article ! C’est pour vous que je met autant de cœur à l’ouvrage.
Et suivez-moi sur mon blog pour être notifié des nouveaux articles !
Merci pour tout !