read time

1 min

dico du produit

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 Agile Product Management

Publié le 24 oct. 2015

Mis à jour le 28 janv. 2022

clipboardCopier le lien
Ecrit par
Hugo Geissmann
Hugo Geissmann

Les prochains évènements

Le No-Code pour les PM

calendar

31 jan 2022

Découvrir

Comment se lancer dans le No-Code ?

calendar

31 jan 2022

Découvrir

Le No-Code pour construire des back-offices/SaaS

calendar

1 fév 2022

Découvrir

La Product Conf Paris

calendar

9 juin 2022

Découvrir

Filles_ordinateur

Envie de partager tes idées ?


Plus de 20.000 passioné.e.s du Produit viennent sur notre média chaque mois. Retours d’expérience, opinions clivantes, n’hésite pas à nous proposer des contenus.

 

Contacter la rédaction