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 Les Clés du Product Management

Publié le 24 oct. 2015

Mis à jour le 26 mars 2024

clipboardCopier le lien
Ecrit par
Hugo Geissmann
Hugo Geissmann Hugo, co-fondateur et PDG de Thiga, a débuté chez ATOS Origin en 2008, puis rejoint Xebia en 2010. Créateur de Xebia Studio, il a lancé Thiga en 2013 avec Alexandre pour promouvoir le Product Management en France. En une décennie, Hugo a marqué la communauté Produit française en lançant la Product Conference et contribuant au premier "contrat agile". Investisseur dans des startups comme Tabesto, Ottho, RenovationMan, Hugo est un acteur clé du secteur tech, participant à des ouvrages sur le Product Management.

Les prochains évènements

La Product Conf Paris

calendar

15 May 2024

Découvrir

Transformed Workshop by Marty Cagan

calendar

25 Apr 2024

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