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 !