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.

2 Comments Anomalie

  1. Maximilien

    Hello,
    Si les bugs chiffrés impactent positivement la vélocité de l’équipe lors leurs résolution, les intégrer au Sprint sans les chiffrer impactent alors la vélocité et les burn-down charts négativement, cela voudrait donc dire que le PO intégre au prochain Sprint un nombre de US correspondant au nombre de story points totale de l’équipe, et un certain nombre de tickets non estimés ? L’equipe ne pourra donc pas traiter toutes les US/Bugs durant le Sprint et démarre déjà pénalisé.
    J’ai pour habitude d’intégrer les bugs au Backlog Grooming afin d’avoir une estimation grossière de la part de l’équipe technique, et de les prioriser sur les prochains Sprints avec le ratio criticité/compléxité à résoudre, en évitant de dépasser un quota de 15% de bugs / 85% de User stories afin de délivrer un maximum de valeur au produit.

    Bien qu’il soit difficile en effet d’estimer un bug, je trouve que le timeboxing en story points est souvent la bonne méthode, permet une meilleur intégration dans la préparation du Sprint coté PO, et permet également aux Développeurs de venir solliciter le PO à la fin du temps passé sur le ticket (correspondant au score) afin de trouver un compromis sur la résolution, plutot que de rester bloqué sur le bug plusieurs jours. Le timeboxing déclenche en fait une réelle discussion PO/Devs, et implique souvent un gain de temps dans un environnement changeant rapidement.
    Si le bug est très critique (hotfix), il est intégré au Sprint non estimé, et sera estimé retrospectivement en Consume Points, afin d’avoir un nouveau point de référence dans l’estimation des futurs bugs.

    Qu’en penses vous ?
    Toujours un plaisir de vous lire !
    Maximilien.

    Reply
    1. Benjamin Fourio

      Bonjour Maximilien,

      Merci pour ce commentaire.
      Je préfère prévenir que ma réponse n’engage que moi et non tous les Thiguys. J’ai en effet peur que sur le sujet il y’ait pas mal d’avis différents !

      Pour ma part je préfère que l’équipe ne perde pas son temps à estimer les bugs, car :
      – la qualité est une priorité, je déteste les bugs et je veux les éradiquer : tous ! et peut-importe l’impact sur la vélocité (mais ok, selon le contexte c’est pas toujours possible)
      – j’aime le no-estimate d’une façon générale
      – les estimations servent trop souvent pour répondre à des problématiques comptables (capacité, vélocité, prédictibilité…), au lieu d’encourager avant tout la discussion entre les membres de l’équipe pour s’assurer que tout le monde comprenne le besoin
      – réserver de la capa pour les bugs c’est aussi accepter d’inscrire la non-qualité dans une norme : je sais que j’ai des bugs mais j’ai un % de ma capa pour les résoudre
      – les estimations sont… fausses

      Je suis donc très en phase avec ton approche qui consiste à timeboxer l’analyse, et ensuite décider de ce que l’on fait (poursuite de l’analyse, résolution immédiate, ou différée).

      Que l’on utilise des points pour les estimations ou que l’on fasse du no-estimate, on peut se baser sur 2 métriques :
      – Ratio Defects/US : combien (en moyenne) je génère de bugs par stories DONE
      – Le débit : combien d’US DONE dans un sprint en moyenne

      Connaitre ces 2 métriques permet – sans faire d’estimations en points – de facilement juger de la pertinence de l’engagement de l’équipe lors du sprint planning. Et si on base la prédictibilité sur le débit, alors on tient compte du temps généralement gaspillé à résoudre les defects. Le buffer est donc intégré par design.

      Ainsi pas besoins de calculs savants ! et on fait l’économie du temps d’estimation pour résoudre plus de bugs 🙂

      Reply

Laisser un commentaire

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