Prochain Rendez-Vous de l'Institut: le 22 mars à Caen

L'Institut sort de Paris pour son prochain Rendez-Vous:"Vous avez dit Management Agile ?"

Il s'agit d'une journée pleine, proposée par l'Institut Agile, le Chapitre France-Atlantic du PMI et l'Université de Caen, qui se tiendra le 22 mars 2012 à Caen. Vous pouvez télécharger la plaquette ou vous inscrire sur le site du Chapitre.

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!

Devops - premières rencontres et survol

Ce mercredi 1er décembre j'ai eu le plaisir de participer à la première rencontre Devops parisienne; en voici un compte-rendu, et bien sûr je vais tenter de répondre à la question que vous vous posez déjà: "Devops, qu'est-ce que c'est encore que ce bidule ?"

Commençons par les ingrédients: un petit groupe (une douzaine de personnes) qui se réunissait dans une ambiance informelle et très auto-organisée, la plupart ne connaissant pas les autres participants présents, simplement pour discuter d'un sujet qui leur tenait à coeur: recette classique pour passer une soirée passionnante. (Merci au passage à nos hôtes, Theodo, et aux initiateurs, Philippe, Samuel et Fabrice.)

Ajoutons des bières et des pizzas; en effet "Devops" est un raccourci pour "developers and operations", c'est à dire des intervenants du développement (appelés diversement programmeurs, développeurs, codeurs, "softeux", etc.) et de l'exploitation ("exploitants", ingénieurs de production, administrateurs systèmes, etc.). Vous aurez compris qu'on est entre techniciens...

Pourtant il y a là deux cultures très différentes, et on s'en aperçoit vite à mesure que le tour de table pour faire les présentations commence, chacun y allant de son "troll", petite pique pour deviner à la réaction de chacun qui fait partie de quel bord, ça donne à peu près: "je m'appelle X et je préfère vi à emacs, il faut que j'en dise plus?" Le sujet qui nous réunit c'est justement le rapprochement entre deux cultures que l'organisation usuelle des projets de développement a eu tendance à séparer. (Parfois littéralement, au sens "les développeurs dans la grande salle du 3è étage, les exploitants à la cave".) Certains des effets néfastes de cette séparation sont proverbiaux dans la profession: "excuse n°1 du développeur: ça marche sur ma machine!".

Après le tour de table Raphaël a proposé d'organiser le reste de la réunion en Open Space, ce qui nous a permis d'apprécier l'étendue des sujets qui nous intéressaient. De mémoire et en vrac:

• des outils (Chef ou Puppet) pour gérer les configurations système
• exploiter la virtualisation du développement à l'exploitation
• intégrer la création de packages dans le build automatisé
• déploiement maîtrisé des applications Web 
• ...et d'autres que j'oublie...

 Cette liste ne vous apprend sans doute pas grand-chose sur ce que veut dire "Devops"? C'est justement tout l'intérêt de cette communauté naissante.

Je m'explique: de façon très similaire à l'invention en 2001 du terme "Agile", la communauté Devops est née du sentiment diffus d'un certain nombre de personnes qu'elles avaient, chacune dans leur coin, eu des idées convergentes pour résoudre des difficultés lancinantes dans leur métier. En se rencontrant et en donnant un nom (une étiquette, certes) à cette convergence elles espèrent donner plus de visibilité à la fois à ces difficultés et aux solutions proposées.

Il s'agit donc de briser les "silos" qui isolent les développeurs et les exploitants chacun dans leur coin, avec de nombreuses conséquences néfastes: par exemple des projets qui semblent "réussis" techniquement (code propre et bien testé) et fonctionnent très bien... jusqu'au jour de la "mise en prod" où rien ne va plus: quelques connections simultanées et le serveur "tombe", ou encore une base de données ralenties par des accès mal conçus.

On retrouve dans cette volonté de "déspécialiser" une constante de la culture Agile, au sein de laquelle d'ailleurs les fondateurs de Devops ont fait leurs armes. Le discours Agile a cherché à modifier, voire à effacer les frontières entre développeurs et clients, entre développeurs et testeurs, ou plus récemment entre développeurs et ergonomes; Devops vise à abolir une frontière supplémentaire. Plutôt que développer dans leur coin des applications qu'ils vont ensuite "balancer par-dessus le mur" aux exploitants, les développeurs sont encouragés à travailler dès le début du projet avec eux et à les intégrer à l'équipe.

De même que le discours Agile s'oppose à des approches "cérémoniales" ou totalisantes du développement, de même Devops se positionne comme une réponse "Agile" aux démarches ITIL ou Cobit très prisées dans le domaine de l'exploitation.

On retrouve donc dans l'approche Devops, d'une part des outils et pratiques "empruntés" à l'approche Agile:

• outils de management visuel (on parle de "visible ops") pour créer de la transparence
• alignement sur un rythme itératif et incrémental (mettre en production au rythme du développement)
• automatisation du test
• intégration continue

Mais on va également trouver dans Devops des solutions spécifiques, transposant l'approche Agile au métier de l'exploitation, ou qui visent à établir un nouveau contrat avec les développeurs:

