Accueil > Méthodes Agiles > Science, agilité et religion

Science, agilité et religion

Quel rapport entre ces trois notions ?

Prenons un exemple pour illustrer.

La majorité des sages-femmes vous confirmeront que les naissances sont bien plus nombreuses à la pleine lune. Ces professionnelles du domaine sont bien placées pour le savoir, et il n’est pas question de remettre en doute leur expertise ni leur expérience. Et pourtant cette affirmation est fausse ! Au delà du fait que la lune n’influence ni les plantes ni les humains, les études statistiques ne montrent absolument aucune corrélation. Un savoir propagé par des experts n’est donc pas nécessairement à prendre pour argent comptant.

L’argument d’autorité n’est pas accepté dans une démarche scientifique, et toute affirmation doit être étayée par des éléments vérifiables et objectifs. Il en est de même pour l’agilité : la parole des experts, même assenée avec force et conviction, ne doit pas faire office de loi, à l’instar de celle de grands gourous

L’agilité pragmatique

Au-delà d’un phénomène de mode, l’agilité regroupe un ensemble de principes et de pratiques apportant un bénéfice avéré aux projets de développement informatique. Une bonne partie des éléments fondateurs de l’agilité ont fait l’objet de publications dès le début des années 1990, et les grands principes ont été consolidés dans le maintenant bien connu manifeste agile.

Comme pour tout phénomène de mode, l’information circule beaucoup sur les media de communication modernes. De nombreux experts, plus ou moins autoproclamés, s’expriment régulièrement sur le sujet, souvent avec humour et de manière pertinente, mais aussi parfois de manière discutable (cette affirmation s’applique aussi à moi-même !).

Nous sommes parvenus au point où il n’est plus nécessaire de justifier l’agilité : la majorité des acteurs IT en France sont convaincus des intérêts de la méthode. En conséquence, la parole agile est propagée sous forme de commandements, quasi-religieux, que les adeptes doivent suivre aveuglément et répéter comme une évidence, comme par exemple : « aucune tâche tu assigneras». Il suffit qu’une personne suggère, par exemple, que la tâche de mise en place de la configuration Maven soit affectée au membre de l’équipe qui a la compétence correspondante pour que des extrémistes brandissent leur drapeau rouge et répètent à l’envi la prière agile, disant que c’est mal, très mal, et qu’on file tout droit vers la damnation éternelle dans l’enfer des projets cycle en cascade. Amen.

L’agilité n’est pas un objectif en soi

Ne perdons pas de vue l’essentiel ! L’agilité n’est pas un but, c’est un moyen. Un outil. Un peu comme le ciseau du sculpteur, qui lui permettra de faire émerger une forme esthétique à partir d’un bloc brut de matière première. L’agilité est un moyen d’améliorer l’efficacité de la production de logiciels informatiques. Dans un projet informatique, le but premier c’est de fabriquer le logiciel, et non d’être strictement conforme à la Bible Agile. Dès lors, chaque membre d’un projet, et surtout le Scrum Master, doit toujours se demanderdans quelle mesure telle pratique agile pourra contribuer à l’objectif du projet, compte tenu de son contexte spécifique.

Pour reprendre l’exemple Maven, c’est une intention louable que de souhaiter faire monter en compétences l’ensemble des membres de l’équipe sur un framework ou un langage, cependant ce n’est pas nécessairement parmi les objectifs du projet, et d’autre part, cela doit rester compatible avec le plan de management des compétences qui a peut-être été défini au niveau du service ou de l’entreprise.

Plausible ne signifie pas authentique

Second point, la validité des recommandations sont assises sur des bases non uniques (généralisation abusive), non personnelles (manque d’objectivité) et statistiques.

Une affirmation en apparence plausible n’est pas nécessairement authentique.

