Mthode agile

Mthode agile
Les mthodes agiles sont des groupes de pratiques pouvant s'appliquer divers types de projets, mais se limitant plutt actuellement aux projets de dveloppement en informatique (conception de logiciel). Les mthodes agiles se veulent plus pragmatiques que les mthodes traditionnelles. Elles impliquent au maximum le demandeur (client) et permettent une grande ractivit ses demandes. Elles visent la satisfaction relle du besoin du client en priorit aux termes d'un contrat de dveloppement. Les mthodes agiles reposent sur une structure (cycle de dveloppement) commune (itrative, incrmentale et adaptative), quatre valeurs communes dclines en douze principes communs desquels dcoulent une base de pratiques, soit communes, soit complmentaires. Parmi ces mthodes on trouve en premier lieu la mthode RAD Modle schmatique des mthodes agiles (dveloppement rapide d'applications) (1991), puis DSDM, la version anglaise du RAD (1995). Plusieurs autres mthodes, comme ASD ou FDD, reconnaissent leur parent directe avec RAD. Les deux mthodes agiles dsormais les plus utilises sont : la mthode Scrum (1995) et la mthode XP Extreme programming (1999). Un mouvement plus large (management agile) couple les valeurs agiles aux techniques de l'amlioration continue de la qualit (plus particulirement le Lean). Le feedback de cette tendance revient impacter les techniques de dveloppement[Quoi?] par le biais d'une spcialisation porte initialement par les travaux de Mary et Tom Poppendieck (le Lean software development[1]). On constate galement un largissement de l'utilisation d'agile l'ensemble de la structure de l'entreprise[2].

Itratif, incrmental et adaptatif

L'volution des cycles en matire de dveloppement informatique a dbut avec une vision incrmentale dite "cascade" ou "cycle en V" de la succession des livrables produire et valider, puis s'est complexifie en acceptant les recouvrements de phases de l'ingnierie concourante (figure : Evolution des cycles basiques). La notion d'itratif (retour pour affinements ou modifications) a ensuite t utilise partir de 1991 dans la plupart des cycles de dveloppement (figure : Diverses formes d'itratif). Dans la ralit des mthodes actuelles, le qualificatif d'itratif recouvre le plus souvent une ralit semi-itrative : la phase de production tant prcde de plusieurs tapes telles que l'exploration du besoin, le design de l'architecture et la planification (figure : Le cycle agile est en fait semi-itratif). Une mthode agile est avant tout itrative sur la base dun affinement du besoin mis en uvre dans des fonctionnalits en cours de ralisation et mme dj ralises. Cet affinement, indispensable la mise en uvre du concept adaptatif, se ralise en matire de gnie logiciel sous deux aspects :
Evolution des cycles basiques

Mthode agile

fonctionnellement, par adaptation systmatique du produit aux changements du besoin dtect par lutilisateur lors de la conception-ralisation du produit (notion de validation permanente de lutilisateur avec RAD et notion de conception mergente avec XP) ; techniquement, par remaniement rgulier du code dj produit (refactoring). Une mthode agile est ensuite, ventuellement, incrmentale. Lorsque le projet, quel que soit le nombre de participants, dpasse en dure une dizaine de journes en moyenne, la production de ses fonctionnalits seffectue en plusieurs incrments. La notion d'adaptatif, quant elle, ncessite au-del d'un simple principe, la mise en uvre de techniques de contrle de l'volution du livrable et d'une mtrique formelle des modifications, avant, aprs et en cours de la production. Il en dcoule une planification oprationnelle lmentaire, directement visible par le biais de l'affichage mural (figure : Affichage mural lmentaire). L'acceptation du mode adaptatif, qui permet au client de modifier ses exigences en cours de projet, aura pour consquence l'ventualit d'un primtre variable (figure : Critres Itratif - Incrmental - Adaptatif). Dans la plupart des projets consquents ou stratgiques des contraintes plus nombreuses devront tre prises en compte afin d'optimiser le pilotage de la ralisation (figure : Paramtres d'ajustement de planification).
Diverses formes d'itratif

Le cycle agile est en fait semi-itratif

Affichage mural lmentaire

Historique
Les mthode agiles sont l'aboutissement de nombreux travaux tels que ceux de Tom Gilb (cycle de vie volutif), de Scott Shultz (production en itrations rapides), de Brian Gallagher et de Alex Balchin. Elles intgrent aussi les techniques JRP (Joint Requirements Planning) et JAD (Joint application design)(en) qui furent inities par Dan Gielan, puis formalises par Chuck Morris d'IBM en 1984 et diffuses sous forme de livres en 1989 par, entre autres, J. Wood et D. Silver. En 1986, Barry Boehm publie le modle en spirale (dveloppement incrmental) tandis que Hirotaka Takeuchi(en) et Ikujiro Nonaka(en) publient The new new product developpement game[3] un modle de dveloppement de produits industriels bas sur l'engagement simultan des diverses disciplines concernes (ingnierie concourante). En 1991, James Martin(en) (RAD), sappuyant sur une vision de l'volution continue des technologies informatiques, propose une Paramtres d'ajustement de planification mthode de dveloppement rapide dapplication. Sa structure (itrative-incrmentale-adaptative), base des approches agiles actuelles, dtermine le phasage essentiel (figure : Le cycle agile est en fait semi-itratif) et met en uvre un principe adaptatif non restrictif fond sur la validation permanente des utilisateurs et leur responsabilit directe dans la dynamique applicative.

Critres Itratif - Incrmental - Adaptatif

Mthode agile 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 complments et des volutions (dtails Dveloppement rapide d'applications). En 2001, aux tats-Unis, dix-sept figures minentes du dveloppement logiciel se runissent pour dbattre d'un thme unificateur de leurs mthodes respectives. Les plus connus d'entre eux sont Ward Cunningham, l'inventeur du Wiki via WikiWikiWeb, Kent Beck, pre de l'extreme programming et cofondateur de JUnit, Ken Schwaber(en) et Jeff Sutherland(en), fondateurs de Scrum, Jim Highsmith(en), prnant l'ASD, Alistair Cockburn pour la mthode 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 critres communs et les principes qui, selon eux, conduisent aux meilleures concepts de direction de projets et de dveloppement de logiciels. De cette runion merge le Manifeste agile, considr comme la dfinition canonique du dveloppement agile et de ses principes sous-jacents[4]. Au dbut des annes 2000, une vague dune dizaine de mthodes (dont XP Extreme programming et Scrum sont les principales reprsentantes) apparaissent. L'apport mthodologique d'XP rside dans la prconisation de pousser lextrme les principales pratiques de qualit de la construction applicative ainsi que les techniques adaptatives destimation consensuelle, de planification pilote par l'utilisateur et de reporting visuel en temps rel de l'avancement ainsi que des problmes rencontrs (affichage mural base de post-it).

Valeurs
Les mthodes agiles prnent 4 valeurs fondamentales (entre parenthses, les citations du manifeste)[5] : 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 contrle) ou les procdures de fonctionnement. Il est prfrable d'avoir une quipe soude et qui communique, compose de dveloppeurs (ventuellement niveaux variables), plutt qu'une quipe compose d'experts fonctionnant chacun de manire isole. La communication est une notion fondamentale. L'application ( Des logiciels oprationnels, plus qu'une documentation exhaustive ) : Il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est une aide prcieuse mais non un but en soi. Une documentation prcise est utile comme moyen de communication. La documentation reprsente une charge de travail importante, mais peut pourtant tre nfaste si elle n'est pas jour. Il est prfrable de commenter abondamment le code lui-mme, et surtout de transfrer les comptences au sein de l'quipe (on en revient l'importance de la communication). La collaboration ( La collaboration avec les clients, plus que la ngociation contractuelle ) : Le client doit tre impliqu dans le dveloppement. On ne peut se contenter de ngocier un contrat au dbut du projet, puis de ngliger les demandes du client. Le client doit collaborer avec l'quipe et fournir un feed-back continu sur l'adaptation du logiciel ses attentes. L'acceptation du changement ( 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 premires livraisons du logiciel vont souvent provoquer des demandes d'volution.

Mthode agile

Principes
Ces 4 valeurs se dclinent en 12 principes gnraux communs toutes les mthodes agiles[6] : 01 - La plus haute priorit est de satisfaire le client en livrant rapidement et rgulirement des fonctionnalits forte valeur ajoute. 02 - Le changement est accept, mme tardivement dans le dveloppement, car les processus agiles exploitent le changement comme avantage comptitif pour le client. 03 - La livraison sapplique une application fonctionnelle, toutes les deux semaines deux mois, avec une prfrence pour la priode la plus courte. 04 - Le mtier et les dveloppeurs doivent collaborer rgulirement et de prfrence quotidiennement au projet. 05 - Le projet doit impliquer des personnes motives. Donnez leur l'environnement et le soutien dont elles ont besoin et faites leur confiance quant au respect des objectifs. 06 - La mthode la plus efficace de transmettre l'information est une conversation en face face. 07 - Lunit de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut de comptabiliser les fonctions non formellement acheves). 08 - Les processus agiles promeuvent un rythme de dveloppement soutenable (afin dviter la non qualit dcoulant de la fatigue). 09 - 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 tches parasites, sont appliqus comme principes essentiels. 11 - Les quipes s'auto-organisent afin de faire merger les meilleures architectures, spcifications et conceptions. 12 - intervalle rgulier, l'quipe rflchit aux moyens de devenir plus efficace, puis accorde et ajuste son processus de travail en consquence. Une mthode qualifie d'agile doit donc se composer d'un ensemble de pratiques instrumentant le cadre dcrit par les 12 principes gnraux agiles et en consquence s'inscrire dans le respect des 4 valeurs fondamentales ayant inspir le Manifeste agile.

