Si vous êtes impliqué dans la gestion de projets agiles, vous savez à quel point il peut être difficile de prioriser les demandes, initiatives, epics, user features et autres user stories. La « Bi
Dans cet article, Didier Joliot, expert et coach agile, auteur et formateur, aborde la complexité et les nuances de l’analyse de la valeur dans le cadre de la gestion de projets informatiques agiles. Il propose une réflexion de fond sur la pertinence et la manière d’appliquer correctement l’analyse de la valeur afin d’optimiser la satisfaction des besoins métiers tout en minimisant les coûts et les efforts de réalisation. Son étude étayée approfondie est un « must have » pour tous les professionnels en quête de méthode pour prioriser efficacement des développements logiciels.
L’analyse de la valeur est une méthode née aux États-Unis juste à la fin de la Seconde Guerre mondiale grâce à Lawrence Delos Miles. C’est une méthode rationnelle d’optimisation d’un produit (ou d’un procédé, ou d’un processus) qui s’inscrit donc dans le cadre du travail de l’ingénieur, en particulier dans les bureaux d’études (source : Wikipédia).
L’informatique, avec la démarche traditionnelle du cycle en V, a tenu compte timidement de cette discipline de gestion de projet entre 1960 et 1990 (par exemple au travers de la démarche d’analyse fonctionnelle APTE), avant de l’oublier dans la plupart des cas.
Avec l’avènement des méthodes agiles (rappelons que le Manifeste Agile date de 2001), la notion de « valeur » a été remise en avant. Seulement voilà : parle-t-on dans les deux cas de la même chose ? Et comment se pratique l’analyse de la valeur en agile ?
La notion de valeur
Reprenons la définition de la valeur telle que l’AFNOR nous la fournit : « La valeur est un moyen d’appréciation (ou jugement) de solutions : c’est un indice de pertinence, constituant une aide à la décision » (FD X50-153 : 2009).
Pour préciser, la valeur d’un produit pour les parties prenantes est définie par l’ISO à travers l’équation suivante :
C’est la mise en balance d’une part des avantages (numérateur), d’autre part d’inconvénients générés (dénominateur). Autrement dit, la valeur d’un produit est une grandeur qui croit lorsque la satisfaction du besoin augmente et/ou que le coût du produit diminue. Son but est donc d’assurer à un produit les fonctions qu’on lui demande, et cela au coût le plus faible.
La notion de valeur en agile
En première approche (nous verrons qu’en fait les choses sont plus complexes qu’il n’y paraît), les « agilistes » ont opté pour :
- Un numérateur appelé en général « Business Value»
- Un dénominateur qui est, non pas un coût, mais l’effort de réalisation.
Pourquoi ces choix ?
La Business Value représente bien l’appétence utilisateur pour un produit logiciel ou une fonctionnalité, donc la satisfaction des besoins. Sa faisabilité n’est pas considérée.
Pourquoi un effort plutôt qu’un coût ? Les agilistes soulignent, avec raison, que le coût logiciel est très incertain. Comment en effet estimer les coûts de production ? De fait, tout le monde s’accorde pour remplacer les coûts globaux de développement et d’exploitation du logiciel par l’effort de réalisation. Celui-ci approche l’idée de coût, mais se restreint à estimer ce qui est possible dans les phases amont de projet. Nous sommes en effet très démunis : seules l’analogie et/ou l’expérience sont nos possibles repères !
De fait, la Business Value, comme son nom l’indique, est évaluée par les métiers (le Product Owner), tandis que l’effort est de la responsabilité de l’équipe qui réalise (avec des experts IT).
On retiendra, par conséquent, que très souvent, en agile, nous avons l’équation suivante :
Nous parlerons donc dans la suite de priorité, en la distinguant bien de la Business Value.
Qu’en est-il de l’analyse de la valeur ?
L’Analyse de la Valeur (AV) est la démarche dont la finalité est de permettre de fixer la « valeur », au sens ISO, d’une partie de produit, afin de décider s’il faut l’implémenter ou non, quand et comment …
Ainsi, comme en agile nous développons les logiciels de manière itérative et incrémentale, l’analyse de la valeur est, en réalité, la discipline visant la priorisation des « tickets agiles » que nous créons, par exemple dans un outil tel que Jira. C’est un retour sur investissement qui est visé, et non pas seulement l’identification de la Business Value, contrairement à ce que pensent souvent les équipes IT.
On a donc à prioriser entre éléments de même nature :
- Soit des projets de logiciel,
- Soit des grandes fonctionnalités (« Epics » au sens SAFe) qui requièrent souvent des actions de plusieurs utilisateurs.
- Soit des fonctionnalités à la disposition d’un utilisateur (« Features » au sens SAFe) qui se définissent par le gabarit : En tant que … Je veux pouvoir <libellé de la fonction>, afin de …
- Soit des « morceaux de fonctionnalités» à implémenter le temps d’un sprint Scrum :
- Des User Stories (US : opérations simples et compréhensibles pour un utilisateur, contribuant à au moins une Feature, et se conformant aux critères INVEST définis par Bill Wake),
- Des corrections de bug de réalisation,
- Ou encore des corrections de spécifications internes à des US INVEST!
A travers cette liste, nous voyons qu’a priori, quatre jalons d’analyse de la valeur sont nécessaires en démarche agile, afin de prioriser des tickets qui peuvent se challenger.
L’analyse de la valeur est-elle homogène pour les projets IT d’une entreprise ?
Considérons tout d’abord le numérateur de la priorité.
La Business Value (BV) ne repose pas sur des critères homogènes selon les projets logiciels.
En fait, il y a de nombreux « critères de valeur » qui permettent d’apprécier la BV. Par exemple (liste non exhaustive et non normalisée) :
- Valeur politique: le produit/les fonctionnalités ont-ils un impact stratégique, par exemple sur l’image de l’entreprise ?
- Valeur économique: c’est souvent la valeur la plus recherchée. Que va-t-elle nous rapporter commercialement ?
- Valeur d’usage: sa facilité d‘utilisation va-t-elle nous amener plus de clients satisfaits du produit ?
- Valeur technologique: le logiciel va-t-il utiliser de nouvelles techniques comme l’IA, la blockchain, etc. nous permettant de sécuriser les informations ou d’apporter de nouvelles possibilités à l’utilisateur, voire de prendre de l’avance sur nos concurrents ?
- Valeur écologique: quel est l’impact du futur produit en utilisation, typiquement le bilan carbone pour l’utilisateur ?
- Valeur légale: dans quelle mesure le logiciel est-il contraint se conformer à des règlements sur le marché visé ?
La Business Value … n’est parfois pas le seul facteur permettant de déterminer les avantages d’un « ticket ».
On peut y ajouter l’urgence, le risque à ne pas faire, le risque à faire, etc.
En fait rien n’est clair, chacun doit choisir ses propres critères et/ou doit les adapter finement lui-même à ses besoins, … selon le type de ticket !
On trouve donc des « modèles » totalement différents pour le numérateur de la priorité, par projet et par type d’artefact agile.
Par exemple (liste non exhaustive) :
- La BV seule
- Le résultat issu de la matrice de Merrill & Covey (BV et urgence- Cf. le « quadrant d’Eisenhower »),
- Ou bien le score issu de l’approche Reach/Impact/Confidence (cf. méthode RICE d’Intercom)
- Ou encore la notion « comptable » du « coût du retard » dans la démarche WSJF (cf. Donald G Reinertsen)
Les techniques d’analyse de la valeur
Les techniques d’estimation des critères sont multiples et variées. Par exemple :
- Par formule de type « tableau » Excel, en s’appuyant sur des questions ou des sous-critères
- Par quadrant (ex : modèle de Kano pour la BV)
- Par « poker » donnant directement une estimation par « intuition », sur la base d’une présentation préalable des éléments.
La mise en œuvre des techniques d’estimation des critères n’est pas normalisée :
- Les tableaux Excel sont avec des colonnes différentes et des formules de calcul différentes (moyenne, moyenne pondérée, somme, multiplications, …)
- L’exploitation des quadrants diffère selon les équipes
- Il existe différentes possibilités pour réaliser les pokers (ex : poker planning, taille de T-Shirt, « buy a feature », MOSCOW, …).
L’analyse de la valeur a-t-elle du sens pour les User Stories ?
Il est certain que le choix des projets dans le « Portfolio Management » requiert l’analyse de la valeur, de même pour les Epics et les Features.
Mais qu’en est-il des US ?
Ce sont des « artefacts agiles » créés exclusivement pour la réalisation : il s’agit de la faire la plus simple possible en respectant, pour chaque US, la contrainte du délai d’un sprint.
Plusieurs arguments peuvent permettre d’affirmer que l’analyse de la valeur n’est pas forcément utile à ce stade …
- La plupart des équipes s’évertuent à mettre une Business Value à leurs US, alors que les Features sont déjà évaluées. Donc, pour respecter les choix de priorité de celles-ci, il suffit que les US « héritent » de la valeur de leur Feature associée ! N’oublions pas aussi que les Features sont versionnées : une fonction peut être définie comme simple (V1), puis complexifiée (V2 et plus), ce qui est une manière simple de considérer des US à plus ou moins de valeur ajoutée.
- Et leur effort ? Comme les US se veulent très petites en termes de taille, le mouvement “no estimate » intervient, considérant qu’il est inutile de les estimer ! Ceci n’est cependant pas en contradiction avec le fait qu’il faut placer les US dans des sprints. Pour cela, il faut analyser :
- La capacité à faire c’est-à-dire les ressources dont on dispose
- Et la notion de « vélocité prévisionnelle » : nb d’US « no estimate » possibles à prendre en compte en fonction de la capacité à faire, ou la somme des efforts relatifs de chacune (en points), pour la capacité à faire considérée.
Ces deux paramètres permettront alors leurs choix.
Ainsi si les US sont à placer dans des sprints, le travail est largement réalisé à partir de la priorisation des Features. Seules la capacité à faire et la vélocité sont vraiment importantes à analyser.
L’analyse de la valeur est-elle vraiment scientifique et utile pour planifier en agile ?
Tout d’abord que penser des évaluations effectuées ?
Comme cela a été décrit, nous voyons que la démarche reste très empirique, et avec des résultats très discutables :
- Les choix sont nombreux
- Il reste difficile de comparer des résultats qui, même s’ils positionnent des scores sur une échelle identique (de 1 à 10, ou de la suite de Fibonacci par exemple), représentent des concepts radicalement différents.
- Certaines formules font polémiques. Ainsi le « coût du retard » dans le WSJF fait la somme de scores, sur des données complexes à obtenir (des coûts …), sans même tenir compte de pondérations (à l’inverse d’une approche comme celle de « la matrice de Wiegers » utilisée en ingénierie des exigences). Cela ajoute de l’incompréhension car la somme de données hétéroclites et non pondérées choque les managers. Ils préfèrent naturellement se référer à leur bon sens plutôt que de fonder leurs décisions sur des formules « magiques ». Pour tout dire, malgré les efforts de communication déployés par des coachs « certifiés », cette approche académique (respectable en théorie) reste peu appréciée des hommes de terrain (et ceci est un euphémisme).
Ajoutons que, pour éviter que les évaluations privilégient systématiquement certains critères (ex : le retour commercial et non l’image), ou que les analyses soient perturbées par des biais (ex : le choix des formules avantage trompeusement tel ou tel sujet), les managers privilégient pragmatiquement des « enveloppes budgétaires », par direction et par catégorie (ex : par critères de la BV), en laissant à l’analyse de la valeur un espace de liberté plus réduit et plus homogène.
D’autre part, qu’en est-il de la planification de fonctionnalités ou de correction de bugs EN CONCURRENCE ?
Bien souvent, les applications automatisent des parcours utilisateurs. Ces derniers apportent des contraintes puisqu’une fonction A s’impose à être réalisée avant une fonction B, même si elle est moins prioritaire, simplement parce qu’elle est indispensable pour B ! Donc on peut s’étonner des analyses de la valeur chronophages pour des sujets en dépendance et non pas en concurrence.
En conclusion, l’analyse de la valeur en agile est-elle pertinente ?
Les choix d’analyse de la valeur s’imposent au moment des choix de projet et de « roadmap », ou de planning de release (cf. PI planning dans SAFe). Ils permettent, de plus, à tous les acteurs, de comprendre les enjeux du projet. Comme le souligne le proverbe asiatique « Le but n’est pas au bout du chemin : il est le chemin », la discussion engendrée est très enrichissante, bien au-delà du résultat brut.
On peut regretter que souvent l’AV s’arrête à appliquer des formules sans chercher à les appréhender et à en voir les faiblesses.
Par contre :
- Les dépendances fonctionnelles sont bien plus importantes pour planifier les fonctions qui sont, par nature, liées.
- Les US sont essentiellement planifiées par l’analyse statistique des vélocités observées, donc assez simplement.
Les résultats de l’AV, enfin, ne sont pas scientifiques. Ils participent à la vision mais ne sont pas gravés dans le marbre et d’une précision absolue.
L'auteur de cet article
Didier JOLIOT, ingénieur et coach agile, a une grande expérience professionnelle.
Il a d'abord été développeur puis responsable certification de logiciels temps réels critiques. Ex : Airbus, spatial, nucléaire, sous-marins, systèmes de défense … Didier Joliot a été ensuite expert spécifications et tests auprès d’équipes MOE, puis de MOA bancaires. Il a été aussi directeur de projet, et enfin expert pour la stratégie des SI (« gestionnaire de Portfolio Management » et « architecte d’entreprise »).
Il pratique depuis 2012 l’agilité. Il a été coach agile pour le Product management de très gros projets « agiles à l’échelle » au Crédit Agricole et à la Société Générale, et pour de nombreuses équipes en démarche agile Scrum.
Aujourd’hui il enseigne l’offre « Modern Product Agility » co-créée avec Stéphane Badreau.
Il a écrit 5 livres et de nombreux articles.
Il a créé, de plus, plusieurs méthodes de savoir-faire agile, par exemple le langage « Business Modeling Language (BML) », l’algorithme des tamis successifs pour concevoir les tests
Diplômé comme médiateur il a aussi créé la méthode de gestion des conflits "CNV-A" hybridant les techniques de Communication Non Violente utilisée en psychologie avec des techniques utilisées en projet agile.
