Critères de compatibilité avec l'agile (Mike Griffiths Juin 2007)

Transcription

1 Pourquoi ne pas utiliser systématiquement les méthodes agiles? Eh bien, même si cela peut vous choquer ou vous horrifier, peut-être qu'elles ne sont pas toujours la meilleure approche en toutes circonstances! Alors, comment pouvonsnous décider quand les utiliser? Il est tentant de penser que tous les projets doivent être gérés selon une démarche agile. Il est vrai que je suis convaincu que tous les projets bénéficieraient de l'encouragement à l'amélioration de la collaboration et de la communication spécifiques à l'approche agile. Néanmoins, la collaboration et la communication ne représentent que deux caractéristiques des projets agiles et nous devons prendre en considération des paramètres plus larges qui influencent le succès ou l'échec d'un projet. Mon hypothèse est que le résultat final que nous recherchons est un projet réussi avec des parties prenantes satisfaites. Il est donc préférable d'avoir un projet réussi et mené selon une démarche traditionnelle plutôt qu'un projet raté mené selon une démarche agile. Certains ne seront pas d'accord mais je les qualifierais de puristes plutôt que de pragmatiques. Les choix possibles sont A) l'utilisation d'un progiciel qui peut éventuellement exiger le développement d'un spécifique et son intégration, B) la conduite du projet selon une démarche traditionnelle (cycle en V en une seule passe) ou C) la conduite du projet selon une démarche agile. Alors, comment pouvons-nous identifier et évaluer les caractéristiques de la "forme" d'un projet? Il existe heureusement une multitude de recherches fructueuses sur le sujet et dont on peut tirer parti. Cet article décrit certains des outils les plus populaires et certains autres moins connus en termes d'estimation de la compatibilité d'un projet avec l'agile : 1. Le curseur 2. Les critères de compatibilité d'un projet selon DSDM 3. La criticité du projet et la taille de l'équipe selon Alistair Cockburn 4. Le radar de Boehm et Turner 5. Les critères agiles selon Dave Cohen 6. Les critères de compatibilité d'une organisation 7. La méthode du marteau Traduction de Fabrice Aimetti, le 05/01/2011 1/14

2 1. Le curseur Le curseur est un modèle simple que j'ai créé pour illustrer le fait que le choix d'une démarche agile ou traditionnelle n'est pas nécessairement binaire. Le modèle est conçu comme une vieille commande de contrôle du chauffage d'une voiture : curseur à gauche : pas d'agile du tout, curseur entre les deux : un mélange avec de l'agile, curseur à droite : à fond agile. Les caractéristiques qui tireront le curseur dans un sens ou l'autre sont représentées par des poids : Stabilité du projet Risque technique faible Inertie au changement Criticité du projet Projet incertain Réactivité du client Culture de l'innovation Colocalisation possible des équipes Certaines caractéristiques d'un projet telles que des "exigences non stabilisées" et des "utilisateurs qui demandent tout le temps de nouvelles choses" sont en faveur d'une démarche agile et tireront le curseur vers la droite. D'autres caractéristiques telles que "des exigences stabilisées" et "l'inertie au changement" rendront la justification d'une démarche agile plus problématique et seront plutôt en faveur d'une démarche plus traditionnelle. Les approches traditionnelle et agile peuvent être combinées avec succès sur des projets hybrides ou difficile à catégoriser. "Vous pouvez utiliser l'agile à fond de temps en temps et un peu d'agile tout le temps." Traduction de Fabrice Aimetti, le 05/01/2011 2/14

