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.

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.

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.

Canevas de description d'une pratique

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

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

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

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

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

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

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

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

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

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

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

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

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

Agilité en kit: les outils de montage

Une autre raison me pousse à vouloir donner un coup de projecteur sur les pratiques Agiles, plutôt que sur les étiquettes Scrum, XP, etc. Chacune de ces différentes approches est présentée comme un tout: un ensemble de pratiques qui vont donner un bénéfice maximal si on les met en place ensemble.

Oui, mais vouloir passer d'un seul coup de "pas Agile du tout" à "tout Scrum" ou "tout XP" est, du point de vue humain et managérial, une situation très rare. Elle peut se produire lorsque les équipes sont en crise et sont prêtes à tout pour en sortir; ou encore lorsque des gens se retrouvent pour un nouveau projet qui ont déjà utilisé Scrum ou XP précédemment. Mais la situation encore la plus courante est celle d'équipes et d'entreprises qui veulent bien mettre un pied dans l'eau, mais pas plonger la tête la première.

Une première idée est d'appliquer la logique Agile à la transition elle-même: "Adoptez la pratique qui vous semble la plus importante, puis itérez". Ce type de conseil a un intérêt limité, d'une part parce qu'il n'est justement pas évident de déterminer quel outil "agile" est pertinent dans telle ou telle situation, d'autre part parce qu'une seule pratique utilisée en isolation peut avoir des bénéfices marginaux. Enfin, il existe un risque que le discours consistant à dire "cette pratique ne s'applique pas dans mon contexte" serve de prétexte à ne pas se remettre en question.

Pour éviter les écueils du type "Culte du Cargo", nous voudrions une démarche qui permette de déployer, dans un contexte donné, et à diverses étapes d'un projet, les pratiques agiles les plus pertinentes. Avec au départ 'un "kit" de pratiques, et des outils permettant un assemblage cohérent, on va fabriquer une méthodologie sur mesure.

Le premier de ces outils est la modélisation du processus de développement.

En fait de modélisation, on pratique trop souvent ce que j'appelle 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.

Les modèles les plus utiles ne sont pas en UML - voyez ci-dessous pour une notation plus simple. Les modèles les plus utiles ne sont pas nécessairement visuels - une ou deux équations, une phrase de texte peuvent utilement servir de modèle. Et les modèles les plus utiles ne sont pas nécessairement des représentations d'une architecture ou d'un logiciel. On peut également modéliser utilement le processus de développement lui-même.

Un exemple. Un des principes Agiles consiste à tester tout au long du projet: on a remis en cause l'approche classique consistant à laisser le test pour la fin. La base de cette critique est une réflexion sur les modèles qui conduisent à prendre cette décision. Dans un modèle trop simplifié, on part du principe que la production de code aboutit à une certaine production de défauts, et qu'il suffit une fois le code produit de procéder à l'élimination de ces défauts:

 Si on croit cela, on va légitimement remettre les tests à la fin du projet. Le diagramme ci-dessus, dans une notation appelée "diagramme d'effets", permet de rendre explicite cette supposition, et on peut le comparer avec le diagramme suivant:

Dans ces diagrammes on s'intéresse aux caractéristiques quantitatives des situations: une bulle est une quantité susceptible, si on le voulait, d'être mesurée. Une flèche est un lien de cause à effet. Lorsqu'elle est ornée d'un "+", l'effet et la cause vont dans le même sens (si l'un augmente, l'autre augmente, et vice-versa); ornée d'un "-", cause et effet vont dans le sens opposé. On doit ce type de diagramme à Peter Senge et Jerry Weinberg.

 Je dis "susceptibles d'être mesurée" parce que ces diagrammes donnent surtout des résultats qualitatifs. Il existe des outils permettant de transformer des diagrammes de ce type en simulations numériques. Mais dès que l'on fait intervenir tous les facteurs qui rendent l'analyse plus réaliste, la complexité des modèles rend cette analyse laborieuse, alors qu'on peut obtenir de très bons résultats sur la base d'une analyse quantitative. Ainsi on voit sur le second diagramme que le coût du test est fonction de plusieurs variables, notamment la taille du projet et le délai entre réalisation et test: on rend compte du fait que plus il s'écoule de temps entre l'introduction d'un défaut et sa mise en évidence par le test, plus il est difficile à corriger. Comme les effets de ces deux variables se renforcent, on peut s'attendre à ce que le coût du test augmente plus que linéairement avec la taille des projets.