• l'automatisation du "build" ne doit pas se cantonner à produire un exécutable mais va jusqu'au bout de la chaîne en produisant un "package" dont l'installation est répétable et même automatisable
• considérer la description d'une infrastructure système comme du code, et intégrer ce code à la gestion de version au même titre que le code applicatif; c'est l'intérêt d'outils comme Chef ou Puppet
• de même qu'on ne teste pas à la main, on n'installe pas à la main, on ne configure pas à la main, etc. - tout ce qui est manuel et répétitif représente de la connaissance et il faut capturer cette connaissance sous la forme de fichiers texte ou de code
• intégrer très tôt dans le cycle de développement les questions de surveillance et de gestion de l'application, de benchmarking des performances, etc. - en d'autres termes adopter une vision d'ensemble
• plus généralement considérer qu'on est "tous dans le même bateau" et qu'il n'est pas productif de chercher "à qui reviennent les reproches" lors d'un incident en production: abolir les petits jeux qu'on voit fréquemment pour savoir si c'est un bug ou un défaut de surveillance qui est à l'origine d'une panne par exemple; adopter des outils, des processus et surtout une responsabilité partagées

Vous pourrez trouver plus d'information ailleurs sur le Web:

• What is this Devops thing, anyway? de Patrick Debois
• Devops Best Practices (concis et précis)
• What is Devops? de Rodrigo Campo
• What is Devops? de Damon Edwards

Les parallèles avec la communauté Agile sont intéressants, notamment le fait que la question "qu'est-ce que DevOps" ne donne pas pour l'instant lieu à une réponse brève, précise et circonstanciée, le mouvement se dérobant aux tentatives de définition. On pourrait le réduire à des outils: de fait au cours de la soirée de mercredi nous avons beaucoup parlé d'outils (j'ai découvert l'existence de Chef, Puppet, Vagrant et d'autres outils et je vais m'y intéresser, par curiosité et pour ma culture générale), mais ce serait la même erreur que de réduire l'approche Agile à des outils.

Dans les deux cas, il ne s'agit ni de définir des méthodologies, d'imposer des processus ou des outils,  mais de créer, d'animer et de se réclamer d'une communauté; l'objet de cette communauté étant l'élaboration et la conservation d'un ensemble de pratiques, non pas pour leur valeur en soi (on ne "sacralise" pas les pratiques) mais pour les bénéfices que ces pratiques apportent aux projets.

MD Day - agilité, modélisation et modélisme

Jeudi dernier, le 25 novembre, se tenait le quatrième MD Day, une journée intéressante à plus d'un titre.

La conférence était hébergée dans le très beau centre de conférences de Microsoft à Issy, auquel le seul reproche que je puisse faire est une connectivité 3G limitée (et je n'avais pas les infos pour me connecter au réseau WiFi en tant qu'invité). Cela n'a pas empêché de nombreux commentaires sur Twitter.

Cette année le thème retenu était "Model-Driven et Agilité", un lien thématique qui se traduisait dans le programme: le mot "agilité" apparaissait dans le titre de quatre des 10 sessions prévues, plus une "table ronde" au sein de laquelle Xavier Warzee et votre serviteur avaient pour mission de représenter le point de vue Agile.

J'étais un peu anxieux à l'idée d'apporter en quelque sorte une "caution" Agile à un événement organisé autour d'une approche du développement, le fameux "model-driven", à laquelle je n'adhère personnellement pas et qui peut sembler aux antipodes du discours Agile: en caricaturant, elle semble marginaliser le rôle du développeur (remplacé par la génération automatique de code) au profit de celui de l'architecte (traçant des diagrammes de modèles dans le but de les convertir en code automatiquement).

Lors d'une intervention aux Valtech Days il y a quelque temps, j'avais ainsi opposé "modélisation" et "modélisme":

En fait de modélisation, on pratique trop souvent ce que j'appellerai le "modélisme": une activité somme toute assez prenante, et qui constitue un excellent passe-temps, mais qui ne produit pas des résultats très constructifs. Ma définition de "modèle" est la suivante: un modèle est une représentation d'une situation réelle, qui sans y être fidèle dans tous les détails est utile pour répondre à des questions concernant cette situation.

On peut illustrer le "modélisme" par ce diagramme par exemple, obtenu à l'aide d'un outil UML qui analyse du code existant. Trente classes différentes sur un seul diagramme ce n'est tout simplement pas lisible, pertinent, ou utile: c'est uniquement une perte de temps.

Il me semblait cependant important d'accepter l'invitation, pour plusieurs raisons. D'une part, je suis favorable aux échanges entre les diverses communautés de professionnels qui se retrouvent autour d'une volonté commune d'améliorer leur pratique d'un métier, en l'occurrence le développement de logiciels. D'autre part, la communauté "model driven" me semble avoir un rapport plus étroit avec le milieu de la recherche, privée ou publique, que la communauté Agile, et l'une des missions de l'Insittut est de resserrer ces liens.

