Mthode agile

Les mthodes agiles sont des groupes de pratiques de pilotage et de ralisation de projets.
Initialement destines au dveloppement en informatique (conception de logiciel), leur champ
d'application s'largit rgulirement. Elles ont pour origine l'Agile manifesto. Rdig en 2001,
celui-ci consacre le terme d' agile pour rfrencer de multiples mthodes existantes. Les
mthodes agiles se veulent plus pragmatiques que les mthodes traditionnelles. Elles
impliquent au maximum le demandeur (client) et permettent une grande ractivit ses
demandes. Elles visent la satisfaction relle du client en priorit aux termes d'un contrat de
dveloppement.

Les mthodes agiles reposent sur une structure (cycle de dveloppement) itrative,
incrmentale et adaptative. Elles doivent respecter quatre valeurs fondamentales dclines en
douze principes desquels dcoulent une base de pratiques, soit communes, soit
complmentaires.

Les mthodes pouvant tre qualifies d'agiles depuis la publication de l'agile manifesto sont le
RAD (dveloppement rapide d'applications) (1991) avec DSDM, la version anglaise du RAD
(1995) ainsi que plusieurs autres mthodes, comme ASD ou FDD qui reconnaissent leur
parent directe avec RAD. Les deux mthodes agiles dsormais les plus utilises sont : la
mthode Scrum qui fut prsente en 1995 par Ken Schwaber1puis publie en 2001 par lui
mme et Mike Beedle pour enfin tre diffuse mondialement par Jeff Sutherland ainsi que la
mthode XP Extreme programming publie en 1999 par Kent Beck.

Un mouvement plus large (management agile) couple les valeurs agiles aux techniques de
l'amlioration continue de la qualit. On constate un largissement de l'utilisation d'agile
l'ensemble de la structure de l'entreprise2.

Paramtres d'ajustement de planification

Dans la ralit des mthodes actuelles, le qualificatif d'itratif recouvre le plus souvent une
ralit semi-itrative : la phase de production tant prcde de plusieurs tapes telles que
l'exploration du besoin, le design de l'architecture et la planification.

Une mthode agile est avant tout itrative sur la base dun affinement du besoin mis en uvre
dans des fonctionnalits en cours de ralisation et mme dj ralises. Cet affinement,
indispensable la mise en uvre du concept adaptatif, se ralise en matire de gnie logiciel
sous deux aspects :

fonctionnellement, par adaptation systmatique du produit aux changements du besoin

dtect par lutilisateur lors de la conception-ralisation du produit (notion de
validation permanente de lutilisateur avec RAD et notion de conception mergente
avec XP) ;
techniquement, par remaniement rgulier du code dj produit (refactoring).

Une mthode agile est ensuite, ventuellement, incrmentale. Lorsque le projet, quel que soit
le nombre de participants, dpasse en dure une dizaine de journes en moyenne, la
production de ses fonctionnalits seffectue en plusieurs incrments.

1
La notion d'adaptatif, quant elle, ncessite au-del d'un simple principe, la mise en uvre de
techniques de contrle de l'volution du livrable et d'une mtrique formelle des modifications,
avant, aprs et en cours de la production. Il en dcoule une planification oprationnelle
lmentaire, directement visible par le biais de l'affichage mural (figure : Affichage mural
lmentaire).

Un contrat agile est tout fait possible. Il se base sur l'valuation du primtre connu
produire avec une technique agile comme le jeu d'estimation consensuelle. Ce principe
exprime en unit d'uvre, telle les journes idales par exemple, un engagement de lquipe
sur des objectifs prcis. Ces objectifs font lobjet du contrat-projet initial. Le contenu
fonctionnel peut ensuite tre modifi, en permanence et mme en cours de dveloppement,
par la matrise d'ouvrage. Chaque modification est trace sur la fiche de rcit utilisateur de la
fonctionnalit modifie ou abandonne en cours de dveloppement. Les parties de
dveloppement rutilisables sont alors rintgres dans lvaluation formelle des
modifications ou des nouvelles fonctionnalits. Dans ce contexte, lquipe a pour obligation
de livrer en fin dincrment un nombre dunits duvre au moins gal sa vitesse nominale
prvue en dbut de projet (nombre de personnes * nombre de jours ouvrs de travail sur
lincrment) ; le nombre dunit duvre (UE) permettant de prsenter graphiquement la
productivit obtenue pour chaque incrment se compose alors ainsi : UE livres au total = UE
livres utiles + UE livres abandonnes. Ce principe se matrialise ensuite avec la forme de
reporting agile nomm BurnUp chart (figure : Avancement graphique du projet).

