Article publié en décembre 2012 sur le blog AgilBee Lab, aujourd’hui dans nos archives.
Les livres et sites web qui parlent de développement agile dépeignent souvent une situation idéale assez éloignée de la réalité. La plupart du temps dans nos interventions, l’équipe agile n’est pas nouvelle dans un environnement vierge, il existe un passé, voir un passif à maintenir en même temps qu’il faut créer de nouvelles fonctionnalités. Le Bug Hero est une stratégie pour protéger l’équipe de développement des interruptions en envoyant l’un d’entre eux à l’assaut des bugs.
Ça a encore recommencé. Un jour seulement après le planning meeting le service support remonte 5 bugs qui touchent un client clé et qu’il faut traiter de toute urgence. Ces bugs ne portent pas sur le sprint en cours, ni même sur la précédente release, mais sur un autre logiciel que l’équipe a le malheur de devoir maintenir. Ils sont comme ça au service support, ils débarquent, posent plein de questions, interrompent les meilleurs de l’équipe, les anciens, afin de comprendre comment traiter ces bugs et quoi répondre au client. Cela perturbe tout de suite le sprint, c’est sure on aura pas le temps de corriger tout ça et de tenir les objectifs.
Ce genre d’histoire arrive tout le temps. Bien souvent une équipe commence un projet en mode agile et doit maintenir un existant en même temps. Si le nouveau développement se prête bien à Scrum, la maintenance est par contre plus contrariante. Les clients déclarent leurs bugs n’importe quand et il faut un travail d'enquête conséquent pour estimer les temps de réparation, parfois plus long que la réparation même. Faut il une équipe dédiée à la maintenance des anciens codes ? de la tierce maintenance applicative ? Lorsque, face à une équipe, je demande qui a envie de ne faire que de la correction de bug toute sa vie, étrangement, aucune main ne se lève.
La stratégie du Bug Hero est la suivante : à chaque sprint, un développeur de l'équipe est désigné sous le titre de Bug Hero et se consacre entièrement à la correction de bugs. Le développeur doit être désigné par un roulement sur l'ensemble de l'effectif, afin que chacun y participe à la même hauteur. Durant ce sprint, son rôle est :
-
d'assister le service support dans le service des clients,
-
de s'atteler à l’analyse et la correction des bugs qu'il est en mesure de traiter,
-
de se former sur les problématiques concrètes des clients.
Par sa présence auprès du service support, le Bug Hero protège partiellement le reste de l'équipe des interruptions, améliorant la productivité globale. Il ne participe pas au planning meeting de son équipe et ne compte pas dans la vélocité puisqu’il ne travaille pas sur les objectifs du sprint. Il peut par contre avoir un rôle au planning meeting suivant pour bien expliquer les bugs qu’il aurait analysé et qui resteraient à corriger.
Parfois un développeur peut sembler particulièrement indispensable pour le Sprint à venir, l’ordre de roulement doit être souple afin de le prendre en compte. Par contre il ne faut pas pour ce prétexte l’exclure du roulement. Considérer un développeur en particulier comme étant durablement indispensable par ce que personne d’autre au sein de l’équipe ne saura poursuivre son travail est une sacrée mise en danger pour la pérennité de l’équipe et du produit développé. Que devient on lorsqu’il prend des vacances ? Que devient on s’il se casse une jambe ? la sur-spécialisation est une source de fragilité, la polyvalence une force. La stratégie du Bug Hero doit s’appliquer à tous.
Cette stratégie permet enfin au Bug Hero de sortir temporairement du rythme de sprints et de travailler autrement, plus près du service support et donc des clients finaux. Elle sensibilise les développeurs à la qualité perçue par leurs clients, ce qui leur sera utile dans les prochains sprints.
Image : forum du jeu Bug Heroes http://forums.toucharcade.com/showthread.php?t=79560
Pour aller plus loin
Découvrez le parcours Scrum Master.