De ce point de vue, l'important était de participer. Mais je me devais d'apporter un regard plus attentif, et dès le début de la journée je m'étais fixé comme objectif de répondre à la question suivante: la communauté "model driven" ici présente est-elle motivée par un réel intéret pour les pratiques agiles, ou s'agit-il (pour l'instant) d'une simple curiosité, piquée par le "buzz" de plus en plus présent autour de l'étiquette "Agile"?

Mon canevas d'évaluation était, comme il se doit, le Manifeste Agile et la liste des pratiques Agiles: lors des sessions, est-ce que les orateurs évoquaient ce qui, dans leurs solutions proposées, privilégiait les individus et les interactions, la livraison de logiciels opérationnels, la collaboration avec le client, et la réponse au changement? Est-ce que les orateurs mettaient en avant l'inclusion dans une stratégie "model-driven" de telle ou telle pratique appartenant à la "boîte à outils" Agile? J'ai prévenu les orateurs des différentes sessions auxquelles j'assistais, afin de ne pas les prendre en traitre, de mon intention de distribuer en fin de journée un "carnet de notes" avec mention des bons et des mauvais élèves.

Alors, quel bilan de cette journée?

Force est de constater qu'il y a encore loin de la coupe au lèvres, et que la communauté "model-driven" n'est pas encore pleinement Agile. Le mot "agile" était plus utilisé pour légitimer un discours déjà établi, que pour y chercher un véritable contenu pouvant constituer un apport.

La première présentation, celle de Grégory Weinbach et Jérémie Grodziski, se distinguait par un rappel explicite du Manifeste Agile, et un véritable "zoom" sur des pratiques, en l'occurrence le Behaviour-Driven Development (BDD) et le Ubiquitous Language issu de l'approche Domain-Driven Design. D'autres éléments Agiles y étaient présents, portant à... quatre le nombre des pratiques Agiles mentionnées lors de cette intervention. C'est honorable mais sans doute en-deça de ce qu'il serait possible de faire en combinant les deux approches, et je suis resté un peu sur ma faim.

Malheureusement, le reste de la journée n'allait pas combler mon appétit pour une mise en valeur de pratiques et de réalités de terrain: les autres sessions auxquelles j'ai assisté se résumaient à peu de choses près à des démos d'outils. La session proposée par l'éditeur W4 abordait (en passant) deux pratiques que j'ai pu reconnaitre comme issues du discours Agile, mais il aurait été plus juste de parler de RAD pour caractériser l'approche présentée. Pour les autres les retours clients étaient (à mon goût) réduits au strict minimum et laissaient la part belle au "pitch" de l'ingénieur commercial montrant (tout seul au clavier) ce qu'on peut faire avec l'outil.

J'ai été particulièrement frappé par une remarque d'un des orateurs, en fin de journée: "pour la suite je vous demande de m'excuser mais il va falloir que je rentre un peu dans les détails du métier de l'assurance...". Mais non, c'est justement l'attention portée au métier de vos clients qui fait, en tout cas pour moi et en tant "qu'Agiliste", toute la valeur et la saveur de votre retour d'expérience.

Car encore une fois, qu'est-ce que modéliser sinon poser des questions à un client dont, en tout cas en début de projet, on ne connaît pas le métier? Pour être vraiment convaincante, une démonstration de l'approche "model driven" soutenue par un outil devrait se tenir sous la forme suivante: on choisit au hasard dans l'assistance une personne qui propose une situation à traiter, issue d'un domaine d'expertise non technique - ou même de la vie courante, par exemple "gérer la fréquentation d'un musée" ou "réserver une table au restaurant" - et on construit en direct une solution à base de modèles. C'est à mon avis dans ce genre d'exercice qu'on s'apercevrait le mieux des bienfaits ou des limites de tel outil ou de telle approche.

Quand on l'aborde sous cet angle, celui où développer des logiciels consiste à encoder et formaliser des connaissances sur un domaine, la distinction entre "code source" et "modèle" commence à mon sens à s'effacer, proposition qui m'a servi de conclusion lors de la table ronde. Toutes les préoccupations que nous avons vis-à-vis du code source sont applicables aux modèles, dès lors que nous sortons du "modélisme" (faire de beaux documents visuels) et que nous cherchons à répondre à la demande d'un client: est-ce que le résultat est correct (ne donne pas des réponses fausses), est-ce qu'il est utilisable (son ergonomie s'adapte à l'utilisateur), est-ce qu'il créée de la valeur?

Dans une approche qui consiste à créer des modèles pour générer automatiquement du code source, cette seconde étape s'apparente à de la compilation, par conséquent le modèle devient le véritable code source. Mais d'un autre côté on constate que les langages modernes (par exemple Ruby) permettent de plus en plus, par le biais de l'abstraction et de techniques comme les DSL, de séparer les préoccupations purement techniques et algorithmiques de l'expression (dans le même langage) des connaissances sur le domaine fonctionnel et des exigences: le code source devient tout à fait adéquat pour exprimer ce qu'on appele en général le "modèle".

Mauvaises conception de la conception

Mon exposé sur les pratiques Agiles liées à la conception a été très bien accueilli à Reykjavik, dont je suis revenu hier très fatigué mais aussi très content.

Mon principal objectif était de faire le lien entre les connaissances accumulées depuis quelques décennies sur les biais cognitifs et l'activité de conception ou "design". J'y ai déjà fait allusion dans mes billets précédents évoquant la danseuse et les bugs du cerveau.

Le point sur la conception

Cet exposé était aussi l'occasion de faire le point sur ce qu'ont été les apports du mouvement Agile au discours sur la conception.

Le terme anglais "design" est très surchargé, que ce soit dans la vie courante (une brosse à dents ou un siège peuvent "être design", c'est une discipline artistique mais aussi industrielle) ou dans le champ professionnel du logiciel, où il peut suggérer aussi bien l'ergonomie (product design, interaction design), l'esthétique (graphic design), la représentation de l'information (information design), ou enfin la conception logicielle à proprement parler.

La terminologie francophone laisse peut-être légèrement moins de place à l'ambiguité, quand on parle de "conception" ce sont le plus souvent les programmeurs qui se sentent concernés.

Avis de décès?

En 2000 paraissait un article important de Martin Fowler, intitulé "Is Design Dead?". A l'époque on ne connaissait que peu Scrum, le "buzz" se concentrait autour d'Extreme Programming et ni l'un ni l'autre de ces discours n'était encore appelé "Agile" - ce n'est qu'à partir de 2001 que le terme issu de la rencontre de Snowbird sera adopté.

On sortait d'une période qui avait vu UML triompher après un long et intense débat sur les notations formelles graphiques, bien illustré dans ce dessin. Pour une grande partie de la profession, "UML" et "conception logicielle" étaient devenus des synonymes.

Fowler relevait l'une des principales critiques à l'égard d'Extreme Programming, auquel on reprochait d'être "centré sur le code". Et de constater le rejet par Extreme Programming non seulement d'UML mais de plusieurs dogmes tout aussi fortement associés à l'idée de conception: le principe d'une "phase de conception" venant en amont de la phase de programmation, celui d'organiser le développement autour de "frameworks" ou de "patrons de conception".

Pour certains, selon Fowler, Extreme Programming semblait vouloir en finir avec la conception. Martin Fowler était en bonne position pour arbitrer ce débat: il était non seulement le co-auteur d'un bréviaire sur UML qui avait connu des ventes record, mais également d'un livre sur le "refactoring" connu comme l'une des pratiques clés d'Extreme Programming, et considéré commel'une des figures tutélaires de cette mouvance.

Non, concluait Fowler, Extreme Programming n'appellait pas à la mort de la conception ni n'annonçait son décès; et Fowler d'attester, en analysant de près les recommandations effectivement émises par Extreme Programming, que la conception y restait une préoccupation majeure, et que ses critiques avaient eu une vision caricaturale de la conception.

Trois mises au point sur la conception

Extreme Programming, et à sa suite le mouvement Agile, ont ainsi permis de rectifier, ou de commencer à rectifier, un certain nombre d'idées fausses sur la conception, et trois exemples me paraissent particulièrement importants.

La conception n'implique pas nécessairement une notation formelle qui s'exprime visuellement. Cette idée a longtemps été le cheval de bataille des tenants d'UML, et le triomphe d'UML au tournant de l'an 2000 était partiellement le triomphe de cette idée. Par un raccourci de pensée jamais justifié "visuel" était présenté comme synonyme de "supérieur": parce que UML permettait de modéliser visuellement, il était un meilleur véhicule pour parler de conception. Corollairement, le code source lui-même, n'étant que textuel, ne pouvait pas être un support approprié pour exprimer des notions de conception.

Le succès des approches Agiles a contribué à remettre les pendules à l'heure. Toutes les modalités d'expression - visuelles, textuelles, ou autres - ont leur place pour parler de conception. La question est moins de savoir comment représenter le résultat des activités de conception, mais plutôt de savoir qui doit y participer, et par conséquent où elles doivent se dérouler. L'approche privilégiée par les équipes agiles est celle de la "modélisation agile" ou des "sessions rapides de conception": cela se passe au tableau blanc, on doit impliquer les développeurs chargés de la réalisation, et s'il faut conserver une trace permanente une photo du tableau suffit largement.

La conception n'est pas nécessairement une activité qui précède la programmation. Avec UML c'est aussi une approche en phases du projet de développement logiciel qui prévaut. L'accent a été mis sur des outils permettant aux architectes de réaliser un document de conception détaillé en amont du développement, et (comme on dit alors) de le "balancer par-dessus le mur" aux programmeurs qui doivent en suivre les recommandations. C'est une vision caricaturale et inefficace des activités de conception qui n'a que peu de rapport avec la réalité du terrain.

La démonstration en est faite par Fowler lui-même dans son ouvrage sur le Refactoring, dont le sous-titre est "améliorer la conception d'un code existant". C'est un travail rigoureux, argumenté, basé sur un travail de thèse doctorale, celle de Bill Opdyke; il amène Fowler à prédire, et l'avenir lui donnera raison, l'intégration du refactoring automatisé dans les éditions futures des outils de développement.

La conception est une activité collective, pas exclusivement individuelle. Le discours sur la conception est dominé par la description de principes, d'heuristiques, de règles. Grammaticalement, la forme la plus usitée est celle de l'impératif: "évitez les classes contenant un trop grand nombre de méthodes publiques". On n'y prend presque pas garde mais une hypothèse, implicite et jamais remise en question, sous-tend la quasi totalité de ce discours: il s'adresse à une seule personne (Le Concepteur), travaillant de manière isolée. Elle se confirme facilement en examinant des sites d'entraide du type StackOverflow: les questions sont systématiquement de la forme "Comment dois-je m'y prendre pour..."

L'approche Agile suggère une autre démarche, dans laquelle le "nous", le collectif, l'équipe prennent le pas sur l'individu. La question n'est plus "quelle est la bonne conception dans cette situation", mais "sur quelle conception pouvons-nous être d'accord". Non pas "quel principe de conception prévaut", mais "quels critères nous permettent de décider entre deux propositions individuelles (ou mieux encore en faire la synthèse)".

L'enjeu de la conception n'est pas, d'une façon un peu scolaire, de donner individuellement la réponse correcte; il est pragmatique et économique, et consiste à générer plusieurs propositions et décider, entre ces diverses alternatives, laquelle offre les conséquences les plus désirables pour le projet. Cette décision engage la responsabilité de chacune des personnes qui devront ensuite assurer la maintenance du code, elle est donc une négotiation collective... sans pour autant être nécessairement égalitaire: les compétences en matière de conception ne seront que rarement partagées dans l'équipe de façon homogène.

Changer de point de vue

Sur ces trois points au moins, le discours Agile a contribué à chasser les images d'Epinal de la conception et rétablir une perception plus juste de cette activité. Reste que ces trois erreurs avaient à mon sens une origine commune, l'erreur de projection que je dénonçais dans un précédent billet: et malheureusement, y compris au sein de la communauté Agile, nous continuons à commettre cette erreur en parlant exclusivement de propriétés du code telles la duplication, la complexité, les heuristiques SOLID, les métriques de conception, etc.

Tout comme la dette technique, la conception, bonne ou mauvaise, n'est pas exclusivement une propriété du code source (ou des documents et autres artefacts qui l'entourent), et se focaliser sur les produits de l'activité de développement, c'est faire l'impasse sur la moitié de la question: le fonctionnement cognitif humain et ses limites.

Des bugs dans le cerveau aux bugs dans le code

Pourquoi est-il si difficile de créer du logiciel sans bugs? Probablement en grande partie parce que l'outil principal que nous utilisons est lui-même un très mauvais exemple de conception rationnelle, et pour cause, et quand on y regarde de près s'avère bourré de bugs.

Cet outil, c'est le cerveau; ou si l'on veut, mais en ne le prenant que comme une métaphore, le logiciel, appelé "Intelligence", que nous faisons tourner sur le matériel qu'est le "Cerveau". (Faire le parallèle entre l'esprit-logiciel et le cerveau-matériel, c'est en soi rentrer dans la vaste controverse de l'intelligence artificielle, et ce n'est pas mon propos.)

La Loi des Bugs

Je ne suis pas loin de penser que l'énoncé suivant est une loi fondamentale du développement:

Il n'existe de bugs dans nos programmes qu'en raison de bugs dans notre pensée.

Le terme "bug" est en soi un choix terminologique malheureux, c'est un excellent exemple de la psychologie de la projection que j'évoquais dans un précédent billet: on visualise une petite bestiole dont l'existence et les décisions sont autonomes et indépendantes de notre volonté. Je lui préfère en général le terme "défaut", qui indique plus clairement ce qui est, selon moi, toujours à l'origine de ce qu'on appele familièrement un bug: une erreur du programmeur, se traduisant par un code source qui spécifie un comportement différent de ce qu'il devrait être.

Mais c'est au moins un terme familier, et si vous dites à quelqu'un "tu ne t'en aperçois pas mais ton cerveau est plein de bugs", vous êtes au moins sûr de faire une forte impression.

Biais cognitifs

L'étude des bugs du cerveau relève de la psychologie, et le terme plus communément accepté est celui de "biais cognitif". Contrairement à la situation qui prévaut dans le domaine du logiciel, les sciences cognitives ont produit, s'agissant des biais cognitifs, des connaissances scientifiques démontrées de façon robuste, répétable, qui ne sont plus affaire d'opinion. Indépendamment de ce que je voudrais croire ou de mes bonnes intentions, je suis bien contraint de reconnaitre que mon cerveau, à peu de choses près dans la même mesure que celui de mes congénères, est sujet à un certain nombre de biais cognitifs.

Intéressons-nous par exemple au biais de confirmation. Nous allons voir que ce phénomène, qui est par ailleurs l'un des plus importants et sournois dans la psychologie humaine, est tout à fait pertinent pour éclairer notre approche du développement logiciel.

Il est mis en évidence par de nombreuses expériences dont les premières remontent aux années 1960 avec les travaux de Peter Wason.

Wason montre à ses sujets un triplet composé de trois chiffres: (2, 4, 6) et indique que ce triplet répond à une "règle de construction" qu'il s'agit de deviner. Il demande aux sujets de lui fournir des exemples supplémentaires afin de "tester" diverses hypothèses quant à l'énoncé de cette règle. L'expérimentateur se borne à donner une réponse binaire: "oui, votre exemple est conforme à la règle" ou bien "non, votre exemple n'est pas conforme". C'est donc une tâche inductive, très ouverte par nature.

En étudiant de près les hypothèses formulées par les personnes confrontées à cet épreuve et les "essais" fournis successivement, Wason est en mesure de démontrer une tendance tout à fait systématique: on propose beaucoup plus facilement des exemples "de confirmation", c'est-à-dire conformes à l'hypothèse qu'on a la plus récemment formulée. Or c'est une erreur, car si des exemples confirmés peuvent nous amener à valider une réponse avant de la proposer, la démarche la plus fructueuse consiste à proposer des exemples qui (s'ils sont acceptés par l'expérimentateur comme conformes à la règle) invalident notre hypothèse et nous forcent à la reformuler.

D'autres expériences de Wason conforteront le "biais de confirmation" comme une erreur de raisonnement tellement courante qu'on peut la considérer comme systématique chez l'être humain: ainsi sur une tâche consistant à déterminer lesquelles parmi quatre cartes on doit retourner pour vérifier une règle du type "SI telle figure apparaît au recto ALORS telle autre doit apparaître au verso", seuls 10% des sujets donnent la bonne réponse! Ceci alors que plus de 90% des sujets reconnaissent, une fois qu'on leur a donné cette réponse, qu'elle est effectivement correcte et qu'ils pouvaient logiquement le déterminer à la lecture de l'énoncé: ce qui écarte donc l'hypothèse d'une ambiguité ou d'une mauvaise compréhension de la tâche.

(Si vous êtes tenté à la lecture de ce billet de développer vos propres facultés en matière d'induction et de formulation d'exemples contradictoires, essayez le jeu Zendo, passionnant pour les petits et les grands...)

Application au développement

Revenons au développement de logiciels, et plus précisément à un des épisodes de l'historique du génie logiciel. En 1976, Glenford Myers, auteur de l'ouvrage de référence "Software Reliability, Principles and Practices", écrit ceci:

Il est impossible de tester vos propres programmes. Aucun programmeur ne devrait tenter de tester son propre programme. Ceci s'applique à toutes les formes de test, que ce soit le test système, fonctionnel ou le test unitaire. [...] Le test doit être une activité extrêmement destructrice, et il est des raisons psychologiques profondes qui empêchent le programmeur d'adopter une attitude destructrice vis-à-vis de son propre programme."

Les mots employés sont très forts: "impossible", "toutes les formes de test". Myers ne cite pas Wason et ne détaille pas dans cet ouvrage les "raisons psychologiques profondes" auxquelles il fait allusion, mais il semble clairement s'agir de notre tendance à imaginer plus facilement des jeux d'essais qui visent à confirmer nos hypothèses que ceux pouvant les infirmer. (Il existe d'ailleurs quelques études cherchant à démontrer directement l'impact du biais de confirmation sur l'incidence des défauts dans le code.)

Cette affirmation que Myers présente comme un "axiome" deviendra pendant de nombreuses années l'orthodoxie en matière de test logiciel. (Une recherche Google avec la phrase "test their own code" donne assez facilement des exemples récents de billets d'opinion reprenant sans la critiquer cette idée, comme si elle allait de soi.)

En un sens, cette affirmation a eu un effet positif: elle a favorisé l'apparition d'une sous-discipline, le test indépendant, dont l'apport est certainement bénéfique; bien qu'en France la culture soit apparemment bien moins sensible à l'intérêt d'employer des personnes dans un rôle dédié de "testeur" ou "assurance qualité", par rapport aux Etats-Unis.

TDD ou l'inversion géniale

Pourtant, je soupçonne cette attitude d'avoir également généré de sérieux dégâts, en berçant d'innombrable développeurs dans la douillette illusion que "tester leur propre code" était non seulement une erreur mais une faute professionnelle. Pensez-y la prochaine fois que vous rencontrez sur un site Web une NullPointerException, l'exemple par excellence d'une défaillance logicielle qu'on peut parfaitement éviter en testant plus soigneusement son code.

Les choses n'ont commencé à changer que relativement récemment, et grâce à l'introduction de la pratique agile du Développement par les Tests (ou TDD).

Il s'agit pour moi (et pour d'autres, comme Steve McConnell dans Code Complete) de l'une des contributions majeures de la mouvance Agile à ce qu'il faut bien encore appeler le génie logiciel. Depuis les années 2000 le discours autour de cette pratique a considérablement évolué en sophistication, mais l'idée élémentaire est restée la même.