L'acceptation du mode adaptatif, qui permet au client de modifier ses exigences en cours de
projet, aura pour consquence l'ventualit d'un primtre variable (figure : Critres Itratif -
Incrmental - Adaptatif). Dans la plupart des projets consquents ou stratgiques des
contraintes plus nombreuses doivent tre prises en compte afin d'optimiser le pilotage de la
ralisation (figure : Paramtres d'ajustement de planification).

Sommaire
1 Historique
2 Fondements
o 2.1 Quatre valeurs fondamentales
o 2.2 Douze principes gnraux
o 2.3 Structure oprationnelle et pratiques du dveloppement agile
3 Identification des mthodes agiles
o 3.1 Pratiques communes l'ensemble des mthodes agiles
o 3.2 Pratiques diffrenciatrices des mthodes agiles
4 Critres d'ligibilit
5 Principales critiques
6 Exemples de mthodes
o 6.1 Mthodes agiles au sens strict
o 6.2 Autres mthodes se reconnaissant un lien avec l'agilit
7 vnements
8 Bibliographie
o 8.1 Bibliographie francophone
o 8.2 Bibliographie anglophone
9 Voir aussi
o 9.1 Articles connexes
o 9.2 Rfrences

2
Historique
Les travaux sur le cycle de production itratif et incrmental remontent aux annes 1930 et
40, avec les travaux de Walter Shewhart et William Edwards Deming. Ces recherches sont
appliques la production informatique la fin des annes 1950, notamment avec le
dveloppement de parties logicielles dans le cadre du programme Mercury3. Gerald
Weinberg (en) mentionne un projet de dveloppement ralis en 1957 pour Motorola qui
utilisait une technique similaire ce qui sera plus tard l'eXtreme programming3.

Les mthodes agiles sont l'aboutissement de nombreux travaux tels que ceux de Tom Gilb
(cycle de vie volutif), de Scott Shultz (production en itrations rapides), de Brian Gallagher
et de Alex Balchin. Elles intgrent aussi les techniques JRP (Joint Requirements Planning) et
JAD (Joint application design) (en) qui furent inities par Dan Gielan, puis formalises par
Chuck Morris d'IBM en 1984 et diffuses sous forme de livres en 1989 par, entre autres, J.
Wood et D. Silver. La premire mthode agile4 serait la mthode EVO5, de Tom Gilb (en),
publie en 1976.

En 1986, Barry Boehm publie le modle en spirale (dveloppement incrmental) tandis que
Hirotaka Takeuchi (en) et Ikujiro Nonaka publient The new new product developpement
game6 un modle de dveloppement de produits industriels bas sur l'engagement simultan
des diverses disciplines concernes (ingnierie concourante).

En 1991, James Martin (en) (RAD), sappuyant sur une vision de l'volution continue des
technologies informatiques, propose une mthode de dveloppement rapide dapplication. Sa
structure (itrative-incrmentale-adaptative), base des approches agiles actuelles, dtermine le
phasage essentiel (figure : Le cycle agile est en fait semi-itratif) et met en uvre un principe
adaptatif non restrictif fond sur la validation permanente des utilisateurs et leur
responsabilit directe dans la dynamique applicative.

partir de 1994, Jean-Pierre Vickoff en France, notamment avec le Processus RAD2 publi
par le Gartner Group en 1999, et Jennifer Stapleton en Grande-Bretagne, avec DSDM,
introduisent des complments et des volutions (dtails Dveloppement rapide d'applications).

En 2001, aux tats-Unis, dix-sept figures minentes du dveloppement logiciel se runissent

pour dbattre d'un thme unificateur de leurs mthodes respectives. Les plus connus d'entre
eux sont Ward Cunningham, l'inventeur du Wiki via WikiWikiWeb, Kent Beck, pre de
l'extreme programming et cofondateur de JUnit, Ken Schwaber (en) et Jeff
Sutherland (en), crateur et promoteur de Scrum, Jim Highsmith (en), prnant l'ASD,
Alistair Cockburn pour la mthode Crystal clear, Martin Fowler et Dave Thomas, ainsi
qu'Arie van Bennekum pour DSDM (Dynamic System Development Method). Ces 17 experts
extraient alors de leurs usages respectifs les critres communs et les principes qui, selon eux,
conduisent aux meilleures concepts de direction de projets et de dveloppement de logiciels.

De cette runion merge le Manifeste agile, considr comme la dfinition canonique de

valeurs de l'agilit agile et de ses principes sous-jacents7.

Au dbut des annes 2000, une vague dune dizaine de mthodes (dont XP Extreme
programming et Scrum sont les principales reprsentantes) sont popularises. L'apport
mthodologique d'XP rside dans la prconisation de pousser lextrme les principales

3
pratiques de qualit de la construction applicative ainsi que les techniques adaptatives
destimation consensuelle, de planification pilote par l'utilisateur et de reporting visuel en
temps rel de l'avancement ainsi que des problmes rencontrs (affichage mural base de
post-it). Scrum propose un ensemble rduit de pratiques concentres sur le dveloppement de
l'adaptabilit par l'apprentissage et l'auto-organisation.

Fondements
Quatre valeurs fondamentales

Les mthodes agiles prnent 4 valeurs fondamentales (entre parenthses, les citations du
manifeste)8 :

L'quipe ( Les individus et leurs interactions, plus que les processus et les outils ) :
dans l'optique agile, l'quipe est bien plus importante que les outils (structurants ou de
contrle) ou les procdures de fonctionnement. Il est prfrable d'avoir une quipe
soude et qui communique, compose de dveloppeurs (ventuellement niveaux
variables), plutt qu'une quipe compose d'experts fonctionnant chacun de manire
isole. La communication est une notion fondamentale.

L'application ( Des logiciels oprationnels, plus qu'une documentation

exhaustive ) : il est vital que l'application fonctionne. Le reste, et notamment la
documentation technique, est une aide prcieuse mais non un but en soi. Une
documentation prcise est utile comme moyen de communication. La documentation
reprsente une charge de travail importante, mais peut pourtant tre nfaste si elle n'est
pas jour. Il est prfrable de commenter abondamment le code lui-mme, et surtout
de transfrer les comptences au sein de l'quipe (on en revient l'importance de la
communication).

