La gestion des défauts

Face à la réalité

Le meilleur des mondes serait celui où les défauts n'existent pas, où les bugs n'empêcheraient jamais nos clients de travailler. En attendant d'en arriver à cet idéal, nous devons apprendre à gérer les défauts que nous produisons.

Un des piliers de Scrum est la "Visibilité", alors ne pas les gérer devient un péché. Quoi de pire qu'une version de logiciel planifiée sur 6 mois avec, par exemple, une trentaine de défauts à corriger non estimés en effort, et un release burndown qui montre que tout va bien, nous sommes dans les temps? Cela revient à conduire dans le brouillard avec un oeil caché!

Il y a, selon moi, 3 aspects à considérer pour sortir du brouillard:

• Est-ce bien un défaut et non une amélioration? Une limitation, bien que gênante, n'est pas un défaut.
• La criticité pour nos clients. Elle va nous aider à décider quand corriger le défaut.
• La taille du défaut. Elle va nous donner plus de précision sur l'avancement du projet.

Chaque projet, chaque équipe doit trouver le moyen le plus adapté à son contexte pour gérer les défauts. Néanmoins, il convient d'avoir les éléments suivant en tête:

• Il n'y a pas de Scrum sans IPPS (Incrément de Produit Potentiellement Shippable/Livrable).
• Plus un défaut est corrigé tard, plus il coûte cher.

Quelques pistes à considérer

Je trouve intéressante la solution décrite par Mitch Lacey car elle permet une correction plus ou moins immédiate suivant 4 niveaux de criticité P0 à P4 :

- P0 Catastrophique : Fonctionnalités majeures du système ne fonctionnent pas. Il y a aucun moyen de contourner le défaut.

- P1 Haute : Fonctionnalités majeures du système ne fonctionnent pas. Il existe un moyen de contourner le défaut.

- P2 Modéré : Utilisabilité du système diminuée

- P3 Basse : Peu d'impact; défaut d'aspect, désagrément

Quand un défaut est identifié, il est rapidement classifié et deux scénarios peuvent être suivis:

--> Soit c'est un P2 ou P3 et le défaut est ajouté au product backlog avec tous les éléments nécéssaires à sa reproduction afin d'être priorisé par le Product Owner.

--> Soit c'est un P0 ou P1 et sa correction doit-être entreprise immédiatement. Sachant que certain défauts sont parfois grave mais ne prennent que quelques dizaines de minutes à corriger, la solution décrite permet de ne pas créer de travail administratif si en une heure, le défaut est corrigé.

Claude Aubry décrit une approche similaire appliquée au projet IceScrum

J'aime aussi la pratique d'Alexandre Boutin lorsqu'il accupait la fonction de Process Group Manager; je cite : "Si le backlog comptabilise plus de 10 défauts, je vais voir l'équipe et lui demande d'arrêter tous les travaux en cours et de diminuer ce nombre pour qu'il soit en dessous de 10". Cette pratique très Lean, permet de maîtriser le coût des défauts et de les corriger avant que d'autres fonctionnalités soit ajoutées sur une base défectueuse.

Le coût des défauts

Pour finir, j'aimerais mettre l'accent sur le coût des défauts. Il est bien connu que plus le défaut est trouvé tard dans le cycle de développement, plus son coût de correction est important. Un bug trouvé lors de la phase de développement sera moins cher à corriger qu'un défaut identifié juste avant le déploiement. Évidemment, chez les clients, c'est encore pire. Ensuite, tout défaut devant être corrigé avant la sortie d'un logiciel va apporter un retard sur l'amortissement de son développement. On peut imaginer la catastrophe si un concurrent commercialise un logiciel similaire pendant que nous corrigeons des défauts ... le coût des défauts devient extrêmement important.

Une fois le défaut identifié, là encore, nous pouvons faire monter la facture en fonction du délai de correction. La gestion administrative des défauts a un coût, ils "polluent" le backlog, il nous gênent dans l'avancement du projet. Ainsi, un défaut P0 critique corrigé en 2 jours dès son identification pourra coûter moins cher qu'un défaut P3 moins important corrigé en 2 heures mais 10 semaines plus tard. Pour mesurer la portée de ces propos, nous pouvons imaginer une nouvelle unité pour mesurer le coût des défauts : le "$Day". En reprenant l'exemple ci-dessus, en considérant qu'une heure de travail vaut 100$, le défaut P0 vaut 1600 $Day alors que P3 vaut 16000 $Day soit 10 fois plus. Cette unité est à considérer de manière relative comme l'effort des éléments du Backlog, elle reflète un coût mais n'est pas directement convertible en dollars.

Que pensez-vous de ces approches? Comment gérez-vous les défauts?