Comptabiliser la correction des anomalies dans la vélocité ? ça dépend...
Auteur : Vikas Hazrati
Source : Count Bug Fixes Towards Velocity? Depends…
Date : 16/09/2011
Traducteur : Fabrice Aimetti
Date : 20/09/2011
Traduction :
Il y a eu de nombreux débats dans le passé pour savoir si les corrections d'anomalies devraient être comptabilisées dans la vélocité. Il semble qu'il n'y ait pas "une" bonne réponse. Toutefois, les Agilistes ont certaines recommandations décrivant des situations dans lesquelles il faudrait les ajouter, mais comment les ajouter et dans quels cas éviter de le faire ?
Syed a suggéré que comptabiliser ou non dépend de la façon dont vous définissez la vélocité. Si la vélocité est basée sur la "valeur" alors les corrections d'anomalies ne doivent pas être comptabilisées puisqu'elles n'ajoutent pas de valeur supplémentaire pour le client. Toutefois, si la vélocité est basée sur les "coûts" alors les anomalies doivent être comptabilisées dans la vélocité car cela prend du temps et des efforts pour les corriger.
Mike Cohn recommande que les anomalies soient estimées en points de story. Selon Mike :
On tire vraiment le meilleur des deux mondes. Nous sommes capables de voir la quantité de travail que l'équipe est vraiment capable d'accomplir, mais nous sommes aussi capable d'inspecter l'historique des données et de voir combien concernait des stories de corrections d'anomalies lors de chaque sprint.
Jason Yip a fait une analogie intéressante quand il a comparé la vélocité à un indicateur de la façon dont nous courons pour atteindre un objectif. Jason a souligné l'importance de l'objectif.
Si quelqu'un vous pousse en arrière de 5 mètres, alors la vitesse est réduite. Ainsi la vitesse est plus un vecteur qu'un scalaire.
Robert a suggéré une comptabilisation en partie double pour déterminer la vélocité. Selon Robert :
Je comptabilise les corrections d'anomalies dans la vélocité - mais selon la tradition classique de comptabilité en partie double - je tiendrai aussi compte de la vélocité des itérations précédentes dans lesquelles les anomalies ont été créées, et j'y appliquerai une perte.
Greg a commenté que déclarer de but en blanc ne pas comptabiliser les anomalies dans la vélocité est dangereux. Décider si elles doivent être comptabilisées ou non dépend énormément du contexte et la définition réelle de l'objectif.
Peut-être que l'objectif ce sont les nouvelles fonctionnalités. Peut-être que l'objectif c'est de produire une feature surprenante qui séduira de nombreux clients. Peut-être que le but est de corriger les anomalies dans un produit existant. La pratique de ne pas comptabiliser les anomalies dans la vélocité pourra fonctionner pour votre équipe, mais il y a beaucoup de contextes dans lesquels cela n'aura pas de sens.
Jack Milunsky a mentionné qu'indépendamment du fait que vous finissiez ou non par ajouter les corrections des anomalies dans votre vélocité, elles doivent quand même être comptabilisées car elles prennent du temps à corriger.
Les anomalies doivent être planifiées dans un sprint ou itération à côté des user stories lors de la réunion de planification du Sprint. Donc le temps total nécessaire à la mise en œuvre des tâches et la correction des anomalies ne doit pas être supérieure à la capacité disponible estimée pour l'équipe. Je sais que beaucoup de coachs vous diront que les corrections d'anomalies doivent être suivies séparément et que les anomalies devraient être corrigées dans le sprint dans lesquelles elles ont été découvertes. Cependant, en pratique, cela n'est pas toujours aussi simple. Essayez, et vous améliorerez le pouvoir de prévision des équipes de manière significative.
Ainsi, il y a un fort consensus sur la comptabilisation des anomalies. Décider si elles devraient être ajoutées ou non dans la vélocité est une question pour laquelle les opinions diffèrent, probablement à juste titre, selon la situation.