Structure oprationnelle et pratiques du dveloppement agile

La premire des mthode Agiles, le RAD, depuis ses dbuts en 1991, prconise la formation d'une quipe de dveloppement particulire. Cette quipe est autonome, spcialement forme, concrtement motive et outille. Elle se compose essentiellement d'un profil unique de concepteurs-dveloppeurs forms des spcialits techniques complmentaires. L'quipe travaille avec les utilisateurs et gnralement un animateur dans une salle ddie, isole, spcialement quipe dans le style war room, o les murs sont utiliss 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 mthodes agiles. Parmi les techniques caractristiques de la conduite de projet agile apparues plus rcemment, on trouve l'expression des exigences formalise de prfrence en "rcits utilisateur" et son valuation consensuelle par l'quipe dans le cadre d'un jeu srieux intitul planning poker qui estime la charge produire dans une unit de valeur pouvant tre soit des "journes idales" soit des "points de rcit". Toutes les mthodes agiles utilisent un mode opratoire similaire, voire identique : Un responsable fonctionnel dfinit et ordonne la production des composants de l'application. Le projet est structur en incrments de 1 6 semaines suivant les ncessits (taille, ractivits, visibilit, ...). Une runion initiale organise chaque incrment en dfinissant les tches raliser. Lquipe pilote la qualit et la performance du projet de manire consensuelle.

