De l'opinion au savoir

Dans mon billet précédent je pointais ce qui me semble être des faiblesses des études actuellement les plus diffusées sur les "bénéfices de l'Agilité".

Pour ceux qui ont suivi les épisodes précédents, ce n'est pas difficile de comprendre d'où me vient cette attitude critique: d'une part parler "d'un projet Agile" en soi ne veut pas dire grand-chose, puisque ça ne nous dit rien sur ce que font les gens; d'autre part les apparences de la science ne suffisent pas à faire d'une étude quelque chose qui créée de la connaissance: le Culte du Cargo existe aussi dans le domaine scientifique.

J'ai entendu plus d'une fois l'argument suivant:

Ce n'est pas possible d'aborder de façon scientifique les projets logiciels, parce qu'ils sont le fait d'individus, humains et uniques, et que leurs projets sont eux-mêmes uniques.

Je ne suis absolument pas d'accord.

Qu'est-ce que c'est, sans vouloir chercher midi à quatorze heures, qu'un savoir scientifique? C'est un énoncé qui se vérifie de manière fiable dans toute une catégorie de situations, indépendamment des opinions de l'observateur. Par exemple "l'eau bout à 100 degrés" est une observation qui se vérifie avec beaucoup de régularité, et en particulier indépendamment de mes convictions sur ce que l'eau devrait faire à telle ou telle température, de mes décrets ou de mes incantations à ce sujet.

Certes il existe des exceptions: par exemple, si on veut faire du bon café au sommet de l'Himalaya, il vaut mieux savoir que la pression atmosphérique joue un rôle dans cette relation fiable entre l'état liquide ou gazeux de l'eau et sa température. Pour être vraiment précis, on pourra dire "l'eau bout à 100 degrés dans les conditions normales de pression et de température ambiante." Ces exceptions ne sont  pas plus une affaire d'opinion que la règle à laquelle elles s'opposent. Le point d'ébullition de l'eau est un fait réel; pour reprendre une citation de Philip K. Dick: "la réalité, c'est ce qui continue d'exister même si vous cessez d'y croire".

A quelles réalités sommes-nous confrontés dans le domaine du logiciel? Elles sont de deux catégories, et malheureusement les recherches scientifiques à ce sujet ont tendance à faire, au mieux une impasse, au pire de graves contre-sens, vis-à-vis de l'une de ces catégories.

D'une part il existe la réalité de ce qu'un programme peut ou ne peut pas faire. Cette branche, c'est (dans les grandes lignes) l'algorithmique, la discipline appelée imprudemment "computer science", étrange étiquette puisqu'elle s'apparente plus aux mathématiques qu'aux sciences expérimentales et qu'elle n'étudie quasiment pas les ordinateurs. Les faits qu'on y découvre sont souvent très contre-intuitifs et leur applicabilité pratique rarement évidente. Par exemple la Thèse de Church-Turing qui permet notamment de démontrer que tous les langages de programmation et tous les ordinateurs se valent, du moins en termes de leur capacité à instantier n'importe quel processus qui peut s'exprimer sous la forme d'un programme: dans la pratique, les programmeurs professionnels sont précisément intéressés par l'inverse de cette conclusion, à savoir quel langage est le plus approprié.

La raison tient à l'autre catégorie de réalités pertinentes dans le domaine du logiciel: celles qui concernent le fonctionnement et les limitations de l'esprit humain. Nous ne nous intéressons que de loin en loin à ce qu'il est possible "en principe" à un ordinateur de faire; au quotidien, nous sommes plus concernés par leur application "en pratique", et notamment à savoir à quel coût et en combien de temps nous pouvons faire quelque chose, et quels sont les facteurs qui influent sur ces réponses.

Est-ce qu'il est impossible d'étudier le fonctionnement et les limitations de l'esprit humain? Pas du tout, la psychologie et les sciences cognitives le font depuis fort longtemps. Pour autant, il faut avancer avec prudence, parce que dès lors qu'on s'intéresse à l'humain, les opinions et croyances de l'observateur ou de l'observé ont une fâcheuse tendance à influer sur les résultats des expériences! On connait par exemple les distortions introduites par l'effet placebo, qu'on va chercher à éliminer par la mise en place de protocoles expérimentaux adaptés, tels que les protocoles en double aveugle.

L'équivalent dans notre domaine de l'effet placebo pourrait bien être l'effet Hawhthorne: lorsque des travailleurs savent qu'ils sont les sujets d'une expérience sur les conditions de travail, leur performance s'améliore, indépendamment des conditions expérimentales précises auxquelles ils sont soumis. Ce résultat souligne au passage que la motivation est un paramètre expérimental comme un autre, une observation qui a son importance. Elle peut facilement menacer la validité d'une étude scientifique sur la performance ou la productivité.

