Traiter ses bugs : essentiel mais pas si simple !

Les bugs, tout le monde en a, personne ne sait comment les traiter efficacement. C’est ce qui ressort des nombreuses conférences et articles de blogs sur ce thème.

Disclaimer : on n’a pas non plus résolu ce sujet, mais on expérimente plusieurs modes de travail et on espère qu’en les partageant on trouvera de nouvelles inspirations.

Commençons par le commencement : c’est quoi un bug chez MeilleursAgents ?

Un bug, c’est un dysfonctionnement constaté en production.

En d’autres termes : une fonctionnalité qui aurait dû rendre un service à l’utilisateur, mais qui est cassée quand il tente de s’en servir.

Nous avons mis plusieurs mois avant d’atterrir à une définition commune et ne plus avoir les réflexes “pendant que je testais cette fonctionnalité sur un environnement de développement, j’ai trouvé un bug”.

De cette définition sont exclus les ratés fonctionnels (ou trous fonctionnels) : quelque chose qui n’était pas prévu lors de la conception et qui aurait dû être prévu (par exemple, on envoie des SMS à des clients B2B le weekend parce qu’on a oublié de gérer les jours ouvrés).

Sont exclus également les retours de la phase de QA ou de recette qui a lieu sur des environnements de développement ou de test. Puisque l’outil n’est pas dans les mains des utilisateurs finaux et en production, ce que l’on identifie relève du retour et non du bug.

Pourquoi être si tatillon ? Parce qu’un grand nombre de bugs frustrent, agacent, dénotent d’un problème de qualité plus global, et restent une mesure intéressante de la qualité du travail fourni par l’équipe (Point important : on utilise cette mesure pour s’améliorer, pas pour blâmer).

Criticité et urgence : swimline dédiée.

Ok, maintenant qu’on a un bug, on fait quoi ? L’étape 1 pour le Product Manager est de le qualifier au mieux et de déterminer sa criticité. Nous n’utilisons à ce jour que deux niveaux de criticité :

• Blocker : le bug mérite que quelqu’un de l’équipe interrompe son travail, malgré l’impact bien connu du context-switching, pour que le bug soit résolu dans les plus brefs délais.
• Normal : le bug peut attendre un autre sprint.

Il est probable que nous nous limitions dans notre capacité de priorisation du fait de l’utilisation de seulement deux niveaux de criticité à ce jour.

Pour traiter un bug urgent, nous avons créé un “raccourci” qui lui permet de traverser notre process de développement le plus vite possible. Puisque nous utilisons un Kanban sur l’outil Jira, nous avons comme beaucoup d’équipes ajouté une Swimline “Urgent” par laquelle rentrent les bugs blockers.

Les étapes de notre flux de développement

Lors de ma première expérience @AppaloosaStore, nous appelions ça joliment les Silver Bullets : des tickets qui doivent avoir un Time To Market le plus proche possible de zéro.

Pas besoin de grande science pour déterminer la criticité d’un bug.

• Le site ne marche plus ?
• Les clients n’ont plus accès à une fonctionnalité qu’ils paient ?

Si la réponse à une de ces questions est oui, le bug est probablement une urgence et mérite que une ou plusieurs personnes de l’équipe interrompent leur tâche pour le traiter.

Comment traiter les bugs non-critiques ?

Tentative #1 : les mathématiques empiriques

Un sprint de 15 jours = 10 bugs traités.

Une formule simple pour calculer le nombre de bugs à traiter

C’est la règle empirique à laquelle l’équipe est arrivée en début d’année. Au lieu de prévoir un temps dédié à la gestion des bugs, on a considéré qu’on devait embarquer un nombre réduit de points de complexité dans le sprint et que le reste du temps serait réparti entre gestion des bugs, réunions et toute autre activité ne concernant pas nos User Stories.

Problème

Ce système ne permet pas de matérialiser le temps réellement consacré aux bugs, et n’encourage pas la priorisation entre les différents objets du backlog, notamment entre User Stories et bugs.

On se retrouve à tenter de prendre 10 bugs, qu’ils soient longs ou courts, et on considère qu’on a mal travaillé en fin de sprint si les 10 bugs n’ont pas été traités, quand bien même un des bugs aurait pris plus d’une semaine à résoudre.

Pour ces raisons, nous avons abandonné ce système.

Tentative #2 : un Product Manager est le gardien de l’équipe pendant un Sprint ; il est en charge de spécifier et prioriser les bugs.

Nous avons défini un rôle dans l’équipe Produit : celui du protecteur. Il s’agit d’une personne désignée, qui change tous les quinze jours (à chaque Sprint) et qui est le responsable de gérer l’entrée des bugs. Il doit donc le qualifier et prévoir sa place au sein des Sprints.

L’objectif en créant ce rôle est de ne pas passer à côté d’un bug qualifié Urgent et de ne pas laisser tomber de balles. En plus, cela va nous permettre d’être très réactifs et de faire un retour aux personnes qui ont remonté le bug. Car la moindre des choses, avant même de le résoudre, est de garantir qu’il a bien été pris en compte.