Chaque jour, une courte runion d'avancement donne l'quipe une vision globale du projet, met en vidence les ventuels problmes et permet de factoriser les solutions.

Mthode agile Un reporting mural (Kanban, graphes de progression, etc.) est mis a jour en temps rel par les membres de l'quipe. Un incrment achev contient une livraison complte, dveloppe, approuve et teste. Une runion finale prsente l'application et est suivie d'une rtrospective technique du processus de dveloppement. Le responsable fonctionnel valide le travail de l'quipe et ajuste les besoins entre chaque incrment.

Pratiques communes l'ensemble des mthodes agiles

1. Les pratiques communes lies aux ressources humaines Participation de lutilisateur final aux groupes de travail. Groupes de travail disposant du pouvoir de dcision. Autonomie et organisation centralise de lquipe (motivation). Spcification et validation permanente des Exigences. 2. Les pratiques communes lies au pilotage du projet Niveau mthodologique variable en fonction des enjeux du projet. Pilotage par les enjeux et les risques. Planification stratgique globale base sur des itrations rapides. Ralisation en jalons par prototypage actif itratif et incrmental. Recherche continue damlioration des pratiques. 3. Les pratiques communes lies la qualit de la production Recherche dexcellence technique de la conception. Vision graphique dune modlisation ncessaire et suffisante. Vision de la documentation ncessaire et suffisante. Normes et techniques raisonnables de qualit du code (mtrique). Architecture base de composants. Gestion des changements automatise.

Pratiques diffrenciatrices des mthodes agiles

