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.