13 min de lecture
Sébastien Nobour
Fondateur de DEVEDANOS
Cycle en V ou agile : la question revient dès qu’on fait développer un logiciel. On y répond souvent en comparant deux méthodes de gestion de projet, avec leurs étapes, leurs réunions et leurs documents. La différence se situe ailleurs. Au début d’un projet, personne ne sait exactement ce dont vos utilisateurs auront besoin. On peut essayer de le prévoir, l’écrire dans un cahier des charges et s’y tenir. On peut aussi l’apprendre en chemin, en mettant le logiciel entre leurs mains, et s’adapter à ce qu’on découvre.
Une approche prédictive décide à l’avance ce qui sera construit, et quand. Une approche adaptative décide au fur et à mesure, à partir de ce qu’on apprend. Et beaucoup de pratiques qui portent aujourd’hui le nom d’agilité prédisent encore, par d’autres moyens.
Le modèle en cascade et le cycle en V partagent un principe. Les étapes se suivent, des exigences jusqu’à l’exploitation, et chacune part du résultat de la précédente. Le plan se fixe au début. Le test vient après la réalisation.
Ce modèle a une histoire, et elle commence par un avertissement. En 1970, Winston Royce, ingénieur chez TRW, publie un article où il dessine cette succession d’étapes. Juste en dessous, il écrit : « I believe in this concept, but the implementation described above is risky and invites failure. »
Il explique pourquoi. La phase de test, placée à la fin, est la première où l’on observe le comportement réel du système. Si ce comportement ne respecte pas les contraintes, il faut revoir la conception. Le développement revient alors à son point de départ, et l’on peut s’attendre, écrit-il, à un dépassement allant jusqu’à 100 % du calendrier ou des coûts.
Royce tient pourtant l’approche pour saine, à une condition : lui ajouter cinq étapes. Parmi elles, faire le travail deux fois, la première version servant de simulation de la seconde. Et impliquer le client, de façon formelle et continue.
Craig Larman, alors directeur scientifique du cabinet de conseil Valtech, et Victor Basili, professeur d’informatique à l’université du Maryland, ont retracé la suite. La norme DOD-STD-2167 du département de la Défense américain imposait un modèle en cascade strict, piloté par les documents, en une seule passe. À la fin des années 1980, le département de la Défense connaît des échecs importants dans ses achats de logiciels. Près de dix ans plus tard, le principal auteur de la norme dit regretter de l’avoir écrite : il ne connaissait pas alors le développement itératif, et il l’aurait fortement recommandé. En décembre 1994, la MIL-STD-498 remplace sa version révisée, la DOD-STD-2167A. Elle décrit un développement en plusieurs versions successives, dont chacune réalise une partie des capacités prévues.
Une approche prédictive reste adaptée à un besoin qui ne bougera pas. Un travail qu’on refait à l’identique devient prévisible. Un logiciel, lui, se développe toujours pour la première fois.
En février 2001, dix-sept spécialistes des méthodes itératives se réunissent dans l’Utah. Il en sort le Manifeste pour le développement agile de logiciels. Son titre dit son objet : le développement de logiciels, pas la gestion de projet.
Ses quatre valeurs tiennent en quatre lignes. L’une d’elles : « L’adaptation au changement plus que le suivi d’un plan ». Deux de ses principes vont dans le même sens : « Accueillez positivement les changements de besoins, même tard dans le projet » et « Un logiciel opérationnel est la principale mesure d’avancement ».
Dans ce texte, l’agilité n’est pas une méthode. C’est une approche : livrer un logiciel qui fonctionne, voir ce qu’il produit, et changer de direction quand ce qu’on apprend le demande.
Une bonne part de ce qui se pratique aujourd’hui sous ce nom réintroduit la prédiction.
Les points. Ron Jeffries, l’un des créateurs d’Extreme Programming, raconte leur origine. Son équipe estimait en « jours idéaux », que les parties prenantes lisaient comme des jours de calendrier. Pour dissiper la confusion, elle les a renommés « points ». En 2019, il écrit : « I like to say that I may have invented story points, and if I did, I’m sorry now. »
La vélocité. Beaucoup d’équipes estiment chaque élément en points de complexité, mesurent combien de points elles terminent par itération, et en déduisent une date. Vasco Duarte en relève le défaut. Il travaille dans le logiciel depuis 1997, pratique l’agilité depuis 2004, et a été l’un des moteurs de son adoption chez Nokia et F-Secure. Dans NoEstimates, un livre qui montre comment suivre l’avancement d’un projet sans rien estimer, il explique qu’en avançant, l’équipe comprend mieux le travail. Certaines équipes finissent alors par réestimer plusieurs fois tout ce qui reste à faire, et la date qu’on en avait déduite ne tient plus. Il revient sur ce point dans un entretien publié par InfoQ en 2015.
Les cadres de mise à l’échelle. SAFe (Scaled Agile Framework) est un cadre conçu pour organiser de nombreuses équipes « agiles » en même temps. Les équipes s’y réunissent toutes les 8 à 12 semaines pour planifier ensemble la période suivante. Parmi les résultats de cette séance, la documentation de SAFe cite un tableau qui fait apparaître les dates de livraison des fonctionnalités et ce qui doit être livré avant quoi.
Le site SAFe Delusion, tenu par un groupe de praticiens de l’agilité, rassemble dix cas documentés d’organisations qui ont adopté SAFe, dans des secteurs et des pays différents, appuyés sur 74 sources. L’une conclut que le cadre a été pour elle plus un frein qu’un avantage ; une autre a vu, après l’avoir quitté, de réelles améliorations et des clients plus satisfaits. Selon les auteurs, les entreprises qui adoptent SAFe perdent souvent l’essentiel des bonnes pratiques agiles, reproduisent, en plus marqué, les faiblesses des méthodes traditionnelles, et consacrent beaucoup de temps à apprendre des pratiques dépassées. Ces effets tiennent à la conception du cadre, non aux personnes qui l’appliquent ni aux coachs qui l’enseignent.
Je l’ai vécu. Dans une organisation qui fonctionnait avec SAFe, j’ai rejoint pour six mois une équipe, sur un projet de 10 M€ prévu sur deux ans. Vers le quatrième mois, on nous a annoncé que le projet était annulé. Je raconte cette expérience sur la page À propos. SAFe est une supercherie, une industrie complète vivant de la vente de formations et de certifications ne servant qu’à décrocher des postes dans de grandes entreprises où l’on brasse du vent.
Face à ces cadres, Bryan Finster a choisi l’humour. Développeur depuis 1996, il faisait partie, chez Walmart, de la petite équipe de cinq personnes qui a introduit la livraison continue auprès de plus de 18 000 développeurs, et il maintient aujourd’hui MinimumCD.org, un site consacré aux pratiques de base de la livraison continue. Il a lancé SADMF, pour Scaled Agile DevOps Maturity Framework : un faux cadre de mise à l’échelle, présenté avec le sérieux des vrais. Il promet « une transformation DevOps sans le risque d’un changement de culture », obtenue par davantage de cérémonies, une documentation exhaustive et des rôles clairement définis. Parmi ses pratiques figurent le « Strategic Test Deferral » (le report stratégique des tests) et le « Precise Forecasting and Tracking » (la prévision et le suivi précis). Parmi ses rôles, un « Review Board Review Board » : un comité chargé de revoir les comités de revue. C’est la caricature de ce que décrit cet article : un cadre qui promet l’agilité sans rien changer à la façon de travailler, et qui ajoute des réunions, des documents, des comités et des prévisions.
D’ailleurs, je suis moi-même certifié SADMF. Vous vous demandez ce que c’est ? Une certification aussi parodique que le cadre qui la délivre.
Martin Fowler, l’un des signataires du Manifeste, a nommé ce glissement en 2018 : « faux-agile: agile that’s just the name, but none of the practices and values in place ». La même année, Jeffries parle lui aussi de « Faux Agile ».
Certaines équipes ont cessé d’estimer. Duarte propose de découper le travail en éléments assez petits pour qu’ils se ressemblent, de compter combien en sont terminés chaque semaine, et de prolonger ce rythme pour prévoir la suite. Allen Holub, architecte logiciel et formateur, accompagne les entreprises vers l’agilité. Dans son introduction à #NoEstimates, il recommande la même méthode. Il propose de prévoir la suite d’après le nombre moyen d’éléments que l’équipe a réellement terminés, plutôt que d’après des suppositions. Pour aller plus loin, il renvoie au livre de Duarte. Il appelle cela des projections, et le mot vient de cette école : on prolonge une mesure au lieu de deviner.
C’est plus honnête qu’une devinette. Mais cela reste une prédiction. On a remplacé une supposition sur l’avenir par une extrapolation du passé.
La question posée n’a pas changé : à quel rythme irons-nous, et quand aurons-nous fini ?
Une approche adaptative ne pose pas cette question. Elle en pose une autre : quelle est la chose la plus utile à faire maintenant ? Et elle y répond avec ce qu’on sait à ce moment-là. Pas avec ce qu’on imaginait le jour du devis.
Dave Farley, ingénieur logiciel et coauteur du livre Continuous Delivery, est plus tranché dans sa vidéo « How To Estimate Software Development Time » : il ne croit pas aux estimations et dit que nous ne devrions pas y croire non plus.
Frédéric Leguédois, coach agile et formateur, va dans le même sens dans sa conférence « Éloge de la simplicité » : « Le planning, c’est la liste de tout ce que nous sommes sûrs de ne pas faire aujourd’hui. »
Adaptatif ne veut pas dire que rien n’est prévu. L’approche prédit ce qui est prévisible : le budget mensuel et les jours de développement par mois. Elle ne cherche pas à prédire l’imprévisible : ce que vos utilisateurs feront d’une fonctionnalité avant de l’avoir entre les mains.
Il y a une raison derrière cette distinction. Quand Microsoft mesure l’effet de ses idées par expérience contrôlée, une sur trois seulement améliore l’indicateur visé. Un tiers n’a aucun effet, un tiers le dégrade (Kohavi et Thomke, Harvard Business Review, 2017). Personne ne sait d’avance lesquelles. On l’apprend à l’usage. Avant de construire quoi que ce soit, une idée peut d’ailleurs se tester : c’est le rôle d’un MVP.
Avec une approche prédictive, la liste des fonctionnalités se fixe au départ, avec le prix et la date. Or la liste s’écrit avant que le logiciel n’existe, le jour où l’on en sait le moins sur l’usage qu’en feront les utilisateurs de votre application. Chaque découverte faite en cours de route devient un avenant. Chaque avenant creuse l’écart avec le devis. Dave Farley l’explique dans sa vidéo « Fighting User Requirements That CONSTANTLY Change » : développer un logiciel, c’est apprendre au fur et à mesure ce qu’il doit faire. Mieux rédiger les exigences n’y suffit pas.
Notre approche de développement agile part de l’autre côté. Ce qui est fixé, c’est le budget et le problème à résoudre. Ce qui reste flexible, c’est le périmètre fonctionnel, c’est-à-dire les fonctionnalités qui répondent à ce problème.
Votre application est utilisable en un mois, en quelques fonctionnalités essentielles : vos utilisateurs s’en servent immédiatement, et c’est leur usage qui définit les fonctionnalités suivantes à développer. Une application vivante n’est jamais finie : si l’on cesse de la faire évoluer, elle ne reçoit plus que des correctifs de sécurité et des mises à jour des composants sur lesquels elle repose, et c’est une application qui se meurt.
Prenons l’exemple d’un robot d’exploration envoyé sur Mars. Sa conception et sa construction coûtent cher, et une fois envoyé, on ne peut pas le faire revenir. Nous devons donc à tout prix éviter les erreurs, car une fois envoyé, on ne peut plus le corriger. Avant le départ, on l’étudie, on le construit et on le teste, quitte à échouer, pour vérifier qu’on a visé juste. Ce qu’on a appris sert ensuite à la version suivante : Perseverance, lancé en 2020, reprend de nombreux composants de Curiosity, son prédécesseur, mais ses roues ont été redessinées, et les essais ont montré qu’elles résistaient mieux aux rochers et au sable. Pour capitaliser ainsi d’une génération à l’autre, il faut une conception facile à changer : c’est cela, la qualité. Une application de tous les jours demande la même rigueur, pour éviter le gaspillage, mais son contexte change sans arrêt : les réglementations, les habitudes, la façon de consommer. C’est comme si l’on devait envoyer un robot sur Mars tous les jours, et que l’espace et Mars changeaient d’un jour à l’autre.
Une fois recettée et mise en ligne, chaque fonctionnalité est jugée sur la réaction de vos utilisateurs, et nous décidons aussitôt avec vous des suivantes, tant que vous le souhaitez.
Nous développons votre application sur mesure pour un budget fixe, facturé chaque fin de mois pour le travail réalisé. Ce budget est arrêté avant de commencer. La liste des fonctionnalités, en revanche, se construit avec l’usage. C’est un forfait, mais pas un forfait à périmètre fixe.
Quand le besoin change en cours de route, qui en paie le prix ? La réponse dépend du contrat, et notre article sur le forfait et la régie compare le forfait à périmètre et budget fixes, la régie, à périmètre fixe et budget flexible, et le forfait à budget fixe et périmètre flexible. Il y a aussi la question du prix. Au forfait à périmètre fixe, le prix est la somme d’estimations faites avant de commencer, sur une liste de fonctionnalités dont on ignore complètement la pertinence. Le coût réel finit souvent au-dessus du budget prévu, pour très peu de fonctionnalités développées qui ont un véritable intérêt commercial : chez Microsoft, nous l’avons vu, une idée sur trois seulement améliore l’indicateur visé. Notre article sur les dépassements de budget explique pourquoi.
Notre guide retrace en détail l’histoire du modèle en cascade, et ce que les créateurs de l’agilité disent de ce qu’elle est devenue.
Vous avez un logiciel à faire développer, ou un outil qui ne suit plus votre activité ? On en parle ?
Livraison continue (continuous delivery) et déploiement continu (continuous deployment) ne diffèrent que d'un geste. Pourquoi un petit changement fréquent est moins risqué qu'un gros, sources à l'appui.
Feature flag, c'est quoi ? Quatre types de toggles, ce qu'il faut essayer avant d'en ajouter un, et sept anti-patterns qui font tourner du code jamais testé.
Quel budget pour créer une application ? Le montant ne suffit pas : visez un objectif plutôt qu'une liste, avec des utilisateurs dès le premier mois.