Prioriser des demandes d’amélioration d’intégration continue

Je voudrais partager cette pratique que je me suis imposé récemment. Le problème à résoudre était le suivant :

"Comment prioriser les demandes d’amélioration de notre plateforme d’intégration continue ?"

En effet, les équipes y détectent souvent des pistes d’améliorations. Ces améliorations ont pour but de leur permettre de travailler plus efficacement. Comme nos ressources pour modifier nos outils d’intégration continue sont assez limitées, il faut faire des choix, prioriser les demandes et délivrer en fonction des priorités. Un tel backlog existe depuis très longtemps mais il n’y a jamais eu de notion de priorité à l’intérieur. Les demandes étaient traitées selon la règle de « celui qui parle en dernier » ou la règle de « celui qui parle le plus fort ».

A un moment, pour résoudre le problème, je fut tenté de faire voter les équipes pour qu’elles définissent elle-même la valeur des demandes d’amélioration. Un peu comme un planning poker. Ce processus avait pas mal d’inconvénient :

• disponibilité des équipes pour voter
• la décision de faire telle ou telle chose repose sur un vote «au feeling» et non sur du «factuel»
• il se peut que de grosses différences de perception surviennent pendant les votes (des discussions certes intéressantes peuvent se tenir, mais au final le processus peut prendre beaucoup de temps)

Nous n’avons jamais tenté cette méthode.

M’inspirant de l’approche Lean, j’ai essayé de poser chaque demande d’amélioration du point de vue « Muda » (=gaspillage). Par intégration continue, on entend en fait une « ligne de production logicielle » dont le but est de convertir une ou plusieurs modifications de code en un produit terminé. Chaque attente sur cette « chaîne de montage » introduit un délai supplémentaire dans le temps de réalisation. Les demandes d’amélioration peuvent être vues comme des moyens de supprimer ces attentes. Le résultat d’une amélioration est donc un gain de temps de disponibilité de la plateforme afin de traiter de nouvelles modifications de code.

Partant de cela, avec l’aide de membres des équipes, nous avons estimé le gain de temps (=réduction de « Muda ») engendré par chaque demande. En adoptant le point de vue d’une User Story, on exprime la valeur de la demande dans l’unité « Heure.UserStory/Jour ». Par exemple une valeur de 2 signifie un gain de disponibilité de la plateforme de 2 heures par jour pour une User Story en cours de développement. Introduire la notion de « Heures.UserStory » permet de tenir compte du fait que l’amélioration aura un impact sur plusieurs User Stories en parallèle.

Je ne suis pas un expert du product backlog produit mais j'imagine que la même démarche pourrait être utilisée pour quantifier précisemment la valeur d'une fonctionnalité utilisateur : comment cette fonctionnalité pourra faire gagner du temps à l'utilisateur? Comment cette fonctionnalité lui apporte une réelle valeur, chiffrée?

Reste ensuite à estimer la taille de développement de chaque demande. En calculant ensuite le rapport Taille/Valeur on peut alors s’attaquer aux demandes qui auront le meilleur retour sur investissement.