Elle exploite la notion d'un test unitaire automatisé, c'est-à-dire un bout de code qu'on écrit uniquement pour mettre en évidence qu'un autre bout de code (celui-là utilisé directement dans le programme réel) fonctionne comme attendu. Il va de soi qu'un test unitaire automatisé, en soi, reste un "test", un "essai" qu'on confronte à une hypothèse: l'automatisation ne change rien de fondamental.

Ce qui est radical, c'est l'idée suivante:

écrire le test avant d'écrire le code correspondant

Cela n'a l'air de rien mais cette simple inversion suffit simultanément:

• à donner raison à Glenford Myers sur l'importance du biais de confirmation en matière de test
• à lui donner tort sur les conclusions: un développeur peut et doit tester son code

En effet, avant d'avoir écrit un élément de programme, nous ne sommes pas sujets au biais de confirmation, puisque nous ignorons encore les détails de l'implémentation. Ces détails fonctionnenent en programmation comme l'hypothèse à tester dans la tâche de Wason: si nous avions connaissance de notre implémentation, nous serions tenté de ne penser qu'à des jeux d'essais qui confortent l'impression que nous avons que notre code est correct.

En inversant l'ordre de marche, nous avons tenu compte de nos propres limitations cognitives, et nous leur avons apporté une solution nettement plus efficace, car nécessitant moins de coordination, que la solution classique "embaucher des testeurs indépendants pour tester le code mal fichu des développeurs". (Cette dernière solution garde cependant de son intérêt, car il existe bien d'autres aspects de la qualité logicielle qui peuvent bénéficier du travail d'un testeur que la seule qualité technique du code source.)

