AgileTour Toulouse 2012 : adopter l’agilité
0 j'aime605 vues
Le document traite des défis et des perceptions autour de l'adoption des méthodes agiles dans la gestion de projet, en répondant à des objections fréquentes des clients sceptiques. Il met en lumière les pratiques à éviter et propose une vision de l'agilité 'naturelle' qui respecte à la fois les acquis des clients et l'évolution des projets. L'auteur insiste sur l'importance de la communication, de l'engagement des parties prenantes et de l'adaptation des processus aux spécificités de chaque projet.
AgileTour Toulouse 2012 : adopter l’agilité
- 2. Adopter l’agilité Le kit pour convaincre David Brocard - 2012
- 3. Prérequis • Connaissances de base de ce qu’est l’Agilité • Les concepts présentés ne sont pas détaillés • Fournir des points d’entrée pour aiguiller The author must be referenced for any reuse
- 4. David Brocard Consultant indépendant Gestion de Projet Informatique - Méthodes Agiles
- 5. Sommaire ✓ Client septique ✓ Frequently Heard Answers ✓ Convaincre pour changer
- 7. • L’Agilité progresse ! • “Méthodologie de rupture” • Encore beaucoup d’effort pour convaincre
- 8. Halte au simplisme ! • 10 ans d’Agilité quand même... • Une communication à améliorer • Ne prenons pas le client pour un ... • Respectons ses acquis • agilité vs Agilité
- 9. Frequently Heard Answers (FHA)
- 10. Pour chaque FHA 1. L’hypothèse simpliste 2. Les pratiques à éviter 3. L’agilité "naturelle" 4. Les différences avec l'Agilité
- 11. Frequently Heard Answers • "Nous cassons déjà l'effet tunnel !" • "Notre méthode gère déjà les changements !" • "Notre façon de faire de l'architecture ne se limite pas à tout figer dès le départ !" • "L'Agilité est incompatible avec nos sous-traitants au forfait !" • "Nous mettons déjà en oeuvre les pratiques d’ingénierie logicielles agiles !" • “Notre documentation est la minimum nécessaire“
- 12. "Nous cassons déjà l'effet tunnel !"
- 13. Effet tunnel • L’hypothèse simpliste ‣ Pur cycle en V ‣ Pas de livraisons intermédiaires, effet tunnel d’un an ‣ Phasage strict: pas d’anticipation d’une phase sur l’autre, on attend la tenue des jalons avant de poursuivre • Les pratiques à éviter ‣ Inscrire le cycle en V comme fondation du référentiel projet • L’agilité "naturelle" ‣ Incrémental: plusieurs mini-cycles en V ‣ Une vraie discipline de tests unitaires ‣ “Lean en V”: les principes Lean génériques appliqués au cycle en V ‣ Le design et le code sont souvent commencés avant la fin des specs
- 14. Effet tunnel • Les différences avec l'Agilité ‣ Pas de time box, ni de vrai flux ‣ Différent du Lean Software Development ‣ Phases vs activités d’ingénierie ‣ RUP : agile ?
- 15. "Notre méthode gère déjà les changements !"
- 16. Changements • L’hypothèse simpliste ‣ Tous les besoins définis au départ de façon détaillée • Les pratiques à éviter ‣ Critères de succès basés sur la conformité au plan initial ‣ CCB lourd et inadapté à la taille du projet ‣ Sous estimer la part de l’inconnu à l’instant t (voir les statistiques) • L’agilité "naturelle" ‣ CCB léger et adapté à la taille du projet ‣ Phase de prototypage préliminaire permettant de limiter la casse
- 17. Changements • Les différences avec l'Agilité ‣ L’acceptation du changement est sans doute l’aspect le mieux pris en compte par l’Agilité ‣ A l’origine de la culture agile <> CCB formel, vécu a posteriori ‣ Injection de changements au début de cycles courts ‣ L’agilité technique sécurise l’acceptation des changements ‣ Gestion des besoins taillées pour prévenir les perturbations
- 18. "Notre façon de faire de l'architecture ne se limite pas à tout figer dès le départ !"
- 19. Architecture • L’hypothèse simpliste ‣ Architecture exhaustive figée dans les détails avant de passer à la phase suivante ‣ Architectes non impliqués dans les phases de développements • Les pratiques à éviter ‣ Différer la mise à l’épreuve de l’architecture sur papier ‣ Rester trop abstrait en termes d’exigences non fonctionnelles (NFR) ‣ Mettre toutes les NFR au même niveau d’importance • L’agilité "naturelle" ‣ Commencer par un mini-projet dans le projet : POC (Proof Of Concepts) ou prototypes ‣ Cas du RUP : la phase d’élaboration vise explicitement à itérer pour livrer une “architecture exécutable”
- 20. Architecture • Les différences avec l'Agilité ‣ Architecture = “les grands principes de conception irréversibles” - phase d’exploration ‣ L’architecture est propriété de l’équipe et non d’experts mandatés ‣ Une approche POC intrinsèque ‣ Les NFR sont exprimées sous forme de user stories et sont systématiquement priorisées ‣ Les NFR sont priorisés, donc échelonnées ‣ Même quand il y a une “Release 0”, l’architecture continue à émerger lors des itérations “fonctionnelles” ‣ Une utilisation raisonnée des outils de modélisation Exploration Engagement Release 0 Release 1
- 21. "L'Agilité est incompatible avec nos sous- traitants au forfait !"
- 22. Sous-traitance • L’hypothèse simpliste ‣ Le client transmet un cahier des charges et ne revient qu’au moment de la recette ‣ Le client est à même de sécuriser son forfait par des besoins précis ‣ Le client sait écrire les tests de recette et passer la recette • Les pratiques à éviter ‣ Jouer pour perdre : demander l’impossible à son sous-traitant et fermer les yeux en attendant qu’il se récupère par des avenants hors de prix ‣ Négliger l’effort à consacrer pour un suivi régulier et son importance
- 23. Sous-traitance • L’agilité "naturelle" ‣ Des personnes plus intelligentes que des contrats inadaptés ‣ Granularité des engagements ‣ Contrats cadre éprouvés Spec1 SERVICE WORKLOAD F1 Complexe UC 10 days Spec2 Average UC 5 days F2 Simple UC 2 days Corrective patch 3 days etc F3
- 24. Sous-traitance • Les différences avec l'Agilité ‣ Le client est réellement engagé ‣ De la subordination au partenariat ‣ Vers la sortie du “triangle de fer” ‣ Une vraie difficulté : toujours un monde d’aventuriers ‣ Les catalogues de services sont plus rigides que les contrats à base d’engagement de vélocité ‣ Rediriger l’engagement vers la qualité intrinsèque
- 25. "L'Agilité est incompatible avec nos gros projets en équipes distribuées !"
- 26. Gros projets • L’hypothèse simpliste ‣ Grosses équipes “en râteau” ‣ Pas d’interactions horizontales ‣ Pas de rendez-vous intermédiaires • Les pratiques à éviter ‣ Excès de hiérarchie et de subordinations entre les différents niveaux ‣ Ségrégation des activités. Céder au mythe du découpage stricte expertise métier / software factory V Us Them Someone
- 27. Gros projets • L’agilité "naturelle" ‣ Pas de solution “tout-en-un”. Adaptation à la spécificité du contexte ‣ Volonté de développer la communication et les rencontres sur place ‣ Développement des visio • Les différences avec l'Agilité ‣ L’agilité invite à considérer le rapprochement géographique ‣ Rendez-vous plus fréquents ‣ On privilégie le découpage en “Feature Team” pour que chaque entité soit impliquée verticalement dans le développement ‣ Intégration continue transverse ou multi-niveaux ‣ Les valeurs prennent le relais des contraintes
- 28. "Nous mettons déjà en oeuvre les pratiques d’ingénierie logicielles agiles !"
- 29. Ingénierie logicielle • L’hypothèse simpliste ‣ Intégration big-bang ‣ Tests unitaires et fonctionnels non automatisés • Les pratiques à éviter ‣ Exigences mal découpées ; pilotage par les tâches techniques ‣ Négliger l’importance d’une couverture maximale de tests unitaires ‣ Ecriture tardive des tests fonctionnels et de recette • L’agilité "naturelle" ‣ Structuration des besoins en uses case métier ‣ Savoir-faire en matière de tests (“XUnit Tests Patterns” - Meszaros) ‣ Automatisation des tests unitaires et fonctionnels
- 30. Ingénierie logicielle • Les différences avec l'Agilité ‣ Use cases vs user stories : de nombreux points communs mais des différences essentielles ‣ TDD, BDD : bien plus que des tests unitaires ‣ Discipline sous-jacente autour de l’intégration continue ‣ Une traçabilité par construction et par exécution User story Acc. Tests Fixture Code Tests results
- 31. “Notre documentation est la minimum nécessaire“
- 32. Documentation • L’hypothèse simpliste ‣ Client obnubilé par une documentation exhaustive • Les pratiques à éviter ‣ Ne pas se préoccuper au préalable des relecteurs à consulter pour assurer la pertinence du contenu ‣ Faire du zèle aux poulets • L’agilité "naturelle" ‣ Référentiels qualité prévoient des déclinaisons en fonction de la complexité des projets ‣ Les cochons ne disent rien mais n’en pensent pas moins
- 33. Documentation • Les différences avec l'Agilité ‣ Inscrit noir sur blanc dans les 1eres lignes du Manifeste ‣ La métaphore “voyager léger” autorise de remettre en cause l’intérêt, l’efficacité et le contenu d’un document ‣ La documentation n’est requise que si elle réellement nécessaire pour le contexte du projet ‣ La documentation minimale se limite à ce qui est nécessaire pour compléter les conversations face à face et fédérer les intervenants ‣ La documentation “exécutable” prend le relais de la documentation classique (TDR, TDD) ‣ “La doc c’est le code”
- 34. Convaincre pour changer
- 35. Pourquoi convaincre ? • Identifier l’origine de l’impulsion 1. Marketing ou politique 2. Vraie volonté de changement de gouvernance 3. Levier technique • Agir en conséquence 1. Des valeurs = du courage ! 2. Ne pas survendre l’Agilité 3. La route vers l’Agilité technique (Craftsmanship)
- 36. Changer • Changer le process ou changer les valeurs ? • Les pilotes sont indispensables • Ne pas négliger le niveau culturel du changement • Montrer l’intérêt avec le temps par l’absence d’Agilité • Etre respectueux et pragmatique Coaching : une affaire de sensibilité
- 37. Merci !