La collaboration ( La collaboration avec les clients, plus que la ngociation

contractuelle ) : le client doit tre impliqu dans le dveloppement. On ne peut se
contenter de ngocier un contrat au dbut du projet, puis de ngliger les demandes du
client. Le client doit collaborer avec l'quipe et fournir un compte rendu continu sur
l'adquation du logiciel avec ses attentes.

L'acceptation du changement ( L'adaptation au changement, plus que le suivi d'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 premires
livraisons du logiciel vont souvent provoquer des demandes d'volution.

Douze principes gnraux

Ces quatre valeurs se dclinent en 12 principes gnraux communs toutes les mthodes
agiles9 :

1. La plus haute priorit est de satisfaire le client en livrant rapidement et rgulirement

des fonctionnalits forte valeur ajoute. (ce principe est superflu dans cette thorie)

4
 2. Le changement est accept, mme tardivement dans le dveloppement, car les
processus agiles exploitent le changement comme avantage concurrentiel pour le
client.
3. La livraison sapplique une application fonctionnelle, toutes les deux semaines
deux mois, avec une prfrence pour la priode la plus courte.
4. Le mtier et les dveloppeurs doivent collaborer rgulirement et de prfrence
quotidiennement au projet.
5. Le projet doit impliquer des personnes motives. Donnez-leur l'environnement et le
soutien dont elles ont besoin et faites leur confiance quant au respect des objectifs.
6. La mthode la plus efficace pour transmettre l'information est une conversation en
face face.
7. Lunit de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut
de comptabiliser les fonctions non formellement acheves).
8. Les processus agiles promeuvent un rythme de dveloppement soutenable (afin
dviter la non qualit dcoulant de la fatigue).
9. Les processus agiles recommandent une attention continue l'excellence technique et
la qualit de la conception.
10. La simplicit et l'art de minimiser les tches parasites, sont appliqus comme principes
essentiels.
11. Les quipes s'auto-organisent afin de faire merger les meilleures architectures,
spcifications et conceptions.
12. intervalle rgulier, l'quipe rflchit aux moyens de devenir plus efficace, puis
accorde et ajuste son processus de travail en consquence.

