Methode Agile PDF

Méthode agile - Wikipédia Page 1 of 8
Méthode agile
Les méthodes Agiles sont des groupes de pratiques pouvant en s'appliquer à divers types de projets,
mais se limitant plutôt actuellement au projets de développement en informatique (conception de
logiciel). Les méthodes Agiles se veulent plus pragmatiques que les méthodes traditionnelles. Elles
impliquent au maximum le demandeur (client) et permettent une grande réactivité à ses demandes.
Elles visent la satisfaction réelle du besoin du client et non les termes d'un contrat de développement.
La notion de méthode agile a été officialisée en 2001 par un document, le Manifeste Agile (Agile
Manifesto), signé par 17 personnalités impliquées dans l'évolution du génie logiciel, en particulier,
en tant qu'auteur de leur propre méthode.
Les méthodes Agiles et les pratiques qu'elles recouvrent étaient antérieures au Manifeste Agile. Le
manifeste Agile n’est donc pas l’acte de naissance des méthodes Agiles ou du mouvement Agile,
mais la formalisation consensuelle par les auteurs de ces méthodes, toutes nées dans la deuxième
partie de la décennie 90, du fait qu’elles avaient des valeurs communes, une structure (cycle de
développement) commune (itérative, incrémentale et adaptative) et une base de pratiques, soit
communes, soit complémentaires. Parmi ces méthodes on trouve en premier lieu la méthode RAD
(Développement rapide d'applications) de James Martin (1991), puis DSDM la version anglaise du
RAD (1995). Plusieurs autres méthodes comme ASD ou FDD reconnaissent leur parenté directe
avec RAD (que certains de ses promoteurs présentent comme la première méthode Agile publiée).
Les deux méthodes Agiles les plus connues en France sont : la méthode Scrum (1996) et la méthode
XP pour Extreme programming (1999).
La notion de méthode agile a émergé avec des pratiques ciblant uniquement le développement d'une
application informatique. Mais un mouvement managérial plus large (Management Agile)
http://fr.wikipedia.org/wiki/M%C3%A9thode_agile 01/06/2010
commence à coupler les valeurs Agiles aux techniques de l'amélioration continue de la qualité
(MTQS ou Lean).
Sommaire
1 Historique
2 Valeurs
3 Principes
4 Méthodes Agiles reconnues par date de publication officielle
5 Autres Méthodes se reconnaissant de l'agilité
6 Tronc des pratiques communes à l'ensemble des méthodes Agiles
7 Pratiques différenciatrices des méthodes Agiles
8 Pratiques d'autres méthodes proches ou ayant un rapport avec les méthodes agiles
9 Optimisation des pratiques
10 Bibliographie
11 Voir aussi
11.1 Liens internes
11.2 Références
11.3 Liens externes
11.3.1 Communautés agiles
11.3.2 Autres sites traitant de l'agilité ou du génie logiciel
12 Autres liens
Historique
Évolution du courant de pensée Agile en matière de systèmes d'informations
En 1986, Barry W. Boehm présentait un nouveau modèle de développement itératif et incrémental.
En 1986 également, Hirotaka Takeuchi et Ikujiro Nonaka publient "the new product developpement
game" dans la Harvard business review. Leur article présente un modèle de développement basé sur
l'aptitude au changement, l'auto organisation, l'imbrication des phases de développement, et
l'itération (on y fait d'ailleurs mention du mot scrum par analogie au rugby).
En 1991, James Martin (RAD), s’appuyant sur cette vision d’une évolution continue, proposa une
méthode de développement rapide d’application. Sa structure, base des approches actuelles,
déterminait le phasage essentiel et mettait en œuvre un principe adaptatif fondé sur la validation
permanente des utilisateurs.
À partir de 1994, Jean-Pierre Vickoff en France, notamment avec le Processus RAD2 publié par le
Gartner Group, et Jennifer Stapleton en Grande-Bretagne, avec DSDM, introduisirent des
compléments tels que :
■ la spécialisation des rôles,

■ l’instrumentation des communications,
■ l’organisation des divers types de réunions,
■ le groupe de facilitation et de rapport,
■ les « raccourcis méthodologiques » de modélisation,
■ l’architecture de réalisation (imbrication des itérations),

■ la formalisation de processus légers de mise en œuvre.
Dans la seconde moitié des années 1990, une vague d’une dizaine de méthodes (dont Extreme
programming et Scrum sont les principales représentantes) poussa à l’extrême certaines pratiques de
qualité de la construction applicative ainsi que les techniques adaptatives d’estimation, de
planification et de pilotage de projet.
En 2001, aux États-Unis, dix-sept figures éminentes du développement logiciel se sont réunies pour
débattre du thème unificateur de leurs méthodes respectives, dites méthodes agiles. Les plus connus
d'entre eux étaient Ward Cunningham l'inventeur du Wiki via WikiWikiWeb, Kent Beck, père de
l'extreme programming et cofondateur de JUnit, Ken Schwaber et Jeff Sutherland, fondateurs de
Scrum, Jim Highsmith, prônant l'ASD, Alistair Cockburn pour la méthode Crystal clear, Martin
Fowler, et Dave Thomas ainsi que Arie van Bennekum pour DSDM (Dynamic System Development
Method). Ces 17 experts venant tous d'horizons différents réussirent à extraire de leur concepts
respectifs des critères pour définir une nouvelle façon de développer des logiciels :
De cette réunion devait émerger le Manifeste Agile, considéré comme la définition canonique du
1
développement Agile et de ses principes sous-jacents .
Le Manifeste Agile débute par la déclaration suivante (traduction) :
" Nous avons trouvé une voie améliorant le développement logiciel en réalisant ce travail et en
aidant les autres à le faire. De ce fait nous avons déduit des valeurs communes. "
Il aura fallu près de vingt années au mouvement Agile, parallèlement à la pression de la

mondialisation, pour bousculer vraiment la conduite de projet classique. Désormais, le futur de
l’agilité méthodologique se trouve certainement, d’une part, dans l’instrumentation et la
personnalisation « à la carte » des pratiques essentielles pour un contexte spécifique et, d’autre part,
dans son élargissement à tous les aspects de l’Agilité organisationnelle.
Valeurs
Dans ce but, elles prônent 4 valeurs fondamentales (entre parenthèse, les citations du manifeste) :
■ L'équipe (« Personnes et interaction plutôt que processus et outils ») : Dans l'optique agile,
l'équipe est bien plus importante que les outils (structurants ou de contrôle) ou les procédures de
fonctionnement. Il est préférable d'avoir une équipe soudée et qui communique composée de
développeurs (éventuellement à niveaux variables) plutôt qu'une équipe composée d'experts
fonctionnant chacun de manière isolée. La communication est une notion fondamentale.
■ L'application (« Logiciel fonctionnel plutôt que documentation complète ») : Il est vital que
l'application fonctionne. Le reste, et notamment la documentation technique, est une aide précieuse
mais non un but en soi. Une documentation précise est utile comme moyen de communication. La
documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle
n'est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de
transférer les compétences au sein de l'équipe (on en revient à l'importance de la communication).
■ La collaboration (« Collaboration avec le client plutôt que négociation de contrat ») : Le client

doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début
du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir
un feed-back continu sur l'adaptation du logiciel à ses attentes.
■ L'acceptation du changement (« Réagir au changement plutôt que suivre un plan ») : La

planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de
la demande du client tout au long du projet. Les premières releases du logiciel vont souvent
provoquer des demandes d'évolution.
Principes
Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles :
■ « Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels
utiles ».
■ « Le changement est bienvenu, même tardivement dans le développement. Les processus agiles
exploitent le changement comme avantage compétitif pour le client ».
■ « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec
une tendance pour la période la plus courte ».
■ « Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet ».
■ « Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont
elles ont besoin, et croyez en leur capacité à faire le travail ».
■ « La méthode la plus efficace pour transmettre l'information est une conversation en face à face ».
■ « Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet ».
■ « Les processus agiles promeuvent un rythme de développement durable. Commanditaires,
développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment ».
■ « Une attention continue à l'excellence technique et à la qualité de la conception améliore
l'agilité ».
■ « La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle ».
■ « Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-
organisent ».
■ « À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et
ajuste son comportement dans ce sens ».
Méthodes Agiles reconnues par date de publication officielle

■ Rapid Application Development (RAD, 1991)
■ Dynamic systems development method (DSDM, 1995, consortium anglais commercialisant le
RAD)
■ Scrum (1996)
■ Feature Driven Development(FDD) (1999)
■ Extreme programming (XP, 1999)
■ Adaptive software development (ASD, 2000)
■ Crystal clear (2004)
Autres Méthodes se reconnaissant de l'agilité

