Méthode agile

Modèle schématique des méthodes agiles

Les méthodes agiles sont des groupes de pratiques pouvant s'appliquer à divers types de projets, mais se limitant plutôt actuellement aux projets de développement en informatique (conception de logiciel). Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles. Elles impliquent au maximum le demandeur (client) et permettent une grande réactivité à ses demandes. Elles visent la satisfaction réelle du besoin du client et non les termes d'un contrat de développement. La notion de méthode agile a été officialisée en 2001 par un document, le Manifeste agile (Agile Manifesto), signé par 17 personnalités impliquées dans l'évolution du génie logiciel, en particulier, en tant qu'auteur de leur propre méthode.

Les méthodes agiles et les pratiques qu'elles recouvrent sont antérieures au Manifeste agile, qui 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).

Agile (adaptatif) = itératif, incrémental. Une méthode agile est donc avant tout itérative sur la base d’un affinement du besoin mis en œuvre dans des fonctionnalités en cours de réalisation et même déjà réalisées. Cet affinement, indispensable à la mise en œuvre du concept adaptatif, se réalise en matière de génie logiciel sous deux aspects :

• fonctionnellement, par adaptation systématique du produit aux changements du besoin détecté par l’utilisateur lors de la conception-réalisation du produit (notion de validation permanente de l’utilisateur avec RAD et notion de conception émergente avec XP) ;
• techniquement, par remaniement régulier du code déjà produit (refactoring).

Une méthode agile est ensuite, éventuellement, incrémentale. Lorsque le projet, quel que soit le nombre de participants, dépasse en durée une dizaine de journées en moyenne, la production de ses fonctionnalités s’effectuent en plusieurs incréments.

La notion de méthode agile a émergé avec des pratiques ciblant uniquement le développement d'une application informatique. Mais un mouvement managérial plus large (management agile) commencerait à coupler les valeurs agiles aux techniques de l'amélioration continue de la qualité (MTQS ou Lean).

Historique

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

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

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

En 1991, James Martin (RAD), s’appuyant sur cette vision d’une évolution continue, propose une méthode de développement rapide d’application. Sa structure (itérative-incrémentale-adaptative), base des approches actuelles, détermine le phasage essentiel et met en œuvre un principe adaptatif non restrictif fondé sur la validation permanente des utilisateurs et leur responsabilité directe dans la dynamique applicative.

À 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, introduisent 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 1990, une vague d’une dizaine de méthodes (dont XP Extreme programming et Scrum sont les principales représentantes) apparaissent. L'apport méthodologique d'XP réside dans la préconisation de pousser à l’extrême les principales pratiques de qualité de la construction applicative ainsi que les techniques adaptatives d’estimation consensuelle, de planification pilotée par l'utilisateur et de reporting visuel en temps réel de l'avancement ainsi que des problèmes rencontrés (affichage mural à base de post-it).

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 sont 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éussissent à extraire de leurs concepts respectifs des critères pour définir une nouvelle façon de développer des logiciels :

De cette réunion émerge le Manifeste agile, considéré comme la définition canonique du développement agile et de ses principes sous-jacents^[1].

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

" Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser : "

Valeurs

Dans ce but, elles prônent 4 valeurs fondamentales (entre parenthèses, les citations du manifeste)^[2] :

• L'équipe (« Les individus et leurs interactions plus que les processus et les outils ») : Dans l'optique agile, l'équipe est bien plus importante que les outils (structurants ou de 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 (« Des logiciels opérationnels plus qu'une documentation exhaustive ») : Il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est une aide précieuse mais non un but en soi. Une documentation précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l'équipe (on en revient à l'importance de la communication).

• La collaboration (« La collaboration avec les clients plus que la négociation contractuelle ») : 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 (« L'adaptation au changement plus que le suivi d'un plan ») : La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet. Les premières releases du logiciel vont souvent provoquer des demandes d'évolution.

Principes

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

• « Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. »
• « Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client. »
• « Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts. »
• « Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. »
• « Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés. »
• « La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face. »
• « Un logiciel opérationnel est la principale mesure d’avancement. »
• « Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs

et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant. »

• « Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité. »
• « La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle. »
• « Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées. »
• « À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. »

Citation

« 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. » Jean-Pierre Vickoff dans l'ouvrage Méthode AGILE

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)
• Test Driven Development (TDD, 2002)
• Crystal clear (2004)

Autres méthodes se reconnaissant de l'agilité

• MACAO
• PUMA (Processus Urbanisant les Méthodes Agiles) de Jean-Pierre Vickoff
• Kanban