Conclusions

Ce premier exemple donne une perspective un peu différente sur le TDD que celle habituellement présentée, et surtout démontrant à quel point s'intéresser au développement logiciel par le biais des sciences cognitives, et notamment par celui des biais cognitifs, peut être puissant et fructueux.


L'approche usuelle du génie logiciel a été d'écarter systématiquement ces considérations, qui reposent pourtant sur des bases scientifiques robustes, pour ne considérer que les aspects "objectifs" du logiciel, vu comme une "chose naturelle" indépendante de l'esprit humain qui l'a créé: c'est pourquoi, à mon sens, cette discipline telle qu'elle a été conçue jusque là ne peut pas résoudre les difficultés qu'elle prétendait aborder. Pour progresser, il est impératif de tenir compte des aspects cognitifs qui jouent un rôle déterminant dans la création de logiciels.

Le champ d'application de cette démarche va bien au-delà de la technique, on peut lui trouver des applications dans la gestion de projet, la gestion des compétences, l'estimation des délais, bref à l'ensemble des préoccupations des professions du logiciel.

Reykjavik, Prezi, conception Agile

Jeudi prochain, destination: Reykjavik! Le choix du coeur, ayant beaucoup apprécié l'Islande lors de vacances passées là-bas il y a deux ans, et promis d'y revenir; mais également un coup de pouce à une communauté Agile très dynamique.