3 2. Les critères de compatibilité d'un projet selon DSDM J'ai eu la chance d'être impliqué dans la création de DSDM 1 en 1994 et je me suis donc rappelé les débuts de l'utilisation du Questionnaire sur les critères de compatibilité d'un projet. Il était alors assez primitif et a subsisté sous la forme d'une simple liste de questions auxquelles il fallait répondre par Oui ou par Non. L'idée de base est de vérifier si les caractéristiques du projet sont en faveur d'un développement agile, telles que : 1. Accord sur la philosophie agile avant de commencer à travailler : timeboxing, implication des utilisateurs, développement itératif, Accord sur la délégation du pouvoir de décision aux utilisateurs et développeurs embarquées dans l'équipe. 3. Engagement du management client pour assurer la disponibilité et la participation importante de certains utilisateurs finaux. 4. Livraison incrémentale : accord sur le fait que c'est acceptable et souhaitable. 5. Facilité d'accès des développeurs aux utilisateurs finaux et clients sur site. 6. Stabilité de l'équipe : conserver une équipe minimale pour maintenir la connaissance tacite plutôt que d'exiger de la documentation. 7. Compétences en développement de l'équipe : disposer d'une équipe qualifiée et qui communique. 8. Taille de l'équipe de développement : de petites équipes pour privilégier les discussions en face à face et minimiser les coûts de communication et de documentation. 9. Soutien actif des commerciaux : la confiance et la collaboration sont plus importants que la négociation d'un contrat. 10. Technologie utilisée pour le développement : permet la livraison incrémentale, le prototypage rapide et le refactoring. La présence ou l'absence de ces caractéristiques fournissent une très bonne indication sur la probable adhésion à l'application d'une démarche agile. Des réponses négatives ne signifieront pas automatiquement que l'agile ne fonctionnera pas, elles mettent plutôt en évidence les risques potentiels qui devront être gérés. Par exemple, si l'on répond "Non" sur "la disponibilité des utilisateurs", cela signifiera peut-être que nous avons un risque de faible disponibilité et qu'il faudra le traiter au démarrage du projet pour essayer de garantir cette disponibilité. Par contre si l'on répond "Non" à la plupart des questions, une alerte est levée quant à l'emploi d'une démarche agile. Avec de telles limitations, cela devient rédhibitoire pour le succès du projet. Vous pouvez télécharger une copie du Questionnaire sur les critères de compatibilité DSDM en passant par le lien ci-dessous. Répondre à ces questions peut vous fournir des informations précieuses sur l'emploi de tout type de méthodologie agile. Télécharger project_suitability_questionnaire.doc 1 DSDM : Dynamic Systems Development Method Traduction de Fabrice Aimetti, le 05/01/2011 3/14

4 3. La criticité du projet et la taille de l'équipe selon Alistair Cockburn Les méthodes Crystal créées par Alistair Cockburn sont basées sur la criticité du système et la taille de l'équipe. Alistair a divisé ses méthodes comme indiqué ci-dessous. En abscisse, nous trouvons la taille des équipes en commençant à partir de très petites équipes de 1 à 4 personnes pour aller vers des grands projets de plus de 500 personnes. En ordonnée, nous trouvons la criticité du système exprimée sous la forme des risques encourus. Si un jeu ou un traitement de texte se bloque alors nous perdons un peu de temps. Si un système de facturation tombe alors on peut subir des pertes financières substantielles. Nous pouvons voir que Crystal Clear est une méthodologie agile conçue pour de petites équipes gérant des projets dont la défaillance du système n'entraînerait que des pertes financières maîtrisées. La méthode Crystal Red, par contre, impose plus de rigueur et de contrôle et est destiné aux équipes de 50 à 100 personnes travaillant sur des systèmes dont la défaillance peut entraîner des pertes financières importantes. Prendre en compte la taille de l'équipe et la criticité du projet est un bon moyen d'évaluer la compatibilité du projet avec la démarche agile. Les méthodes agiles ont eu de bons résultats sur des projets mettant en jeu de grandes équipes voire même sur des systèmes dits très critiques, mais cela exige beaucoup plus de compétences et d'efforts. Elles sont beaucoup plus faciles à mettre en œuvre sur de petites applications non critiques. Traduction de Fabrice Aimetti, le 05/01/2011 4/14

