Des informations de cet article ou section devraient être mieux reliées aux sources mentionnées dans la bibliographie ou en liens externes.

Les méthodes agiles sont des groupes de pratiques de projets de développement en informatique (conception de logiciel), pouvant s'appliquer à divers types de projets. Elles ont pour dénominateur commun l'Agile manifesto. Rédigé en 2001, celui-ci consacre le terme d'« agile » pour référencer de multiples méthodes existantes. 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 client en priorité aux termes d'un contrat de développement.

Les méthodes agiles reposent sur une structure (cycle de développement) commune (itérative, incrémentale et adaptative), quatre valeurs communes déclinées en douze principes communs desquels découlent une base de pratiques, soit communes, soit complémentaires.

Les méthodes pouvant se qualifier d'agile depuis la publication de l'agile manifesto sont le RAD (développement rapide d'applications) (1991) avec DSDM, la version anglaise du RAD (1995) ainsi que plusieurs autres méthodes, comme ASD ou FDD qui reconnaissent leur parenté directe avec RAD. Les deux méthodes agiles désormais les plus utilisées sont : la méthode Scrum qui fut présentée en 1995 par Ken Schwaber¹puis publiée en 2001 par lui même et Mike Beedle pour enfin être diffusée mondialement par Jeff Sutherland ainsi que la méthode XP Extreme programming publiée en 1999 par Kent Beck.

Un mouvement plus large (management agile) couple les valeurs agiles aux techniques de l'amélioration continue de la qualité (plus particulièrement le Lean). On constate un élargissement de l'utilisation d'agile à l'ensemble de la structure de l'entreprise².

L'évolution des cycles en matière de développement informatique a débuté avec une vision incrémentale dite « cascade » ou « cycle en V » de la succession des livrables à produire et à valider, puis s'est complexifiée en acceptant les recouvrements de phases de l'ingénierie concourante.

Evolution des cycles basiques

Diverses formes d'itératif

Le cycle agile est en fait semi-itératif

Affichage mural élémentaire

Avancement graphique du projet

Critères Itératif - Incrémental - Adaptatif

Paramètres d'ajustement de planification

Les travaux sur le cycle de production itératif et incrémental remontent aux années 1930 et 40, avec les travaux de Walter Shewhart et William Edwards Deming. Ces recherches sont appliquées à la production informatique à la fin des années 1950, notamment avec le développement de parties logicielles dans le cadre du programme Mercury³. Gerald Weinberg mentionne un projet de développement réalisé en 1957 pour Motorola qui utilisait une technique similaire à ce qui sera plus tard l'eXtreme programming³.

Dans la réalité des méthodes actuelles, le qualificatif d'itératif recouvre le plus souvent une réalité semi-itérative : la phase de production étant précédée de plusieurs étapes telles que l'exploration du besoin, le design de l'architecture et la planification.

Une méthode agile est 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’effectue en plusieurs incréments.

La notion d'adaptatif, quant à elle, nécessite au-delà d'un simple principe, la mise en œuvre de techniques de contrôle de l'évolution du livrable et d'une métrique formelle des modifications, avant, après et en cours de la production. Il en découle une planification opérationnelle élémentaire, directement visible par le biais de l'affichage mural (figure : Affichage mural élémentaire).

Un contrat agile est tout à fait possible. Il se base sur l'évaluation du périmètre connu à produire avec une technique agile comme le jeu d'estimation consensuelle. Ce principe exprime en unité d'œuvre, telle les journées idéales par exemple, un engagement de l’équipe sur des objectifs précis. Ces objectifs font l’objet du contrat-projet initial. Le contenu fonctionnel peut ensuite être modifié, en permanence et même en cours de développement, par la maîtrise d'ouvrage. Chaque modification est tracée sur la fiche de récit utilisateur de la fonctionnalité modifiée ou abandonnée en cours de développement. Les parties de développement réutilisables sont alors réintégrées dans l’évaluation formelle des modifications ou des nouvelles fonctionnalités. Dans ce contexte, l’équipe a pour obligation de livrer en fin d’incrément un nombre d’unités d’œuvre au moins égal à sa vitesse nominale prévue en début de projet (nombre de personnes * nombre de jours ouvrés de travail sur l’incrément) ; le nombre d’unité d’œuvre (UE) permettant de présenter graphiquement la productivité obtenue pour chaque incrément se compose alors ainsi : UE livrées au total = UE livrées utiles + UE livrées abandonnées. Ce principe se matérialise ensuite avec la forme de reporting agile nommé BurnUp chart (figure : Avancement graphique du projet).

L'acceptation du mode adaptatif, qui permet au client de modifier ses exigences en cours de projet, aura pour conséquence l'éventualité d'un périmètre variable (figure : Critères Itératif - Incrémental - Adaptatif). Dans la plupart des projets conséquents ou stratégiques des contraintes plus nombreuses doivent être prises en compte afin d'optimiser le pilotage de la réalisation (figure : Paramètres d'ajustement de planification).

Les méthodes agiles sont l'aboutissement de nombreux travaux tels que ceux de Tom Gilb (cycle de vie évolutif), de Scott Shultz (production en itérations rapides), de Brian Gallagher et de Alex Balchin. Elles intègrent aussi les techniques JRP (Joint Requirements Planning) et JAD (Joint application design) qui furent initiées par Dan Gielan, puis formalisées par Chuck Morris d'IBM en 1984 et diffusées sous forme de livres en 1989 par, entre autres, J. Wood et D. Silver. La première méthode agile⁴ serait la méthode EVO⁵, de Tom Gilb , publiée en 1976.

En 1986, Barry Boehm publie le modèle en spirale (développement incrémental) tandis que Hirotaka Takeuchi et Ikujiro Nonaka publient « The new new product developpement game⁶ » un modèle de développement de produits industriels basé sur l'engagement simultané des diverses disciplines concernées (ingénierie concourante).

En 1991, James Martin (RAD), s’appuyant sur une vision de l'évolution continue des technologies informatiques, propose une méthode de développement rapide d’application. Sa structure (itérative-incrémentale-adaptative), base des approches agiles actuelles, détermine le phasage essentiel (figure : Le cycle agile est en fait semi-itératif) 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 en 1999, et Jennifer Stapleton en Grande-Bretagne, avec DSDM, introduisent des compléments et des évolutions (détails Développement rapide d'applications).

En 2001, aux États-Unis, dix-sept figures éminentes du développement logiciel se réunissent pour débattre d'un thème unificateur de leurs méthodes respectives. 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 , créateur et promoteur de Scrum, Jim Highsmith , prônant l'ASD, Alistair Cockburn pour la méthode Crystal clear, Martin Fowler et Dave Thomas, ainsi qu'Arie van Bennekum pour DSDM (Dynamic System Development Method). Ces 17 experts extraient alors de leurs usages respectifs les critères communs et les principes qui, selon eux, conduisent aux meilleures concepts de direction de projets et de développement de logiciels.

De cette réunion émerge le Manifeste agile, considéré comme la définition canonique de valeurs de l'agilité agile et de ses principes sous-jacents⁷.

Au début des années 2000, une vague d’une dizaine de méthodes (dont XP Extreme programming et Scrum sont les principales représentantes) sont popularisées. 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). Scrum propose un ensemble réduit de pratiques concentrées sur le développement de l'adaptabilité par l'apprentissage et l'auto-organisation.