J'avais bien apprécié l'atelier sur la pensée visuelle proposé par Benoit Gantaume (Agilidée, partenaire de l'Institut) lors de l'étape Nancéenne de l'Agile Tour et je m'étais promis de mettre en oeuvre les outils présentés à l'occasion d'un exposé pour une conférence.

La session avec laquelle je "tourne" actuellement, "Quarante ans de crise, dix ans d'agilité, et après" est largement constituée des sujets que j'ai traité récemment sur ce blog, qui proviennent eux-mêmes des réflexions qui ont motivé le lancement de l'Institut; elle n'est pas vraiment pertinente pour mes amis Islandais (et une précédente expérience m'a appris que le caractère Nordique peut être impatient avec ce qui ne lui semble pas pertinent: c'est mon unique et cuisant souvenir d'un exposé où une bonne partie de la salle a "voté avec ses pieds").

J'avais donc proposé un sujet sur les pratiques Agiles liées à la conception. Je souhaitais apporter une perspective un peu différente sur ce sujet: que nous a appris le mouvement Agile sur la conception, quelles pratiques sont utiles dans ce domaine et pourquoi, comment la prise en compte du non-technique et du "facteur humain" en Agile éclaire-t-elle notre compréhension de cette activité, vers quels sujets scientifiques nous pousse-t-elle à nous intéresser?