5 4. Le radar de Boehm et Turner Dans leur livre "Balancing Agility and Discipline: A Guide for the Perplexed" (un très bon livre mais avec un mauvais titre puisque l'agile est discipliné), Barry Boehm et Richard Turner ont trouvé une manière assez sympatique pour représenter visuellement l'évaluation des caractéristiques d'un projet qui, selon eux, le rende compatible avec la démarche agile. L'idée est que le projet est évalué en fonction de cinq caractéristiques et les scores sont reportés sur le radar. Les scores proches du centre indiquent une bonne compatibilité avec la démarche agile, alors que les scores éloignés du centre indiquent une meilleure compatibilité avec l'approche traditionnelle. Les caractéristiques mesurées sont : Personnel : mesure la compétence des développeurs de l'équipe selon une échelle empruntée à Alistair Cockburn : Niveau 1 (débutant), Niveau 2 (intermédiaire) et Niveau 3 (expert). Pour que les projets agiles se passe bien, il est préférable d'avoir une faible proportion de développeurs débutants et une forte proportion de développeurs de niveaux intermédiaire et expert. Si votre équipe a un pourcentage plus élevé de débutants (et donc un faible pourcentage de développeurs plus expérimentés), alors peut-être qu'une approche plus traditionnelle (codage à partir des spécifications) serait plus facile. Dynamisme : c'est un terme qui évalue la probabilité des changements. Le projet est-il dynamique (soumis à des changements), quel est le pourcentage des exigences qui sont susceptibles de changer au cours du projet? Si 50% des exigences sont susceptibles de changer alors nous sommes très proche du centre du graphique dans la zone agile. Si seulement 1% des exigences sont susceptibles de changer alors nous sommes sur le bord extérieur du graphique dans la zone traditionnelle. Cela ne veut pas dire que vous ne pouvez pas utiliser une approche agile, mais peut-être (pour cette caractéristique tout au moins) que planifier le travail puis suivre le planning fonctionnera mieux sur ce projet. Culture (chaos vs ordre) : quel est le profil de l'organisation? Est-ce une organisation qui accueille facilement voire se nourrit du changement, ou est-ce une organisation reposant sur l'ordre et la tradition. Vendre l'agile dans un environnement très ordonné peut être difficile avec des idées Traduction de Fabrice Aimetti, le 05/01/2011 5/14

6 telles que les exigences émergentes, les équipes auto-organisées et le leadership-serviteur qui apparaissent contradictoires par rapport à la culture et les valeurs de l'organisation. Cela peut encore être réalisé en faisant appel à leur désir de réduire l'incertitude du projet. Les deux prochaines caractéristiques "Taille de l'équipe" et "Criticité" de Boehm et Turner sont en fait tirées des méthodes Crystal de Alistair Cockburn. Taille de l'équipe : les méthodes agiles sont plus faciles à mettre en place, à exécuter et à gérer avec de petites équipes. Cela ne veut pas dire que les grandes équipes agiles ne peuvent pas travailler correctement, mais que c'est beaucoup plus difficile à accomplir. Des équipes de moins de 10 personnes constituent une bonne dimension pour l'agile étant donné que ce nombre est plus facile à colocaliser, ils peuvent communiquer en face-à-face, ils peuvent gérer des connaissances informelles (tacites) par le biais des conversations et utiliser des systèmes de suivi très simples et visuels. Au fur et à mesure que la taille des équipes croît, conserver ces principes agiles requièrent des techniques supplémentaires pour dimensionner de manière efficace. Cela peut être fait, mais cela demande plus de travail et de compétence. En revanche, les structures hiérarchiques des projets traditionnels ont été faites pour gérer des équipes de grande dimension en se basant sur la prolifération naturelle des comités, de la documentation et des organisations matricielles. Criticité (la défaillance du système a pour conséquence la perte de...) : il s'agit de la caractéristique la plus controversée. Boehm et Turner se sont basés sur le modèle de Alistair Cockburn et ont affirmé que l'agile est plus approprié pour les applications légères où la défaillance du système conduit à une perte de confort (comme perdre du temps lorsqu'un jeu se bloque ou perdre ses modifications lorsque le traitement de texte se plante), mais moins appropriées pour des applications critiques. Je peux comprendre d'où cela vient, après avoir travaillé sur des projets militaires ; il y a toujours une traçabilité forte des tests par rapport aux exigences et des exigences par rapport aux spécifications qui peuvent être automatiquement vérifiées et dans les deux sens. Les frameworks de tests agiles récents peuvent fournir de telles fonctionnalités mais de nombreuses approches agiles ne prescrivent pas ce niveau de détail. Cependant, cela ne veut pas dire que cela ne peut pas être ajouté, et je recommande une approche itérative agile pour s'attaquer à l'architecture et tester des fonctionnalités significatives tôt et souvent sur des projets qui consistent à construire des applications critiques. Commencez par l'agile et ajouter les couches de vérification supplémentaires exigées par la criticité du système. Pour illustrer la façon dont le radar est utilisé, je montre l'exemple d'un projet de pharmacie en ligne que j'ai géré lorsque je travaillais chez Quadrus développement. Le projet consistait à développer une pharmacie en ligne pour vendre à bas prix des médicaments canadiens sur ordonnance (principalement) pour des clients américains. La vente de ces médicaments est un sujet controversé au Canada ainsi qu'aux États-Unis et par conséquent cette industrie est caractérisée par des changements rapides de la réglementation et une concurrence féroce. Nous avons donc été confrontés à une extrême volatilité des exigences avec des changements majeurs semaine après semaine. Nous avons utilisé des itérations très courtes (2 jours) et des livraisons hebdomadaires pour contrecarrer cette fréquence élevée des changements. Traduction de Fabrice Aimetti, le 05/01/2011 6/14