■ MACAO ([1] (http://www.jbcc.fr/presentationMACAO_Fr.php) )
■ Processus Urbanisant les Méthodes Agiles (PUMA (http://www.entreprise-agile.com/) )
■ KANBAN ([2] (http://fr.wikipedia.org/wiki/Kanban) )
Note RUP (Rational Unified Process) n'est pas une méthode Agile et, est de plus un produit propriété
d'IBM. Il existe une déclinaison Agile, mais non libre de droits, de RUP sous l'acronyme de AUP
(Agile Unified Process).
Tronc des pratiques communes à l'ensemble des méthodes

Agiles
1. Les pratiques communes liées aux ressources humaines
■ Participation de l’utilisateur final aux groupes de travail.
■ Groupes de travail disposant du pouvoir de décision.
■ Autonomie et organisation centralisée de l’équipe (motivation).
■ Spécification et validation permanente des Exigences.
2. Les pratiques communes liées au pilotage du projet
■ Niveau méthodologique variable en fonction des enjeux du projet.
■ Pilotage par les enjeux et les risques.
■ Planification stratégique globale basée sur des itérations rapides.
■ Réalisation en jalons par prototypage actif itératif et incrémental.
■ Recherche continue d’amélioration des pratiques.
3. Les pratiques communes liées à la qualité de la production
■ Recherche d’excellence technique de la conception.
■ Vision graphique d’une modélisation nécessaire et suffisante.
■ Vision de la documentation nécessaire et suffisante.
■ Normes et techniques raisonnables de qualité du code (métrique).
■ Architecture à base de composants.
■ Gestion des changements automatisée.
Pratiques différenciatrices des méthodes Agiles

Seules quelques techniques complémentaires entre elles, ou mieux adaptées à des typologies et à des
tailles de projets spécifiques, différencient les méthodes Agiles (y compris ASD ou Crystal Clear).
Les pratiques différenciatrices les plus marquantes sont :
■ La méthode DSDM se particularise par la spécialisation des acteurs du projet dans une notion de
« rôles ». Ainsi, l'on trouvera dans les réunions DSDM des sponsors exécutifs, des ambassadeurs,
des utilisateurs visionnaires, des utilisateurs conseillers, sans oublier l'animateur-facilitateur et des
rapporteurs.
■ La méthode Scrum affirme sa différence dans des pratiques de courtes réunions quotidiennes
(Stand-Up meeting). Ces temps de travail commun ont pour objectifs d'améliorer la motivation des
participants, de synchroniser les tâches, de débloquer les situations difficiles et d'accroître le
partage de la connaissance.
■ Pour FDD, la particularité nommée Mission focused réside dans une forte orientation vers un but
immédiat mesurable guidé par la notion de valeur métier. C'est en fait l'ambition globale d'une
itération qui se trouve ainsi renforcée. Cet aspect se retrouve aussi dans la méthode RAD sous la
forme des objectifs de Focus ou dans Scrum dans la notion de Sprint. FDD préconise aussi le
Features Driven Development. Cette technique se caractérise par des notions de Feature et de
Features set (fonctionnalités et groupes de fonctionnalités). La priorité est donnée aux
fonctionnalités porteuses de valeur. Le RAD propose des techniques proches : livraison en

fonctionnalité réduite ou livraison par thèmes.
■ XP (extreme programming) est très axé sur la partie Construction de l'application. Une de ses
originalités réside dans l’approche de planification qui se matérialise sous la forme d’un jeu intitulé
Planning game et qui implique simultanément les utilisateurs et les développeurs. On notera aussi
des techniques particulières liées à la production du code comme la programmation en binôme
(Pair programming), l'appropriation collective du code, la Refactorisation (refactoring) et l'
Intégration continue. La méthode RAD préconise dans ce sens des revues de code personnelles,
puis collectives et l'intégration avant chaque Focus (ou Show). Par contre, le RAD limite la
programmation en binôme aux parties les plus stratégiques.
Pratiques d'autres méthodes proches ou ayant un rapport avec

les méthodes agiles
■ 2TUP (2 track unified process, prononcez "toutiyoupi") préconise un cycle de vie en Y qui dissocie
la résolution des questions fonctionnelles et techniques. Le cycle de vie de 2TUP s'apparente à un
cycle de développement en cascade mais introduit une forme itérative interne à certaines tâches. Il
n'est pas certain que ce cycle s'apparente réellement à une approche Agile. Par contre, 2TUP
préconise des formes de recherche de qualité et de performance intéressantes telles que les services
réutilisables et la conception générique (Framework et Patron de conception Design pattern)
proches des mécanismes architecturaux de RUP.
■ RUP se caractérise par une approche globale nommée « Vue 4+1 ». Les 5 composants de cette vue
sont : la vue des Cas d'utilisation, la vue Logique, la vue d'Implémentation, la vue du Processus, la
vue du Déploiement. RUP offre aussi, à l'identique du RAD 2, un Processus guide formel et
adaptable comme guide d'activité. Dans le cas de RUP, il est malheureusement propriétaire et
orienté outil.
■ Le plus sérieux apport du RAD à la communication de projet et à la formalisation des exigences

applicatives : le Groupe d'Animation et de Rapport (GAR).
■ Le RAD dans sa version 2 recommande la variabilité de la taille et de la maturité des groupes de

travail en fonction des phases du projet afin d'optimiser l'engagement des ressources et de
préserver leur intérêt par un travail adapté à leurs préoccupations.
■ Avec RAD 2, l'organisation performante des réunions est basée sur un mode opératoire des
entretiens et sur des techniques de validation permanente.
■ Toute méthode de conduite de projet devrait inclure un mode opératoire pour les arrêts d'urgence
(Go/NoGo). Sur ce point la force du RAD se situe dans la présence d'un animateur-facilitateur.
Cette ressource, de préférence externe, doit être neutre en regard des autres intervenants. Elle
répond à une autorité supérieure à tous les participants du projet. Ainsi, lorsque le contexte
stratégique, économique ou technique d'un projet évolue, ou si les conditions de réalisation se
dégradent, l'animateur reporte le problème au dirigeant qui l'a mandaté. Ce dernier peut alors
prendre, dans les meilleurs délais, et avec des informations objectives les décisions qui s'imposent.
■ Le RAD comme les autres méthodes Agiles préconise la formation d'une équipe de développement
particulière, le SWAT (Skill With Advanced Tools dérivé de Special Weapons And Tactics). Cette
équipe est autonome, spécialement formée, concrètement motivée et outillée. Elle se compose
essentiellement d'un profil unique de concepteurs-développeurs formés à des spécialités techniques
complémentaires. Le SWAT travaille avec les utilisateurs dans une salle permanente spécialement
équipée style War Room qui transforme les murs en Information Radiator (une forme de cokpit de
management de projet).
Optimisation des pratiques

Selon Jean-Pierre Vickoff dans la communication PUMA (Proposition pour l'Unification des
Méthodes Agiles)[3] (http://www.adeli.org/voirdoc.php?dest=lalettre/l48p19.pdf) publié sur le site
de ADELI (Association pour la maitrise des Systèmes d'Information) " La méthode Agile idéale
s'appuierait sur une utilisation optimisée des pratiques du tronc commun et s'enrichirait d'une
sélection des pratiques spécifiques utiles à un contexte projet particulier. "
Bibliographie
■ Agile Modeling, Ron Jeffries et Scott W. Ambler , John Wiley & Sons, 2002, (ISBN 0471202827)
■ L'eXtreme Programming, de Jean-Louis Bénard,Laurent Bossavit, Régis Médina, Dominic

Williams Eyrolles 2002 (ISBN 221211561X)
■ Maîtriser les projets avec XP : Pilotage par les tests-client, Thierry Cros, Editions Cépadues,
2004, (ISBN 2854286391)
■ AGILE, l’Entreprise et ses projets, Jean-Pierre Vickoff, QI, 2007, (ISBN 2912843006)
■ Systèmes d'information et processus Agiles, Jean-Pierre Vickoff, Hermes Science Publication,

2003 (ISBN 2746207028)
Voir aussi
Liens internes
■ Management Agile
■ Agile Alliance
■ Principes de gestion agiles
■ Cycle de développement
Références
1. ↑ "The Agile Manifesto was put forward in 2001, and several method instantiations, such as XP, SCRUM, and
Crystal exist.", Kieran Conboy & Brian Fitzgerald, Extreme Programming And Agile Methods - XP/Agile
Universe 2004: 4th Conference On Extreme Programming And Agile Methods, Calgary, Canada, August 15-
18, 2004, Proceedings, chap. Toward a Conceptual Framework of Agile Methods, Springer Verlag, New York,
août 2004, (ISBN 354022839X), lien (http://books.google.fr/books?
hl=en&lr=&id=tmvI_a4YUNMC&oi=fnd&pg=PA105&ots=xejboEQhET&sig=ULAr0yaORppprWTgs8Sne0x
Liens externes
Communautés agiles
■ (en) Le manifeste des méthodes agiles (http://agilemanifesto.org/)

■ (en) Agile Alliance (http://www.agilealliance.com/)
■ (en) Declaration of Interdependence (http://pmdoi.org/)
■ (fr) La communauté eXtreme Programing Francaise (http://xp-france.net/cgi-bin/wiki.pl)

■ (fr) La Communauté Agile Suisse (http://www.agile-swiss.org/wiki/index.php/Accueil)
■ (fr) La Communauté Agile de Québec (http://www.agilequebec.ca/)
■ (fr) La Communauté Agile de Montréal (http://www.agilemontreal.ca/)
■ (en) Site de la méthode xp (http://www.extremeprogramming.org/)
■ (fr) Le Club Agile Rhône-Alpes (http://clubagile.org/)
Autres sites traitant de l'agilité ou du génie logiciel
■ (fr) Synergies entre CMMI et les méthodes agiles (http://blog.octo.com/synergies-entre-cmmi-et-

les-methodes-agiles/)
■ (fr) Association pour la maîtrise des systèmes d'informations (http://www.adeli.org/)
■ (fr) Site historique de la méthode RAD (http://www.rad.fr/)
Autres liens
Principes de gestion agiles
Ce document provient de « http://fr.wikipedia.org/wiki/M%C3%A9thode_agile ».
Dernière modification de cette page le 28 mai 2010 à 14:34.

Droit d'auteur : les textes sont disponibles sous licence Creative Commons paternité partage à
l’identique ; d’autres conditions peuvent s’appliquer. Voyez les conditions d’utilisation pour plus de
détails, ainsi que les crédits graphiques. En cas de réutilisation des textes de cette page, voyez
comment citer les auteurs et mentionner la licence.
Wikipedia® est une marque déposée de la Wikimedia Foundation, Inc., organisation de bienfaisance
régie par le paragraphe 501(c)(3) du code fiscal des États-Unis.
Manifeste agile - Wikipédia Page 1 of 3
Manifeste agile
Le Manifeste Agile est un texte rédigé par 17 experts reconnus pour leurs apports respectifs au
développement d'applications informatiques sous la forme de plusieurs méthodes dont les plus
connues sont Extreme Programming et Scrum. Ces experts estimaient que le traditionnel cycle de
développement en cascade ne correspondait plus aux nouveaux besoins applicatifs. Le Manifeste
Agile est considéré comme l'acte généralisateur des méthodes agiles sous la dénomination initiale de
Agile Manifesto [1] (http://agilemanifesto.org/) . Les valeurs et principes du Manifeste Agile sont
défendus par l'Agile Alliance.
Sommaire
1 Introduction
2 Les 4 valeurs
3 Les 12 principes
4 Résumé de la mise en pratique
5 Organisation
6 Notes et références
7 Voir aussi
7.1 Articles connexes
7.2 Bibliographie
7.3 Liens externes
Introduction
En 2001, aux États-Unis, dix-sept figures éminentes du développement logiciel se sont réunies pour
débattre du thème unificateur de leurs méthodes respectives, dites méthodes agiles. Les plus connus
d'entre eux étaient Ward Cunningham l'inventeur du Wiki via WikiWikiWeb, Kent Beck, père de
l'extreme programming et cofondateur de JUnit, Ken Schwaber et Jeff Sutherland, fondateurs de
Scrum, Jim Highsmith, prônant l'ASD, Alistair Cockburn pour la méthode Crystal clear, Martin
Fowler, et Dave Thomas ainsi que Arie van Bennekum pour DSDM (Dynamic System Development
Method) la version anglaise du RAD (Développement rapide d'applications). Ces 17 experts venant
tous d'horizons différents réussirent à extraire de leur concepts respectifs des critères pour définir une
nouvelle façon de développer des logiciels :
De cette réunion devait émerger le Manifeste Agile, considéré comme la définition canonique du
1
développement Agile et de ses principes sous-jacents .
Le Manifeste Agile débute par la déclaration suivante (traduction) :
" Nous avons trouvé une voie améliorant le développement logiciel en réalisant ce travail et en aidant
les autres à le faire. De ce fait nous avons déduit des valeurs communes. "
Le Manifeste Agile est constitué de 4 valeurs et de 12 principes fondateurs.
http://fr.wikipedia.org/wiki/Manifeste_Agile 01/06/2010
Les 4 valeurs
2
Les quatre valeurs fondamentales Agiles sont :
■ Davantage l’interaction avec les personnes que les processus et les outils.
■ Davantage un produit opérationnel qu’une documentation pléthorique.
■ Davantage la collaboration avec le client que la négociation de contrat.
■ Davantage la réactivité face au changement que le suivi d'un plan.
Les 12 principes
■ Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.
■ Le changement est accepté, même tardivement dans le développement. Les processus agiles
exploitent le changement comme avantage compétitif pour le client.
■ Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une
tendance pour la période la plus courte.
■ Les experts métier et les développeurs doivent collaborer quotidiennement au projet.
■ Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont
elles ont besoin, et croyez en leur capacité à faire le travail.
■ La méthode la plus efficace pour transmettre l'information est une conversation en face à face.
■ Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
■ Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires,

développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
■ Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité.
■ La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.
■ Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-
organisent.
■ À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste
son comportement dans ce sens.
Résumé de la mise en pratique

Le développement Agile, appelé aussi développement adaptatif, se caractérise donc par un style de
conduite de projet itératif incrémental, centré sur l’autonomie des ressources humaines impliquées
dans la spécification, la production et la validation d’une application intégrée et testée en continu
(Méthode Agile).
C’est à partir de ces réalités pratiques, et non pas sur la base d’une théorie globale ou structurante, que
l’Agilité progresse vers les sphères les plus hautes de l’organisation.
Organisation
L'Agile Alliance est une organisation sans but lucratif chargée de promouvoir à l'échelle mondiale les
valeurs et principes du Manifeste Agile.
Notes et références
1. ↑ "The Agile Manifesto was put forward in 2001, and several method instantiations, such as XP, SCRUM, and
Crystal exist.", Kieran Conboy & Brian Fitzgerald, Extreme Programming And Agile Methods - XP/Agile
Universe 2004: 4th Conference On Extreme Programming And Agile Methods, Calgary, Canada, August 15-18,
2004, Proceedings, chap. Toward a Conceptual Framework of Agile Methods, Springer Verlag, New York, août
2004, (ISBN 354022839X), lien (http://books.google.fr/books?
hl=en&lr=&id=tmvI_a4YUNMC&oi=fnd&pg=PA105&ots=xejboEQhET&sig=ULAr0yaORppprWTgs8Sne0x9
2. ↑ (en) Manifesto for Agile Software Development (http://agilemanifesto.org/)
Voir aussi
Articles connexes
■ Méthode agile
Bibliographie
■ (en) Agile Software Development Ecosystems: Problems, Practices, and Principles, Jim
Highsmith, Addison-Wesley, 2002 (ISBN 0201760436). Lien (http://books.google.fr/books?
id=10Ow8GomG80C&printsec=frontcover&hl=en)
Liens externes
■ (en) The Agile Manifesto, Août 2001 (http://www.hristov.com/andrey/fht-

stuttgart/The_Agile_Manifesto_SDMagazine.pdf)
■ Les signataires actuels du manifeste (http://agilemanifesto.org/sign/display.cgi)
Ce document provient de « http://fr.wikipedia.org/wiki/Manifeste_agile ».

Scrum - Wikipédia Page 1 of 19
Scrum
Scrum est une méthode agile pour la gestion de projets. Elle a été conçue pour améliorer grandement
la productivité dans les équipes auparavant paralysées par des méthodologies plus lourdes.
La méthode Scrum a été conçue pour la gestion de projets de développement de logiciels. Elle peut
aussi être utilisée par des équipes de maintenance. Dans le cas de très grands projets, les équipes se
multiplient et on parle alors de Scrum de Scrums. La méthode Scrum peut théoriquement s'appliquer à
n'importe quel contexte ou à un groupe de personnes qui travaillent ensemble pour atteindre un but
commun (comme gérer une petite école, des églises, des projets de recherche scientifique ou planifier
un mariage).
http://fr.wikipedia.org/wiki/Scrum 01/06/2010
Par contre, la méthode Scrum ne couvre aucune technique d'ingénierie du logiciel. Aussi, son
utilisation dans le contexte du développement d'une application informatique nécessite de lui
adjoindre une méthode complémentaire (comme l' Extreme Programming, par exemple).
Sommaire
1 Historique
2 Caractéristiques
3 Quelques rappels sur les méthodes agiles
3.1 Origine
3.2 Grands principes
3.2.1 Individus et interactions contre processus et outils
3.2.2 Logiciel qui fonctionne contre documentation exhaustive
3.2.3 Collaboration du client contre négociation de contrat
3.2.4 Réponse au changement contre suivi d'un plan prédéfini
3.3 Idées clé
4 Rôles
4.1 Directeur de produit
4.2 Équipe
4.3 Facilitateur / Animateur
4.4 Intervenants
5 Planification
5.1 Sprints
5.2 Releases
5.3 Quotidien
6 Gestion des besoins
6.1 Backlog de produit
6.2 Backlog de sprint
7 Estimations
7.1 Items de backlog de produit
7.2 Calcul de vélocité
7.3 Items de backlog de sprint
8 Déroulement d'un sprint
8.1 Réunion de planification
8.2 Au quotidien
8.3 Revue de sprint
8.4 Rétrospective du sprint
9 Compléments
9.1 Lancement du projet
9.2 Vue globale
9.3 Burndown Charts
9.3.1 Sprint Burndown Chart
9.3.2 Release Burndown Chart
9.3.3 Interprétation
9.4 Qualité de l'environnement de travail
9.5 Documentation de projet
9.6 Outils pour Scrum
9.6.1 Papier et crayon / tableur
9.6.2 Outils libres
9.6.3 Outils propriétaires
9.6.4 Autres outils
10 Conclusion
10.1 Scrum
10.2 Mise en garde
11 Glossaire
12 Voir aussi
12 1 Articles connexes
Historique
En 1986, Hirotaka Takeuchi et Ikujiro Nonaka décrivent une nouvelle approche holistique qui
1
augmenterait la vitesse et la flexibilité dans le développement commercial de nouveaux produits .
Dans celle-ci les phases se chevauchent fortement et l'ensemble du processus est réalisé par une
équipe aux compétences croisées à travers différentes phases. Ils ont comparé cette nouvelle approche
au rugby, où l'équipe essaye d'avancer unie, en faisant circuler la balle (« tries to go to the distance as
a unit, passing the ball back and forth »).
2
En 1991, DeGrace et Stahl, dans "Wicked problems, righteous solutions" , font référence à cette
approche comme Scrum (mêlée, en anglais), un terme de rugby mentionné dans l'article de Takeuchi
et Nonaka. Dans le début des années 1990, Ken Schwaber a utilisé une approche qui a conduit à
Scrum au sein de son entreprise, Advanced Development Methods. En même temps, Jeff Sutherland,
John Scumniotales et Jeff McKenna développent une approche similaire à Easel Corporation et sont
3
les premiers à appeler cela Scrum . En 1995, Sutherland et Schwaber ont présenté conjointement un
document décrivant Scrum à l'OOPSLA de 1995 à Austin. Schwaber et Sutherland ont collaboré au
cours des années suivantes pour fusionner les publications, leurs expériences et les meilleures
pratiques du secteur en ce qui est maintenant connu comme Scrum. En 2001, Schwaber fait équipe
avec Mike Beedle pour décrire la méthode dans le livre "Agile Software Development With Scrum".
En France, le premier livre français entièrement consacré à Scrum est publié en février 2010 :
4
"SCRUM : Le guide pratique de la méthode agile la plus populaire" .
Caractéristiques
Le terme Scrum est emprunté au rugby et signifie mêlée. Ce processus s'articule en effet autour d'une
équipe soudée, qui cherche à atteindre un but, comme c'est le cas en rugby pour avancer avec le
ballon pendant une mêlée.
Le principe de base de Scrum est de focaliser l'équipe de façon itérative sur un ensemble de
fonctionnalités à réaliser, dans des itérations de durée fixe de une à quatre semaines, appelées sprints.
Chaque sprint possède un but à atteindre, défini par le directeur de produit, à partir duquel sont
choisies les fonctionnalités à implémenter dans ce sprint. Un sprint aboutit toujours sur la livraison
d'un produit partiel fonctionnel. Pendant ce temps, le ScrumMaster a la charge de réduire au
maximum les perturbations extérieures et de résoudre les problèmes non techniques de l'équipe.
Un principe fort en Scrum est la participation active du client pour définir les priorités dans les
fonctionnalités du logiciel et pour choisir celles qui seront réalisées dans chaque sprint. Il peut à tout
moment compléter ou modifier la liste des fonctionnalités à réaliser, mais jamais celles qui sont en
cours de réalisation pendant un sprint.
Quelques rappels sur les méthodes agiles
Origine
En 2001, 17 représentants des méthodes légères alternatives aux processus lourds traditionnels se sont
réunis pour trouver les points communs à leurs méthodes "to find common ground". De cette réunion
5
de quelques jours est né le Manifeste Agile : un texte bref énonçant des grands concepts, simples,
mais qui proposent une nouvelle façon de penser un projet de développement informatique. Si
certains dénoncent une certaine évidence de ces concepts, il n'en est pas moins que ce manifeste a
pour lui le mérite de les formaliser et surtout de les structurer en un tout homogène et cohérent, par
opposition aux pratiques semblables mais complètement hétérogènes d'une entreprise à l'autre et d'un
projet à l'autre.
Grands principes
Le manifeste agile résume sa philosophie en quatre oppositions entre les concepts traditionnels et les
concepts proposés.
Individus et interactions contre processus et outils
Ce sont les individus qui font la valeur du travail accompli, ce sont donc eux que l’on doit privilégier.
Sans l’artisan, les meilleurs outils ne servent à rien. Les processus qui définissent ce que doit faire
chaque personne brident le potentiel caché derrière chacun : faire interagir les gens au maximum est
bien plus fructueux et permet d'améliorer grandement l'efficacité et la qualité du travail fourni, en
rassemblant des visions différentes d'un même problème.
Logiciel qui fonctionne contre documentation exhaustive
Les processus lourds génèrent une documentation qui se veut exhaustive avec tous ses inconvénients :
ambigüité du langage, coût de la rédaction, coût du maintien en accord avec la réalité, etc. Ces
documents ne sont qu'une illusion d'avancement du projet. Même une conception technique initiale
peut être complètement remise en cause en phase de codage (ou après) : comment peut-on alors
déterminer l'avancement du projet ? Une régression ?
Dans les méthodes Agiles, un seul critère permet de mesurer l'avancement d'un projet : le logiciel qui
fonctionne. La documentation n'est qu'un support concret qui aide à produire le logiciel.
Collaboration du client contre négociation de contrat
Dans tout projet, le but premier est de gagner de l’argent, autant pour le client (rentabilisation) que
pour le fournisseur (prestation). Si la négociation protège plus ou moins des risques financiers, elle
peut provoquer l’échec des projets (délais non respectés, budgets insuffisants) et engendrer
d'interminables procès où tout le monde y perd au bout du compte (le client n'a pas son logiciel et le
fournisseur ferme boutique).
Il faut sortir de la guerre client/fournisseur et penser en équipe qui veut atteindre un but commun :
réussir le projet.
Réponse au changement contre suivi d'un plan prédéfini
Un plan prédéfini a tendance à nous rendre autistes aux événements qui surviennent pendant le projet.
Il est en plus à l'origine des conflits client/fournisseur classiques sur les délais de livraison. Pour le
client, pouvoir adapter les besoins en cours de projet est un atout concurrentiel : il est réactif aux
fluctuations des marchés et s'assure en plus que le logiciel développé répond parfaitement à ses
véritables besoins.
Les méthodes Agiles sont conçues pour s’adapter au changement, en assurant un plan macroscopique
précis et adaptatif.
Idées clé
■ Le client au cœur du projet

■ Esprit d’équipe
■ La communication est la clé
■ Simplicité, efficacité et qualité
■ Flexibilité aux changements
■ Avancement basé sur le concret
Rôles
Scrum définit trois rôles principaux : le
directeur de produit, le facilitateur /
animateur et l'équipe. Des intervenants
peuvent s'intégrer également au projet de façon
plus ponctuelle.
Directeur de produit
Le directeur de produit (Product Owner) est le

représentant des clients et utilisateurs. C'est lui
qui définit l'ordre dans lequel les fonctionnalités
Rôles dans Scrum seront développées et qui prend les décisions
importantes concernant l'orientation du projet.
Le terme directeur n'est d'ailleurs pas à prendre
au sens hiérarchique du terme, mais dans le sens de l'orientation.
Dans l'idéal, le directeur de produit travaille dans la même pièce que l'équipe. Il est important qu'il
reste très disponible pour répondre aux questions de l'équipe et pour lui donner son avis sur divers
aspects du logiciel (interface par exemple).
Équipe
L'équipe ne comporte pas de rôles prédéfinis, elle est auto-gérée. Il n'y a pas non plus de notion de
hiérarchie interne : toutes les décisions sont prises ensemble et personne ne donne d'ordre à l'équipe
sur sa façon de procéder. Contrairement à ce que l'on pourrait croire, les équipes auto-gérées sont
celles qui sont les plus efficaces et qui produisent le meilleur niveau de qualité de façon spontanée.
L'équipe s'adresse directement au directeur de produit. Il est conseillé qu'elle lui montre le plus
souvent possible le logiciel développé pour qu'il puisse ajuster les détails d'ergonomie et d'interface
par exemple.
Facilitateur / Animateur
Le facilitateur / animateur (ScrumMaster) joue un rôle capital : c'est lui qui est chargé de protéger
l'équipe de tous les éléments perturbateurs extérieurs à l'équipe et de résoudre ses problèmes non
techniques (administratifs par exemple). Il doit aussi veiller à ce que les valeurs de Scrum soient
appliquées, mais il n'est pas un chef de projet ni un intermédiaire de communication avec les clients.
On parle parfois d'équipe étendue, qui intègre en plus le ScrumMaster et le directeur de produit. Ce
concept renforce l'idée que client et fournisseur travaillent d'un commun effort vers le succès du
projet.
Intervenants
Les intervenants (Stakeholders) sont les personnes qui souhaitent avoir une vue sur le projet sans
réellement s'investir dedans. Il peut s'agir par exemple d'experts techniques ou d'agents de direction
qui souhaitent avoir une vue très éloignée de l'avancement du projet.
Planification
Scrum utilise une planification à trois
niveaux : release/projet, sprint et
quotidien.
Sprints
Scrum est un processus itératif : les Exemple de planification en Scrum

itérations sont appelées des sprints et
durent en théorie 30 jours calendaires. En
pratique, les itérations durent généralement entre 2 et 4 semaines. Chaque sprint possède un but et on
lui associe une liste d'items de backlog de produit (fonctionnalités) à réaliser. Ces items sont
décomposés par l'équipe en tâches élémentaires de quelques heures, les items de backlog de sprint.
Pendant un sprint, les items de backlog de sprint à réaliser ne peuvent pas être changés. Les
changements éventuels sont pris en compte dans le backlog de produit et seront éventuellement
réalisés dans les sprints suivants.
Il y a une exception à cela : il se peut que l'équipe se rende compte en cours du sprint qu'elle n'aura
pas le temps de terminer un item du backlog de sprint ou au contraire qu'elle aura fini en avance. Dans
ce cas, et seulement d'un commun accord entre l'équipe et le directeur du produit, on peut enlever ou
ajouter un item à ce qui a été prévu.
Releases
Pour améliorer la lisibilité du projet, on regroupe généralement des itérations en releases. Bien que ce
concept ne fasse pas explicitement partie de Scrum, il est utilisé pour mieux identifier les versions. En
effet, comme chaque sprint doit aboutir à la livraison d'un produit partiel, une release permet de
marquer la livraison d'une version aboutie, susceptible d'être mise en exploitation.
Il est intéressant de planifier à l'échelle d'une release, en répartissant les items du backlog de produit
sur les sprints, en respectant leur priorité. Bien entendu, ce qui est planifié au-delà du sprint courant
peut changer à tout moment, rien n'est figé à l'avance.
Quotidien
Au quotidien, une réunion, le ScrumMeeting, permet à l'équipe et au ScrumMaster de faire un point

d'avancement sur les tâches et sur les difficultés rencontrées.
Gestion des besoins
Backlog de produit
Scrum utilise une approche fonctionnelle pour récolter les besoins des utilisateurs. L'objectif est
d'établir une liste de fonctionnalités à réaliser, que l'on appelle backlog de produit (NDT : Le terme
backlog peut être traduit par cahier, liste ou carnet de commandes, qui ne collent pas bien avec l'esprit
du terme anglais qui évoque aussi une réserve, un retard accumulé ; aussi ce terme a été gardé tel
quel).
À chaque item de backlog sont associés deux attributs : une estimation en points arbitraires (voir
Estimation) et une valeur client, qui est définie par le directeur de produit (retour sur investissement
par exemple). Ce dernier définit dans quel ordre devront être réalisés ces items. Il peut changer cet
ordre en cours de projet et même ajouter, modifier ou supprimer des items dans le backlog.
La somme des points des items du backlog de produit constitue le reste à faire total du projet. Cela
permet de produire un release burndown chart, qui montre les points restant à réaliser au fur et à
mesure des sprints.
Remarque : il arrive souvent qu'on utilise dans Scrum les User Stories de la méthode Extreme
Programming, qui proposent des pratiques et des techniques intéressantes (le Planning poker pour les
estimer par exemple).
Backlog de sprint
Lorsqu'on démarre un sprint, on choisit quels items du backlog de produit seront réalisés dans ce
sprint. L'équipe décompose ensuite chaque item en liste de tâches élémentaires (techniques ou non),
chaque tâche étant estimée en heures et ne devant pas durer plus de 2 jours. On constitue ainsi le
backlog de sprint.
Pendant le déroulement du sprint, chaque équipier s'affecte des tâches du backlog de sprint et les
réalise. Il met à jour régulièrement dans le backlog du sprint le reste à faire de chaque tâche. Les
tâches ne sont pas réparties initialement entre tous les équipiers, elles sont prises au fur et à mesure
que les précédentes sont terminées.
La somme des heures des items du backlog de sprint constitue le reste à faire total du sprint. Cela
permet de produire un sprint burndown chart qui montre les heures restantes à réaliser au fur et à
mesure du sprint.
Estimations
Scrum ne définit pas spécialement d'unités pour les items des backlogs. Néanmoins, certaines
techniques se sont imposées de fait.
Items de backlog de produit
Les items de backlog de produit sont souvent des User Stories empruntées à Extreme Programming.
Ces User Stories sont estimées en points relatifs, sans unité. L'équipe prend un item représentatif et lui
affecte un nombre de points arbitraire. Cela devient un référentiel pour estimer les autres items. Par
exemple, un item qui vaut 2 points représente deux fois plus de travail qu'un item qui en vaut 1. Pour
les valeurs, on utilise souvent les premières valeurs de la suite de Fibonacci (1,2,3,5,8,13), qui évitent
les difficultés entre valeurs proches (8 et 9 par exemple).
L'intérêt de cette démarche est d'avoir une idée du travail requis pour réaliser chaque fonctionnalité
sans pour autant lui donner une valeur en jours que le directeur de produit serait tenté de considérer
comme définitivement acquise. En revanche, on utilise la vélocité pour planifier le projet à l'échelle
macroscopique de façon fiable et précise.
Calcul de vélocité
Une fois que tous les items de backlog de produit ont été estimés, on attribue un certain nombre
d'items à réaliser aux sprints successifs. Ainsi, une fois un sprint terminé, on sait combien de points
ont été réalisés et on définit alors la vélocité de l'équipe, c'est-à-dire le nombre de points qu'elle peut
réaliser en un sprint.
En partant de cette vélocité et du total de points à réaliser, on peut déterminer le nombre de sprints qui
seront nécessaires pour terminer le projet (ou la release en cours). L'intérêt, c'est qu'on a une vision de
plus en plus fiable (retours d'expérience de sprint en sprint) de la date d'aboutissement du projet, tout
en permettant d'aménager les items de backlog du produit en cours de route.
Items de backlog de sprint
Les items de backlog de sprint sont généralement exprimés en heures et ne doivent pas dépasser 2
journées de travail, auquel cas il convient de les décomposer en plusieurs items. Par abus de langage,
on emploie le terme de tâches, les concepts étant très proches.
Déroulement d'un sprint
Réunion de planification
Tout le monde est présent à cette réunion, qui ne doit pas durer plus de 4 heures. La réunion de
planification (Sprint Planning) consiste à définir d'abord un but pour le sprint, puis à choisir les items
de backlog de produit qui seront réalisés dans ce sprint. Cette première partie du sprint planning
représente l'engagement de l'équipe. Compte tenu des conditions de succès énoncées par le directeur
de produit et de ses connaissances techniques, l'équipe s'engage à réaliser un ensemble d'items du

backlog de produit.
Dans un second temps, l'équipe décompose chaque item du backlog de produit en liste de tâches
(items du backlog du sprint), puis estime chaque tâche en heures. Il est important que le directeur de
produit soit présent dans cette étape, il est possible qu'il y ait des tâches le concernant (comme la
rédaction des règles métier que le logiciel devra respecter et la définition des tests fonctionnels).
Au quotidien
Chaque journée de travail commence par une réunion de 15 minutes maximum appelée mêlée
quotidienne (Daily Scrum). Seuls l'équipe, le directeur de produit et le ScrumMaster peuvent parler,
tous les autres peuvent écouter mais pas intervenir (leur présence n'est pas obligatoire). A tour de rôle,
chaque membre répond à 3 questions :
■ Qu'est-ce que j'ai fait hier ?

■ Qu'est-ce que je compte faire aujourd'hui ?
■ Quelles sont les difficultés que je rencontre ?
Le tour de parole doit être scrupuleusement respecté pour éviter que le Scrum dérive sur des
discussions techniques et déborde des 15 minutes. Si le besoin s'en fait sentir, des discussions sont
alors menées librement après le Scrum.
Cette réunion a un but de synchronisation pour l'équipe et ne doit pas être vécue comme un reporting
d'activité. C'est le niveau quotidien du principe inspect and adapt de Scrum.
L'équipe se met ensuite au travail. Elle travaille dans une même pièce, dont le ScrumMaster a la
responsabilité de maintenir la qualité de son environnement. Les activités se déroulent éventuellement
en parallèle : analyse, conception, codage, intégration, tests, etc. Scrum ne définit volontairement
pas de démarche technique pour le développement du logiciel : l'équipe s'auto-gère et décide en toute
autonomie de la façon dont elle va travailler.
Remarque : Il est assez fréquent que les équipes utilisent la démarche de développement guidé par les
tests. Cela consiste à coder en premier lieu les modules de test vérifiant les contraintes métier, puis à
coder ensuite le logiciel à proprement parler, en exécutant les tests régulièrement. Cela permet de
s'assurer entre autres de la non-régression du logiciel au fil des sprints.
Revue de sprint
À la fin du sprint, tout le monde se réunit pour effectuer la revue de sprint, qui dure au maximum 4
heures. L'objectif de la revue de sprint est de valider le logiciel qui a été produit pendant le sprint.
L'équipe commence par énoncer les items du backlog de produit qu'elle a réalisés. Elle effectue
ensuite une démonstration du logiciel produit. C'est sur la base de cette démonstration que le directeur
de produit valide chaque fonctionnalité planifiée pour ce sprint.
Une fois le bilan du sprint réalisé, l'équipe et le directeur de produit proposent des aménagements sur
le backlog du produit et sur la planification provisoire de la release. Il est probable qu'à ce moment
des items soient ajoutés, modifiés ou réestimés, en conséquence de ce qui a été découvert
Rétrospective du sprint
La rétrospective du sprint est faite en interne à l'équipe (incluant le ScrumMaster). L'objectif est de
comprendre ce qui n'a pas bien marché dans le sprint, les erreurs commises et de prendre des
décisions pour s'améliorer. Il est tout à fait possible d'apporter des aménagements à la méthode Scrum
dans le but de s'améliorer. Il faut être très vigilant à ne pas retomber dans des pratiques rigides des
méthodologies plus classiques.
Compléments
Lancement du projet
Scrum présuppose que le backlog de produit est déjà défini au début du projet. Une approche possible
pour constituer ce backlog est de réaliser une phase de lancement. Cette phase de lancement
s'articule autour de deux axes de réflexion : l'étude d'opportunité et l'expression initiale des besoins.
L'étude d'opportunité est très variable d'un projet à l'autre, tout dépend du contexte de l'entreprise, de
la nature du projet (sous-traitance ou interne), etc. Chaque entreprise a sa propre politique sur cette
activité.
L'expression initiale des besoins n'est pas un élément défini dans Scrum et n'est surtout pas une
activité de contractualisation d'un cahier des charges. L'esprit d'une telle activité dans les méthodes
Agiles est de définir d'une part le cadre du projet (pour que l'équipe s'imprègne du contexte métier)
et d'autre part une première analyse globale des besoins. L'objectif est d'identifier un maximum de
fonctionnalités que le logiciel devra implémenter, en se limitant à un niveau de précision assez
grossier. On peut par exemple utiliser une approche par raffinages successifs, en partant des secteurs
métiers concernés par l'application, puis en identifiant les activités métier, qu'on décompose en tâches
métier qui correspondent à des fonctionnalités que l'on doit/peut ou non implémenter dans le logiciel
final.
L'objectif pour Scrum est de produire la première version du backlog de produit.
Vue globale
Vue synthétique du processus Scrum
Burndown Charts
Les burndown charts (graphiques d'avancement) permettent de visualiser graphiquement

l'avancement du travail. Une interprétation simple permet d'avoir une idée sur les échéances futures.
Sprint Burndown Chart
Exemple de Sprint Burndown Chart
Ce graphique représente la quantité totale d'heures restantes à faire dans le sprint, au fil des jours. Il
permet d'avoir une vue sur l'avancement du sprint.
Release Burndown Chart
Exemple de Release Burndown Chart
Ce graphique représente la quantité totale de points restant à faire dans la release, au fil des sprints. Il
permet d'avoir une vue sur l'avancement de la release.
Interprétation
Ces graphiques sont très intéressants à analyser et interpréter. Outre le fait de montrer l'avancement
concret du travail, ils permettent d'anticiper de façon relativement fiable les échéances futures en
cours du sprint ou de la release.
On peut observer de légères augmentations du reste à faire sur le burndown chart du sprint. Cela
correspond généralement à une réestimation à la hausse, suite à la prise en compte de contraintes
techniques que l'on n'avait pas vues lors de l'estimation initiale. Si c'est le cas, il est indispensable de
comprendre la cause de ces augmentations. Le même phénomène peut s'observer sur des légères
diminutions, pour les mêmes raisons.
On peut utiliser en cours du sprint la tendance de la courbe pour avoir une idée approximative de la
fin du sprint. Cela consiste à prendre un segment de droite dont la pente est représentative des valeurs
déjà recensées et de le prolonger jusqu'à son point d'intersection avec l'axe des abscisses. Cela nous
donne alors la date a priori de la fin du sprint et nous permet alors de prendre une décision sur la
suppression (ou l'ajout) d'un item de backlog du produit à réaliser dans ce sprint. C'est ce qui s'est
probablement passé le 15 mai 2002 sur le graphique de sprint ci-dessus : le reste à faire diminue dans
ce cas assez brutalement.
C'est exactement la même chose pour les burndown charts de release. Si la date de publication de la
release est clairement au-delà de ce que l'on espérait, on peut aviser en enlevant des items de backlog
du produit ou changeant leur ordre, de sorte que les fonctionnalités les moins importantes soient celles
qui risquent de ne pas être développées à temps.
Cette approche, bien que basée sur des tendances approximatives, permet d'identifier très tôt les
risques de défaillance et d'agir en conséquence, en conservant à l'esprit le caractère critique des
fonctionnalités à développer. Ces décisions importantes relèvent complètement du directeur de
produit.
Une dernière chose importante : la fiabilité de la vélocité de l'équipe et des estimations qu'elle a faites
augmente au fil des sprints. On élimine de cette façon les risques majeurs au plus tôt dans le projet.
Qualité de l'environnement de travail
Un concept fort de Scrum est la qualité de l'environnement de travail de l'équipe. Cela inclut :
■ Pas de changements imposés pendant un sprint

■ Toute l'équipe dans une même pièce
■ Un tableau blanc et/ou en liège
■ Un bon outil de suivi du projet
■ Prévenir des interventions extérieures (téléphone, irruption dans la pièce, etc.)
■ Tout ce qui peut rendre l'équipe plus sereine et efficace
Documentation de projet
Scrum n'impose aucune documentation particulière pour les projets. Des documents sont
implicitement produits (backlogs, burndown charts), mais ils ont une vocation avant tout utilitaire.
Produire de la documentation, c'est souvent utile, mais c'est aussi souvent inutile. En plus, il faut la
maintenir à jour et c'est quelque chose qui est rarement fait sur le terrain. Pour savoir s'il faut rédiger
un document, on peut se poser une question très simple : Est-ce que ce document va m'être
vraiment utile et tout de suite ?.
Voici quelques exemples de documents utiles et dans quels cas :
■ Diagrammes métiers (processus, objets, etc.), associé au backlog de produit : uniquement si la

logique métier du client qui concerne l'application est vraiment complexe. Dans ce cas, l'équipe
devrait produire ce document avec lui.
■ Diagramme de séquence, associé à un item du backlog du produit : uniquement si la fonctionnalité
aura une utilisation complexe, tant au niveau métier qu'applicatif.
■ Diagrammes d'architecture du logiciel (classes, modules, composants, etc.), pour le projet :
indispensable pour avoir toujours sous les yeux une vue de l'architecture et s'assurer ainsi qu'elle est
de qualité.
■ Les manuels utilisateur, à chaque sprint : les manuels sont produits à chaque sprint et pas en fin de
projet. Utiliser des vidéos de démonstrations commentées est une solution efficace.
■ Les FAQ pour la hotline : des cas classiques où les utilisateurs ne vont pas comprendre un
comportement métier. Cela permet de traiter un maximum de problèmes au niveau de la hotline,
avant que cela n'arrive aux équipes de développement/maintenance.
Bref, un document ne doit être produit que si son utilité est réelle et immédiate.
Outils pour Scrum
Un bon artisan n'est rien sans un bon outil. Il n'y a pas aujourd'hui d'outil ultime pour Scrum. Voici un
petit panel des possibilités.
Papier et crayon / tableur
Scrum peut être mis en pratique avec trois fois rien : deux listes suffisent. La liste des items du
backlog de produit et la liste des items du backlog de sprint. La saisie et la mise à jour des données est
simplement un peu moins agréable.
Outils libres
■ IceScrum (http://www.icescrum.org) (open-source et démo en ligne)

■ theSCRUM (http://www.the-scrum.org/) open-source et démo en ligne, implémente un tableau
blanc virtuel
■ EPF (http://www.eclipse.org/epf) Eclipse Process Framework intègre un plug-in Scrum (open-
source)
■ OpenERP (http://www.openerp.com) OpenERP intègre un module Scrum (open-source)
Outils propriétaires
■ AccuRev (http://www.accurev.com) (Solutions de gestion de configuration logicielle intégrant les

méthodes Agile et Scrum)
■ ScrumDesk (http://www.scrumdesk.com) (gratuit pour 5 utilisateurs maximum)
■ Intra'Know PROJET (http://www.intraknow.com) (cette solution collaborative intégre les grands
principes de la méthode AGILE )
■ ScrumWorks (http://danube.com/scrumworks) (gratuit sous conditions)
■ VersionOne (http://www.versionone.com/Resources/AgileDevelopment.asp) (gratuit sous
conditions)
■ RallyDev (http://www.rallydev.com/)
■ GreenHopper (http://www.greenpeppersoftware.com/en/products/GreenHopper/)
■ Microsoft eScrum Version 1.0 (http://www.microsoft.com/downloads/details.aspx?
FamilyID=55a4bde6-10a7-4c41-9938-f388c1ed15e9&displaylang=en) pour Visual Studio Team
Foundation Server
■ Scrumy (http://www.scrumy.com/) (Démonstration en ligne gratuite)
■ ScrumEdge (http://www.scrumedge.com/) (Démonstration en ligne gratuite)
■ Serena Agile On Demand (http://www.serena.com/products/agile-software/) Entièrement en mode
SAAS. Aucune installation nécessaire. Essai gratuit 60j.
■ Urban Turtle (http://www.urbanturtle.net/) Plugin for TFS web Access (Essai gratuit 30 Jours).
■ Virtual SCRUM Board (http://www.virtualscrumboard.com/) (Essais gratuit de 60 Jours)
Autres outils
■ Voir les ressources ScrumAlliance (http://www.scrumalliance.org/resources/) .
Conclusion
Scrum
Scrum est un processus de développement de logiciels qui s'intéresse plutôt à l'organisation du projet
qu'aux aspects techniques. Son cadre de travail est sa force, si bien que cette méthode pourrait être
appliquée à d'autres domaines. Son approche itérative et basée sur les besoins priorisés du client lui
confèrent une flexibilité extrême. Elle incarne bien par là l'état d'esprit de la mêlée de rugby : avancer
tous ensemble vers un but commun, la réussite du projet.
Scrum est un processus intéressant comme premier pas vers les méthodes Agiles : il est facile à
comprendre et à pratiquer. La seule difficulté relève plutôt de l'environnement organisationnel (voir la
mise en garde ci-dessous).
Mise en garde
On entend de plus en plus de sociétés clamer qu'elles sont Agiles, comme argument commercial à la
mode, parce qu'elles utilisent quelques pratiques des méthodes Agiles. Mais être Agile, c'est bien plus
que de mettre en pratique une méthode. L'Agilité requiert des dispositions particulières qui sont loin
d'être faciles à mettre en place :
■ Une organisation adaptée : il est très difficile de faire admettre aux organes décideurs d'une
entreprise de travailler de façon Agile. En effet, cela signifie de ne pas disposer dès le départ d'une
date et d'un budget très précis, mais plutôt d'un ordre de grandeur.
■ Un état d'esprit : être Agile, c'est privilégier l'esprit d'équipe et pas seulement dans la réalisation
technique. Le client doit comprendre que l'on attend de lui un investissement personnel bien
supérieur à celui des méthodes plus classiques, en testant le logiciel souvent et en participant à
toutes les réunions.
■ Un environnement favorable : éliminer les contraintes dans une entreprise n'est pas toujours
évident. Comment limiter les appels téléphoniques trop fréquents, les irruptions dans la pièce de
l'équipe, les opérations "urgentes" demandées aléatoirement par la direction, etc. ?
Bref, utiliser une méthode comme Scrum au niveau de l'équipe technique ne suffit pas. L'Agilité est
une façon de travailler différente de ce dont on a l'habitude, c'est l'attitude du changement, de la
flexibilité, de l'adaptation et de l'amélioration continue. Ce n'est pas aussi simple qu'une méthode…
Glossaire
Directeur de produit (Product Owner)
personne responsable de produire et maintenir à jour le backlog de produit. C'est lui qui en
détermine les priorités et qui prend les décisions concernant l'orientation du projet.
ScrumMaster
membre de l'équipe dont l'objectif principal est de la protéger des perturbations extérieures. Il
est complètement transparent pour la communication entre l'équipe et les clients et n'a aucun
pouvoir hiérarchique sur l'équipe. C'est en revanche un facilitateur pour les problèmes non
techniques de l'équipe.
Backlog de produit (Product Backlog)

liste des fonctionnalités qui devront être réalisées par le logiciel.
Backlog de sprint (Sprint Backlog)

liste des tâches à accomplir pendant un sprint. Elles correspondent à la réalisation des items de
backlog du produit affectés au sprint.
Mêlée quotidienne (Daily Scrum)

réunion quotidienne de 15 minutes qui a pour but de faire le point sur ce qui a été fait depuis la
dernière mêlée, ce qui est prévu de faire jusqu'à la prochaine et quelles sont les embûches
rencontrées durant le travail.
Sprint
nom d'une itération dans Scrum. Cette itération dure 30 jours calendaires en théorie, mais en
pratique on utilise plutôt entre 2 et 4 semaines. Pendant une itération, l'équipe doit développer
une liste d'items du backlog de produit qui a été définie au début de ce sprint.
Graphique d'avancement (Burndown Chart)

graphique qui montre la tendance du reste à faire total de jour en jour (pour les sprints) ou de
sprint en sprint (pour les releases).
Voir aussi
Articles connexes
■ Méthode agile
■ Extreme programming
Liens externes
■ (en) Site officiel Scrum (http://www.controlchaos.com/)

■ (en) Agile Alliance (http://www.agilealliance.org/) : Communauté autour des méthodes Agiles
■ (en) Scrum Alliance (http://www.scrumalliance.org/) : Communauté autour de Scrum
■ (en) Liste de discussion par mail (http://groups.yahoo.com/group/scrumdevelopment/)
■ (fr) Liste de discussion par mail francophone (http://fr.groups.yahoo.com/group/scrum-fr/)
■ (fr) Introduction à Scrum (http://www.aubryconseil.com/dotclear/index.php/2007/05/28/235-mise-
a-jour-majeure-de-la-presentation-introduction-a-scrum) en licence CreativeCommons, traduction
par Claude Aubry à partir de la version de Mike Cohn
(http://www.mountaingoatsoftware.com/news/view/5) . La traduction des termes Scrum anglais de
cette présentation a été utilisée dans cet article.
■ (fr) Planification et gestion de projet informatique : SCRUM
(http://techtalks.intellicore.net/2008/04/24/video-planification-gestion-projet-informatique-scrum/)
: Conférence vidéo de Christian Trotobas enregistrée aux Intellicore Tech Talks
(http://techtalks.intellicore.net) au sujet de la méthode SCRUM et de ses applications
■ (fr) Le French Scrum User Group
(http://www.frenchsug.org/display/FRSUG/French+Scrum+User+Group/) : le groupe d'utilisateurs
de Scrum en France.
■ (en) Vidéo "Scrum in the real World" (http://www.vimeo.com/4587652/) : Une Vidéo sur
l'application de la méthode Scrum sur un projet Web.
■ (en) Processus "Scrum Process Asset Library" (http://scrum.gem-up.com) : Un moyen facile de
naviguer la methodologie Scrum
1. ↑ The New New Product Development Game (http://apln-
richmond.pbworks.com/f/New+New+Prod+Devel+Game.pdf) Havard Business Review,er jan-fév 1986
2. ↑ (en) DeGrace, Stahl et Hulet, Wicked problems, righteous solutions, Prentice Hall, 1 octobre 1990 (ISBN 978
-0-135-90126-7)
3. ↑ Jeff Sutherland, « Agile Development: Lessons learned from the first Scrum
(http://www.scrumalliance.org/resources/35) »
4. ↑ SCRUM : Le guide pratique de la méthode agile la plus populaire (http://www.aubryconseil.com/pages/Livre-
Scrum)
5. ↑ Manifesto for Agile Software Development (http://agilemanifesto.org/)
Ce document provient de « http://fr.wikipedia.org/wiki/Scrum ».

Extreme programming - Wikipédia Page 1 of 7
Extreme programming
L'Extreme Programming (XP) est une méthode agile de gestion de projet informatique adaptée aux
équipes réduites avec des besoins changeants. Elle pousse à l'extrême des principes simples.
Sommaire
1 Origine
2 Pratiques extrêmes
3 Cycle de développement
4 La programmation comme discipline collective
4.1 Valeurs
4.1.1 La communication
4.1.2 La simplicité
4.1.3 Le feedback
4.1.4 Le courage
4.1.5 Le respect
4.2 Pratiques
4.2.1 Client sur site
4.2.2 Jeu du Planning ou Planning poker
4.2.3 Intégration continue
4.2.4 Petites livraisons
4.2.5 Rythme soutenable
4.2.6 Tests de recette (ou tests fonctionnels)
4.2.7 Tests unitaires
4.2.8 Conception simple
4.2.9 Utilisation de métaphores
4.2.10 Refactoring (ou remaniement du code)
4.2.11 Appropriation collective du code
4.2.12 Convention de nommage
4.2.13 Programmation en binôme
4.3 Autres principes
5 Environnements défavorables
6 Voir aussi
6.1 Articles connexes
6.2 Bibliographie
6.3 Liens externes
Origine
L'Extreme Programming a été inventée par Kent Beck, Ward Cunningham et Ron Jeffries pendant
leur travail sur un projet « C3 » de calcul des rémunérations chez Chrysler. Kent Beck, chef de projet
en mars 1996 commença à affiner la méthodologie de développement utilisée sur le projet. La
http://fr.wikipedia.org/wiki/Extreme_programming 01/06/2010
méthode est née officiellement en octobre 1999 avec le livre Extreme Programming Explained de
Kent Beck.
Pratiques extrêmes
Dans le livre Extreme Programming Explained, la méthode est définie comme :
■ une tentative de réconcilier l´humain avec la productivité ;

■ un mécanisme pour faciliter le changement social ;
■ une voie d'amélioration ;
■ un style de développement ;
■ une discipline de développement d´applications informatiques.
Son but principal est de réduire les coûts du changement. Dans les méthodes traditionnelles, les
besoins sont définis et souvent fixés au départ du projet informatique ce qui accroît les coûts
ultérieurs de modifications. XP s´attache à rendre le projet plus flexible et ouvert au changement en
introduisant des valeurs de base, des principes et des pratiques.
Les principes de cette méthode ne sont pas nouveaux : ils existent dans l'industrie du logiciel depuis
des dizaines d'années et dans les méthodes de management depuis encore plus longtemps.
L'originalité de la méthode est de les pousser à l'extrême :
■ puisque la revue de code est une bonne pratique, elle sera faite en permanence (par un binôme) ;
■ puisque les tests sont utiles, ils seront faits systématiquement avant chaque implantation ;
■ puisque la conception est importante, elle sera faite tout au long du projet (refactoring) ;
■ puisque la simplicité permet d'avancer plus vite, nous choisirons toujours la solution la plus
simple ;
■ puisque la compréhension est importante, nous définirons et ferons évoluer ensemble des
métaphores ;
■ puisque l'intégration des modifications est cruciale, nous l'effectuerons plusieurs fois par jour ;
■ puisque les besoins évoluent vite, nous ferons des cycles de développement très rapides pour nous
adapter au changement.
Cycle de développement
L'Extreme Programming repose sur des cycles
rapides de développement (des itérations de
quelques semaines) dont les étapes sont les
suivantes :
Le cycle de l'Extreme Programming
■ une phase d'exploration détermine les
scénarios clients qui seront fournis pendant
cette itération ;
■ l'équipe transforme les scénarios en tâches à réaliser et en tests fonctionnels ;
■ chaque développeur s'attribue des tâches et les réalise avec un binôme ;
■ lorsque tous les tests fonctionnels passent, le produit est livré.
Le cycle se répète tant que le client peut fournir des scénarios à livrer. Généralement le cycle de la
première livraison se caractérise par sa durée et le volume important de fonctionnalités embarquées.
Après la première mise en production, les itérations peuvent devenir plus courtes (une semaine par
exemple).
La programmation comme discipline collective

Tout en mettant l'accent sur les bonnes pratiques de programmation, XP préconise un déroulement
par itérations courtes et gérées collectivement, avec une implication constante du client. Il en découle
une redéfinition de la relation entre client et fournisseur avec de surprenants résultats en termes de
qualité de code, de délais et de satisfaction de la demande du client.
Valeurs
L'eXtreme Programming repose sur cinq valeurs fondamentales :
La communication
C'est le moyen fondamental pour éviter les problèmes. Les pratiques que préconise l'XP imposent
une communication intense. Les tests, la programmation en binôme et le jeu du planning obligent les
développeurs, les décideurs et les clients à communiquer. Si un manque apparait malgré tout, un
coach se charge de l'identifier et de remettre ces personnes en contact.
La simplicité
La façon la plus simple d'arriver au résultat est la meilleure. Anticiper les extensions futures est une
perte de temps. Une application simple sera plus facile à faire évoluer.
Le feedback
Le retour d'information est primordial pour le programmeur et le client. Les tests unitaires indiquent
si le code fonctionne. Les tests fonctionnels donnent l'avancement du projet. Les livraisons
fréquentes permettent de tester les fonctionnalités rapidement.
Le courage
Certains changements demandent beaucoup de courage. Il faut parfois changer l'architecture d'un
projet, jeter du code pour en produire un meilleur ou essayer une nouvelle technique. Le courage
permet de sortir d'une situation inadaptée. C'est difficile, mais la simplicité, le feedback et la
communication rendent ces tâches accessibles.
Le respect
Cette valeur fut ajoutée dans la deuxième édition de Extreme Programming Explained de K. Beck.
Pratiques
Ces cinq valeurs se déclinent en treize pratiques qui se renforcent mutuellement :
Client sur site
Un représentant du client doit, si possible, être présent pendant toute la durée du projet. Il doit avoir
les connaissances de l'utilisateur final et avoir une vision globale du résultat à obtenir. Il réalise son
travail habituel tout en étant disponible pour répondre aux questions de l'équipe.
Jeu du Planning ou Planning poker
Le client crée des scénarios pour les fonctionnalités qu'il souhaite obtenir. L'équipe évalue le temps
nécessaire pour les implémenter. Le client sélectionne ensuite les scénarios en fonction des priorités
et du temps disponible.
Intégration continue
Lorsqu'une tâche est terminée, les modifications sont immédiatement intégrées dans le produit
complet. On évite ainsi la surcharge de travail liée à l'intégration de tous les éléments avant la
livraison. Les tests facilitent grandement cette intégration : quand tous les tests passent, l'intégration
est terminée.
Petites livraisons
Les livraisons doivent être les plus fréquentes possible. L'intégration continue et les tests réduisent
considérablement le coût de livraison.
Rythme soutenable
L'équipe ne fait pas d'heures supplémentaires. Si le cas se présente, il faut revoir le planning. Un
développeur fatigué travaille mal. En effet le programmeur ne doit pas dépasser 35 heures de travail
par semaine (formations inclues) car le dépassement de ce taux peut engendrer des problèmes ce qui
influe sur la qualité du développement.
Tests de recette (ou tests fonctionnels)
À partir des scénarios définis par le client, l'équipe crée des procédures de test qui permettent de
vérifier l'avancement du développement. Lorsque tous les tests fonctionnels passent, l'itération est
terminée. Ces tests sont souvent automatisés mais ce n'est pas toujours possible.
Tests unitaires
Avant d'implémenter une fonctionnalité, le développeur écrit un test qui vérifiera que son
programme se comporte comme prévu. Ce test sera conservé jusqu'à la fin du projet, tant que la
fonctionnalité est requise. À chaque modification du code, on lance tous les tests écrits par tous les
développeurs, et on sait immédiatement si quelque chose ne fonctionne plus.
Conception simple
L'objectif d'une itération est d'implémenter les scénarios sélectionnés par le client et uniquement
cela. Envisager les prochaines évolutions ferait perdre du temps sans avoir la garantie d'un gain
ultérieur. Les tests permettront de changer l'architecture plus tard si nécessaire. Plus l'application est
simple, plus il sera facile de la faire évoluer lors des prochaines itérations. De même, la
documentation doit être minimale : on préfèrera un programme simple qui nécessite peu
d'explications à un système complexe.
Utilisation de métaphores
On utilise des métaphores et des analogies pour décrire le système et son fonctionnement. Le
fonctionnel et le technique se comprennent beaucoup mieux lorsqu'ils sont d'accord sur les termes
qu'ils emploient.
Refactoring (ou remaniement du code)
Amélioration régulière de la qualité du code sans en modifier le comportement. On retravaille le

code pour repartir sur de meilleures bases tout en gardant les mêmes fonctionnalités. Les phases de
refactoring n'apportent rien au client mais permettent aux développeurs d'avancer dans de meilleures
conditions et donc plus vite.
Appropriation collective du code
L'équipe est collectivement responsable de l'application. Chaque développeur peut faire des
modifications dans toutes les portions du code, même celles qu'il n'a pas écrites. Les tests diront si
quelque chose ne fonctionne plus.
Convention de nommage
Puisque tous les développeurs interviennent sur tout le code, il est indispensable d'établir et de
respecter des normes de nommage pour les variables, méthodes, objets, classes, fichiers, etc.
Programmation en binôme
La programmation se fait par deux. Le premier appelé driver (ou pilote) tient le clavier. C'est lui qui
va travailler sur la portion de code à écrire. Le second appelé partner (ou co-pilote) est là pour l'aider
en suggérant de nouvelles possibilités ou en décelant d'éventuels problèmes. Les développeurs
changent fréquemment de partenaire ce qui permet d'améliorer la connaissance collective de
l'application et d'améliorer la communication au sein de l'équipe.
Autres principes
■ Ne pas ajouter de fonctionnalités plus tôt que prévu ;

■ N'optimiser qu'à la toute fin.
Cette méthode s'appuie sur :
■ une forte réactivité au changement des besoins du client ;

■ un travail d'équipe ;
■ la qualité du code ;
■ la qualité des tests effectués au plus tôt.
Environnements défavorables
En lieu et place d'inconvénient de la méthode, on parlera plus aisément d'environnements
défavorables dans lesquels la méthode XP n'est pas applicable. Dans ce cas, seule une partie des
1
pratiques peut être réalisée. Les principaux contextes défavorables sont :
■ un blocage culturel : quand le client ou les développeurs ont l'habitude de fonctionner autrement.
L'ingénieur à qui l'on attribue des mini-tâches quotidiennes et qui doit les réaliser avec un binôme
peut avoir le sentiment que sa fonction est déqualifiée. Son principal rôle n'est plus d'être force de
proposition, mais bel et bien de produire et d'accroitre sa productivité (Taylorisme, Fordisme). Une
telle vision peut en effet provoquer un blocage culturel qui peut conduire à un turn-over important.
■ une équipe de vingt développeurs ou plus car la communication devient difficile : Il est fréquent de
voir au fil du temps des binômes travailler toujours ensemble, toujours sur les mêmes sujets, et
former ainsi des sous-équipes spécialisées, ce que ne veut pas XP. Par ailleurs, les évolutions
possibles dans l'entreprise sont très limitées dans la mesure où tous les membres de l'équipe jouent
tous les mêmes rôles.
■ un coût de changement exponentiel car « XP nécessite du code propre et simple » ;
■ un feedback long ou difficile à obtenir : le retour sur investissement est visible sur le moyen/long
terme.
■ un aménagement qui empêche la communication ou la programmation en binôme (il est nécessaire

d'avoir une infrastructure open-space).
■ Respect d'une discipline collective et travail en binôme au quotidien : cette méthode ne peut pas
être appliquée avec n'importe qui, car elle dégage très peu de temps à l'autonomie et au travail
individuel, dans la mesure où systématiquement le travail se fait à deux sur un même poste de
travail. Les développeurs auront de la difficulté à établir un projet professionnel dans leur
entreprise.
■ la résistance au changement.
Voir aussi
Articles connexes
■ Méthode agile
■ Scrum
■ Test Driven Development
Bibliographie
■ Kent Beck, eXtreme Programming - La référence, 2002 (ISBN 2-7440-1433-8)

■ Jean-Louis Bénard, Laurent Bossavit, Régis Médina et Dominic Williams, L'Extreme
Programming - Avec deux études de cas, 2002 (ISBN 2212110510), nouvelle édition du même
ouvrage sous le nom Gestion de projet eXtreme Programming (ISBN 2-212-11561-X)
■ Thierry Cros, Maîtrisez les projets avec l'Extreme Programming, 2004 (ISBN 2854286391)
■ (en) Matt Stephens et Doug Rosenberg, Extreme Programming Refactored: The Case Against XP,
2003 (ISBN 1590590961)
Liens externes
■ (en) ExtremeProgrammingRoadmap (http://www.c2.com/cgi/wiki?

ExtremeProgrammingRoadmap) , un wiki très complet
■ (fr) L'association eXtreme Programming France (http://xp-france.net/) et
son wiki (http://xp-france.net/cgi-bin/wiki.pl?XpFrance)
■ (fr) Présentation complète d'XP
Logo site Xp
(http://www.regismedina.com/articles/fr/extreme-programming)
■ (fr) Un autre article sur l'XP (http://lagace.developpez.com/extreme-
programming/)
■ (fr) Un exposé succinct de la méthode : historique, fondements et mise en oeuvre
(http://extremeprogramming.free.fr/)
■ (en) Do You Understand XP? (http://klimek.box4.net/blog/2007/02/19/do-you-understand-xp/) de
Manuel Klimek
■ (en) Extreme Deprogramming (http://www.hacknot.info/hacknot/action/showEntry?eid=11) qui
compare XP à une secte ("cult") (et la réponse de Manuel Klimek
(http://klimek.box4.net/blog/2007/02/26/xp-cult-or-movement/) )
■ (en) Extreme programming.org (http://www.extremeprogramming.org/)
1. ↑ eXtreme Programming - La référence, Kent Beck, chapitre 25 - Quand faut-il éviter XP
Ce document provient de « http://fr.wikipedia.org/wiki/Extreme_programming ».

Lean - Wikipédia Page 1 of 3
Lean
Le lean est une école de gestion d'entreprise - voir l'histoire de l'utilisation de ce mot pour nommer le
1
Système de Production Toyota - s'intéresse à la performance (productivité, qualité). Les tenants du
lean recherchent la performance par l'amélioration continue et l'élimination des gaspillages (muda en
japonais), dont il existe sept catégories : productions excessives, attentes, transports et manutentions
inutiles, tâches inutiles, stocks, mouvements inutiles et productions défectueuses. L'école de gestion
lean trouve ses sources au Japon dans le Toyota Production System (TPS). Adaptable à tous les
secteurs économiques, le lean est actuellement principalement implanté dans l'industrie (et surtout
l'industrie automobile).
Lean est un qualificatif donné par une équipe de chercheurs du MIT au système de production Toyota
sans que cette équipe ait eu une vision globale du système. A l'origine le TPS a été créé par Sakichi
Toyoda, puis par son fils Kiichiro Toyoda, et enfin par son neveu Eiji Toyoda, assistés par un
ingénieur surdoué Taiichi Ohno. Quand en 1972 après 25 ans d'efforts le système fut déployé depuis la
fabrication des moteurs jusqu'à la fin de la ligne d'assemblage chez Toyota, une cellule de 12
consultants internes (dont Fujio Cho, Hajime Ohba, etc.) fut créée (l'OMCD) pour aider les
fournisseurs de Toyota à livrer des produits de qualité en juste-à-temps. Chacun de ces consultants
s'occupa d'un fournisseur principal. Ensuite Hajime Ohba fut chargé de créer le TSSC, cellule de
support pour les fournisseurs de Toyota aux États-Unis. C'est dans cette cellule que John Shook et
James (Jim) P. Womack furent formés, selon les méthodes de Hajime Ohba. Ceci explique le fait que
certains « outils lean », tels que le MIFA, ne soient pas connus chez Toyota, le savoir initial de Ohno
s'étant perdu lors des différentes étapes de transmission entre des personnes, et celles-ci ayant inventé
de nouveaux outils. Aujourd'hui le TSSC est une entreprise indépendante de Toyota. De nombreux
consultants américains n'ont eu comme formation que celle du TSSC, sans pratique sur le terrain, et
ont créé des cabinets qui sous l'appellation lean sont loin des pratiques originelles du TPS.
Sommaire
1 Concepts de base
2 Lean et changement dans les organisations
4 Voir aussi
4.1 Liens externes
4.2 Bibliographie
Concepts de base
La pensée lean repose sur deux concepts principaux : le juste-à-temps et le jidoka. Les outils du juste-à
-temps sont le temps TAKT, le lissage, le flux continu en pièce à pièce, le flux tiré, le changement
rapide d'outils (SMED) et l'intégration de la logistique ; les outils du jidoka (peu visibles chez Toyota,
et donc par le fait moins connus en dehors de l'entreprise) sont la séparation de l'homme et de la
machine, les outils d'arrêt de production au premier défaut (andon), les méthodes d'élimination des
http://fr.wikipedia.org/wiki/Lean 01/06/2010
causes d'erreur (poka yoke), d'analyse de problème (« Cinq pourquoi »), la ré-ingénierie des
équipements de production.
La démarche lean est plus riche qu'une simple méthode de production, et forme un système cohérent
de concepts complexes, articulés à une pratique originale et à des moyens de formalisation et
d'appropriation spécifiques ; c'est pourquoi on peut utiliser à son endroit le terme d'école. Les tenants
du lean s'appliquent à l'enseigner, à l'appliquer et à répandre ses règles au sein de la communauté
industrielle. Après une première vague d'engouement dans les années 1970 et 1980 pour les
« méthodes japonaises », l'école du lean s'est formalisée aux États-Unis dans les années 1990 (le terme
2
même lean a été inventé au MIT en 1987) et a été popularisée par le livre Lean Thinking (1996) de
James P. Womack et Daniel T. Jones. De nombreux travaux ont suivi, parmi lesquels Team Toyota
(1996) de Terry L. Bresser et The Toyota Way (2004) de Jeffrey K. Liker. Ces ouvrages ont permis de
clarifier les concepts et les pratiques lean, de mieux comprendre les fondements cognitifs et sociaux
sur lesquels le système repose et de multiplier les exemples et études de cas.
On peut distinguer quatre niveaux d’analyse du système de pensée lean : une redéfinition de la valeur
produite par une entreprise, le développement d’un schéma productif caractéristique, le développement
d'attitudes managériales originales et la formulation d’une stratégie à long terme.
■ la valeur :
■ la valeur ajoutée d’une tâche contribuant à un processus doit être définie du point de vue du client ;
■ l'entreprise doit assurer un écoulement sans interruption de la valeur le long de sa chaîne de
production (en termes plus triviaux, on fait la « chasse aux stocks »).
■ le schéma de production :
■ l'entreprise produit en « tirant » sa production en fonction de la demande et non en « poussant » en
fonction des capacités locales de production ;
■ les tâches productives sont standardisées de manière à faciliter l'amélioration continue par
suppression des tâches non créatrices de valeur ;
■ l'entreprise entretient une relation partenariale riche avec ses fournisseurs et les incite à adopter ses
méthodes de production ;
■ l'attitude managériale :
■ les managers et les travailleurs doivent trouver et éliminer les causes profondes des problèmes dès
que ces derniers surviennent ;
■ chaque employé est incité à réfléchir et à proposer des améliorations du système productif. Ceci
débouche sur des chantiers ponctuels d'amélioration (kaizen) ;
■ le management doit se dérouler « sur le terrain », car seule l'expérience directe des situations de
crise permet un diagnostic efficace (genchi genbutsu) ;
■ les décisions sont nécessairement adoptées par consensus ;
■ la stratégie à long terme :
■ l'entreprise doit privilégier les enjeux de long terme en explicitant son objectif global et en
l'inscrivant de façon soutenable dans l'avenir ;
■ l'entreprise doit rechercher en permanence l'excellence.
Sur ces bases, l'école de gestion lean est en constante évolution. Après avoir, ces dernières années,
dépassé son cadre initial – l'organisation de la production –, elle est aujourd'hui perçue comme une
méthode pertinente pour combattre tous les types d’inefficacité : l'intérêt pour le lean s'étend aux
services administratifs (Lean Office), au développement de produit (Lean Development).
Lean et changement dans les organisations

L'application des principes du lean, notamment l'amélioration continue du système, impose de
profonds changements dans les organisations. La résolution des problèmes au plus près du terrain,
impliquant les opérationnels tout autant que les responsables, est un premier changement d'envergure,
tant le changement est plutôt perçu dans les grands organisations comme quelque chose qui suit la voie
hiérarchique descendante (top-down), où peu d'autonomie est laissée au terrain dans la prise
d'initiative.
1. ↑ lean Lettre8Octobre2004 (http://lean.enst.fr/wiki/bin/view/Lean/Lettre8Octobre2004)
2. ↑ Littéralement « penser maigre ».
Voir aussi
Liens externes
■ (en) The Origins of the Toyota Production System

(http://www.toyota.co.jp/en/vision/production_system/origin.html)
■ Article: The Roots of Lean: Training Within Industry: The Origin of Japanese Management and
Kaizen (http://www.twisummit.com/Roots-of-Lean-TWI.pdf) written by Jim Huntzinger
■ Article: Lean Accounting: What's It All About?
(http://www.leanaccountingsummit.com/LeanAccountingDefined-Target.pdf)
■ L'informatique Conviviale (http://informatique-conviviale.eyrolles.com/) , Le Lean Management
peut-il transformer l'entreprise ? Eyrolles, 2010
■ Une optique variée du lean (http://artoflean.com/elearn_tps/slides/slide_Page_008.jpg)
Bibliographie
Ce document provient de « http://fr.wikipedia.org/wiki/Lean ».


Methode Agile PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Methode Agile PDF

Transféré par

Droits d'auteur :

Formats disponibles

Méthode agile - Wikipédia Page 1 of 8

En 1986, Barry W. Boehm présentait un nouveau modèle de développement itératif et incrémental.

■ la spécialisation des rôles,

■ l’architecture de réalisation (imbrication des itérations),

Le Manifeste Agile débute par la déclaration suivante (traduction) :

Il aura fallu près de vingt années au mouvement Agile, parallèlement à la pression de la

■ La collaboration (« Collaboration avec le client plutôt que négociation de contrat ») : Le client

■ L'acceptation du changement (« Réagir au changement plutôt que suivre un plan ») : La

Méthodes Agiles reconnues par date de publication officielle

Autres Méthodes se reconnaissant de l'agilité

Tronc des pratiques communes à l'ensemble des méthodes

Pratiques différenciatrices des méthodes Agiles

Les pratiques différenciatrices les plus marquantes sont :

fonctionnalités porteuses de valeur. Le RAD propose des techniques proches : livraison en

Pratiques d'autres méthodes proches ou ayant un rapport avec

■ Le plus sérieux apport du RAD à la communication de projet et à la formalisation des exigences

■ Le RAD dans sa version 2 recommande la variabilité de la taille et de la maturité des groupes de

Optimisation des pratiques

■ L'eXtreme Programming, de Jean-Louis Bénard,Laurent Bossavit, Régis Médina, Dominic

■ Systèmes d'information et processus Agiles, Jean-Pierre Vickoff, Hermes Science Publication,

■ (en) Le manifeste des méthodes agiles (http://agilemanifesto.org/)

■ (fr) La communauté eXtreme Programing Francaise (http://xp-france.net/cgi-bin/wiki.pl)

Autres sites traitant de l'agilité ou du génie logiciel

■ (fr) Synergies entre CMMI et les méthodes agiles (http://blog.octo.com/synergies-entre-cmmi-et-

Ce document provient de « http://fr.wikipedia.org/wiki/M%C3%A9thode_agile ».

Dernière modification de cette page le 28 mai 2010 à 14:34.

Le Manifeste Agile débute par la déclaration suivante (traduction) :

Le Manifeste Agile est constitué de 4 valeurs et de 12 principes fondateurs.

■ Les experts métier et les développeurs doivent collaborer quotidiennement au projet.

■ Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.

■ Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires,

■ Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité.

■ La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.

Résumé de la mise en pratique

■ (en) The Agile Manifesto, Août 2001 (http://www.hristov.com/andrey/fht-

Ce document provient de « http://fr.wikipedia.org/wiki/Manifeste_agile ».

Dernière modification de cette page le 28 mai 2010 à 14:43.

Quelques rappels sur les méthodes agiles

Individus et interactions contre processus et outils

Logiciel qui fonctionne contre documentation exhaustive

Collaboration du client contre négociation de contrat

Réponse au changement contre suivi d'un plan prédéfini

■ Le client au cœur du projet

Le directeur de produit (Product Owner) est le

Scrum est un processus itératif : les Exemple de planification en Scrum

Au quotidien, une réunion, le ScrumMeeting, permet à l'équipe et au ScrumMaster de faire un point

Gestion des besoins

Items de backlog de produit

Items de backlog de sprint

Déroulement d'un sprint

de produit et de ses connaissances techniques, l'équipe s'engage à réaliser un ensemble d'items du

■ Qu'est-ce que j'ai fait hier ?

L'objectif pour Scrum est de produire la première version du backlog de produit.

Vue synthétique du processus Scrum

Les burndown charts (graphiques d'avancement) permettent de visualiser graphiquement

Sprint Burndown Chart

Exemple de Sprint Burndown Chart

Release Burndown Chart

Exemple de Release Burndown Chart

Qualité de l'environnement de travail

■ Pas de changements imposés pendant un sprint

Voici quelques exemples de documents utiles et dans quels cas :

■ Diagrammes métiers (processus, objets, etc.), associé au backlog de produit : uniquement si la