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

6. Client
Septique

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 !