methode agile

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

Upload: sebtarris

Post on 24-Jun-2015

747 views

Category:

Documents


8 download

TRANSCRIPT

Page 1: Methode Agile

Méthode agileLes 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 8Méthode agile - Wikipédia

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

Page 2: Methode Agile

commence à coupler les valeurs Agiles aux techniques de l'amélioration continue de la qualité (MTQS ou Lean).

Sommaire1 Historique2 Valeurs3 Principes4 Méthodes Agiles reconnues par date de publication officielle5 Autres Méthodes se reconnaissant de l'agilité6 Tronc des pratiques communes à l'ensemble des méthodes Agiles7 Pratiques différenciatrices des méthodes Agiles8 Pratiques d'autres méthodes proches ou ayant un rapport avec les méthodes agiles9 Optimisation des pratiques10 Bibliographie11 Voir aussi

11.1 Liens internes11.2 Références11.3 Liens externes

11.3.1 Communautés agiles11.3.2 Autres sites traitant de l'agilité ou du génie logiciel

12 Autres liens

Historique

Évolution du courant de pensée Agile en matière de systèmes d'informations

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

En 1986 également, Hirotaka Takeuchi et Ikujiro Nonaka publient "the new product developpement game" dans la Harvard business review. Leur article présente un modèle de développement basé sur l'aptitude au changement, l'auto organisation, l'imbrication des phases de développement, et l'itération (on y fait d'ailleurs mention du mot scrum par analogie au rugby).

En 1991, James Martin (RAD), s’appuyant sur cette vision d’une évolution continue, proposa une méthode de développement rapide d’application. Sa structure, base des approches actuelles, déterminait le phasage essentiel et mettait en œuvre un principe adaptatif fondé sur la validation permanente des utilisateurs.

À partir de 1994, Jean-Pierre Vickoff en France, notamment avec le Processus RAD2 publié par le Gartner Group, et Jennifer Stapleton en Grande-Bretagne, avec DSDM, introduisirent des compléments tels que :

la spécialisation des rôles,■l’instrumentation des communications,■l’organisation des divers types de réunions,■le groupe de facilitation et de rapport,■les « raccourcis méthodologiques » de modélisation,■

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

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

Page 3: Methode Agile

l’architecture de réalisation (imbrication des itérations),■la formalisation de processus légers de mise en œuvre.■

Dans la seconde moitié des années 1990, une vague d’une dizaine de méthodes (dont Extreme programming et Scrum sont les principales représentantes) poussa à l’extrême certaines pratiques de qualité de la construction applicative ainsi que les techniques adaptatives d’estimation, de planification et de pilotage de projet.

En 2001, aux États-Unis, dix-sept figures éminentes du développement logiciel se sont réunies pour débattre du thème unificateur de leurs méthodes respectives, dites méthodes agiles. Les plus connus d'entre eux étaient Ward Cunningham l'inventeur du Wiki via WikiWikiWeb, Kent Beck, père de l'extreme programming et cofondateur de JUnit, Ken Schwaber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith, prônant l'ASD, Alistair Cockburn pour la méthode Crystal clear, Martin Fowler, et Dave Thomas ainsi que Arie van Bennekum pour DSDM (Dynamic System Development Method). Ces 17 experts venant tous d'horizons différents réussirent à extraire de leur concepts respectifs des critères pour définir une nouvelle façon de développer des logiciels :

De cette réunion devait émerger le Manifeste Agile, considéré comme la définition canonique du développement Agile et de ses principes sous-jacents .

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

" Nous avons trouvé une voie améliorant le développement logiciel en réalisant ce travail et en aidant les autres à le faire. De ce fait nous avons déduit des valeurs communes. "

Il aura fallu près de vingt années au mouvement Agile, parallèlement à la pression de la mondialisation, pour bousculer vraiment la conduite de projet classique. Désormais, le futur de l’agilité méthodologique se trouve certainement, d’une part, dans l’instrumentation et la personnalisation « à la carte » des pratiques essentielles pour un contexte spécifique et, d’autre part, dans son élargissement à tous les aspects de l’Agilité organisationnelle.

Valeurs

Dans ce but, elles prônent 4 valeurs fondamentales (entre parenthèse, les citations du manifeste) :

L'équipe (« Personnes et interaction plutôt que processus et outils ») : Dans l'optique agile, l'équipe est bien plus importante que les outils (structurants ou de contrôle) ou les procédures de fonctionnement. Il est préférable d'avoir une équipe soudée et qui communique composée de développeurs (éventuellement à niveaux variables) plutôt qu'une équipe composée d'experts fonctionnant chacun de manière isolée. La communication est une notion fondamentale.

L'application (« Logiciel fonctionnel plutôt que documentation complète ») : Il est vital quel'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

1

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

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

Page 4: Methode Agile

du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du logiciel à ses attentes.

L'acceptation du changement (« Réagir au changement plutôt que suivre un plan ») : La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet. Les premières releases du logiciel vont souvent provoquer des demandes d'évolution.

Principes

Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles :

« Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logicielsutiles ».

« 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éliorel'agilité ».

« La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle ».■« Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent ».

« À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens ».

Méthodes Agiles reconnues par date de publication officielle Rapid Application Development (RAD, 1991)■Dynamic systems development method (DSDM, 1995, consortium anglais commercialisant le RAD)

Scrum (1996)■Feature Driven Development(FDD) (1999)■Extreme programming (XP, 1999)■Adaptive software development (ASD, 2000)■Crystal clear (2004)■

Autres Méthodes se reconnaissant de l'agilité

MACAO ([1] (http://www.jbcc.fr/presentationMACAO_Fr.php) )■Processus Urbanisant les Méthodes Agiles (PUMA (http://www.entreprise-agile.com/) )■KANBAN ([2] (http://fr.wikipedia.org/wiki/Kanban) )■

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

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

Page 5: Methode Agile

Note RUP (Rational Unified Process) n'est pas une méthode Agile et, est de plus un produit propriété d'IBM. Il existe une déclinaison Agile, mais non libre de droits, de RUP sous l'acronyme de AUP (Agile Unified Process).

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

Les pratiques communes liées aux ressources humaines 1.Participation de l’utilisateur final aux groupes de travail.■Groupes de travail disposant du pouvoir de décision.■Autonomie et organisation centralisée de l’équipe (motivation).■Spécification et validation permanente des Exigences.■

Les pratiques communes liées au pilotage du projet 2.Niveau méthodologique variable en fonction des enjeux du projet.■Pilotage par les enjeux et les risques.■Planification stratégique globale basée sur des itérations rapides.■Réalisation en jalons par prototypage actif itératif et incrémental.■Recherche continue d’amélioration des pratiques.■

Les pratiques communes liées à la qualité de la production 3.Recherche d’excellence technique de la conception.■Vision graphique d’une modélisation nécessaire et suffisante.■Vision de la documentation nécessaire et suffisante.■Normes et techniques raisonnables de qualité du code (métrique).■Architecture à base de composants.■Gestion des changements automatisée.■

Pratiques différenciatrices des méthodes Agiles

Seules quelques techniques complémentaires entre elles, ou mieux adaptées à des typologies et à des tailles de projets spécifiques, différencient les méthodes Agiles (y compris ASD ou Crystal Clear).

Les pratiques différenciatrices les plus marquantes sont :

La méthode DSDM se particularise par la spécialisation des acteurs du projet dans une notion de « rôles ». Ainsi, l'on trouvera dans les réunions DSDM des sponsors exécutifs, des ambassadeurs, des utilisateurs visionnaires, des utilisateurs conseillers, sans oublier l'animateur-facilitateur et des rapporteurs.

La méthode Scrum affirme sa différence dans des pratiques de courtes réunions quotidiennes (Stand-Up meeting). Ces temps de travail commun ont pour objectifs d'améliorer la motivation des participants, de synchroniser les tâches, de débloquer les situations difficiles et d'accroître le partage de la connaissance.

Pour FDD, la particularité nommée Mission focused réside dans une forte orientation vers un but immédiat mesurable guidé par la notion de valeur métier. C'est en fait l'ambition globale d'une itération qui se trouve ainsi renforcée. Cet aspect se retrouve aussi dans la méthode RAD sous la forme des objectifs de Focus ou dans Scrum dans la notion de Sprint. FDD préconise aussi le Features Driven Development. Cette technique se caractérise par des notions de Feature et de Features set (fonctionnalités et groupes de fonctionnalités). La priorité est donnée aux

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

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

Page 6: Methode Agile

fonctionnalités porteuses de valeur. Le RAD propose des techniques proches : livraison en fonctionnalité réduite ou livraison par thèmes.

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

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

2TUP (2 track unified process, prononcez "toutiyoupi") préconise un cycle de vie en Y qui dissociela résolution des questions fonctionnelles et techniques. Le cycle de vie de 2TUP s'apparente à un cycle de développement en cascade mais introduit une forme itérative interne à certaines tâches. Il n'est pas certain que ce cycle s'apparente réellement à une approche Agile. Par contre, 2TUP préconise des formes de recherche de qualité et de performance intéressantes telles que les services réutilisables et la conception générique (Framework et Patron de conception Design pattern) proches des mécanismes architecturaux de RUP.

RUP se caractérise par une approche globale nommée « Vue 4+1 ». Les 5 composants de cette vue sont : la vue des Cas d'utilisation, la vue Logique, la vue d'Implémentation, la vue du Processus, la vue du Déploiement. RUP offre aussi, à l'identique du RAD 2, un Processus guide formel et adaptable comme guide d'activité. Dans le cas de RUP, il est malheureusement propriétaire et orienté outil.

Le plus sérieux apport du RAD à la communication de projet et à la formalisation des exigences applicatives : le Groupe d'Animation et de Rapport (GAR).

Le RAD dans sa version 2 recommande la variabilité de la taille et de la maturité des groupes detravail en fonction des phases du projet afin d'optimiser l'engagement des ressources et de préserver leur intérêt par un travail adapté à leurs préoccupations.

Avec RAD 2, l'organisation performante des réunions est basée sur un mode opératoire des entretiens et sur des techniques de validation permanente.

Toute méthode de conduite de projet devrait inclure un mode opératoire pour les arrêts d'urgence (Go/NoGo). Sur ce point la force du RAD se situe dans la présence d'un animateur-facilitateur. Cette ressource, de préférence externe, doit être neutre en regard des autres intervenants. Elle répond à une autorité supérieure à tous les participants du projet. Ainsi, lorsque le contexte stratégique, économique ou technique d'un projet évolue, ou si les conditions de réalisation se dégradent, l'animateur reporte le problème au dirigeant qui l'a mandaté. Ce dernier peut alors prendre, dans les meilleurs délais, et avec des informations objectives les décisions qui s'imposent.

Le RAD comme les autres méthodes Agiles préconise la formation d'une équipe de développement particulière, le SWAT (Skill With Advanced Tools dérivé de Special Weapons And Tactics). Cette équipe est autonome, spécialement formée, concrètement motivée et outillée. Elle se compose essentiellement d'un profil unique de concepteurs-développeurs formés à des spécialités techniques complémentaires. Le SWAT travaille avec les utilisateurs dans une salle permanente spécialement

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

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

Page 7: Methode Agile

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

Optimisation des pratiques

Selon Jean-Pierre Vickoff dans la communication PUMA (Proposition pour l'Unification des Méthodes Agiles)[3] (http://www.adeli.org/voirdoc.php?dest=lalettre/l48p19.pdf) publié sur le site de ADELI (Association pour la maitrise des Systèmes d'Information) " La méthode Agile idéale s'appuierait sur une utilisation optimisée des pratiques du tronc commun et s'enrichirait d'une sélection des pratiques spécifiques utiles à un contexte projet particulier. "

Bibliographie Agile Modeling, Ron Jeffries et Scott W. Ambler , John Wiley & Sons, 2002, (ISBN 0471202827)■

L'eXtreme Programming, de Jean-Louis Bénard,Laurent Bossavit, Régis Médina, Dominic Williams Eyrolles 2002 (ISBN 221211561X)

Maîtriser les projets avec XP : Pilotage par les tests-client, Thierry Cros, Editions Cépadues,2004, (ISBN 2854286391)

AGILE, l’Entreprise et ses projets, Jean-Pierre Vickoff, QI, 2007, (ISBN 2912843006)■

Systèmes d'information et processus Agiles, Jean-Pierre Vickoff, Hermes Science Publication, 2003 (ISBN 2746207028)

Voir aussi

Liens internes

Management Agile■Agile Alliance■Principes de gestion agiles■Cycle de développement■

Références

↑ "The Agile Manifesto was put forward in 2001, and several method instantiations, such as XP, SCRUM, and Crystal exist.", Kieran Conboy & Brian Fitzgerald, Extreme Programming And Agile Methods - XP/Agile Universe 2004: 4th Conference On Extreme Programming And Agile Methods, Calgary, Canada, August 15-18, 2004, Proceedings, chap. Toward a Conceptual Framework of Agile Methods, Springer Verlag, New York, août 2004, (ISBN 354022839X), lien (http://books.google.fr/books?hl=en&lr=&id=tmvI_a4YUNMC&oi=fnd&pg=PA105&ots=xejboEQhET&sig=ULAr0yaORppprWTgs8Sne0x

1.

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

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

Page 8: Methode Agile

Liens externes

Communautés agiles

(en) Le manifeste des méthodes agiles (http://agilemanifesto.org/) ■(en) Agile Alliance (http://www.agilealliance.com/) ■(en) Declaration of Interdependence (http://pmdoi.org/) ■

(fr) La communauté eXtreme Programing Francaise (http://xp-france.net/cgi-bin/wiki.pl) ■(fr) La Communauté Agile Suisse (http://www.agile-swiss.org/wiki/index.php/Accueil) ■(fr) La Communauté Agile de Québec (http://www.agilequebec.ca/) ■(fr) La Communauté Agile de Montréal (http://www.agilemontreal.ca/) ■(en) Site de la méthode xp (http://www.extremeprogramming.org/) ■(fr) Le Club Agile Rhône-Alpes (http://clubagile.org/) ■

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

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

(fr) Association pour la maîtrise des systèmes d'informations (http://www.adeli.org/) ■(fr) Site historique de la méthode RAD (http://www.rad.fr/) ■

Autres liens

Principes de gestion agiles

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

Dernière modification de cette page le 28 mai 2010 à 14:34.Droit d'auteur : les textes sont disponibles sous licence Creative Commons paternité partage à l’identique ; d’autres conditions peuvent s’appliquer. Voyez les conditions d’utilisation pour plus de détails, ainsi que les crédits graphiques. En cas de réutilisation des textes de cette page, voyez comment citer les auteurs et mentionner la licence. Wikipedia® est une marque déposée de la Wikimedia Foundation, Inc., organisation de bienfaisance régie par le paragraphe 501(c)(3) du code fiscal des États-Unis.

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

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

Page 9: Methode Agile

Manifeste agileLe Manifeste Agile est un texte rédigé par 17 experts reconnus pour leurs apports respectifs au développement d'applications informatiques sous la forme de plusieurs méthodes dont les plus connues sont Extreme Programming et Scrum. Ces experts estimaient que le traditionnel cycle de développement en cascade ne correspondait plus aux nouveaux besoins applicatifs. Le Manifeste Agile est considéré comme l'acte généralisateur des méthodes agiles sous la dénomination initiale de Agile Manifesto [1] (http://agilemanifesto.org/) . Les valeurs et principes du Manifeste Agile sont défendus par l'Agile Alliance.

Sommaire1 Introduction2 Les 4 valeurs3 Les 12 principes4 Résumé de la mise en pratique5 Organisation6 Notes et références7 Voir aussi

7.1 Articles connexes7.2 Bibliographie7.3 Liens externes

Introduction

En 2001, aux États-Unis, dix-sept figures éminentes du développement logiciel se sont réunies pour débattre du thème unificateur de leurs méthodes respectives, dites méthodes agiles. Les plus connus d'entre eux étaient Ward Cunningham l'inventeur du Wiki via WikiWikiWeb, Kent Beck, père de l'extreme programming et cofondateur de JUnit, Ken Schwaber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith, prônant l'ASD, Alistair Cockburn pour la méthode Crystal clear, Martin Fowler, et Dave Thomas ainsi que Arie van Bennekum pour DSDM (Dynamic System Development Method) la version anglaise du RAD (Développement rapide d'applications). Ces 17 experts venant tous d'horizons différents réussirent à extraire de leur concepts respectifs des critères pour définir une nouvelle façon de développer des logiciels :

De cette réunion devait émerger le Manifeste Agile, considéré comme la définition canonique du développement Agile et de ses principes sous-jacents .

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

" Nous avons trouvé une voie améliorant le développement logiciel en réalisant ce travail et en aidant les autres à le faire. De ce fait nous avons déduit des valeurs communes. "

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

1

Page 1 of 3Manifeste agile - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Manifeste_Agile

Page 10: Methode Agile

Les 4 valeurs

Les quatre valeurs fondamentales Agiles sont :

Davantage l’interaction avec les personnes que les processus et les outils.■Davantage un produit opérationnel qu’une documentation pléthorique.■Davantage la collaboration avec le client que la négociation de contrat.■Davantage la réactivité face au changement que le suivi d'un plan.■

Les 12 principes

Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.■

Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.

Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.

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

Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.

La méthode la plus efficace pour transmettre l'information est une conversation en face à face.■

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

Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.

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

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

Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent.

À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.

Résumé de la mise en pratique

Le développement Agile, appelé aussi développement adaptatif, se caractérise donc par un style de conduite de projet itératif incrémental, centré sur l’autonomie des ressources humaines impliquées dans la spécification, la production et la validation d’une application intégrée et testée en continu (Méthode Agile).

C’est à partir de ces réalités pratiques, et non pas sur la base d’une théorie globale ou structurante, que l’Agilité progresse vers les sphères les plus hautes de l’organisation.

2

Page 2 of 3Manifeste agile - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Manifeste_Agile

Page 11: Methode Agile

Organisation

L'Agile Alliance est une organisation sans but lucratif chargée de promouvoir à l'échelle mondiale les valeurs et principes du Manifeste Agile.

Notes et références ↑ "The Agile Manifesto was put forward in 2001, and several method instantiations, such as XP, SCRUM, and Crystal exist.", Kieran Conboy & Brian Fitzgerald, Extreme Programming And Agile Methods - XP/Agile Universe 2004: 4th Conference On Extreme Programming And Agile Methods, Calgary, Canada, August 15-18, 2004, Proceedings, chap. Toward a Conceptual Framework of Agile Methods, Springer Verlag, New York, août 2004, (ISBN 354022839X), lien (http://books.google.fr/books?hl=en&lr=&id=tmvI_a4YUNMC&oi=fnd&pg=PA105&ots=xejboEQhET&sig=ULAr0yaORppprWTgs8Sne0x9

1.

↑ (en) Manifesto for Agile Software Development (http://agilemanifesto.org/) 2.

Voir aussi

Articles connexes

Méthode agile■

Bibliographie

(en) Agile Software Development Ecosystems: Problems, Practices, and Principles, Jim Highsmith, Addison-Wesley, 2002 (ISBN 0201760436). Lien (http://books.google.fr/books?id=10Ow8GomG80C&printsec=frontcover&hl=en)

Liens externes

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

Les signataires actuels du manifeste (http://agilemanifesto.org/sign/display.cgi) ■

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

Dernière modification de cette page le 28 mai 2010 à 14:43.Droit d'auteur : les textes sont disponibles sous licence Creative Commons paternité partage à l’identique ; d’autres conditions peuvent s’appliquer. Voyez les conditions d’utilisation pour plus de détails, ainsi que les crédits graphiques. En cas de réutilisation des textes de cette page, voyez comment citer les auteurs et mentionner la licence. Wikipedia® est une marque déposée de la Wikimedia Foundation, Inc., organisation de bienfaisance régie par le paragraphe 501(c)(3) du code fiscal des États-Unis.

Page 3 of 3Manifeste agile - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Manifeste_Agile

Page 12: Methode Agile

ScrumScrum est une méthode agile pour la gestion de projets. Elle a été conçue pour améliorer grandement la productivité dans les équipes auparavant paralysées par des méthodologies plus lourdes.

La méthode Scrum a été conçue pour la gestion de projets de développement de logiciels. Elle peut aussi être utilisée par des équipes de maintenance. Dans le cas de très grands projets, les équipes se multiplient et on parle alors de Scrum de Scrums. La méthode Scrum peut théoriquement s'appliquer à n'importe quel contexte ou à un groupe de personnes qui travaillent ensemble pour atteindre un but commun (comme gérer une petite école, des églises, des projets de recherche scientifique ou planifier un mariage).

Page 1 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 13: Methode Agile

Par contre, la méthode Scrum ne couvre aucune technique d'ingénierie du logiciel. Aussi, son utilisation dans le contexte du développement d'une application informatique nécessite de lui adjoindre une méthode complémentaire (comme l' Extreme Programming, par exemple).

Page 2 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 14: Methode Agile

Sommaire1 Historique2 Caractéristiques3 Quelques rappels sur les méthodes agiles

3.1 Origine3.2 Grands principes

3.2.1 Individus et interactions contre processus et outils3.2.2 Logiciel qui fonctionne contre documentation exhaustive3.2.3 Collaboration du client contre négociation de contrat3.2.4 Réponse au changement contre suivi d'un plan prédéfini

3.3 Idées clé4 Rôles

4.1 Directeur de produit4.2 Équipe4.3 Facilitateur / Animateur4.4 Intervenants

5 Planification 5.1 Sprints5.2 Releases5.3 Quotidien

6 Gestion des besoins 6.1 Backlog de produit6.2 Backlog de sprint

7 Estimations 7.1 Items de backlog de produit7.2 Calcul de vélocité7.3 Items de backlog de sprint

8 Déroulement d'un sprint 8.1 Réunion de planification8.2 Au quotidien8.3 Revue de sprint8.4 Rétrospective du sprint

9 Compléments 9.1 Lancement du projet9.2 Vue globale9.3 Burndown Charts

9.3.1 Sprint Burndown Chart9.3.2 Release Burndown Chart9.3.3 Interprétation

9.4 Qualité de l'environnement de travail9.5 Documentation de projet9.6 Outils pour Scrum

9.6.1 Papier et crayon / tableur9.6.2 Outils libres9.6.3 Outils propriétaires9.6.4 Autres outils

10 Conclusion 10.1 Scrum10.2 Mise en garde

11 Glossaire12 Voir aussi

12 1 Articles connexes

Page 3 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 15: Methode Agile

Historique

En 1986, Hirotaka Takeuchi et Ikujiro Nonaka décrivent une nouvelle approche holistique qui augmenterait la vitesse et la flexibilité dans le développement commercial de nouveaux produits . Dans celle-ci les phases se chevauchent fortement et l'ensemble du processus est réalisé par une équipe aux compétences croisées à travers différentes phases. Ils ont comparé cette nouvelle approcheau rugby, où l'équipe essaye d'avancer unie, en faisant circuler la balle (« tries to go to the distance as

passing the ball back and forth a unit, »).

En 1991, DeGrace et Stahl, dans "Wicked problems, righteous solutions" , font référence à cette approche comme Scrum (mêlée, en anglais), un terme de rugby mentionné dans l'article de Takeuchi et Nonaka. Dans le début des années 1990, Ken Schwaber a utilisé une approche qui a conduit à Scrum au sein de son entreprise, Advanced Development Methods. En même temps, Jeff Sutherland, John Scumniotales et Jeff McKenna développent une approche similaire à Easel Corporation et sont les premiers à appeler cela Scrum . En 1995, Sutherland et Schwaber ont présenté conjointement un document décrivant Scrum à l'OOPSLA de 1995 à Austin. Schwaber et Sutherland ont collaboré au cours des années suivantes pour fusionner les publications, leurs expériences et les meilleures pratiques du secteur en ce qui est maintenant connu comme Scrum. En 2001, Schwaber fait équipe avec Mike Beedle pour décrire la méthode dans le livre "Agile Software Development With Scrum". En France, le premier livre français entièrement consacré à Scrum est publié en février 2010 : "SCRUM : Le guide pratique de la méthode agile la plus populaire" .

Caractéristiques

Le terme Scrum est emprunté au rugby et signifie mêlée. Ce processus s'articule en effet autour d'une équipe soudée, qui cherche à atteindre un but, comme c'est le cas en rugby pour avancer avec le ballon pendant une mêlée.

Le principe de base de Scrum est de focaliser l'équipe de façon itérative sur un ensemble de fonctionnalités à réaliser, dans des itérations de durée fixe de une à quatre semaines, appelées sprints. Chaque sprint possède un but à atteindre, défini par le directeur de produit, à partir duquel sont choisies les fonctionnalités à implémenter dans ce sprint. Un sprint aboutit toujours sur la livraison d'un produit partiel fonctionnel. Pendant ce temps, le ScrumMaster a la charge de réduire au maximum les perturbations extérieures et de résoudre les problèmes non techniques de l'équipe.

Un principe fort en Scrum est la participation active du client pour définir les priorités dans les fonctionnalités du logiciel et pour choisir celles qui seront réalisées dans chaque sprint. Il peut à tout moment compléter ou modifier la liste des fonctionnalités à réaliser, mais jamais celles qui sont en cours de réalisation pendant un sprint.

Quelques rappels sur les méthodes agiles

Origine

En 2001, 17 représentants des méthodes légères alternatives aux processus lourds traditionnels se sont réunis pour trouver les points communs à leurs méthodes "to find common ground". De cette réunion

1

2

3

4

Page 4 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 16: Methode Agile

de quelques jours est né le Manifeste Agile : un texte bref énonçant des grands concepts, simples, mais qui proposent une nouvelle façon de penser un projet de développement informatique. Si certains dénoncent une certaine évidence de ces concepts, il n'en est pas moins que ce manifeste a pour lui le mérite de les formaliser et surtout de les structurer en un tout homogène et cohérent, par opposition aux pratiques semblables mais complètement hétérogènes d'une entreprise à l'autre et d'un projet à l'autre.

Grands principes

Le manifeste agile résume sa philosophie en quatre oppositions entre les concepts traditionnels et les concepts proposés.

Individus et interactions contre processus et outils

Ce sont les individus qui font la valeur du travail accompli, ce sont donc eux que l’on doit privilégier. Sans l’artisan, les meilleurs outils ne servent à rien. Les processus qui définissent ce que doit faire chaque personne brident le potentiel caché derrière chacun : faire interagir les gens au maximum est bien plus fructueux et permet d'améliorer grandement l'efficacité et la qualité du travail fourni, en rassemblant des visions différentes d'un même problème.

Logiciel qui fonctionne contre documentation exhaustive

Les processus lourds génèrent une documentation qui se veut exhaustive avec tous ses inconvénients : ambigüité du langage, coût de la rédaction, coût du maintien en accord avec la réalité, etc. Ces documents ne sont qu'une illusion d'avancement du projet. Même une conception technique initiale peut être complètement remise en cause en phase de codage (ou après) : comment peut-on alors déterminer l'avancement du projet ? Une régression ?

Dans les méthodes Agiles, un seul critère permet de mesurer l'avancement d'un projet : le logiciel qui fonctionne. La documentation n'est qu'un support concret qui aide à produire le logiciel.

Collaboration du client contre négociation de contrat

Dans tout projet, le but premier est de gagner de l’argent, autant pour le client (rentabilisation) que pour le fournisseur (prestation). Si la négociation protège plus ou moins des risques financiers, elle peut provoquer l’échec des projets (délais non respectés, budgets insuffisants) et engendrer d'interminables procès où tout le monde y perd au bout du compte (le client n'a pas son logiciel et le fournisseur ferme boutique).

Il faut sortir de la guerre client/fournisseur et penser en équipe qui veut atteindre un but commun : réussir le projet.

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

Un plan prédéfini a tendance à nous rendre autistes aux événements qui surviennent pendant le projet. Il est en plus à l'origine des conflits client/fournisseur classiques sur les délais de livraison. Pour le client, pouvoir adapter les besoins en cours de projet est un atout concurrentiel : il est réactif aux

5

Page 5 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 17: Methode Agile

Rôles dans Scrum

fluctuations des marchés et s'assure en plus que le logiciel développé répond parfaitement à ses véritables besoins.

Les méthodes Agiles sont conçues pour s’adapter au changement, en assurant un plan macroscopique précis et adaptatif.

Idées clé

Le client au cœur du projet■Esprit d’équipe■La communication est la clé■Simplicité, efficacité et qualité■Flexibilité aux changements■Avancement basé sur le concret■

Rôles

Scrum définit trois rôles principaux : le directeur de produit, le facilitateur / animateur et l'équipe. Des intervenants peuvent s'intégrer également au projet de façon plus ponctuelle.

Directeur de produit

Le directeur de produit (Product Owner) est le représentant des clients et utilisateurs. C'est lui qui définit l'ordre dans lequel les fonctionnalités seront développées et qui prend les décisions importantes concernant l'orientation du projet. Le terme directeur n'est d'ailleurs pas à prendre

au sens hiérarchique du terme, mais dans le sens de l'orientation.

Dans l'idéal, le directeur de produit travaille dans la même pièce que l'équipe. Il est important qu'il reste très disponible pour répondre aux questions de l'équipe et pour lui donner son avis sur divers aspects du logiciel (interface par exemple).

Équipe

L'équipe ne comporte pas de rôles prédéfinis, elle est auto-gérée. Il n'y a pas non plus de notion de hiérarchie interne : toutes les décisions sont prises ensemble et personne ne donne d'ordre à l'équipe sur sa façon de procéder. Contrairement à ce que l'on pourrait croire, les équipes auto-gérées sont celles qui sont les plus efficaces et qui produisent le meilleur niveau de qualité de façon spontanée.

L'équipe s'adresse directement au directeur de produit. Il est conseillé qu'elle lui montre le plus souvent possible le logiciel développé pour qu'il puisse ajuster les détails d'ergonomie et d'interface par exemple.

Page 6 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 18: Methode Agile

Exemple de planification en Scrum

Facilitateur / Animateur

Le facilitateur / animateur (ScrumMaster) joue un rôle capital : c'est lui qui est chargé de protéger l'équipe de tous les éléments perturbateurs extérieurs à l'équipe et de résoudre ses problèmes non techniques (administratifs par exemple). Il doit aussi veiller à ce que les valeurs de Scrum soient appliquées, mais il n'est pas un chef de projet ni un intermédiaire de communication avec les clients.

On parle parfois d'équipe étendue, qui intègre en plus le ScrumMaster et le directeur de produit. Ce concept renforce l'idée que client et fournisseur travaillent d'un commun effort vers le succès du projet.

Intervenants

Les intervenants (Stakeholders) sont les personnes qui souhaitent avoir une vue sur le projet sans réellement s'investir dedans. Il peut s'agir par exemple d'experts techniques ou d'agents de direction qui souhaitent avoir une vue très éloignée de l'avancement du projet.

Planification

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

Sprints

Scrum est un processus itératif : les itérations sont appelées des sprints et durent en théorie 30 jours calendaires. En pratique, les itérations durent généralement entre 2 et 4 semaines. Chaque sprint possède un but et on lui associe une liste d'items de backlog de produit (fonctionnalités) à réaliser. Ces items sont décomposés par l'équipe en tâches élémentaires de quelques heures, les items de backlog de sprint.

Pendant un sprint, les items de backlog de sprint à réaliser ne peuvent pas être changés. Les changements éventuels sont pris en compte dans le backlog de produit et seront éventuellement réalisés dans les sprints suivants.

Il y a une exception à cela : il se peut que l'équipe se rende compte en cours du sprint qu'elle n'aura pas le temps de terminer un item du backlog de sprint ou au contraire qu'elle aura fini en avance. Dans ce cas, et seulement d'un commun accord entre l'équipe et le directeur du produit, on peut enlever ou ajouter un item à ce qui a été prévu.

Releases

Pour améliorer la lisibilité du projet, on regroupe généralement des itérations en releases. Bien que ce concept ne fasse pas explicitement partie de Scrum, il est utilisé pour mieux identifier les versions. En effet, comme chaque sprint doit aboutir à la livraison d'un produit partiel, une release permet de marquer la livraison d'une version aboutie, susceptible d'être mise en exploitation.

Page 7 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 19: Methode Agile

Il est intéressant de planifier à l'échelle d'une release, en répartissant les items du backlog de produit sur les sprints, en respectant leur priorité. Bien entendu, ce qui est planifié au-delà du sprint courant peut changer à tout moment, rien n'est figé à l'avance.

Quotidien

Au quotidien, une réunion, le ScrumMeeting, permet à l'équipe et au ScrumMaster de faire un point d'avancement sur les tâches et sur les difficultés rencontrées.

Gestion des besoins

Backlog de produit

Scrum utilise une approche fonctionnelle pour récolter les besoins des utilisateurs. L'objectif est d'établir une liste de fonctionnalités à réaliser, que l'on appelle backlog de produit (NDT : Le terme backlog peut être traduit par cahier, liste ou carnet de commandes, qui ne collent pas bien avec l'esprit du terme anglais qui évoque aussi une réserve, un retard accumulé ; aussi ce terme a été gardé tel quel).

À chaque item de backlog sont associés deux attributs : une estimation en points arbitraires (voir Estimation) et une valeur client, qui est définie par le directeur de produit (retour sur investissement par exemple). Ce dernier définit dans quel ordre devront être réalisés ces items. Il peut changer cet ordre en cours de projet et même ajouter, modifier ou supprimer des items dans le backlog.

La somme des points des items du backlog de produit constitue le reste à faire total du projet. Cela permet de produire un release burndown chart, qui montre les points restant à réaliser au fur et à mesure des sprints.

Remarque : il arrive souvent qu'on utilise dans Scrum les User Stories de la méthode Extreme Programming, qui proposent des pratiques et des techniques intéressantes (le Planning poker pour les estimer par exemple).

Backlog de sprint

Lorsqu'on démarre un sprint, on choisit quels items du backlog de produit seront réalisés dans ce sprint. L'équipe décompose ensuite chaque item en liste de tâches élémentaires (techniques ou non), chaque tâche étant estimée en heures et ne devant pas durer plus de 2 jours. On constitue ainsi le backlog de sprint.

Pendant le déroulement du sprint, chaque équipier s'affecte des tâches du backlog de sprint et les réalise. Il met à jour régulièrement dans le backlog du sprint le reste à faire de chaque tâche. Les tâches ne sont pas réparties initialement entre tous les équipiers, elles sont prises au fur et à mesure que les précédentes sont terminées.

La somme des heures des items du backlog de sprint constitue le reste à faire total du sprint. Cela permet de produire un sprint burndown chart qui montre les heures restantes à réaliser au fur et à mesure du sprint.

Page 8 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 20: Methode Agile

Estimations

Scrum ne définit pas spécialement d'unités pour les items des backlogs. Néanmoins, certaines techniques se sont imposées de fait.

Items de backlog de produit

Les items de backlog de produit sont souvent des User Stories empruntées à Extreme Programming. Ces User Stories sont estimées en points relatifs, sans unité. L'équipe prend un item représentatif et lui affecte un nombre de points arbitraire. Cela devient un référentiel pour estimer les autres items. Par exemple, un item qui vaut 2 points représente deux fois plus de travail qu'un item qui en vaut 1. Pour les valeurs, on utilise souvent les premières valeurs de la suite de Fibonacci (1,2,3,5,8,13), qui évitent les difficultés entre valeurs proches (8 et 9 par exemple).

L'intérêt de cette démarche est d'avoir une idée du travail requis pour réaliser chaque fonctionnalité sans pour autant lui donner une valeur en jours que le directeur de produit serait tenté de considérer comme définitivement acquise. En revanche, on utilise la vélocité pour planifier le projet à l'échelle macroscopique de façon fiable et précise.

Calcul de vélocité

Une fois que tous les items de backlog de produit ont été estimés, on attribue un certain nombre d'items à réaliser aux sprints successifs. Ainsi, une fois un sprint terminé, on sait combien de points ont été réalisés et on définit alors la vélocité de l'équipe, c'est-à-dire le nombre de points qu'elle peut réaliser en un sprint.

En partant de cette vélocité et du total de points à réaliser, on peut déterminer le nombre de sprints qui seront nécessaires pour terminer le projet (ou la release en cours). L'intérêt, c'est qu'on a une vision de plus en plus fiable (retours d'expérience de sprint en sprint) de la date d'aboutissement du projet, tout en permettant d'aménager les items de backlog du produit en cours de route.

Items de backlog de sprint

Les items de backlog de sprint sont généralement exprimés en heures et ne doivent pas dépasser 2 journées de travail, auquel cas il convient de les décomposer en plusieurs items. Par abus de langage, on emploie le terme de tâches, les concepts étant très proches.

Déroulement d'un sprint

Réunion de planification

Tout le monde est présent à cette réunion, qui ne doit pas durer plus de 4 heures. La réunion de planification (Sprint Planning) consiste à définir d'abord un but pour le sprint, puis à choisir les items de backlog de produit qui seront réalisés dans ce sprint. Cette première partie du sprint planning représente l'engagement de l'équipe. Compte tenu des conditions de succès énoncées par le directeur

Page 9 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 21: Methode Agile

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

Dans un second temps, l'équipe décompose chaque item du backlog de produit en liste de tâches (items du backlog du sprint), puis estime chaque tâche en heures. Il est important que le directeur de produit soit présent dans cette étape, il est possible qu'il y ait des tâches le concernant (comme la rédaction des règles métier que le logiciel devra respecter et la définition des tests fonctionnels).

Au quotidien

Chaque journée de travail commence par une réunion de 15 minutes maximum appelée mêlée quotidienne (Daily Scrum). Seuls l'équipe, le directeur de produit et le ScrumMaster peuvent parler, tous les autres peuvent écouter mais pas intervenir (leur présence n'est pas obligatoire). A tour de rôle, chaque membre répond à 3 questions :

Qu'est-ce que j'ai fait hier ?■Qu'est-ce que je compte faire aujourd'hui ?■Quelles sont les difficultés que je rencontre ?■

Le tour de parole doit être scrupuleusement respecté pour éviter que le Scrum dérive sur des discussions techniques et déborde des 15 minutes. Si le besoin s'en fait sentir, des discussions sont alors menées librement après le Scrum.

Cette réunion a un but de synchronisation pour l'équipe et ne doit pas être vécue comme un reporting d'activité. C'est le niveau quotidien du principe inspect and adapt de Scrum.

L'équipe se met ensuite au travail. Elle travaille dans une même pièce, dont le ScrumMaster a la responsabilité de maintenir la qualité de son environnement. Les activités se déroulent éventuellement en parallèle : analyse, conception, codage, intégration, tests, etc. Scrum ne définit volontairement pas de démarche technique pour le développement du logiciel : l'équipe s'auto-gère et décide en toute autonomie de la façon dont elle va travailler.

Remarque : Il est assez fréquent que les équipes utilisent la démarche de développement guidé par les tests. Cela consiste à coder en premier lieu les modules de test vérifiant les contraintes métier, puis à coder ensuite le logiciel à proprement parler, en exécutant les tests régulièrement. Cela permet de s'assurer entre autres de la non-régression du logiciel au fil des sprints.

Revue de sprint

À la fin du sprint, tout le monde se réunit pour effectuer la revue de sprint, qui dure au maximum 4 heures. L'objectif de la revue de sprint est de valider le logiciel qui a été produit pendant le sprint. L'équipe commence par énoncer les items du backlog de produit qu'elle a réalisés. Elle effectue ensuite une démonstration du logiciel produit. C'est sur la base de cette démonstration que le directeur de produit valide chaque fonctionnalité planifiée pour ce sprint.

Une fois le bilan du sprint réalisé, l'équipe et le directeur de produit proposent des aménagements sur le backlog du produit et sur la planification provisoire de la release. Il est probable qu'à ce moment des items soient ajoutés, modifiés ou réestimés, en conséquence de ce qui a été découvert

Page 10 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 22: Methode Agile

Rétrospective du sprint

La rétrospective du sprint est faite en interne à l'équipe (incluant le ScrumMaster). L'objectif est de comprendre ce qui n'a pas bien marché dans le sprint, les erreurs commises et de prendre des décisions pour s'améliorer. Il est tout à fait possible d'apporter des aménagements à la méthode Scrum dans le but de s'améliorer. Il faut être très vigilant à ne pas retomber dans des pratiques rigides des méthodologies plus classiques.

Compléments

Lancement du projet

Scrum présuppose que le backlog de produit est déjà défini au début du projet. Une approche possible pour constituer ce backlog est de réaliser une phase de lancement. Cette phase de lancement s'articule autour de deux axes de réflexion : l'étude d'opportunité et l'expression initiale des besoins.

L'étude d'opportunité est très variable d'un projet à l'autre, tout dépend du contexte de l'entreprise, de la nature du projet (sous-traitance ou interne), etc. Chaque entreprise a sa propre politique sur cette activité.

L'expression initiale des besoins n'est pas un élément défini dans Scrum et n'est surtout pas une activité de contractualisation d'un cahier des charges. L'esprit d'une telle activité dans les méthodes Agiles est de définir d'une part le cadre du projet (pour que l'équipe s'imprègne du contexte métier) et d'autre part une première analyse globale des besoins. L'objectif est d'identifier un maximum de fonctionnalités que le logiciel devra implémenter, en se limitant à un niveau de précision assez grossier. On peut par exemple utiliser une approche par raffinages successifs, en partant des secteurs métiers concernés par l'application, puis en identifiant les activités métier, qu'on décompose en tâches métier qui correspondent à des fonctionnalités que l'on doit/peut ou non implémenter dans le logiciel final.

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

Page 11 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 23: Methode Agile

Vue globale

Vue synthétique du processus Scrum

Burndown Charts

Les burndown charts (graphiques d'avancement) permettent de visualiser graphiquement l'avancement du travail. Une interprétation simple permet d'avoir une idée sur les échéances futures.

Page 12 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 24: Methode Agile

Sprint Burndown Chart

Exemple de Sprint Burndown Chart

Ce graphique représente la quantité totale d'heures restantes à faire dans le sprint, au fil des jours. Il permet d'avoir une vue sur l'avancement du sprint.

Page 13 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 25: Methode Agile

Release Burndown Chart

Exemple de Release Burndown Chart

Ce graphique représente la quantité totale de points restant à faire dans la release, au fil des sprints. Il permet d'avoir une vue sur l'avancement de la release.

Interprétation

Ces graphiques sont très intéressants à analyser et interpréter. Outre le fait de montrer l'avancement concret du travail, ils permettent d'anticiper de façon relativement fiable les échéances futures en cours du sprint ou de la release.

On peut observer de légères augmentations du reste à faire sur le burndown chart du sprint. Cela correspond généralement à une réestimation à la hausse, suite à la prise en compte de contraintes techniques que l'on n'avait pas vues lors de l'estimation initiale. Si c'est le cas, il est indispensable de comprendre la cause de ces augmentations. Le même phénomène peut s'observer sur des légères diminutions, pour les mêmes raisons.

On peut utiliser en cours du sprint la tendance de la courbe pour avoir une idée approximative de la fin du sprint. Cela consiste à prendre un segment de droite dont la pente est représentative des valeurs déjà recensées et de le prolonger jusqu'à son point d'intersection avec l'axe des abscisses. Cela nous donne alors la date a priori de la fin du sprint et nous permet alors de prendre une décision sur la suppression (ou l'ajout) d'un item de backlog du produit à réaliser dans ce sprint. C'est ce qui s'est probablement passé le 15 mai 2002 sur le graphique de sprint ci-dessus : le reste à faire diminue dans ce cas assez brutalement.

C'est exactement la même chose pour les burndown charts de release. Si la date de publication de la release est clairement au-delà de ce que l'on espérait, on peut aviser en enlevant des items de backlog du produit ou changeant leur ordre, de sorte que les fonctionnalités les moins importantes soient celles qui risquent de ne pas être développées à temps.

Page 14 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 26: Methode Agile

Cette approche, bien que basée sur des tendances approximatives, permet d'identifier très tôt les risques de défaillance et d'agir en conséquence, en conservant à l'esprit le caractère critique des fonctionnalités à développer. Ces décisions importantes relèvent complètement du directeur de produit.

Une dernière chose importante : la fiabilité de la vélocité de l'équipe et des estimations qu'elle a faites augmente au fil des sprints. On élimine de cette façon les risques majeurs au plus tôt dans le projet.

Qualité de l'environnement de travail

Un concept fort de Scrum est la qualité de l'environnement de travail de l'équipe. Cela inclut :

Pas de changements imposés pendant un sprint■Toute l'équipe dans une même pièce■Un tableau blanc et/ou en liège■Un bon outil de suivi du projet■Prévenir des interventions extérieures (téléphone, irruption dans la pièce, etc.)■Tout ce qui peut rendre l'équipe plus sereine et efficace■

Documentation de projet

Scrum n'impose aucune documentation particulière pour les projets. Des documents sont implicitement produits (backlogs, burndown charts), mais ils ont une vocation avant tout utilitaire.

Produire de la documentation, c'est souvent utile, mais c'est aussi souvent inutile. En plus, il faut la maintenir à jour et c'est quelque chose qui est rarement fait sur le terrain. Pour savoir s'il faut rédiger un document, on peut se poser une question très simple : Est-ce que ce document va m'être vraiment utile et tout de suite ?.

Voici quelques exemples de documents utiles et dans quels cas :

Diagrammes métiers (processus, objets, etc.), associé au backlog de produit : uniquement si la logique métier du client qui concerne l'application est vraiment complexe. Dans ce cas, l'équipe devrait produire ce document avec lui.

Diagramme de séquence, associé à un item du backlog du produit : uniquement si la fonctionnalité aura une utilisation complexe, tant au niveau métier qu'applicatif.

Diagrammes d'architecture du logiciel (classes, modules, composants, etc.), pour le projet : indispensable pour avoir toujours sous les yeux une vue de l'architecture et s'assurer ainsi qu'elle est de qualité.

Les manuels utilisateur, à chaque sprint : les manuels sont produits à chaque sprint et pas en fin de projet. Utiliser des vidéos de démonstrations commentées est une solution efficace.

Les FAQ pour la hotline : des cas classiques où les utilisateurs ne vont pas comprendre un comportement métier. Cela permet de traiter un maximum de problèmes au niveau de la hotline, avant que cela n'arrive aux équipes de développement/maintenance.

Bref, un document ne doit être produit que si son utilité est réelle et immédiate.

Outils pour Scrum

Un bon artisan n'est rien sans un bon outil. Il n'y a pas aujourd'hui d'outil ultime pour Scrum. Voici un petit panel des possibilités.

Page 15 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 27: Methode Agile

Papier et crayon / tableur

Scrum peut être mis en pratique avec trois fois rien : deux listes suffisent. La liste des items du backlog de produit et la liste des items du backlog de sprint. La saisie et la mise à jour des données est simplement un peu moins agréable.

Outils libres

IceScrum (http://www.icescrum.org) (open-source et démo en ligne)■theSCRUM (http://www.the-scrum.org/) open-source et démo en ligne, implémente un tableau blanc virtuel

EPF (http://www.eclipse.org/epf) Eclipse Process Framework intègre un plug-in Scrum (open-source)

OpenERP (http://www.openerp.com) OpenERP intègre un module Scrum (open-source)■

Outils propriétaires

AccuRev (http://www.accurev.com) (Solutions de gestion de configuration logicielle intégrant les méthodes Agile et Scrum)

ScrumDesk (http://www.scrumdesk.com) (gratuit pour 5 utilisateurs maximum)■Intra'Know PROJET (http://www.intraknow.com) (cette solution collaborative intégre les grands principes de la méthode AGILE )

ScrumWorks (http://danube.com/scrumworks) (gratuit sous conditions)■VersionOne (http://www.versionone.com/Resources/AgileDevelopment.asp) (gratuit sous conditions)

RallyDev (http://www.rallydev.com/) ■GreenHopper (http://www.greenpeppersoftware.com/en/products/GreenHopper/) ■Microsoft eScrum Version 1.0 (http://www.microsoft.com/downloads/details.aspx?FamilyID=55a4bde6-10a7-4c41-9938-f388c1ed15e9&displaylang=en) pour Visual Studio Team Foundation Server

Scrumy (http://www.scrumy.com/) (Démonstration en ligne gratuite)■ScrumEdge (http://www.scrumedge.com/) (Démonstration en ligne gratuite)■Serena Agile On Demand (http://www.serena.com/products/agile-software/) Entièrement en mode SAAS. Aucune installation nécessaire. Essai gratuit 60j.

Urban Turtle (http://www.urbanturtle.net/) Plugin for TFS web Access (Essai gratuit 30 Jours).■Virtual SCRUM Board (http://www.virtualscrumboard.com/) (Essais gratuit de 60 Jours)■

Autres outils

Voir les ressources ScrumAlliance (http://www.scrumalliance.org/resources/) .■

Conclusion

Scrum

Scrum est un processus de développement de logiciels qui s'intéresse plutôt à l'organisation du projet qu'aux aspects techniques. Son cadre de travail est sa force, si bien que cette méthode pourrait être appliquée à d'autres domaines. Son approche itérative et basée sur les besoins priorisés du client lui

Page 16 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 28: Methode Agile

confèrent une flexibilité extrême. Elle incarne bien par là l'état d'esprit de la mêlée de rugby : avancer tous ensemble vers un but commun, la réussite du projet.

Scrum est un processus intéressant comme premier pas vers les méthodes Agiles : il est facile à comprendre et à pratiquer. La seule difficulté relève plutôt de l'environnement organisationnel (voir la mise en garde ci-dessous).

Mise en garde

On entend de plus en plus de sociétés clamer qu'elles sont Agiles, comme argument commercial à la mode, parce qu'elles utilisent quelques pratiques des méthodes Agiles. Mais être Agile, c'est bien plus que de mettre en pratique une méthode. L'Agilité requiert des dispositions particulières qui sont loin d'être faciles à mettre en place :

Une organisation adaptée : il est très difficile de faire admettre aux organes décideurs d'une entreprise de travailler de façon Agile. En effet, cela signifie de ne pas disposer dès le départ d'une date et d'un budget très précis, mais plutôt d'un ordre de grandeur.

Un état d'esprit : être Agile, c'est privilégier l'esprit d'équipe et pas seulement dans la réalisation technique. Le client doit comprendre que l'on attend de lui un investissement personnel bien supérieur à celui des méthodes plus classiques, en testant le logiciel souvent et en participant à toutes les réunions.

Un environnement favorable : éliminer les contraintes dans une entreprise n'est pas toujours évident. Comment limiter les appels téléphoniques trop fréquents, les irruptions dans la pièce de l'équipe, les opérations "urgentes" demandées aléatoirement par la direction, etc. ?

Bref, utiliser une méthode comme Scrum au niveau de l'équipe technique ne suffit pas. L'Agilité est une façon de travailler différente de ce dont on a l'habitude, c'est l'attitude du changement, de la flexibilité, de l'adaptation et de l'amélioration continue. Ce n'est pas aussi simple qu'une méthode…

Glossaire Directeur de produit (Product Owner)

personne responsable de produire et maintenir à jour le backlog de produit. C'est lui qui en détermine les priorités et qui prend les décisions concernant l'orientation du projet.

ScrumMaster membre de l'équipe dont l'objectif principal est de la protéger des perturbations extérieures. Il est complètement transparent pour la communication entre l'équipe et les clients et n'a aucun pouvoir hiérarchique sur l'équipe. C'est en revanche un facilitateur pour les problèmes non techniques de l'équipe.

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

Backlog de sprint (Sprint Backlog) liste des tâches à accomplir pendant un sprint. Elles correspondent à la réalisation des items de backlog du produit affectés au sprint.

Mêlée quotidienne (Daily Scrum) réunion quotidienne de 15 minutes qui a pour but de faire le point sur ce qui a été fait depuis la dernière mêlée, ce qui est prévu de faire jusqu'à la prochaine et quelles sont les embûches rencontrées durant le travail.

Page 17 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 29: Methode Agile

Sprint nom d'une itération dans Scrum. Cette itération dure 30 jours calendaires en théorie, mais en pratique on utilise plutôt entre 2 et 4 semaines. Pendant une itération, l'équipe doit développer une liste d'items du backlog de produit qui a été définie au début de ce sprint.

Graphique d'avancement (Burndown Chart) graphique qui montre la tendance du reste à faire total de jour en jour (pour les sprints) ou de sprint en sprint (pour les releases).

Voir aussi

Articles connexes

Cycle de développement■Méthode agile■Extreme programming■

Liens externes

(en) Site officiel Scrum (http://www.controlchaos.com/) ■(en) Agile Alliance (http://www.agilealliance.org/) : Communauté autour des méthodes Agiles■(en) Scrum Alliance (http://www.scrumalliance.org/) : Communauté autour de Scrum■(en) Liste de discussion par mail (http://groups.yahoo.com/group/scrumdevelopment/) ■(fr) Liste de discussion par mail francophone (http://fr.groups.yahoo.com/group/scrum-fr/) ■(fr) Introduction à Scrum (http://www.aubryconseil.com/dotclear/index.php/2007/05/28/235-mise-a-jour-majeure-de-la-presentation-introduction-a-scrum) en licence CreativeCommons, traduction par Claude Aubry à partir de la version de Mike Cohn (http://www.mountaingoatsoftware.com/news/view/5) . La traduction des termes Scrum anglais de cette présentation a été utilisée dans cet article.

(fr) Planification et gestion de projet informatique : SCRUM(http://techtalks.intellicore.net/2008/04/24/video-planification-gestion-projet-informatique-scrum/) : Conférence vidéo de Christian Trotobas enregistrée aux Intellicore Tech Talks (http://techtalks.intellicore.net) au sujet de la méthode SCRUM et de ses applications

(fr) Le French Scrum User Group (http://www.frenchsug.org/display/FRSUG/French+Scrum+User+Group/) : le groupe d'utilisateurs de Scrum en France.

(en) Vidéo "Scrum in the real World" (http://www.vimeo.com/4587652/) : Une Vidéo sur l'application de la méthode Scrum sur un projet Web.

(en) Processus "Scrum Process Asset Library" (http://scrum.gem-up.com) : Un moyen facile de naviguer la methodologie Scrum

Notes et références ↑ The New New Product Development Game (http://apln-richmond.pbworks.com/f/New+New+Prod+Devel+Game.pdf) Havard Business Review, jan-fév 1986

1.

↑ (en) DeGrace, Stahl et Hulet, Wicked problems, righteous solutions, Prentice Hall, 1 octobre 1990 (ISBN 978-0-135-90126-7)

2.

↑ Jeff Sutherland, « Agile Development: Lessons learned from the first Scrum (http://www.scrumalliance.org/resources/35) »

3.

↑ SCRUM : Le guide pratique de la méthode agile la plus populaire (http://www.aubryconseil.com/pages/Livre-Scrum)

4.

er

Page 18 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 30: Methode Agile

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

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

Dernière modification de cette page le 28 mai 2010 à 13:32. Droit d'auteur : les textes sont disponibles sous licence Creative Commons paternité partage à l’identique ; d’autres conditions peuvent s’appliquer. Voyez les conditions d’utilisation pour plus de détails, ainsi que les crédits graphiques. En cas de réutilisation des textes de cette page, voyez comment citer les auteurs et mentionner la licence. Wikipedia® est une marque déposée de la Wikimedia Foundation, Inc., organisation de bienfaisance régie par le paragraphe 501(c)(3) du code fiscal des États-Unis.

Page 19 of 19Scrum - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Scrum

Page 31: Methode Agile

Extreme programmingL'Extreme Programming (XP) est une méthode agile de gestion de projet informatique adaptée aux équipes réduites avec des besoins changeants. Elle pousse à l'extrême des principes simples.

Sommaire1 Origine2 Pratiques extrêmes3 Cycle de développement4 La programmation comme discipline collective

4.1 Valeurs 4.1.1 La communication4.1.2 La simplicité4.1.3 Le feedback4.1.4 Le courage4.1.5 Le respect

4.2 Pratiques 4.2.1 Client sur site4.2.2 Jeu du Planning ou Planning poker4.2.3 Intégration continue4.2.4 Petites livraisons4.2.5 Rythme soutenable4.2.6 Tests de recette (ou tests fonctionnels)4.2.7 Tests unitaires4.2.8 Conception simple4.2.9 Utilisation de métaphores4.2.10 Refactoring (ou remaniement du code)4.2.11 Appropriation collective du code4.2.12 Convention de nommage4.2.13 Programmation en binôme

4.3 Autres principes5 Environnements défavorables6 Voir aussi

6.1 Articles connexes6.2 Bibliographie6.3 Liens externes

7 Notes et références

Origine

L'Extreme Programming a été inventée par Kent Beck, Ward Cunningham et Ron Jeffries pendant leur travail sur un projet « C3 » de calcul des rémunérations chez Chrysler. Kent Beck, chef de projet en mars 1996 commença à affiner la méthodologie de développement utilisée sur le projet. La

Page 1 of 7Extreme programming - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Extreme_programming

Page 32: Methode Agile

Le cycle de l'Extreme Programming

méthode est née officiellement en octobre 1999 avec le livre Extreme Programming Explained de Kent Beck.

Pratiques extrêmes

Dans le livre Extreme Programming Explained, la méthode est définie comme :

une tentative de réconcilier l´humain avec la productivité ;■un mécanisme pour faciliter le changement social ;■une voie d'amélioration ;■un style de développement ;■une discipline de développement d´applications informatiques.■

Son but principal est de réduire les coûts du changement. Dans les méthodes traditionnelles, les besoins sont définis et souvent fixés au départ du projet informatique ce qui accroît les coûts ultérieurs de modifications. XP s´attache à rendre le projet plus flexible et ouvert au changement en introduisant des valeurs de base, des principes et des pratiques.

Les principes de cette méthode ne sont pas nouveaux : ils existent dans l'industrie du logiciel depuis des dizaines d'années et dans les méthodes de management depuis encore plus longtemps. L'originalité de la méthode est de les pousser à l'extrême :

puisque la revue de code est une bonne pratique, elle sera faite en permanence (par un binôme) ;■puisque les tests sont utiles, ils seront faits systématiquement avant chaque implantation ;■puisque la conception est importante, elle sera faite tout au long du projet (refactoring) ;■puisque la simplicité permet d'avancer plus vite, nous choisirons toujours la solution la plus simple ;

puisque la compréhension est importante, nous définirons et ferons évoluer ensemble des métaphores ;

puisque l'intégration des modifications est cruciale, nous l'effectuerons plusieurs fois par jour ;■puisque les besoins évoluent vite, nous ferons des cycles de développement très rapides pour nous adapter au changement.

Cycle de développement

L'Extreme Programming repose sur des cycles rapides de développement (des itérations de quelques semaines) dont les étapes sont les suivantes :

une phase d'exploration détermine les scénarios clients qui seront fournis pendant cette itération ;

l'équipe transforme les scénarios en tâches à réaliser et en tests fonctionnels ;■chaque développeur s'attribue des tâches et les réalise avec un binôme ;■lorsque tous les tests fonctionnels passent, le produit est livré.■

Le cycle se répète tant que le client peut fournir des scénarios à livrer. Généralement le cycle de la première livraison se caractérise par sa durée et le volume important de fonctionnalités embarquées. Après la première mise en production, les itérations peuvent devenir plus courtes (une semaine par exemple).

Page 2 of 7Extreme programming - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Extreme_programming

Page 33: Methode Agile

La programmation comme discipline collective

Tout en mettant l'accent sur les bonnes pratiques de programmation, XP préconise un déroulement par itérations courtes et gérées collectivement, avec une implication constante du client. Il en découle une redéfinition de la relation entre client et fournisseur avec de surprenants résultats en termes de qualité de code, de délais et de satisfaction de la demande du client.

Valeurs

L'eXtreme Programming repose sur cinq valeurs fondamentales :

La communication

C'est le moyen fondamental pour éviter les problèmes. Les pratiques que préconise l'XP imposent une communication intense. Les tests, la programmation en binôme et le jeu du planning obligent les développeurs, les décideurs et les clients à communiquer. Si un manque apparait malgré tout, un coach se charge de l'identifier et de remettre ces personnes en contact.

La simplicité

La façon la plus simple d'arriver au résultat est la meilleure. Anticiper les extensions futures est une perte de temps. Une application simple sera plus facile à faire évoluer.

Le feedback

Le retour d'information est primordial pour le programmeur et le client. Les tests unitaires indiquent si le code fonctionne. Les tests fonctionnels donnent l'avancement du projet. Les livraisons fréquentes permettent de tester les fonctionnalités rapidement.

Le courage

Certains changements demandent beaucoup de courage. Il faut parfois changer l'architecture d'un projet, jeter du code pour en produire un meilleur ou essayer une nouvelle technique. Le courage permet de sortir d'une situation inadaptée. C'est difficile, mais la simplicité, le feedback et la communication rendent ces tâches accessibles.

Le respect

Cette valeur fut ajoutée dans la deuxième édition de Extreme Programming Explained de K. Beck.

Pratiques

Ces cinq valeurs se déclinent en treize pratiques qui se renforcent mutuellement :

Page 3 of 7Extreme programming - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Extreme_programming

Page 34: Methode Agile

Client sur site

Un représentant du client doit, si possible, être présent pendant toute la durée du projet. Il doit avoir les connaissances de l'utilisateur final et avoir une vision globale du résultat à obtenir. Il réalise son travail habituel tout en étant disponible pour répondre aux questions de l'équipe.

Jeu du Planning ou Planning poker

Le client crée des scénarios pour les fonctionnalités qu'il souhaite obtenir. L'équipe évalue le temps nécessaire pour les implémenter. Le client sélectionne ensuite les scénarios en fonction des priorités et du temps disponible.

Intégration continue

Lorsqu'une tâche est terminée, les modifications sont immédiatement intégrées dans le produit complet. On évite ainsi la surcharge de travail liée à l'intégration de tous les éléments avant la livraison. Les tests facilitent grandement cette intégration : quand tous les tests passent, l'intégration est terminée.

Petites livraisons

Les livraisons doivent être les plus fréquentes possible. L'intégration continue et les tests réduisent considérablement le coût de livraison.

Rythme soutenable

L'équipe ne fait pas d'heures supplémentaires. Si le cas se présente, il faut revoir le planning. Un développeur fatigué travaille mal. En effet le programmeur ne doit pas dépasser 35 heures de travail par semaine (formations inclues) car le dépassement de ce taux peut engendrer des problèmes ce qui influe sur la qualité du développement.

Tests de recette (ou tests fonctionnels)

À partir des scénarios définis par le client, l'équipe crée des procédures de test qui permettent de vérifier l'avancement du développement. Lorsque tous les tests fonctionnels passent, l'itération est terminée. Ces tests sont souvent automatisés mais ce n'est pas toujours possible.

Tests unitaires

Avant d'implémenter une fonctionnalité, le développeur écrit un test qui vérifiera que son programme se comporte comme prévu. Ce test sera conservé jusqu'à la fin du projet, tant que la fonctionnalité est requise. À chaque modification du code, on lance tous les tests écrits par tous les développeurs, et on sait immédiatement si quelque chose ne fonctionne plus.

Page 4 of 7Extreme programming - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Extreme_programming

Page 35: Methode Agile

Conception simple

L'objectif d'une itération est d'implémenter les scénarios sélectionnés par le client et uniquement cela. Envisager les prochaines évolutions ferait perdre du temps sans avoir la garantie d'un gain ultérieur. Les tests permettront de changer l'architecture plus tard si nécessaire. Plus l'application est simple, plus il sera facile de la faire évoluer lors des prochaines itérations. De même, la documentation doit être minimale : on préfèrera un programme simple qui nécessite peu d'explications à un système complexe.

Utilisation de métaphores

On utilise des métaphores et des analogies pour décrire le système et son fonctionnement. Le fonctionnel et le technique se comprennent beaucoup mieux lorsqu'ils sont d'accord sur les termes qu'ils emploient.

Refactoring (ou remaniement du code)

Amélioration régulière de la qualité du code sans en modifier le comportement. On retravaille le code pour repartir sur de meilleures bases tout en gardant les mêmes fonctionnalités. Les phases de refactoring n'apportent rien au client mais permettent aux développeurs d'avancer dans de meilleures conditions et donc plus vite.

Appropriation collective du code

L'équipe est collectivement responsable de l'application. Chaque développeur peut faire des modifications dans toutes les portions du code, même celles qu'il n'a pas écrites. Les tests diront si quelque chose ne fonctionne plus.

Convention de nommage

Puisque tous les développeurs interviennent sur tout le code, il est indispensable d'établir et de respecter des normes de nommage pour les variables, méthodes, objets, classes, fichiers, etc.

Programmation en binôme

La programmation se fait par deux. Le premier appelé driver (ou pilote) tient le clavier. C'est lui qui va travailler sur la portion de code à écrire. Le second appelé partner (ou co-pilote) est là pour l'aider en suggérant de nouvelles possibilités ou en décelant d'éventuels problèmes. Les développeurs changent fréquemment de partenaire ce qui permet d'améliorer la connaissance collective de l'application et d'améliorer la communication au sein de l'équipe.

Autres principes

Ne pas ajouter de fonctionnalités plus tôt que prévu ;■N'optimiser qu'à la toute fin.■

Page 5 of 7Extreme programming - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Extreme_programming

Page 36: Methode Agile

Cette méthode s'appuie sur :

une forte réactivité au changement des besoins du client ;■un travail d'équipe ;■la qualité du code ;■la qualité des tests effectués au plus tôt.■

Environnements défavorables

En lieu et place d'inconvénient de la méthode, on parlera plus aisément d'environnements défavorables dans lesquels la méthode XP n'est pas applicable. Dans ce cas, seule une partie des pratiques peut être réalisée. Les principaux contextes défavorables sont :

un blocage culturel : quand le client ou les développeurs ont l'habitude de fonctionner autrement. L'ingénieur à qui l'on attribue des mini-tâches quotidiennes et qui doit les réaliser avec un binôme peut avoir le sentiment que sa fonction est déqualifiée. Son principal rôle n'est plus d'être force de proposition, mais bel et bien de produire et d'accroitre sa productivité (Taylorisme, Fordisme). Une telle vision peut en effet provoquer un blocage culturel qui peut conduire à un turn-over important.

une équipe de vingt développeurs ou plus car la communication devient difficile : Il est fréquent de voir au fil du temps des binômes travailler toujours ensemble, toujours sur les mêmes sujets, et former ainsi des sous-équipes spécialisées, ce que ne veut pas XP. Par ailleurs, les évolutions possibles dans l'entreprise sont très limitées dans la mesure où tous les membres de l'équipe jouent tous les mêmes rôles.

un coût de changement exponentiel car « XP nécessite du code propre et simple » ;■

un feedback long ou difficile à obtenir : le retour sur investissement est visible sur le moyen/long terme.

un aménagement qui empêche la communication ou la programmation en binôme (il est nécessaire d'avoir une infrastructure open-space).

Respect d'une discipline collective et travail en binôme au quotidien : cette méthode ne peut pas être appliquée avec n'importe qui, car elle dégage très peu de temps à l'autonomie et au travail individuel, dans la mesure où systématiquement le travail se fait à deux sur un même poste de travail. Les développeurs auront de la difficulté à établir un projet professionnel dans leur entreprise.

la résistance au changement.■

Voir aussi

Articles connexes

Méthode agile■Cycle de développement■Scrum■Test Driven Development■

1

Page 6 of 7Extreme programming - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Extreme_programming

Page 37: Methode Agile

Logo site Xp

Bibliographie

Kent Beck, eXtreme Programming - La référence, 2002 (ISBN 2-7440-1433-8)■Jean-Louis Bénard, Laurent Bossavit, Régis Médina et Dominic Williams, L'Extreme Programming - Avec deux études de cas, 2002 (ISBN 2212110510), nouvelle édition du même ouvrage sous le nom Gestion de projet eXtreme Programming (ISBN 2-212-11561-X)

Thierry Cros, Maîtrisez les projets avec l'Extreme Programming, 2004 (ISBN 2854286391)■(en) Matt Stephens et Doug Rosenberg, Extreme Programming Refactored: The Case Against XP, 2003 (ISBN 1590590961)

Liens externes

(en) ExtremeProgrammingRoadmap (http://www.c2.com/cgi/wiki?ExtremeProgrammingRoadmap) , un wiki très complet

(fr) L'association eXtreme Programming France (http://xp-france.net/) et son wiki (http://xp-france.net/cgi-bin/wiki.pl?XpFrance)

(fr) Présentation complète d'XP (http://www.regismedina.com/articles/fr/extreme-programming)

(fr) Un autre article sur l'XP (http://lagace.developpez.com/extreme-programming/)

(fr) Un exposé succinct de la méthode : historique, fondements et mise en oeuvre (http://extremeprogramming.free.fr/)

(en) Do You Understand XP? (http://klimek.box4.net/blog/2007/02/19/do-you-understand-xp/) de Manuel Klimek

(en) Extreme Deprogramming (http://www.hacknot.info/hacknot/action/showEntry?eid=11) qui compare XP à une secte ("cult") (et la réponse de Manuel Klimek (http://klimek.box4.net/blog/2007/02/26/xp-cult-or-movement/) )

(en) Extreme programming.org (http://www.extremeprogramming.org/) ■

Notes et références ↑ eXtreme Programming - La référence, Kent Beck, chapitre 25 - Quand faut-il éviter XP1.

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

Dernière modification de cette page le 22 mai 2010 à 20:25.Droit d'auteur : les textes sont disponibles sous licence Creative Commons paternité partage à l’identique ; d’autres conditions peuvent s’appliquer. Voyez les conditions d’utilisation pour plus de détails, ainsi que les crédits graphiques. En cas de réutilisation des textes de cette page, voyez comment citer les auteurs et mentionner la licence. Wikipedia® est une marque déposée de la Wikimedia Foundation, Inc., organisation de bienfaisance régie par le paragraphe 501(c)(3) du code fiscal des États-Unis.

Page 7 of 7Extreme programming - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Extreme_programming

Page 38: Methode Agile

LeanLe lean est une école de gestion d'entreprise - voir l'histoire de l'utilisation de ce mot pour nommer le Système de Production Toyota - s'intéresse à la performance (productivité, qualité). Les tenants du lean recherchent la performance par l'amélioration continue et l'élimination des gaspillages (muda en japonais), dont il existe sept catégories : productions excessives, attentes, transports et manutentions inutiles, tâches inutiles, stocks, mouvements inutiles et productions défectueuses. L'école de gestion lean trouve ses sources au Japon dans le Toyota Production System (TPS). Adaptable à tous les secteurs économiques, le lean est actuellement principalement implanté dans l'industrie (et surtout l'industrie automobile).

Lean est un qualificatif donné par une équipe de chercheurs du MIT au système de production Toyota sans que cette équipe ait eu une vision globale du système. A l'origine le TPS a été créé par Sakichi Toyoda, puis par son fils Kiichiro Toyoda, et enfin par son neveu Eiji Toyoda, assistés par un ingénieur surdoué Taiichi Ohno. Quand en 1972 après 25 ans d'efforts le système fut déployé depuis la fabrication des moteurs jusqu'à la fin de la ligne d'assemblage chez Toyota, une cellule de 12 consultants internes (dont Fujio Cho, Hajime Ohba, etc.) fut créée (l'OMCD) pour aider les fournisseurs de Toyota à livrer des produits de qualité en juste-à-temps. Chacun de ces consultants s'occupa d'un fournisseur principal. Ensuite Hajime Ohba fut chargé de créer le TSSC, cellule de support pour les fournisseurs de Toyota aux États-Unis. C'est dans cette cellule que John Shook et James (Jim) P. Womack furent formés, selon les méthodes de Hajime Ohba. Ceci explique le fait que certains « outils lean », tels que le MIFA, ne soient pas connus chez Toyota, le savoir initial de Ohno s'étant perdu lors des différentes étapes de transmission entre des personnes, et celles-ci ayant inventé de nouveaux outils. Aujourd'hui le TSSC est une entreprise indépendante de Toyota. De nombreux consultants américains n'ont eu comme formation que celle du TSSC, sans pratique sur le terrain, et ont créé des cabinets qui sous l'appellation lean sont loin des pratiques originelles du TPS.

Sommaire1 Concepts de base2 Lean et changement dans les organisations3 Notes et références4 Voir aussi

4.1 Liens externes4.2 Bibliographie

Concepts de base

La pensée lean repose sur deux concepts principaux : le juste-à-temps et le jidoka. Les outils du juste-à-temps sont le temps TAKT, le lissage, le flux continu en pièce à pièce, le flux tiré, le changement rapide d'outils (SMED) et l'intégration de la logistique ; les outils du jidoka (peu visibles chez Toyota, et donc par le fait moins connus en dehors de l'entreprise) sont la séparation de l'homme et de la machine, les outils d'arrêt de production au premier défaut (andon), les méthodes d'élimination des

1

Page 1 of 3Lean - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Lean

Page 39: Methode Agile

causes d'erreur (poka yoke), d'analyse de problème (« Cinq pourquoi »), la ré-ingénierie des équipements de production.

La démarche lean est plus riche qu'une simple méthode de production, et forme un système cohérent de concepts complexes, articulés à une pratique originale et à des moyens de formalisation et d'appropriation spécifiques ; c'est pourquoi on peut utiliser à son endroit le terme d'école. Les tenants du lean s'appliquent à l'enseigner, à l'appliquer et à répandre ses règles au sein de la communauté industrielle. Après une première vague d'engouement dans les années 1970 et 1980 pour les « méthodes japonaises », l'école du lean s'est formalisée aux États-Unis dans les années 1990 (le terme même lean a été inventé au MIT en 1987) et a été popularisée par le livre Lean Thinking (1996) de James P. Womack et Daniel T. Jones. De nombreux travaux ont suivi, parmi lesquels Team Toyota (1996) de Terry L. Bresser et The Toyota Way (2004) de Jeffrey K. Liker. Ces ouvrages ont permis de clarifier les concepts et les pratiques lean, de mieux comprendre les fondements cognitifs et sociaux sur lesquels le système repose et de multiplier les exemples et études de cas.

On peut distinguer quatre niveaux d’analyse du système de pensée lean : une redéfinition de la valeur produite par une entreprise, le développement d’un schéma productif caractéristique, le développement d'attitudes managériales originales et la formulation d’une stratégie à long terme.

la valeur : ■la valeur ajoutée d’une tâche contribuant à un processus doit être définie du point de vue du client ;■l'entreprise doit assurer un écoulement sans interruption de la valeur le long de sa chaîne de production (en termes plus triviaux, on fait la « chasse aux stocks »).

le schéma de production : ■l'entreprise produit en « tirant » sa production en fonction de la demande et non en « poussant » en fonction des capacités locales de production ;

les tâches productives sont standardisées de manière à faciliter l'amélioration continue par suppression des tâches non créatrices de valeur ;

l'entreprise entretient une relation partenariale riche avec ses fournisseurs et les incite à adopter sesméthodes de production ;

l'attitude managériale : ■les managers et les travailleurs doivent trouver et éliminer les causes profondes des problèmes dès que ces derniers surviennent ;

chaque employé est incité à réfléchir et à proposer des améliorations du système productif. Ceci débouche sur des chantiers ponctuels d'amélioration (kaizen) ;

le management doit se dérouler « sur le terrain », car seule l'expérience directe des situations de crise permet un diagnostic efficace (genchi genbutsu) ;

les décisions sont nécessairement adoptées par consensus ;■la stratégie à long terme : ■

l'entreprise doit privilégier les enjeux de long terme en explicitant son objectif global et en l'inscrivant de façon soutenable dans l'avenir ;

l'entreprise doit rechercher en permanence l'excellence.■

Sur ces bases, l'école de gestion lean est en constante évolution. Après avoir, ces dernières années, dépassé son cadre initial – l'organisation de la production –, elle est aujourd'hui perçue comme une méthode pertinente pour combattre tous les types d’inefficacité : l'intérêt pour le lean s'étend aux services administratifs (Lean Office), au développement de produit (Lean Development).

Lean et changement dans les organisations

L'application des principes du lean, notamment l'amélioration continue du système, impose de profonds changements dans les organisations. La résolution des problèmes au plus près du terrain, impliquant les opérationnels tout autant que les responsables, est un premier changement d'envergure,

2

Page 2 of 3Lean - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Lean

Page 40: Methode Agile

tant le changement est plutôt perçu dans les grands organisations comme quelque chose qui suit la voie hiérarchique descendante (top-down), où peu d'autonomie est laissée au terrain dans la prise d'initiative.

Notes et références ↑ lean Lettre8Octobre2004 (http://lean.enst.fr/wiki/bin/view/Lean/Lettre8Octobre2004) 1.↑ Littéralement « penser maigre ».2.

Voir aussi

Liens externes

(en) The Origins of the Toyota Production System(http://www.toyota.co.jp/en/vision/production_system/origin.html)

Article: The Roots of Lean: Training Within Industry: The Origin of Japanese Management and Kaizen (http://www.twisummit.com/Roots-of-Lean-TWI.pdf) written by Jim Huntzinger

Article: Lean Accounting: What's It All About?(http://www.leanaccountingsummit.com/LeanAccountingDefined-Target.pdf)

L'informatique Conviviale (http://informatique-conviviale.eyrolles.com/) , Le Lean Management peut-il transformer l'entreprise ? Eyrolles, 2010

Une optique variée du lean (http://artoflean.com/elearn_tps/slides/slide_Page_008.jpg) ■

Bibliographie

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

Dernière modification de cette page le 26 mai 2010 à 11:51.Droit d'auteur : les textes sont disponibles sous licence Creative Commons paternité partage à l’identique ; d’autres conditions peuvent s’appliquer. Voyez les conditions d’utilisation pour plus de détails, ainsi que les crédits graphiques. En cas de réutilisation des textes de cette page, voyez comment citer les auteurs et mentionner la licence. Wikipedia® est une marque déposée de la Wikimedia Foundation, Inc., organisation de bienfaisance régie par le paragraphe 501(c)(3) du code fiscal des États-Unis.

Page 3 of 3Lean - Wikipédia

01/06/2010http://fr.wikipedia.org/wiki/Lean