SlideShare une entreprise Scribd logo
Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
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 pouvons-
nous 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
Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
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
Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
2. Les critères de compatibilité d'un projet selon DSDM
J'ai eu la chance d'être impliqué dans la création de DSDM1
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, ...
2. 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
Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
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
Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
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
Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
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
Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
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
Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
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
Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
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
Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
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/2011 10/14
Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
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/2011 11/14
Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
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/2011 12/14
Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
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/2011 13/14
Critères de compatibilité avec l'Agile
(Mike Griffiths – Juin 2007)
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/2011 14/14

Contenu connexe

Tendances

Entre le marteau et l'enclume de l'agilité, le manager - conférence Agile Lyo...
Entre le marteau et l'enclume de l'agilité, le manager - conférence Agile Lyo...Entre le marteau et l'enclume de l'agilité, le manager - conférence Agile Lyo...
Entre le marteau et l'enclume de l'agilité, le manager - conférence Agile Lyo...
Damien Thouvenin
 
Agile project-selection-fr
Agile project-selection-frAgile project-selection-fr
Agile project-selection-fr
Fabrice Aimetti
 
Méthodes agiles
Méthodes agilesMéthodes agiles
Méthodes agiles
Mohammed Amine Mostefai
 
Capital humain, facteur de réussite des projets
Capital humain, facteur de réussite des projetsCapital humain, facteur de réussite des projets
Capital humain, facteur de réussite des projets
Fabrice Thomas
 
CONF. 204 - Conditions et mise en œuvre des bénéfices d’un projet Agile
CONF. 204 - Conditions et mise en œuvre des bénéfices d’un projet AgileCONF. 204 - Conditions et mise en œuvre des bénéfices d’un projet Agile
CONF. 204 - Conditions et mise en œuvre des bénéfices d’un projet AgilePMI-Montréal
 
La chaîne critique - Osez terminer tous vos projets à l'heure !
La chaîne critique - Osez terminer tous vos projets à l'heure !La chaîne critique - Osez terminer tous vos projets à l'heure !
La chaîne critique - Osez terminer tous vos projets à l'heure !
Marseille Innovation
 
Feeback scrumday2015
Feeback scrumday2015Feeback scrumday2015
Feeback scrumday2015
SAGNON Joel
 
Les MéThodes Agiles
Les MéThodes AgilesLes MéThodes Agiles
Les MéThodes Agilesguesta206aa87
 
Parlons Agilité !
Parlons Agilité !Parlons Agilité !
Le Projet Borealis : Quelques pratiques Scandinaves en gestion de projet
Le Projet Borealis : Quelques pratiques Scandinaves en gestion de projetLe Projet Borealis : Quelques pratiques Scandinaves en gestion de projet
Le Projet Borealis : Quelques pratiques Scandinaves en gestion de projet
PMI-Montréal
 
Guide du chef de projet
Guide du chef de projetGuide du chef de projet
Guide du chef de projet
Fabrice Thomas
 
CONF. 304 - La gestion de projets dans la chaine d’approvisionnement moderne ...
CONF. 304 - La gestion de projets dans la chaine d’approvisionnement moderne ...CONF. 304 - La gestion de projets dans la chaine d’approvisionnement moderne ...
CONF. 304 - La gestion de projets dans la chaine d’approvisionnement moderne ...
PMI-Montréal
 
Faire preuve d'agilité dans son organisation
Faire preuve d'agilité dans son organisation Faire preuve d'agilité dans son organisation
Faire preuve d'agilité dans son organisation
Camille Coste
 
Méthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XPMéthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XP
Youness Boukouchi
 
Comment livrer plus vite?
Comment livrer plus vite?Comment livrer plus vite?
Comment livrer plus vite?
Agile Montréal
 
CONF. 303 - Une immersion dans la transition Agile de Promutuel
CONF. 303 - Une immersion dans la transition Agile de PromutuelCONF. 303 - Une immersion dans la transition Agile de Promutuel
CONF. 303 - Une immersion dans la transition Agile de PromutuelPMI-Montréal
 
Comment devenir un chef de projet efficace
Comment devenir  un chef de projet efficaceComment devenir  un chef de projet efficace
Comment devenir un chef de projet efficace
nodesway
 
Comment devenir chef de projet
Comment devenir chef de projetComment devenir chef de projet
Comment devenir chef de projet
nodesway
 

Tendances (20)

Entre le marteau et l'enclume de l'agilité, le manager - conférence Agile Lyo...
Entre le marteau et l'enclume de l'agilité, le manager - conférence Agile Lyo...Entre le marteau et l'enclume de l'agilité, le manager - conférence Agile Lyo...
Entre le marteau et l'enclume de l'agilité, le manager - conférence Agile Lyo...
 