7 Comme le montre le diagramme, nous avions une équipe expérimentée de développeurs de niveaux 2 et 3 qui ont travaillé sur des exigences très "dynamiques" avec une culture du changement élevée, proche du chaos. La taille de l'équipe était petite (5 personnes), mais la criticité du système assez élevée avec un impact financier fort pour la pharmacie. L'approche a été très fructueuse et très agile. Ce qui contraste avec le projet suivant sur lequel j'ai travaillé lorsque j'étais chez IBM Global Services. C'était un système de messagerie militaire qui fonctionnait depuis déjà 5 ans lorsque j'ai rejoint l'équipe. Il y avait des niveaux de compétence assez variés, des exigences verrouillées parce que tout changement pouvait impacter de nombreux sous-traitants, et la culture était basée sur les spécifications et le contrôle. Le projet était énorme avec plus de 300 personnes provenant uniquement d'ibm et la criticité était élevée puisque des informations vitales pouvaient être Traduction de Fabrice Aimetti, le 05/01/2011 7/14

8 transmises. Certaines parties du projet aurait pu être séparées et menées sous forme de projets agiles, mais la prise d'initiative était difficile au sein de ce monstre monolithique. Réflexions sur le modèle de Boehm et Turner De temps en temps, je donne un cours de gestion de projet agile pour l'université de Calgary et l'un des exercices que nous faisons est d'essayer d'ajouter des axes supplémentaires au radar. En d'autres termes, de quels autres facteurs devez-vous tenir compte pour déterminer si le projet est ou non compatible avec une démarche agile. Une réponse fréquente est "l'effort de Tests" : si tester un incrément est coûteux en termes d'effort ou de temps alors vous n'avez probablement pas les moyens de le faire très souvent. Ou alors vous devez trouver d'autres moyens pour simuler les tests. Les constructeurs automobiles font des milliers d'essais de collision à partir d'une conception itérative du véhicule et en utilisant des simulations sur ordinateur plutôt que des tests sur des véhicules réels. Donc si le test est coûteux en temps ou en effort, nous devons également trouver un moyen de le rendre plus facile (via des bouchons et des outils de tests automatisés). Traduction de Fabrice Aimetti, le 05/01/2011 8/14