Une mthode qualifie d'agile doit donc se composer d'un ensemble de pratiques
instrumentant le cadre dcrit par les 12 principes gnraux agiles et en consquence s'inscrire
dans le respect des quatre valeurs fondamentales ayant inspir le Manifeste agile.

Structure oprationnelle et pratiques du dveloppement agile

La premire des mthodes Agiles, le RAD, depuis ses dbuts en 1991, prconise la formation
d'une quipe de dveloppement particulire. Cette quipe est autonome, spcialement forme,
concrtement[Mal dit] motive et outille. Elle se compose essentiellement d'un profil unique de
concepteurs-dveloppeurs forms des spcialits techniques complmentaires. L'quipe
travaille avec les utilisateurs et gnralement un animateur dans une salle spciale, isole,
spcialement quipe dans le style war room, o les murs sont utiliss pour afficher un
radiateur d'information (une forme de cockpit de management de projet). Cette
organisation et ces techniques sont devenues communes l'ensemble des mthodes agiles.

Parmi les techniques caractristiques de la conduite de projet agile apparues plus rcemment,
on trouve l'expression des exigences formalise de prfrence en rcits utilisateur et son
valuation consensuelle par l'quipe dans le cadre d'un jeu srieux intitul planning poker qui
estime la charge produire dans une unit de valeur pouvant tre soit des journes idales
soit des points de rcit .

Toutes les mthodes agiles utilisent un mode opratoire similaire, voire identique :

Un responsable fonctionnel dfinit et ordonne la production des composants de

l'application.

5
 Le projet est structur en incrments de une six semaines suivant les ncessits
(taille, ractivit, visibilit...).
Une runion initiale organise chaque incrment en dfinissant les tches raliser.
Lquipe pilote la qualit et la performance du projet de manire consensuelle.
Chaque jour, une courte runion d'avancement donne l'quipe une vision globale du
projet, met en vidence les ventuels problmes et permet de factoriser les solutions.
Un 'reporting' mural (Kanban, graphes de progression, etc.) est mis jour en temps
rel par les membres de l'quipe.
Un incrment achev contient une livraison complte, dveloppe, approuve et teste.
Une runion finale prsente l'application et est suivie d'une rtrospective technique du
processus de dveloppement.
Le responsable fonctionnel valide le travail de l'quipe et ajuste les besoins entre
chaque incrment.

Identification des mthodes agiles

Pratiques communes l'ensemble des mthodes agiles

1. Les pratiques communes lies aux ressources humaines

o Participation de lutilisateur final aux groupes de travail.
o Groupes de travail disposant du pouvoir de dcision.
o Autonomie et organisation centralise de lquipe (motivation).
o Spcification et validation permanente des Exigences.
2. Les pratiques communes lies au pilotage du projet
o Niveau mthodologique variable en fonction des enjeux du projet.
o Pilotage par les enjeux et les risques.
o Planification stratgique globale base sur des itrations rapides.
o Ralisation en jalons par prototypage actif itratif et incrmental.
o Recherche continue damlioration des pratiques.
3. Les pratiques communes lies la qualit de la production
o Recherche dexcellence technique de la conception.
o Vision graphique dune modlisation ncessaire et suffisante.
o Vision de la documentation ncessaire et suffisante.
o Normes et techniques raisonnables de qualit du code (mtrique).
o Architecture base de composants.
o Gestion des changements automatiss.