Agile project-selection-fr
Agile project-selection-frAgile project-selection-fr
Agile project-selection-fr
 
Méthodes agiles
Méthodes agilesMéthodes agiles
Méthodes agiles
 
Capital humain, facteur de réussite des projets
Capital humain, facteur de réussite des projetsCapital humain, facteur de réussite des projets
Capital humain, facteur de réussite des projets
 
CONF. 204 - Conditions et mise en œuvre des bénéfices d’un projet Agile
CONF. 204 - Conditions et mise en œuvre des bénéfices d’un projet AgileCONF. 204 - Conditions et mise en œuvre des bénéfices d’un projet Agile
CONF. 204 - Conditions et mise en œuvre des bénéfices d’un projet Agile
 
La chaîne critique - Osez terminer tous vos projets à l'heure !
La chaîne critique - Osez terminer tous vos projets à l'heure !La chaîne critique - Osez terminer tous vos projets à l'heure !
La chaîne critique - Osez terminer tous vos projets à l'heure !
 
Feeback scrumday2015
Feeback scrumday2015Feeback scrumday2015
Feeback scrumday2015
 
Les MéThodes Agiles
Les MéThodes AgilesLes MéThodes Agiles
Les MéThodes Agiles
 
Parlons Agilité !
Parlons Agilité !Parlons Agilité !
Parlons Agilité !
 
Le Projet Borealis : Quelques pratiques Scandinaves en gestion de projet
Le Projet Borealis : Quelques pratiques Scandinaves en gestion de projetLe Projet Borealis : Quelques pratiques Scandinaves en gestion de projet
Le Projet Borealis : Quelques pratiques Scandinaves en gestion de projet
 
Guide du chef de projet
Guide du chef de projetGuide du chef de projet
Guide du chef de projet
 
CONF. 304 - La gestion de projets dans la chaine d’approvisionnement moderne ...
CONF. 304 - La gestion de projets dans la chaine d’approvisionnement moderne ...CONF. 304 - La gestion de projets dans la chaine d’approvisionnement moderne ...
CONF. 304 - La gestion de projets dans la chaine d’approvisionnement moderne ...
 
Faire preuve d'agilité dans son organisation
Faire preuve d'agilité dans son organisation Faire preuve d'agilité dans son organisation
Faire preuve d'agilité dans son organisation
 
Méthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XPMéthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XP
 
Comment livrer plus vite?
Comment livrer plus vite?Comment livrer plus vite?
Comment livrer plus vite?
 
CONF. 303 - Une immersion dans la transition Agile de Promutuel
CONF. 303 - Une immersion dans la transition Agile de PromutuelCONF. 303 - Une immersion dans la transition Agile de Promutuel
CONF. 303 - Une immersion dans la transition Agile de Promutuel
 
Etude_V4_18sept15b (1)
Etude_V4_18sept15b (1)Etude_V4_18sept15b (1)
Etude_V4_18sept15b (1)
 
Livre Blanc Sauvetage de projets
Livre Blanc Sauvetage de projetsLivre Blanc Sauvetage de projets
Livre Blanc Sauvetage de projets
 
Comment devenir un chef de projet efficace
Comment devenir  un chef de projet efficaceComment devenir  un chef de projet efficace
Comment devenir un chef de projet efficace
 
Comment devenir chef de projet
Comment devenir chef de projetComment devenir chef de projet
Comment devenir chef de projet
 

En vedette

Sitzung 10
Sitzung 10Sitzung 10
Sitzung 10scuy
 
Motivation durch Faszination!
Motivation durch Faszination!Motivation durch Faszination!
Motivation durch Faszination!
comvation
 
Notre classe
Notre classeNotre classe
Notre classe
School
 
Présentation. Je suis comme ça 1º "BD"
Présentation. Je suis comme ça 1º "BD"Présentation. Je suis comme ça 1º "BD"
Présentation. Je suis comme ça 1º "BD"
School
 
Website
WebsiteWebsite
Tecnología y educación
Tecnología y educaciónTecnología y educación
Tecnología y educación
Cinthia Lopez
 
Klare Terminologie durch Finalyser TERM CHECK und UniTerm
Klare Terminologie durch Finalyser TERM CHECK und UniTermKlare Terminologie durch Finalyser TERM CHECK und UniTerm
Klare Terminologie durch Finalyser TERM CHECK und UniTerm
acolada_gmbh
 
Kavaliersdelikte
KavaliersdelikteKavaliersdelikte
Recette brownies. danny et gabriel
Recette brownies. danny et gabrielRecette brownies. danny et gabriel
Recette brownies. danny et gabriel
School
 