9 5. Les critères agiles selon Dave Cohen En 2004, Cohen, Lindvall et Costa ont publié une bonne introduction à l'agile dans "Advances in Computers". Ils ont identifié les critères suivants déterminants dans l'adoption d'une démarche agile : 1. La culture de l'organisation doit être favorable à la négociation. 2. Les personnes doivent se faire confiance. 3. Peu de personnes, mais très compétentes. 4. Les organisations doivent vivre avec les décisions prises par les développeurs. 5. Les organisations doivent avoir un environnement qui facilite la communication rapide entre les membres de l'équipe. Le point 4 peut sembler bizarre et vous pouvez même penser que c'est le métier, au final, qui doit diriger le développement. Toutefois, lorsque vous lisez l'article, on parle du fait qu'il est nécessaire de faire confiance aux développeurs compétents et de leur laisser prendre des décisions sur la conception plutôt que sur les fonctionnalités métiers. Il s'agit de bons critères et j'apprécie le fait que les facteurs organisationnels aient un poids plus important dans l'évaluation. Parce que c'est là que je ressens le plus d'influence ou de résistance. Nous pouvons examiner le projet dans son coin et penser qu'il s'agit d'un excellent candidat pour l'agile, mais si l'organisation a une culture différente ou des directives opposées, alors nous passons à côté d'une pièce importante du puzzle. Traduction de Fabrice Aimetti, le 05/01/2011 9/14

10 6. Les critères de compatibilité d'une organisation Le Consortium DSDM a publié, sous la forme d'un livre blanc, un questionnaire sur les critères de Compatibilité d'une Organisation. Ce questionnaire va de pair avec le Questionnaire sur les critères de compatibilité d'un Projet (vu précédemment). Malheureusement, le livre blanc n'a pas eu le même succès, ce qui est dommage car il fournit des indications utiles sur la façon dont une organisation doit se structurer lorsqu'elle adopte des pratiques agiles. Le questionnaire comprend 46 questions réparties dans les catégories suivantes. J'ai listé les catégories et reformulé l'essentiel des questions ci-dessous : 1. Utilisateurs : avons-nous les bons utilisateurs? savent-ils de quoi ils parlent? et peuvent-ils prendre des décisions? 2. Gestion des utilisateurs : comprennent-ils le développement itératif? vont-ils garantir la disponibilité des personnes? ont-ils confiance dans ces personnes et vont-ils leur déléguer la prise des décisions au nom du groupe? 3. Organisation : est-ce que la technologie informatique lui est familière? est-elle prête à accepter un contrat agile? 4. Culture : y a-t-il une culture d'ouverture? les gens sont-ils prêts à essayer de nouvelles approches? et une première solution réalisée à 80% est-elle acceptable? 5. Equipe informatique : connaît-elle suffisamment la démarche agile? peut-elle parler efficacement aux utilisateurs? quelle niveau de relation entretient-elle avec la communauté des utilisateurs? 6. Management informatique : comprend-il les méthodes agiles? sont-ils prêts à modifier leurs normes et standards en termes de gestion de projet? 7. Management de l'organisation : est-il procédurier? les parties prenantes seront-elles disponibles pour participer au projet? le métier est-il demandeur pour avoir des livraisons incrémentales? 8. Technique : y a-t-il un fort historique d'utilisation du cycle en V? et des outils de builds et de tests sont-ils disponibles pour appuyer l'environnement technique? Je n'ai pas vraiment fait le questionnaire; il offre un bon aperçu des probables risques liés à l'adoption d'une démarche agile et vous n'en aurez que pour 45 minutes environ. Vous pouvez télécharger une copie ici : Télécharger organizational_suitability_questionnaire.doc Une fois que vous aurez rempli le questionnaire, vous pourrez utiliser la feuille de calcul d'évaluation ci-jointe pour vous aider à interpréter les résultats. Télécharger osf_assessment_scoring_example.xls Traduction de Fabrice Aimetti, le 05/01/ /14

11 Dans le radar ci-dessus, on peut voir un exemple de réponse au questionnaire. Le graphique montre bien les niveaux de risque, plus le score est élevé, plus le risque est important : ici c'est le cas pour la Gestion des utilisateurs et la Culture où le risque est très élevé. A l'image des critères de compatibilité d'un projet, les scores élevés ne signifient pas automatiquement que vous ne pouvez pas utiliser une approche agile. Au contraire, ils identifient les zones à risque qui doivent être examinées, comprises et réduites. En apprendre plus sur ces zones à risque est une bonne chose parce que nous pouvons être proactif pour diminuer ces risques ("un homme averti en vaut deux"). Traduction de Fabrice Aimetti, le 05/01/ /14

