On appelle anomalie, “ano” ou “bug” un défaut de conception d’un programme informatique qui cause un dysfonctionnement du système. Ces mots peuvent désigner indifféremment la conséquence du problème (lorsqu’il est décrit par un Product Owner ou Product Manager) et la cause technique du problème (lorsqu’il est traité par les développeurs).
Il est difficile de se prémunir totalement des anomalies ; plus un projet devient complexe, plus la probabilité qu’une erreur échappe à la vigilance des développeurs et testeurs est importante. La réalisation systématique de tests unitaires et de tests end-to-end permettent de limiter l’apparition de bugs. De même, l’écriture de tests d’acceptation propres à chaque user story le permet aussi.
Lorsqu’on découvre un bug, que ce soit en cours de sprint ou après la validation d’une user story, il est important de le matérialiser sous la forme d’un post-it (si possible de couleur vive) sur un board kanban et / ou via un ticket dans un outil comme JIRA.
La gravité d’une anomalie est variable : certaines se traduisent par des erreurs d’affichage, d’autres font “planter” des systèmes entiers. Dans tous les cas, corriger les bugs prend du temps. La priorisation entre correction des anomalies et le développement d’une nouvelle user story incombe alors au PO.
La plupart des Product Owners et des coachs agiles estiment que l'on ne doit pas chiffrer les anomalies :
- Le « coût » d’un bug réside essentiellement dans une phase d’analyse du problème et non dans un développement correctif. Il est difficile d’évaluer la durée de cette phase a priori
- Si on chiffrait les bugs, le temps passé à corriger les bugs viendrait impacter positivement la vélocité de l’équipe. Or l’objectif est plutôt de minimiser le nombre de bugs ; ainsi il se focalise sur la valeur client (contenue dans les user stories)
- Pour certains “petits” bugs, le temps passé à les estimer deviendrait disproportionné par rapport au temps nécessaire pour les corriger
Pour autant, le PO priorise les bugs en fonction de leur criticité et peut choisir en accord avec les développeurs de timeboxer sa résolution.
Il peut être intéressant de suivre un indicateur du nombre moyen d’anomalies constatées par Story validée ; on mesure ainsi la pertinence des tests unitaires et end-to-end effectués, la qualité du développement mais aussi la rigueur de l’équipe de tests.
Pour aller plus loin : Téléchargez notre livre Les Clés du Product Management