Pratiques diffrenciatrices des mthodes agiles

Seules quelques techniques complmentaires entre elles, ou mieux adaptes des typologies
et des tailles de projets donnes, diffrencient les mthodes agiles. Les pratiques
diffrenciatrices les plus marquantes sont :

La mthode RAD prconise lors de la phase de Construction de l'application des

techniques similaires celles d'XP mais non extrmes dans leur mise en uvre : des
revues de code personnelles, puis collectives et l'intgration avant chaque focus (ou
show). Par contre, le RAD limite la programmation en binme aux parties les plus
stratgiques. Toute mthode de conduite de projet devrait inclure un mode opratoire
pour les arrts d'urgence (Go/NoGo). Sur ce point la force du RAD se situe dans la

6
 prsence d'un animateur-facilitateur. Cette ressource, de prfrence externe, doit tre
neutre en regard des autres intervenants. Elle rpond une autorit suprieure tous
les participants du projet. Ainsi, lorsque le contexte stratgique, conomique ou
technique d'un projet volue, ou si les conditions de ralisation se dgradent,
l'animateur reporte le problme au dirigeant qui l'a mandat. Ce dernier peut alors
prendre, dans les meilleurs dlais, et avec des informations objectives les dcisions qui
s'imposent.

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 prserver leur intrt par un travail adapt leurs proccupations. Le
plus srieux apport de RAD2 la communication de projet et la formalisation des
exigences applicatives est le groupe d'animation et de rapport (GAR). Avec RAD 2,
l'organisation performante des runions est base sur un mode opratoire des
entretiens et sur des techniques de validation permanente. Le RAD propose des
techniques de pilotage stratgique comme la livraison en fonctionnalit rduite ou la
livraison par thmes.

La mthode DSDM (nom donn au consortium commercialisant la mthode RAD en

Angleterre) se particularise par la spcialisation des acteurs du projet dans une notion
de rles . Ainsi, l'on trouvera dans les runions DSDM des sponsors excutifs, des
ambassadeurs, des utilisateurs visionnaires, des utilisateurs conseillers, sans oublier
l'animateur-facilitateur et des rapporteurs.

La mthode scrum affirme sa diffrence dans la gnralisation d'un crmonial bas

sur des pratiques de courtes runions chaque tape de la vie du projet
(rtrospectives). Ces temps de travail commun ont pour objectifs d'amliorer la
motivation des participants, de synchroniser les tches, de dbloquer les situations
difficiles et d'accrotre le partage de la connaissance.

Pour FDD, la particularit nomme mission focused rside dans une forte orientation
vers un but immdiat mesurable guid par la notion de valeur mtier. C'est en fait
l'ambition globale d'une itration qui se trouve ainsi renforce. Cet aspect se retrouve
aussi dans la mthode RAD sous la forme des objectifs de Focus ou dans Scrum dans
la notion d'objectifs de Sprint.

XP (extreme programming) est trs ax sur la partie Construction de l'application. Une

de ses originalits rside dans lapproche de planification qui se matrialise sous la
forme dun jeu intitul planning game et qui implique simultanment les utilisateurs et
les dveloppeurs. On notera aussi des techniques particulires lies la production du
code comme le test driven development (TDD), la programmation en binme (Pair
programming), l'appropriation collective du code, la refactorisation (refactoring) et
l'intgration continue.

Critres d'ligibilit
De multiples facteurs contextuels peuvent tre pris en considration pour valider ou invalider
la possibilit d'application d'une mthode agile. Les principaux critres d'ligibilit pourraient
tre les suivants :

7
 1. Favorisant :
