Anomalie

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 croît en complexité, 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, tout comme l’écriture de tests d’acceptation propres à chaque user story.

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 kamban 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 et la priorisation entre correction des anomalies et le développement d’une nouvelle user story incombe au PO.

La plupart des Product Owners et des coachs agiles estiment que les anomalies ne doivent pas être chiffrées :

  • 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 les bugs étaient chiffrés, 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 pour se focaliser sur la valeur client (contenue dans les user stories)
  • Pour certains “petits” bugs, le temps passé à les estimer serait 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.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *