Tour d'horizon des méthodes agiles

Les Méthodes Agiles
Panorama et retours d’expériences

29 août 2006

Le développement de nouveaux logiciels

![Jones97] [BP88] “Last simple SW project was in 1969”

60
50
% Changement d’exigences

40
30
20
10
0
0 10 100 1000 10000 100000
Taille du projet en points de fonction

Approche classique de gestion de projet

!Faire un plan détaillé

!Affecter des ressources

!Contrôler et rectifier les écarts

!La gestion de projets classique
s’assure de la conformité du projet
par rapport au plan, non de la bonne
adéquation de ce plan

« I have always found that plans are
useless, but planning is indispensable »
Dwight Eisenhower

Confusion de Paradigme
Analyse des
besoins et faisabilité
La production en masse tend à
Spécifications
promouvoir un processus :
Conception
!En cascade, architecturale

!Design en amont, Conception détaillée

!Un plan détaillé, Codage

!Etapes pré-définies.
Tests de validation

Le développement de nouveaux Installation

produits nécessite un processus : Préparer

!Itératif,
!Evolutif,
Faire
!Adaptatif,
!Empirique.
Adapter

Approche classique vs Approche Agile

Projet classique Projet agile

!Etablir et suivre un plan !Planifier puis adapter

!Avancement défini par des !Avancement mesuré par la
livrables intermédiaires livraison de fonctionnalités

!Assignation des tâches !Prise en charge des tâches

!Solution imposée !Solution émergente

6

Développement Itératif

Méthodes itératives et
évolutives

Méthodes Agiles

Historique

Lean Software Development, 2002
Agile UP, 1999
Adaptive Software Development, 1998
xBreed, 1998
Feature-Driven Development, 1997
Crystal, 1997
XP, 1995
DSDM, 1992
Scrum, 1992
Spiral Model, 1987
Lean Thinking, 1950s

Web

!www.agilealliance.com
!www.scrumalliance.org
!www.agilemodeling.com
!www.featuredrivendevelopment.com
!www.poppendick.com
!www.lean.org
!www.extremeprogramming.org
!www.testdriven.com

!www.jimhighsmith.com
!www.martinfowler.com
!alistair.cockburn.us
!www.craiglarman.com

Historique

Question :
“What are the most exciting, promising software engineering ideas
techniques on the horizon?”

Réponse :
“I don’t think that the promising ideas are on the horizon. They are already
here and have been for years, but are not being used properly.”

David L. Parnas

Preuves

!IEEE Computer, Juin 2003, Larman et Basili

Estimé vs. Réel [DeMarco82, Little04]

!p50 réel = 2x estimé
!p90 réel = 3,25x estimé
!La meilleure estimation initiale à 10% de chances de se réaliser

Fonctionnalités inutiles ?

Taux d’utilisation des fonctionnalités développées [Johnson02] sur
des projets développés en méthodes classiques.

Souvent
Parfois 13%
16%

Rarement Toujours
19% 7%

Jamais
45%

Echec du processus en cascade

Facteurs clefs de succès/d’échec sur 1027 projets [Thomas01]

!Les pratiques du processus en cascade :
!Phase amont d’analyse,
!Planning sous forme de gantt-chart,
!Planning “fixe”.

!Sont la toute première cause d’échec des projets,

!Cité en premier dans 82% des projets.

Processus Itératif et Evolutif

Etude de deux ans [MacCormack01] :
!La majorité des gains en productivité sont dus à :
! Des itérations avec un feedback précoce,
! Une intégration continue journalière (ou plus fréquente) de tout le code avec
des tests automatiques de non-régression.

Etude sur 23.000 projets [Standish98] :
!2 facteurs clefs de succès sur 5 sont liés aux méthodes itératives :
! Implication fréquente des utilisateurs,
! Petites milestones,
! Objets métiers clairs,
! Chef de projet expérimenté,
! Support du management.

