Agile, une innovation de rupture

En quoi le débat en cours entre le Génie Logiciel inspiré par les conférences de 68-69 d'une part, et le challenger Agile d'autre part, répond-il à la théorie de la rupture évoquée dans le précédent billet?

Pour obtenir une réponse, il faut se repencher sur les origines du Génie Logiciel dans la "crise du logiciel". Celle-ci se manifeste initialement par des difficultés à fournir des prévisions fiables quant aux projets, souvent liées à des allers-retours autour des exigences. Le critère de performance exigé de tout ce qui se présente comme une solution à ladite crise est, en un mot, la possibilité de contrôler tout aléa. On va privilégier la traçabilité, la documentation, et le respect des contraintes que ces outils permettent de suivre le mieux: délais (et donc coûts) maîtrisés, spécifications respectées.

"Ça ne peut pas marcher"
 
Cette phrase qui constitue le leitmotiv d'un des chapitres du livre de Kent Beck illustre bien en quoi l'approche Agile joue le rôle du produit "gadget", totalement insuffisant, dans l'analogie avec la photo numérique autour des années 1990.


Planifier en permanence, ça ne peut pas marcher, on ferait peur au client (pas assez de contrôle). Mettre une nouvelle version en exploitation tous les mois ou deux, ça ne peut pas marcher, on ferait peur aux utilisateurs (pas assez de contrôle). Démarrer le développement avec une vision architecturale résumée en une métaphore, ça ne peut pas marcher, et si on s'était trompés? (Pas assez de contrôle.) Ne pas anticiper sur les besoins futurs lors de la conception, ça ne peut pas marcher, on se retrouvera coincés (pas assez de contrôle). Faire écrire les tests par les programmeurs, ça ne peut pas marcher, tout le monde sait que les programmeurs ne peuvent pas tester leur propre travail et que le test est une profession à part entière (pas assez de spécialisation, donc de contrôle). Travailler en binômes, ça ne peut pas marcher, ça va prendre deux fois plus longtemps, et ils risquent de ne pas s'entendre (pas assez de contrôle, mais aussi une vision du développement comme activité mécanique, réduite à la saisie de code au clavier).


Pour la plupart ces arguments sont légitimes, de même qu'il est légitime de condamner en 1990 la nouvelle technologie numérique comme tout à fait inadéquate.


Valeurs classiques contre valeurs agiles


