Depuis quelques années, l’agilité est un mot qui a envahi le langage et qui se trouve apprêté à toutes les sauces, a priori pour qualifier la flexibilité.
Improprement utilisé pour le management, le concept d’agilité a été initié dans le domaine du développement de logiciels et porte sur des méthodes de gestion de projet.
Petit retour en arrière
La méthode traditionnelle pour aborder un projet informatique consiste à définir les besoins dans un cahier de spécification le plus précis possible, puis de passer à la phase de réalisation (développement) du logiciel en évitant toute modification des spécifications en cours de réalisation.
Ces méthodes sont inspirées de la gestion de projets tels qu’on les rencontre dans la construction de bâtiments ou l’industrie.
A l’usage, on s’est aperçu que près de 85% des projets informatiques échouaient. Abandon, dépassement de crédits, fonctionnalités inutiles, délais, bugs sont les causes le plus souvent observées avec des pertes nettes qui peuvent parfois se chiffrer en milliards de dollars ou d’euros.
La littérature regorge d’exemples et d’analyses qui dissèquent l’origine de ces catastrophes numériques. Parmi les grandes causes, on retrouve un manque d’engagement de la direction, une insuffisance de communication, un manque de compréhension de la problématique et des objectifs, un optimisme dans la planification et une mauvaise appréciation des difficultés.
Intuitivement on comprend que la promesse de livraison en un bloc d’un logiciel qui implique des dizaines d’années-homme de travail et qui a été décidé des années auparavant, a toutes les chances de subir des dérives temporelles et des inadéquations fonctionnelles.
Schématiquement voici le déroulement d’un projet géré de façon traditionnelle :
La droite verte représente le planning et les fonctionnalités fixés dans le cahier des spécifications.
En rouge on observe la production réelle.
(1) Au début du projet la productivité est bonne car ce sont les éléments les plus faciles qui sont implémentés et d’autre part, l’équipe est motivée par un nouvel objectif. Elle s’infléchit ensuite pour adopter un rythme de croisière, généralement plus lent que la prévision.
(2) Arrive le moment où la productivité s’effondre. C’est un effet du principe de Pareto adapté pour un projet informatique : le 20% des fonctionnalités prennent le 80% du temps. Les fonctionnalités complexes ont été remises à plus tard et vient le moment de les réaliser.
(3) L’effet Pareto induit des dérives importantes qui arrivent malheureusement en fin de projet, les budgets sont épuisés et on ne peut plus reculer tant l’engagement est important. Le piège se referme et le dérapage a de bonnes chances d’être fatal.
Méthodes agiles
Fort de ces constats peu glorieux, le début de millénaire a vu émerger des méthodes dites agiles telles : extreme programming XP, SCRUM ou RAD. Ces méthodes bouleversent complètement les paradigmes des approches traditionnelles, notamment avec l’abandon d’un cahier des spécifications lourd et figé, au profit d’une souplesse de réalisation en cours de projet et d’une implication concrète du client usager.
A titre d’anecdote, l’extreme programming recommande des mesures contre-intuitives telles que la programmation par paire, soit deux développeurs derrière la même machine. Comment deux personnes dont une seule accède au clavier peuvent être plus productives ? Le regard de l’autre évite la dispersion (lecture des mails, navigation sur le net, etc) et la synergie créée par le double regard augmente l’attention à l’écriture du code et profite à la qualité du produit.
Une autre caractéristique de la démarche est le découpage du projet en parts fines correspondant à des fonctionnalités qui seront délivrées au client selon un rythme rapproché, typiquement toutes les deux semaines. L’ordre de production des fonctionnalités est décidé par le client en fonction de ses priorités. Avec des livraisons rapprochées, le client peut immédiatement tester et mettre en production des portions de fonctionnalités, ce qui lui permet concrètement d’appréhender le logiciel et de s’impliquer dans sa conception.
Pour les développeurs, c’est un outil qui permet une meilleure maîtrise de la productivité et qui fixe des objectifs réalistes en ajustant le nombre de fonctionnalités qui peuvent concrètement être livrées par période.
Schématiquement voici le déroulement d’un projet agile :
En vert, le planning initial de projet.
(1) Le projet est découpé en plusieurs fonctionnalités qui sont délivrées selon un rythme préétabli et rapide.
(2) L’observation continue des fonctionnalités livrées (3) permet un ajustement réaliste et corrigé de la productivité réelle.
(3) Les prochaines fonctionnalités à livrer sont décidées en cours de projet par le client. Il priorise en fonction de ses besoins (ligne rouge) et peut décider de supprimer des fonctionnalités qu’il ne juge plus nécessaires.
(4) Des fonctionnalités nouvelles peuvent être ajoutées (ligne orange) selon les besoins du client.
Les méthodes agiles présentent donc des avantages réels, dont :
- La capacité d’adaptation et de priorisation des fonctionnalités produites
- La capacité de mieux évaluer la productivité du développement
- Un engagement concret des parties prenantes
- Une meilleure qualité de la production de logiciels
Ce sont les nouvelles technologies de programmation qui permettent d’appliquer une telle souplesse. Dans le domaine du bâtiment l’ordre et les dépendances ne permettent pas cette souplesse. Il n’est pas possible de poser le parquet avant la chappe.
Ces qualités sont bluffantes d’efficacité et font baisser drastiquement le taux d’échec des projets.
Mais…
Devant toutes ces qualités quels peuvent être les éventuels pièges de la méthode ?
Je vois deux points qui méritent notre attention.
- L’équipe de développement est juge et partie de sa propre productivité c’est elle qui fixe le nombre de fonctionnalités livrable à chaque échéance. Ainsi, elle dispose d’un auto-justificatif de sa force de production voire même, de sa propre baisse de productivité.
Le système n’intègre pas de de contre-pouvoir capable de challenger l’équipe. - L’équipe de développement est positionnée comme un outil de production, sans aucun rôle de conseiller. Le périmètre fonctionnel et la priorisation de réalisation sont entièrement dans les mains du mandant.
Une approche disruptive que pourrait amener la transition numérique n’est pas du tout abordée dans les méthodes agiles.
Si le mandant ne se pose pas les bonnes questions sur sa propre organisation en regard des bénéfices qu’il pourrait obtenir du numérique, ce n’est pas sur son équipe de développement qu’il pourra compter.
La question de l’organisation et de la recherche de la valeur ajoutée doit apparaitre dans l’organisation avant d’entreprendre un projet numérique.
Je relève deux points d’attention qui sont abondamment commentés dans la littérature mais qui, d’expérience, sont négligés.
- Le client/mandataire. en particulier sa direction, doit être un acteur engagé dans projet et doit adhérer à la méthode en connaissance de cause.
Des assertions telles que « faites au mieux », « nous vous faisons confiance » ou un client absent sont des alarmes qu’il convient de traiter rapidement.
Le client/mandataire doit non seulement être très impliqué mais également formé à la méthode. - Les méthodes agiles privilégient des petites équipes (entre 5 et 7 personnes) très compétentes. Les développeurs peu motivés et/ou aux compétences techniques insuffisantes sont à proscrire.
Il peut être difficile de réunir ces talents pour constituer une équipe efficace et solidaire.
Conclusions
L’agilité ne consiste pas à sauter du coq à l’âne mais constitue est une vraie méthode qui demande de la rigueur et surtout une grande expérience et d’excellentes compétences.
Les méthodes agiles sont très efficaces et ont fait leurs preuves. N’hésitez pas à vous engager dans des projets agiles. Si vous n’avez pas d’expérience, associez-vous avec des partenaires compétents et capitalisez car il y a beaucoup à prendre et à apprendre !
Toutefois, en termes de conception et d’organisation, l’agilité n’apporte aucune plus-value compétitive. Il vous appartient de définir les axes de votre projet numérique afin que vos investissements produisent une réelle valeur ajoutée.
© Pascal Rulfi, avril 2021.
Téléchargez l’article : Agile mais…