Seules quelques techniques complmentaires entre elles, ou mieux adaptes des typologies et des tailles de projets donnes, diffrencient les mthodes agiles. Les pratiques diffrenciatrices les plus marquantes sont : La mthode RAD prconise lors de la phase de Construction de l'application des techniques similaires celles d'XP mais non extrmes dans leur mise en oeuvre : des revues de code personnelles, puis collectives et l'intgration avant chaque focus (ou show). Par contre, le RAD limite la programmation en binme aux parties les plus stratgiques. Toute mthode de conduite de projet devrait inclure un mode opratoire pour les arrts d'urgence (Go/NoGo). Sur ce point la force du RAD se situe dans la prsence d'un animateur-facilitateur. Cette ressource, de prfrence externe, doit tre neutre en regard des autres intervenants. Elle rpond une autorit suprieure tous les participants du projet. Ainsi, lorsque le contexte stratgique, conomique ou technique d'un projet volue, ou si les conditions de ralisation se dgradent, l'animateur reporte le problme au dirigeant qui l'a mandat. Ce dernier peut alors prendre, dans les meilleurs dlais, et avec des informations objectives les dcisions qui s'imposent. Le RAD dans sa version 2 recommande la variabilit de la taille et de la maturit des groupes de travail en fonction des phases du projet afin d'optimiser l'engagement des ressources et de prserver leur intrt par un travail adapt leurs proccupations. Le plus srieux 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 runions est base sur un mode opratoire des entretiens et sur des techniques de

Mthode agile validation permanente. Le RAD propose des techniques de pilotage stratgique comme la livraison en fonctionnalit rduite ou la livraison par thmes. La mthode DSDM (nom donn au consortium commercialisant la mthode RAD en Angleterre) se particularise par la spcialisation des acteurs du projet dans une notion de rles . Ainsi, l'on trouvera dans les runions DSDM des sponsors excutifs, des ambassadeurs, des utilisateurs visionnaires, des utilisateurs conseillers, sans oublier l'animateur-facilitateur et des rapporteurs. La mthode scrum affirme sa diffrence dans la gnralisation d'un crmonial bas sur des pratiques de courtes runions chaque tape de la vie du projet (rtrospectives). Ces temps de travail commun ont pour objectifs d'amliorer la motivation des participants, de synchroniser les tches, de dbloquer les situations difficiles et d'accrotre le partage de la connaissance. Pour FDD, la particularit nomme mission focused rside dans une forte orientation vers un but immdiat mesurable guid par la notion de valeur mtier. C'est en fait l'ambition globale d'une itration qui se trouve ainsi renforce. Cet aspect se retrouve aussi dans la mthode RAD sous la forme des objectifs de Focus ou dans Scrum dans la notion d'objectifs de Sprint. XP (extreme programming) est trs ax sur la partie Construction de l'application. Une de ses originalits rside dans lapproche de planification qui se matrialise sous la forme dun jeu intitul planning game et qui implique simultanment les utilisateurs et les dveloppeurs. On notera aussi des techniques particulires lies la production du code comme le test driven development (TDD), la programmation en binme (Pair programming), l'appropriation collective du code, la refactorisation (refactoring) et l'intgration continue.

Optimisation des pratiques