Brochure Ecole De Langue Italienne 2011
Brochure Ecole De Langue Italienne 2011Brochure Ecole De Langue Italienne 2011
Brochure Ecole De Langue Italienne 2011
Piccola Università Italiana
 
Paragraph 89 hr. mück
Paragraph 89 hr. mückParagraph 89 hr. mück
Paragraph 89 hr. mückheilholz
 
Deutsch nur deutsch
Deutsch nur deutschDeutsch nur deutsch
Deutsch nur deutsch
loshad
 
La peche aux chiffres # 2
La peche aux chiffres # 2La peche aux chiffres # 2
La peche aux chiffres # 2
Jocelyn Prud'homme
 
ALGUNAS ESCULTURAS DE JOAN MIRÓ
ALGUNAS ESCULTURAS DE JOAN MIRÓALGUNAS ESCULTURAS DE JOAN MIRÓ
ALGUNAS ESCULTURAS DE JOAN MIRÓ
Ignacio Beiro
 
Sarah Palin : quand la politique change de sexe
Sarah Palin :  quand la politique change de sexeSarah Palin :  quand la politique change de sexe
Sarah Palin : quand la politique change de sexe
Newday
 

En vedette (20)

Sitzung 10
Sitzung 10Sitzung 10
Sitzung 10
 
Motivation durch Faszination!
Motivation durch Faszination!Motivation durch Faszination!
Motivation durch Faszination!
 
Car accidents no comment
Car accidents no commentCar accidents no comment
Car accidents no comment
 
Notre classe
Notre classeNotre classe
Notre classe
 
Présentation. Je suis comme ça 1º "BD"
Présentation. Je suis comme ça 1º "BD"Présentation. Je suis comme ça 1º "BD"
Présentation. Je suis comme ça 1º "BD"
 
Website
WebsiteWebsite
Website
 
Tecnología y educación
Tecnología y educaciónTecnología y educación
Tecnología y educación
 
Klare Terminologie durch Finalyser TERM CHECK und UniTerm
Klare Terminologie durch Finalyser TERM CHECK und UniTermKlare Terminologie durch Finalyser TERM CHECK und UniTerm
Klare Terminologie durch Finalyser TERM CHECK und UniTerm
 
Kavaliersdelikte
KavaliersdelikteKavaliersdelikte
Kavaliersdelikte
 
9
99
9
 
Recette brownies. danny et gabriel
Recette brownies. danny et gabrielRecette brownies. danny et gabriel
Recette brownies. danny et gabriel
 
Les 07 2
Les 07 2Les 07 2
Les 07 2
 
Brochure Ecole De Langue Italienne 2011
Brochure Ecole De Langue Italienne 2011Brochure Ecole De Langue Italienne 2011
Brochure Ecole De Langue Italienne 2011
 
Les 13 3
Les 13 3Les 13 3
Les 13 3
 
Moslem
MoslemMoslem
Moslem
 
Paragraph 89 hr. mück
Paragraph 89 hr. mückParagraph 89 hr. mück
Paragraph 89 hr. mück
 
Deutsch nur deutsch
Deutsch nur deutschDeutsch nur deutsch
Deutsch nur deutsch
 
La peche aux chiffres # 2
La peche aux chiffres # 2La peche aux chiffres # 2
La peche aux chiffres # 2
 
ALGUNAS ESCULTURAS DE JOAN MIRÓ
ALGUNAS ESCULTURAS DE JOAN MIRÓALGUNAS ESCULTURAS DE JOAN MIRÓ
ALGUNAS ESCULTURAS DE JOAN MIRÓ
 
Sarah Palin : quand la politique change de sexe
Sarah Palin :  quand la politique change de sexeSarah Palin :  quand la politique change de sexe
Sarah Palin : quand la politique change de sexe
 

Similaire à Critères de compatibilité avec l'Agile

Agile expliqué aux managers
Agile expliqué aux managersAgile expliqué aux managers
Agile expliqué aux managers
Pyxis Technologies
 
Agilite Scrum
Agilite Scrum Agilite Scrum
Agilite Scrum
Skander Hamza
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
JEAN-GUILLAUME DUJARDIN
 
Impacts de l'adoption de Scrum
Impacts de l'adoption de ScrumImpacts de l'adoption de Scrum
Impacts de l'adoption de Scrum
Pyxis Technologies
 
Agile du point de vue d'un PMP
Agile du point de vue d'un PMPAgile du point de vue d'un PMP
Agile du point de vue d'un PMP
Pyxis Technologies
 
Agile du point de vue d'un PMP
Agile du point de vue d'un PMPAgile du point de vue d'un PMP
Agile du point de vue d'un PMP
guestaaee88d
 
