of 40 /40
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) Page 1 of 8 Méthode agile - Wikipédia 01/06/2010 http://fr.wikipedia.org/wiki/M%C3%A9thode_agile

Methode Agile

Embed Size (px)

Text of Methode Agile

Mthode agile - Wikipdia

Page 1 of 8

Mthode agileLes mthodes Agiles sont des groupes de pratiques pouvant en s'appliquer divers types de projets, mais se limitant plutt actuellement au projets de dveloppement en informatique (conception de logiciel). 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 besoin du client et non les termes d'un contrat de dveloppement. La notion de mthode agile a t officialise en 2001 par un document, le Manifeste Agile (Agile Manifesto), sign par 17 personnalits impliques dans l'volution du gnie logiciel, en particulier, en tant qu'auteur de leur propre mthode. Les mthodes Agiles et les pratiques qu'elles recouvrent taient antrieures au Manifeste Agile. Le manifeste Agile nest donc pas lacte de naissance des mthodes Agiles ou du mouvement Agile, mais la formalisation consensuelle par les auteurs de ces mthodes, toutes nes dans la deuxime partie de la dcennie 90, du fait quelles avaient des valeurs communes, une structure (cycle de dveloppement) commune (itrative, incrmentale et adaptative) et une base de pratiques, soit communes, soit complmentaires. Parmi ces mthodes on trouve en premier lieu la mthode RAD (Dveloppement rapide d'applications) de James Martin (1991), puis DSDM la version anglaise du RAD (1995). Plusieurs autres mthodes comme ASD ou FDD reconnaissent leur parent directe avec RAD (que certains de ses promoteurs prsentent comme la premire mthode Agile publie). Les deux mthodes Agiles les plus connues en France sont : la mthode Scrum (1996) et la mthode XP pour Extreme programming (1999). La notion de mthode agile a merg avec des pratiques ciblant uniquement le dveloppement d'une application informatique. Mais un mouvement managrial plus large (Management Agile)

http://fr.wikipedia.org/wiki/M%C3%A9thode_agile

01/06/2010

Mthode agile - Wikipdia

Page 2 of 8

commence coupler les valeurs Agiles aux techniques de l'amlioration continue de la qualit (MTQS ou Lean).

Sommaire1 Historique 2 Valeurs 3 Principes 4 Mthodes Agiles reconnues par date de publication officielle 5 Autres Mthodes se reconnaissant de l'agilit 6 Tronc des pratiques communes l'ensemble des mthodes Agiles 7 Pratiques diffrenciatrices des mthodes Agiles 8 Pratiques d'autres mthodes proches ou ayant un rapport avec les mthodes agiles 9 Optimisation des pratiques 10 Bibliographie 11 Voir aussi 11.1 Liens internes 11.2 Rfrences 11.3 Liens externes 11.3.1 Communauts agiles 11.3.2 Autres sites traitant de l'agilit ou du gnie logiciel 12 Autres liens

Historiquevolution du courant de pense Agile en matire de systmes d'informations En 1986, Barry W. Boehm prsentait un nouveau modle de dveloppement itratif et incrmental. En 1986 galement, Hirotaka Takeuchi et Ikujiro Nonaka publient "the new product developpement game" dans la Harvard business review. Leur article prsente un modle de dveloppement bas sur l'aptitude au changement, l'auto organisation, l'imbrication des phases de dveloppement, et l'itration (on y fait d'ailleurs mention du mot scrum par analogie au rugby). En 1991, James Martin (RAD), sappuyant sur cette vision dune volution continue, proposa une mthode de dveloppement rapide dapplication. Sa structure, base des approches actuelles, dterminait 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 complments tels que : la spcialisation des rles, linstrumentation des communications, lorganisation des divers types de runions, le groupe de facilitation et de rapport, les raccourcis mthodologiques de modlisation,

http://fr.wikipedia.org/wiki/M%C3%A9thode_agile

01/06/2010

Mthode agile - Wikipdia

Page 3 of 8

larchitecture de ralisation (imbrication des itrations), la formalisation de processus lgers de mise en uvre. Dans la seconde moiti des annes 1990, une vague dune dizaine de mthodes (dont Extreme programming et Scrum sont les principales reprsentantes) poussa lextrme certaines pratiques de qualit de la construction applicative ainsi que les techniques adaptatives destimation, de planification et de pilotage de projet. En 2001, aux tats-Unis, dix-sept figures minentes du dveloppement logiciel se sont runies pour dbattre du thme unificateur de leurs mthodes respectives, dites mthodes agiles. Les plus connus d'entre eux taient Ward Cunningham l'inventeur du Wiki via WikiWikiWeb, Kent Beck, pre de l'extreme programming et cofondateur de JUnit, Ken Schwaber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith, prnant l'ASD, Alistair Cockburn pour la mthode 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 diffrents russirent extraire de leur concepts respectifs des critres pour dfinir une nouvelle faon de dvelopper des logiciels : De cette runion devait merger le Manifeste Agile, considr comme la dfinition canonique du 1 dveloppement Agile et de ses principes sous-jacents . Le Manifeste Agile dbute par la dclaration suivante (traduction) : " Nous avons trouv une voie amliorant le dveloppement logiciel en ralisant ce travail et en aidant les autres le faire. De ce fait nous avons dduit des valeurs communes. " Il aura fallu prs de vingt annes au mouvement Agile, paralllement la pression de la mondialisation, pour bousculer vraiment la conduite de projet classique. Dsormais, le futur de lagilit mthodologique se trouve certainement, dune part, dans linstrumentation et la personnalisation la carte des pratiques essentielles pour un contexte spcifique et, dautre part, dans son largissement tous les aspects de lAgilit organisationnelle.

ValeursDans ce but, elles prnent 4 valeurs fondamentales (entre parenthse, les citations du manifeste) : L'quipe ( Personnes et interaction plutt que processus et 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 ( Logiciel fonctionnel plutt que documentation complte ) : 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 ( Collaboration avec le client plutt que ngociation de contrat ) : Le client doit tre impliqu dans le dveloppement. On ne peut se contenter de ngocier un contrat au dbut

http://fr.wikipedia.org/wiki/M%C3%A9thode_agile

01/06/2010

Mthode agile - Wikipdia

Page 4 of 8

