Corriger les bugs rapidement et facilement

La correction des bugs était déjà un défi dans le développement logiciel bien avant Scrum. Les itérations courtes en Agile ne facilitent pas forcément la tâche des équipes pour décider quels bugs doivent être corrigés et lesquels peuvent encore attendre.

La bonne nouvelle, c'est qu'une équipe Scrum a généralement beaucoup moins de bugs qu'une équipe travaillant avec des frameworks de développement plus traditionnels. Mais même les équipes agiles découvrent de temps en temps un bug ou deux, surtout lorsqu'une partie du développement date d'avant la transition vers une approche agile. Et pour prioriser ces défauts, l'équipe a besoin d'une solution efficace.

Priorisation des corrections de bugs : Ce qu'il ne faut pas faire

Tôt dans ma carrière de programmeur, mon chef a mobilisé toute l'équipe pendant une semaine entière pour discuter de tous les défauts connus. Nous avons parlé des causes possibles, de la gravité de chaque bug, de sa fréquence d'apparition, de sa reproductibilité, de l'endroit dans le code où l'erreur pouvait se trouver et de qui parmi nous devait résoudre ce problème.

Nous avons même estimé le temps nécessaire pour chaque bug. Ces estimations étaient non seulement assez inutiles dans la plupart des cas, mais il fallait souvent plus de temps pour faire l'estimation que pour simplement corriger le bug.

Après ces premières expériences, quand j'ai commencé à diriger des équipes, j'ai commencé à expérimenter d'autres approches plus légères.

Aujourd'hui, je voudrais te présenter ma méthode préférée pour corriger les bugs.

Lignes directrices pour la priorisation des bugs

Au lieu de prendre le temps de réfléchir à chaque bug individuellement, il vaut mieux créer des directives qui définissent la rapidité avec laquelle un bug doit être corrigé, ou l'importance du défaut, c'est-à-dire la gravité du problème lors de l'apparition du bug.

Exemple 1 : L'une de ces directives pourrait être que tout bug affectant tous les utilisateurs de manière dramatique doit être corrigé immédiatement, ce qui signifie interrompre les travaux en cours dans le Sprint. Une autre directive pourrait par exemple stipuler que les bugs qui n'apparaissent qu'extrêmement rarement et n'empêchent pas l'utilisateur d'exécuter les fonctions principales sont notés et corrigés sans pression, dès que du temps se libère.

Créer et utiliser des directives s'appelle aussi la priorisation par politique (prioritization by policy).

Exemple 2 : Un exemple un peu plus concret serait si le Product Owner se met d'accord avec son équipe que tout bug empêchant les utilisateurs de passer des commandes sur leur site eCommerce doit être corrigé le plus rapidement possible.

D'autres directives peuvent concerner des bugs qui ne devraient être corrigés qu'en fin de journée, en fin de semaine, voire pas du tout.

Définir les directives de défauts

Les réflexions suivantes sont utiles pour formuler des directives de correction de bugs :

• Probabilité d'un défaut : À quelle fréquence le problème survient-il ?
• Gravité d'un défaut : Quelle est la gravité du problème lorsqu'il survient ?

Imagine qu'Amazon ait un bug qui empêche les commandes d'une valeur de 1 million de dollars d'être passées, parce qu'un développeur a supposé qu'une commande ne dépasserait jamais 999 999,99 dollars.

C'est problématique si ce cas se produit (gravité élevée), mais je pense qu'Amazon ne reçoit pas beaucoup de commandes dépassant 1 million de dollars (faible probabilité).

Création de la matrice de directives des défauts pour prioriser les bugs

Les deux dimensions – gravité et priorité – peuvent être combinées pour définir la politique de priorisation d'un défaut. Une telle matrice peut aider :

Il existe de nombreuses façons de classer la probabilité et la gravité des bugs. Dans l'exemple du site e-commerce, la probabilité est exprimée par le pourcentage de transactions affectées. Tout ce qui impacte 10% ou plus des transactions est assez important, c'est pourquoi j'ai classé toute la colonne en priorité haute ou très haute.

Pour évaluer la gravité d'un défaut, on peut se demander s'il existe une solution de contournement et si elle est évidente ou plutôt difficile à trouver. Sur un site e-commerce, il peut par exemple y avoir deux boutons "Acheter maintenant" mais un seul fonctionne.

Les cellules de la matrice indiquent quelle directive s'applique aux défauts ayant une probabilité et une gravité données. Dans cet exemple, j'ai choisi cinq niveaux de priorité différents – de très bas à très haut. Dans certains cas, trois niveaux peuvent suffire. Je déconseille d'en utiliser plus de cinq, mais j'ai déjà vu cela aussi.

Voici comment j'utilise les cinq niveaux de priorité :

• Très élevée : Intégrée immédiatement dans l'itération en cours, même si cela implique de mettre d'autres travaux en pause. Peut nécessiter plus d'un membre de l'équipe, voire l'équipe entière.

• Élevée : Intégrée immédiatement dans l'itération en cours, même si cela implique de mettre d'autres travaux en pause. L'équipe décide qui est le mieux placé pour résoudre le problème.

• Moyenne : Peut être intégrée dans l'itération en cours à la discrétion du Product Owner.

• Basse : Documentée et discutée lors du prochain Planning Meeting à la discrétion du Product Owner.

• Très basse : Documentée dans la liste des problèmes connus. Ne sera abordée à nouveau que si la probabilité ou la gravité change, ou à la discrétion du Product Owner.

Avantages de la priorisation par directives

Le principal avantage de cette approche est qu'on passe beaucoup moins de temps à discuter de ce qu'il faut faire avec chaque défaut individuel. Ce type de priorisation des bugs demande un certain effort initial pour créer les directives. Cependant, une fois ces directives établies, la priorisation des nouveaux défauts devient un jeu d'enfant.

L'objectif de cette approche est de rendre la priorisation des défauts plus objective que subjective. Bien sûr, quelqu'un devra décider de la fréquence probable d'apparition d'un problème, mais à part cela, la priorisation elle-même ne prendra pas plus de temps que de consulter la matrice de priorisation.

Cet article provient du blog de Mike Cohn et a été traduit par nos soins.

Séminaire Product Owner

=> Deviens Product Owner certifié et participe à l'une de nos formations

Exigences non fonctionnelles

=> Découvre comment transformer les exigences non fonctionnelles en User Stories.

Product Scorecard

=> Découvre si ton produit contribue à la stratégie de l'entreprise et utilise la Product Scorecard.