12 7. La méthode du marteau : facteurs non liés au projet Ces facteurs organisationnels sont critiques, même si le projet est en théorie idéal pour la démarche agile. Si le management ou les autres parties prenantes sont contre cette approche, alors l'application de la démarche agile comporte un risque important. En outre, si le chef de projet croit que les méthodes agiles ne fonctionne tout simplement pas, alors je suis convaincu qu'il réussira à prouver qu'il a raison et qu'il échouera dans l'utilisation de la démarche agile. Si votre cœur n'y est pas, alors les obstacles du projet apparaîtront comme une justification de la faiblesse du processus, et non comme des défis à surmonter. C'est ce que j'appelle "Les préjugés sur la méthodologie" et je pense que c'est le facteur le plus important à évaluer. Si vous voulez, on pourrait appeler ça "Adhésion à la méthodologie", mais cela cache le côté inconscient du préjugé qui influence nos décisions inconsciemment. Par exemple, personnellement, je suis par nature pro-agile et j'emploierai les principes agiles sur différents types de projets sans grande variation. C'est juste mon approche, j'aime construire progressivement la collaboration et le consensus et j'ai une grande "tolérance aux fautes". Je visualise "Les préjugés sur la méthodologie" sous la forme du marteau que nous utilisons pour faire rentrer nos projets dans la méthode de notre choix. Si une équipe a un fort désir de réussir avec l'approche agile (ou une autre), elle va probablement trouver des moyens inventifs pour faire fonctionner la méthode. Nous pouvons utiliser des outils tels que le radar de Boehm et Turner afin de déterminer les caractéristiques idéales d'un projet agile, mais nous ne devons jamais sous-estimer nos préjugés et notre obstination qui feront que notre marteau pourra rendre les projets les plus improbables compatibles avec une démarche agile. Dans le schéma ci-dessus, le projet A semble un bon choix pour notre marteau Agile, sans trop de modification, cela devrait être un projet agile assez facilement. Il semble que le projet B puisse Traduction de Fabrice Aimetti, le 05/01/ /14

13 mieux être traité avec une approche traditionnelle. Le projet C est plus problématique, il inclut un composant progiciel et le reste pourrait être mené selon une démarche traditionnelle ou agile. Bienvenue dans le monde réel, les choses sont compliquées ; peut-être qu'une approche hybride est nécessaire ici avec la mise en œuvre du progiciel et le développement traités en parallèle. Le Projet D semble comporter une partie traditionnelle et une partie agile ; peut-être pouvons-nous diviser cela en deux sous-projets et les gérer de cette manière? Il s'agit d'une approche valable qui est souvent négligé. Sinon, nous pouvons utiliser notre marteau favori et taper dessus jusqu'à ce que nous nous convainquions nous-mêmes et les autres que le projet est compatible avec notre méthode préférée. Traduction de Fabrice Aimetti, le 05/01/ /14

14 Parmi tous ces critères de compatibilité, lesquels utiliser? Eh bien, ce ne serait pas très adaptatif ou agile d'imposer une approche unique ou un parcours d'utilisation unique des différents modèles. Au lieu de cela, je vous suggère de vous familiariser avec une variété d'entre eux, puis de sélectionner ceux que vous pensez les plus adaptés à votre environnement. Soyez tout de même bien conscient que la compatibilité théorique et la compatibilité pratique sont souvent très différentes. Apprenez à reconnaître la présence du marteau et apprenez à comprendre la façon dont il influe sur vos choix et donc sur votre réussite. Enfin, n'oubliez pas que ce ne sont que des outils et qu'ils ne remplaceront pas votre réflexion et votre dialogue avec les parties prenantes du projet. Plutôt que de les utiliser à part, utilisez-les pour démarrer des conversations sur la compatibilité avec une démarche agile et bâtissez un consensus autour de la méthode permettant de faire le bon choix.. Traduction de Fabrice Aimetti, le 05/01/ /14