Les différents méthodes d’évolution du projet.pptx
Les différents méthodes d’évolution du projet.pptxLes différents méthodes d’évolution du projet.pptx
Les différents méthodes d’évolution du projet.pptx
taiebamin1
 
Les différents méthodes d’évolution du projet.pptx
Les différents méthodes d’évolution du projet.pptxLes différents méthodes d’évolution du projet.pptx
Les différents méthodes d’évolution du projet.pptx
taiebamin1
 
L'agilité pour gérer la complexité en TI
L'agilité pour gérer la complexité en TIL'agilité pour gérer la complexité en TI
L'agilité pour gérer la complexité en TI
Etienne Laverdière
 
Matinée PMI : L’Agilité pour gérer la complexité en TI
Matinée PMI : L’Agilité pour gérer la complexité en TIMatinée PMI : L’Agilité pour gérer la complexité en TI
Matinée PMI : L’Agilité pour gérer la complexité en TI
PMI-Montréal
 
Ddj Architecture & Design The Distributed Agile Team
Ddj   Architecture &  Design   The Distributed Agile TeamDdj   Architecture &  Design   The Distributed Agile Team
Ddj Architecture & Design The Distributed Agile Team
Emmanuel Hugonnet
 
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Pyxis Technologies
 
Méthodes agile
Méthodes agileMéthodes agile
Méthodes agile
ISSAE Cnam Liban
 
lean development
lean developmentlean development
lean development
Rima Jamli Faidi
 
Tableau Drive, Une méthodologie innovante pour les déploiements en entreprise
Tableau Drive, Une méthodologie innovante pour les déploiements en entrepriseTableau Drive, Une méthodologie innovante pour les déploiements en entreprise
Tableau Drive, Une méthodologie innovante pour les déploiements en entreprise
Tableau Software
 
Le Digital Lab chez Kiabi - version 2024
Le Digital Lab chez Kiabi  - version 2024Le Digital Lab chez Kiabi  - version 2024
Le Digital Lab chez Kiabi - version 2024
Julien Roynette
 
La gestion de projet agile
La gestion de projet agileLa gestion de projet agile
La gestion de projet agile
Eugène ZENGOMONA
 
Adoption de l'Agilité : principes et défis
Adoption de l'Agilité : principes et défisAdoption de l'Agilité : principes et défis
Adoption de l'Agilité : principes et défis
Pyxis Technologies
 
Agil organisationnelle dg_sept_2018
Agil organisationnelle dg_sept_2018Agil organisationnelle dg_sept_2018
Agil organisationnelle dg_sept_2018
Daniel Gagnon PMP,ACP,CDAC,CKP,SPS,PSPO,PSD
 
Aborder la transition vers l'agilité
Aborder la transition vers l'agilitéAborder la transition vers l'agilité
Aborder la transition vers l'agilité
Christophe Addinquy
 

Similaire à Critères de compatibilité avec l'Agile (20)

Agile expliqué aux managers
Agile expliqué aux managersAgile expliqué aux managers
Agile expliqué aux managers
 
Agilite Scrum
Agilite Scrum Agilite Scrum
Agilite Scrum
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
 
Impacts de l'adoption de Scrum
Impacts de l'adoption de ScrumImpacts de l'adoption de Scrum
Impacts de l'adoption de Scrum
 
Agile du point de vue d'un PMP
Agile du point de vue d'un PMPAgile du point de vue d'un PMP
Agile du point de vue d'un PMP
 
Agile du point de vue d'un PMP
Agile du point de vue d'un PMPAgile du point de vue d'un PMP
Agile du point de vue d'un PMP
 
Les différents méthodes d’évolution du projet.pptx
Les différents méthodes d’évolution du projet.pptxLes différents méthodes d’évolution du projet.pptx
Les différents méthodes d’évolution du projet.pptx
 
Les différents méthodes d’évolution du projet.pptx
Les différents méthodes d’évolution du projet.pptxLes différents méthodes d’évolution du projet.pptx
Les différents méthodes d’évolution du projet.pptx
 
L'agilité pour gérer la complexité en TI
L'agilité pour gérer la complexité en TIL'agilité pour gérer la complexité en TI
L'agilité pour gérer la complexité en TI
 
Matinée PMI : L’Agilité pour gérer la complexité en TI
Matinée PMI : L’Agilité pour gérer la complexité en TIMatinée PMI : L’Agilité pour gérer la complexité en TI
Matinée PMI : L’Agilité pour gérer la complexité en TI
 
Ddj Architecture & Design The Distributed Agile Team
Ddj   Architecture &  Design   The Distributed Agile TeamDdj   Architecture &  Design   The Distributed Agile Team
Ddj Architecture & Design The Distributed Agile Team
 
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
 
Méthodes agile
Méthodes agileMéthodes agile
Méthodes agile
 