Fondementsmodifiermodifier le code

Quatre valeurs fondamentalesmodifiermodifier le code

Les méthodes agiles prônent 4 valeurs fondamentales (entre parenthèses, les citations du manifeste)⁸ :

• 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 compte rendu continu sur l'adéquation du logiciel avec 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 livraisons du logiciel vont souvent provoquer des demandes d'évolution.

Douze principes générauxmodifiermodifier le code

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

1. La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à forte valeur ajoutée. ( ce principe est superflu dans cette théorie )
2. Le changement est accepté, même tardivement dans le développement, car les processus agiles exploitent le changement comme avantage concurrentiel pour le client.
3. La livraison s’applique à une application fonctionnelle, toutes les deux semaines à deux mois, avec une préférence pour la période la plus courte.
4. Le métier et les développeurs doivent collaborer régulièrement et de préférence quotidiennement au projet.
5. Le projet doit impliquer des personnes motivées. Donnez-leur l'environnement et le soutien dont elles ont besoin et faites leur confiance quant au respect des objectifs.
6. La méthode la plus efficace pour transmettre l'information est une conversation en face à face.
7. L’unité de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut de comptabiliser les fonctions non formellement achevées).
8. Les processus agiles promeuvent un rythme de développement soutenable (afin d’éviter la non qualité découlant de la fatigue).
9. Les processus agiles recommandent une attention continue à l'excellence technique et à la qualité de la conception.
10. La simplicité et l'art de minimiser les tâches parasites, sont appliqués comme principes essentiels.
11. Les équipes s'auto-organisent afin de faire émerger les meilleures architectures, spécifications et conceptions.
12. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son processus de travail en conséquence.