Productivité - Mauvaise Pratiques
Reuse of low-quality deliverables -300%
Low management knowledge/experience -90

Low staff knowledge/experience -87
High requirements creep -77

Inadequate development tools -75
No inspections -48

Inadequate management tools -45
Inadequate methods/process; not following -41

Poor estimation -40
High project complexity -35

Schedule pressure -30
Crowed office space; low table/wall space -27
Low-level languages -25
Geographic separation -24

Informal/sloppy cost/schedule estimates -22
Only generalist occupations -15

Low client participation -13

Productivité - Bonnes Pratiques

Reuse of high-quality deliverables 350%
High management experience 65

High staff experience 55
Really followed an effective method/process 35

Used adequate management tools 30
Used effective development tools 27

High-level language 24

Used estimating tools 19
Specialist occupations 18

Client participation 18
Formal cost/schedule estimates 17

Unpaid overtime 15
Inspections 15

Low project complexity 15

Facteurs de Productivité

Etude d’équipes de développement hyper-productives [HC96] :
!Développement itératif,

!Organisation simples; moins de rôles que d’ordinaire,

!L’architecte a été un développeur,

!Forte composant communication ; un focus technique tous les jours,

!Le noyau a été développé en premier, par une équipe très aguerrie.

Les études montrent qu’un facteur 5:1 à 10:1 sépare le développeur le
moins productif du développeur le plus productif.

Facteurs de Productivité

Deux études menées sur 15 projets montrent que :

!La productivité est doublée si l’équipe évolue dans un Openspace
sans aucune frontière ni barrière.

Quelle organisation est la plus efficace ?

Manifeste Agile
Priorité aux personnes et aux interactions,
plutôt que sur les processus et les outils. L’accent
est sur les individus, l’expertise, l’esprit d’équipe.

Des applications fonctionnelles
opérationnelles,
plutôt qu’une documentation pléthorique. On
privilégie le code testé.

Collaborer avec le client,
plutôt que négocier un contrat. Le client est un
partenaire qui participe au projet pour donner son
feedback

Réactivité au changement,
plutôt que suivre un plan. Le planning est flexible
pour accepter les modifications.

Process Agile : Solution miracle ?

“Process is a second-order effect” - Alistair Cockburn

Le Marché aux pratiques

!Une cause d’échec des méthodes agiles est la
tentation de faire “son marché” dans les pratiques,

!Les méthodes agiles sont basées sur des
principes et des valeurs plus que des pratiques,

!Les pratiques doivent être adaptées :
!aux individus,
!au contexte,
!en cours de projet.

Se donner comme objectif d’adopter une pratiques
détourne de l’objectif de livraison d’un produit de
qualité dans les temps et budget impartis.

Méthodes Agiles

!Lean Software Development,

!eXtreme Programming,

!Scrum,

!DSSM,

!Crystal.

Lean Thinking

!5 principes à mettre en oeuvre

!Montrent le but à atteindre :
!Complexe à maîtriser
!Pas de tout ou rien,
!Pas de maintenant ou jamais.

Lean Thinking : 5 principes

!Traquer les déchets (Waste),
!Effectuer les tâches en petits lots (Small batches) à la demande (Pull),
!Voir le système dans son intégralité. Pas d’optimisations locales,
!Equipe soudée et motivée (Jelled Team)
!Apprendre et améliorer le processus en continu (KAISEN)
!Manager qui écoute et règle les problèmes de son équipe (GEMBA)

échets
rimer les d
aleur et supp
Maxim iser la v

Lean Thinking

!Cela peut sembler simple ou évident,

!En fait cela demande un profond changement de mentalité et de
management :
!On se focalise sur la production de valeur pour les utilisateurs,
!Le chef de projet gestionnaire devient un facilitateur,
!Le processus évolue continuellement,
!Il ne s’affine pas, il évolue en fonction des demandes,
!L’équipe est au coeur du processus d’amélioration continu,
!Ils cherchent à améliorer leur environnement de travail pour
produire plus de valeur.
!Les optimisations locales sont monnaie-courante,
!Financer les moyens plutôt que les objectifs.

