Une critique du manifeste Agile. (1/3)

Léo DRIAT 20 juin 2021 Critique, Conseils, Non-technique

Faites entrer l'accusé

Agile.

Si vous n'avez pas vécu dans la jungle durant ces 20 dernières années, vous en avez forcément entendu parler.

C'est LA méthodologie phare du développement informatique moderne. Livres, articles, blogs, formateurs et coachs autoproclamés, on en bouffe à toutes les sauces.

Mais s'il y a bien un truc donc on ne parle pas assez, ce sont ses problèmes.

Agile est loin d'être un remède miracle, et beaucoup de projets en ont fait les frais.

Pourtant, la plupart des articles et fils de discussion sur les échecs d'Agile parlent toujours d'une mauvaise implémentation, de développeurs qui n'auraient pas respecté les principes correctement.

C'est un peu facile comme argument. D'ailleurs, c'est le même que certains sportifs utilisent pour défendre le CrossFit : la méthodologie est géniale, et si tu te blesses, c'est que tu l'as mal appliqué, donc c'est de ta faute.

Franchement, je pense qu'au lieu de toujours se justifier en parlant de Dark Agile, on ferait mieux de s'attarder plus en détail sur la méthodologie en elle-même, car comme vous allez le voir, il y a beaucoup de choses à redire.

Bien sûr, je ne suis pas là pour mettre Agile en pièces, car même bien que ça serait très drôle, ça n'aurait aucun intérêt.

Mon but est surtout d'analyser les différents aspects de la méthodologie, déceler les problèmes, préciser certaines choses et présenter des alternatives. Bref, apporter un regard nouveau.


Pourquoi Agile ?

Attends un peu, si Agile était vraiment aussi problématique, personne ne l'utiliserait !

Si l’on veut comprendre comment Agile en est arrivé là, il faut commencer par le commencement. Qu'est-ce qu'Agile ?

Il s'agit d'une méthodologie de gestion de projet destinée au développement logiciel, qui valorise l'humain et la communication plutôt que les outils et les processus.

Elle met en avant une relation continue avec le client et la formation d'équipes autoorganisées (en limitant les influences extérieures) et multidisciplinaires (avec des compétences diversifiées parmi les membres).

Sa particularité est qu'elle contraste totalement avec ce qui était la norme avant, le cycle en cascade, qui est une autre méthodologie définissant un projet comme ayant un début, une fin, et une série d'étapes à accomplir.

C'est le cycle de référence dans la plupart des domaines de l'ingénierie, tels que l'industrie, la manufacture ou la construction… C'est précis, rigoureux, et ça fonctionne plutôt pas mal.

Alors, pourquoi ne pas faire pareil pour du développement logiciel ?

En fait, le cycle en cascade à un gros désavantage : il décourage le changement.

Dans les domaines industriels, ce n'est pas vraiment un problème. Après tout, vous n'allez pas déplacer tous les murs de votre maison après qu'elle soit construite, il faut tout prévoir, car le résultat est figé.

Un logiciel ne fonctionne pas comme ça, il évolue et s'adapte au changement. C'est ce qui marque la différence entre le logiciel (software) et le matériel (hardware) : quand il faut changer le logiciel, on le modifie, quand faut changer le matériel, on le remplace.

Mais théoriquement, rien ne m'empêche de faire des logiciels en cascade ?

En effet, d'ailleurs, c'était monnaie courante à l'époque, mais il y a deux gros problèmes.

Le premier est que ça amènerait à écarter toute notion de changement dans les choix techniques pour faire irrémédiablement des systèmes jetables, c'est dommage.

Le second est bien plus abstrait. Quand un client commande un appareil pour son usine, il sait exactement ce qu'il veut et la manière dont cet appareil va répondre à son besoin.

Mais avec un logiciel, les possibilités sont tellement infinies que les clients ont du mal à comprendre à quel point un logiciel pourra répondre à son besoin, ce qui donne lieu à énormément de confusion :

  • Il ne sait pas du tout à quoi le résultat doit ressembler.
  • Il sait très bien à quoi le résultat doit ressembler, mais celui-ci n'est pas optimal pour résoudre son problème.
  • Il ne veut pas aller au fond de sa pensée de peur qu'elle soit irréaliste.