Depuis quelque temps je voulais aussi sortir de l'ornière "PowerPoint" (en l'occurrence Keynote puisque je suis un "Apple fanboy", mais c'est du pareil au même) mais je ne me sens pas encore à l'aise, lorsque j'aborde des sujets un peu théoriques, avec un exposé sans aucun support visuel. D'expérience, mon auditoire est composé de personnes ayant des préférences cognitives diverses: certains sont plutôt visuels, d'autres plutôt auditifs, d'autres kinesthétiques. Je cherche à présenter le même contenu sous plusieurs formes pour m'assurer que le maximum de personnes en retirent l'essentiel.

J'avais entendu parler de Prezi (et vu une présentation de Jonathan Perret utilisant cet outil à Agile France 2010), j'ai saisi l'occasion pour expérimenter.

Mon retour, façon Perfection Game: j'attribue largement 6/10, Prezi tient ses promesses de dépasser le carcan suranné du "slideware" directement hérité du projecteur de diapos (que mes parents avaient rangé dans un placard pour ne jamais le ressortir alors que j'avais, disons, 8 ou 10 ans). A la place, et après un démarrage très déroutant, on goûte un vrai sentiment de liberté devant le canevas sans limite et la possibilité de zoomer en avant, en arrière à l'infini (presque, j'ai réussi à me faire taper sur les doigts parce que ma présentation commençait à faire concurrence à "powers of ten" en termes de niveaux parcourus). On se sent vraiment incité à penser visuellement, à organiser spatialement des idées jetées pèle-mèle, à les hiérarchiser par la taille. Je me suis même pris à créer des jeux de mots visuels, alors que c'est tout sauf mon langage de prédilection!