Lean Software Development

!7 principes
!Eliminer les déchets,
!Accentuer l’apprentissage,
!Décider le plus tard possible,
!Délivrer aussi vite que possible,
!Donner du pouvoir à l’équipe,
!Maintenir l’intégrité,
!Voir le système dans sa globalité.

!22 principes concrets ou “Thinking
Tools”

Eliminer les déchets

!Voir les déchets :
!Fonctionnalité partiellement réalisée,
!Processus trop lourd
!Fonctionnalités inutilisées
!Changement de tâche
!Attente
!Passage de documents
!Anomalies, bugs,
!Duplication.

!Modélisation agile,
!Eviter un design détaillé en amont,
!Ne pas écrire de document sans besoin réel,...

Délivrer aussi vite que possible

!Intégration continue,

!Design patterns,

!Améliorer la productivité :
!Recruter des développeurs expérimentés,
!Un seul site,
!Outillage agile,
!Open space,
!...

Donner du pouvoir à l’équipe

!Promouvoir l’auto-organisation,

!Stand-up meeting journalier,

!Retrospective de fin d’itération :
!Aux mains de l’équipe,
!Analyser,
!Adapter,
!Le processus :
!Outils,
!Pratiques,
!Eliminer le déchet en évitant les optimisations locales.

!Attention : Pas de tout ou rien ! Ni de maintenant ou jamais !

Phases vs Disciplines

!Une itération met en oeuvre toutes les disciplines et se termine pas un
produit éxécutable

e
a lys
An
on
epti
o nc
C

st n
Te tat
io
n
me
m plé
I

Changement de terminologie

Phase de
Conception

Phase
de Test

Des équipes cross-fonctionnelles

!Des Workshops,

!Toute l’équipe :
!Analystes,
!Développeurs,
!Testeurs,
!Product Owner.

Equipe orientée Fonctionnalité

Fonctionnalité
!=
Module

Fonctionnalité
=
Centrée Utilisateur

Workshops étalés dans le temps

Développement Orienté Risque et Valeur

Développer Feedback Développer Feedback Développer
quelques quelques quelques
fonctionnalités fonctionnalités fonctionnalités

Risques Valeurs

eXtreme Programming

!Origines :
!Initiative de Kent Back et Ron Jeffries en 1996, en collaboration avec
Wad Cunningham
!Projet C3 chez Chrysler

!5 valeurs : !4 activités essentielles :
!Communication, !Conception (un peu mais tout le
!Simplicité, temps),
!Feedback, !Codage (pas mal) et refactoring,
!Courage, !Tests (beaucoup),
!Respect. !Ecoute.

L’environnement de travail

L’environnement
productif

La diffusion de
l’information

Cruise Control / Information Radiator

XP : Points forts / Points faibles

!Approche très radicale…
!Les « curseurs » sont au minimum ou au maximum !
!Nécessite beaucoup de discipline.

!… adaptée aux petits projets :
!Pas plus de 10-12 personnes.

!Centrée sur l’ingénierie, plus légère sur le management,

!Favorise la qualité :
!Client présent sur le site de développement,
!Mais cela a un coût !
!Tests omniprésents.

!Le pair-programming n’est pas toujours bien ressenti par les
développeurs :
!Doit être basé sur le volontariat et l’autodiscipline.

Origines

Iterative,
The New, New
Incremental,
Product Lean Thinking
Development,
Development Game
Timeboxes

Scrum (1993)

Dr Jeff Sutherland
Ken Schwaber

Scrum

!Principales pratiques :
!Élaboration et mise à jour d’un planning produit (product backlog),
!Des itérations de 30 jours (sprint),
!Planification de chaque itération (sprint backlog),
!Réunion d’avancement quotidienne (scrum),
!Isolation des développeurs (face au chaos extérieur),
!Revue de fin d’itération (sprint review meeting).