Selon Jean-Pierre Vickoff, dans la communication initiale de PUMA (Proposition pour l'unification des mthodes agiles), publie sur le site de l'ADELI (Association pour la matrise des Systmes d'Information), La mthode agile idale s'appuierait sur une utilisation optimise des pratiques du tronc commun et s'enrichirait d'une slection des pratiques particulires utiles un contexte de projet particulier. Le principe final de PUMA (Processus Urbanisant les Mthodes Agiles tendu l'entreprise) et de PUMA Essentiel (une version lgre limite au niveau "projet"), a fait l'objet de plusieurs publications en anglais[7], ainsi qu' une synthse en franais[8].

Critres d'ligibilit
De multiples facteurs contextuels peuvent tre pris en considration pour valider ou invalider la possibilit d'application d'une mthode agile. Les principaux critres d'ligibilit pourraient tre les suivants : 1. Favorisant : Besoin rapide de mise disposition du produit Imprvisibilit des besoins du client Ncessit de changements frquents Besoin de visibilit du client sur l'avancement des dveloppements Prsence de l'utilisateur assurant un feedback immdiat 2. Dfavorisant : Indisponibilit du client ou de l'utilisateur Dispersion gographique des ressources humaines Inertie des acteurs du projet ou refus des changements Gouvernance complexe de la DSI

Dans les cas o les critres d'ligibilit de l'utilisation d'une approche agile n'ont pas t respects, un risque de drive li un formalisme lger peut apparatre.

Mthode agile

Principales critiques
Dans la ralit de leur mise en uvre, toutes les mthodes ne respectent pas l'identique les principes fondamentaux agiles. Scrum ncessite une importante spcification pralable la mise en production (backlog produit)ce qui le classe en partie du ct prdictif des mthodes. Ce point ne serait pas un problme si Scrum disposait d'une mtrique formelle de gestion des modifications. Mais l'objectif de Scrum est essentiellement orient sur la matrise dune livraison dincrments (sprint) son processus rfute donc la possibilit de modifier les fonctionnalits en cours de ralisation ( l'exception d'un simple affinement depuis la version 2011). Scrum ne peut pas tre alors considr comme rellement itratif et adaptatif. Ces points interdisent aussi la mise en uvre dune conception mergente. Par ailleurs, comme Scrum ne propose aucune technique d'ingnierie du logiciel, il est indispensable de faire appel une autre mthode pour assurer la qualit et la fiabilit des dveloppements informatiques. De mme, lors de projets complexes, il est ncessaire d'ajouter Scrum comme eXtrme Programming les pratiques de structuration des exigences qui leur font dfaut.

Citation
Il aura fallu prs de vingt annes au mouvement agile, paralllement la pression de la mondialisation, pour bousculer vraiment la conduite de projet classique. Dsormais, le futur de lagilit mthodologique se trouve certainement, dune part, dans linstrumentation et la personnalisation la carte des pratiques essentielles pour un contexte spcifique et, dautre part, dans son largissement tous les aspects de lAgilit organisationnelle. Jean-Pierre Vickoff dans diverses contributions, dont, en premier lieu l'Informatique Professionnelle 2007 et, plus rcemment, l'ouvrage Mthode AGILE.

Mthodes agiles
Classes 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 mthodes se reconnaissant un lien avec l'agilit

MACAO 2TUP (2 track unified process, prononcez "toutiyoupi") prconise un cycle de vie en Y qui dissocie la rsolution des questions fonctionnelles et techniques. Le cycle de vie de 2TUP s'apparente un cycle de dveloppement en cascade mais introduit une forme itrative interne certaines tches. Il n'est pas certain que ce cycle s'apparente rellement une approche agile. Par contre, 2TUP prconise des formes de recherche de qualit et de performance intressantes telles que les services rutilisables et la conception gnrique (Framework et Patron de conception Design pattern) proches des mcanismes architecturaux de RUP. RUP se caractrise par une approche globale nomme Vue 4+1 . Les 5 composants de cette vue sont : la vue des Cas d'utilisation, la vue Logique, la vue d'Implmentation, la vue du Processus, la vue du Dploiement. 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, proprit d'IBM, n'est pas une mthode

Mthode agile agile stricto sensu. Mais il en existe une dclinaison agile, mais non libre de droits, sous l'acronyme de AUP (Agile unified process(en)).

Bibliographie francophone
RAD, le dveloppement d'applications client-serveur, Jean-Pierre Vickoff, Macmillan, 1996 (ISBN2744002224) Systmes d'information et processus agiles, Jean-Pierre Vickoff, Hermes Science Publication, 2003
(ISBN2746207028)

L'eXtreme Programming, de Jean-Louis Bnard, Laurent Bossavit, Rgis Mdina, Dominic Williams Eyrolles 2004 (ISBN221211561X) Matriser les projets avec XP : Pilotage par les tests-client, Thierry Cros, Editions Cpadues, 2004
(ISBN2854286391)

Mthode agile, Les meilleures pratiques, Comprhension et mise en uvre, Jean-Pierre Vickoff, QI, 2009
(ISBN978-2912843074)

SCRUM, le guide de la mthode agile la plus populaire, Claude Aubry, InfoPro, Dunod, 2010
(ISBN978-2100540181)

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

Rfrences
[1] (http:/ / cf. agilealliance. org/ articles/ article_list. cfm?CategoryID=40) [2] Travaux (http:/ / cf. agilealliance. org/ articles/ article_list. cfm?CategoryID=82) de Jean-Pierre Vickoff publis par l'Agile Alliance (en) et par ADELI (fr) [3] (en) Hirotaka Takeuchi(en) et Ikujiro Nonaka(en), The New New Product Development Game (Article preview) (http:/ / hbr. org/ 1986/ 01/ the-new-new-product-development-game/ ar/ 1) sur The magasine (Harvard business review), janvier1986. Mis en ligne le 14/05/2012, consult le 14/05/2012 [4] Le Manifeste agile a t rendu public en 2001, et plusieurs implmentations de la mthode, comme XP, SCRUM, et Crystal, existent., Kieran Conboy et Brian Fitzgerald, Extreme Programming And Mthodes agiles - XP/Agile Universe 2004 : 4e Confrence sur Extreme Programming et les Mthodes Agiles, Calgary, Canada, du 15 au 18 aot 2004, Actes, chapitre Vers un cadre conceptuel pour les Mthodes Agiles, Springer Verlag, New York, aot 2004[pas clair], (ISBN354022839X), (en) lien (http:/ / books. google. fr/ books?hl=en& lr=& id=tmvI_a4YUNMC& oi=fnd& pg=PA105& ots=xejboEQhET& sig=ULAr0yaORppprWTgs8Sne0x9f4I) [5] Manifeste pour le dveloppement Agile de logiciels (http:/ / agilemanifesto. org/ iso/ fr/ ) [6] Traduction des principes sous-jacents au manifeste (http:/ / agilemanifesto. org/ iso/ fr/ principles. html) [7] Articles relevant de PUMA (http:/ / cf. agilealliance. org/ articles/ article_list. cfm?CategoryID=82) sur Agile Alliance US. Consult le 21/05/2012 [8] PUMA Essentiel (http:/ / www. entreprise-agile. com/ Pessentiel. htm) sur entreprise-agile.com. Consult le 21/05/2012

Sources et contributeurs de larticle

Sources et contributeurs de larticle

Mthode agile Source: http://fr.wikipedia.org/w/index.php?oldid=82498020 Contributeurs: Alain Caraco, AlexisMonville, Ancalagon, Ange Gabriel, Auregann, Badmood, Bapti, Baraby, Bbullot, BernardNotarianni, Boly38, Chest, Chrismeau, Christophe.moustier, Copyleft, Corendiel, Dhorv, Dirac, Dominic.danis, Drongou, Elem1, Elolozone, Ericlaplante, Fabizor, Flo, Free French, GastelEtzwane, Gbog, Gdgourou, Goodshort, Gribeco, Guillaume Pousse, Herve, Ilario, JJ-Stern, Jerome66, Jmax, Jonathan.Scher, Josepant, Koui, Laddo, Le petit correcteur, Lomita, Lordgun, MathsPoetry, MattMoissa, Merimac, Mrigaudvin, Mwkm, Mgluglu, Ortholam, Pascalfares, Pautard, Phido, Plyd, Rollmops312, Sanao, Sariputra, Sebleouf, SimonMalenky, Slacrampe, Soliver, TcheBTchev, Tfrebault, TigH, Timinou, Traroth, Turb, Ulysse2000, Vickoff, Virtualblackfox, WazaPopo, Yelkrokoyade, 128 modifications anonymes

Source des images, licences et contributeurs

File:Agile Software Development methodology.svg Source: http://fr.wikipedia.org/w/index.php?title=Fichier:Agile_Software_Development_methodology.svg Licence: Creative Commons Attribution-Sharealike 3.0 Contributeurs: Agile-Software-Development-Poster-En.pdf: and VersionOne, Inc. *derivative work: Devon Fyson File:CyclesBasiques.jpg Source: http://fr.wikipedia.org/w/index.php?title=Fichier:CyclesBasiques.jpg Licence: Creative Commons Attribution-Sharealike 3.0 Contributeurs: User:Vickoff File:IteratifCycles.jpg Source: http://fr.wikipedia.org/w/index.php?title=Fichier:IteratifCycles.jpg Licence: Creative Commons Attribution-Sharealike 3.0 Contributeurs: User:Vickoff File:SemiIteratif.jpg Source: http://fr.wikipedia.org/w/index.php?title=Fichier:SemiIteratif.jpg Licence: Creative Commons Attribution-Sharealike 3.0 Contributeurs: User:Vickoff File:ReportingMural.jpg Source: http://fr.wikipedia.org/w/index.php?title=Fichier:ReportingMural.jpg Licence: Creative Commons Attribution-Sharealike 3.0 Contributeurs: User:Vickoff File:IteratiIncrementalAdaptatif.jpg Source: http://fr.wikipedia.org/w/index.php?title=Fichier:IteratiIncrementalAdaptatif.jpg Licence: Creative Commons Attribution-Sharealike 3.0 Contributeurs: User:Vickoff File:Planification.jpg Source: http://fr.wikipedia.org/w/index.php?title=Fichier:Planification.jpg Licence: Creative Commons Attribution-Sharealike 3.0 Contributeurs: User:Vickoff

Licence
Creative Commons Attribution-Share Alike 3.0 Unported //creativecommons.org/licenses/by-sa/3.0/