Les paramètres qui nous préoccupent sont souvent les mêmes d'un projet à un autre: taille du projet, taille de l'équipe, délai, productivité, qualité, etc. Par contre les influences qui s'exercent sur ces paramètres peuvent être très différentes, selon le type d'entreprises (SSII, éditeur, industriel), le secteur d'activité (finance, scientifique, commerce) et autres caractéristiques du contexte. Et, toujours en fonction du contexte, la priorité accordée à ces différents paramètres peut être très différente. Chez un éditeur on pourra privilégier le respect des délais par rapport à la qualité, dans un contexte industriel l'inverse peut se produire; dans la finance de marchés les performance peuvent être le critère dominant, etc.

Par conséquent, il faut s'attendre à ce que chaque projet soit régi par un modèle différent. L'idéal est de réunir plusieurs personnes concernées par la situation et chercher à explorer, dans une session de type "brainstorm", les liens de causalité entre les différentes variables. Ensuite, on cherche à trouver des interventions: des modifications dans la façon habituelle d'aborder le projet qui, en modifiant le sens d'une relation existante, en supprimant ou créant de nouvelles relations, aient une influence favorable sur les paramètres qui nous préoccupent sans pour autant avoir d'influence néfastes. (C'est souvent là qu'est l'os...)

Souvent, on ne trouve une réponse efficace qu'après avoir obtenu un "déclic" qui permet de réduire le modèle à un nombre moins importants de variables. Les pratiques agiles sont autant d'interventions permettant de modifier la structure des influences mutuelles entre les paramètres du projet. Ainsi la pratique du développement par les tests modifie profondément l'interaction modélisée ci-dessus: pour une bonne partie l'activité de test a lieu avant le développement, la valeur moyenne du paramètre "délai entre l'introduction d'un défaut et le test permettant de le détecter" est réduit de plusieurs ordres de grandeur.

Ces diagrammes d'effets font partie des outils utilisés par les meilleurs consultants étiquetés "Agiles" pour s'assurer de l'efficacité de leurs interventions. Pour être efficace avec une approche Agile il faut non seulement très bien connaître les mécanismes "typiques" qui régissent les projets de développement, mais encore être capable d'analyser finement les variations de ces mécanismes propres à un contexte donné. La simple connaissance des pratiques ne suffit pas: il faut savoir pourquoi et comment elles fonctionnent, mais aussi quand elles sont susceptibles de ne pas fonctionner.

Pratiques agiles: précautions d'utilisation

Attention, terrain miné. J'ai dit précédemment que pour tirer parti des approches Agiles, il était plus efficace de s'intéresser en priorité aux pratiques: à ce que font les équipes et les individus; les principes servant plutôt de règles générales pour vérifier la cohérence de ces actions.

Pour autant, il y a un risque majeur à trop se focaliser sur ces pratiques: celui de tomber dans l'imitation, ce que l'on connait sous le nom de Culte du Cargo, en référence à ces tribus mélanésiennes qui, durant la seconde guerre mondiale, voyaient les militaires japonais et américains construire des pistes d'atterrissage et des tours de contrôle. Activités systématiquement suivies de l'arrivée d'avions chargées de cargaisons de vivres et autres objets sophistiqués. Lorsque la guerre cessa, et faisant le lien logique entre l'activité et son résultat, certains chefs tribaux promirent à leurs ouailles la reprise des livraisons: il suffisait pour cela... de construire des répliques en bambou des tours et des pistes!

On aurait tort de se moquer, tant on retrouve souvent la même attitude au sein d'équipes et d'entreprises dans le domaine du logiciel. "Chez Goopple les équipes utilisent des pratiques Agiles: du TDD, des rétrospectives, des itérations. Et regardez leur valorisation en bourse! Chez nous aussi, faisons du TDD, des rétrospectives et des itérations. On devrait avoir les mêmes résultats." (De même  - ça fait déjà quelques années que j'en parle - pour l'approche "classique" des projets de développement: les boîtes qui marchent bien font un contrat, puis un cahier des charges, puis une conception technique détaillée, puis implémentent et testent, alors on va faire la même chose. Ainsi se perpétue une "méthode" qui, en réalité, ne fonctionne pas.)