Or, le but de toute entreprise est de satisfaire son client, c'est une des seules manières de faire un maximum de flouze (ou alors miner de l'Ether comme Shadow).

Donc si le client commande un logiciel et que le résultat ne lui plait pas, vous ne pouvez pas juste lui répondre que c'est ce qu'il avait demandé. Il va vous claquer la porte au nez, et il aura raison, car c'est votre travail de le satisfaire.

C'est pour ça qu'il fallait impérativement une méthodologie plus flexible que le cycle en cascade pour pouvoir collecter les retours du client en continu et améliorer le produit de manière incrémentale.

Autrement dit, les développeurs ont besoin des principes agiles.

Certains s'en sont rendu compte, et ont décidé de s'assembler afin d'écrire le manifeste Agile, un guide pour accompagner les développeurs dans cette démarche.

Qui sont ces développeurs ? Bah, des gens pas trop connus, tels que :

Et bien d'autres.

Avec cette équipe de choc, on pourrait s'attendre à un truc de fou… Mais au final, le résultat est franchement médiocre.

Avant de plonger dedans, je tiens à me décharger de quelques responsabilités :

  • Je ne prétends pas réécrire le manifeste Agile, je ne fais que critiquer son contenu et donner des pistes de réflexion. À prendre ou à laisser.
  • Tous les intitulés des principes sont copiés-collés du site officiel agilemanifesto.org, version française, au 16/06/2021.
  • Je ne parlerais ici que du manifeste Agile et non pas de ses implémentations (Scrum, XP…), je tiens encore à ma santé mentale…

Voilà, maintenant que je me suis mis à dos tous les haters, on peut continuer.


Analyse du manifeste Agile

Commençons par nous attarder un peu sur la taille du manifeste : 206 mots en comptant les 12 principes et les 4 règles, pas d'explications détaillées, pas de mise en pratique, pas d'outils, que dalle, juste de la pure théorie et des généralités.

C'est absurde de penser qu'on peut révolutionner positivement l'industrie du développement logiciel avec un manifeste aussi court, à croire qu'ils n'avaient que des Post-its lors de leur réunion.

Oui, mais justement, c'est fait pour ne pas avoir à imposer des tas de trucs aux développeurs, et leur laisser plus de liberté pour être plus flexible.

Mais c'est justement ça le problème, on ne peut pas écrire un manifeste ultra-théorique pour ensuite venir parler de Dark Agile.

C'est comme si l’on décidait de supprimer toutes les lois pour se baser uniquement sur la déclaration des droits de l'homme, pour ensuite s'étonner du grand nombre d'injustices.

Plus vous laissez de libertés à quelqu'un, plus il aura la liberté de faire n'importe quoi.

Certes, restreindre à mort n'aurait pas été mieux, autant retourner au cycle en cascade. Mais 208 mots ? Il y avait peut-être moyen de faire plus complet, surtout avec une équipe pareille.

Bref, passons à l'analyse.


1. Satisfaction du client

Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
- Manifeste Agile

On commence avec un principe typique de ce qu'on peut retrouver dans ce manifeste. C'est tellement blanc et flou qu'on ne peut qu'être d'accord, comme un discours populiste.

Le gros problème vient de l'ambiguïté sur le mot satisfaire.

Est-ce que cela veut dire qu'il faut répondre aux demandes ou aux besoins du client ? Parce qu'en fonction d'où l’on se positionne, les mesures sont radicalement différentes.

Imaginez que vous recevez un patient souffrant d'aigreurs d'estomac, et qu'il vous demande quelque chose pour calmer sa douleur. Répondre à sa demande est assez facile, un p'tit Doliprane et c'est reparti comme en 40.

Mais si vous faites ça, vous risquez de le voir redébouler le lendemain avec de nouvelles aigreurs, et insatisfait de votre prestation de la veille. Car son vrai besoin n'est pas de calmer sa douleur, mais de ne plus avoir d'aigreur d'estomac.

Il aurait mieux fallu le questionner sur l'apparition des symptômes, son alimentation, ses traitements en cours, etc. Et quand vous avez trouvé la cause, le conseillez pour ne plus qu'il ait d'aigreur ET lui donnez un Doliprane pour calmer sa douleur maintenant.

