Escolar Documentos
Profissional Documentos
Cultura Documentos
Méthode agile
Les méthodes Agiles sont des groupes de pratiques pouvant
s'appliquer à divers types de projets, mais se limitant plutôt
actuellement aux 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.
Agile (adaptatif) = Itératif, Incrémental. Une méthode Agile est donc avant tout itérative sur la base d’un
affinement du besoin mis en œuvre dans des fonctionnalités en cours de réalisation et même déjà
réalisées. Cet affinement, indispensable à la mise en œuvre du concept adaptatif, se réalise en matière de
génie logiciel sous deux aspects :
• Fonctionnellement par adaptation systématique du produit aux changements du besoin détecté par
l’utilisateur lors de la conception-réalisation du produit (notion de validation permanente de l’utilisateur
avec RAD et notion de conception émergente avec XP).
Une méthode Agile est ensuite, éventuellement, incrémentale. Lorsque le projet, quel que soit le nombre
de participants, dépasse en durée une dizaine de journées en moyenne, la production de ses
fonctionnalités s’effectuent en plusieurs incréments.
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) commencerait
à coupler les valeurs Agiles aux techniques de l'amélioration continue de la qualité (MTQS ou Lean).
http://fr.wikipedia.org/wiki/M%C3%A9thode_agile 09/03/2011
Méthode agile - Wikipédia Page 2 sur 9
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 Critiques
11 Critères d'éligibilité
12 Bibliographie
13 Voir aussi
13.1 Liens internes
13.2 Références
13.3 Liens externes
13.3.1 Communautés agiles
13.3.2 Autres sites traitant de l'agilité ou du génie logiciel
14 Autres liens
Historique
Évolution du courant de pensée Agile en matière de systèmes d'informations
En 1986 également, Hirotaka Takeuchi et Ikujiro Nonaka publient « the new 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 :
http://fr.wikipedia.org/wiki/M%C3%A9thode_agile 09/03/2011
Méthode agile - Wikipédia Page 3 sur 9
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 leurs 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
développement Agile et de ses principes sous-jacents 1.
" 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èses, les citations du manifeste)2 :
■ 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.
http://fr.wikipedia.org/wiki/M%C3%A9thode_agile 09/03/2011
Méthode agile - Wikipédia Page 4 sur 9
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 3 :
■ « 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 »
■ « À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste
son comportement dans ce sens »
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).
http://fr.wikipedia.org/wiki/M%C3%A9thode_agile 09/03/2011
Méthode agile - Wikipédia Page 5 sur 9
■ 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.
http://fr.wikipedia.org/wiki/M%C3%A9thode_agile 09/03/2011
Méthode agile - Wikipédia Page 6 sur 9
■ 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 propriétaire et orienté outil.
■ 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).
D'autres voies, telles que l'association d'Agile et de techniques en cascade classique, sembleraient donner
http://fr.wikipedia.org/wiki/M%C3%A9thode_agile 09/03/2011
Méthode agile - Wikipédia Page 7 sur 9
de bons résultats 4. Cette direction est soutenue par des experts techniques certifiés et reconnus 5.
Critiques
Dans les cas où les critères d'éligibilité de l'utilisation d'une approche agile n'ont pas été respectés, la
méthode peut montrer plusieurs limites : risques de dérives, documentation insuffisante, inadaptation à
des projets de grande envergure.
Toutes les méthodes ne respectent pas à l'identique les principes fondamentaux Agiles. Par exemple : les
pratiques de Scrum sont essentiellement orientés sur la maîtrise d’une livraison d’incréments (sprint)
mais réfutent la possibilité de modifier les fonctionnalités en cours de réalisation (backlog de sprint),
interdisant donc la mise en œuvre d’une conception émergente. Scrum, ne disposant pas de métrique de
gestion du changement à ce niveau, nécessite donc une importante spécification préalable à la mise en
production (backlog produit) et, du fait de cette prédictibilité imposée, ne peut pas être considéré comme
réellement itératif, donc adaptatif. De même, lors de projets complexes, il est nécessaire d'ajouter à
eXtrême Programming les pratiques de structuration des exigences qui lui font défaut.
Critères d'éligibilité
De multiples facteurs contextuels peuvent être pris en considération pour valider ou invalider la
possibilité d'application d'une méthode agile. Les principaux critères d'éligibilité pourraient être les
suivants :
1. favorisant :
■ Besoin rapide de mise à disposition du produit
■ Imprévisibilité des besoins du client
■ Nécessité de changements fréquents
■ Besoin de visibilité du client sur l'avancement des développements
■ Présence de l'utilisateur assurant un feedback immédiat
2. défavorisant :
■ Indisponibilité du client ou de l'utilisateur
■ Dispersion géographique des ressources humaines
■ Inertie des acteurs du projet ou refus des changements
Bibliographie
■ Agile Modeling, Ron Jeffries et Scott W. Ambler , John Wiley & Sons, 2002 (ISBN 0471202827)
■ 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)
■ Méthode Agile, Les meilleures pratiques, Compréhension et mise en œuvre , Jean-Pierre Vickoff, QI,
2009 (ISBN 978-2912843074)
http://fr.wikipedia.org/wiki/M%C3%A9thode_agile 09/03/2011
Méthode agile - Wikipédia Page 8 sur 9
■ PUMA Essentiel, Méthode Agile Optimale, Jean-Pierre Vickoff, QI, 2008 (ISBN 978-2912843067)
■ SCRUM, le guide de la méthode agile la plus populaire, Claude Aubry, InfoPro, Dunod
(ISBN 978-2100540181)
Voir aussi
Liens internes
■ Agilepartner.net
■ Management Agile
■ Agile Alliance
■ Principes de gestion agiles
■ Scrum_(méthode)
■ Cycle de développement
Références
1. « Le Manifeste Agile a été rendu public en 2001, et plusieurs implémentations de la méthode, comme XP, SCRUM,
et Crystal, existent. », Kieran Conboy et Brian Fitzgerald, Extreme Programming And Méthodes Agiles - XP/Agile
Universe 2004 : 4e Conférence sur Extreme Programming et les Méthodes Agiles, Calgary, Canada, du 15 au 18
août 2004, Actes, chapitre Vers un cadre conceptuel pour les Méthodes Agiles, Springer Verlag, New York, août
2004, (ISBN 354022839X), (en) lien (http://books.google.fr/books?
hl=en&lr=&id=tmvI_a4YUNMC&oi=fnd&pg=PA105&ots=xejboEQhET&sig=ULAr0yaORppprWTgs8Sne0x9f4I)
2. Manifeste pour le développement Agile de logiciels (http://agilemanifesto.org/iso/fr/)
3. Traduction des principes sous-jacents au manifeste (http://agilemanifesto.org/iso/fr/principles.html)
4. (en) Why hybrid waterfall/agile process lessens distributed software development problems
(http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1515179,00.html)
5. [1] (http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1515179,00.html) Une fois les fondations
fixées (plan, modèle et analyse globale), des évolutions incrémentales peuvent être mises en œuvre, afin de livrer
des produits de court terme. Et c'est là que vous pouvez mettre en place des délais et utiliser les Méthodes Agiles.
Chacune de ces lignes droites sera une étape vers le but final.
Liens externes
Communautés agiles
http://fr.wikipedia.org/wiki/M%C3%A9thode_agile 09/03/2011
Méthode agile - Wikipédia Page 9 sur 9
Autres liens
l'Agilité au Luxembourg (http://www.agilepartner.net/)
http://fr.wikipedia.org/wiki/M%C3%A9thode_agile 09/03/2011