Nous avons nommé un protecteur B2B et un protecteur B2C pour traiter les différentes typologies de bugs, car à ce moment de notre histoire, nous avions séparé les expertises de nos Product Managers selon cet axe.

Malheureusement, la mayonnaise n’a pas pris.

Le malheureux Protecteur

Problème

Le protecteur est un moyen de régler le problème de la prise en charge des bugs et réduire notre temps de réponse.

Par contre, ce système ne donne aucune clé pour gérer les bugs. Globalement, le protecteur finit par avoir le sentiment de recevoir des bugs et de les ranger dans une pile… de laquelle ils ne sortiront jamais.

En ne traitant qu’un morceau de la chaîne (l’entrée des bugs) au lieu de mettre en place un système plus complet, nous avons rendu impossible l’adoption de cette pratique.

Tentative #3 : pour passer des bugs, on les rend urgents

Décision prise main dans la main avec notre équipe technique, nous nous sommes dit que la swimline Urgent pourrait contenir deux types de bugs : les bugs vraiment urgents, et ceux que l’équipe produit pense importants à traiter à l’instant T du sprint.

Pour expliquer plus précisément, il se peut qu’un bug ne soit pas bloquant, mais qu’il puisse être plus important que les prochaines User Stories à développer. Au lieu de le prioriser dans les swimlines des User Stories, nous le passons directement en Urgent pour que le prochain développeur disponible le traite.

Vous voyez arriver le …

Problème

Quand tout est urgent, rien n’est urgent. Et quand tout est bloquant, rien n’est bloquant. Nous nous sommes donc rapidement retrouvés avec une dizaine de bugs bloquants dans cette swimline. On n’arrivait plus à différencier les véritables urgences des bugs simplement “à faire”.

Ce n’est pas ce que vous croyez

L’organisation cible : un bug est une User Story comme une autre

Comme une User Story, le bug doit être pris en charge par un Product Manager de l’équipe. Il a la responsabilité de le comprendre, le qualifier, et le prioriser par rapport aux autres sujets qui doivent être traités. Pour ne pas qu’une seule personne gère l’ensemble des bugs, le système de protecteur que nous avions tenté d’utiliser est une bonne piste, à condition d’être rigoureux et de donner à ce protecteur tous les outils pour pouvoir gérer convenablement le bug.

Nous sommes une chaîne de production qui manipule au quotidien des objets différents : bugs, User Stories, cadrages, sujets techniques. Ces objets ont des caractéristiques communes :

• Ils sont chiffrés (que ce soit pour les prioriser ou les timeboxer)
• Ils passent par le même processus (spécification -> développement -> Pair Review -> QA -> Mise en Production)
• Ils occupent une à plusieurs personnes de l’équipe

Notre cible devrait nous permettre de manipuler ces bugs comme les autres objets qui traversent notre chaine de production.

Le chiffrage des bugs est le point le plus complexe au sein de notre équipe : nos développeurs ne voient pas comment chiffrer quelque chose d’imprévu en production. Pour la Scrum alliance, la réponse ne diffère pas de comment chiffrer une User Story : si on ne sait pas la chiffrer, c’est qu’il manque des éléments pour le faire. On peut alors prévoir un temps contraint (par exemple une demi journée) pour y voir plus clair. Si le bug est traité pendant la demi journée, tant mieux. S’il ne l’est pas, le livrable de cette demi journée est une vision plus claire sur les causes et les travaux pour corriger le problème.

Une fois la question du chiffrage réglée reste celle de la priorisation. Là encore, pas de magie : la question à se poser est “est-ce que j’apporte plus de valeur à l’utilisateur en corrigeant ce bug ou en réalisant cette User Story qui attend sagement dans mon Sprint Backlog ?”. Pour répondre à cette question, toutes les méthodes classiques de priorisation du backlog sont bonnes : VRAC, RICE etc.

C’est pour cet enjeu de priorisation qu’il est indispensable de ne pas créer une swimline dédiée aux bugs dans le Kanban, car on va terminer avec une décharge dans laquelle les bugs entrent mais ne sortent jamais.

En résumé, nous nous orientons vers le système suivant :

• Désigner un membre de l’équipe pour accueillir les bugs et les qualifier
• Chiffrer les bugs (et si on ne sait pas les chiffrer, allouer un temps limité pour mieux les comprendre)
• Intégrer les bugs aux swimlines des équipes et les prioriser par rapport à des User Stories

Nous testons ce système depuis deux semaines, et voyons les premiers bénéfices :

• Un temps de réponse réduit pour informer de la bonne prise en charge des bugs.
• Plusieurs résolutions de bugs sont passés au fil de l’eau dans le sprint et sans se poser de questions.
• Un bug urgent a été traité en moins d’une heure, montrant l’efficacité de cette swimline dédiée.

Edit (11/04/2018) : voilà les résultats de l’application de ce système !