Une méthode qualifiée d'agile doit donc se composer d'un ensemble de pratiques instrumentant le cadre décrit par les 12 principes généraux agiles et en conséquence s'inscrire dans le respect des quatre valeurs fondamentales ayant inspiré le Manifeste agile.

Structure opérationnelle et pratiques du développement agilemodifiermodifier le code

La première des méthode Agiles, le RAD, depuis ses débuts en 1991, préconise la formation d'une équipe de développement particulière. 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. L'équipe travaille avec les utilisateurs et généralement un animateur dans une salle spéciale, isolée, spécialement équipée dans le style war room, où les murs sont utilisés pour afficher un « radiateur d'information » (une forme de cockpit de management de projet). Cette organisation et ces techniques sont devenues communes à l'ensemble des méthodes agiles.

Parmi les techniques caractéristiques de la conduite de projet agile apparues plus récemment, on trouve l'expression des exigences formalisée de préférence en « récits utilisateur » et son évaluation consensuelle par l'équipe dans le cadre d'un jeu sérieux intitulé planning poker qui estime la charge à produire dans une unité de valeur pouvant être soit des « journées idéales » soit des « points de récit ».

Toutes les méthodes agiles utilisent un mode opératoire similaire, voire identique :

• Un responsable fonctionnel définit et ordonne la production des composants de l'application.
• Le projet est structuré en incréments de une à six semaines suivant les nécessités (taille, réactivité, visibilité...).
• Une réunion initiale organise chaque incrément en définissant les tâches à réaliser.
• L’équipe pilote la qualité et la performance du projet de manière consensuelle.
• Chaque jour, une courte réunion d'avancement donne à l'équipe une vision globale du projet, met en évidence les éventuels problèmes et permet de factoriser les solutions.
• Un 'reporting' mural (Kanban, graphes de progression, etc.) est mis à jour en temps réel par les membres de l'équipe.
• Un incrément achevé contient une livraison complète, développée, approuvée et testée.
• Une réunion finale présente l'application et est suivie d'une rétrospective technique du processus de développement.
• Le responsable fonctionnel valide le travail de l'équipe et ajuste les besoins entre chaque incrément.

Identification des méthodes agilesmodifiermodifier le code

Pratiques communes à l'ensemble des méthodes agilesmodifiermodifier le code

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

Pratiques différenciatrices des méthodes agilesmodifiermodifier le code

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. Les pratiques différenciatrices les plus marquantes sont :

• La méthode RAD préconise lors de la phase de Construction de l'application des techniques similaires à celles d'XP mais non extrêmes dans leur mise en œuvre : 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. 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 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. Le plus sérieux apport de RAD2 à la communication de projet et à la formalisation des exigences applicatives est le groupe d'animation et de rapport (GAR). 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. Le RAD propose des techniques de pilotage stratégique comme la livraison en fonctionnalité réduite ou la livraison par thèmes.

• La méthode DSDM (nom donné au consortium commercialisant la méthode RAD en Angleterre) 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 la généralisation d'un cérémonial basé sur des pratiques de courtes réunions à chaque étape de la vie du projet (rétrospectives). 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 d'objectifs de Sprint.

• 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 le test driven development (TDD), la programmation en binôme (Pair programming), l'appropriation collective du code, la refactorisation (refactoring) et l'intégration continue.

Critères d'éligibilitémodifiermodifier le code

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

Dans les cas où les critères d'éligibilité de l'utilisation d'une approche agile n'ont pas été respectés, un risque de dérive lié à un formalisme léger peut apparaître.

