Une anomalie devrait-elle donner des points à l'équipe?

Publié par David Beaumier le mercredi 27 novembre 2013 à 21:07

Dernièrement, on me posait la question suivante : « J’aimerais une confirmation sur le fait que les bogues ne devraient pas être pointés et comptabilisés dans le calcul de la vélocité de l’équipe ». C’est une excellente question et une qui revient assez souvent, particulièrement lorsqu’une équipe débute avec Scrum.

La réponse que je donne généralement est assez simple : non, on n’attribue pas de points aux anomalies. La raison principale est que Scrum se veut un cadre de travail qui valorise la livraison de valeur ajoutée (appelée value-driven en anglais). Lorsqu’on ajoute un élément au carnet d’un sprint c’est dans l’objectif de livrer une fonctionnalité qui a de la valeur pour le client. À l’opposé, un bogue représente une somme de travail de correction à quelque chose qui a déjà été livré. En corrigeant un bogue, l’équipe n’apporte, malheureusement, pas de valeur au client. En anglais, on parle de failure-driven.

L’objectif d’un cadre de travail empirique comme Scrum c’est d’amener l’équipe à réfléchir sur sa façon de travailler et d’en venir à identifier des façons de livrer plus de valeur au client durant un Sprint. Si l’équipe reçoit des points pour corriger des bogues elle n’aura alors aucun incitatif à être créative et à trouver des façons d’éviter ces bogues à la source. À mon avis, ça reviendrait en quelque sorte à offrir un biscuit à un chien alors qu’il vient de désobéir. En fait, en éducation on suggère d’encourager les bons comportements et d’ignorer les mauvais. C’est exactement l’approche préconisée par Scrum puisque l’équipe n’est pas pénalisée. Elle ne perd pas de points, mais elle n’en gagne pas non plus et sa vélocité n’augmentera pas.

Une équipe qui doit corriger un nombre significatif de bogues au cours d’un sprint va probablement en souffrir puisque sa vélocité risque de « prendre une débarque ». C’est un peu le but en fait... Si l’équipe est sérieuse, on devrait voir émerger des suggestions pour corriger la situation et éviter que la situation se répète. Cela peut parfois prendre plus d’un sprint pour que l’équipe réalise qu’elle est sur une mauvaise pente. Scrum Master, soyez vigilants!

Toutefois il est important pour les équipes de distinguer un bogue (un vrai) d’un changement au comportement d’une application. Je prends un exemple qui m’a été présenté récemment : lorsqu’un utilisateur imprime un rapport en sélectionnant un client qui n’a pas de facture impayée, le rapport "plante" car ce cas n’avait pas été prévu par le PO, ni testé dans ces conditions  (le rapport sert en principe pour les clients qui ont des comptes en souffrance). J’ai alors suggéré à l’équipe de créer un élément dans son carnet de produit afin d’ajouter le support pour ce besoin qui venait d’émerger. Par contre, si le rapport avait affiché la liste des factures dans le mauvais ordre, là j'aurais plutôt penché pour le bogue.

Qu’en pensez-vous? Est-ce que vous suivez cette règle dans votre équipe?

blog comments powered by Disqus

0 Comments:

Post a comment

Comments have been closed for this post.