Évaluation d'un bug impossible à reproduire

Si vous ne pouvez pas le reproduire, 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 une note à la correction avant que la cause ne soit connue revient à évaluer une tâche que l’équipe ne peut pas réellement visualiser.

La correction n’est pas toujours difficile une fois que vous en avez identifié la cause ; il suffit souvent de modifier une seule ligne de code. C’est la recherche qui coûte cher. Estimer le temps nécessaire à la recherche relève de l’honnêteté ; estimer celui nécessaire à la correction relève de l’optimisme.

Ce qui se dit dans la salle

Ingénieur A : « Je pense que c’est 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’était 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 le 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 présente un problème connu 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 imparti pour l’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 à 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 est identifiée, évaluez le coût de la réparation 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 concrets, ou lancez une session gratuite de Planning Poker lorsque la cause est connue.