View
352
Download
2
Category
Preview:
Citation preview
Adopter l’agilitéLe kit pour convaincre
David Brocard - 2012
• 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
Prérequis
The author must be referenced for any reuse
David BrocardConsultant indépendant
Gestion de Projet Informatique - Méthodes Agiles
✓ Client septique
✓ Frequently Heard Answers
✓ Convaincre pour changer
Sommaire
Client Septique
• L’Agilité progresse !
• “Méthodologie de rupture”
• Encore beaucoup d’effort pour convaincre
• 10 ans d’Agilité quand même...
• Une communication à améliorer
• Ne prenons pas le client pour un ...
• Respectons ses acquis
• agilité vs Agilité
Halte au simplisme !
Frequently Heard
Answers(FHA)
1. L’hypothèse simpliste
2. Les pratiques à éviter
3. L’agilité "naturelle"
4. Les différences avec l'Agilité
Pour chaque FHA
• "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“
Frequently Heard Answers
"Nous cassons déjà l'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
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 ?
Effet tunnel
"Notre méthode gère déjà les 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
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
Changements
"Notre façon de faire de l'architecture ne se limite pas à tout figer dès le départ !"
• 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”
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
Architecture
Exploration Engagement Release 1Release 0
"L'Agilité est incompatible avec nos sous-traitants au forfait !"
• 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
Sous-traitance
• L’agilité "naturelle"‣ Des personnes plus intelligentes que des contrats inadaptés‣ Granularité des engagements‣ Contrats cadre éprouvés
Sous-traitance
SERVICE WORKLOADComplexe UC 10 days
Average UC 5 days
Simple UC 2 days
Corrective patch 3 days
etc
F1
F2
F3
Spec1
Spec2
• 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
Sous-traitance
"L'Agilité est incompatible avec nos gros projets en équipes distribuées !"
• 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
Gros projets
Us
Them
SomeoneV
• 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
Gros projets
"Nous mettons déjà en oeuvre les pratiques d’ingénierie logicielles agiles !"
• 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
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
Ingénierie logicielle
User story
Tests results
Acc. Tests
Fixture
Code
“Notre documentation est la minimum nécessaire“
• 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
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”
Documentation
Convaincre pour
changer
• Identifier l’origine de l’impulsion1. Marketing ou politique2. Vraie volonté de changement de gouvernance3. Levier technique
• Agir en conséquence1. Des valeurs = du courage !2. Ne pas survendre l’Agilité3. La route vers l’Agilité technique (Craftsmanship)
Pourquoi convaincre ?
• 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
Changer
Coaching : une affaire de sensibilité
Merci !
Recommended