C'est la même chose avec un client : répondre à ses demandes, c'est bien sur court terme pour lui montrer que vous avancez correctement. Le vrai objectif, c'est de répondre à son besoin.

Mais comme le client à énormément de mal à l'exprimer, la meilleure solution est de devenir un expert du domaine qui concerne votre application.

Je ne vous cache pas que c'est difficile, ça demande parfois des années d'expérience et des compétences qui vont bien au-delà de l'informatique. Mais voici quelques pistes de réflexion pour vous y prendre :

  • Engagez-vous dans de longues discussions avec le client. Essayez de comprendre ce qu'il essaye d'accomplir avec cette application et pourquoi. Ne vous contentez pas de la surface de l'iceberg, laissez-le exprimer tous les détails. Essorez-le comme une éponge avec vos questions jusqu’à ce qu'il vous mette à la porte, rien ne doit vous échapper. Parfois, ce sont des dizaines d'heures d'interrogation qui seront nécessaires avant de bien comprendre ce dont il a vraiment besoin.
  • Dressez des relations avec des experts métiers. Profitez des pauses café/repas pour parler business de manière décomplexée. Le responsable de produit de votre projet ne fait pas exception, il doit être votre meilleur ami.
  • Étudier les applications déjà en places. Lisez la documentation, l'historique des commits, le code source, et essayez de comprendre les raisons derrière chaque fonction.
  • Consommez des ressources sur le domaine. Lisez des articles, suivez des blogs, plongez dans les spécifications et si vous êtes un bon négociateur, faites-vous payer une formation par votre entreprise.

Je vous peut-être donné le tournis, mais satisfaire un client n'est pas un jeu d'enfants. Il ne suffit pas de livrer rapidement et régulièrement des fonctionnalités à grande valeur ajoutée, comme le décrit si bien le manifeste Agile, car encore faut-il savoir où est la vraie valeur. Et le seul moyen, c'est de comprendre le métier.


2. Acceptation des changements

Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.
- Manifeste Agile

C'est le principe clef de ce manifeste, car c'est lui qui fait qu'Agile est si différent des méthodologies classiques. Mais malheureusement, c'est aussi celui où il y a le plus de dérives.

Voici un fait qui risque d'en surprendre plus d'un d'entre vous : aucun logiciel n'aime le changement.

Mais tu as dit…

… Que les logiciels DOIVENT pouvoir changer, pas qu'ils AIMENT changer.

Construire un logiciel capable d'évoluer sans encombre pendant des années est une des choses les plus difficiles à faire dans notre métier. Ça demande un niveau d'expertise technique et architecturale qu'une infime minorité de développeurs possède.

Et pourtant, le manifeste Agile vend ça comme un truc évident, une illumination que les lobbies nous auraient cachée pendant des décennies. Donc forcément, ça ne peut qu'encourager les développeurs à coder n'importe comment.

Sauf que le jour où votre codebase commence à pourrir jusqu’à la moelle, il devient impossible de livrer rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. C'est la fameuse dette technique.

Plus que les accepter, le vrai challenge est surtout de se préparer aux changements, en armant les développeurs pour qu'ils puissent faire face à ces challenges techniques. Je reviendrais sur ce point quand je parlerais du principe n°9.

Un autre truc qui me chiffonne avec Agile est que l'on pousse toujours aux changements d'exigences, sous prétexte d'avantage compétitif, comme si c'était quelque chose de sain.

Soyons clairs, avoir ce genre de mentalité est le meilleur moyen de devenir le larbin du client, qui n'hésitera pas à vous faire subir ses caprices.

Tous les projets Agile dont j'ai fait partie avaient sans cesse les mêmes problèmes :

  • La charge de travail augmente, mais pas les délais.
  • Le client ne prend pas la peine de peaufiner le cahier des charges.
  • Le client envoie ses exigences petit à petit, sans laisser les développeurs avoir une vision globale du projet. Parfois, lui-même ne l'a pas.

C'est pour ça qu'il faut serrer la vis avec le client. Il faut qu'il comprenne que changer les exigences est donnant-donnant et qu'il y aura irrémédiablement un impact, parfois élevé, sur le budget et les délais.