!3 rôles :
!Scrum Master,
!Product Owner,
!Team.

Scrum - Le cycle de développement

Scrum a été utilisé par...

!Des éditeurs de logiciels,

!Des société faisant partie de “Fortune 100”,

!Des “start-up”,

!Des équipes de développement en interne,

!Des équipes sur des contrats au forfait.

Scrum a été utilisé pour...

!Du logiciel critique dans le domaine médical,

!Des applications financières,

!De la biotechnologie,

!Des systèmes pour les Centres d’appels,

!De environnements de développement,

!Des systèmes disponibles 24x7, 99.99999%,

!Des applications base de données de plusieurs terabytes,

!Des applications Web innovantes.

4 manières de maîtriser un projet

Fonctionnalités Temps

Projet

Tests Ressources

!Une fois une itération commencée, ne JAMAIS changer la date de fin,
!On peut par contre enlever des fonctionnalités

Iteration Burn Down Chart

60

45

30

15

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Scrum : Points forts / Points faibles

!Favorise la communication :
!Partage des informations grâce au scrum quotidien,
!Isolation et protection des développeurs,

!Approche plus axée sur le management,

!Adaptée au développement de progiciels au sein d’équipes
« produit » :
!Présence d’un Product Owner,

!Bonne complémentarité avec XP = méthode XBreed.

Dynamic Software Development Method (DSDM)

!Développée en GB, en 1994, sous la forme d’un consortium de
sociétés qui voulaient utiliser RAD et le développement itératif.

!9 principes de base :
!Implication active des utilisateurs,
!Pouvoir de décision des équipes,
!Livraisons fréquentes,
!Adéquation aux besoins,
!Développement itératif et incrémental,
!Modifications réversibles,
!Définition globale des besoins,
!Intégration des tests dans tout le cycle de vie,
!Collaboration et coopération entre toutes les parties prenantes.

DSDM – le cycle de développement

1. Étude de faisabilité
• Définition du problème à 2. Étude du « business »
résoudre • Étude des processus à automatiser
et des besoins en informations
• Évaluation des coûts (ateliers facilités)
• Ébauche de la solution • Priorisation des fonctionnalités
technique • Définition de l’architecture système

3. Modèle fonctionnel 4. Conception et
itératif développement itératifs
• Spécifications détaillées • Réalisation du système
• Modules logiciels conforme aux standards

5. Mise en oeuvre
• Mise en production
• Formation
• Documentation
• Capitalisation
68

DSDM : Points forts / Points faibles

!Conformité avec la norme Iso 9001,

!Trop d’autonomie donnée à l’équipe et aux utilisateurs dans la prise
de décision, par rapport au « payeur »,

!Faire trop simple peut nuire à l’évolutivité de l’application,

!Peut-être la moins agile des méthodes agiles, assez proche d’UP.

Crystal

!Mise au point en 1990, par Alistair Cockburn, il s’agit plutôt d’une
famille de méthodologies adaptables à chaque type de projet,

!9 propriétés :
!Livraisons fréquentes,
!Améliorations permanentes,
!Communication osmotique,
!Confiance, sécurité personnelle,
!Focus sur l’objectif et disponibilité,
!Contact permanent avec les utilisateurs,
!Environnement de travail et automatisation des tâches,
!Coopération avec toutes les parties prenantes,
!Réflexion sur les propriétés.

Crystal : Points forts / Points faibles

!Adaptée à des petits projets de moins de 6 personnes,

!La famille de méthodes Crystal offre une large possibilité
d’adaptation à chaque type de projet :
!Mais les autres « membres de la famille » ne sont pas encore décrits,
!Ni même fortement expérimentés.

Tour d'horizon des méthodes agiles

Contenu connexe

Tendances

En vedette

Similaire à Tour d'horizon des méthodes agiles

Plus de Christophe Addinquy

Tour d'horizon des méthodes agiles