AgileTour Toulouse 2012 : adopter l’agilité

475 views
436 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
475
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

AgileTour Toulouse 2012 : adopter l’agilité

  1. 1. Adopter l’agilité Le kit pour convaincre David Brocard - 2012
  2. 2. 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
  3. 3. David Brocard Consultant indépendantGestion de Projet Informatique - Méthodes Agiles
  4. 4. Sommaire✓ Client septique✓ Frequently Heard Answers✓ Convaincre pour changer
  5. 5. ClientSeptique
  6. 6. • L’Agilité progresse !• “Méthodologie de rupture”• Encore beaucoup d’effort pour convaincre
  7. 7. 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é
  8. 8. Frequently Heard Answers (FHA)
  9. 9. Pour chaque FHA1. L’hypothèse simpliste2. Les pratiques à éviter3. L’agilité "naturelle"4. Les différences avec lAgilité
  10. 10. Frequently Heard Answers• "Nous cassons déjà leffet tunnel !"• "Notre méthode gère déjà les changements !"• "Notre façon de faire de larchitecture ne se limite pas à tout figer dès le départ !"• "LAgilité 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“
  11. 11. "Nous cassons déjà leffet tunnel !"
  12. 12. 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
  13. 13. Effet tunnel• Les différences avec lAgilité ‣ Pas de time box, ni de vrai flux ‣ Différent du Lean Software Development ‣ Phases vs activités d’ingénierie ‣ RUP : agile ?
  14. 14. "Notre méthode gère déjà les changements !"
  15. 15. 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
  16. 16. Changements• Les différences avec lAgilité ‣ 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
  17. 17. "Notre façon de faire de larchitecture ne se limite pas à tout figer dès le départ !"
  18. 18. 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”
  19. 19. Architecture• Les différences avec lAgilité ‣ 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
  20. 20. "LAgilité est incompatible avec nos sous- traitants au forfait !"
  21. 21. 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
  22. 22. 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
  23. 23. Sous-traitance• Les différences avec lAgilité ‣ 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
  24. 24. "LAgilité est incompatible avec nos gros projets en équipes distribuées !"
  25. 25. 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
  26. 26. 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 lAgilité ‣ 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
  27. 27. "Nous mettons déjà en oeuvre les pratiques d’ingénierie logicielles agiles !"
  28. 28. 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
  29. 29. Ingénierie logicielle• Les différences avec lAgilité ‣ 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
  30. 30. “Notre documentation est la minimum nécessaire“
  31. 31. 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
  32. 32. Documentation• Les différences avec lAgilité ‣ 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”
  33. 33. Convaincre pour changer
  34. 34. 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)
  35. 35. 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é
  36. 36. Merci !

×