L'approche Agile quand à elle est initialement destinée à des projets qui ne se soucient que très peu de contrôler et de tracer. On privilégie la communication directe et orale avec le client, lui permettant d'ajuster sa demande en temps réel; la qualité du produit et sa pertinence pour répondre aux besoins réels (plus qu'à ceux exprimés), la maîtrise des priorités fonctionnelles sous contrainte de délais.


Ne pas chercher à faire concurrence aux "méthodologies" dominantes et aux approches de management orientées sur les production documentaires de ces dernières permet aux "agilistes" comme on ne les appellera que plus tard de s'affranchir de nombreuses contraintes, et d'inventer un mode de développement très souple, basé sur des itérations courtes régies par la règle du "timebox" (on cherche à en faire le maximum en temps imparti plutôt qu'à terminer un objectif fixe quitte à jouer les prolongations), décomposé par incréments fonctionnels. Les phases amont et le travail documentaire sont réduits à l'essentiel, c'est-à-dire à ce qui permet à l'équipe de partager une même compréhension de l'objectif. Le chef de projet perd ses prérogatives: il n'attribue plus les tâches et ne joue plus les intermédiaires, le client étant présent sur place. Des dispositifs techniques (automatisation des tests, intégration continue) limitent au minimum les coûts d'intégration et de refonte.


Une métaphore souvent employée compare l'équipe Agile à des musiciens de jazz qui improvisent, par rapport à leurs collègues dans une formation classique: l'absence de contrôle n'implique pas moins de technicité, et de satisfaction procurée par le résultat final.

Une recherche textuelle dans les actes des conférences de l'OTAN (NATO1968), comparée à la même recherche (grâce à Google Books) dans les actes de la conférence européenne sur XP et les processus agiles (XP2008) permet d'objectiver quelque peu ces différences de valeurs:

• le mot-clé "control" apparaît plus de 100 fois dans NATO1968, 27 fois dans XP2008 (et souvent dans le contexte "groupe contrôle vs groupe expérimental", pour les papiers scientifiques
• le mot-clé "team" apparaît plus de 100 fois dans XP2008, seulement 17 fois dans NATO1968
• le mot-clé "skill" apparaît seulement 5 fois dans NATO1968, 15 fois dans XP2008
• le mot-clé "motivation" apparaît seulement une fois dans NATO1968 ("la motivation de cette conférence..."), 12 fois dans XP2008 et pour la plupart au sens "motivation de l'équipe"

Le critère de performance privilégié par l'approche Agile, ce n'est plus le contrôle, mais bien l'exploitation du talent individuel et collectif. Lorsque les approches Agiles se font connaître sous ce nom, en 2001, ces valeurs sont codifiées sous la forme du fameux Manifeste Agile.

Agile, dix ans après

Mais depuis 2001, les pratiques ont évolué: le challenger Agile a progressé sur plusieurs critères de performance y compris ceux reconnus par le modèle dominant. C'est exactement ce que prédit la théorie de la rupture, pourtant cette évolution est en grande partie invisible, très peu reconnue par les professionnels qui ont rejoint la communauté récemment et ignorée même d'un certain nombre de vétérans. (Ou bien, elle se traduit pour certains par un inconfort, un sentiment que "Agile c'est devenu n'importe quoi".)

Plusieurs pratiques considérées désormais comme au coeur de Scrum sont ainsi apparues depuis 2001, postérieurement au terme “Agile” lui-même: par exemple les Rétrospectives et le Task Board, deux pratiques très proche du "noyau" mais pourtant d'importation relativement récente. Quant à Extreme Programming son statut de "work in progress" est acquis depuis la deuxième édition du livre de Kent Beck.

Des pratiques sont apparues pour combler par exemple des lacunes dans la prise en compte de l'ergonomie par les approches Agiles, ou encore pour donner des directives plus précises sur la façon d'organiser les "phases amont", le recueil des exigences: on parle de Personas, de Charte Projet, de Story Mapping.




Initialement vécue comme une obligation déraisonnable, la pratique Extreme Programming désignée à l'origine par le conseil "faites écrire vos tests de recette par le client" a beaucoup évolué et donné naissance à des écoles et appellations diverses: ATDD ou pilotage par les tests client, BDD ou Spécifications Exécutables. Bien que ce sujet soit actuellement en pleine fermentation pour ainsi dire, une tendance se dégage clairement: ces évolutions commencent à répondre de façon satisfaisante aux exigences de formalisation et de traçabilité qui sont l'apanage des organisations les plus exigeantes en termes de contrôle.

Des pans entiers de pratiques ont enfin servi à occuper de nouveaux terrains. En 2001, Scrum et XP se focalisent sur de petites équipes colocalisées dont la préoccupation presque exclusive est le développement dans un contexte projet: la "date de fin" est une des préoccupations majeures, on conçoit le projet comme un effort unique au-delà duquel l'équipe passe à autre chose.

Ce n'est qu'au fil du temps que la recherche d'adaptation des approches agiles à d'autres contextes conduit à explorer des pratiques alternatives. Ainsi l'approche Lean et Kanban peut-elle trouver un terrain d'application fertile parmi les équipes chargées de maintenance ou de TMA. La communauté Agile voit aussi se développer des mouvements visant à repenser d'autres métiers, à l'image de DevOps qui réunit des admin systèmes sensibles aux évolutions du développement.

Agile dans dix ans?

 En 2010, la photo numérique a entièrement remplacé la technologie précédente (et une nouvelle mutation s'amorce, celle du cinéma, mais c'est une autre histoire). Peut-on imaginer un avenir comparable pour les approches Agiles?


Il convient de rester prudent. D'une part, on apprend vite quand on s'intéresse à l'histoire et à la sociologie des sciences et des techniques que le progrès n'est jamais gagné d'avance. (J'y reviendrai, notamment en parlant des travaux de Bruno Latour qui sont très pertinents pour comprendre ce qui se trame autour de l'Agilité.) Rejeté par toute la communauté médicale de son temps, Semmelweiss ne fut reconnu comme un pionnier de l'hygiène médicale qu'après avoir été poussé à une dépression nerveuse qui lui fut fatale. Il faut du temps, beaucoup de travail et sans doute un peu de chance pour qu'une idée s'impose de manière irréversible; le plus simple est sans doute encore de considérer que tout est réversible.

Une existe une autre raison d'être prudent: le statut de "challenger" ne confère pas automatiquement l'infallibilité de ceux qui se rangent sous sa bannière. Comme le disait Carl Sagan: "They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown." On s'est moqués de Christophe Colomb, de Robert Fulton - l'inventeur du bateau à vapeur - des frères Wright, et de Semmelweiss.

Mais on s'est aussi moqués de tout un tas de gugusses que l'histoire a eu bien raison d'ignorer.

Notamment, certaines lacunes persistantes continuent à plomber la communauté Agile, et risquent de mettre en péril l'avenir du sujet. Je traiterai ce sujet brièvement dans le prochain billet.

La cascade, retour aux sources

Si vous avez apprécié le précédent billet sur la discrète et méconnue histoire du Génie Logiciel, je vous recommande chaudement cette vidéo d'une intervention de Glen Vanderburg en partie sur le même sujet.

Dans la série "comprendre l'origine des idées pour éviter de nous faire piéger par elles", Glen retrace également l'historique du "waterfall" ou processus en cascade, dont le fameux "cycle en V" est une variante mieux connue en France.

On y découvre que la raison de la popularité de ce processus d'ingénierie est que la plupart des lecteurs ont préféré retenir le diagramme n°3 dans le papier de Winston Royce datant de 1970, et ce malgré l'avertissement de Royce sur l'aspect "dangereux et incomplet" du processus représenté dans ledit diagramme; oui, mais les diagrammes suivants dans ce même article étaient... de plus en plus complexes, puisque représentant une pensée plus sophistiquée, et par voie de conséquence impossibles à graver en mémoire aussi facilement. Il n'en fallait pas plus pour que de nombreux décideurs et influenceurs ne gardent en mémoire que la solution "simple, élégante et totalement fausse" selon la citation de H.L. Mencken.

Cette théorie est intéressante (et la conférence de Glen savoureuse), mais un peu battue en brèche par la lecture attentive des actes de la conférence de 1968, puisque dès le second diagramme contenu dans ces derniers on peut tomber sur une représentation tout à fait classique en phases successives du processus de développement, et ce deux ans donc avant l'article de Royce.

Il est cependant exact que c'est l'article de Royce qui sera pendant des années cité comme principal soutien d'une conception "phasiste" de l'organisation des activités de développement. A vous de juger de la pertinence de cette théorie!

Quarante ans de crise

Connaissez-vous l'expression "crise du logiciel"? Peut-être connaissez-vous un peu mieux une de ses manifestations, la célèbre illustration du "Projet Balançoire". Tellement célèbre qu'elle a depuis quelque temps son propre site web 2.0, normalement elle se passe de commentaires...

Le terme "crise du logiciel" est contemporain d'une autre expression certainement plus familière, "Génie Logiciel", formulée en 1968 lors d'une conférence organisée sous les auspices de l'OTAN. La seconde fut proposée comme solution de la première.

La Crise se manifestait par divers aspects. Les projets de développement dépassaient les délais et budgets impartis, les logiciels produits étaient de mauvaise qualité et leurs performances insuffisantes, ils ne répondaient pas aux exigences exprimées, ils étaient difficiles à faire évoluer.

Il y eut non pas une mais deux conférences de l'OTAN sur le Génie Logiciel, à un an d'intervalle. Que se passa-t-il durant ces douze mois? Presque en filigrane du discours officiel, on devine un événement d'importance.

En 1968, la première conférence semble poser une question. "L'approche de l'ingénieur est-elle appropriée pour aborder le développement de logiciels?" Environ cinquante experts venus de onze pays sont présents. Parmi les participants on compte des sommités comme Edsger Dijkstra (connu pour sa campagne contre le "goto" et en faveur de la programmation structurée), Alan Perlis (créateur d'Algol et auteur de proverbes qui sont au logiciel ce qu'une certaine tradition japonaise est au jeu de Go) ou Peter Naur (co-crédité de l'invention de la notation BNF pour décrire les langages de programmation).

Les actes des deux conférences disponibles sur le Web, dans une version PDF d'une qualité remarquable alors que la plupart des documents de cette époque sont en général simplement scannés, donc non indexés ni "cherchables", méritent d'être lus avec attention; j'avoue ne les avoir que trop rapidement parcourus jusqu'à présent, en tout cas pas avec la minutie qu'un historien leur accorderait. On y trouve par exemple ce conseil de Peter Naur qui recommande de s'intéresser aux idées d'un jeune architecte, Christopher Alexander. Le même Alexander qui sera redécouvert vingt anx plus tard par un certain Kent Beck, donnant naissance au mouvement des Design Patterns. Structurés d'une façon très systématique, ils couvrent la quasi-totalité des préoccupations encore d'actualité aujourd'hui quant à la façon de mener des projets dans le domaine du logiciel.


Ces documents sont éloquents quant au degré de controverse que suscite la question du génie logiciel. Voici une citation d'un participant: "La chose la plus dangereuse dans le domaine du logiciel est l'idée, apparemment presque universelle, que vous allez spécifier ce qu'il y a à réaliser, puis le réaliser. Voilà d'où viennent la plupart de nos ennuis. On appelle réussis les projets qui sont conformes à leurs spécifications. Mais ces spécifications s'appuient sur l'ignorance dans laquelle étaient les concepteurs avant de démarrer le boulot!"

Les titres de la conférence de 1968 reflètent un certain degré d'incertitude: "Réflexions sur le séquencement de l'écriture d'un logiciel", "Vers une méthodologie de la conception", "Quelques réflexions sur la production de systèmes de grande taille". Certes la plupart des participants utilisent l'expression "Génie Logiciel" comme si elle allait de soi, et des lacunes sont déjà apparentes (on parle notamment assez peu du facteur humain), mais on peut deviner une véritable controverse sur les grandes lignes de ce qui préoccupera cette discipline.

En 1969 les titres des articles proposés ont gagné en assurance. "Critères pour un langage de description de systèmes", "La conception de systèmes très fiables en exploitation continue", etc. Mais c'est surtout en lisant entre les lignes qu'on décèle un changement, et notamment en lisant "The Writing of the NATO reports" de Brian Randell, une sorte de "making of" datant de 1996. Une drôle d'ambiance règne apparemment à la conférence de 1969, mais on ne peut que la deviner dans la description à demi-mot qu'en fait Randell:

Contrairement à la première conférence, ou il était tout à fait clair que le terme de Génie Logiciel reflétait l'expression d'un besoin plutôt qu'une réalité, à Rome on avait déjà tendance à en parler comme si le sujet existait déjà. Et, pendant la conférence, l'intention cachée des organisateurs se précisa, à savoir: persuader l'OTAN de financer la mise en place d'un Institut International du Génie Logiciel. Cependant les choses ne se passèrent pas comme ils l'avaient prévu. Les sessions qui étaient censées fournir les preuves d'un large et ferme soutien à cette initiative furent en fait dominées par le plus grand scepticisme, au point qu'un des participants, Tom Simpson de chez IBM, écrivit une superbe et courte satire intitulée "Masterpiece Engineering" (Ingénierie du Chef-d'Oeuvre).

Un article qui parlait, par exemple, de mesurer la productivité des peintres en nombre de coups de pinceau par journée. Et Randell d'ajouter que les organisateurs réussirent à le "persuader" d'omettre cet article satirique de Tom Simpson des actes officiels!

L'acte de naissance définitif du Génie Logiciel ayant ainsi été associé à un acte de censure, Randell ajoute qu'il s'interdit pendant la décennie qui suivit d'utiliser le terme, le jugeant injustifié. Il n'acceptera de revenir sur cette décision que pour une conférence marquant en 1979 le dixième anniversaire de Rome, où il profita de l'occasion pour adresser à Barry Boehm, alors la "nouvelle star" de la discipline, une série de piques, que Boehm "ignora soigneusement, je suis navré de le rapporter, à moins qu'il n'ait pas été en mesure de les reconnaitre comme telles".

Ingénieur en logiciel, un métier sans histoire?

Souvent, pour prendre du recul par rapport au monde du logiciel, je m'évade vers d'autres disciplines. Au cours de ces balades, le paysage m'étant par définition étranger, j'ai le loisir de me comporter en touriste, sans me sentir aggressé lorsqu'une de mes idées toutes faites, confrontée à la réalité locale, se retrouve bouleversée.

Parmi les guides que j'affectionne, Stephen Jay Gould était particulièrement doué pour emmener le lecteur dans un coin intéressant de son propre fief, la biologie et l'évolution. J'ai surtout apprécié dans ses écrits l'usage qu'il faisait de l'histoire des idées scientifiques. Il n'avait pas son pareil pour montrer comment, loin d'être un inexorable progrès comme peut le laisser croire certaines images d'Epinal, de nombreuses découvertes sont le fait de curieux renversements, et bien souvent la lecture qui en est faite finit elle aussi à l'envers de la réalité.

Dans Aux Racines du Temps, par exemple, Gould revient sur les portraits souvent dressés de trois acteurs importants dans l'estimation de l'âge de la Terre et des débuts du "temps géologique", un débat qui est un précurseur important à l'acceptation des théories de Darwin: pour que l'évolution puisse avoir lieu, il faut que nos origines remontent à bien plus que la période donnée par la Bible, à savoir quelques milliers d'années seulement.

L'image d'Epinal de ce débat est celle de deux héros (Hutton et Lyell) triomphant, grâce à leur lucidité scientifique et leur courage exemplaire, du rétrograde et fondamentaliste Thomas Burnet. Gould met en évidence l'inspiration véritable, fortement naturaliste, des arguments avancés par Burnet, la forte emprise idéologique sous laquelle Hutton formula les siens ou le scepticisme de Lyell vis-à-vis des idées de Darwin. Le travail de Gould est minutieusement documenté, étayé notamment par une lecture de première main des textes originaux, lesquels éclairent de façon implacable sur les motivations véritables des uns et des autres.

A lire Gould, on comprend qu'il faut se méfier d'une interprétation trop simpliste de l'histoire des idées. Plus nous travaillons dans le monde des idées, plus les idées peuvent exercer sur nous un contrôle d'autant plus fort et d'autant plus insidieux que nous en ignorons les origines.
C'est à ce stade que souvent, loin de rester de simples promenades, ces lectures me ramènent indirectement à mon propre métier.

Je me fais parfois la réflexion que notre profession tourne résolument le dos à sa propre histoire. Je ne prétends pas être particulièrement bon élève de ce point de vue, et lors de mes courtes études, l'histoire était parmi mes points faibles. Je manque sans doute cruellement de culture générale, mais au sein de ma propre profession, je me fais parfois l'impression du borgne au royaume des aveugles.

Ainsi des idées nous sont-elles présentées comme "neuves" et "révolutionnaires" alors que, pour qui s'est penché sur l'historique de la discipline, il ne s'agit que de réchauffé: des idées présentes dans tel ou tel dialecte de Lisp ou de Smalltalk depuis trente ou quarante ans. (Si vous ne me croyez pas, penchez-vous sur les comparaisons entre XML et les "s-expressions" ou entre la Programmation Orientée Aspects et les MOP ou Meta-Object Protocols.)

On pourrait aussi se demander combien, parmi ceux qui se réclament aujourd'hui du mouvement Agile, ont conscience de ses prédécesseurs, tels le RAD ou le Processus en Spirale dû à Barry Boehm. De façon générale, notre profession tend à considérer toute idée âge de plus de cinq ans comme obsolète et peu digne d'intérêt, et c'est sans doute en partie pour cela qu'on a parfois l'impression que notre industrie est aussi dominée par des cycles de mode que la haute couture.

Parmi les idées qui ont façonné les métiers du logiciel, une l'a fait de façon particulièrement forte et durable, l'idée du Génie Logiciel. Le logiciel relève-t-il vraiment d'une activité d'ingénieur? La question, lancinante, revient comme un serpent de mer dans les conférences consacrées au sujet, mais elle est rarement traitée sous un angle historique.

Au quotidien, trop rares sont ceux qui semblent conscients que le "logiciel" ayant lui-même une histoire d'à peine plus d'un demi-siècle, il a bien fallu inventer l'expression Génie Logiciel; que celle-ci ne va pas de soi, et que l'application des techniques de l'ingénieur au domaine du logiciel relève, non pas des lois de la nature, mais d'une décision à laquelle il a fallu rallier divers groupes: des militaires, des scientifiques, des groupes industriels.

Nous allons donc nous plonger dans la discrète histoire du Génie Logiciel. C'est une excursion qui a de quoi satisfaire les esprits curieux, même s'il devaient en ressortir plus convaincus que jamais de la pertinence de ce mariage. Mais nous verrons que cette histoire a de quoi alimenter bien des doutes...