Contrairement à ce qu'on peut découvrir sur le point d'ébullition de l'eau, ces études ont aussi en commun avec, par exemple, la recherche médicale le fait de s'intéresser à des phénomènes qui sont rarement systématiques, mais au contraire présentent un aspect probabiliste. Cette difficulté vient de ce que l'esprit humain est complexe, il se compose d'un très grand nombre de processus qui contribuent de façon différente et parfois contradictoire aux résultats observés (et peuvent même interagir). Selon le processus qui l'emporte dans une situation donnée, le résultat peut être différent; il n'est généralement pas possible de reproduire la situation initiale avec assez de fidélité pour obtenir systématiquement le même résultat.

Est-il impossible d'étudier scientifiquement des phénomènes résultant, de façon probabiliste, de processus complexes? Evidemment pas; il faut par contre se doter des outils appropriés. La statistique permet de décrire les relations entre les paramètres qu'on arrive à tenir fixe d'une situation à une autre, et les résultats observés. Elle permet par exemple de mettre en évidence des corrélations, qui sont la matière première principale de très nombreuses études. Là aussi, il faut savoir rester prudent. Ce n'est pas l'outil statistique en soi qui rend scientifique une étude. Il faut savoir se méfier, par exemple, des conclusions hâtives à la lecture de simples corrélations.