lean development
lean developmentlean development
lean development
 
Tableau Drive, Une méthodologie innovante pour les déploiements en entreprise
Tableau Drive, Une méthodologie innovante pour les déploiements en entrepriseTableau Drive, Une méthodologie innovante pour les déploiements en entreprise
Tableau Drive, Une méthodologie innovante pour les déploiements en entreprise
 
Le Digital Lab chez Kiabi - version 2024
Le Digital Lab chez Kiabi  - version 2024Le Digital Lab chez Kiabi  - version 2024
Le Digital Lab chez Kiabi - version 2024
 
La gestion de projet agile
La gestion de projet agileLa gestion de projet agile
La gestion de projet agile
 
Adoption de l'Agilité : principes et défis
Adoption de l'Agilité : principes et défisAdoption de l'Agilité : principes et défis
Adoption de l'Agilité : principes et défis
 
Agil organisationnelle dg_sept_2018
Agil organisationnelle dg_sept_2018Agil organisationnelle dg_sept_2018
Agil organisationnelle dg_sept_2018
 
Aborder la transition vers l'agilité
Aborder la transition vers l'agilitéAborder la transition vers l'agilité
Aborder la transition vers l'agilité
 

Plus de Fabrice Aimetti

Guide Comment faire du Product Discovery ?
Guide Comment faire du Product Discovery ?Guide Comment faire du Product Discovery ?
Guide Comment faire du Product Discovery ?
Fabrice Aimetti
 
8 different ways to organize your product backlog_FR.pdf
8 different ways to organize your product backlog_FR.pdf8 different ways to organize your product backlog_FR.pdf
8 different ways to organize your product backlog_FR.pdf
Fabrice Aimetti
 
Du 7-eyed model au 10-eyed model pour la supervision
Du 7-eyed model au 10-eyed model pour la supervisionDu 7-eyed model au 10-eyed model pour la supervision
Du 7-eyed model au 10-eyed model pour la supervision
Fabrice Aimetti
 
Dites "NON" en tant que Product Manager !
Dites "NON" en tant que Product Manager !Dites "NON" en tant que Product Manager !
Dites "NON" en tant que Product Manager !
Fabrice Aimetti
 
Contrat relatif au Programme de Mentorat
Contrat relatif au Programme de MentoratContrat relatif au Programme de Mentorat
Contrat relatif au Programme de Mentorat
Fabrice Aimetti
 
L'aide-mémoire du Mentorat / Mentoring_Cheat_Sheets
L'aide-mémoire du Mentorat / Mentoring_Cheat_SheetsL'aide-mémoire du Mentorat / Mentoring_Cheat_Sheets
L'aide-mémoire du Mentorat / Mentoring_Cheat_Sheets
Fabrice Aimetti
 
L'aide-mémoire du Mentoré / Mentee Cheat Sheet
L'aide-mémoire du Mentoré / Mentee Cheat SheetL'aide-mémoire du Mentoré / Mentee Cheat Sheet
L'aide-mémoire du Mentoré / Mentee Cheat Sheet
Fabrice Aimetti
 
Groupe de Balint
Groupe de BalintGroupe de Balint
Groupe de Balint
Fabrice Aimetti
 
La fabrique narrative marcela polanco
La fabrique narrative marcela polancoLa fabrique narrative marcela polanco
La fabrique narrative marcela polanco
Fabrice Aimetti
 
Beata Jardin de vie (Rwanda)
Beata Jardin de vie (Rwanda)Beata Jardin de vie (Rwanda)
Beata Jardin de vie (Rwanda)
Fabrice Aimetti
 
Bibliographie narrative
Bibliographie narrativeBibliographie narrative
Bibliographie narrative
Fabrice Aimetti
 
Arrêtez de promettre des miracles
Arrêtez de promettre des miraclesArrêtez de promettre des miracles
Arrêtez de promettre des miracles
Fabrice Aimetti
 
20191126 conf-au-dela-de-la-prison
20191126 conf-au-dela-de-la-prison20191126 conf-au-dela-de-la-prison
20191126 conf-au-dela-de-la-prison
Fabrice Aimetti
 
20190627 intro-clean-language slideshare
20190627 intro-clean-language slideshare20190627 intro-clean-language slideshare
20190627 intro-clean-language slideshare
Fabrice Aimetti
 
Agile self assessment card game by Ben Linders
Agile self assessment card game by Ben LindersAgile self assessment card game by Ben Linders
Agile self assessment card game by Ben Linders
Fabrice Aimetti
 
Les 4 étapes du processus de la CNV
Les 4 étapes du processus de la CNVLes 4 étapes du processus de la CNV
Les 4 étapes du processus de la CNV
Fabrice Aimetti
 
