A la demande / la rache

Pour une raison ou une autre (faire plaisir au client / PDG , parce que le service ne marche plus, parce que c'est une petite tache), l'équipe accepte les tâches et les traitent tout de suite. Implicitement, les users stories légitimes de l'itération sont décalées. Le client ne réalise pas toujours que la prise en charge immédiate des imprévus décalent le reste, c'est important de mettre ce point en valeur. Accepter une tâche de sa part revient à changer la priorité. Le fait de tout accepter me parait très grave car cela signifie qu'il n'y a pas de priorisation de la part du client. C'est juste le dernier qui l'emporte.

Les stories suivantes ne sont pas toujours décalées : on peut par exemple charger un peu plus l'équipe, voire cette dernière décidera d'elle même de prendre sur elle pour atteindre les objectifs fixés (stories du sprint + imprévus). Le coût de cela est évidemment les prévisions futures, qui seront faussées ("la derniere fois, vous avez bien réussi à tout faire") et la fatigue qui s'accumule (et donc le risque d'erreurs avec).

Une organisation dédiée

C'est le schéma le plus courant, où des personnes sont dédiées à la maintenance. L'aspect exclusif s'applique sur le temps (après la mise en production, tout le monde bascule en mode maintenance) ou sur les hommes (certaines personnes sortent temporairement du projet pour ne faire que cela). On peut aussi voir des équipes séparées de façon permanente, la maintenance étant alors considérée comme un "projet" à part entière.

Faire passer toute l'équipe en maintenance après une MEP est moins douloureux que de sacrifier juste quelques personnes. Je ne connais personne qui aime gérer les bugs...

Du mou

Une autre pratique consiste à embrasser les imprévus : on sait qu'il y en aura. On se reserve donc du temps en rab dans l'itération exprès pour cela.

Je ne suis pas à l'aise avec cette pratique car je ne sais pas quand m'arrêter. On peut très facilement se faire avaler. J'ai une tâche importante : admettons que je la prenne, il faut que je m'arrête dès que j'ai atteint le quota d'heures ?

Et comment décider de prendre une tâche ou non ? Je ne sais pas si dans deux jours, je n'en aurai pas une plus importante. Dans le doute, je peux me dire que je ne veux pas griller mon quota de mou. Et si finalement, il n'y a aucun imprévu ?

Du donnant donnant

C'est ce qui me parait le plus sain, mais cette tactique n'est pas applicable dans tous les projets. Concrètement, j'accepte très exceptionnellement les tâches en cours d'itération, mais je la traite comme une story : elle doit être chiffrée. En contrepartie, on enlève une story de complexité équivalente.

Des binomes tournants

Une idée séduisante de prime abord mais qui ne m'a pas du tout convenu. Tous les jours, un binome est "de perturbation". Le jour suivant, l'un d'entre eux sort, l'autre reste pour passer la main à un autre.

Là ou ça ne fonctionne pas : une journée passe trop vite. C'est difficile de monter en compétences dans cet espace, en particulier dans un contexte ou les perturbations sont des bugs sur l'application. En plus, certaines perturbations dépassent la journée, ce qui laisse un goût d'inachevé. Le fait de switcher tous les x jours de taches est assez pénible et fait perdre du temps. Enfin, il est facile de trainer des pieds sur les taches désagréables, et de laisser ça au suivant. Au final, on peut se retrouver avec toujours les mêmes qui traitent les perturbations.

Du Dris

Par rapport au binome tournant, j'avais proposé de passer à des périodes plus longues de service de perturbations. La proposition n'a pas été votée car jugée trop pénible (une itération de perturbations pourrait entrainer du turn over).

Sur un autre projet, c'est entre les deux. Une personne est dris (je suis incapable de détailler l'acronyme) pendant une semaine et cela tourne.

C'est pas mal. Cela laisse le temps de traiter des sujets et de voir autre chose. Par contre, il vaut mieux éviter que ce soit toujours la même personne de service quand il y a une MEP.

Un ancien accompagne les nouveaux lors de leur première semaine de dris.

Du kanban

Cela ressemble au donnant / donnant finalement, sauf que ce n'est même plus du scrum. Il n'y a plus d'itération, juste un nombre maximum de tâches à traiter (2 par exemple). Si le client change d'avis, il doit simplement en enlever une autre. Je vous invite à lire Kanban et Scrum tirer le meilleur parti des deux si vous souhaitez en savoir plus.

Conclusion

Je n'ai pas expérimenté de méthodes parfaites mais j'en ai quand même des préférées : le donnant/donnant et la semaine de perturbation via le Dris car elles favorisent la polyvalence de l'équipe. Même si traiter des perturbations n'est pas l'activité la plus passionnante, elle a le mérite de former le développeur aux défauts de l'application et au fonctionnel. Le kanban est aussi assez séduisant.

Et vous, comment gérer vous les imprévus ? Quels sont les avantages de votre gestion, les inconvénients ?

anniversaire.gifRien à voir, mais c'est important : Bon anniversaire Louise !!