Mthode agile Wikipdia

21/05/2014 22:19

Mthode agile
Les mthodes agiles sont des groupes de pratiques de projets de dveloppement en informatique (conception de logiciel), pouvant s'appliquer
divers types de projets. Elles ont pour dnominateur commun 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) commune (itrative, incrmentale et adaptative), quatre valeurs
communes dclines en douze principes communs desquels dcoulent une base de pratiques, soit communes, soit complmentaires.
Les premires mthodes agiles apparues sont EVO (Evolutionary Project Management) (1976), RAD (dveloppement rapide d'applications)
(1991), puis DSDM, la version anglaise du RAD (1995). Plusieurs autres mthodes, comme ASD ou FDD, reconnaissent leur parent directe
avec RAD. Les trois mthodes agiles dsormais les plus utilises sont : la mthode Kanban, issue de la mthode industrielle Lean, la mthode
Scrum publie en 2001 par Ken Schwaber et Jeff Sutherland, et 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 (plus
particulirement le Lean). On constate un largissement de l'utilisation d'agile l'ensemble de la structure de l'entreprise 1.

Sommaire
1 Itratif, incrmental et adaptatif
2 Historique
3 Valeurs
4 Principes
4.1 Structure oprationnelle et pratiques du dveloppement agile
5 Pratiques communes l'ensemble des mthodes agiles
6 Pratiques diffrenciatrices des mthodes agiles
7 Critres d'ligibilit
8 Principales critiques
9 Mthodes agiles
10 Autres mthodes se reconnaissant un lien avec l'agilit
11 Bibliographie francophone
12 Bibliographie anglophone
13 Voir aussi
13.1 Articles connexes
13.2 Rfrences

Itratif, incrmental et adaptatif

L'volution des cycles en matire de dveloppement informatique a dbut avec une vision incrmentale dite cascade ou cycle en V de
la succession des livrables produire et valider, puis s'est complexifie en acceptant les recouvrements de phases de l'ingnierie concourante
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 Mercury 2. 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 programming 2.
Dans la ralit des mthodes actuelles, le qualificatif d'itratif recouvre le plus souvent une ralit semiitrative : la phase de production tant prcde de plusieurs tapes telles que l'exploration du besoin, le
design de l'architecture et la planification.

http://fr.wikipedia.org/wiki/Mthode_agile

Evolution des cycles basiques

Page 1 sur 7

Mthode agile Wikipdia

21/05/2014 22:19

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.

Diverses formes d'itratif

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).

Le cycle agile est en fait semi-itratif

Affichage mural lmentaire

Avancement graphique du projet

Historique
Les mthode 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
agile 3 serait la mthode EVO 4, de Tom Gilb (en), publie en 1976.

Critres Itratif - Incrmental Adaptatif

En 1986, Barry Boehm publie le modle en spirale (dveloppement incrmental) tandis que Hirotaka
Takeuchi (en) et Ikujiro Nonaka (en) publient The new new product developpement game 5 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 (itrativeincrmentale-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.

Paramtres d'ajustement de
planification

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).

http://fr.wikipedia.org/wiki/Mthode_agile

Page 2 sur 7

Mthode agile Wikipdia

21/05/2014 22:19

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), crateurs 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 sous6
jacents .
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 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.

Valeurs
7

Les mthodes agiles prnent 4 valeurs fondamentales (entre parenthses, les citations du manifeste) :
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.

Principes
Ces 4 valeurs se dclinent en 12 principes gnraux communs toutes les mthodes agiles 8 :
1. La plus haute priorit est de satisfaire le client en livrant rapidement et rgulirement des fonctionnalits forte valeur ajoute.
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 de 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 4 valeurs fondamentales ayant inspir le Manifeste agile.

http://fr.wikipedia.org/wiki/Mthode_agile

Page 3 sur 7

Mthode agile Wikipdia

21/05/2014 22:19

Structure oprationnelle et pratiques du dveloppement agile

La premire des mthode Agiles, le RAD, depuis ses dbuts en 1991, prconise la formation d'une quipe de dveloppement particulire. Cette
quipe est autonome, spcialement forme, concrtement 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.
Le projet est structur en incrments de 1 6 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.

