méthode agile et coûts

Travailler en utilisant une méthode agile axée tout d’abord sur le livrable de qualité n’implique pas de s’abstraire totalement des aspects financiers de chaque phase. Lorsque l’on aborde la fabrication, on peut simplement mettre une petite touche de gestion des coûts afin de disposer d’un axe d’analyse supplémentaire, parfois crucial.

Le développement logiciel, lorsqu’il utilise une méthodologie agile, peine à travailler sur les 3 axes que sont le délai, la qualité et le coût. Souvent on ne peut tenter de fixer que 2 paramètres et généralement l’usage en agile est de fixer le contenu (disons ici la qualité) et le délai, dans le waterfall, les axes sont similaires, mais le contrôle encore plus complexe. L’équipe agile estime sa vélocité sur la base du coût estimé des user stories (US) avec des unités équivalentes, après quelques sprints, si l’équipe est stable (pas de mouvement, pas trop d’absence), la vélocité et le coût des US tendent à être de plus en plus précis.

Qu’en est-il du coût ? Puisque l’équipe propose une vélocité, qui peut éventuellement être remise en cause par des personnes compétentes en développement logiciel (donc pas le PO¹, ni le PM², soyons raisonnables) et puisque cette équipe coûte, on devrait pouvoir estimer le coût du produit en se projetant à la fin des versions majeures, ou de chaque sprint (intérêt ?).

Combien de projets partent avec une bonne connaissance de la valeur métier de leur version, y compris le MVP³ ? On connait assez bien le coût des équipes de fabrication, en fonction de la zone géographique d’implantation et du marché du travail, assez simple de ramener le point de complexité à une valeur monétaire de cette fabrication. Alors pourquoi ne voit-on pas plus d’approche sur la valeur, notamment basée sur l’EVM (Earned Value Management) ?

Si on reprend les concepts fondamentaux du développement en méthode agile, on retrouve :

• une démarche itérative sur la base de sprint assez cours (2 ou 3 semaines) avec une livraison stabilisée à la fin de chaque sprint sur la base des user stories

• une liste de user stories idéalement assez courtes pour entrer dans un demi-sprint, disposant d’une priorité business (ou technique si fondation) et d’une complexité évaluée par l’équipe de fabrication dans une unité simple à comprendre pour tout le monde, l’ensemble de US est regroupé dans un backlog

• une orientation vers la solution finale, orientée business avec une valeur direct pour les utilisateurs, on pense d’abord à eux

• une équipe restreinte et autonome dans son organisation, dans sa capacité de production, dans les décisions qu’elle doit prendre afin de répondre au résultat sur lequel elle s’est engagée au début de chaque sprint

• si une équipe ne suffit pas, on forme un train de release avec plusieurs équipes dont les livraisons sont synchronisées dans le temps et sur les adhérences s’il en existe

• une revue régulière et impérative à chaque fin de sprint sur ce qui a apporté de la valeur, ce qu’il faut améliorer, ce qu’il faut arrêter, que ce soit sur un plan technique ou d’organisation

• un reporting d’abord axé sur la production plutôt que sur de la comitologie, on mesure, on analyse les indicateurs, on améliore en continu les pratiques. Idéalement on utilisera des outils le plus possible automatiques afin de limiter les charges de reporting, le management visuel, les outils de travail à distance, notamment si l’équipe est dispersée sur des sites différents

• une intégration la plus fluide possible de la production du code à la mise en ligne pour le client en instrumentant toutes les tâches automatisables et en apportant le maximum de contrôle de qualité de façon automatique, non équivoque, fiable

Si on regarde du côté de la valeur, on peut assez facilement calculer le coût (en monnaie) en rapport avec les complexités des user stories. Ceci va nous permettre de pouvoir rapporter l’attente du produit en termes de valeur métier avec son coût de fabrication. Si on fait cet exercice, il faut se projeter plus loin que le sprint en cours, il faut idéalement se positionner sur les jalons de notre train de release.

L’approche AgileEVM apporte les notions de planned value (PV), earned value (EV) :

• planned value représente ce que l’on pense dépenser pour réaliser un ensemble de fonctionnalités (en gros un taux d’avancement global du jalon sur la base de la somme des user stories)

• earned value représente le coût remis à jour du coût sur la base des mêmes jalons que pour la planned value, cette valeur peut-être en décalage par rapport à la PV

On va donc pouvoir comparer PV et EV, l’un représentant ce que l’on pensait dépenser et l’autre ce que l’on a effectivement dépensé. A la fin de chaque sprint il est donc possible de réagencer les user stories qui seront réalisées à la prochaine itération sur la base de la valeur imaginée de la user story pour les utilisateurs, la complexité de réalisation par rapport à la vélocité de l’équipe et enfin le coût de l’ensemble des fonctionnalité.

Puisque la valeur pour le client est quelque chose d’assez difficile à évaluer, notamment en phase très amont de la fabrication sur les premiers sprints, il peut être intéressant de regarder ce que cela coûte et donc challenger le ROI qui avait été présenté au lancement du développement du produit.

La véritable valeur de l’approche EVM est à mon sens au niveau des solutions ou des programmes, pas uniquement au niveau d’une équipe produit. Il est en effet assez rare que l’on ne développe qu’un seul produit. Plusieurs produits rentrent dans le cadre d’un train de livraison cohérent et le coût de ce genre de programme doit être analysé avec un peu de recul, certains produits ayant plus de valeur que d’autre.

L’approche EVM couplée au fonctionnement des équipes agiles sur les méthodologies comme scrum permet de mettre en parallèle le fonctionnement autonome de l’équipe (à ne pas remettre en cause), sa vélocité (à challenger si possible) et le coût des choses. Car il y a souvent une logique économique à la fabrication d’un produit, même si elle n’est pas toujours simple à suivre, à évaluer, à prouver, notamment sur les produits utilisés en interne et qui visent à améliorer la productivité des utilisateurs.

Bilbiographie :

• Measuring Integrated Progress on Agile Software Development Projects
• How to Manage Cost and Time of Agile Software Project
• AgileEVM: Measuring Cost Efficiency Across the Product Lifecycle
• SAFe
• Less framework

Photo from Harry Sandhu