Saviez-vous par exemple qu'une étude scientifique a constaté, sur un échantillon représentatif de plages touristiques, qu'il existait une nette corrélation entre le nombre de sorbets et crèmes glacées vendues par les buvettes chaque saison et le nombre de morts par noyade? On pourrait être tenté d'appeler au vote d'une loi interdisant la vente de glaces... Ce qui serait une idiotie: ce sont en fait deux paramètres corrélés à un troisième, la fréquentation des plages. S'il fait beau et chaud et qu'il vient beaucoup de monde sur la plage, on vendra plus de glaces ET il y aura (statistiquement, c'est hélas difficile à éviter) plus de noyades. Cette erreur est désignée de plusieurs façons: "cum hoc ergo propter hoc", "corrélation n'est pas causation", etc.

Raisonner de façon claire sur les phénomènes probabilistes n'est pas chose simple, parce que l'esprit humain est mal équipé pour traiter les probabilités. Je reviendrai là-dessus plus tard, lorsque j'aborderai un sujet presque totalement ignoré dans la recherche sur le génie logiciel, qui joue pourtant un rôle majeur pour expliquer la presque totalité des difficultés que nous rencontrons encore quarante ans après le "constat de crise" de notre profession: celui des biais cognitifs.

Il me semble parfaitement possible d'étudier de façon scientifique une question telle que "les approches Agiles ont-elles plus d'intérêt", mais il est clair que pour le faire il n'est pas possible de s'arrêter à une interprétation naïve de cette question. Il faut regarder de plus près, d'une part ce qu'on veut dire par une approche Agile, mais aussi ce qu'est le travail des scientifiques.

Dans le prochain billet, je reviendrai sur un exemple très concret pour illustrer un élément important de ce travail: le "fait scientifique" selon lequel la productivité des programmeurs varie dans un rapport de 1 à 20.

Recherche: garder l'esprit critique

Merci à Claude d'avoir pris le temps d'une réponse point par point à mon billet précédent sur les "cinq défis". Le titre que j'avais initialement choisi était "Quelques lacunes persistantes", mais finalement il m'avait semblé plus constructif de le formuler comme une série d'objectifs à se donner.

Je trouve les réponses de Claude un peu optimistes. Certes, sur ces cinq points il existe des signes prometteurs. Mais ce qui m'intéresse c'est la "vélocité" observée dans la communauté pour y apporter des réponses complètes. Le boulet de la certification, voilà déjà plusieurs années que nous le traînons, et les choses n'évoluent pas dans un sens positif: nous avions jusqu'à présent une seule organisation proposant de la certification (la Scrum Alliance), il y en a maintenant deux depuis le départ de Ken Schwaber.

De même les progrès faits en matière de preuve empirique sont très, très insuffisants. Claude fournit un pointeur vers une présentation de Mike Cohn, sur les bénéfices mesurés des approches Agiles.

La première chose à observer c'est que s'intéresser uniquement aux bénéfices est en soi une approche biaisée! Faire de la recherche, c'est répondre à une question - "qu'est-ce qui change quand on introduit telle pratique, et pourquoi" - sans avoir écrit d'avance la réponse.

La présentation de Mike Cohn s'appuie sur plusieurs sources, dont plusieurs ont une validité d'emblée contestable: par exemple les questionnaires que fait circuler Scott Ambler, ou ceux de Version One (un éditeur d'outils de gestion de projet). J'ai eu l'occasion de discuter brièvement de ce sujet avec Scott à l'occasion d'Agile 2010, et il est le premier à le reconnaître: un questionnaire diffusé par Internet est totalement inadéquat pour mesurer l'effet réel des pratiques sur le terrain. Au mieux peut-on le considérer comme un sondage d'opinion, évaluant la popularité relative des pratiques Agiles parmi une population auto-sélectionnée de personnes s'intéressant déjà à ce sujet.

L'étude empirique la plus solide citée par Mike Cohn est celle de Michael Mah, "How Agile Projects Measure Up", basée sur une importante collecte de données terrain. La présentation de Mike Cohn reprend plusieurs graphes, apparemment issus de cette étude. Quand on y regarde de plus près, on s'aperçoit que la base de données évoquée par Michael Mah contient un total de 7500 projets. Impressionnant, certes... Mais sur ce nombre, seuls 23 sont des projets agiles! Et encore, on ne nous dit pas sur quels critères ces 23 ont été retenus parmi 7500 pour faire partie de ce lot, ni (ce qui est plus important) quel critère d'exclusion a permis d'écarter tous les autres. L'un de ces projets prétendument "Agile" mobilisait 1000 développeurs, ce qui laisse perplexe. Il me semble difficile de revendiquer une pertinence statistique pour un tel échantillon.

La présentation de Mike Cohn présente d'autres aspects troublants vis-à-vis de cette étude. Ainsi, page 5 apparaît un graphe opposant en abcisse la taille des projets, en ordonnée leur productivité. Ce graphe est tout simplement introuvable dans le rapport publié par Michael Mah: à tout le moins, le mécanisme de la citation, par lequel le discours scientifique permet de remonter aux sources et aux données originales, n'est pas utilisé correctement dans ce cas de figure.

Si nous citons des études scientifiques à l'appui de notre discours sur les méthodes agiles, il est important de ne pas nous laisser abuser par notre propre conviction. Nous devons être tout aussi critiques vis-à-vis des études qui font apparaître des résultats favorables que nous le sommes vis-à-vis de celles affichant des résultats négatifs, et nous devons nous intéresser également à chacune de ces deux catégories. Faute de quoi, nous ne sommes pas dans une approche empirique, mais tout simplement dans de la propagande.

Le contrat, la piscine et le reste

Vacances scolaires obligent, un billet un peu plus relax, même si le sujet est sérieux...

Je parlais précédemment de la question incontournable du "contrat agile". Claude, dans un billet qui appelle par ailleurs d'autres réponses, me rappelle qu'il existe déjà quelques propositions et pistes. Tout à fait d'accord. Reste que pour avoir une réponse crédible à apporter, il faut à mon sens plus d'audace, plus d'expérimentation, avant de pouvoir commencer à converger vers un modèle que nous serions prêts à recommander plus largement.

Dans cet esprit je vous recommande de jeter un oeil sur La Piscine, la dernière idée ébouriffante de mes amis de ut7 (le nouveau nom de la branche Parisienne de Pyxis). Une sorte de développement à la carte croisé avec de la formation; l'équipe d'ut7 vous accueille pour binômer avec eux sur votre produit, et vous repartez avec des user stories implémentées.

Ce que j'apprécie dans cette initiative c'est le côté "cash", au sens propre du terme: le prix de la prestation est affiché (3000€ H.T. la user story), il n'y a pas de chichis ou de secret. C'est très rafraîchissant comparé à la culture des SSII où votre projet fait généralement l'objet d'une interminable phase d'approche et de négotiations. A la question "combien ça va me coûter" on vous répond par une autre question, du genre "dites-nous ce que vous voulez précisément" dont on sent parfois qu'elle cacherait bien un "ça dépend combien vous êtes prêt à dépenser".

Pour autant ce n'est pas de la régie: ce n'est pas indiqué clairement sur la page (et je n'ai pas pensé à poser la question directement à Manu), mais mon attente pour un tel contrat serait que si je ne suis pas satisfait de la user story développée pour mon produit, je garde mes sous.

Cela répond à l'idée que je me fais d'une innovation de rupture: ce n'est certainement pas pour tout le monde, ce n'est pas un produit qui fait une concurrence frontale à l'offre des SSII. Par contre il pourrait très bien plaire à des marchés de niche, par exemple les startups. En tant que créateur de startup, je trouverais très intéressant d'avoir accès à des développeurs prêts à travailler à la carte, pour un prix clairement affiché: cela évite d'engager des budgets importants (à l'échelle d'une startup) avec des perspectives de retour sur investissement souvent floues.

A voir maintenant quels seront les premiers retours de clients intéressés par cette proposition... A suivre!

Cinq défis pour la communauté Agile

Le billet précédent positionnait Agile comme le concurrent, initialement peu crédible, du "produit dominant" qu'est le Génie Logiciel. Mais nous l'avons vu, le challenger augmente progressivement ses parts de marché en diversifiant sa cible, et ce faisant il rattrape peu à peu son retard y compris sur les critères qui assurent au produit dominant sa position de force.

Pour autant, en matière d'innovation la victoire n'est jamais acquise d'avance. Bien des avancées prometteuses ont échoué, pour des raisons qui n'ont pas forcément à voir avec la qualité des technologies sous-jacentes, mais faute d'avoir habilement négocié cette montée en puissance.

Premier défi: enterrer la certification

Ainsi l'obession persistante de la communauté pour le sujet de la certification continue-t-elle de mener bataille sur un terrain, le contrôle des qualifications, où elle représente précisément ce qu'il ne faut pas faire, une concurrence frontale au modèle dominant. Le mouvement Agile doit trouver des solutions à cette question lancinante, mais des solutions qui soient compatibles avec sa propre philosophie.

Deuxième défi: proposer un modèle contractuel propre

De même, il faut répondre enfin à une autre question lancinante, celle du modèle contractuel. Nous continuons à dire que le contrat forfaitaire est un frein à l'adoption des pratiques Agiles en France, mais quelle solution proposons-nous?

Troisième défi: le choc des photos plutôt que le poids des mots

La prolifération de jargon rend difficile la conversation au-delà du cercle des initiés; la communication sur les pratiques Agile est brouillonne et trop centrée sur les étiquettes: Scrum vs Kanban vs Lean vs XP. J'applaudis ceux qui présentent la réalité du terrain, les éléments concrets et visibles qui au sein d'une équipe permettent d'identifier les pratiques Agiles et les bénéfices qu'elles apportent.

Quatrième défi: des chiffres!

A ce sujet, il est regrettable que l'une des critiques les plus courantes du mouvement Agile soit désormais la suivante: "Depuis 10 ans, il n'y a toujours pas de chiffres probants". La communauté Agile a désormais suffisamment d'ampleur pour être en principe capable de fournir ces chiffres.

Certes, il y a dix ans, la demande "montrez-nous vos statistiques" pouvait à raison être rejetée comme un discours de délégitimation, une façon de remettre à leur place ces "hippies du logiciel". Mais nous ne sommes plus en 2001, nous sommes en 2010; les éléments empiriques sont nécessaires, non seulement pour étayer ce que nous avançons, mais aussi pour faire le tri entre celles des pratiques qu'il faut conserver et celles qu'il faut modifier ou éliminer de notre discours. Non seulement nécessaires, mais disponibles, pour peu que nous nous donnions la peine d'aller les chercher.

Cinquième défi: le gouffre recherche-industrie

Dans cette logique, il est critique que la communauté Agile se rapproche de la communauté de la recherche et de l'enseignement. Pour l'instant, rares sont les chercheurs qui s'intéressent à l'Agilité, tout simplement parce que les travaux dans ce domaine ne trouveraient pas à être publiés. Ceci pourrait être réparé en entamant une démarche explicite pour faire de ce sujet une discipline soeur, voire concurrente, du Génie Logiciel. Après tout, cette dernière a pu persister pendant 40 ans sans solutionner les difficultés qui ont motivé sa création... il est temps qu'elle subisse la concurrence.

Cette liste n'est sans doute pas exhaustive mais suffirait probablement à tracer une feuille de route pour les approches Agiles au cours des 10 ans à venir.

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.

Théorie de la rupture

La théorie de la rupture est due à Clayton Christensen qui la présente en 1997 dans The Innovator's Dilemma. Le sous-titre, éloquent, avertit du risque que présentent certaines innovations ou "ruptures technologiques": "lorsque de nouvelles technologies entraînent la chute de grandes entreprises".

Christensen distingue deux types d'innovation, l'innovation de continuité et l'innovation de rupture. La première est caractérisée par des produits qui renforcent, dans le contexte concurrentiel, la position dominante des acteurs déjà bien placés sur ce marché: ces produits sont jugés sur des critères de performance déjà reconnus. Imaginez par exemple la dernière génération des appareils photos numériques, qui passent de 8 à 12 megapixels. (Une innovation "révolutionnaire" n'est pas nécessairement une rupture en ce sens, ainsi l'article Wikipedia consacré à la théorie précise que l'automobile fut une révolution mais pas, dans ses effets sur les acteurs de l'économie industrielle, une véritable rupture.)

L'innovation de rupture se caractérise par l'ouverture de nouveaux marchés, et la mise en danger des acteurs dominants dans un marché donné; elle propose quelque chose d'inattendu en décalage avec les critères de valorisation dominants.

L'histoire de la photo numérique à ses débuts est à ce titre éclairante, sa victime emblématique étant Polaroid, l'un de ces noms de marque passés dans l'usage courant, tant son emprise sur un important segment du marché était complète. Pourtant, en 2001 Polaroid se mettait en faillite, pour ne renaître de ses cendres qu'à la suite du rachat de la marque et presque uniquement de cela par des investisseurs cherchant à profiter d'une image encore favorable.

Pourtant, seulement dix ans plus tôt, bien malin qui aurait pu prédire à la photographie le bel avenir qui est devenu notre présent: disparition inéluctable non seulement des modèles argentiques mais également de tout un secteur d'économie qui en dépendait, comme les petites boutiques qui assuraient le développement de nos "péloches".

Ainsi en 1991 le modèle Fotoman, est selon une critique pourtant lucide "incapable de produire des images de qualité professionnelle". En noir et blanc et d'une résolution maximum de 320x240, il coûte la bagatelle de 1000$. Ce n'est en fait qu'un gadget, conseillé aux personnes qui souhaitent s'amuser sur leur PC à triturer et retoucher leurs photos.

Comment un tel produit arrive-t-il, petit à petit, à s'imposer jusqu'à vingt ans plus tard avoir totalement détrôné la génération précédente? Pour avoir un début de réponse, il faut comprendre que les acteurs dominants du marché le sont en vertu de l'excellence de leurs produits selon des critères de performance appréciés par la clientèle: en l'occurrence, la finesse de l'image, le bon rendu des couleurs, etc. De ce point de vue la photo numérique présente des avantages (facilité de stockage, moins d'usure mécanique, manipulation numérique) mais ceux-ci ne sont pas suffisant pour l'emporter face aux concurrents dominants.

Oui, mais certains marchés n'ont que faire de ces critères de performance majeurs. Parmi les premiers clients auxquels s'adresse le numérique on trouve des fabricants d'avions, qui doivent prendre leurs appareils sous toutes les coutures pendant leur construction pour des raisons règlementaires, et vont donc faire des économies considérables sur le développement chimique, mais ne se soucient guère d'une résolution très fine. Ou bien encore des journalistes qui vont privilégier la transmission rapide d'une information brûlante mais ne sont que peu handicapés, compte tenu des qualités d'impression, par une résolution limitée ou par le noir et blanc.

L'innovation de rupture est donc portée par des produits initialement totalement inadéquats quand on les juge à l'aune des critères de performance établis, mais qui vont conquérir un marché de niche puis se développer. L'innovation plus classique, "de continuité", permet progressivement à ces produits de rattraper tout ou partie de leur retard sur ces critères dominants, et c'est ainsi qu'ils peuvent finir par mettre en danger les leaders du marché.

Alors, en quoi le débat entre "Génie Logiciel" et "Agile" peut-il être considéré comme une instantiation de ce modèle? Certes, il faut faire preuve d'un peu de prudence: considérer l'un et l'autre comme des "produits" en concurrence sur un "marché" relève, sinon de la métaphore, d'une moins d'une interprétation assez libre de ces termes. Je trouve pourtant que le modèle s'applique plutôt bien, et permet d'expliquer non seulement le succès initial de l'approche Agile mais également ses évolutions au cours des dernières années. (Evolutions qui sont souvent mal connues des personnes qui pratiquent ces approches et même de certains experts: toujours ce blocage sur l'histoire...)

L'idée est donc d'analyser le Génie Logiciel comme le produit dominant, et d'expliquer cette domination par le fait qu'il répond aux critères exigés par le marché. L'histoire du projet Chorus nous suggère que "le succès du projet" ne fait pas nécessairement partie de ces critères... alors quels sont-ils? Selon quel critère de performance le discours classique du Génie Logiciel, issu des conférences de 1968 et 1969, est-il, malgré ces échecs, jugé satisfaisant, à tel point qu'on enseigne encore le cycle en V dans les universités?

Je laisse la question en suspens jusqu'au prochain billet... A vous de réagir dans les commentaires.

Chorus, une histoire pas drôle

Lors de mes interventions (par exemple dernièrement pour Agile Tour Nancy) sur le sujet que j'ai abordé au fil des précédents billets, il y a toujours un moment ou je sais que j'arriverai à tirer un rire de toute la salle: je viens de rappeler la date de naissance du Génie Logiciel et le contexte de sa création, celui de la "crise du logiciel".

Il n'y a plus qu'à lancer un constat: "Heureusement, nous avons tous remarqué que la Crise du Logiciel est maintenant résolue." Effet garanti.

Quels étaient effet les symptômes de ladite Crise en 1968? Dépassement de délais, mauvaise qualité, inadaptation des logiciels aux besoins des utilisateurs...

Que peut-on observer en 2010? Qu'il existe encore des projets comme Chorus. Si vous n'en avez jamais entendu parler, je vous conseille de vous documenter: c'est de votre argent qu'il s'agit, puisque Chorus est le nouveau système d'information destiné à toutes les administrations françaises. Le projet prévu sur quatre ans démarre en Mars 2006, son coût annoncé aux parlementaires à l'origine est déjà important: 600M€.

Dès le début 2008 apparaissent les premières dérives et l'on apprend que des retards sont à envisager, que le budget serait dépassé. Fin 2008, une "mise au point" du ministère permet d'apprendre qu'en fait le budget communiqué ne tenait pas compte des coûts de fonctionnement, chiffrés à 100M€ annuels sur cinq ans: la facture serait donc de 1,1Md€. Un petit oubli, en somme. (Un rapport parlementaire de juillet 2010, un peu inquiétant, recommande "d'actualiser l'évaluation du coût complet de Chorus" - ce qui laisse supposer que ce coût réel est encore inconnu à l'heure actuelle...) Les délais s'accumulent, et dès 2009 Chorus qui devait être déployé entièrement à partir de 2010 se voit repoussé à janvier 2011, et ce malgré une révision à la baisse de ses objectifs fonctionnels.

Il y a pire: Chorus... ne fonctionne pas. Plus exactement son installation perturbe le paiement des factures aux fournisseurs des administrations. Alors que l'Etat gronde le secteur privé sur les délais de paiement, son propre système d'information met en difficulté de très nombreuses PME qui se retrouvent dans l'incapacité d'encaisser leur dû: un comble! Est-ce une difficulté transitoire? C'est en tout cas un transitoire qui dure... et la Cour des Comptes émet des réserves sur l'éventualité que Chorus puisse un jour assumer pleinement la comptabilité de l'Etat français.

Alors, oui, cela fait rire, de constater que quarante ans après, les méthodes proposées par le Génie Logiciel, loin d'avoir résolu la crise, semblent contribuer à la perpétuer: c'est évidemment un rire jaune.

Pourtant force est de constater que le Génie Logiciel se porte bien. On enseigne toujours le cycle en V dans les universités: voici un exemple, notez cependant qu'à l'heure où j'écris ces lignes il vous sera nécessaire de défiler plusieurs pages d'avertissements PHP avant de lire le descriptif de cette unité d'enseignement. (Tout un symbole...)

Comment comprendre cette situation dominante occupée par le Génie Logiciel? Et quelle grille de lecture nous permettrait de mieux appréhender le positionnement des approches Agiles dans ce débat? J'ai trouvé un certain nombre d'explications dans les thèses de Christensen, auteur de la Théorie de la Rupture. Ce sera le sujet du 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...

Synthèse: référentiel des pratiques

Voici, pour ceux qui le découvriraient tardivement et souhaitent le lire dans l'ordre, un récapitulatif du chapitre "référentiel" tel que je l'ai abordé au fil des billets précédents. (L'inconvénient majeur d'un blog, c'est que quand on arrive après le début du film, les épisodes précédents sont présentés à l'envers: ça marche bien pour Memento mais moins bien pour un sujet plus technique.) Je profiterai également de ce billet pour dire un mot sur un sujet connexe: à qui appartient ce référentiel et comment il va évoluer.

Voici l'adresse de publication du Référentiel, et en voici les motivations:

1. Pourquoi il est préférable de se focaliser sur les pratiques agiles et non sur l'étiquette "Agile"
2. Principes, concepts, pratiques et compétences: les composants du corpus Agile
3. Précautions d'utilisation d'un référentiel des pratiques Agiles: attention au Culte du Cargo
4. Comment adapter les pratiques Agiles à son propre contexte: une activité efficace
5. Les "rôles" Agiles et pourquoi s'en méfier
6. Les canevas pour décrire une pratique et une compétence

Il est tout à fait possible que ce chapitre sur le Référentiel s'étoffe par la suite, et si c'est le cas je viendrai y ajouter (dans l'ordre approprié) les billets complémentaires.

Les billets futurs vont se concentrer sur d'autres chapitres de l'action de l'Institut.

A qui appartiennent les pratiques Agiles?

Une des raisons qui me font me méfier des initiatives de certification: je me préoccupe des mécanismes par lesquels, si je juge incorrecte la conception que se font les certifieurs de l'Agilité, je pourrai leur soumettre une demande de correction. C'est un point important: si j'enseigne quelque chose en rapport avec l'agilité, mais que mon contenu est incompatible avec ce que disent les certifieurs, j'aurai le choix cornélien entre enseigner quelque chose auquel je ne crois pas ou renoncer à l'atout que peut représenter la certification.

Pour l'Institut, la question ne se pose pas, puisqu'il y a un parti pris contre toute initiative de ce type. Mais le Référentiel tel qu'il se présente a, sans détour, une intention normative. Il prétend rendre compte de la pratique la plus courante, même si cela admet des exceptions.

A mon sens, les pratiques Agiles appartiennent à la communauté Agile dans son entier, et je pose cette interprétation comme un principe qui fait partie de la définition même de l'Agilité. C'est un mouvement qui a ceci de particulier qu'il est "bottom up", par construction et par philosophie.

Le Référentiel lui-même est une "oeuvre de l'esprit", protégé par le droit d'auteur. Je souhaite, pour des raisons éditoriales, contrôler un tant soit peu sa diffusion et sa modification pendant la période de rédaction, avant d'en faire un contenu "open source" une fois qu'il sera complet. Par conséquent, le Référentiel sera:

• dans un premier temps, diffusé sous une licence Creative Commons "by-nc-nd", avec l'exception suivante: toute personne qui le souhaite est autorisée à "forker" le Référentiel et à le modifier, sous réserve que ce soit dans la seule intention de soumettre ces modifications à l'auteur
• dans un second temps, et pas plus tard que le 31 décembre 2012, le Référentiel sera utilisable sous la licence "by-nc-sa", toute personne souhaitant alors y apporter ses modifications pourra le faire sans restriction

L'exploitation commerciale du Référentiel - par exemple, sa publication sur papier - sera réservée au seul Institut Agile: je ne souhaite priver ce dernier d'aucune source de revenus, l'Institut étant contractuellement dans l'incapacité de vendre des services ou prestations en concurrence avec les sociétés de service.


L'évolution future du Référentiel


La version actuelle du Référentiel est techniquement minimaliste, mais je compte dans l'immédiat me concentrer sur son contenu (tout en alimentant ce blog en parallèle...). Je publierai simultanément sur Github et sur le site les nouvelles pratiques au fur et à mesure de leur rédaction.


Tout au long de cette phase de rédaction j'acueillerai avec plaisir les suggestions d'amélioration, y compris sous la forme de "patchs" proposés via Github. L'objectif est d'être en mesure d'accueillir le plus largement possible les connaissances pertinentes sur les pratiques Agiles: liens vers des articles de référence, vers des travaux de recherche, vers des descriptifs de formations universitaires.


(Je suis dés à présent ouvert à l'inclusion de liens vers des formations commerciales, sous réserve que cela puisse se faire sans entrer en conflit avec la politique de l'Institut vis-à-vis de ses partenaires et vis-à-vis du marché: une neutralité bienveillante.)

Canevas de description d'une compétence

Que dire de plus pour éclairer précisément une compétence, par rapport à ce qu'on peut dire concernant une pratique? Notre exemple sera le Refactoring, compétence centrale dans Extreme Programming.

Tout d'abord, une compétence est aussi une pratique: elle se constate à certains signes visibles, elle apporte un bénéfice présumé, qui peut être démontré par des études empiriques. Le canevas de description d'une compétence est donc en règle générale un sur-ensemble de celui qui vaut pour les pratiques.

La principale différence est qu'une compétence nous amènes à distinguer des niveaux de performance. Cela n'a pas tellement de sens de dire qu'une personne ou même une équipe est "douée" pour établir sa "definition of Done". Soit elle a une définition, et la trouve satisfaisante; soit elle n'en a pas. Il n'y a pas grand chose à dire à une équipe qui lui permettra d'améliorer sa pratique de la définition. (Certes, une équipe peut avoir une mauvaise définition de "fini", si elle est incomplète ou au contraire trop rigoureuse. Pour autant on ne parlera pas d'améliorer une compétence, mais simplement d'améliorer... le document!)

Au contraire, une personne peut maîtriser plus ou moins bien les différentes techniques du refactoring, et s'améliorer dans ce domaine, soit par la recherche et la pratique personnelle, soit par des mécanismes d'apprentissage en travaillant auprès d'un mentor qui lui enseignera des éléments plus avancés que ceux déjà connus, soit en suivant une formation qui fixera des objectifs pédagogiques adaptés. Recenser ces formations est, en matière de compétences, l'un des objectifs importants du référentiel.

N'étant pas lui-même un support pédagogique, le référentiel n'a pas vocation à recenser l'intégralité des savoirs-faires qui composent une compétence donnée, mais simplement de fournir des pointeurs vers les ressources documentaires, lorsqu'elles existent, qui font autorité. Par exemple, le livre de Martin Fowler qui définit plusieurs dizaines de refactorings élémentaires. La connaissance encyclopédique de tous ces refactorings n'est certes pas une exigence pour pouvoir prétendre maîtriser le sujet, mais d'évidence l'une des choses qui distinguera un expert d'un débutant sera le nombre de ces refactorings qu'il est capable d'utiliser à bon escient.

Canevas de description d'une pratique

Voici les éléments qui me semblent pertinent pour décrire une pratique agile. Nous allons prendre pour exemple une pratique Scrum relativement récente, la Définition de 'fini'.

Parlons d'abord, même si ce n'est pas la première chose qu'on lira, du descriptif succint d'une pratique. (La première chose qu'on lira, c'est le nom, j'y reviens plus bas.) Le référentiel n'a pas vocation à se substituer aux livres, articles et contenus de formation qui donne une définition plus précise et plus détaillée de chaque pratique, compétence et outil abordés. Il s'agit donc ici de se borner à un paragraphe court qui reprend l'essentiel.

Un autre exercice délicat consiste à choisir un nom canonique pour cette pratique. La plupart de mes collègues francophones utilisent un demi-anglicisme, et parlent de "Definition du Done", quand ce n'est pas le terme anglais qu'ils utilisent directement. Quand c'est possible, il me semble souhaitable de vraiment traduire, c'est pourquoi j'ai préféré "fini" à "done".

Le but n'est pas de faire évoluer le lexique, même s'il est tentant de chercher jouer de son influence... Ma préférence irait au terme "Liste Sashimi", le terme "sashimi" bénéficie actuellement d'un petit effet de mode, et comme l'illustre le site Web de cette formation de mon ami et collègue J.B. Rainsberger il est parlant et plaisant. Mais cette appellation pour désigner une pratique spécifique reste tout à fait marginale.

En tout cas, pour toutes ces raisons, il me semble important de recenser les synonymes connus qui désignent la même pratique ou des pratiques tellement voisines que nous les considérerons comme une seule (par exemple le Sprint de Scrum ne diffère pas assez de l'Itération d'XP pour y voir deux pratiques distinctes).

Une pratique s'accompagne généralement d'un certain nombre d'erreurs classiques, de contre-sens et d'abus. En rencensant les plus courantes, on donne de la profondeur à la description brève (mais toujours sans chercher à se substituer à un contenu plus pédagogique), et on encourage à se méfier des imitations et contrefaçons.

Conformément à la division "principes, concepts, pratiques, compétences" j'ai choisi de faire ressortir de cette pratique le côté visible: je sais qu'une équipe utilise une pratique quand je peux le constater par des signes observables dans l'espace de travail, par exemple une feuille de paperboard sur laquelle on peut lire la (ou les) définition(s) de "fini".

(C'est un arbitrage de ma part, certaines personnes diront qu'il suffit qu'une équipe connaisse sa définition de "fini" et que tout le monde soit d'accord. Pourquoi pas: dans ce cas, le signe observable consiste à s'asseoir avec plusieurs personnes dans l'équipe et leur demander de réciter cette définition. Je suis presque certain que dans ces conditions chacun donnera une définition de "fini" légérement différente; je vous renvoie donc à la rubrique "erreurs classiques".)

Comme indiqué précédemment, une pratique ne vaut que par les bénéfices qu'elle confère au projet. Décider, en conscience, d'adopter une pratique, c'est s'engager à vérifier quelques temps après si ces bénéfices ont bien été obtenus, et remettre en question sa vision du fonctionnement du projet si ce n'est pas le cas. L'objectif n'est pas d'utiliser telle et telle pratique pour le plaisir de s'identifier comme "Agile" mais bel et bien d'obtenir ces bénéfices. Notamment, chaque pratique se caractérisera aussi par un coût d'utilisation plus ou moins grand et une efficacité plus ou moins nette: notre objectif, idéalement, est d'obtenir avec le minimum de pratiques, exigeant le minimum d'effort pour les adopter, le plus grand nombre de bénéfices possibles sur les aspects du projet qui nous intéressent. Peu importe d'où viennent ces pratiques - de Scrum, d'XP, de Lean...

Il est cependant important, pour plusieurs raisons que j'approfondira dans des billets à venir, de positionner les pratiques dans un contexte historique, de retracer leurs origines et leur évolution. La "définition de 'fini'" ne fait partie de Scrum que depuis quelques années, et son intégration définitive dans les pratiques considérées comme indispensables ne remonte qu'à 2006-2007 environ d'après mes recherches. (Perfectibles, sans doute: c'est pourquoi je citerai mes sources.) Ou bien il est possible de pratiquer Scrum sans utiliser une définition explicite de "fini" - auquel cas on doit se demander s'il est nécessaire dans un contexte particulier d'utiliser cette pratique - ou bien cet évolution s'explique par le fait que seules les équipes qui l'utilisaient réussissaient dans leur application de Scrum, et qu'on a finalement mis le discours en conformité avec la pratique. La différence entre ces deux scénarios n'est pas anodine.

Un dernier élément, mais qui a son importance, consiste à relever les travaux scientifiques pertinents. Ceux-ci sont de deux types: théoriques ou conceptuels, qui vont donner un éclairage plus précis et plus rigoureux sur les mécanismes par lesquels une pratique produit ses effets; et, les plus importants, empiriques, qui vont constater dans des conditions contrôlées la réalité et l'importance quantitative de ces prétendus effets.

Cette validation scientifique n'est pas un prérequis à l'utilisation de pratiques qui ont montré leur efficacité. J'aurai l'occasion de revenir sur ce sujet, mais il faut bien constater que le dialogue entre les chercheurs qui s'intéressent à la dynamique des projets agiles d'une part, et les praticiens d'autre part, n'est pas encore d'une grande qualité. On ne s'étonnera pas, par conséquent, que la recherche tarde à s'intéresser à ce que les praticiens trouvent évident depuis longtemps, ou que ces derniers ignorent des résultats que les chercheurs considèrent comme acquis. Mais la convergence au fil du temps entre
ces deux communautés me semble indispensable.

Si les pratiques sont réellement utiles et produisent leurs effets de façon fiable, alors on doit être en mesure de le prouver; sinon c'est qu'elles ne sont qu'un placebo, et leur utilisation est nuisible puisqu'elles mobilisent une partie de l'énergie des intervenants d'un projet, qu'ils pourraient consacrer à d'autres pratiques qui elles sont réellement utiles.