Ce document présente une synthèse des méthodes Agiles, en particulier le manifeste Agile de 2001, et ses principes clés tels que l'auto-organisation, l'importance du feedback et la réactivité aux besoins des utilisateurs. Il explore différentes pratiques comme l'Extreme Programming et le Scrum, tout en soulignant l'évolution des méthodes légères par rapport aux approches plus traditionnelles. Enfin, il discute de l'importance de la communication et de l'amélioration continue dans un cadre Agile.

1. cocktail d’expérience informatiques
Genève 3 & 4 octobre 2011
Seconde édition
Auteur Thierry Gabriel CROS
Track Agile
Session Agile... Qu'es aco ?

3. Agile...
Qu'es aco ?
Thierry Gabriel Cros

4. Agenda
● Agile ?
● Extreme Programming
● Scrum
● Lean Software Development
● Kanban
● En guise de conclusion...
http://etre-agile.com 2

5. Les façons de faire
● Hors agile, nous rencontrons essentiellement
deux styles de développement...
http://etre-agile.com 3

6. 1. Cycles en V
Spécification Validation
Cascade
Cycle en V Conception
préliminaire Intégration
Conception Tests
détaillée unitaires
Codage
http://etre-agile.com 4

7. 2. L'Arrache (ou La Rache)
● Également connu sous le nom de …
http://www.djibnet.com
http://etre-agile.com 5

8. Alors...
● Cycle en V ?
● Cow-boy ?
● …
http://etre-agile.com 6

9. Méthode :
Empirique ou théorique ?
Il est normal d'adopter l'approche définie par un modèle
(théorique) quand les mécanismes sous-jacents par lesquels
un processus opère sont relativement bien compris.
Si le processus est trop compliqué pour l'approche
définie, alors l'approche empirique est le choix approprié.
Process Dynamics, Modeling, and Control,
Ogunnaike et Ray,
Oxford University Press, 1992
http://etre-agile.com 7

10. Empirique ?
● Empirique != désordonné
● Empirique != indiscipliné
● … Au contraire !
Si vous partez à l'aventure
et si vous êtes un tantinet sérieux,
vous faites très attention !
http://etre-agile.com 8

11. Un peu d'histoire...
● Années 90 : des expérimentations empiriques,
légères, face aux méthodes lourdes
● Rencontre, en février 2001, des concepteurs
de ces différentes méthodes « légères »...
● … Ce qui va aboutir au Manifeste agile,
expression des points communs à toutes ces
méthodes alternatives.
http://etre-agile.com 9

12. Agile : définition
● Autant de définitions que d'Agilistes...
● Pourtant, l'agilité a une histoire et un texte
fondateur en 2001 :
Le manifeste agile
http://agilemanifesto.org
http://etre-agile.com 10

13. 2001 : Le manifeste agile
● 4 valeurs
● 12 principes
● Une histoire
Quand des anarchistes
organisationnels
se rencontrent...
http://etre-agile.com 11

14. Le Manifeste
http://etre-agile.com
Source : agilemanifesto.org 12

15. Dilbert ? Non, merci.
« … l'Extreme Programming a connu
un développement dans son utilisation et son intérêt,
non pas grâce à la programmation en binôme
ou au refactoring, mais parce que,
pris dans leur ensemble, ses pratiques définissent
une communauté de développeurs
libérée des poids des sociétés "Dilbertesques". »
Histoire du Manifeste agile, Jim Highsmith
Traduction de Fabrice Aimetti
http://www.fabrice-aimetti.fr
http://thierrycros.net 13

16. Vous avez aimé Peter ?
Vous adorerez Dilbert !
Le principe de Dilbert est une version aggravée du principe de Peter.
Dans le livre Le Principe de Dilbert,
Scott Adams rappelle le principe de Peter :
Tout employé tend à s'élever
à son niveau d'incompétence.
Le nouveau principe, principe de Dilbert, s'énonce ainsi :
« Les gens les moins compétents
sont systématiquement affectés
aux postes où ils risquent
de causer le moins de dégâts :
ceux de managers. »
http://thierrycros.net 14
Source : wikipedia

17. En résumé
● Pendant plusieurs
● Années 80
années
– Lean
– Confidentiel
● Années 90 – Pionniers
– Scrum, XP, ... ● Depuis, l'agile est
● 2001 : le manifeste devenu une
agile alternative crédible
– Scrum + XP
– Lean Software
– Kanban
http://etre-agile.com 15

18. Agile aujourd'hui : une boite à outils
● Les méthodes ou ● Toutes ces méthodes
guides (XP, Lean...) forment un
véritablement framework de
agiles offrent plus plusieurs dizaines de
que le manifeste principes et
agile. pratiques...
● … Sur lequel nous
nous basons pour
installer l'agilité.
http://etre-agile.com 16

