Parmi les sujets fréquemment débordés lors des formations agiles, c'est la gestion des bogues en Scrum, qui est un sujet pas simple et pas évident, surtout que les bogues sont difficiles à estimer par les développeurs quand on a pas assez d'informations suffisantes, ou on ne connait pas l’origine (Pas possible de reproduire le cas).
Dans le Product Backlog on peut trouver différents types de demandes et objets, en occurrence les User Stories, les Technical Stories, les Spikes, et aussi bien les anomalies et les bogues détectés en production ou lors de la phase de recette chez le client. Du coup le Product Owner dans ce cas de figure doit prioriser ces bogues pour les embarquer dans des Sprints selon leurs criticités. Même dans des cas les bogues peuvent être urgents du coups il faut les prendre en compte et les traiter dans le Sprint en cours.
Je préfère commencer par identifier les deux types de bogues et anomalies qu'on peut trouver chez les équipes agiles Scrum :
1- Bogues détectés par l'équipe de développement lors d'un Sprint :
Il s'agit des bogues et anomalies détectées en interne lors de la phase de test des User Stories ou demandes à réaliser au cours d'un Sprint. Ils sont pris en compte et gérer immédiatement par l'équipe afin de terminer et mettre l'ensemble des User Stories en statut DONE afin d'apporter de la Valeur Métier au client, en plus ils ne sont pas visibles par le client vu qu'ils font partie de la cuisine interne des développeurs, sauf s'ils vont empêcher l'équipe à livrer certaines demandes en fin de Sprint, dans ce cas de figure l'information doit remonter à tous les acteurs (Premier Pilier de Scrum : Transparence).
2- Bogues détectés par le client en production ou en recette ou lors de la Review :
Ce type de bogues est visible par le client, le Product Owner et les parties prenantes, ils sont stockés dans le Product Backlog et doivent être embarqués dans les prochains Sprints pour les corriger et rétablir la valeur commerciale perdue.
En cas général, un bogue n'apporte pas de nouvelle valeur commerciale ou métier, mais plutôt il permet de la récupérer vu que la fonctionnalité associée reste non opérationnelle tant que le bogue n'est pas encore traité et corrigé.
De mon point de vue personnel, je ne recommande pas l'estimation des bogues surtout dans le cas où on est face à des bogues difficiles à estimer vu qu'on ne dispose pas d'informations suffisantes et on ne connais pas l'origine (Impossible parfois de reproduite le cas). Mais pour les équipes qui souhaitent le faire, je recommande la pratique suivante lors d'un Sprint :
Commencer par affecter une valeur fixe au bogue (5 points de complexité par exemple), et de prévoir une durée de traitement d'une journée maximum.
Analyser et traiter le bogue durant la première journée (Faire ce qui est jugé nécessaire) afin de finaliser et corriger le bogue avant le prochain Daily Meeting.
Si le traitement du bogue nécessite plus qu'une journée alors partager l'état d'avancement avec l'équipe lors du prochain Daily Meeting, et décider ensemble quoi faire (Soit continuer le traitement soit non selon la criticité du bogue en question et l'urgence sur les autres User Stories embarquées dans le même Sprint), Sinon partager le résultat avec le reste de l'équipe.
Une fois le traitement du bogue en question est terminé, alors penser à capitaliser, documenter, et identifier la complexité derrière ce type de bogue pour en profiter lors de traitement des bogues pareils dans le futur.
Remarques :
Pour les bogues faciles l'équipe peut donner une estimation selon la complexité de la solution à mettre en place.
Pour les bogues urgents, même si le "Scrum Guide" indique clairement qu'il ne faut pas toucher au contenu d'un Sprint une fois lancé, mais l'équipe peut traiter des bogues en urgences à condition de mesurer l'impact sur le Sprint et le livrable attendu. Et tout ça en étroite collaboration avec le Product Owner.
Dans le cas ou on est face à plusieurs bogues en attente, on peut penser à diviser l'équipe en deux sous-équipes, une pour les User Stories en Scrum (Flux continu), et une autre pour le Run en Kanban (Flux tiré) sans oublier de changer les affectations des membres afin de ne pas pour ne pas avoir des personnes attribuées à 100% au Run (L'effectif de chaque équipe dépend de nombre de bogues existant et la fréquence de réception de nouveaux bogues).
Aussi bien on peut travailler avec la notion des Sprints Répartis en allouant un pourcentage pour le traitement des bogues et un autre pour les fonctionnalités selon le nombre et la fréquence de réception des bogues, mais cela va impacter directement la vélocité de l'équipe vu quelle sera à chaque fois calculée différemment.
Conclusion :
La gestion des bogues reste difficile à maîtriser chez les équipes Scrum, mais avec l'expérience on peut trouver la meilleure façon de les traiter les bogues sans impacter la vélocité de l'équipe (Process Empirique de l'agilité).
Parmi les bonnes pratiques recommandées c'est la capitalisation et la documentation afin de faciliter le travail de l'équipe, et pour une meilleure productivité d'autre part (Documenter les astuces et les techniques de résolution des bogues par exemple).
L'équipe de développement doit travailler en étroite collaboration avec le Product Owner afin de bien gérer le contenu du Product Backlog et savoir quoi embarquer dans chaque Sprint selon l'ordre de priorité (User Stories, Technical Stories, Bogues, ...Etc.).
Comments