L'utilisation judicieuse des pratiques et des compétences proposées par la communauté Agile exige d'abord de bien connaître les mécanismes par lesquels on produit du logiciel, puis de comprendre en quoi les pratiques qu'on souhaite utiliser modifient ces mécanismes.

Si l'on ne se préoccupe pas du tout de la question sous-jacente, "qu'est-ce que c'est, finalement, que cette activité qui consiste à produire du logiciel", on se retrouve dans une situation analogue à celle des tribus Mélanésiennes, qui voient arriver "magiquement" du cargo mais ignorent tout de la formidable complexité du système industriel qui, à des milliers de kilomètres, est responsable de la production de ces richesses.

Voici donc, en version courte, la notice d'utilisation des pratiques et compétences Agiles:

On déploie une pratique ou une compétence dans le but d'en obtenir des bénéfices bien identifiés; l'hypothèse selon laquelle nous obtiendrons ces bénéfices doit être justifiée par un mécanisme supposé (on pourrait aussi dire une modélisation de l'activité de développement) qui nous permet de penser que cette pratique aura les bénéfices attendus. L'utilisation sur la durée de cette pratique ou compétence doit être soumise à une vérification empirique, si nous n'obtenons pas, dans un délai préalablement établi, les bénéfices attendus d'une façon que nous pouvons un tant soit peu objectiver, alors il nous faudra, d'une part abandonner ou modifier cette pratique, d'autre part remettre en question notre compréhension des mécanismes.

(Voici, soit dit en passant, pourquoi je suis très peu favorable à un mouvement actuellement en vogue visant à "étendre les approches Agiles au-delà des technologies de l'information". Notre compréhension de la façon dont fonctionne le développement logiciel ne s'applique certainement pas à l'identique dans d'autres domaines; faire la supposition que des pratiques qui "marchent" bien, dans le domaine bien précis des technologies basées sur du logiciel, vont marcher aussi dans d'autres domaines, n'est pas sans rappeler le Culte du Cargo.)

La question "qu'est-ce que c'est que la production de logiciel" est évidemment très vaste, mais on ne peut pas en faire l'économie. Pour être utile, la description des pratiques Agiles doit faire le lien entre la nature de cette activité d'une part, les "lois" et les contraintes qui la régissent, et d'autre part les bénéfices attendus et le raisonnement qui nous laisse penser que ces pratiques apporteront ces bénéfices.

Principes, concepts, pratiques et compétences

Voici résumés dans le titre, et par ordre croissant d'importance, les éléments qui font le contenu de l'approche Agile. Pour résumer le contenu de ce billet: les principes, c'est ce qui nous préoccupe quand on s'arrête pour réfléchir; les concepts, ce sont les définitions auxquelles on revient pour éviter de se tromper; les pratiques, c'est ce qui nous distingue visiblement d'autres équipes; mais le plus important reste les compétences, c'est-à-dire que nous nous attachons à améliorer.

La question "sommes-nous Agiles" n'a que peu d'intérêt. Bien plus importante est la question "qu'avons-nous appris, qui nous permet dans la pratique de mieux réussir nos projets?"

Lors de la réunion où fut écrit le fameux Manifeste, c'est cette question qui animait les participants. Leur objectif était de décrire leurs points de convergence les plus forts possibles: c'est une démarche qui les conduisait nécessairement à une formulation un peu abstraite, un peu éloignée de la réalité quotidienne des projets qu'ils vivaient alors. Ce sont donc les "douze principes" réputés sous-tendre la pratique Agile.

Les principes fournissent un garde-fou utile. Si je m'aperçois que la mise en place de pratiques censément Agiles a eu pour résultat de démoraliser toute l'équipe, le cinquième principe, "bâtissez le projet autour de personnes motivées", m'avertit qu'il y a peut-être une contradiction quelque part. A tout le moins, je dois le prendre comme un sérieux avertissement, envisager que j'ai pu faire fausse route.

Mais on ne peut pas construire un projet sur la seule base de quelques principes. Admettons, nous somme tous d'accord pour "satisfaire le client en livrant tôt et régulièrement des logiciels utiles". Cela ne constitue pas un conseil opérant, ou comme on le dit en anglais avec beaucoup de pertinence, "actionable". C'est comme si on vous conseillait, pour gagner en bourse: "achetez des actions lorsque les prix sont bas et revendez-les lorsque les prix sont hauts". Parfaitement juste et sensé, mais aussi parfaitement inutile: on demande immédiatement comment?

Les concepts doivent être maîtrisés sous peine de contresens fatals. Scène vécue: un "Scrum Master" nouvellement certifié débarque sur une liste de diffusion et demande, "est-il raisonnable de fixer pour le prochain Sprint une vélocité de 80% parce qu'un membre de l'équipe est absent?". Des questions de ce type me mettent mal à l'aise quant à l'efficacité et à la qualité des formations! (C'est un de ces incidents qui m'a amené à la conclusion qu'un référentiel plus clair était nécessaire.)

La mise en place d'une approche Agile exige de connaitre un peu de théorie. Pour acquérir un concept théorique il suffit le plus souvent d'en recevoir la définition, par exemple "la vélocité est obtenue en faisant le total des points (estimations) associés aux User Stories qui ont été terminées dans l'itération qui vient de s'achever". Cette définition suffit à identifier les erreurs de notre jeune Scrum Master; la vélocité est quelque chose qui se mesure, non quelque chose qui se décrete à l'avance; c'est une mesure qui s'exprime dans la même unité que les estimations, donc des points ou des hommes-jours mais en aucun cas un pourcentage. Le réflexe qui joue est le même que celui du physicien à qui on annoncerait une vitesse exprimée en mètres carrés: ce n'est pas la peine de vérifier le calcul, il faut d'abord rectifier une incompréhension théorique.

Nuançons quand même le propos: certains des termes utilisés pour décrire Scrum ou XP exigent plus qu'une définition brute, il faut comprendre comment les mettre en relation. J'affectione les simulations de projet comme outil pédagogique pour garantir que des termes comme vélocité ou itération sont bien compris.

Les pratiques, c'est ce dont on peut constater la mise en place sur le terrain, de façon visible. Par exemple, une heuristique que j'emploie fréquemment pour juger qu'équipe prend au sérieux l'approche Agile: les murs de la salle de travail sont-ils recouverts de tableaux blancs remplis, de grandes feuilles de papier chargés de Post-It, de documents divers relatifs au projet et mis à jours récemment? La présence de ces indices n'est évidemment pas une garantie de succès, mais elle met en évidence certaines pratiques communes parmi les équipes Agiles: utilisation d'un tableau de tâches par exemple.

Ou bien encore, je pourrais passer un peu de temps avec un développeur, et constater quelques différences visibles entre son travail et ce que j'ai vu faire ailleurs. Lorsqu'il programme, je le vois systématiquement se préoccuper de tests unitaires automatisés, qui se matérialisent par une "barre verte" ou "barre rouge" dans l'outil qui gère ces tests. Ou bien, je remarque qu'il ne travaille que rarement seul, mais le plus souvent avec un autre développeur assis au même bureau; il ne travaille pas en silence mais explique (sans trop lever la voix pour ne pas perturber d'autres binômes) le raisonnement derrière le code qu'il propose à son collègue.

Les compétences, c'est ce qu'on peut voir quand on examine de plus près certaines pratiques (mais pas toutes), ce sont celles parmi les pratiques qui amènent à distinguer des niveaux de performance. Telle équipe est meilleure que l'équipe voisine dans le domaine de la conception évolutive. Tel développeur est plus doué qu'un autre pour le refactoring, il l'applique de façon plus fluide, à une plus grande échelle, avec plus de rapidité.

Certaines pratiques ne sont pas nécessairement des compétences: d'un certain point de vue une réunion de type "stand-up" ou "daily Scrum", c'est simplement une réunion. On constate, ou non, que l'équipe se réunit une fois par jour à heure fixe pour échanger sur les progrès accomplis. Par contre on peut considérer que l'animation de cette réunion est une compétence. Si cette compétence est présente cela se traduit par une réunion courte et le sentiment (subjectif, certes) qu'elle a été utile. Si cette compétence fait défaut, la réunion peut s'éterniser et sembler contre-productive.

Attention, "animer un stand-up court" ne décrit pas une compétence! On préfèrera quelque chose comme: "telle personne est capable d'équilibrer les temps de parole lors d'une réunion, en encourageant les plus timides à contribuer et les plus extravertis à se limiter". Cette compétence s'appuie sur de l'observation (il faut avoir noté qui a parlé ou pas parlé) et sur de l'autorité (adopter le ton juste lorsqu'on demande à quelqu'un de rendre la parole: ni minauderie ni éclat de voix).

Conclusion: pour pouvoir obtenir les bénéfices d'une approche Agile, il me semble important d'avoir accès à une description approfondie et détaillée du contenu de cette approche, avec une attention particulière aux pratiques et aux compétences qui, sans doute parce qu'elles sont plus difficile à décrire finement, ont jusqu'à présent surtout fait l'objet d'une "tradition orale", d'un apprentissage par la transmission individuelle. Même si cette dernière garde son importance dans la culture Agile, elle ne peut que bénéficier d'un corpus écrit, si celui-ci est soigneusement réalisé et entretenu.

Dans une bonne bouteille, vous buvez l'étiquette?

Une question malicieuse pour un sujet très sérieux, puisque l'une de mes plus grandes inquiétudes est de voir notre profession se détourner d'idées qu'elles vient pourtant à peine de découvrir et qui, bien maîtrisées, lui font le plus grand bien.

Ce qui est important dans l'ensemble certes un peu hétéroclite de notions associées au terme "Agile", ce n'est évidemment pas le mot "Agile", de la même façon que ce qui nous procure du plaisir dans une bonne bouteille de vin, c'est (en principe) son contenu.

En principe? Oui, une des vertus de cette analogie, c'est de nous rappeler que trop souvent on se délecte de l'étiquette. On appelle "effet de halo" le biais cognitif qui nous fait trouver plus plaisant un produit lorsqu'on sait qu'il provient d'une "bonne" marque, alors même que si nous faisions l'essai à l'aveugle nous ne saurions pas distinguer une piquette d'un cru à la mode.

Je ne jetterai donc la pierre à personne, mais le fait est que nous courons un risque à trop parler des étiquettes: Agile, Lean, Scrum, XP... J'entends des choses parfaitement absurdes, par exemple "Lean est le successeur d'Agile".

C'est un contre-sens pour qui connaît le contenu qu'on désigne par le terme Agile: un ensemble de pratiques, certes pas toutes de la même origine, certes pas toutes aussi largement connues et pratiquées, mais dont statistiquement, en interrogeant un assez grand nombre de personnes faisant partie de la communauté depuis longtemps (cette appartenance pourrait se déterminer par un critère concret tel que la participation à des conférences), le recouvrement nous donnerait une idée assez précise.

Citons en vrac, et pour l'exercice: le développement par les tests (TDD), le refactoring, l'automatisation du build, l'intégration continue, la conception incrémentale, les User Stories, les tests de recette, les critères "Done", les Personas, le Story Mapping, le Planning Poker, les itérations timeboxées, les rétrospectives, le tableau des tâches, le libre choix des tâches, la réunion quotidienne ou "mélée", la programmation en binômes, les demandes d'aide explicites...

Parmi les "méthodes Agiles" (le mot méthode est mal choisi, mais ce sera le sujet d'un prochain billet) on peut effectivement recenser certaines dont les préconisations sont des sous-ensembles de cette longue liste: Scrum et XP notamment.

Si on se pose la question de savoir de quel mode de pensée sont issues les pratiques Agiles, alors oui, on retombe sur quelque chose qui a de nombreuses affinités avec le discours Lean. Pour autant, le recouvrement en termes de pratiques est relativement faible.

Or, soyons clair là-dessus, ce qui fait le succès ou non d'un projet, ce n'est pas le nom du discours dont on se revendique, l'attachement identitaire des membres de l'équipe: "nous sommes Agiles" ou "nous sommes Lean". Ce qui fait le succès d'un projet c'est ce que font les gens!

De ce point de vue, force est de constater que beaucoup d'équipes se proclament "Agiles" alors même qu'elles peinent à appliquer de façon compétente des pratiques aussi élémentaires que le refactoring, ou qu'elles révèlent lorsqu'on interroge les ingénieurs des contresens sur des notions de base comme la vélocité.

Une partie de ce déficit est à mettre sur le compte de la communauté Agile elle-même: il n'existe nulle part sur le Web un "Wikipedia de l'Agilité", une description systématique, détaillée, cohérente et mise à jour des pratiques désignées par le terme "Agile".

D'où le projet actuellement prioritaire de l'Institut Agile: mettre à la disposition des personnes intéressées par le sujet un "référentiel des compétences, pratiques, notions et principes" des approches Agiles. Qu'est-ce qui différentie une compétence d'une pratique, d'un principe, etc? C'est ce que j'aborderai dans le prochain billet...