Une fois qu'il a compris ça (ce qui n'est pas gagné avec certains spécimens), il commencera à faire plus attention :

  • Il analysera le retour sur investissement de ses exigences de manière plus précise.
  • Il détaillera ses exigences et écrira un cahier des charges plus étoffé.
  • Il comprendra que certaines fonctionnalités sont plus prioritaires que d'autres.

Mais tout n'est pas à jeter sur le client non plus. Comme pour le principe n°1, être un expert du domaine aide beaucoup, car ça permet de :

  • Combler les trous du cahier des charges.
  • Prioriser soit même les tâches.
  • Anticiper les changements d'exigences.

3. Cycles de développement

Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
- Manifeste Agile

Je suis sincèrement bafoué qu'un principe aussi ridicule fasse partie de ce manifeste. Je m'explique.

Déjà, il ne faut pas confondre logiciel opérationnel et logiciel à haute valeur ajoutée :

  • Un logiciel opérationnel fonctionne comme il le devrait.
  • Un logiciel à haute valeur ajoutée répond précisément aux besoins de celui qui l'utilise.

Autrement dit :

Un logiciel opérationnel sans valeur ajoutée ne sert strictement à rien. C'est comme cuisiner un délicieux pavé de bœuf de Kobe pour le donner à manger au chien.

Donc non, ne vous contentez pas de simples logiciels opérationnels. Livrez des logiciels à haute valeur ajoutée sans bugs.

Ça parait évident dit comme ça, mais regardez plutôt la seconde partie : avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

Ce n'est pas précisé si ces cycles doivent être de taille fixe ou non (évidemment…), mais si c'est le cas, c'est juste un énorme frein à la qualité du logiciel et à l'apport de valeur.

Après tout, dans un restaurant, le serveur vient vous apporter vos plats dès que le cuisinier a fini de les préparer. Il ne va pas vous apporter la vinaigrette, puis les lardons, la garniture et enfin les feuilles de salade, ça serait débile.

Une fonctionnalité, par définition, n'a de valeur que quand elle est terminée, pour certaines ça prendra deux jours, pour d'autres ça prendra deux mois. Livrer un truc opérationnel, mais incomplet juste pour respecter un cycle, ça ne sert à rien.

Mais comment je fais pour avoir son retour d'expérience si je ne lui livre qu'une fonctionnalité tous les deux mois ?

Facile, vous lui mettez à disposition une démo qui se met à jour automatiquement quand les développeurs poussent du code stable, et qu'il peut consulter à tout moment pour voir l'avancement du projet et faire des remarques.

En complément, vous pouvez aussi régulièrement enregistrer des vidéos de ce que vous avez fait, ça permet de vraiment présenter le flux de travail de l'application.

Enfin, une petite présentation fait toujours son petit effet et favorise le retour utilisateur à chaud.

Outre l'aspect communication, il ne faut pas sous-estimer le DevOps, car c'est lui qui vous permettra de maintenir une démo stable, et de publier vos corrections de bugs à chaud dès qu'ils sont prêts à la production.

Je m'arrête ici pour cet article. Dans le prochain, j'aborderais les autres principes, et dans le dernier, je ferais un récapitulatif plus général sur le manifeste et comment ne pas tomber dans ses travers.

Je précise encore une fois que mon but n'est pas de démonter Agile. En réalité, le manifeste me sert surtout de support pour parler de mon flux de travail.

Donc si vous voulez ajouter quelque chose, exprimer une critique ou partagez votre expérience, les commentaires sont faits pour ça.

Je vous invite fortement à commenter ici plutôt que sur les agrégateurs et réseaux sociaux (ou de faire les deux), car ça permet à tous les lecteurs de pouvoir suivre la discussion.

Merci d'avoir lu cet article jusqu'au bout et de faire partie des 20% de personnes qui n'ont pas ragequit en cours de route !

Pensez à le partager, c'est le meilleur moyen de soutenir le blog <3, et suivez-moi sur Twitter @ITExpertFr pour avoir la suite en avant-première.

Et pour ceux qui veulent plus de concret dans les pratiques Agiles, voici quelques articles qui devraient vous intéresser.

Quant à moi, je vous laisse, il faut que j'aille écrire la partie 2 parce que je n'ai pas commencé (aïe…).

À bientôt pour un nouvel article sur le blog des développeurs ultra-efficaces. Tchao !