19. Agile : quatre axes fondateurs
Centré
Importance Métier
Équipe
Auto-organisée Auto-similarité
* Responsabilité Empirique Feedback
* Hédonisme concret & rapide
Amélioration
continue
http://etre-agile.com 17

20. Intérêt d'un feed-back
concret et rapide
Feedback
des Utilisateurs,
de l'exploitation
Approche agile
Début du
Retour sur
Investissement
Ajuster, voire rectifier
les besoins,
la solution informatique :
http://etre-agile.com
à 3 mois, à un an ? 18

21. Un autre principe clé de l'agilité
● « Les meilleures spécifications,
conceptions et architectures
émergent d'équipes auto-organisées »
– Émergence des specs ?
– Émergence de la conception, de
l'architecture ?
– Grâce à une « Équipe auto-organisée » ?
http://etre-agile.com 19

22. Intérêt de l'auto-organisation
● Pas de gaspillage ● La Vision du produit,
d'opportunités : partagée, est un
possibilité de attracteur dans une
proposer équipe auto-
organisée
● Interaction
● Pas de chef = plus
Utilisateur / Développeur de responsabilité
http://etre-agile.com 20

23. Extreme Programming :
ce célèbre inconnu
http://etre-agile.com 21

24. XP : l'émancipation du Développeur
● XP pour s'évaluer
● XP pour être soi
● XP pour s'émanciper en tant que Développeur
http://thierrycros.net 22

25. Extreme « Programming »
● Quelles activités ● Programming
apportent vraiment « Coder » (Java...)
une Valeur Ajoutée ?
Paramétrer
● Programming
= Réaliser le produit
Remettre en cause, réduire voire éliminer les activités « non V.A. »
http://thierrycros.net 23

26. « Extreme » Programming
● Une fois les activités ● Dialogues
« non VA » réduites, ● Tests
quelles activités
conserver et dans ● Conception
quelle proportion ? ● Relecture
Extreme Programming = « Pousser à fond » les activités
qui apportent de la valeur
http://thierrycros.net 24

27. Le « paquetage » XP
Valeurs
Principes
Pratiques
Rôles
Cycle de Vie
http://thierrycros.net 25

28. Rôles
● Une équipe, plusieurs rôles
Client (Product Manager)
Spécifie les demandes et les tests-client, planifie en
tenant compte de la VA des demandes
Développeur
Estime les demandes, réalise
Manager
Fait confiance, aplanie le terrain,
● Un point focal pour tous: la Valeur Métier
offerte par le produit
http://thierrycros.net 26

29. Valeurs de l' Extreme Programming
● Communication
Combien d'exemples... et de contre-exemples !
● Feedback
Pour contrôler à partir d'éléments les plus objectifs
● Simplicité
Le pari de l'Extreme Programming, pour tous, tout le temps
● Courage
De changer de rôle, de vision du produit
● Respect
Respecter et être respecté en tant que Principe Lean
personne
http://thierrycros.net 27

30. Un Cycle de Vie agile :
livrer rapidement et régulièrement
1
Exploration
2
2 mois max.
Engagement
3 4 5
...
1 semaine
Pilotage par feedback
n
Des années !
Mort
1. Fin d'exploration : carottages, architecture, de l'appli
périmètre initial, estimations
2. Engagement : premières valeurs des variables projet :
- Coût
- Délais Principe : Le client en choisit 3,
- Périmètre le Développeur la quatrième.
- Qualité
3. 4. 5. … Les différentes versions livrées
n. Fin de l'application.
http://etre-agile.com 28

31. Au cœur de l'expression de besoins :
les « user stories » d'XP
800
Valeur Métier (surtout thème)
En tant que Pilote,
je règle le commutateur en mode "
niveau horizontal" afin de
maintenir les ailes à l'horizontale
et l'avion sur sa trajectoire initiale.
Estimation (jours réels ou points)
5
Une histoire est :
1) un déclencheur de discussions dans l'équipe
2) l'unité de planification (correspondance histoire / itération)
http://thierrycros.net 29

32. Story : les 3C*
● Carte
● Conversation
– Pour estimer, développer la story
● Confirmation
– Tests d'acceptation
Tout n'est pas écrit
* cf. Ron. Jeffries
http://thierrycros.net 30

33. Importance
des Tests d'Acceptation
● Spécifier un test, c'est spécifier le produit
● « Deal » entre Product Manager et
Développeurs
● Automatiser les T.A.
– Fitnesse
– GreenPepper
– ...
http://thierrycros.net 31

34. Développement agile : emblématique
de l'Extreme Programming
● Test Driven Development : le Développement
piloté par la conception exprimée en tests
● Conception – Développement simple
– Code expressif
– Pas de duplication
– Nombre minimal de classes et méthodes
● Intégration continue
● Déploiement / nuit
http://thierrycros.net 32

35. Développement agile
● Produit malléable ● Test Driven
● Environnements Development
performants : ● Refactoring
– Cartes perforées ● Conception
vs émergente
Intelli J...
– Temps de
« compilation »
http://etre-agile.com 33