o Besoin rapide de mise disposition du produit
o Imprvisibilit des besoins du client
o Ncessit de changements frquents
o Besoin de visibilit du client sur l'avancement des dveloppements
o Prsence de l'utilisateur assurant un feedback immdiat
2. Dfavorisant :
o Indisponibilit du client ou de l'utilisateur
o Dispersion gographique des ressources humaines
o Inertie des acteurs du projet ou refus des changements
o Gouvernance complexe de la DSI
o Ne jamais arriver fournir et donc vendre quoi que ce soit

Dans les cas o les critres d'ligibilit de l'utilisation d'une approche agile n'ont pas t
respects, un risque de drive li un formalisme lger peut apparatre.

Principales critiques
Dans la ralit de leur mise en uvre, toutes les mthodes ne respectent pas l'identique les
principes fondamentaux agiles.

Scrum ncessite une importante spcification pralable la mise en production (backlog

produit), ce qui le classerait en partie du ct prdictif des mthodes. Certains estiment que ce
point ne serait pas un problme si Scrum disposait d'une mtrique formelle de gestion des
modifications. Mais l'objectif de Scrum est essentiellement orient sur la matrise dune
livraison dincrments (sprint). Son processus rfute donc la possibilit de modifier les
fonctionnalits en cours de ralisation ( l'exception d'un simple affinement depuis la version
2011). Pour cette raison, certains prtendent que Scrum ne peut tre alors considr comme
rellement itratif et adaptatif.

Par ailleurs, comme Scrum ne propose aucune technique d'ingnierie du logiciel, il est
indispensable de faire appel une autre mthode pour assurer la qualit et la fiabilit des
dveloppements informatiques.

D'aucuns expliquent, notamment lors de projets complexes, qu'il serait ncessaire d'ajouter
Scrum comme eXtrme Programming les pratiques de structuration des exigences qui leur
font dfaut.

Exemples de mthodes
Mthodes agiles au sens strict

Classes par date de publication :

Rapid Application Development (RAD, 1991)

Dynamic systems development method (DSDM, 1995, consortium anglais
commercialisant le RAD)
Scrum (1996)
Feature Driven Development ((en) FDD) (1999)

8
 Extreme programming (XP, 1999)
Adaptive software development (ASD, 2000)
Crystal clear (2004)

Autres mthodes se reconnaissant un lien avec l'agilit

MACAO
2TUP (2 track unified process, prononcez toutiyoupi ) prconise un cycle de vie en
Y qui dissocie la rsolution des questions fonctionnelles et techniques. Le cycle de vie
de 2TUP s'apparente un cycle de dveloppement en cascade mais introduit une
forme itrative interne certaines tches. Il n'est pas certain que ce cycle s'apparente
rellement une approche agile. Par contre, 2TUP prconise des formes de recherche
de qualit et de performance intressantes telles que les services rutilisables et la
conception gnrique (Framework et Patron de conception Design pattern) proches
des mcanismes architecturaux de RUP.
RUP se caractrise par une approche globale nomme Vue 4+1 . Les cinq
composants de cette vue sont : la vue des Cas d'utilisation, la vue Logique, la vue
d'Implmentation, la vue du Processus, la vue du Dploiement. l'instar du guide
d'activit de RAD 2, RUP offre galement un guide de processus formel et adaptable.
Ce guide est propre RUP et orient outil. noter que Rational Unified Process,
proprit d'IBM, n'est pas une mthode agile stricto sensu. Mais il en existe une
dclinaison agile, mais non libre de droits, sous l'acronyme de AUP (Agile unified
process (en)).

vnements
Plusieurs vnements traitant du thme de l'agilit sont organiss tous les ans dans le monde.
Ils ont la plupart du temps pour objectif de faire dcouvrir cette mthodologie de
dveloppement sous forme de jeux agiles ou de retours d'expriences.

L'agile Tour10 est un des grand vnement agile qui a lieu dans plusieurs pays (France,
Amrique du Sud, tats-Unis, Chine, Vietnam, Inde...) d'octobre dcembre. Il est organis
localement par des associations but non lucratif.

L'Agile Alliance11 et la Scrum Alliance12 recensent galement des vnements dans le monde.

