De l'art de bricoler sa méthodologie
Par Olivier Azeau le 8 mai 2006, 21:02 - En français - Lien permanent
Je viens de lire un échange intéressant où Fabien Benoit s'interroge sur la mise en oeuvre effective de méthodologies opposées par des guerres plus ou moins religieuses et Aurélien Pelletier répond en faisant un tour d'horizon des pratiques actuelles et en concluant qu'il n'y a pas de méthodes idéale : tout est une question de dosage en fonction du contexte. Fabien acquiesce en faisant remarquer qu'il ne peut donc pas y avoir de méthode "prête à l'emploi" contrairement à ce qu'espèrent proposer divers vendeurs de solutions miracle.
Je me permets de venir ajouter mon grain de sel à la discussion en abondant dans le sens des conclusions déjà établies. Force est de constater que lorsque des personnes communiquent des retours d'expérience sur des méthodes récentes, c'est principalement pour en vendre une mise en oeuvre plus ou moins packagée (je n'ai rien contre la société mentionnée à travers le lien, c'est juste un exemple).
RUP, XP, Scrum et consorts sont devenus autant de mots-clef marketing qui servent aussi bien à des prestataires de services pour s'ouvrir de nouveaux marchés qu'à des entités internes aux sociétés pour mettre en exergue leur façon de travailler et dégager ainsi les budgets adéquats. "Nous faisons de la bonne qualité avec notre méthode eXtreme Programming. Si vous voulez que l'on vous fasse cette fonctionnalité X, il va falloir payer une paire de développeurs supplémentaire".
Peu de voix s'élèvent pour dire que, en fin de compte, mettre en place une méthode de développement qui fonctionne réellement, c'est avant tout une histoire de bricolage pragmatique qui pioche des idées ici ou là et les assemble en fonction du contexte et de la sensibilité des intervenants. Je voudrais donner ici un exemple d'un tel bricolage.
Je me permets de venir ajouter mon grain de sel à la discussion en abondant dans le sens des conclusions déjà établies. Force est de constater que lorsque des personnes communiquent des retours d'expérience sur des méthodes récentes, c'est principalement pour en vendre une mise en oeuvre plus ou moins packagée (je n'ai rien contre la société mentionnée à travers le lien, c'est juste un exemple).
RUP, XP, Scrum et consorts sont devenus autant de mots-clef marketing qui servent aussi bien à des prestataires de services pour s'ouvrir de nouveaux marchés qu'à des entités internes aux sociétés pour mettre en exergue leur façon de travailler et dégager ainsi les budgets adéquats. "Nous faisons de la bonne qualité avec notre méthode eXtreme Programming. Si vous voulez que l'on vous fasse cette fonctionnalité X, il va falloir payer une paire de développeurs supplémentaire".
Peu de voix s'élèvent pour dire que, en fin de compte, mettre en place une méthode de développement qui fonctionne réellement, c'est avant tout une histoire de bricolage pragmatique qui pioche des idées ici ou là et les assemble en fonction du contexte et de la sensibilité des intervenants. Je voudrais donner ici un exemple d'un tel bricolage.
Un schéma avait tout particulièrement retenu mon attention dans la description de XP par Ron Jeffries :
Ce schéma a la particularité de découper les pratiques de XP en plusieurs niveau. Grosso modo :
Une question que je me suis posée en voyant ce schéma est : peut-on mettre en oeuvre un cercle sans vraiment appliquer les autres. La logique de XP qui veut que les pratiques se compensent les unes les autres dit que non. Par exemple, mettre à jours le produit de manière très incrémentale en rajoutant les fonctionalités une à une (donc faire des "small releases") peut vite mener au chaos si aucune pratique de "refactoring" n'est là pour remettre de l'ordre dans l'architecture de l'application.
Cependant, plus ou moins consciemment (car je m'en suis rendu compte a posteriori), j'ai une fois repris un projet existant où je me suis vu appliquer des principes issus des méthodes agiles sur la gestion macroscopique du projet en ne touchant pas à la façon dont travaillaient les développeurs quand ils étaient face à leur code.
Imaginons un projet avec les caractéristiques suivantes :
Dans un tel cas de figure, on (en tout cas moi) est tout de suite tenté de résoudre le problème de visibilité sur les choix évolutifs en se référant aux méthodes agiles : "we have come to value responding to change over following a plan". En pratique, cela peut signifier :
Le processus ainsi décrit est donc un dosage entre agilité pour résoudre certains problème et classicisme pour conserver ce qui fonctionne déjà. Certaines pratiques de XP sont mises en avant : "Whole team", "Planning game" et "Small releases".
Cela fonctionne car les pratiques XP qui pourraient avoir besoin de garde-fous sont bien encadrées par le contexte. L'architecture étant stable, les besoins en refactoring sont très faibles. Les boucles de feedback ne sont pas pleinement utilisées car ce n'est pas un besoin essentiel. Les développeurs continuent leur schéma de développement classique car ils s'y sentent à l'aise.
J'ai l'impression que beaucoup de gens à qui on fait miroiter les mérites de l'agilité, principalement à travers eXtreme Programming partent dans l'idée d'implémenter entièrement la méthodologie, comme si c'était là le but principal. A mon avis, il ne faut surtout pas oublier qu'un des principes fondateurs de l'agilité c'est "Individuals and interactions over processes and tools". La bonne méthode c'est celle qui fait que les gens se sentent à l'aise et font du bon boulot, pas celle écrite dans les livres.
Je ne sais pas si ce que je raconte est utile pour quelqu'un mais, en ce qui me concerne, j'aimerais trouver plus de véritables retours d'expérience de méthodes de développement "bricolées sur mesure" à partir de principes issus des méthodes un peu plus formelles.
Ce schéma a la particularité de découper les pratiques de XP en plusieurs niveau. Grosso modo :
- le niveau extérieur contient les pratiques appliquées par l'ensemble de l'équipe, client compris
- le niveau intermédiaire contient les pratiques applicables aux développeurs en tant que groupe
- le niveau intérieur contient les pratiques relatives à un développeur individuel, ou une paire de développeurs
Une question que je me suis posée en voyant ce schéma est : peut-on mettre en oeuvre un cercle sans vraiment appliquer les autres. La logique de XP qui veut que les pratiques se compensent les unes les autres dit que non. Par exemple, mettre à jours le produit de manière très incrémentale en rajoutant les fonctionalités une à une (donc faire des "small releases") peut vite mener au chaos si aucune pratique de "refactoring" n'est là pour remettre de l'ordre dans l'architecture de l'application.
Cependant, plus ou moins consciemment (car je m'en suis rendu compte a posteriori), j'ai une fois repris un projet existant où je me suis vu appliquer des principes issus des méthodes agiles sur la gestion macroscopique du projet en ne touchant pas à la façon dont travaillaient les développeurs quand ils étaient face à leur code.
Imaginons un projet avec les caractéristiques suivantes :
- le produit a déjà une base installée. Les évolutions, livrées environ tous les 6 mois, apportent des fonctionnalités importantes mais sans jamais remettre en cause l'architecture générale ;
- l'équipe de développement nécessaire est relativement restreinte (moins de 3 développeurs) ;
- l'équipe actuelle est stable et les personnes se connaissent bien ;
- beaucoup d'inconnues sur les choix évolutifs font que personne n'est vraiment capable de prioritiser ces choix longtemps à l'avance ;
- une certaine gêne est présente chez les développeurs vis a vis du sponsoring du projet car, par le passé, on leur a plusieurs fois demandé de changer de cap à la dernière minute.
Dans un tel cas de figure, on (en tout cas moi) est tout de suite tenté de résoudre le problème de visibilité sur les choix évolutifs en se référant aux méthodes agiles : "we have come to value responding to change over following a plan". En pratique, cela peut signifier :
- identifier individuellement chaque demande d'évolution ou de correction ;
- demander systématiquement aux développeurs une cotation pour chaque demande ;
- mettre en place des itérations relativement courtes (par exemple 3 semaines) avec un système de "planning game" faisant participer plus activement les décideurs des évolutions ;
- mener l'itération en conservant un schéma classique conception-codage-tests ;
- formaliser une livraison interne au développement en fin d'itération pour valider les rajouts fonctionnels ;
- conserver la périodicité de livraison client relativement large (livraison à 6 mois pour des itérations de 3 semaines) lors de laquelle le produit est validé dans son ensemble;
Le processus ainsi décrit est donc un dosage entre agilité pour résoudre certains problème et classicisme pour conserver ce qui fonctionne déjà. Certaines pratiques de XP sont mises en avant : "Whole team", "Planning game" et "Small releases".
Cela fonctionne car les pratiques XP qui pourraient avoir besoin de garde-fous sont bien encadrées par le contexte. L'architecture étant stable, les besoins en refactoring sont très faibles. Les boucles de feedback ne sont pas pleinement utilisées car ce n'est pas un besoin essentiel. Les développeurs continuent leur schéma de développement classique car ils s'y sentent à l'aise.
J'ai l'impression que beaucoup de gens à qui on fait miroiter les mérites de l'agilité, principalement à travers eXtreme Programming partent dans l'idée d'implémenter entièrement la méthodologie, comme si c'était là le but principal. A mon avis, il ne faut surtout pas oublier qu'un des principes fondateurs de l'agilité c'est "Individuals and interactions over processes and tools". La bonne méthode c'est celle qui fait que les gens se sentent à l'aise et font du bon boulot, pas celle écrite dans les livres.
Je ne sais pas si ce que je raconte est utile pour quelqu'un mais, en ce qui me concerne, j'aimerais trouver plus de véritables retours d'expérience de méthodes de développement "bricolées sur mesure" à partir de principes issus des méthodes un peu plus formelles.
Commentaires