Méthode agile 34228 31800438 2008-07-22T19:48:48Z 82.224.21.26 /* Méthodes Agiles publiées */ La notion de '''méthode agile''' se limite actuellement aux méthodes ciblant le développement d'une application [[informatique]]. Ces méthodes Agiles permettent de [[conception de logiciel|concevoir des logiciels]] en impliquant au maximum le demandeur (client), ce qui permet une grande réactivité à ses demandes. Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles. Elles visent la satisfaction réelle du besoin du client, et non d'un contrat établi préalablement. La notion de méthode agile est née à travers un [[Manifeste Agile]] signé par 17 personnalités. ==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 1991, [[James Martin]] ([[Développement rapide d'applications|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 initiait 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, - 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 quatre-vingt-dix, 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éthode agile|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'[[Adaptive software development|ASD]], [[Alistair Cockburn]] pour la méthode [[Crystal clear]], [[Martin Fowler]], et [[Dave Thomas (programmeur)|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 des développer des logiciels : De cette réunion devait émerger le Manifeste Agile, considéré comme la définition canonique du [[méthode agile|développement Agile]] et de ses principes sous-jacents<ref>"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 [[méthode agile|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}}, [http://books.google.fr/books?hl=en&lr=&id=tmvI_a4YUNMC&oi=fnd&pg=PA105&ots=xejboEQhET&sig=ULAr0yaORppprWTgs8Sne0x9f4I lien]</ref> . 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 ans 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 moyens matériels ou les procédures. Il est préférable d'avoir une équipe soudée et qui communique composée de développeurs moyens plutôt qu'une équipe composée d'individualistes, même brillants. La communication est une notion fondamentale. * '''L'application''' (« Logiciel fonctionnel plutôt que documentation complète ») : Il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est secondaire, même si une documentation succincte et précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l'équipe (on en revient à l'importance de la communication). * '''La collaboration''' (« Collaboration avec le client plutôt que négociation de contrat ») : Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du logiciel à ses attentes. * '''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 logiciels utiles ». * « Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client ». * « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte ». * « Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet ». * « Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail ». * « La méthode la plus efficace pour transmettre l'information est une conversation en face à face ». * « Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet ». * « Les processus agiles promeuvent un rythme de développement 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 ». ==Méthodes Agiles publiées == * [[Rapid Application Development]] (RAD) * [[Dynamic systems development method]] (DSDM) * [[Extreme programming]] (XP) * [[Adaptive software development]] (ASD) * Feature Driven Development([[:en:Feature Driven Development|FDD]]) * [[Scrum]] * [[Crystal clear]] * [[Processus Urbanisant les Méthodes Agiles]] ([http://www.entreprise-agile.com/ PUMA]) Note RUP (Rational [[Unified Process]]) n'est pas une méthode Agile et, est de plus un produit propriétaire d'IBM. Il existe une déclinaison Agile, mais propriétaire, de RUP sous l'acronyme de AUP (Agile Unified Process). ==Tronc des pratiques communes à l'ensemble des méthodes Agiles== '''1 - Les pratiques communes liées aux ressources humaines''' - 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. '''2 - Les pratiques communes liées au pilotage du projet''' - 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. '''3 - Les pratiques communes liées à la qualité de la production''' - 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 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. - [[2TUP]] préconise un cycle de vie en Y qui dissocie la 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. - [[UP]] 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 de travail 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 équipée style '''War Room''' qui transforme les mur 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)[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, 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}} * ''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, Eyrolles 2002 {{ISBN|221211561X}} * ''Maîtriser les projets avec XP : Pilotage par les tests-client'', Thierry Cros, Editions Cépadues, 2004, {{ISBN|2854286391}} ==Voir aussi== [[Management Agile]] ===Liens internes=== * [[Cycle de développement]] === Références === <references/> ===Liens externes=== * {{fr}} La Communauté Agile Suisse [http://www.agile-swiss.org/wiki/index.php/Accueil] * {{fr}} [http://www.agilequebec.ca/ La Communauté Agile de Québec] * {{fr}} [http://www.rad.fr/ Portail des DSI et chefs de projets SI & NTIC] * {{en}} [http://www.agilealliance.com/ L'Alliance agile] * {{en}} [http://agilemanifesto.org/ Le manifeste des méthodes agiles] * {{en}} [http://www.extremeprogramming.org/ Site de la méthode xp] Organisation garante du génie logiciel [http://www.adeli.org/ ADELI] pour l'aspect francophone. Organisation garante du génie logiciel [[Agile Alliance]] pour l'Aspect Anglophone. ==Autres liens == Ces liens font référence à des pratiques ou des théories se référant de l'Agilité sans pour autant avoir été officialisées par une communication sur le site de l'[[Agile Alliance]]. [[Principes de gestion agiles]] {{Portail informatique}} [[Catégorie:Méthode de développement logiciel]] [[Catégorie:Gestion de projet]] [[da:Agile]] [[de:Agile Softwareentwicklung]] [[en:Agile software development]] [[es:Desarrollo ágil de software]] [[fi:Ketterä ohjelmistokehitys]] [[he:פיתוח תוכנה זריז]] [[is:Agile]] [[it:Metodologia agile]] [[ja:アジャイルソフトウェア開発]] [[ko:애자일 개발 프로세스]] [[lt:Lankstusis programavimas]] [[lv:Spējā izstrāde]] [[nl:Agile-software-ontwikkeling]] [[pl:Agile]] [[pt:Desenvolvimento ágil de software]] [[ru:Гибкая методология разработки]] [[sh:Agilni razvoj softvera]] [[sv:Agile software development]] [[uk:Гнучка розробка програмного забезпечення]] [[vi:Lập trình linh hoạt]] [[zh:敏捷软件开发]]