Tout le monde sait que les ondes émises par les téléphones mobiles engendrent de la chaleur, et vous vous souvenez peut-être de cette étude controversée prouvant que ces ondes pouvaient tuer des poussins. Deux journaliste russes, de renommée internationale, ont monté un dispositif avec deux téléphones mobiles placés face à face de manière à reproduire la configuration d’un four à micro-ondes, avec un œuf frais placé entre les deux. Après 65 minutes de conversation sur les deux téléphones, placés ainsi en résonnance, l’œuf était cuit dur. Vidéos et photos à l’appui.

Plausible ? En l’occurrence complètement faux ! Il s’agit d’un canular tellement bien présenté que des scientifiques ont même tenté de reproduire l’expérience, sans succès bien entendu. Donc méfiance et discernement sont de rigueur, en tout domaine. Même si la personne qui diffuse le message est de bonne foi, le fait d’être Gourou ne dispense pas de justifier ce qu’il raconte.

Justifier : sous quelle forme ?

L’expérience personnelle n’est malheureusement pas suffisante pour se forger une opinion relativement à telle ou telle affirmation. Nous avons tendance naturelle à isoler les éléments qui tendent à confirmer une croyance en ignorant ou minimisant les éléments allant à l’encontre de cette croyance.

Le philosophe, amoureux de la sagesse, illustre volontiers ses propos par des exemples. L’exemple a-t-il valeur de preuve ? Est-ce parce qu’une fois, sur un projet, la séparation de l’équipe en deux sous-groupes, pour le chiffrage, n’a pas été convaincante qu’il faut conclure que c’est une mauvaise pratique pour tous les projets ?

Le scientifique s’appuie sur la mesure et la reproductibilité. Il analyse une série d’informations obtenues dans des circonstances contrôlées et réalise une étude statistique. Lorsque les circonstances ne peuvent pas être aisément contrôlées, l’analyse statistique d’un échantillon de taille plus importante reste possible, à condition, et c’est valable dans tous les cas, de rester vigilent sur les possibles biais (biais dans la sélection des données, biais dans l’interprétation d’éléments qualitatifs, etc.).

Comment démêler le vrai du faux ?

L’idéal consiste à avoir accès à un compte-rendu précis des démarches qui ont permis de valider (ou infirmer) une hypothèse. Les articles scientifiques, publiés dans des revues à comité de lecture, sont parfois arides à lire, mais ils sont abordables et restent la meilleure garantie de sérieux. Les articles récents seront accessibles dans les bibliothèques universitaires, et les articles un peu plus anciens (quelques années) sont disponibles sur internet. Les sites de preprint sont une source d’information intéressante, à condition de s’assurer que l’article ait bien passé la barre du peer-review.

Malheureusement, quand le sujet d’étude est l’efficacité d’un groupe d’humains au sein d’une organisation, il est difficile et délicat d’appliquer la méthode scientifique. Pour ce qui concerne l’humain, l’approche est souvent empirique.

A défaut de publication scientifique, une affirmation de gourou devra être considérée avec précautions, dans une attitude de doute (respectueux) par opposition à une attitude de croyant. Une mise en œuvre prudente sur les projets est envisageable, tout en conservant à l’esprit la règle d’or : l’objectif est de délivrer un produit conforme aux exigences du product owner, et toute pratique qui nuit à cet objectif doit être impitoyablement écartée ou adaptée, même si c’est un gourou qui l’a dit.

Conclusions

Contrairement à ce que pourrait laisser penser le présent article, je suis convaincu de l’intérêt des méthodes agiles en général, et de son principe fondamental : l’approche itérative. Cette conviction est fondée sur mon expérience, mais aussi sur de nombreuses études.

Un fait est indéniable : une démarche itérative permet de piloter le triangle de fer. A délai et budget fixés, un produit sera délivré, la variable d’ajustement étant le périmètre fonctionnel. L’approche traditionnelle de la méthode en cascade consiste à fixer le périmètre, les variables d’ajustement étant le coût et le délai !

Dans tous les cas, il convient de garder à l’esprit que la méthode sert un objectif, et n’est pas l’objectif. Le pragmatisme prime sur le dogmatisme. Le doute est de rigueur.

Categories: Méthodes Agiles Tags:
  1. Pas encore de commentaire
  1. Pas encore de trackbacks


× six = 12