Principales critiquesmodifiermodifier le code

Cet article ou cette section peut contenir un travail inédit ou des déclarations non vérifiées. Vous pouvez aider en ajoutant des références. Voir la page de discussion pour plus de détails.

Dans la réalité de leur mise en œuvre, toutes les méthodes ne respectent pas à l'identique les principes fondamentaux agiles.

Scrum nécessite une importante spécification préalable à la mise en production (backlog produit), ce qui le classerait en partie du côté prédictif des méthodes. Certains estiment que ce point ne serait pas un problème si Scrum disposait d'une métrique formelle de gestion des modifications. Mais l'objectif de Scrum est essentiellement orienté sur la maîtrise d’une livraison d’incréments (sprint). Son processus réfute donc la possibilité de modifier les fonctionnalités en cours de réalisation (à l'exception d'un simple affinement depuis la version 2011). Pour cette raison, certains prétendent que Scrum ne peut être alors considéré comme réellement itératif et adaptatif.

Par ailleurs, comme Scrum ne propose aucune technique d'ingénierie du logiciel, il est indispensable de faire appel à une autre méthode pour assurer la qualité et la fiabilité des développements informatiques.

D'aucuns expliquent, notamment lors de projets complexes, qu'il serait nécessaire d'ajouter à Scrum comme à eXtrême Programming les pratiques de structuration des exigences qui leur font défaut.

Exemples de méthodesmodifiermodifier le code

Méthodes agiles au sens strictmodifiermodifier le code

Classées par date de publication :

• Rapid Application Development (RAD, 1991)
• Dynamic systems development method (DSDM, 1995, consortium anglais commercialisant le RAD)
• Scrum (1996)
• Feature Driven Development ((en) FDD) (1999)
• Extreme programming (XP, 1999)
• Adaptive software development (ASD, 2000)
• Crystal clear (2004)

Autres méthodes se reconnaissant un lien avec l'agilitémodifiermodifier le code

• MACAO
• 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 cinq 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. À l'instar du guide d'activité de RAD 2, RUP offre également un guide de processus formel et adaptable. Ce guide est propre à RUP et orienté outil. À noter que Rational Unified Process, propriété d'IBM, n'est pas une méthode agile stricto sensu. Mais il en existe une déclinaison agile, mais non libre de droits, sous l'acronyme de AUP (Agile unified process ).

Événementsmodifiermodifier le code

Plusieurs événements traitant du thème de l'agilité sont organisés tous les ans dans le monde. Ils ont la plupart du temps pour objectif de faire découvrir cette méthodologie de développement sous forme de jeux agiles ou de retours d'expériences.

L'agile Tour¹⁰ est un des grand événement agile qui a lieu dans plusieurs pays (France, Amérique du Sud, États-Unis, Chine, Vietnam, Inde...) d'octobre à décembre. Il est organisé localement par des associations à but non lucratif.

L'Agile Alliance¹¹ et la Scrum Alliance¹² recensent également des événements dans le monde.

Bibliographiemodifiermodifier le code

Bibliographie francophonemodifiermodifier le code

• RAD, le développement d'applications client-serveur, Jean-Pierre Vickoff, Macmillan, 1996 (ISBN 2744002224)

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

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

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

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

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

• Le marketing de l'Incertain. Méthode agile de prospective par les signaux faibles et les scénarios dynamiques, Philippe Cahen, Kawa, 2011 (ISBN 978-2-918866-22-0)

Bibliographie anglophonemodifiermodifier le code

• Rapid Application Development, James Martin, Macmillan, 1991 (ISBN 978-0023767753)
• Extreme Programming Explained: Embrace Change, Kent Beck, (Addison-Wesley, October 5, 1999) 978-0201616415 (ISBN 978-0201616415)
• Agile Software Development With Scrum, Ken Schwaber, Mike Beedle, (Prentice Hall, October 21, 2001) (ISBN 978-0130676344)

Voir aussimodifiermodifier le code

Articles connexesmodifiermodifier le code

Référencesmodifiermodifier le code

Agile, de quoi s'agit-il ? Conférence de l'Association Française du Droit d'Internet et des Technologies (AFDIT)