Évaluation d'un bug impossible à reproduire
Comment évaluer un bug impossible à reproduire : vous ne pouvez pas estimer le temps nécessaire à la correction, mais uniquement celui de la recherche. Comment fixer une durée limite à l'investigation plutôt que de voter sur une tâche que personne ne peut voir.
Si vous ne pouvez pas reproduire le phénomène, vous ne pouvez pas l’estimer. Vous pouvez l’estimer en le recherchant.
Un bug impossible à reproduire, c’est comme si deux inconnues partageaient un même ticket. La première inconnue est la cause : il y a un symptôme en production, mais aucun moyen fiable de le reproduire localement, aucune trace de pile cohérente, aucune ligne dans les journaux qui le précède systématiquement. La deuxième inconnue est la correction, qui dépend entièrement de la première. Attribuer un score à la correction avant que la cause ne soit connue revient à se prononcer sur une tâche que l’équipe ne peut pas réellement visualiser.
La solution n’est pas toujours difficile à mettre en œuvre une fois que l’on a identifié la cause : il suffit souvent de modifier une seule ligne de code. C’est la recherche de la cause qui coûte cher. L’estimation du temps nécessaire à la recherche est réaliste ; celle du temps nécessaire à la correction relève de l’espoir.
Ce qui se dit dans la salle
Ingénieur A : « Je pense que cela vient de l’invalidation du cache. »
Ingénieur B : « Je pense que c’est une question de motivation chez le salarié. »
Introduction : « Quelqu’un a-t-il déjà réussi à y parvenir à la demande ? »
Question : « Nous avons essayé une vingtaine de solutions. Aucune n’est fiable. »
Assistance : « Il y a trois utilisateurs par semaine, toujours le mardi après-midi. »
Questions qu’il convient de se poser avant de voter
- Quel est ce symptôme, et à quelle fréquence se manifeste-t-il ?
- Avez-vous déjà mis en place la journalisation sur les chemins concernés, ou devons-nous d’abord l’ajouter ?
- Y a-t-il un client dont le compte est connu pour présenter un problème et sur lequel nous pourrions reproduire le problème ?
- Quel est le coût hebdomadaire de ce bug pour le client ? Et cela justifie-t-il une analyse approfondie ?
- Quel est le délai fixé pour cette enquête avant que nous ne réexaminions la question ?
Deux théories identifiées et aucune reproduction : ce n’est pas un chiffre sur lequel se contenter, mais une piste de recherche à financer. Allouez-lui un budget et fixez-lui une échéance, puis réévaluez la situation une fois que la cause aura été identifiée.
Votez un budget de recherche. Lorsque la cause a un nom, estimez le coût de la solution séparément.
Consultez « Estimer un test instable » pour le même cas de figure, ainsi que « Erreurs courantes au Planning Poker » concernant l’estimation des bogues au niveau d’une fonctionnalité. Parcourez les autres exemples d’estimation commentés, ou lancez une session gratuite de Planning Poker lorsque la cause est connue.