En faisant mes adieux à l’agile

• Réexamen critique de la méthodologie Agile qui a dominé l’industrie logicielle : en pratique, elle n’aurait été qu’un ensemble de principes flous et un reconditionnement de problèmes déjà résolus
• L’opposition avec le modèle waterfall relèverait largement de l’illusion, et des concepts clés comme le développement itératif et la participation du client étaient déjà formulés dans des travaux des années 1970
• Agile s’est toujours défini uniquement comme l’opposé du modèle waterfall, alors que les limites de ce modèle étaient déjà largement connues dès les années 1970
• Avec l’émergence récente des grands modèles de langage (LLM), le développement guidé par les spécifications (Spec-Driven Development) redevient central, et une approche centrée sur la documentation gagne du terrain
• Le mot d’ordre agile « du logiciel qui fonctionne plutôt qu’une documentation exhaustive » est désormais en train de céder la place à l’idée que « une documentation exhaustive produit un logiciel qui fonctionne »
• Au-delà du flou laissé par Agile, il est temps de revenir à des principes clairs et à une approche d’ingénierie

---

RIP Agile, we hardly knew ye.
And I mean that literally - because no one was ever clear on what it was.
Agile, repose en paix. Nous ne t’avons jamais vraiment connu.
Et je le dis au sens littéral : parce que personne n’a jamais vraiment su clairement ce que c’était.

Le problème d’identité d’Agile

• Agile a été une immense vague qui a balayé toute l’industrie du logiciel, mais en réalité le concept s’est diffusé alors même que son sens restait flou
• Chaque fois qu’une critique surgissait, la réponse revenait inlassablement : « ce n’est pas du vrai Agile »
• Quand on lit réellement le Manifeste Agile (2001), on y trouve très peu de directives concrètes, plutôt des maximes vagues du type « la collaboration avec le client est plus importante que la négociation contractuelle »
• Des principes comme « accueillir favorablement les changements d’exigences, même tard dans le développement » sont commercialement irréalistes
• Sous l’argument du « True Agile », on a régulièrement évacué les problèmes pratiques en prétendant qu’ils n’avaient rien à voir avec le manifeste
• Si l’industrie de l’agile ne pratique pas réellement l’agile, et si le manifeste lui-même manque de substance, alors la réalité même d’Agile devient sujette à caution

« Un spectre du waterfall hante le logiciel »

• Agile s’est toujours défini uniquement par ce qu’il n’était pas — le waterfall — avec une logique simple : si vous ne faites pas de l’agile, alors vous faites du waterfall, et le waterfall ne fonctionne pas
• Pourtant, le fait que le waterfall ne fonctionne pas était déjà connu dès 1970, et Winston W. Royce en avait expliqué précisément les raisons
• Royce recommandait comme alternative de commencer par la conception du programme, de construire un prototype logiciel pour affiner les exigences, et d’impliquer le client de manière formelle, approfondie et continue
• Tout cela a ensuite été présenté comme l’innovation d’Agile, alors qu’en réalité c’était déjà écrit en 1970, l’année suivant l’alunissage
• Note 1 : comment les programmeurs de l’Apollo Guidance Computer ont-ils pu accomplir un tel exploit sans story points, et sans même connaître le principe selon lequel « une attention continue à l’excellence technique renforce l’agilité » ?

L’article Bell-Thayer de 1976 et l’histoire du développement itératif

• L’article de Bell et Thayer de 1976 est présenté comme le premier texte à employer le terme « Waterfall », et ce terme y sert lui-même d’exemple de ce qu’il ne faut pas faire
• Conclusion de l’étude empirique de cet article : les défauts des exigences ne sont découverts, au cours du développement logiciel, qu’au moment où l’on tente de satisfaire ces exigences par la conception
• Le développement itératif n’avait rien de nouveau et avait déjà été affiné en continu pendant des décennies avant Agile
• Même avant que le manifeste ne « libère » l’industrie, le waterfall n’était pas à la pointe de l’état de l’art, et personne de sérieux ne mettait vraiment en doute l’utilité des exigences et des spécifications

L’essor du développement guidé par les spécifications et l’après-Agile

• Avec la diffusion des LLM, les programmeurs reviennent à l’écriture de spécifications
  • Les LLM étant fragiles face aux entrées ambiguës, décrire clairement le problème s’impose comme le meilleur moyen d’obtenir le bon code
  • Là où Agile mettait en avant « du logiciel qui fonctionne plutôt qu’une documentation exhaustive », le développement guidé par les spécifications propose la thèse inverse : « une documentation exhaustive produit un logiciel qui fonctionne »
• Royce soulignait déjà en 1970 que « documentation, spécification et conception ne font qu’un avant l’écriture du code ; si la documentation est mauvaise, la conception l’est aussi »
  • Il insistait sur le fait que si la documentation n’existe pas, alors la conception n’existe pas non plus
• En revenant sur les travaux de 1970 et 1976, on constate que le Manifeste Agile de 2001 n’a pas apporté d’éclairage réellement nouveau
  • Agile n’aurait fait que remplacer une approche d’ingénierie existante par une définition floue et un emballage commercial, sans produire de progrès substantiel
  • Les articles de ces ingénieurs étaient bien plus clairs dans leur signification
• Alors que le développement logiciel continue de changer et d’évoluer, il est temps d’envoyer Agile dans les livres d’histoire et d’adopter une nouvelle perspective
  • Il faut revenir aux principes clairs et à la pensée d’ingénierie légués par les ingénieurs sérieux du passé