La gestion des bugs dans le projet IceScrum

La gestion des bugs, ou plus exactement des défauts, varie selon les projets. Même si l'objectif ultime avec une méthode agile est de ne pas avoir de défauts dans le code, dans la vraie vie des projets il y a toujours des défauts. Et il faut s'en occuper, en gardant à l'idée que c'est moins cher de les corriger tôt que tard.

Je vais vous raconter comment nous traitons les défauts sur le projet de développement de l'outil IceScrum, dont je suis le Product Owner. L'approche que nous suivons est adaptée à notre contexte, il n'est pas sûr qu'elle puisse s'appliquer de la même façon sur un autre projet.

Sources qui peuvent identifier des défauts

IceScrum est un logiciel Open Source disponible en téléchargement. Les utilisateurs, qui ne sont pas connus à priori, disposent d'un Jira pour enregistrer les défauts qu'ils rencontrent. De mon côté, avec d'autres intervenants impliqués sur le projet, j'utilise les builds produits régulièrement par l'équipe.
L'équipe ne dispose pas d'une salle permanente. Le projet est géré avec l'outil ... IceScrum. Le Jira ne sert qu'à l'enregistrement des défauts pour les utilisateurs, il ne sert pas du tout à leur gestion, qui est faite avec IceScrum.

Gravité des défauts

Un défaut est quelque chose qui enlève de la valeur à une story.

  • Un défaut critique empêche le fonctionnement d'une ou plusieurs stories, dont la valeur devient nulle.
  • Un défaut majeur ne permet pas un fonctionnement normal et fait perdre une grande partie de la valeur à la story.
  • Un défaut mineur fait perdre un peu de valeur à une story en rendant son fonctionnement plus difficile.

Etat de la story concernée

La story sur laquelle porte le défaut peut être :

  • finie. Parce qu'elle a été effectivement développée dans une itération précédente et qu'elle a été considérée comme finie. A tort, mais c'est la vie. Rentrent aussi dans cette rubrique les défauts qui portent sur des parties développées avant que le projet mette en place un processus agile.
  • en cours. Elle est associée à l'itération courante. Elle a été incluse dans un build intermédiaire.

Traitement des défauts sur stories en cours

C'est simple : un défaut est une condition de satisfaction en échec. La story n'est pas finie. L'équipe ajoute les tâches qu'il faut pour corriger le défaut (code, test) et les réalise pour finir la story avant la fin du sprint.

Traitement des défauts sur stories finies

Traitement des défauts critiques

Un défaut critique est traité de façon prioritaire. Lorsque je suis informé d'un défaut critique, je crée une tâche dans le backlog de sprint. Je lui associe un reste à faire d'une heure. Alors, dans l'équipe de développement, une personne (ou un binôme) arrête son travail en cours pour étudier le défaut, identifier sa cause et corriger le défaut, en mettant à jour les tests automatisés.
Si tout ça est fait en une heure, il suffit alors de déclarer la tâche finie. Si le travail demande plus d'une heure, il faudra alors identifier les tâches nécessaires pour la résolution et les ajouter dans le backlog de sprint.
Il est probable que cela aura un impact sur le périmètre du sprint. Il convient de ne déclarer comme critique ce qui est vraiment catastrophique pour l'usage du produit, sans solution de contournement.

Traitement des défauts majeurs

Un défaut majeur suit le même processus au début. La différence c'est que si la correction n'est pas finie en une heure, on crée une entrée dans le backlog de produit, avec comme type defect. Le défaut sera alors estimé et corrigé dans une prochaine itération.

Traitement des défauts mineurs

Un défaut mineur va directement dans le backlog de produit.

Commentaires

1. Le mardi 10 février 2009, 12:25 par temps

Parfois un seul terme dans la ligne de codes suffit pour créer le défaut. Souvent le détecter, c'est aussi le réparer.
cordialement

2. Le mardi 10 février 2009, 13:49 par Pascal

Petite précision relative à la prise en compte d'un bug sur une storie en cours....C'est uniquement les développeurs qui peuvent remonter cet évènement et non le directeur produit puisqu'il n'a pas de livrable, n'est-ce pas ?

Si si il y a production d'un build intermédiaire et le Product owner (directeur de produit) l'utilise pour des tests. Pour le projet IceScrum, les sprints sont de 3 semaines et on me livre un build au moins une fois par semaine.

Dans l'affirmative, pourquoi les développeurs ne passent-ils pas le temps nécessaire pour corriger l'anomalie rencontrée au risque de ne pas compléter le sprint ?

3. Le mardi 10 février 2009, 20:34 par david

a la notion de gravité critique on peut ajouter le critère de "contournement impossible pour fournir le service attendu". d'expérience, ca aide a identifier les gravités.

sinon, tu pourrais renvoyer vers tes autres excellents billets sur la "dette technique".

sur ce dernier point, je suis partisan de ne pas logger chaque anomalie dans le backlog sprint+1 mais de consacrer une sorte de provision pour correction de bugs (estimée bien sur)

4. Le lundi 16 février 2009, 23:33 par JM.D

Les bugs qui sont trouvés par une "source interne au projet" mais qui ne vont pas être traités dans le sprint (inscrits dans le backlog de produit pour plus tard) deviennent potentiellement "visibles" par un utilisateur du produit potentiellement livrable en fin de sprint. Je suis alors d'avis de les enregistrer dans le Jira, permettant ainsi de faire connaitre le reliquat des bugs d'une version.
Le Jira me parait alors utile pour "rassurer" les utilisateurs (source externe au projet) sur la prise en compte future des bugs identifiés.