Le jeu du prénom en mode multitâche
Le jeu du prénom en mode multitâcheLe jeu du prénom en mode multitâche
Le jeu du prénom en mode multitâche
Fabrice Aimetti
 
Xplane fr
Xplane frXplane fr
Xplane fr
Fabrice Aimetti
 
Twenty ways to_split_fr
Twenty ways to_split_frTwenty ways to_split_fr
Twenty ways to_split_fr
Fabrice Aimetti
 
Schlitz mapping changebattlefield_fr
Schlitz mapping changebattlefield_frSchlitz mapping changebattlefield_fr
Schlitz mapping changebattlefield_fr
Fabrice Aimetti
 

Plus de Fabrice Aimetti (20)

Guide Comment faire du Product Discovery ?
Guide Comment faire du Product Discovery ?Guide Comment faire du Product Discovery ?
Guide Comment faire du Product Discovery ?
 
8 different ways to organize your product backlog_FR.pdf
8 different ways to organize your product backlog_FR.pdf8 different ways to organize your product backlog_FR.pdf
8 different ways to organize your product backlog_FR.pdf
 
Du 7-eyed model au 10-eyed model pour la supervision
Du 7-eyed model au 10-eyed model pour la supervisionDu 7-eyed model au 10-eyed model pour la supervision
Du 7-eyed model au 10-eyed model pour la supervision
 
Dites "NON" en tant que Product Manager !
Dites "NON" en tant que Product Manager !Dites "NON" en tant que Product Manager !
Dites "NON" en tant que Product Manager !
 
Contrat relatif au Programme de Mentorat
Contrat relatif au Programme de MentoratContrat relatif au Programme de Mentorat
Contrat relatif au Programme de Mentorat
 
L'aide-mémoire du Mentorat / Mentoring_Cheat_Sheets
L'aide-mémoire du Mentorat / Mentoring_Cheat_SheetsL'aide-mémoire du Mentorat / Mentoring_Cheat_Sheets
L'aide-mémoire du Mentorat / Mentoring_Cheat_Sheets
 
L'aide-mémoire du Mentoré / Mentee Cheat Sheet
L'aide-mémoire du Mentoré / Mentee Cheat SheetL'aide-mémoire du Mentoré / Mentee Cheat Sheet
L'aide-mémoire du Mentoré / Mentee Cheat Sheet
 
Groupe de Balint
Groupe de BalintGroupe de Balint
Groupe de Balint
 
La fabrique narrative marcela polanco
La fabrique narrative marcela polancoLa fabrique narrative marcela polanco
La fabrique narrative marcela polanco
 
Beata Jardin de vie (Rwanda)
Beata Jardin de vie (Rwanda)Beata Jardin de vie (Rwanda)
Beata Jardin de vie (Rwanda)
 
Bibliographie narrative
Bibliographie narrativeBibliographie narrative
Bibliographie narrative
 
Arrêtez de promettre des miracles
Arrêtez de promettre des miraclesArrêtez de promettre des miracles
Arrêtez de promettre des miracles
 
20191126 conf-au-dela-de-la-prison
20191126 conf-au-dela-de-la-prison20191126 conf-au-dela-de-la-prison
20191126 conf-au-dela-de-la-prison
 
20190627 intro-clean-language slideshare
20190627 intro-clean-language slideshare20190627 intro-clean-language slideshare
20190627 intro-clean-language slideshare
 
Agile self assessment card game by Ben Linders
Agile self assessment card game by Ben LindersAgile self assessment card game by Ben Linders
Agile self assessment card game by Ben Linders
 
Les 4 étapes du processus de la CNV
Les 4 étapes du processus de la CNVLes 4 étapes du processus de la CNV
Les 4 étapes du processus de la CNV
 
Le jeu du prénom en mode multitâche
Le jeu du prénom en mode multitâcheLe jeu du prénom en mode multitâche
Le jeu du prénom en mode multitâche
 
Xplane fr
Xplane frXplane fr
Xplane fr
 
Twenty ways to_split_fr
Twenty ways to_split_frTwenty ways to_split_fr
Twenty ways to_split_fr
 
Schlitz mapping changebattlefield_fr
Schlitz mapping changebattlefield_frSchlitz mapping changebattlefield_fr
Schlitz mapping changebattlefield_fr
 

Dernier

BeeBOP diaporama webinaire : Et si l’IA permettait de compléter l’observatio...
BeeBOP diaporama webinaire : Et si l’IA permettait de compléter l’observatio...BeeBOP diaporama webinaire : Et si l’IA permettait de compléter l’observatio...
BeeBOP diaporama webinaire : Et si l’IA permettait de compléter l’observatio...
Institut de l'Elevage - Idele
 
Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...
Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...
Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...
Institut de l'Elevage - Idele
 