36. Conception émergente
● Itération 1 ● Itération n
Histoires Histoires du A380
d'utilisation A320
Avion
A320
A320 A380
YAGNI ! http://thierrycros.net 34

37. Scrum :
la marque qui fait vendre l'agilité
http://thierrycros.net 35

38. Scrum en un schéma
24 heures
Itération
1-3 semaines
But du sprint
Retour
Produit partiel
Tâches potentiellement
Annuler
Retour
utilisable
Coupons
Emballage
Emballage
Annuler Coupons
http://etre-agile.com 36

39. Scrum : les piliers
● Transparence
– Partager la définition de « done »
● Inspection
– Feedback rapide : artefacts, produits
● Adaptation
– L' amélioration du produit
– Et des pratiques
http://etre-agile.com 37

40. Scrum : les rôles
● Product Owner ● Équipe de
– Exprime les Développement
besoins – Estime l'effort
– Priorise nécessaire
– Valide – Fabrique le
produit
● ScrumMaster
– Garant de Scrum
http://etre-agile.com 38

41. Scrum : le cérémonial
● Sprint Meeting (plan d'itération)
● Sprint Review (Revue)
● Rétrospective (l'amélioration, 12ème principe)
● Daily Scrum Meeting (mélée quotidienne)
http://etre-agile.com 39

42. Scrum : le Business Model
● Dans la famille « certified », je demande...
– Le ScrumMaster
– Le Trainer
– Le Product Owner
● Scrum Guide de K. Schwaber :
http://scrum.org 17 pages
● Scrum... de Claude Aubry chez Dunod (300
pages)
http://etre-agile.com 40

43. Lean Software Develoment :
une autre voie vers l'agilité
http://etre-agile.com 41

44. Agenda
q
Agile, Lean, Lean Software ●
Outils
q
Les sept principes de base – SIPOC
●
1. Éliminer les gaspillages – Value Stream Mapping
●
2. Améliorer le système – Go & See
●
3. Qualité intrinsèque – ...
●
4. Gérer les décisions
●
5. Livrer rapidement
●
6. Fortement respecter les
personnes
●
7. Créer et faire vivre la
connaissance
v1
q
Lean Software - Être Agile 42

45. Une autre conduite du changement
● AS IS ● L.S.D.
● TO BE – Améliorer
l'existant
● Scrum + XP
– Le « package »
v1
Lean Software - Être Agile 43

46. Kanban : le dernier venu
● Visualiser le workflow ● Optimiser le temps
– Identifier le goulot de cycle
– Début du travail
sur un élément
– Début du cash-
back
● Limiter le
Work In Progress
– Terminer plutôt
v1 que commencer
Lean Software - Être Agile 44

47. Agile aujourd'hui : une boite à outils
● Les méthodes ou ● Toutes ces méthodes
guides (XP, Lean...) forment un
véritablement framework de
agiles offrent plus plusieurs dizaines de
que le manifeste principes et
agile. pratiques...
● … Sur lequel nous
nous basons pour
installer l'agilité.
http://etre-agile.com 45

48. Un dernier mot
● XP ● L'Agile se définit en
● Scrum – Valeurs
● Lean Software Dev – Principes
● Kanban
● Être agile c'est
mettre en pratique
● ... ces principes
● Soit vous « achetez »
ces valeurs, soit...
http://etre-agile.com 46

49. Bienvenue en agilité
Thierry Cros
http://etre-agile.com
Twitter
@thierrycros
Mél :
tco@thierrycros.net
Illustration : NASA
http://etre-agile.com 47

50. Itération,
objectif : TERMINER les histoires
Produit testé
V(n+1) et incrémenté.
ITERATION
(sprint)
Nouveau backlog
Périmètre
de l'itération
= { Histoires }
http://etre-agile.com 48

51. Une autre façon de dire le modèle
« théorique »
UML
C'est la quête éperdue
vers la perfection
MDA
(avant d'écrire du code)
qui est à l'origine de l'agilité
CMMI Anderson, Agile2008
BPM
L'Agilité va à l'encontre du « big * »
http://etre-agile.com 49

52. (R)UP : (Rational) Unified Process
- Piloté par les cas d'utilisation
- Itératif incrémental
http://etre-agile.com 50
- Centré architecture

53. Dérives usuelles (1)
Fonctionnalités utilisées
dans un système
Parfois Rarement
16% 19%
Jamais
Souvent 45%
13%
Toujours
7%
Standish Group Study Reported at XP2002 by Jim Johnson, Chairman
http://etre-agile.com 51

54. Dérives usuelles (2)
100% Début
Integration
Réalisation du développement
corrections
(% codé)
Date Date réelle
de fin
cible prévue
Avancement du projet
http://etre-agile.com 52
D'après Walker Royce