Note : RUP (Rational Unified Process), un produit propriété d'IBM, n'est pas une méthode Agile. Il en existe une déclinaison Agile, mais non libre de droits, 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 données, 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.

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

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

• 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 murs en Information Radiator (une forme de cokpit de management de projet).

Optimisation des pratiques

Selon Jean-Pierre Vickoff, dans la communication initiale de PUMA (Proposition pour l'Unification des Méthodes Agiles)[2], publié sur le site de l'ADELI (Association pour la maîtrise 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 particulières utiles à un contexte de projet particulier. » Le principe final de PUMA (Processus Urbanisant les Méthodes Agiles étendu à l'entreprise)et de PUMA Essentiel (une version légère limitée au niveau "projet"), a fait l'objet de plusieurs publications en anglais sur le site de l'Agile Alliance US et une synthèse en français de trouve sur ce lien.

D'autres voies, telles que l'association d'Agile et de techniques en cascade classique, sembleraient donner de bons résultats^[4]. Cette direction est soutenue par un expert technique reconnu^[5].

Critiques

Dans les cas où les critères d'éligibilité de l'utilisation d'une approche agile n'ont pas été respectés, la méthode peut montrer plusieurs limites : risques de dérives, documentation insuffisante, inadaptation à des projets de grande envergure.

Toutes les méthodes ne respectent pas à l'identique les principes fondamentaux Agiles. Par exemple : les pratiques de Scrum sont essentiellement orientés sur la maîtrise d’une livraison d’incréments (sprint) mais réfutent la possibilité de modifier les fonctionnalités en cours de réalisation (backlog de sprint), interdisant donc la mise en œuvre d’une conception émergente. Scrum, ne disposant pas de métrique de gestion du changement à ce niveau, nécessite donc une importante spécification préalable à la mise en production (backlog produit) et, du fait de cette prédictibilité imposée, ne peut pas être considéré comme réellement itératif, donc adaptatif. De même, lors de projets complexes, il est nécessaire d'ajouter à eXtrême Programming les pratiques de structuration des exigences qui lui font défaut.

Critères d'éligibilité

De multiples facteurs contextuels peuvent être pris en considération pour valider ou invalider la possibilité d'application d'une méthode agile. Les principaux critères d'éligibilité pourraient être les suivants :

1. favorisant :
   • Besoin rapide de mise à disposition du produit
   • Imprévisibilité des besoins du client
   • Nécessité de changements fréquents
   • Besoin de visibilité du client sur l'avancement des développements
   • Présence de l'utilisateur assurant un feedback immédiat
2. défavorisant :
   • Indisponibilité du client ou de l'utilisateur
   • Dispersion géographique des ressources humaines
   • Inertie des acteurs du projet ou refus des changements
   • Gouvernance complexe de la DSI

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)

• Méthode Agile, Les meilleures pratiques, Compréhension et mise en œuvre , Jean-Pierre Vickoff, QI, 2009 (ISBN 978-2912843074)

• PUMA Essentiel, Méthode Agile Optimale, Jean-Pierre Vickoff, QI, 2008 (ISBN 978-2912843067)

• SCRUM, le guide de la méthode agile la plus populaire, Claude Aubry, InfoPro, Dunod (ISBN 978-2100540181)

Voir aussi

Liens internes

• Management agile
• Agile Alliance
• Principes de gestion agile
• Scrum (méthode)
• Cycle de développement (logiciel)

Références

1. ↑ « Le Manifeste agile a été rendu public en 2001, et plusieurs implémentations de la méthode, comme XP, SCRUM, et Crystal, existent. », Kieran Conboy et Brian Fitzgerald, Extreme Programming And Méthodes agiles - XP/Agile Universe 2004 : 4e Conférence sur Extreme Programming et les Méthodes Agiles, Calgary, Canada, du 15 au 18 août 2004, Actes, chapitre Vers un cadre conceptuel pour les Méthodes Agiles, Springer Verlag, New York, août 2004, (ISBN 354022839X), (en) lien
2. ↑ Manifeste pour le développement Agile de logiciels
3. ↑ Traduction des principes sous-jacents au manifeste
4. ↑ (en) Why hybrid waterfall/agile process lessens distributed software development problems
5. ↑ [1] Une fois les fondations fixées (plan, modèle et analyse globale), des évolutions incrémentales peuvent être mises en œuvre, afin de livrer des produits de court terme. Et c'est là que vous pouvez mettre en place des délais et utiliser les Méthodes Agiles. Chacune de ces lignes droites sera une étape vers le but final.