pdfcoffee.com_polycopie-de-cours-ppt-lge604-20012-bf-pdf-free.pdf
pdfcoffee.com_polycopie-de-cours-ppt-lge604-20012-bf-pdf-free.pdfpdfcoffee.com_polycopie-de-cours-ppt-lge604-20012-bf-pdf-free.pdf
pdfcoffee.com_polycopie-de-cours-ppt-lge604-20012-bf-pdf-free.pdf
Elisée Ndjabu
 
electronique de puissance Electronique-de-puissance-cours-N°5.pdf
electronique de puissance Electronique-de-puissance-cours-N°5.pdfelectronique de puissance Electronique-de-puissance-cours-N°5.pdf
electronique de puissance Electronique-de-puissance-cours-N°5.pdf
Elisée Ndjabu
 
Leviers d’adaptation au changement climatique, qualité du lait et des produit...
Leviers d’adaptation au changement climatique, qualité du lait et des produit...Leviers d’adaptation au changement climatique, qualité du lait et des produit...
Leviers d’adaptation au changement climatique, qualité du lait et des produit...
Institut de l'Elevage - Idele
 
RAPPORT DE STAGE sur CHANTIER BTP (by BR Engineering ) (1) (1).pdf
RAPPORT DE STAGE  sur CHANTIER  BTP (by BR Engineering ) (1) (1).pdfRAPPORT DE STAGE  sur CHANTIER  BTP (by BR Engineering ) (1) (1).pdf
RAPPORT DE STAGE sur CHANTIER BTP (by BR Engineering ) (1) (1).pdf
fatima413951
 
COUPROD Une méthode nationale commune à l’ensemble des filières herbivores
COUPROD Une méthode nationale commune à l’ensemble des filières herbivoresCOUPROD Une méthode nationale commune à l’ensemble des filières herbivores
COUPROD Une méthode nationale commune à l’ensemble des filières herbivores
Institut de l'Elevage - Idele
 
Accompagner les porteurs de projets en transformation fermière
Accompagner les porteurs de projets en transformation fermièreAccompagner les porteurs de projets en transformation fermière
Accompagner les porteurs de projets en transformation fermière
Institut de l'Elevage - Idele
 
Accompagner les éleveurs dans l'analyse de leurs coûts de production
Accompagner les éleveurs dans l'analyse de leurs coûts de productionAccompagner les éleveurs dans l'analyse de leurs coûts de production
Accompagner les éleveurs dans l'analyse de leurs coûts de production
Institut de l'Elevage - Idele
 
Comment aborder le changement climatique dans son métier, volet adaptation
Comment aborder le changement climatique dans son métier, volet adaptationComment aborder le changement climatique dans son métier, volet adaptation
Comment aborder le changement climatique dans son métier, volet adaptation
Institut de l'Elevage - Idele
 
JTC 2024 - Atelier APaChe-Pâturage des arbres par les chèvres
JTC 2024 - Atelier APaChe-Pâturage des arbres par les chèvresJTC 2024 - Atelier APaChe-Pâturage des arbres par les chèvres
JTC 2024 - Atelier APaChe-Pâturage des arbres par les chèvres
Institut de l'Elevage - Idele
 
1er webinaire INOSYS Réseaux d’élevage Ovins Viande
1er webinaire INOSYS Réseaux d’élevage Ovins Viande1er webinaire INOSYS Réseaux d’élevage Ovins Viande
1er webinaire INOSYS Réseaux d’élevage Ovins Viande
Institut de l'Elevage - Idele
 
Reconquête de l’engraissement du chevreau à la ferme
Reconquête de l’engraissement du chevreau à la fermeReconquête de l’engraissement du chevreau à la ferme
Reconquête de l’engraissement du chevreau à la ferme
Institut de l'Elevage - Idele
 

Dernier (13)

BeeBOP diaporama webinaire : Et si l’IA permettait de compléter l’observatio...
BeeBOP diaporama webinaire : Et si l’IA permettait de compléter l’observatio...BeeBOP diaporama webinaire : Et si l’IA permettait de compléter l’observatio...
BeeBOP diaporama webinaire : Et si l’IA permettait de compléter l’observatio...
 
Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...
Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...
Quelles rotations dans les systèmes caprins de Nouvelle-Aquitaine et Pays de ...
 
pdfcoffee.com_polycopie-de-cours-ppt-lge604-20012-bf-pdf-free.pdf
pdfcoffee.com_polycopie-de-cours-ppt-lge604-20012-bf-pdf-free.pdfpdfcoffee.com_polycopie-de-cours-ppt-lge604-20012-bf-pdf-free.pdf
pdfcoffee.com_polycopie-de-cours-ppt-lge604-20012-bf-pdf-free.pdf
 