Pour avoir 10/10 il faudrait corriger quelques défauts d'ergonomie, mineurs et pas bloquants mais très, très frustrants par moments; il faudrait pouvoir copier-coller plus facilement entre présentations (à mon avis Prezi a loupé une grosse occasion d'exploiter la dimension "sociale" de leur outil, en encourageant les auteurs à se piquer des éléments réutilisables); il faudrait un peu plus de liberté dans le choix des polices et des couleurs de fond.

Mon premier Prezi est en ligne (c'est la règle du jeu, la gratuité de l'outil est au prix du partage, je trouve ça très bien mais encore une fois on peut regretter que ça ne soit pas mieux exploité), si vous avez envie de jeter un coup d'oeil, vos retours seront les bienvenus.

Une Revue des Logiciels et Projets Agiles?

Il m'est arrivé de parler à des collègues chercheurs dans le milieu universitaire, aussi bien en France qu'à l'étranger, et de leur poser la question: "Comment se fait-il qu'on voit si peu de recherche spécifiquement sur les approches Agiles?" J'en connais plusieurs qui s'y intéressent et travaillent "officiellement" sur des sujets connexes, par exemple en génie logiciel. Mais ils ne publient pas ou peu d'études visant à analyser précisément telle ou telle pratique, tel ou tel discours porté par la communauté Agile.

Quand je m'en étonne, ils me font remarquer la chose suivante: pour un scientifique, un critère d'évaluation important de son travail est la production de publications acceptées par des revues réputées dans son domaine. Produire un "papier" qui ne trouverait pas un débouché dans une publication reconnue comme ayant un caractère scientifique constituerait un travail en pure perte. (Dans le secteur privé, un chercheur est un salarié, il ne rend finalement de comptes qu'à son employeur, et pour peu qu'il ait un manager éclairé il se verra imposer peu de contraintes. Il est possible que cette tyrannie des "bonnes" revues pour publier soit moins contraignante dans ce contexte.)

Il n'existe pas, à ma connaissance, de revues scientifiques spécifiquement consacrées à l'etude des pratiques Agiles. Par conséquent, on ne publie pas sur ce sujet. Mais, bien évidemment, l'absence de travaux dans ce domaine contribue à pérenniser la fracture entre recherche et industrie, ce qui fait que les intervenants des projets Agiles pensent que le travail des chercheurs ne les concerne pas. L'industrie n'en faisant pas la demande, la recherche de son côté continue à ne pas s'intéresser à ce sujet, et a peu de chance de vouloir reconnaître sa pertinence. Cela ressemble pas mal à un cercle vicieux!

Pourtant on peut facilement se convaincre qu'un canal de publication de ce type est nécessaire.

Le modèle consacré est celui de l'évaluation par les pairs ("peer review"), les publications se dotant d'un comité de lecture dont le rôle est de filtrer les travaux proposés pour veiller à ce que ce qui est publié répond à des critères de qualité spécifiques: il s'agit en fait d'assurer la bonne "circulation des références" comme l'a analysé Bruno Latour, vérifier par exemple que les chercheurs sont au courant des travaux précédemment effectués dans leur domaine, les référencent et les sites, que leurs études permettent de combler les lacunes de ces antécédents et ainsi consolider les connaissances.

Ainsi beaucoup de travaux portant sur des sujets tels que le développement par les tests ou la programmation en binômes souffrent d'un travers élémentaire: ils sont réalisés par des chercheurs qui utilisent leurs propres étudiants comme sujets d'étude. Mais, par définition, il s'agit d'une population non pas de programmeurs en exercice, mais de programmeurs en devenir! Pire encore, le protocole expérimental prévoit généralement un temps ridiculement court pour former ces sujets d'étude à la pratique dont on cherche à discerner les bénéfices.

On va donc passer une après-midi ou une journée à expliquer le développement par les tests (TDD) à des étudiants, puis comparer leur performance à celle d'autres étudiants, la condition expérimentale consistant pour l'essentiel à ce qu'un des deux groupes reçoit l'instruction "utilisez ce qu'on vous a appris". Quelle que soit la rigueur de l'analyse statistique qui vient ensuite, il est impensable de tirer de telles études la moindre conclusion définitive quant à l'intérêt que le TDD peut avoir en entreprise. Et ces études, même quand on les qualifie prudemment de "préliminaires", sont rarement suivies de nouvelles visant à corriger ces lacunes. Pour la simple et bonne raison qu'intervenir en entreprise coûte plus cher, et exige de surmonter la réticence, compréhensible mais pas nécessairement appropriée, de ces dernières à inviter des chercheurs dans leurs bureaux pour regarder de près ce qui s'y passe.

Fédérer en réseau les chercheurs qui oeuvrent dans ce domaine, et à terme contribuer à la création d'une telle revue, est une mission tout à fait naturelle pour l'Institut Agile. L'objectif est de produire des connaissances affranchies des opinions et idéologies qui soient utiles aux intervenants des projets Agiles.

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!

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.