Évaluation d'un test instable
Comment estimer un test instable : pourquoi il faut deux estimations, et non une seule, et pourquoi il vaut mieux fixer une limite de temps plutôt que de débattre du nombre de points lorsque la réponse dépend de ce que vous découvrirez.
Un test aléatoire correspond à deux estimations. Vous ne savez pas encore laquelle des deux.
awaitDans un cas, il s’agit d’une correction en une seule ligne : une hypothèse de synchronisation, une dépendance liée à l’ordre des tests, un élément manquant. Dans l’autre cas, il a fallu trois jours pour identifier une condition de concurrence dans le code de production que le test a justement détectée. Lorsque les cartes vont de 2 à 13, l’équipe n’est pas en désaccord sur l’ampleur du problème — elle est en désaccord sur le type de bug dont il s’agit, ce qui constitue la véritable inconnue.
C’est en estimant l’ampleur d’un problème avant de s’y attaquer, plutôt qu’après, que cette histoire se retrouve à 5 la première semaine et à 13 la troisième. La solution ne réside pas dans un chiffre plus précis, mais dans une approche différente du travail. Fixez un délai pour l’analyse, puis estimez la solution concrète une fois que vous en connaissez les contours.
Ce qui se dit dans la salle
Ingénieur A : « Si le problème est dû à la raison que je suppose, je lui attribue la note de 2. »
Ingénieur B : « Si ça plante pour la raison que je pense, c’est un 13. »
Introduction : « Quelqu’un l’a-t-il déjà exécuté localement avec la graine fixée ? »
QA : « Cela ne plante que dans l’environnement de CI. Jamais sur une machine de développement. »
Questions qu’il convient de se poser avant de voter
- Ce problème se reproduit-il localement ou uniquement en environnement de CI ?
- À quelle fréquence cela échoue-t-il : 1 fois sur 50, 1 fois sur 5, une fois sur deux ?
- Quand cela a-t-il commencé à ne plus fonctionner ? À partir de quel commit ?
- Le test est-il erroné, ou détecte-t-il quelque chose de réel ?
- Y a-t-il quelqu’un qui le désactive en attendant, et à quel prix ?
L’écart entre l’ingénieur A et l’ingénieur B n’est pas un désaccord sur les points de story que l’on peut gommer en faisant la moyenne — c’est une inconnue qu’il faut élucider. Un « spike » court et limité permet de le combler ; une dispute plus virulente, non.
Prévoyez un délai fixe, pas une solution toute faite. Une demi-journée pour mener l’enquête, puis un véritable article sur ce que vous aurez découvert.
Consultez « Estimer un bug sans reproduction » pour un cas similaire, ainsi que « Erreurs courantes au Planning Poker » pour estimer des bugs au niveau d’une fonctionnalité. Parcourez les autres exemples d’estimation concrets, ou lancez une session gratuite de Planning Poker lorsque l’analyse aura abouti à un résultat.