electronique de puissance Electronique-de-puissance-cours-N°5.pdf
electronique de puissance Electronique-de-puissance-cours-N°5.pdfelectronique de puissance Electronique-de-puissance-cours-N°5.pdf
electronique de puissance Electronique-de-puissance-cours-N°5.pdf
 
Leviers d’adaptation au changement climatique, qualité du lait et des produit...
Leviers d’adaptation au changement climatique, qualité du lait et des produit...Leviers d’adaptation au changement climatique, qualité du lait et des produit...
Leviers d’adaptation au changement climatique, qualité du lait et des produit...
 
RAPPORT DE STAGE sur CHANTIER BTP (by BR Engineering ) (1) (1).pdf
RAPPORT DE STAGE  sur CHANTIER  BTP (by BR Engineering ) (1) (1).pdfRAPPORT DE STAGE  sur CHANTIER  BTP (by BR Engineering ) (1) (1).pdf
RAPPORT DE STAGE sur CHANTIER BTP (by BR Engineering ) (1) (1).pdf
 
COUPROD Une méthode nationale commune à l’ensemble des filières herbivores
COUPROD Une méthode nationale commune à l’ensemble des filières herbivoresCOUPROD Une méthode nationale commune à l’ensemble des filières herbivores
COUPROD Une méthode nationale commune à l’ensemble des filières herbivores
 
Accompagner les porteurs de projets en transformation fermière
Accompagner les porteurs de projets en transformation fermièreAccompagner les porteurs de projets en transformation fermière
Accompagner les porteurs de projets en transformation fermière
 
Accompagner les éleveurs dans l'analyse de leurs coûts de production
Accompagner les éleveurs dans l'analyse de leurs coûts de productionAccompagner les éleveurs dans l'analyse de leurs coûts de production
Accompagner les éleveurs dans l'analyse de leurs coûts de production
 
Comment aborder le changement climatique dans son métier, volet adaptation
Comment aborder le changement climatique dans son métier, volet adaptationComment aborder le changement climatique dans son métier, volet adaptation
Comment aborder le changement climatique dans son métier, volet adaptation
 
JTC 2024 - Atelier APaChe-Pâturage des arbres par les chèvres
JTC 2024 - Atelier APaChe-Pâturage des arbres par les chèvresJTC 2024 - Atelier APaChe-Pâturage des arbres par les chèvres
JTC 2024 - Atelier APaChe-Pâturage des arbres par les chèvres
 
1er webinaire INOSYS Réseaux d’élevage Ovins Viande
1er webinaire INOSYS Réseaux d’élevage Ovins Viande1er webinaire INOSYS Réseaux d’élevage Ovins Viande
1er webinaire INOSYS Réseaux d’élevage Ovins Viande
 
Reconquête de l’engraissement du chevreau à la ferme
Reconquête de l’engraissement du chevreau à la fermeReconquête de l’engraissement du chevreau à la ferme
Reconquête de l’engraissement du chevreau à la ferme
 

Critères de compatibilité avec l'Agile

  • 1. Critères de compatibilité avec l'Agile (Mike Griffiths – Juin 2007) 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 pouvons- nous 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. Critères de compatibilité avec l'Agile (Mike Griffiths – Juin 2007) 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. Critères de compatibilité avec l'Agile (Mike Griffiths – Juin 2007) 2. Les critères de compatibilité d'un projet selon DSDM J'ai eu la chance d'être impliqué dans la création de DSDM1 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, ... 2. 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. Critères de compatibilité avec l'Agile (Mike Griffiths – Juin 2007) 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. Critères de compatibilité avec l'Agile (Mike Griffiths – Juin 2007) 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. Critères de compatibilité avec l'Agile (Mike Griffiths – Juin 2007) 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. Critères de compatibilité avec l'Agile (Mike Griffiths – Juin 2007) 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. Critères de compatibilité avec l'Agile (Mike Griffiths – Juin 2007) 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. Critères de compatibilité avec l'Agile (Mike Griffiths – Juin 2007) 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. Critères de compatibilité avec l'Agile (Mike Griffiths – Juin 2007) 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/2011 10/14
  • 11. Critères de compatibilité avec l'Agile (Mike Griffiths – Juin 2007) 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/2011 11/14
  • 12. Critères de compatibilité avec l'Agile (Mike Griffiths – Juin 2007) 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/2011 12/14
  • 13. Critères de compatibilité avec l'Agile (Mike Griffiths – Juin 2007) 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/2011 13/14
  • 14. Critères de compatibilité avec l'Agile (Mike Griffiths – Juin 2007) 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/2011 14/14