du projet, puis de ngliger 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 ( Ragir au changement plutt 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 premires releases du logiciel vont souvent provoquer des demandes d'volution.

PrincipesCes 4 valeurs se dclinent en 12 principes gnraux communs toutes les mthodes agiles : Notre premire priorit est de satisfaire le client en livrant tt et rgulirement des logiciels utiles . Le changement est bienvenu, mme tardivement dans le dveloppement. Les processus agiles exploitent le changement comme avantage comptitif pour le client . Livrer frquemment une application fonctionnelle, toutes les deux semaines deux mois, avec une tendance pour la priode la plus courte . Les gens de l'art et les dveloppeurs doivent collaborer quotidiennement au projet . Btissez le projet autour de personnes motives. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacit faire le travail . La mthode 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 dveloppement durable. Commanditaires, dveloppeurs et utilisateurs devraient pouvoir maintenir le rythme indfiniment . Une attention continue l'excellence technique et la qualit de la conception amliore l'agilit . La simplicit - l'art de maximiser la quantit de travail ne pas faire - est essentielle . Les meilleures architectures, spcifications et conceptions sont issues d'quipes qui s'autoorganisent . intervalle rgulier, l'quipe rflchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens .

Mthodes 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 Mthodes se reconnaissant de l'agilit MACAO ([1] (http://www.jbcc.fr/presentationMACAO_Fr.php) ) Processus Urbanisant les Mthodes Agiles (PUMA (http://www.entreprise-agile.com/) ) KANBAN ([2] (http://fr.wikipedia.org/wiki/Kanban) )

http://fr.wikipedia.org/wiki/M%C3%A9thode_agile

01/06/2010

Mthode agile - Wikipdia

Page 5 of 8

Note RUP (Rational Unified Process) n'est pas une mthode Agile et, est de plus un produit proprit d'IBM. Il existe une dclinaison Agile, mais non libre de droits, de RUP sous l'acronyme de AUP (Agile Unified Process).

Tronc des pratiques communes l'ensemble des mthodes Agiles1. 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 AgilesSeules quelques techniques complmentaires entre elles, ou mieux adaptes des typologies et des tailles de projets spcifiques, diffrencient les mthodes Agiles (y compris ASD ou Crystal Clear). Les pratiques diffrenciatrices les plus marquantes sont : La mthode DSDM 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 des pratiques de courtes runions quotidiennes (Stand-Up meeting). 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 de Sprint. FDD prconise aussi le Features Driven Development. Cette technique se caractrise par des notions de Feature et de Features set (fonctionnalits et groupes de fonctionnalits). La priorit est donne aux

http://fr.wikipedia.org/wiki/M%C3%A9thode_agile

01/06/2010

Mthode agile - Wikipdia

Page 6 of 8

fonctionnalits porteuses de valeur. Le RAD propose des techniques proches : livraison en fonctionnalit rduite ou livraison par thmes. 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 la programmation en binme (Pair programming), l'appropriation collective du code, la Refactorisation (refactoring) et l' Intgration continue. La mthode RAD prconise dans ce sens 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.

Pratiques d'autres mthodes proches ou ayant un rapport avec les mthodes agiles 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. 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 propritaire et orient outil. Le plus srieux 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 prserver leur intrt par un travail adapt leurs proccupations. Avec RAD 2, l'organisation performante des runions est base sur un mode opratoire des entretiens et sur des techniques de validation permanente. 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 comme les autres mthodes Agiles prconise la formation d'une quipe de dveloppement particulire, le SWAT (Skill With Advanced Tools driv de Special Weapons And Tactics). 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. Le SWAT travaille avec les utilisateurs dans une salle permanente spcialement

http://fr.wikipedia.org/wiki/M%C3%A9thode_agile

01/06/2010

Mthode agile - Wikipdia

Page 7 of 8

quipe style War Room qui transforme les murs en Information Radiator (une forme de cokpit de management de projet).

Optimisation des pratiquesSelon Jean-Pierre Vickoff dans la communication PUMA (Proposition pour l'Unification des Mthodes Agiles)[3] (http://www.adeli.org/voirdoc.php?dest=lalettre/l48p19.pdf) publi sur le site de ADELI (Association pour la maitrise des Systmes d'Information) " La mthode Agile idale s'appuierait sur une utilisation optimise des pratiques du tronc commun et s'enrichirait d'une slection des pratiques spcifiques 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 Bnard,Laurent Bossavit, Rgis Mdina, Dominic Williams Eyrolles 2002 (ISBN 221211561X) Matriser les projets avec XP : Pilotage par les tests-client, Thierry Cros, Editions Cpadues, 2004, (ISBN 2854286391) AGILE, lEntreprise et ses projets, Jean-Pierre Vickoff, QI, 2007, (ISBN 2912843006) Systmes d'information et processus Agiles, Jean-Pierre Vickoff, Hermes Science Publication, 2003 (ISBN 2746207028)

Voir aussiLiens internes Management Agile Agile Alliance Principes de gestion agiles Cycle de dveloppement

Rfrences1. "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 1518, 2004, Proceedings, chap. Toward a Conceptual Framework of Agile Methods, Springer Verlag, New York, aot 2004, (ISBN 354022839X), lien (http://books.google.fr/books? hl=en&lr=&id=tmvI_a4YUNMC&oi=fnd&pg=PA105&ots=xejboEQhET&sig=ULAr0yaORppprWTgs8Sne0x

http://fr.wikipedia.org/wiki/M%C3%A9thode_agile

01/06/2010

Mthode agile - Wikipdia

Page 8 of 8

Liens externesCommunauts agiles (en) Le manifeste des mthodes 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 Qubec (http://www.agilequebec.ca/) (fr) La Communaut Agile de Montral (http://www.agilemontreal.ca/) (en) Site de la mthode xp (http://www.extremeprogramming.org/) (fr) Le Club Agile Rhne-Alpes (http://clubagile.org/)

Autres sites traitant de l'agilit ou du gnie logiciel (fr) Synergies entre CMMI et les mthodes agiles (http://blog.octo.com/synergies-entre-cmmi-etles-methodes-agiles/) (fr) Association pour la matrise des systmes d'informations (http://www.adeli.org/) (fr) Site historique de la mthode RAD (http://www.rad.fr/)

Autres liensPrincipes de gestion agiles

Ce document provient de http://fr.wikipedia.org/wiki/M%C3%A9thode_agile . Dernire modification de cette page le 28 mai 2010 14:34. 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/M%C3%A9thode_agile

01/06/2010

Manifeste agile - Wikipdia

Page 1 of 3

Manifeste agileLe Manifeste Agile est un texte rdig par 17 experts reconnus pour leurs apports respectifs au dveloppement d'applications informatiques sous la forme de plusieurs mthodes dont les plus connues sont Extreme Programming et Scrum. Ces experts estimaient que le traditionnel cycle de dveloppement en cascade ne correspondait plus aux nouveaux besoins applicatifs. Le Manifeste Agile est considr comme l'acte gnralisateur des mthodes agiles sous la dnomination initiale de Agile Manifesto [1] (http://agilemanifesto.org/) . Les valeurs et principes du Manifeste Agile sont dfendus par l'Agile Alliance.

Sommaire1 Introduction 2 Les 4 valeurs 3 Les 12 principes 4 Rsum de la mise en pratique 5 Organisation 6 Notes et rfrences 7 Voir aussi 7.1 Articles connexes 7.2 Bibliographie 7.3 Liens externes

IntroductionEn 2001, aux tats-Unis, dix-sept figures minentes du dveloppement logiciel se sont runies pour dbattre du thme unificateur de leurs mthodes respectives, dites mthodes agiles. Les plus connus d'entre eux taient Ward Cunningham l'inventeur du Wiki via WikiWikiWeb, Kent Beck, pre de l'extreme programming et cofondateur de JUnit, Ken Schwaber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith, prnant l'ASD, Alistair Cockburn pour la mthode Crystal clear, Martin Fowler, et Dave Thomas ainsi que Arie van Bennekum pour DSDM (Dynamic System Development Method) la version anglaise du RAD (Dveloppement rapide d'applications). Ces 17 experts venant tous d'horizons diffrents russirent extraire de leur concepts respectifs des critres pour dfinir une nouvelle faon de dvelopper des logiciels : De cette runion devait merger le Manifeste Agile, considr comme la dfinition canonique du 1 dveloppement Agile et de ses principes sous-jacents . Le Manifeste Agile dbute par la dclaration suivante (traduction) : " Nous avons trouv une voie amliorant le dveloppement logiciel en ralisant ce travail et en aidant les autres le faire. De ce fait nous avons dduit 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

Manifeste agile - Wikipdia

Page 2 of 3

Les 4 valeursLes quatre valeurs fondamentales Agiles sont : Davantage linteraction avec les personnes que les processus et les outils. Davantage un produit oprationnel quune documentation plthorique. Davantage la collaboration avec le client que la ngociation de contrat. Davantage la ractivit face au changement que le suivi d'un plan.2

Les 12 principes Notre premire priorit est de satisfaire le client en livrant tt et rgulirement des logiciels utiles. Le changement est accept, mme tardivement dans le dveloppement. Les processus agiles exploitent le changement comme avantage comptitif pour le client. Livrer frquemment une application fonctionnelle, toutes les deux semaines deux mois, avec une tendance pour la priode la plus courte. Les experts mtier et les dveloppeurs doivent collaborer quotidiennement au projet. Btissez le projet autour de personnes motives. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacit faire le travail. La mthode 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 dveloppement soutenable. Commanditaires, dveloppeurs et utilisateurs devraient pouvoir maintenir le rythme indfiniment. Une attention continue l'excellence technique et la qualit de la conception amliore l'agilit. La simplicit - l'art de maximiser la quantit de travail ne pas faire - est essentielle. Les meilleures architectures, spcifications et conceptions sont issues d'quipes qui s'autoorganisent. intervalle rgulier, l'quipe rflchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.

Rsum de la mise en pratiqueLe dveloppement Agile, appel aussi dveloppement adaptatif, se caractrise donc par un style de conduite de projet itratif incrmental, centr sur lautonomie des ressources humaines impliques dans la spcification, la production et la validation dune application intgre et teste en continu (Mthode Agile). Cest partir de ces ralits pratiques, et non pas sur la base dune thorie globale ou structurante, que lAgilit progresse vers les sphres les plus hautes de lorganisation.

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

01/06/2010

Manifeste agile - Wikipdia

Page 3 of 3

OrganisationL'Agile Alliance est une organisation sans but lucratif charge de promouvoir l'chelle mondiale les valeurs et principes du Manifeste Agile.

Notes et rfrences1. "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, aot 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 aussiArticles connexes Mthode 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, Aot 2001 (http://www.hristov.com/andrey/fhtstuttgart/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 . Dernire modification de cette page le 28 mai 2010 14:43. 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/Manifeste_Agile

01/06/2010

Scrum - Wikipdia

Page 1 of 19

ScrumScrum est une mthode agile pour la gestion de projets. Elle a t conue pour amliorer grandement la productivit dans les quipes auparavant paralyses par des mthodologies plus lourdes. La mthode Scrum a t conue pour la gestion de projets de dveloppement de logiciels. Elle peut aussi tre utilise par des quipes de maintenance. Dans le cas de trs grands projets, les quipes se multiplient et on parle alors de Scrum de Scrums. La mthode Scrum peut thoriquement s'appliquer n'importe quel contexte ou un groupe de personnes qui travaillent ensemble pour atteindre un but commun (comme grer une petite cole, des glises, des projets de recherche scientifique ou planifier un mariage).

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

01/06/2010

Scrum - Wikipdia

Page 2 of 19

Par contre, la mthode Scrum ne couvre aucune technique d'ingnierie du logiciel. Aussi, son utilisation dans le contexte du dveloppement d'une application informatique ncessite de lui adjoindre une mthode complmentaire (comme l' Extreme Programming, par exemple).

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

01/06/2010

Scrum - Wikipdia

Page 3 of 19

Sommaire1 Historique 2 Caractristiques 3 Quelques rappels sur les mthodes 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 ngociation de contrat 3.2.4 Rponse au changement contre suivi d'un plan prdfini 3.3 Ides cl 4 Rles 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 vlocit 7.3 Items de backlog de sprint 8 Droulement d'un sprint 8.1 Runion de planification 8.2 Au quotidien 8.3 Revue de sprint 8.4 Rtrospective du sprint 9 Complments 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 Interprtation 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 propritaires 9.6.4 Autres outils 10 Conclusion 10.1 Scrum 10.2 Mise en garde 11 Glossaire 12 Voir aussi 12 1 Articles connexes http://fr.wikipedia.org/wiki/Scrum 01/06/2010

Scrum - Wikipdia

Page 4 of 19

HistoriqueEn 1986, Hirotaka Takeuchi et Ikujiro Nonaka dcrivent une nouvelle approche holistique qui 1 augmenterait la vitesse et la flexibilit dans le dveloppement commercial de nouveaux produits . Dans celle-ci les phases se chevauchent fortement et l'ensemble du processus est ralis par une quipe aux comptences croises travers diffrentes 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 ). En 1991, DeGrace et Stahl, dans "Wicked problems, righteous solutions" , font rfrence cette approche comme Scrum (mle, en anglais), un terme de rugby mentionn dans l'article de Takeuchi et Nonaka. Dans le dbut des annes 1990, Ken Schwaber a utilis une approche qui a conduit Scrum au sein de son entreprise, Advanced Development Methods. En mme temps, Jeff Sutherland, John Scumniotales et Jeff McKenna dveloppent une approche similaire Easel Corporation et sont 3 les premiers appeler cela Scrum . En 1995, Sutherland et Schwaber ont prsent conjointement un document dcrivant Scrum l'OOPSLA de 1995 Austin. Schwaber et Sutherland ont collabor au cours des annes suivantes pour fusionner les publications, leurs expriences et les meilleures pratiques du secteur en ce qui est maintenant connu comme Scrum. En 2001, Schwaber fait quipe avec Mike Beedle pour dcrire la mthode dans le livre "Agile Software Development With Scrum". En France, le premier livre franais entirement consacr Scrum est publi en fvrier 2010 : 4 "SCRUM : Le guide pratique de la mthode agile la plus populaire" .2

CaractristiquesLe terme Scrum est emprunt au rugby et signifie mle. Ce processus s'articule en effet autour d'une quipe soude, qui cherche atteindre un but, comme c'est le cas en rugby pour avancer avec le ballon pendant une mle. Le principe de base de Scrum est de focaliser l'quipe de faon itrative sur un ensemble de fonctionnalits raliser, dans des itrations de dure fixe de une quatre semaines, appeles sprints. Chaque sprint possde un but atteindre, dfini par le directeur de produit, partir duquel sont choisies les fonctionnalits implmenter dans ce sprint. Un sprint aboutit toujours sur la livraison d'un produit partiel fonctionnel. Pendant ce temps, le ScrumMaster a la charge de rduire au maximum les perturbations extrieures et de rsoudre les problmes non techniques de l'quipe. Un principe fort en Scrum est la participation active du client pour dfinir les priorits dans les fonctionnalits du logiciel et pour choisir celles qui seront ralises dans chaque sprint. Il peut tout moment complter ou modifier la liste des fonctionnalits raliser, mais jamais celles qui sont en cours de ralisation pendant un sprint.

Quelques rappels sur les mthodes agilesOrigineEn 2001, 17 reprsentants des mthodes lgres alternatives aux processus lourds traditionnels se sont runis pour trouver les points communs leurs mthodes "to find common ground". De cette runion

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

01/06/2010

Scrum - Wikipdia

Page 5 of 19

de quelques jours est n le Manifeste Agile : un texte bref nonant des grands concepts, simples, mais qui proposent une nouvelle faon de penser un projet de dveloppement informatique. Si certains dnoncent une certaine vidence de ces concepts, il n'en est pas moins que ce manifeste a pour lui le mrite de les formaliser et surtout de les structurer en un tout homogne et cohrent, par opposition aux pratiques semblables mais compltement htrognes d'une entreprise l'autre et d'un projet l'autre.

5

Grands principesLe manifeste agile rsume sa philosophie en quatre oppositions entre les concepts traditionnels et les concepts proposs. Individus et interactions contre processus et outils Ce sont les individus qui font la valeur du travail accompli, ce sont donc eux que lon doit privilgier. Sans lartisan, les meilleurs outils ne servent rien. Les processus qui dfinissent ce que doit faire chaque personne brident le potentiel cach derrire chacun : faire interagir les gens au maximum est bien plus fructueux et permet d'amliorer grandement l'efficacit et la qualit du travail fourni, en rassemblant des visions diffrentes d'un mme problme. Logiciel qui fonctionne contre documentation exhaustive Les processus lourds gnrent une documentation qui se veut exhaustive avec tous ses inconvnients : ambigit du langage, cot de la rdaction, cot du maintien en accord avec la ralit, etc. Ces documents ne sont qu'une illusion d'avancement du projet. Mme une conception technique initiale peut tre compltement remise en cause en phase de codage (ou aprs) : comment peut-on alors dterminer l'avancement du projet ? Une rgression ? Dans les mthodes Agiles, un seul critre 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 ngociation de contrat Dans tout projet, le but premier est de gagner de largent, autant pour le client (rentabilisation) que pour le fournisseur (prestation). Si la ngociation protge plus ou moins des risques financiers, elle peut provoquer lchec des projets (dlais non respects, budgets insuffisants) et engendrer d'interminables procs 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 : russir le projet. Rponse au changement contre suivi d'un plan prdfini Un plan prdfini a tendance nous rendre autistes aux vnements qui surviennent pendant le projet. Il est en plus l'origine des conflits client/fournisseur classiques sur les dlais de livraison. Pour le client, pouvoir adapter les besoins en cours de projet est un atout concurrentiel : il est ractif aux

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

01/06/2010

Scrum - Wikipdia

Page 6 of 19

fluctuations des marchs et s'assure en plus que le logiciel dvelopp rpond parfaitement ses vritables besoins. Les mthodes Agiles sont conues pour sadapter au changement, en assurant un plan macroscopique prcis et adaptatif.

Ides cl Le client au cur du projet Esprit dquipe La communication est la cl Simplicit, efficacit et qualit Flexibilit aux changements Avancement bas sur le concret

RlesScrum dfinit trois rles principaux : le directeur de produit, le facilitateur / animateur et l'quipe. Des intervenants peuvent s'intgrer galement au projet de faon plus ponctuelle.

Directeur de produitLe directeur de produit (Product Owner) est le reprsentant des clients et utilisateurs. C'est lui qui dfinit l'ordre dans lequel les fonctionnalits seront dveloppes et qui prend les dcisions Rles dans Scrum importantes concernant l'orientation du projet. Le terme directeur n'est d'ailleurs pas prendre au sens hirarchique du terme, mais dans le sens de l'orientation. Dans l'idal, le directeur de produit travaille dans la mme pice que l'quipe. Il est important qu'il reste trs disponible pour rpondre aux questions de l'quipe et pour lui donner son avis sur divers aspects du logiciel (interface par exemple).

quipeL'quipe ne comporte pas de rles prdfinis, elle est auto-gre. Il n'y a pas non plus de notion de hirarchie interne : toutes les dcisions sont prises ensemble et personne ne donne d'ordre l'quipe sur sa faon de procder. Contrairement ce que l'on pourrait croire, les quipes auto-gres sont celles qui sont les plus efficaces et qui produisent le meilleur niveau de qualit de faon spontane. L'quipe s'adresse directement au directeur de produit. Il est conseill qu'elle lui montre le plus souvent possible le logiciel dvelopp pour qu'il puisse ajuster les dtails d'ergonomie et d'interface par exemple.

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

01/06/2010

Scrum - Wikipdia

Page 7 of 19

Facilitateur / AnimateurLe facilitateur / animateur (ScrumMaster) joue un rle capital : c'est lui qui est charg de protger l'quipe de tous les lments perturbateurs extrieurs l'quipe et de rsoudre ses problmes non techniques (administratifs par exemple). Il doit aussi veiller ce que les valeurs de Scrum soient appliques, mais il n'est pas un chef de projet ni un intermdiaire de communication avec les clients. On parle parfois d'quipe tendue, qui intgre en plus le ScrumMaster et le directeur de produit. Ce concept renforce l'ide que client et fournisseur travaillent d'un commun effort vers le succs du projet.

IntervenantsLes intervenants (Stakeholders) sont les personnes qui souhaitent avoir une vue sur le projet sans rellement s'investir dedans. Il peut s'agir par exemple d'experts techniques ou d'agents de direction qui souhaitent avoir une vue trs loigne de l'avancement du projet.

PlanificationScrum utilise une planification trois niveaux : release/projet, sprint et quotidien.

SprintsExemple de planification en Scrum Scrum est un processus itratif : les itrations sont appeles des sprints et durent en thorie 30 jours calendaires. En pratique, les itrations durent gnralement entre 2 et 4 semaines. Chaque sprint possde un but et on lui associe une liste d'items de backlog de produit (fonctionnalits) raliser. Ces items sont dcomposs par l'quipe en tches lmentaires de quelques heures, les items de backlog de sprint.

Pendant un sprint, les items de backlog de sprint raliser ne peuvent pas tre changs. Les changements ventuels sont pris en compte dans le backlog de produit et seront ventuellement raliss 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 prvu.

ReleasesPour amliorer la lisibilit du projet, on regroupe gnralement des itrations 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.

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

01/06/2010

Scrum - Wikipdia

Page 8 of 19

Il est intressant de planifier l'chelle d'une release, en rpartissant 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.

QuotidienAu quotidien, une runion, le ScrumMeeting, permet l'quipe et au ScrumMaster de faire un point d'avancement sur les tches et sur les difficults rencontres.

Gestion des besoinsBacklog de produitScrum utilise une approche fonctionnelle pour rcolter les besoins des utilisateurs. L'objectif est d'tablir une liste de fonctionnalits raliser, 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 rserve, un retard accumul ; aussi ce terme a t gard tel quel). chaque item de backlog sont associs deux attributs : une estimation en points arbitraires (voir Estimation) et une valeur client, qui est dfinie par le directeur de produit (retour sur investissement par exemple). Ce dernier dfinit dans quel ordre devront tre raliss ces items. Il peut changer cet ordre en cours de projet et mme 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 raliser au fur et mesure des sprints. Remarque : il arrive souvent qu'on utilise dans Scrum les User Stories de la mthode Extreme Programming, qui proposent des pratiques et des techniques intressantes (le Planning poker pour les estimer par exemple).

Backlog de sprintLorsqu'on dmarre un sprint, on choisit quels items du backlog de produit seront raliss dans ce sprint. L'quipe dcompose ensuite chaque item en liste de tches lmentaires (techniques ou non), chaque tche tant estime en heures et ne devant pas durer plus de 2 jours. On constitue ainsi le backlog de sprint. Pendant le droulement du sprint, chaque quipier s'affecte des tches du backlog de sprint et les ralise. Il met jour rgulirement dans le backlog du sprint le reste faire de chaque tche. Les tches ne sont pas rparties initialement entre tous les quipiers, elles sont prises au fur et mesure que les prcdentes sont termines. 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 raliser au fur et mesure du sprint.

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

01/06/2010

Scrum - Wikipdia

Page 9 of 19

EstimationsScrum ne dfinit pas spcialement d'units pour les items des backlogs. Nanmoins, certaines techniques se sont imposes de fait.

Items de backlog de produitLes items de backlog de produit sont souvent des User Stories empruntes Extreme Programming. Ces User Stories sont estimes en points relatifs, sans unit. L'quipe prend un item reprsentatif et lui affecte un nombre de points arbitraire. Cela devient un rfrentiel pour estimer les autres items. Par exemple, un item qui vaut 2 points reprsente deux fois plus de travail qu'un item qui en vaut 1. Pour les valeurs, on utilise souvent les premires valeurs de la suite de Fibonacci (1,2,3,5,8,13), qui vitent les difficults entre valeurs proches (8 et 9 par exemple). L'intrt de cette dmarche est d'avoir une ide du travail requis pour raliser chaque fonctionnalit sans pour autant lui donner une valeur en jours que le directeur de produit serait tent de considrer comme dfinitivement acquise. En revanche, on utilise la vlocit pour planifier le projet l'chelle macroscopique de faon fiable et prcise.

Calcul de vlocitUne fois que tous les items de backlog de produit ont t estims, on attribue un certain nombre d'items raliser aux sprints successifs. Ainsi, une fois un sprint termin, on sait combien de points ont t raliss et on dfinit alors la vlocit de l'quipe, c'est--dire le nombre de points qu'elle peut raliser en un sprint. En partant de cette vlocit et du total de points raliser, on peut dterminer le nombre de sprints qui seront ncessaires pour terminer le projet (ou la release en cours). L'intrt, c'est qu'on a une vision de plus en plus fiable (retours d'exprience de sprint en sprint) de la date d'aboutissement du projet, tout en permettant d'amnager les items de backlog du produit en cours de route.

Items de backlog de sprintLes items de backlog de sprint sont gnralement exprims en heures et ne doivent pas dpasser 2 journes de travail, auquel cas il convient de les dcomposer en plusieurs items. Par abus de langage, on emploie le terme de tches, les concepts tant trs proches.

Droulement d'un sprintRunion de planificationTout le monde est prsent cette runion, qui ne doit pas durer plus de 4 heures. La runion de planification (Sprint Planning) consiste dfinir d'abord un but pour le sprint, puis choisir les items de backlog de produit qui seront raliss dans ce sprint. Cette premire partie du sprint planning reprsente l'engagement de l'quipe. Compte tenu des conditions de succs nonces par le directeur

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

01/06/2010

Scrum - Wikipdia

Page 10 of 19

de produit et de ses connaissances techniques, l'quipe s'engage raliser un ensemble d'items du backlog de produit. Dans un second temps, l'quipe dcompose chaque item du backlog de produit en liste de tches (items du backlog du sprint), puis estime chaque tche en heures. Il est important que le directeur de produit soit prsent dans cette tape, il est possible qu'il y ait des tches le concernant (comme la rdaction des rgles mtier que le logiciel devra respecter et la dfinition des tests fonctionnels).

Au quotidienChaque journe de travail commence par une runion de 15 minutes maximum appele mle quotidienne (Daily Scrum). Seuls l'quipe, le directeur de produit et le ScrumMaster peuvent parler, tous les autres peuvent couter mais pas intervenir (leur prsence n'est pas obligatoire). A tour de rle, chaque membre rpond 3 questions : Qu'est-ce que j'ai fait hier ? Qu'est-ce que je compte faire aujourd'hui ? Quelles sont les difficults que je rencontre ? Le tour de parole doit tre scrupuleusement respect pour viter que le Scrum drive sur des discussions techniques et dborde des 15 minutes. Si le besoin s'en fait sentir, des discussions sont alors menes librement aprs le Scrum. Cette runion a un but de synchronisation pour l'quipe et ne doit pas tre vcue 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 mme pice, dont le ScrumMaster a la responsabilit de maintenir la qualit de son environnement. Les activits se droulent ventuellement en parallle : analyse, conception, codage, intgration, tests, etc. Scrum ne dfinit volontairement pas de dmarche technique pour le dveloppement du logiciel : l'quipe s'auto-gre et dcide en toute autonomie de la faon dont elle va travailler. Remarque : Il est assez frquent que les quipes utilisent la dmarche de dveloppement guid par les tests. Cela consiste coder en premier lieu les modules de test vrifiant les contraintes mtier, puis coder ensuite le logiciel proprement parler, en excutant les tests rgulirement. Cela permet de s'assurer entre autres de la non-rgression du logiciel au fil des sprints.

Revue de sprint la fin du sprint, tout le monde se runit 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 raliss. Elle effectue ensuite une dmonstration du logiciel produit. C'est sur la base de cette dmonstration que le directeur de produit valide chaque fonctionnalit planifie pour ce sprint. Une fois le bilan du sprint ralis, l'quipe et le directeur de produit proposent des amnagements sur le backlog du produit et sur la planification provisoire de la release. Il est probable qu' ce moment des items soient ajouts, modifis ou restims, en consquence de ce qui a t dcouvert

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

01/06/2010

Scrum - Wikipdia

Page 11 of 19

Rtrospective du sprintLa rtrospective 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 dcisions pour s'amliorer. Il est tout fait possible d'apporter des amnagements la mthode Scrum dans le but de s'amliorer. Il faut tre trs vigilant ne pas retomber dans des pratiques rigides des mthodologies plus classiques.

ComplmentsLancement du projetScrum prsuppose que le backlog de produit est dj dfini au dbut du projet. Une approche possible pour constituer ce backlog est de raliser une phase de lancement. Cette phase de lancement s'articule autour de deux axes de rflexion : l'tude d'opportunit et l'expression initiale des besoins. L'tude d'opportunit est trs variable d'un projet l'autre, tout dpend 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 lment dfini dans Scrum et n'est surtout pas une activit de contractualisation d'un cahier des charges. L'esprit d'une telle activit dans les mthodes Agiles est de dfinir d'une part le cadre du projet (pour que l'quipe s'imprgne du contexte mtier) et d'autre part une premire analyse globale des besoins. L'objectif est d'identifier un maximum de fonctionnalits que le logiciel devra implmenter, en se limitant un niveau de prcision assez grossier. On peut par exemple utiliser une approche par raffinages successifs, en partant des secteurs mtiers concerns par l'application, puis en identifiant les activits mtier, qu'on dcompose en tches mtier qui correspondent des fonctionnalits que l'on doit/peut ou non implmenter dans le logiciel final. L'objectif pour Scrum est de produire la premire version du backlog de produit.

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

01/06/2010

Scrum - Wikipdia

Page 12 of 19

Vue globale

Vue synthtique du processus Scrum

Burndown ChartsLes burndown charts (graphiques d'avancement) permettent de visualiser graphiquement l'avancement du travail. Une interprtation simple permet d'avoir une ide sur les chances futures.

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

01/06/2010

Scrum - Wikipdia

Page 13 of 19

Sprint Burndown Chart

Exemple de Sprint Burndown Chart

Ce graphique reprsente 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.

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

01/06/2010

Scrum - Wikipdia

Page 14 of 19

Release Burndown Chart

Exemple de Release Burndown Chart

Ce graphique reprsente 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. Interprtation Ces graphiques sont trs intressants analyser et interprter. Outre le fait de montrer l'avancement concret du travail, ils permettent d'anticiper de faon relativement fiable les chances futures en cours du sprint ou de la release. On peut observer de lgres augmentations du reste faire sur le burndown chart du sprint. Cela correspond gnralement une restimation 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 mme phnomne peut s'observer sur des lgres diminutions, pour les mmes raisons. On peut utiliser en cours du sprint la tendance de la courbe pour avoir une ide approximative de la fin du sprint. Cela consiste prendre un segment de droite dont la pente est reprsentative des valeurs dj recenses 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 dcision sur la suppression (ou l'ajout) d'un item de backlog du produit raliser 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 mme chose pour les burndown charts de release. Si la date de publication de la release est clairement au-del de ce que l'on esprait, on peut aviser en enlevant des items de backlog du produit ou changeant leur ordre, de sorte que les fonctionnalits les moins importantes soient celles qui risquent de ne pas tre dveloppes temps.

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

01/06/2010

Scrum - Wikipdia

Page 15 of 19

Cette approche, bien que base sur des tendances approximatives, permet d'identifier trs tt les risques de dfaillance et d'agir en consquence, en conservant l'esprit le caractre critique des fonctionnalits dvelopper. Ces dcisions importantes relvent compltement du directeur de produit. Une dernire chose importante : la fiabilit de la vlocit de l'quipe et des estimations qu'elle a faites augmente au fil des sprints. On limine de cette faon les risques majeurs au plus tt dans le projet.

Qualit de l'environnement de travailUn concept fort de Scrum est la qualit de l'environnement de travail de l'quipe. Cela inclut : Pas de changements imposs pendant un sprint Toute l'quipe dans une mme pice Un tableau blanc et/ou en lige Un bon outil de suivi du projet Prvenir des interventions extrieures (tlphone, irruption dans la pice, etc.) Tout ce qui peut rendre l'quipe plus sereine et efficace

Documentation de projetScrum n'impose aucune documentation particulire 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 rdiger un document, on peut se poser une question trs 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 mtiers (processus, objets, etc.), associ au backlog de produit : uniquement si la logique mtier du client qui concerne l'application est vraiment complexe. Dans ce cas, l'quipe devrait produire ce document avec lui. Diagramme de squence, associ un item du backlog du produit : uniquement si la fonctionnalit aura une utilisation complexe, tant au niveau mtier 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 vidos de dmonstrations commentes est une solution efficace. Les FAQ pour la hotline : des cas classiques o les utilisateurs ne vont pas comprendre un comportement mtier. Cela permet de traiter un maximum de problmes au niveau de la hotline, avant que cela n'arrive aux quipes de dveloppement/maintenance. Bref, un document ne doit tre produit que si son utilit est relle et immdiate.

Outils pour ScrumUn 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 possibilits.

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

01/06/2010

Scrum - Wikipdia

Page 16 of 19

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 donnes est simplement un peu moins agrable. Outils libres IceScrum (http://www.icescrum.org) (open-source et dmo en ligne) theSCRUM (http://www.the-scrum.org/) open-source et dmo en ligne, implmente un tableau blanc virtuel EPF (http://www.eclipse.org/epf) Eclipse Process Framework intgre un plug-in Scrum (opensource) OpenERP (http://www.openerp.com) OpenERP intgre un module Scrum (open-source) Outils propritaires AccuRev (http://www.accurev.com) (Solutions de gestion de configuration logicielle intgrant les mthodes Agile et Scrum) ScrumDesk (http://www.scrumdesk.com) (gratuit pour 5 utilisateurs maximum) Intra'Know PROJET (http://www.intraknow.com) (cette solution collaborative intgre les grands principes de la mthode 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/) (Dmonstration en ligne gratuite) ScrumEdge (http://www.scrumedge.com/) (Dmonstration en ligne gratuite) Serena Agile On Demand (http://www.serena.com/products/agile-software/) Entirement en mode SAAS. Aucune installation ncessaire. 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/) .

ConclusionScrumScrum est un processus de dveloppement de logiciels qui s'intresse plutt l'organisation du projet qu'aux aspects techniques. Son cadre de travail est sa force, si bien que cette mthode pourrait tre applique d'autres domaines. Son approche itrative et base sur les besoins prioriss du client lui

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

01/06/2010

Scrum - Wikipdia

Page 17 of 19

confrent une flexibilit extrme. Elle incarne bien par l l'tat d'esprit de la mle de rugby : avancer tous ensemble vers un but commun, la russite du projet. Scrum est un processus intressant comme premier pas vers les mthodes Agiles : il est facile comprendre et pratiquer. La seule difficult relve plutt de l'environnement organisationnel (voir la mise en garde ci-dessous).

Mise en gardeOn entend de plus en plus de socits clamer qu'elles sont Agiles, comme argument commercial la mode, parce qu'elles utilisent quelques pratiques des mthodes Agiles. Mais tre Agile, c'est bien plus que de mettre en pratique une mthode. L'Agilit requiert des dispositions particulires qui sont loin d'tre faciles mettre en place : Une organisation adapte : il est trs difficile de faire admettre aux organes dcideurs d'une entreprise de travailler de faon Agile. En effet, cela signifie de ne pas disposer ds le dpart d'une date et d'un budget trs prcis, mais plutt d'un ordre de grandeur. Un tat d'esprit : tre Agile, c'est privilgier l'esprit d'quipe et pas seulement dans la ralisation technique. Le client doit comprendre que l'on attend de lui un investissement personnel bien suprieur celui des mthodes plus classiques, en testant le logiciel souvent et en participant toutes les runions. Un environnement favorable : liminer les contraintes dans une entreprise n'est pas toujours vident. Comment limiter les appels tlphoniques trop frquents, les irruptions dans la pice de l'quipe, les oprations "urgentes" demandes alatoirement par la direction, etc. ? Bref, utiliser une mthode comme Scrum au niveau de l'quipe technique ne suffit pas. L'Agilit est une faon de travailler diffrente de ce dont on a l'habitude, c'est l'attitude du changement, de la flexibilit, de l'adaptation et de l'amlioration continue. Ce n'est pas aussi simple qu'une mthode

GlossaireDirecteur de produit (Product Owner) personne responsable de produire et maintenir jour le backlog de produit. C'est lui qui en dtermine les priorits et qui prend les dcisions concernant l'orientation du projet. ScrumMaster membre de l'quipe dont l'objectif principal est de la protger des perturbations extrieures. Il est compltement transparent pour la communication entre l'quipe et les clients et n'a aucun pouvoir hirarchique sur l'quipe. C'est en revanche un facilitateur pour les problmes non techniques de l'quipe. Backlog de produit (Product Backlog) liste des fonctionnalits qui devront tre ralises par le logiciel. Backlog de sprint (Sprint Backlog) liste des tches accomplir pendant un sprint. Elles correspondent la ralisation des items de backlog du produit affects au sprint. Mle quotidienne (Daily Scrum) runion quotidienne de 15 minutes qui a pour but de faire le point sur ce qui a t fait depuis la dernire mle, ce qui est prvu de faire jusqu' la prochaine et quelles sont les embches rencontres durant le travail.

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

01/06/2010

Scrum - Wikipdia

Page 18 of 19

Sprint nom d'une itration dans Scrum. Cette itration dure 30 jours calendaires en thorie, mais en pratique on utilise plutt entre 2 et 4 semaines. Pendant une itration, l'quipe doit dvelopper une liste d'items du backlog de produit qui a t dfinie au dbut 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 aussiArticles connexes Cycle de dveloppement Mthode agile Extreme programming

Liens externes (en) Site officiel Scrum (http://www.controlchaos.com/) (en) Agile Alliance (http://www.agilealliance.org/) : Communaut autour des mthodes 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 prsentation a t utilise dans cet article. (fr) Planification et gestion de projet informatique : SCRUM (http://techtalks.intellicore.net/2008/04/24/video-planification-gestion-projet-informatique-scrum/) : Confrence vido de Christian Trotobas enregistre aux Intellicore Tech Talks (http://techtalks.intellicore.net) au sujet de la mthode 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) Vido "Scrum in the real World" (http://www.vimeo.com/4587652/) : Une Vido sur l'application de la mthode Scrum sur un projet Web. (en) Processus "Scrum Process Asset Library" (http://scrum.gem-up.com) : Un moyen facile de naviguer la methodologie Scrum

Notes et rfrences1. The New New Product Development Game (http://aplnrichmond.pbworks.com/f/New+New+Prod+Devel+Game.pdf) Havard Business Review, jan-fv 1986 er 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 mthode agile la plus populaire (http://www.aubryconseil.com/pages/LivreScrum)

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

01/06/2010

Scrum - Wikipdia

Page 19 of 19

5. Manifesto for Agile Software Development (http://agilemanifesto.org/)

Ce document provient de http://fr.wikipedia.org/wiki/Scrum . Dernire modification de cette page le 28 mai 2010 13:32. 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/Scrum

01/06/2010

Extreme programming - Wikipdia

Page 1 of 7

Extreme programmingL'Extreme Programming (XP) est une mthode agile de gestion de projet informatique adapte aux quipes rduites avec des besoins changeants. Elle pousse l'extrme des principes simples.

Sommaire1 Origine 2 Pratiques extrmes 3 Cycle de dveloppement 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 Intgration 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 mtaphores 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 binme 4.3 Autres principes 5 Environnements dfavorables 6 Voir aussi 6.1 Articles connexes 6.2 Bibliographie 6.3 Liens externes 7 Notes et rfrences

OrigineL'Extreme Programming a t invente par Kent Beck, Ward Cunningham et Ron Jeffries pendant leur travail sur un projet C3 de calcul des rmunrations chez Chrysler. Kent Beck, chef de projet en mars 1996 commena affiner la mthodologie de dveloppement utilise sur le projet. La

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

01/06/2010

Extreme programming - Wikipdia

Page 2 of 7

mthode est ne officiellement en octobre 1999 avec le livre Extreme Programming Explained de Kent Beck.

Pratiques extrmesDans le livre Extreme Programming Explained, la mthode est dfinie comme : une tentative de rconcilier lhumain avec la productivit ; un mcanisme pour faciliter le changement social ; une voie d'amlioration ; un style de dveloppement ; une discipline de dveloppement dapplications informatiques.

Son but principal est de rduire les cots du changement. Dans les mthodes traditionnelles, les besoins sont dfinis et souvent fixs au dpart du projet informatique ce qui accrot les cots ultrieurs de modifications. XP sattache rendre le projet plus flexible et ouvert au changement en introduisant des valeurs de base, des principes et des pratiques. Les principes de cette mthode ne sont pas nouveaux : ils existent dans l'industrie du logiciel depuis des dizaines d'annes et dans les mthodes de management depuis encore plus longtemps. L'originalit de la mthode est de les pousser l'extrme : puisque la revue de code est une bonne pratique, elle sera faite en permanence (par un binme) ; puisque les tests sont utiles, ils seront faits systmatiquement 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 comprhension est importante, nous dfinirons et ferons voluer ensemble des mtaphores ; puisque l'intgration des modifications est cruciale, nous l'effectuerons plusieurs fois par jour ; puisque les besoins voluent vite, nous ferons des cycles de dveloppement trs rapides pour nous adapter au changement.

Cycle de dveloppementL'Extreme Programming repose sur des cycles rapides de dveloppement (des itrations de quelques semaines) dont les tapes sont les suivantes : une phase d'exploration dtermine les scnarios clients qui seront fournis pendant cette itration ; l'quipe transforme les scnarios en tches raliser et en tests fonctionnels ; chaque dveloppeur s'attribue des tches et les ralise avec un binme ; lorsque tous les tests fonctionnels passent, le produit est livr.Le cycle de l'Extreme Programming

Le cycle se rpte tant que le client peut fournir des scnarios livrer. Gnralement le cycle de la premire livraison se caractrise par sa dure et le volume important de fonctionnalits embarques. Aprs la premire mise en production, les itrations peuvent devenir plus courtes (une semaine par exemple).

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

01/06/2010

Extreme programming - Wikipdia

Page 3 of 7

La programmation comme discipline collectiveTout en mettant l'accent sur les bonnes pratiques de programmation, XP prconise un droulement par itrations courtes et gres collectivement, avec une implication constante du client. Il en dcoule une redfinition de la relation entre client et fournisseur avec de surprenants rsultats en termes de qualit de code, de dlais et de satisfaction de la demande du client.

ValeursL'eXtreme Programming repose sur cinq valeurs fondamentales : La communication C'est le moyen fondamental pour viter les problmes. Les pratiques que prconise l'XP imposent une communication intense. Les tests, la programmation en binme et le jeu du planning obligent les dveloppeurs, les dcideurs 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 faon la plus simple d'arriver au rsultat 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 frquentes permettent de tester les fonctionnalits 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 inadapte. C'est difficile, mais la simplicit, le feedback et la communication rendent ces tches accessibles. Le respect Cette valeur fut ajoute dans la deuxime dition de Extreme Programming Explained de K. Beck.

PratiquesCes cinq valeurs se dclinent en treize pratiques qui se renforcent mutuellement :

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

01/06/2010

Extreme programming - Wikipdia

Page 4 of 7

Client sur site Un reprsentant du client doit, si possible, tre prsent pendant toute la dure du projet. Il doit avoir les connaissances de l'utilisateur final et avoir une vision globale du rsultat obtenir. Il ralise son travail habituel tout en tant disponible pour rpondre aux questions de l'quipe. Jeu du Planning ou Planning poker Le client cre des scnarios pour les fonctionnalits qu'il souhaite obtenir. L'quipe value le temps ncessaire pour les implmenter. Le client slectionne ensuite les scnarios en fonction des priorits et du temps disponible. Intgration continue Lorsqu'une tche est termine, les modifications sont immdiatement intgres dans le produit complet. On vite ainsi la surcharge de travail lie l'intgration de tous les lments avant la livraison. Les tests facilitent grandement cette intgration : quand tous les tests passent, l'intgration est termine. Petites livraisons Les livraisons doivent tre les plus frquentes possible. L'intgration continue et les tests rduisent considrablement le cot de livraison. Rythme soutenable L'quipe ne fait pas d'heures supplmentaires. Si le cas se prsente, il faut revoir le planning. Un dveloppeur fatigu travaille mal. En effet le programmeur ne doit pas dpasser 35 heures de travail par semaine (formations inclues) car le dpassement de ce taux peut engendrer des problmes ce qui influe sur la qualit du dveloppement. Tests de recette (ou tests fonctionnels) partir des scnarios dfinis par le client, l'quipe cre des procdures de test qui permettent de vrifier l'avancement du dveloppement. Lorsque tous les tests fonctionnels passent, l'itration est termine. Ces tests sont souvent automatiss mais ce n'est pas toujours possible. Tests unitaires Avant d'implmenter une fonctionnalit, le dveloppeur crit un test qui vrifiera que son programme se comporte comme prvu. 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 dveloppeurs, et on sait immdiatement si quelque chose ne fonctionne plus.

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

01/06/2010

Extreme programming - Wikipdia

Page 5 of 7

Conception simple L'objectif d'une itration est d'implmenter les scnarios slectionns par le client et uniquement cela. Envisager les prochaines volutions ferait perdre du temps sans avoir la garantie d'un gain ultrieur. Les tests permettront de changer l'architecture plus tard si ncessaire. Plus l'application est simple, plus il sera facile de la faire voluer lors des prochaines itrations. De mme, la documentation doit tre minimale : on prfrera un programme simple qui ncessite peu d'explications un systme complexe. Utilisation de mtaphores On utilise des mtaphores et des analogies pour dcrire le systme 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) Amlioration rgulire de la qualit du code sans en modifier le comportement. On retravaille le code pour repartir sur de meilleures bases tout en gardant les mmes fonctionnalits. Les phases de refactoring n'apportent rien au client mais permettent aux dveloppeurs d'avancer dans de meilleures conditions et donc plus vite. Appropriation collective du code L'quipe est collectivement responsable de l'application. Chaque dveloppeur peut faire des modifications dans toutes les portions du code, mme celles qu'il n'a pas crites. Les tests diront si quelque chose ne fonctionne plus. Convention de nommage Puisque tous les dveloppeurs interviennent sur tout le code, il est indispensable d'tablir et de respecter des normes de nommage pour les variables, mthodes, objets, classes, fichiers, etc. Programmation en binme 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 suggrant de nouvelles possibilits ou en dcelant d'ventuels problmes. Les dveloppeurs changent frquemment de partenaire ce qui permet d'amliorer la connaissance collective de l'application et d'amliorer la communication au sein de l'quipe.

Autres principes Ne pas ajouter de fonctionnalits plus tt que prvu ; N'optimiser qu' la toute fin.

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

01/06/2010

Extreme programming - Wikipdia

Page 6 of 7

Cette mthode s'appuie sur : une forte ractivit au changement des besoins du client ; un travail d'quipe ; la qualit du code ; la qualit des tests effectus au plus tt.

Environnements dfavorablesEn lieu et place d'inconvnient de la mthode, on parlera plus aisment d'environnements dfavorables dans lesquels la mthode XP n'est pas applicable. Dans ce cas, seule une partie des 1 pratiques peut tre ralise. Les principaux contextes dfavorables sont : un blocage culturel : quand le client ou les dveloppeurs ont l'habitude de fonctionner autrement. L'ingnieur qui l'on attribue des mini-tches quotidiennes et qui doit les raliser avec un binme peut avoir le sentiment que sa fonction est dqualifie. Son principal rle 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 dveloppeurs ou plus car la communication devient difficile : Il est frquent de voir au fil du temps des binmes travailler toujours ensemble, toujours sur les mmes sujets, et former ainsi des sous-quipes spcialises, ce que ne veut pas XP. Par ailleurs, les volutions possibles dans l'entreprise sont trs limites dans la mesure o tous les membres de l'quipe jouent tous les mmes rles. un cot de changement exponentiel car XP ncessite du code propre et simple ; un feedback long ou difficile obtenir : le retour sur investissement est visible sur le moyen/long terme. un amnagement qui empche la communication ou la programmation en binme (il est ncessaire d'avoir une infrastructure open-space). Respect d'une discipline collective et travail en binme au quotidien : cette mthode ne peut pas tre applique avec n'importe qui, car elle dgage trs peu de temps l'autonomie et au travail individuel, dans la mesure o systmatiquement le travail se fait deux sur un mme poste de travail. Les dveloppeurs auront de la difficult tablir un projet professionnel dans leur entreprise. la rsistance au changement.

Voir aussiArticles connexes Mthode agile Cycle de dveloppement Scrum Test Driven Development

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

01/06/2010

Extreme programming - Wikipdia

Page 7 of 7

Bibliographie Kent Beck, eXtreme Programming - La rfrence, 2002 (ISBN 2-7440-1433-8) Jean-Louis Bnard, Laurent Bossavit, Rgis Mdina et Dominic Williams, L'Extreme Programming - Avec deux tudes de cas, 2002 (ISBN 2212110510), nouvelle dition du mme ouvrage sous le nom Gestion de projet eXtreme Programming (ISBN 2-212-11561-X) Thierry Cros, Matrisez 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 trs complet (fr) L'association eXtreme Programming France (http://xp-france.net/) et son wiki (http://xp-france.net/cgi-bin/wiki.pl?XpFrance) (fr) Prsentation complte d'XP Logo site Xp (http://www.regismedina.com/articles/fr/extreme-programming) (fr) Un autre article sur l'XP (http://lagace.developpez.com/extremeprogramming/) (fr) Un expos succinct de la mthode : 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 rponse de Manuel Klimek (http://klimek.box4.net/blog/2007/02/26/xp-cult-or-movement/) ) (en) Extreme programming.org (http://www.extremeprogramming.org/)

Notes et rfrences1. eXtreme Programming - La rfrence, Kent Beck, chapitre 25 - Quand faut-il viter XP

Ce document provient de http://fr.wikipedia.org/wiki/Extreme_programming . Dernire modification de cette page le 22 mai 2010 20:25. 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/Extreme_programming

01/06/2010

Lean - Wikipdia

Page 1 of 3

LeanLe lean est une cole de gestion d'entreprise - voir l'histoire de l'utilisation de ce mot pour nommer le 1 Systme de Production Toyota - s'intresse la performance (productivit, qualit). Les tenants du lean recherchent la performance par l'amlioration continue et l'limination des gaspillages (muda en japonais), dont il existe sept catgories : productions excessives, attentes, transports et manutentions inutiles, tches inutiles, stocks, mouvements inutiles et productions dfectueuses. 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 systme de production Toyota sans que cette quipe ait eu une vision globale du systme. A l'origine le TPS a t cr par Sakichi Toyoda, puis par son fils Kiichiro Toyoda, et enfin par son neveu Eiji Toyoda, assists par un ingnieur surdou Taiichi Ohno. Quand en 1972 aprs 25 ans d'efforts le systme fut dploy 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 cre (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 crer 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 forms, selon les mthodes 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 diffrentes tapes de transmission entre des personnes, et celles-ci ayant invent de nouveaux outils. Aujourd'hui le TSSC est une entreprise indpendante de Toyota. De nombreux consultants amricains 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.

Sommaire1 Concepts de base 2 Lean et changement dans les organisations 3 Notes et rfrences 4 Voir aussi 4.1 Liens externes 4.2 Bibliographie

Concepts de baseLa pense 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 pice pice, le flux tir, le changement rapide d'outils (SMED) et l'intgration 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 sparation de l'homme et de la machine, les outils d'arrt de production au premier dfaut (andon), les mthodes d'limination des

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

01/06/2010

Lean - Wikipdia

Page 2 of 3

causes d'erreur (poka yoke), d'analyse de problme ( Cinq pourquoi ), la r-ingnierie des quipements de production. La dmarche lean est plus riche qu'une simple mthode de production, et forme un systme cohrent de concepts complexes, articuls une pratique originale et des moyens de formalisation et d'appropriation spcifiques ; c'est pourquoi on peut utiliser son endroit le terme d'cole. Les tenants du lean s'appliquent l'enseigner, l'appliquer et rpandre ses rgles au sein de la communaut industrielle. Aprs une premire vague d'engouement dans les annes 1970 et 1980 pour les mthodes japonaises , l'cole du lean s'est formalise aux tats-Unis dans les annes 1990 (le terme 2 mme lean a t invent au MIT en 1987) et a t popularise 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 systme repose et de multiplier les exemples et tudes de cas. On peut distinguer quatre niveaux danalyse du systme de pense lean : une redfinition de la valeur produite par une entreprise, le dveloppement dun schma productif caractristique, le dveloppement d'attitudes managriales originales et la formulation dune stratgie long terme. la valeur : la valeur ajoute dune tche contribuant un processus doit tre dfinie du point de vue du client ; l'entreprise doit assurer un coulement sans interruption de la valeur le long de sa chane de production (en termes plus triviaux, on fait la chasse aux stocks ). le schma de production : l'entreprise produit en tirant sa production en fonction de la demande et non en poussant en fonction des capacits locales de production ; les tches productives sont standardises de manire faciliter l'amlioration continue par suppression des tches non cratrices de valeur ; l'entreprise entretient une relation partenariale riche avec ses fournisseurs et les incite adopter ses mthodes de production ; l'attitude managriale : les managers et les travailleurs doivent trouver et liminer les causes profondes des problmes ds que ces derniers surviennent ; chaque employ est incit rflchir et proposer des amliorations du systme productif. Ceci dbouche sur des chantiers ponctuels d'amlioration (kaizen) ; le management doit se drouler sur le terrain , car seule l'exprience directe des situations de crise permet un diagnostic efficace (genchi genbutsu) ; les dcisions sont ncessairement adoptes par consensus ; la stratgie long terme : l'entreprise doit privilgier les enjeux de long terme en explicitant son objectif global et en l'inscrivant de faon soutenable dans l'avenir ; l'entreprise doit rechercher en permanence l'excellence. Sur ces bases, l'cole de gestion lean est en constante volution. Aprs avoir, ces dernires annes, dpass son cadre initial l'organisation de la production , elle est aujourd'hui perue comme une mthode pertinente pour combattre tous les types dinefficacit : l'intrt pour le lean s'tend aux services administratifs (Lean Office), au dveloppement de produit (Lean Development).

Lean et changement dans les organisationsL'application des principes du lean, notamment l'amlioration continue du systme, impose de profonds changements dans les organisations. La rsolution des problmes au plus prs du terrain, impliquant les oprationnels tout autant que les responsables, est un premier changement d'envergure,

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

01/06/2010

Lean - Wikipdia

Page 3 of 3

tant le changement est plutt peru dans les grands organisations comme quelque chose qui suit la voie hirarchique descendante (top-down), o peu d'autonomie est laisse au terrain dans la prise d'initiative.

Notes et rfrences1. lean Lettre8Octobre2004 (http://lean.enst.fr/wiki/bin/view/Lean/Lettre8Octobre2004) 2. Littralement penser maigre .

Voir aussiLiens 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 varie du lean (http://artoflean.com/elearn_tps/slides/slide_Page_008.jpg)

Bibliographie

Ce document provient de http://fr.wikipedia.org/wiki/Lean . Dernire modification de cette page le 26 mai 2010 11:51. 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/Lean

01/06/2010