Lancement de l'étude Projets - Pratiques - Objectifs

Version courte: l'Institut Agile lance aujourd'hui son étude "Projets - Pratiques - Objectifs" (PPO), et si vous utilisez des pratiques Agiles sur vos projets, vous pouvez nous aider. Il suffit pour cela de remplir ce questionnaire préliminaire en ligne, très court, de le faire très largement circuler autour de vous, et d'indiquer si vous êtes volontaire pour participer à l'étude complète.

• Le questionnaire exploratoire sur SurveyGizmo
• Le descriptif de l'étude (en anglais) sur Github
• L'article "When Agile Met Data" 

Cette étude est soutenue par un programme de l'Alliance Agile ainsi que par les partenaires de l'Institut: Microsoft, Neoxia, Exakis, People In Action, Axones, UT7, Agile To You, Yaal, Agilidée.

Version longue:

Depuis plus de dix ans que l'on parle d'Extreme Programming, de Scrum et plus généralement de pratiques Agiles, se fait entendre une question récurrente tant de la part des adeptes que des simples curieux ou des critiques: "où sont les chiffres prouvant que ça fonctionne ?"

Pour illustrer ce que fut pendant longtemps la réponse de la communauté à cette question, voici ce qu'on peut lire entre autres dans la première version, publiée fin 2002, d'un essai de Scott Ambler:

•  les approches Agiles sont toutes nouvelles, il n'y a donc pas eu le temps de collecter des chiffres
• l'exigence en matière de "preuve" est excessive, et sert en fait d'excuse à ne pas s'intéresser au sujet
• l'approche Agile s'intéresse précisément à d'autres aspects que ceux mesurés jusqu'à présent, par exemple la réponse au changement plutôt que le respect du plan initial

Ambler explique par ailleurs que sur certains aspects précis, comme la programmation en binômes ou le développement par les tests, on commence dès cette époque à voir paraître des résultats empiriques. Mais son argument principal reste qu'il n'est pas légitime de demander aux évangélistes de l'approche Agile des preuves quantitatives.

Dix ans après...

J'ai souvent l'occasion de le répéter ces jours ci, la situation a beaucoup changé au cours des dix dernières années. Suffisamment changé pour que les objections ci-dessus n'aient plus cours, à mon sens:

• dans les années 2000-2006, la communauté Agile militait pour obtenir des entreprises où nous travaillions la permission d'utiliser ces approches; aujourd'hui non seulement cette permission est accordée, l'initiative de leur mise en place vient de plus en plus des entreprises elles-mêmes, les projets se réclamant d'une approche "Agile" se multiplient, et par conséquent depuis au moins quelques années la matière existe à établir des résultats quantitatifs;
• il n'est pas exact que ce sont les "réfractaires" qui exigent ces preuves; on s'aperçoit à l'usage que dans les entreprises qui souhaitent sincèrement en généraliser l'utilisation, certaines fonctions, par exemple les acheteurs, utiliseraient ces chiffres s'ils étaient disponibles pour orienter leurs choix;
• la question "quoi mesurer" n'est sans doute pas la plus importante, en tout cas tant que la communauté Agile continue... à ne pas mesurer grand-chose.

La version la plus récente de l'article d'Ambler cite désormais des résultats chiffrés, en dépit de cette posture qu'on aurait pu interpréter comme défensive; en fait, Ambler a initié depuis quelques années un grand nombre d'enquêtes visant à répondre à ces demandes d'éléments quantitatifs.

Là où le bât blesse, c'est qu'il s'agit de questionnaires diffusés via le Web. De tels questionnaires peuvent donner un aperçu fort utile de la popularité de divers éléments du discours agile, mais ils ne sont pas adéquats pour tirer des conclusions généralisables quant à la pratique, sur le terrain, de ces approches et quant aux résultats obtenus.

Il existe par ailleurs un certain nombres d'études académiques sur le mode de l'étude de cas ou de l'expérimentation contrôlée. Il s'agit, respectivement, soit de suivre de près un projet pour mieux mettre en évidence les mécanismes par lesquels une approche Agile apporte (ou non) les bénéfices prétendus; soit de réaliser un protocole expérimental qui permettra d'isoler un facteur particulier en confrontant deux situations entre lesquelles ce facteur est la seule différence. Dans les deux cas, il s'agit de travaux de longue haleine et nécessitant d'importants investissements, en termes de temps et d'argent.

Les données manquantes

Ce qui n'a pas (ou très peu) été réalisé jusque là, c'est une collecte directe des données de terrain qui se généralisent: celles produites par les projets de plus en plus nombreux qui, dans un nombre également croissant d'entreprises d'horizons très divers, mettent en place des pratiques Agiles pour des raisons purement pragmatiques - ce qui veut dire, dans bien des cas, sans se soucier beaucoup de la "pureté" de leur approche, mais en adoptant au cas par cas les pratiques qui leur semblent judicieuses.

Les conférences, telles Agile France (anciennement XP Day France, issue du cycle européen XP Day), donnent à la communauté une excellente occasion de livrer des informations empiriques, sous la forme de retours d'expérience (REx pour les accros des acronymes). Ils ont été et continuent à être une bonne source d'informations qualitatives.

Ils ont cependant un talon d'Achille, la fiabilité des informations produites. En effet, lors de la présentation d'un retour d'expérience il est facile d'attribuer ses succès à des pratiques qui n'y ont pas beaucoup contribué; de passer sous silence certaines erreurs ou épisodes embarrassants, et ce d'autant plus qu'on citera le nom de l'entreprise où l'on travaillait. Par ailleurs un retour d'expérience suppose que le projet soit allé au bout, on va donc éliminer d'emblée les projets qui ont échoué très rapidement; de la même manière on occultera souvent ce qui se passait en début de projet au bénéfice des événements les plus récents.

L'étude PPO

L'objectif de l'étude PPO est de traiter des projets de façon longitudinale, afin d'obtenir des résultats quantitatifs susceptibles d'un traitement statistique. Elle vise à identifier et décrire des projets le plus tôt possible afin d'éviter les biais de sélection, par exemple celui qui ne consisterait à décrire que les projets ayant réussi ou qui se sont terminés à peu près dans les conditions initialement prévues.

Les questions auxquelles l'étude vise à répondre sont les suivantes:

• quelles pratiques sont choisies pour obtenir quels objectifs (délais, qualité, productivité...)?
• quelles pratiques s'avèrent faciles ou difficiles à adopter?
• quelles pratiques effectivement adoptées contribuent réellement aux objectifs fixés?

Afin d'obtenir des réponses fiables, l'étude s'appuiera sur le Référentiel des pratiques, et s'appuiera pour la collecte des données sur des entretiens (idéalement en personne, au besoin par téléphone) avec les intervenants et décideurs des projets concernés, par exemple pour évaluer le degré d'utilisation réelle des pratiques Agiles déclarées.

L'Institut Agile bénéficie d'une position privilégiée pour répondre à ces questions: c'est une entité neutre et indépendante qui peut donner aux entreprises participantes des garanties de confidentialité des données qui lui seront confiées. L'Institut s'emploie à plein temps à ce rôle d'observateur de la mise en place sur le terrain des pratiques Agiles, ce travail ne souffrira donc pas d'interférences comme cela peut être le cas pour une entreprise ayant par ailleurs des activités commerciales qui entâcheraient son objectivité, ou des consultants freelances qui pourraient être accaparés par leur activité.

Si vous êtes intéressés pour participer à cette étude et aider à mieux mettre en lumière les effets réels des pratiques Agiles, n'hésitez pas à vous manifester en remplissant le questionnaire!

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.