Pratiques communes l'ensemble des mthodes agiles

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

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 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
http://fr.wikipedia.org/wiki/Mthode_agile

Page 4 sur 7

Mthode agile Wikipdia

21/05/2014 22:19

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 :
1. Favorisant :
Besoin rapide de mise disposition du produit
Imprvisibilit des besoins du client
Ncessit de changements frquents
Besoin de visibilit du client sur l'avancement des dveloppements
Prsence de l'utilisateur assurant un feedback immdiat
2. Dfavorisant :
Indisponibilit du client ou de l'utilisateur
Dispersion gographique des ressources humaines
Inertie des acteurs du projet ou refus des changements
Gouvernance complexe de la DSI
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.

Mthodes agiles
Classes par date de publication :
Rapid Application Development (RAD, 1991)
http://fr.wikipedia.org/wiki/Mthode_agile

Page 5 sur 7

Mthode agile Wikipdia

21/05/2014 22:19

Dynamic systems development method (DSDM, 1995, consortium anglais commercialisant le RAD)
Scrum (1996)
Feature Driven Development ((en) FDD) (1999)
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 5 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)).

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)
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
Articles connexes
Management agile
Agile Alliance
Principes de gestion agile
Scrum (mthode)
Cycle de dveloppement (logiciel)
Limitations et extensions des mthodes agiles
Consensus
Software craftsmanship

Sur les autres projets Wikimedia :

Mthode agile, sur Wikiquote

Rfrences

http://fr.wikipedia.org/wiki/Mthode_agile

Page 6 sur 7

Mthode agile Wikipdia

21/05/2014 22:19

Agile, de quoi s'agit-il ?

(http://www.afdit.fr/media/pdf/06%20dec%202013/AFDIT%20slides%20P%20Delort%20ANDSI%20Agile%20&%20m%C3%A9thodes.pdf)
Confrence de l'Association Franaise du Droit d'Internet et des Technologies (AFDIT)
1. Travaux (http://cf.agilealliance.org/articles/article_list.cfm?CategoryID=82) de Jean-Pierre Vickoff publis par l'Agile Alliance (en) et par ADELI (fr)
2. (en) Craig Larman, Victor R. Basilii, Iterative and incremental development : a brief history
(http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf) [PDF], sur craiglarman.org, juin 2003
3. "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 (http://www.craiglarman.com/wiki/downloads/agile_iterative/larman-ch10-agile-1e-evo-andplanguage.pdf), sur craiglarman.com, 2003 (consult le 3/05/2014)
4. (en) Tom Gilb (en), Fundamental Principles of Evolutionary Project Management (http://www.gilb.com/dl59), sur gilb.com, 2005 (consult le
3/05/2014)
5. (en) Hirotaka Takeuchi (en) et Ikujiro Nonaka (en), The New New Product Development Game (Article preview) (http://hbr.org/1986/01/the-newnew-product-development-game/ar/1), sur The magasine (Harvard business review), janvier 1986 (consult le 14/05/2012)
6. 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 (http://books.google.fr/books?
hl=en&lr=&id=tmvI_a4YUNMC&oi=fnd&pg=PA105&ots=xejboEQhET&sig=ULAr0yaORppprWTgs8Sne0x9f4I)
7. Manifeste pour le dveloppement Agile de logiciels (http://agilemanifesto.org/iso/fr/)
8. Traduction des principes sous-jacents au manifeste (http://agilemanifesto.org/iso/fr/principles.html)

Ce document provient de http://fr.wikipedia.org/w/index.php?title=Mthode_agile&oldid=103612318 .

Dernire modification de cette page le 7 mai 2014 22:40.
Droit d'auteur : les textes sont disponibles sous licence Creative Commons paternit partage lidentique ; dautres conditions peuvent
sappliquer. Voyez les conditions dutilisation pour plus de dtails, ainsi que les crdits graphiques. En cas de rutilisation des textes de cette
page, voyez comment citer les auteurs et mentionner la licence.
Wikipedia est une marque dpose de la Wikimedia Foundation, Inc., organisation de bienfaisance rgie par le paragraphe 501(c)(3) du code
fiscal des tats-Unis.

http://fr.wikipedia.org/wiki/Mthode_agile

Page 7 sur 7