Bibliographie
Bibliographie francophone

RAD, le dveloppement d'applications client-serveur, Jean-Pierre Vickoff, Macmillan,

1996 (ISBN 2744002224)

Systmes d'information et processus agiles, Jean-Pierre Vickoff, Hermes Science

Publication, 2003 (ISBN 2746207028)

L'eXtreme Programming, de Jean-Louis Bnard, Laurent Bossavit, Rgis Mdina,

Dominic Williams Eyrolles 2004 (ISBN 221211561X)

9
 Matriser les projets avec XP : Pilotage par les tests-client, Thierry Cros, ditions
Cpadues, 2004 (ISBN 2854286391)

Mthode agile, Les meilleures pratiques, Comprhension et mise en uvre, Jean-

Pierre Vickoff, QI, 2009 (ISBN 978-2912843074)

SCRUM, le guide de la mthode agile la plus populaire, Claude Aubry, InfoPro,

Dunod, 2010 (ISBN 978-2100540181)

Le marketing de l'Incertain. Mthode agile de prospective par les signaux faibles et

les scnarios dynamiques, Philippe Cahen, Kawa, 2011 (ISBN 978-2-918866-22-0)

Bibliographie anglophone

Rapid Application Development, James Martin, Macmillan, 1991 (ISBN 978-0023767753)

Extreme Programming Explained: Embrace Change, Kent Beck, (Addison-Wesley,
October 5, 1999) 978-0201616415 (ISBN 978-0201616415)
Agile Software Development With Scrum, Ken Schwaber, Mike Beedle, (Prentice Hall,
October 21, 2001) (ISBN 978-0130676344)

Voir aussi
Sur les autres projets Wikimedia :

Mthode agile, sur Wikiquote

Articles connexes

Management agile
Principes de gestion agile
Scrum (mthode)
Cycle de dveloppement (logiciel)
Limitations et extensions des mthodes agiles
Consensus
Software craftsmanship

Rfrences

Agile, de quoi s'agit-il ? Confrence de l'Association Franaise du Droit d'Internet et des

Technologies (AFDIT)

1. (en) Ken Schwaber [archive], sur Scrum Guides, 2014 (consult le 2 janvier 2015)
2. Travaux [archive] de Jean-Pierre Vickoff publis par l'Agile Alliance (en) et par ADELI (fr)
3. a et b (en) Craig Larman, Victor R. Basilii, Iterative and incremental development : a brief
history [archive] [PDF], sur craiglarman.org, juin 2003
4. "EVO is perhaps the oldest IID method with a significant agile and adaptative quality, first taking
shape in the 1960s then published in 1976." (en) Craig Larman, Agile & Iterative Development :
Chap 7 [archive], sur craiglarman.com, 2003 (consult le 3 mai 2014)

10
5. (en) Tom Gilb (en), Fundamental Principles of Evolutionary Project Management [archive],
sur gilb.com, 2005 (consult le 3 mai 2014)
6. (en) Hirotaka Takeuchi (en) et Ikujiro Nonaka, The New New Product Development Game
(Article preview) [archive], sur The magazine (Harvard business review), janvier 1986 (consult le 14
mai 2012)
7. Le Manifeste agile a t rendu public en 2001, et plusieurs implmentations de la mthode, comme
XP, SCRUM, et Crystal, existent. , Kieran Conboy et Brian Fitzgerald, Extreme Programming And
Mthodes agiles - XP/Agile Universe 2004 : 4e Confrence sur Extreme Programming et les Mthodes
Agiles, Calgary, Canada, du 15 au 18 aot 2004, Actes, chapitre Vers un cadre conceptuel pour les
Mthodes Agiles, Springer Verlag, New York, aot 2004[pas clair], (ISBN 354022839X), (en)
lien [archive]
8. Manifeste pour le dveloppement Agile de logiciels [archive]
9. Traduction des principes sous-jacents au manifeste [archive]
10. (en) Agile Tour [archive]
11. www.agilealliance.org/events/ [archive]
12. Scrum Alliance [archive]

11