Une critique raisonnée des méthodes Agiles

Après avoir été très à la mode, les méthodes dites “Agiles” subissent désormais une vague de critiques, y compris de la part des fondateurs du mouvement.

Rappelons rapidement ce qu’est cet élan en faveur de ces méthodes “nouvelle vague” : en février 2001, aux États-Unis, dix-sept spécialistes du développement logiciel se sont réunis pour débattre du thème unificateur de leurs méthodes respectives, jusqu’alors appelées sans consensus méthodes lights. De cette réunion devait émerger le Manifeste Agile (Agile Manifesto), considéré comme la définition canonique du développement Agile et de ses principes sous-jacents. Le Manifeste Agile est constitué de quatre valeurs et de douze principes fondateurs (source : https://fr.wikipedia.org/wiki/Manifeste_agile).

En gros, Agile s’oppose aux méthodes traditionnelles en proposant un développement itératif et s’adaptant continuellement aux circonstances plutôt qu’un développement rigide et “en cascade” (je schématise, mais je sais que vous me suivez). Bon, on va se contenter de cela comme rappel.

Que reproche-t-on aux méthodes Agiles tout d’abord ?
Ce sont des “pointures” qui en parlent et c’est en premier lieu pour cela que ces critiques ont eu un certain retentissement : 

Ron Jeffries, un informaticien américain de renom dit qu’on devrait abandonner les méthodes Agiles dans les entreprises. Son avis est d’autant plus important parce qu’il est l’un des 17 signataires du Manifeste pour le développement Agile de logiciels.

Erik Meijer, un développeur de l’écosystème .NET disait il y a quelques années qu’ « Agile est un cancer que nous devons éliminer de l’industrie ». 

Andy Hunt, l’un des 17 coauteurs du Manifeste Agile en 2001 n’a pas caché aussi sa déception. Pour lui, Agile n’a pas atteint les objectifs escomptés au départ. 

Selon Amir Yasin, cofondateur et CTO de June (société US spécialisée dans le recrutement des professionnels seniors de l’IT), « Agile est devenu tout ce que le modèle Waterfall était pour les développeurs, et pire. C’est un loup déguisé en agneau ».

L’habituel débat entre pragmatisme et dogmatisme
Avec une telle avalanche de reproches aussi tranchés, on pouvait penser que la démarche Agile est enterrée pour de bon une fois pour toutes !

En fait, comme souvent, il faut se garder de “jeter le bébé avec l’eau du bain”… Car, selon Ron Jeffries lui-même, ce ne sont pas directement les méthodes qui sont en cause, mais plutôt la manière dont elles sont appliquées. En clair, certaines équipes se sont emparées d’Agile pour se comporter exactement comme avec les méthodes en cascade : avec rigidité, s’imposant d’en respecter la lettre plutôt que d’en comprendre l’esprit. C’est l’habituelle confusion entre pragmatisme (tirer le meilleur d’une démarche) et dogmatisme (obéir aveuglément à des règles qu’on ne comprend pas vraiment).

Ajoutons qu’Agile est également victime de la mode qui l’entoure. En effet, comme il était à la mode d’évoquer les méthodes Agiles, le terme a été largement galvaudé, détourné et déformé. Tout d’un coup, on a vu les équipes IT s’interroger : “sommes-nous Agiles ?” et puis aussi “sommes-nous suffisamment Agiles ?” et ainsi de suite. Tout cela commençait à tourner au ridicule et on sentait bien qu’un retour de bâton se profilait à l’horizon…

Car quand quelque chose est populaire, il arrive forcément un moment où cette faveur s’efface pour laisser la place à du ressentiment. Bref, ce qu’on reproche désormais à Agile repose sans doute plus sur des sentiments et des interprétations que sur sa nature réelle.

Pas d’angélisme sur “Agile” !
Si on veut être efficace avec les méthodes agiles, il faut évidemment éviter de tomber dans un certain “angélisme”. Il faut prendre les fameux principes avec précaution et savoir doser ce qu’on garde et ce qu’on laisse. Par exemple “Les individus et leurs interactions plutôt que les processus et les outils » ou « La collaboration avec le client plutôt que la négociation contractuelle ». C’est joli en théorie, mais en pratique cela peut se révéler bien difficile. L’un des problèmes est que les décideurs sont de gens très occupés, et qu’ils n’assistent pas souvent aux meetings avec les équipes de développement. Très souvent des décisions critiques sont repoussées ou prises à la légère (effet comité) même si l’implication sur le logiciel est importante.

Tout cela pour dire que les démarches de type Agile ne doivent pas être considérées comme le Graal que nous attendions tous. C’est un progrès sérieux par rapport aux méthodes “en cascade” mais cela ne nous exonère pas de devoir utiliser notre discernement et notre bon sens.

Retour sur le long chemin qui nous a conduits à Agile…
Pour comprendre pourquoi nous avons tout de même besoin des démarches Agiles, revenons sur les premiers essais et erreurs en matière de méthodes de développement d’applications informatiques… Pour aller au fond des choses, nous allons évoquer tout le parcours vécu jusqu’à aujourd’hui… Restez avec moi, il y a beaucoup à dire !

Pour commencer, l’apparition des méthodes de développement et de suivi de projet peut être vue comme une réaction à la démarche “chaotique” qui régnait dans les premiers temps de l’informatique moderne (mettons dans les années 60). La plupart des activités de développement logiciel suivaient un cours désordonné souvent caractérisé par la phrase “coder et corriger”. Le logiciel était écrit sans vraiment de plan d’ensemble et la conception des systèmes était le fruit de nombreuses décisions basées sur le court terme (tout cela est encore vrai dans bien des cas…).

Ce type de pratique pouvait convenir pour de petits programmes, mais quand on voulait mettre en place des applications plus importantes, il devenait de plus en plus difficile d’ajouter des fonctions au système au fur et à mesure de sa “construction”. De plus en plus de défauts deviennent proéminents et il devient de plus en plus difficile de les corriger.

Une longue période de tests après que le logiciel soit considéré comme terminé sur le plan fonctionnel est un signe typique de ce type de démarche. Elle vient remettre en cause le calendrier du projet puisque la durée des tests et du debug est presque impossible à évaluer.

Apparition des méthodes
Certains ont vécu avec ce style de développement pendant longtemps, mais il existe aussi une alternative depuis des décennies : les méthodes de développement et de suivi de projet. Les méthodologies imposent une discipline sur les processus de développement logiciel avec pour but de rendre le projet plus prévisible et son déroulement plus efficace.

Ce but est théoriquement atteint en suivant un enchaînement rigoureux de tâches et en respectant à la lettre un planning détaillé. Ces méthodologies informatiques sont inspirées ou même dérivées des pratiques connues dans d’autres disciplines faisant appel à l’ingénierie.

La critique la plus fréquente qui est faite à l’encontre de ces démarches c’est qu’elles sont bureaucratiques. Il y a tant à faire pour simplement suivre la démarche que le rythme des projets s’en trouve ralenti. Du coup, on les appelait souvent les méthodologies lourdes, voire “monumentales” (ont dit “en cascade” désormais)…

Le classeur sacré où tout devait être consigné
Les méthodes monumentales étaient souvent basées sur un gros classeur où tout était décrit et où tout devait être consigné. Ces méthodologies étaient connues et utilisées depuis le tout début des années quatre-vingt. Le moins que l’on puisse dire est qu’elles n’ont pas donné de résultats spectaculaires et, conséquence logique, elles sont devenues de moins en moins populaires. Le désaveu qui a frappé les méthodes traditionnelles s’explique facilement : ces démarches strictes sont sans doute adaptées aux domaines de la fabrication en série, mais pas pour le développement logiciel qui est très éloigné du systématisme qui a cours dans l’industrie.

Pourtant, les méthodes traditionnelles avec leur cycle en cascades ne sont pas forcément une ineptie. Comme expliqué ici sur Wikipedia (voir à https://fr.wikipedia.org/wiki/Cycle_de_d%C3%A9veloppement_(logiciel)#Cycle_en_spirale), le cycle en cascade a pour origine l’industrie lourde. La particularité de ce milieu est que la phase suivante nécessite bien plus de ressources que la précédente.

Par exemple, pour fabriquer un objet en matière plastique,

1. un bureau d’étude va concevoir le produit,
2. puis des empreintes de moules seront usinées et placées dans des carcasses pour recevoir de la matière plastique par injection,
3. et une fois que le prototype est correct, on passe à une phase de production.

Il faut savoir que pour un objet simple tel qu’un gobelet en plastique, la conception est une affaire d’une poignée de semaines (soit quelques milliers d’euros) alors qu’un moule (empreinte + carcasse) nécessite plusieurs mois de fabrication et plusieurs centaines de milliers d’euros.

On comprend mieux, avec des contraintes de cet ordre, qu’il vaut mieux s’assurer d’avoir bien bouclé une étape avant de passer à la suivante !

Ceci dit, les projets industriels qui dérapent, ça arrive aussi (on appelle même cela des “accidents industriels” dans les cas les plus extrêmes…).

Un bilan désastreux
Revenons à notre chère informatique. Sous bien des aspects, le bilan des développements associés à ces pratiques (les projets menés avec des méthodes “en cascade”) est terrible. Ces mauvais résultats découlent, entre autres, d’une approche trop planificatrice (démarche inspirée par la doctrine des méthodes classiques) symbolisée par la mode du “schéma directeur” qui sévissait au début des années quatre-vingt. Les directions informatiques payaient alors très cher quelques consultants issus de cabinets réputés afin de rédiger un “plan d’orientation général des développements” (une définition approximative de la notion de “schéma directeur”). Souvent, ce plan d’ensemble était composé de deux parties : un volet fonctionnel (analyse des besoins et des demandes afin de déterminer les applications qu’il fallait développer) et un volet technique (définition d’une architecture informatique et réseau capable de supporter les applications envisagées et choix des outils pour les développer).

Il fallait des mois pour établir ce plan qui, à peine publié, était déjà dépassé par l’évolution de la technique et par l’évolution des demandes des utilisateurs. Lorsqu’enfin, on tenait le précieux document, on pouvait passer à l’examen des demandes et à la mise en œuvre des projets.

Et là, une fois encore, on repartait pour un nouvel “effet tunnel” : rien ne voit le jour pendant un certain temps et quand l’équipe émerge avec son application, le contexte a encore changé !

Un taux de mortalité effrayant !
Avec cette logique de la planification, on pouvait s’attendre à un suivi pointilleux des projets alors que c’est le contraire qui se produisait. Même les organisations appliquant des méthodes de conception et de développement sont, dans la plupart des cas, restées à l’écart des relevés chiffrés permettant de tracer l’évolution des projets de développement (les fameuses “métriques logicielles”).

C’est d’autant plus surprenant que le bon sens veut qu’on ne puisse prévoir avec précision (volet planification) que ce qu’on a déjà mesuré par le passé. Le bon sens n’a pas suffi à assurer la popularité des métriques logicielles…

Bref, toute cette approche de la planification à outrance n’a rien donné de bon et a contribué au désaveu général qui frappe aujourd’hui les méthodes classiques.

Mais, tous les projets n’ont pas été victimes de l’effet tunnel, certains ont été stoppés avant leur terme pour des raisons “politiques” (changement de responsables ou autres…). En cumulant toutes ces aberrations, on en arrive à une mortalité effrayante des projets informatiques.

Un gâchis effroyable ? Oui, mais pas que…
Finalement, toutes ces décennies où les projets informatiques mal gérés ont généré un gâchis effroyable n’auront pas été en pure perte. Si on considère qu’il a fallu tous ces errements pour trouver enfin la bonne démarche, peut-être alors qu’on peut dire que le darwinisme informatique a encore fonctionné puisqu’il nous a conduits à considérer une approche réellement adaptée, les méthodes Agiles.

Développement logiciel : le cœur du problème…
Si on combine les effets pervers bien connus des développements logiciels traditionnels (“effet tunnel” déjà évoqué, “effet comité” qui consiste à faire spécifier un projet par des gens qui ne font pas partie des futurs utilisateurs, etc.), on réalise combien il est effectivement difficile d’aboutir dans ce type de projet en persistant à vouloir les mener avec des méthodologies lourdes qui ne sont pas adaptées à la nature particulière du logiciel.

Car, on ne le dira jamais assez, les projets logiciels ne sont pas comparables aux autres. 

Une des difficultés du logiciel est qu’une demande de l’utilisateur, apparemment anodine, peut avoir de très grandes conséquences en terme d’architecture du logiciel. Et un logiciel un peu conséquent aura une multitude de telles décisions qui ne peuvent pas être toutes trouvées lorsque le cahier des charges initial est écrit. Résultat, l’architecture doit parfois être sérieusement repensée en plein cours de développement. 

De plus, devoir travailler avec de l’intangible est une difficulté particulière toujours négligée. Devoir combiner de la programmation avec de l’ergonomie requiert des talents spéciaux et rares.

En plus, ces talents ne sont pas spécialement doués pour gérer la “relation client”… En effet, les programmeurs sont des gens précis qui aiment les systèmes qui ont des comportements formellement définis. Travailler avec des personnes non sans connaissances techniques est encore plus difficile pour eux; elles ont tendance à prendre chacune des requêtes à la lettre, au lieu d’essayer de comprendre les besoins réels.

En empilant tout cela, on réalise combien une démarche adéquate peut-être utile voire indispensable. Et c’est là que les méthodes Agiles se sont révélées être efficaces, d’où leur succès initial et mérité. Elles se sont retrouvées tout de même sous le feu des critiques, car il faut accepter de vraiment tenir compte de l’essence de la démarche plutôt que de vouloir “être Agile” à la lettre, mais pas dans l’esprit.

Tirer parti de la démarche Agile
Pourtant, tirer profit de la démarche Agile n’est pas si compliqué. Pierre Bougette le dit fort bien dans son article “Comme agiliser son entreprise” (voir à https://www.redsen.com/fr/inspired/intelligence-collective/agile-comment-agiliser-son-entreprise) :

L’Agile est une philosophie fondée sur l’itération et l’empirisme. Elle peut s’appliquer quelle que soit la fonction : direction informatique, ressources humaines ou marketing, etc. Et se décline en différents cadres de travail dont Scrum est le plus connu.

Selon moi, la culture Agile débute par la transparence du travail et la fréquence des événements qui vont permettre de :

• Faciliter le partage d’informations entre les collaborateurs.
• Répartir les responsabilités au sein des équipes.
• Améliorer la qualité de vos réalisations.
• Accélérer la mise en production des projets.

Itérations et dialogues font toute la différence
Agile s’avère particulièrement bien adaptée pour le développement logiciel justement parce qu’elle favorise le dialogue entre demandeurs et développeurs. Les clients ne sont pas très à l’aise dans l’expression en avance de leurs besoins (même s’ils pensent souvent le contraire !). 

Du coup, inutile de les contraindre à rédiger en profondeur et dans le détail tout ce que la future application sera censée faire et comment. Par contre, en présentant souvent ce qui est en train de se faire, il est rare que les futurs utilisateurs ne soient pas capables de préciser ce qui leur plait ou pas. Ainsi, par cette succession de revues (sprint reviews), on affine le projet bien plus facilement (et rapidement !) qu’en voulant tout spécifier dès le départ.

Enfin une démarche adaptée à l’informatique !

Oui, les méthodes Agiles représentent enfin la bonne manière de mener des projets informatiques. Attention tout de même de ne pas tomber dans les pièges habituels où même la meilleure des méthodes ne pourra vous sauver : développer trop et de trop gros projets (voir à ce sujet “Et si la solution c’était de développer moins ?” à https://www.redsen.com/fr/inspired/tendances-decryptees/et-si-la-solution-cetait-de-developper-moins).

Pour aller plus loin…
Xavier Perrin, consultant chez Redsen, vous recommande les ouvrages suivants avec cette précision : les méthodes Agiles ne font que mettre en œuvre des principes du Lean pour le développement logiciel. A ce titre, il est parfois nécessaire de revenir aux principes et d’adapter les pratiques au contexte donné plutôt que de s’acharner sur des pratiques qui ne sont pas toujours adaptées.

• Lean Software Development: An Agile Toolkit (Agile Software Development Series) (English Edition)
• The Principles of Product Development Flow: Second Generation Lean Product Development (English Edition)

 

Pour plus d’informations, n’hésitez pas à nous contacter