Pmbok methodes agiles

3 169 vues

Publié le

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 169
Sur SlideShare
0
Issues des intégrations
0
Intégrations
132
Actions
Partages
0
Téléchargements
189
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Pmbok methodes agiles

  1. 1. Page 2/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Table des matières1. INTRODUCTION .............................................................................................4Business Interactif en quelques mots ....................................................................4Pourquoi un white paper sur les méthodes agiles ?...........................................42. LES METHODOLOGIES AGILES : GENERALITES .........................52.1 CONTEXTE.........................................................................................................52.2 CARACTERISTIQUES COMMUNES DES METHODES AGILES..........................52.2.1 Priorité aux personnes et aux interactions sur les procédures et lesoutils 62.2.2 Priorité aux applications fonctionnelles sur une documentationpléthorique.................................................................................................................72.2.3 Priorité de la collaboration avec le client sur la négociation decontrat 72.2.4 Priorité de l’acceptation du changement sur la planification.........72.3 DES METHODES RAD (RAPID APPLICATION DEVELOPMENT ) AUXMETHODES AGILES, UNE FILIATION ?.......................................................................102.3.1 Origines du RAD ...................................................................................102.3.2 Les acteurs du RAD...............................................................................102.3.3 Les cinq phases dun projet RAD........................................................132.3.4 RAD et modélisation.............................................................................142.3.5 Pourquoi le RAD nest il pas à proprement parler une méthode"agile" ? 142.4 DE UNIFIED PROCESS (UP & RUP) A L’AGILITE, UNE FILIATION ?.......152.4.1 Les 5 principes dUP.............................................................................152.4.2 Les activités dans la méthode UP.......................................................172.4.3 Les phases du cycle de vie....................................................................182.4.4 Pourquoi UP nest pas à proprement parler une méthode agile ?192.5 LA SITUATION EN FRANCE : UN FORT ANCRAGE DE LA METHODE MERISEET DE LA MODELISATION ENTITE-RELATION...........................................................203. PRINCIPALES METHODOLOGIES AGILES, ETAT DES LIEUX,COMPARAISON..........................................................................................................223.1 EXTREME PROGRAMMING (XP) ...................................................................223.1.1 Aux origines deXtreme Programming...............................................223.1.2 Les 4 valeurs deXtreme Programming .............................................223.1.3 Principes de base...................................................................................233.1.4 Les 12 pratiques XP..............................................................................253.1.5 Cycle de vie.............................................................................................283.1.6 Rôles ........................................................................................................313.1.7 Forces et faiblesses ...............................................................................323.2 DYNAMIC SOFTWARE DEVELOPMENT METHOD (DSDM).......................333.2.1 Les origines de DSDM ..........................................................................333.2.2 9 principes fondamentaux....................................................................333.2.3 5 phases...................................................................................................353.2.4 Les rôles ..................................................................................................383.2.5 Forces et faiblesses de la méthode.....................................................413.3 ADAPTIVE SOFTWARE DEVELOPMENT........................................................41
  2. 2. Page 3/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.13.3.1 Contexte...................................................................................................413.3.2 Les 6 caractéristiques principales dASD..........................................413.3.3 Le cycle de vie selon Adaptive Software Development...................433.3.4 Forces et faiblesses ...............................................................................453.4 CRYSTAL METHODOLOGIES...........................................................................453.4.1 Origine.....................................................................................................453.4.2 Les valeurs partagées par léquipe.....................................................463.4.3 Processus Crystal..................................................................................473.4.4 Forces et faiblesses ...............................................................................483.5 SCRUM..............................................................................................................493.5.1 Les origines de Scrum...........................................................................493.5.2 Le processus Scrum : vue générale....................................................493.5.3 Les "sprints" ...........................................................................................513.5.4 Forces et faiblesses ...............................................................................533.6 FEATURE DRIVEN DEVELOPMENT ...............................................................543.6.1 Les grandes lignes de la méthode.......................................................543.6.2 La notion de "feature" et de "feature set".........................................543.6.3 Les 5 phases dun projet FDD .............................................................553.6.4 Forces et faiblesses ...............................................................................603.7 RECAPITULATIF : COMPARATIF DES METHODES AGILES...........................603.7.1 Adaptation des méthodes à la taille des projets et des équipes.....603.7.2 Degré dexigence des méthodes agiles pour le client......................623.7.3 Facilité de mise en œuvre et contraintes en interne ........................634. LES METHODES AGILES VUES PAR BUSINESS INTERACTIF664.1 LES METHODES AGILES SONT ELLES VRAIMENT NOUVELLES ?................664.2 LA BONNE METHODE POUR LE BON PROJET ................................................664.2.1 Un exemple : la modélisation de données.........................................674.3 QUELLES SONT LES MAUVAISES METHODES ?............................................674.4 QUELQUES POINTS CLES CROSS METHODES...............................................674.4.1 Petites équipes et outils véloces..........................................................674.4.2 Polyvalence des développeurs.............................................................684.4.3 Feedback client et itérations................................................................684.4.4 Gestion des risques................................................................................684.4.5 Maîtrise d’ouvrage et maîtrise d’œuvre jouent dans le même camp684.4.6 Tester toujours et encore......................................................................694.5 LA CULTURE ET LES VALEURS......................................................................704.5.1 La culture de l’humilité........................................................................704.5.2 Le pragmatisme......................................................................................704.5.3 Le souci de la qualité............................................................................704.5.4 Le partage...............................................................................................704.5.5 Le courage..............................................................................................714.6 CONCLUSION...................................................................................................714.7 CHOISIR ET METTRE EN ŒUVRE LES METHODES.........................................724.8 COLLABORER AVEC BUSINESS INTERACTIF................................................72Les noms de produits ou de sociétés cités dans ce document peuvent faire l’objet d’un dépôt de marque par leurpropriétaires respectifs.
  3. 3. Page 4/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Nous sommes heureux de vous présenter notrenouveau white paper sur les méthodes agiles degestion de projet et de développement, ExtremeProgramming étant probablement la plus connue deces méthodes. Dans un contexte économique plustendu, le succès des projets informatiques devienttoujours plus critique. La démarche méthodologiqueadoptée joue pour beaucoup dans le succès de cesprojets. Les méthodes agiles constituent elles lenouvel eldorado ? Business Interactif fait le point surle sujet…Business Interactif en quelques motsBusiness Interactif conçoit et réalise de grands projets e-business à fortecomposante technologique, couvrant les aspects front, middle et back-office.Avec plus de 220 collaborateurs, dont 60% sur les aspects technologiques,Business Interactif accompagne ses clients sur des projets stratégiques enFrance et à l’étranger (Bureaux à Paris, Lyon, New-York, Tokyo et Rio).Deux références symbolisent à elles seules l’étendue du savoir-faire de Bu-siness Interactif : OOSHOP.COM d’un côté (réalisation de l’ensemble duprojet, tant sur les aspects Front que Middle et Back-Office),LANCOME.COM de l’autre. Que ce soit pour des projets à haute technicitéou nécessitant une valeur ajoutée marketing et créatrice hors-pair, BusinessInteractif s’est peu à peu imposé comme l’un des acteurs clé sur le marchéde l’e-business. Pour plus de renseignements, nous vous invitons à consulternotre site : www.businessinteractif.frPourquoi un white paper sur les méthodes agiles?Au cours des huit dernières années, nos équipes ont contribué à la réussitede grands projets E-business, dans une logique de maîtrise d’œuvre. L’unedes étapes clé dans le développement de notre société a été la mise enœuvre d’un Plan Assurance Qualité permettant d’offrir à nos clients un hautniveau de service. La gestion d’un projet et les méthodes de développementoptimales sont des préoccupations récurrentes dans notre métier. Nosgrands projets sont réalisés en s’appuyant sur des méthodes éprouvées,tirées notamment de Merise pour la conception des modèles de données, deRAD pour la gestion de projet et le maquettage, d’UML pour la conceptionobjets/composants. Nous avons au fil des années tiré le meilleur de ces diffé-rentes approches pour les adapter au contexte des projets e-business.La montée en puissance de méthodes dites «nouvelles », les méthodesagiles, ne pouvait nous laisser insensibles. A ce titre, comme nous l’avionsfait pour le Knowledge Management, il nous a paru intéressant de faire par-tager par le biais d’un White Paper notre vision de ce sujet : cartographie desméthodes, mais aussi retours d’expérience!Jean-Louis Bénard, directeur technique de Business Interactif.1. INTRODUCTION
  4. 4. Page 5/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.12.1 CONTEXTELes méthodes de gestion de projet informatique connaissent, au même titreque les technologies mises en œuvre, une remise en cause permanente.La proportion importante d’échec des projets vient souvent alimenter desréactions plus ou moins constructives aux méthodes mises en œuvre. Lesévolutions des architectures technologiques et des outils de développement ycontribuent également pour part importante.Ainsi, UML et Unified Process sont venues en réaction aux méthodes dites« merisiennes » (cycle en V, etc.) à la fois poussées par les technologiesobjet et les insuffisances de méthodes préconisant des cycles très longs.Les méthodes agiles n’échappent pas à la règle. Mais elles s’inscrivent dansune démarche plus radicale, que l’on pourrait résumer par «trop de méthodetue la méthode ».De manière générale, leur but est daugmenter le niveau de satisfaction desclients tout en rendant le travail de développement plus facile. Mais les véri-tables fondements des méthodes agiles résident plus précisément dans deuxcaractéristiques :— Les méthodes agiles sont "adaptatives" plutôt que prédictivesSi les méthodes lourdes tentent d’établir dès le début d’un projet un planningà la fois très précis et très détaillé du développement sur une longue périodede temps, cela suppose que les exigences et spécifications de base restentimmuables. Or, dans tous les projets, les exigences changent au cours dutemps et le contexte évolue aussi. Par conséquent, si elles fonctionnent surdes projets courts et de petite taille, ces méthodologies sont trop réfractairesau changement pour pourvoir être appliquées à des projets plus importants.A l’inverse, les méthodes agiles se proposent de réserver un accueil favora-ble au changement : ce sont des méthodes itératives à planification souplequi leur permettent de s’adapter à la fois aux changements de contexte et despécifications du projet.— Les méthodes agiles sont orientées vers les personnes plutôt que versles processusLes méthodes agiles s’efforcent de travailler avec les spécificités de chacunplutôt que contre la nature de chacun pour que le développement soit uneactivité plaisante où chacun se voit confier une part de responsabilité.Nées en réaction aux méthodes traditionnelles, il existe une grande diversitéde méthodes auxquelles ont peut donner le qualificatif d’agile. Avant de pas-ser en revue les spécificités de chacune parmi les principales d’entre ellesdans une seconde partie, essayons tout d’abord de dégager les principalescaractéristiques communes à toutes ces méthodes, autrement dit : qu’est cequi fait qu’une méthode de développement est une méthode agile ?2.2 CARACTERISTIQUESCOMMUNES DES METHODES AGILESTrès récemment, en février 2001, les instigateurs des principales méthodesagiles se sont réunis pour former l’ "Agile Alliance" (http://agilealliance.org).Ensemble, ils ont pu dégager des principes fondamentaux sur lesquels2. LESMETHODOLOGIESAGILES :GENERALITES
  5. 5. Page 6/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1s’appuyer pour que le développement puisse se faire rapidement et s’adapterau changement.Leur travail a abouti au "Manifeste pour le développement agiled’applications" :Manifesto for Agile Software DevelopmentWe are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items onthe right, we value the items on the left more.Ce manifeste, comme on peut le voir, comporte quatre valeurs principa-les détaillées ci-dessous.Les paragraphes suivants ont pour objet de présenter les méthodes agiles,telles qu’elles ont été conçues par les membres de l’Agile Alliance, ils netraduisent pas spécifiquement la position de Business Interactif sur lesujet.2.2.1 Priorité aux personnes et aux interactions sur les procédures etles outilsLa meilleure garantie de succès réside dans les personnes : même unebonne méthode, de bonnes procédures ne sauveront pas un projet del’échec si l’équipe n’est pas constituée de personnes adéquates et ouvertes.Par contre, une mauvaise méthode peut conduire une équipe parfaite àl’échec. Pour constituer une équipe, pas besoin de génies du développe-ment : un programmeur moyen, mais doué de capacités à travailler engroupe et à communiquer est un bien meilleur équipier.La gestion de projet a longtemps établi la «méthode » comme le vecteuressentiel de succès d’un projet. Cette méthode a souvent pris la forme deprocédures. L’importance accordée aux outils supports de la gestion de pro-jets s’est également renforcée au détriment de l’individu.Utiliser les outils appropriés (compilateurs, environnements de développe-ment, outils de modélisation, etc.) peut être décisif. En revanche, l’utilisationd’outils surdimensionnés ou faisant de l’homme un simple instrument de ladémarche est aussi néfaste que le manque d’outils appropriés.Opposés à une approche trop outillée, les membres de l’AgileAlliance affir-ment que la meilleure garantie de succès réside dans les personnes : mêmeune bonne méthode, de bonnes procédures ne sauveront pas un projet de
  6. 6. Page 7/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1l’échec si l’équipe n’est pas constituée de personnes très impliquées dans leprojet. Pour constituer une équipe, pas besoin de génies du développement :un programmeur moyen, mais doué de capacités à travailler en groupe et àcommuniquer est un bien meilleur équipier. Ce sont avant tout les interac-tions, les initiatives et la communication interpersonnelles qui feront le suc-cès.2.2.2 Priorité aux applications fonctionnelles sur une documentationpléthoriqueLes partisans des méthodes agiles affirment la légitimité d’une certaine formede documentation mais ils dénoncent les effets pervers d’une documentationpléthorique. En effet, l’écriture et le maintien à niveau de la documentationsont extrêmement consommateurs de ressources. Un document qui n’estpas mis à jour régulièrement devient très rapidement totalement inutile, voiremême trompeur. Le manifeste est donc favorable aux documentations suc-cinctes, ne décrivant que les grandes lignes de l’architecture du systèmemais régulièrement tenues à jour, et d’une documentation permanente ducode lui-même. Le meilleur transfert des connaissances sur le systèmes’effectue de toute manière par la participation au travail de l’équipe.2.2.3 Priorité de la collaboration avec le client sur la négociation decontratLe succès d’un projet requiert un feedback régulier et fréquent de la part duclient. Un contrat qui spécifie les exigences, le planning et le coût d’un projeta priori relève d’une vision utopique d’une projet informatique. La meilleuremanière de procéder pour le client est de travailler en étroite collaborationavec l’équipe de développement, pour lui fournir un feedback continu quiassure un meilleur contrôle du projet. Ainsi, des modifications de spécifica-tions peuvent intervenir très tard dans le cycle de développement du projet.C’est en définitive une solution répondant réellement aux attentes du clientqui est réalisée et non une solution répondant aux exigences d’un contratétabli a priori. Nous le verrons en synthèse, ce point ne reste pas simple àmettre en œuvre. Cela nécessite bien sûr une grande maturité du client et duprestataire de service afin d’établir une réelle relation de confiance, ainsiqu’une bonne compréhension de la réalité opérationnelle du projet par lesjuristes en charge du dossier.2.2.4 Priorité de l’acceptation du changement sur la planificationC’est la capacité à accepter le changement qui fait bien souvent la réussiteou l’échec d’un projet. Lors de la planification, il est donc nécessaire de veil-ler à ce que le planning soit flexible et adaptable aux changements qui peu-vent intervenir dans le contexte, les technologies et les spécifications.En effet il est très difficile de penser dès le début à toutes les fonctionnalitésdont on aimerait disposer et il est très probable que le client modifie ses exi-gences une fois qu’il aura vu fonctionner une première version du système.
  7. 7. Page 8/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Figure 1 - Positionnement des méthodes par rapport aux quatre critèresagilesLes quatre valeurs ci-dessus sont en fait déclinées sur douze principes plusgénéraux qui caractérisent en détail les méthodes agiles :— "Notre priorité est de satisfaire le client en lui livrant très tôt et régulière-ment des versions fonctionnelles de l’application source de valeur"Les méthodes agiles recommandent de livrer très tôt, dans les premièressemaines si possible une version rudimentaire de l’application puis de livrersouvent des versions auxquelles les fonctionnalités s’ajoutent progressive-ment. De cette manière, le client peut décider à tout moment la mise en pro-duction de l’application, dès qu’il la considère comme assez fonctionnelle. Achaque version (release), un feedback de la part du client est nécessairepour permettre soit de continuer le développement comme prévu, soitd’opérer des changements. De cette manière, les changements dans lesspécifications interviennent tôt dans le processus de développement et sontmoins problématiques.— "Accueillir le changement à bras ouverts, même tard dans le processusde développement. Les méthodologies agiles exploitent les change-ments pour apporter au client un avantage concurrentiel"Ceci est un état d’esprit nécessaire : tout changement des exigences doitêtre perçu comme une bonne chose car cela signifie que l’équipe a compriset appris comment satisfaire encore mieux la demande.Le but des méthodes agiles est de produire des systèmes très flexibles, desorte que l’impact sur le système d’une évolution des spécification resteminimal.Ressourceshumaines etcommunicationProcessuset outilsApplicationsfonctionnellesDocumentationCollaborationétroite avec leclientNégociationde contratAccueil duchangementPlanificationrigide
  8. 8. Page 9/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1— "Livrer le plus souvent possible des versions opérationnelles del’application, avec une fréquence comprise entre deux semaines et deuxmois"Ne pas se contenter de livrer des liasses de documents décrivantl’application : il faut constamment garder pour objectif de livrer le plus rapi-dement possible au client une solution qui satisfasse ses besoins.— "Clients et développeurs doivent coopérer quotidiennement tout au longdu projet"Pour qu’un projet puisse être considéré comme agile, il faut qu’il y ait uneinteraction permanente entre le client, les développeurs : c’est ce qui guidecontinuellement le projet.— "Construire des projets autour d’individus motivés. Leur donnerl’environnement et le support dont ils ont besoin et leur faire confiancepour remplir leur mission"Dans un projet agile, les personnes sont considérées comme le facteur cléde succès. Tous les autres facteurs, processus, environnement, manage-ment sont susceptibles d’être changés s’ils s’avèrent être une entrave au bonfonctionnement de l’équipe.— "La méthode la plus efficace de communiquer des informations à uneéquipe et à l’intérieur de celle-ci reste la conversation en face à face"Le mode de communication par défaut au sein d’une équipe agile est laconversation et non l’écrit. Des documents peuvent bien sûr être rédigésmais ils n’ont en aucun cas pour but de consigner par écrit la totalité desinformations relatives au projet. Même les spécifications peuvent très bien nepas être écrites de manière formelle.— "Le fonctionnement de l’application est le premier indicateurd’avancement du projet"Contrairement à d’autres méthodes, l’avancement du projet ne se mesurepas à la quantité de documentation rédigée ni en terme de phase dans la-quelle il se trouve mais bien en terme de pourcentage de fonctionnalitéseffectivement mises en place.— "Les méthodes agiles recommandent que le projet avance à un rythmesoutenable : développeurs et utilisateurs devraient pouvoir maintenir unrythme constant indéfiniment"Il ne s’agit pas de sprinter sur 100 mètres, mais plutôt de tenir la distance surun marathon : l’équipe se doit donc d’adapter son rythme pour préserver laqualité de son travail sur toute la durée du projet.— "Porter une attention continue à l’excellence technique et à la conceptionaméliore l’agilité"La meilleure façon de développer rapidement est de maintenir le code sourcede l’application aussi propre et robuste que possible. Les membres del’équipe doivent donc s’efforcer de produire le code le plus clair et le pluspropre possible. Ils sont invités à nettoyer chaque jour le code qu’ils ont écrit.— "La simplicité – art de maximiser la quantité de travail à ne pas faire – estessentielle"
  9. 9. Page 10/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Rien ne sert d’essayer d’anticiper les besoins de demain. Au contraire, il fautconstruire le système le plus simple répondant aux besoins actuels pour quecelui-ci soit facilement adaptable dans le futur.— "Les meilleures architectures, spécifications et conceptions sont le fruitd’équipes qui s’auto organisent"Les responsabilités ne sont pas confiées à quelqu’un en particulier mais àl’équipe dans son intégralité. Les membres de l’équipe prennent ensuite leursresponsabilités et se partagent les tâches sur le principe du volontariat.— "A intervalles de temps réguliers, l’ensemble de l’équipe s’interroge surla manière de devenir encore plus efficace, puis ajuste son comporte-ment en conséquence"Une équipe agile est consciente que son environnement est en perpétuelleévolution. C’est pourquoi elle ajuste continuellement son organisation, sesrègles, son fonctionnement, etc. de manière à rester agile.2.3 DESMETHODESRAD(RAPID APPLICATIONDEVELOPMENT) AUX METHODES AGILES, UNE FILIATION ?2.3.1 Origines du RADLe RAD (Rapid Application Development) est né dans les années 80 à lasuite dun double constat. Dune part, le manque de concertation entre lesinformaticiens en charge de la réalisation dun projet et les utilisateursconduit souvent à la réalisation dapplications mal adaptées aux besoins.Dautre part les méthodes classiques de conduite de projet sont inadaptées àla vitesse des évolutions technologiques et la durée des projets est beaucouptrop longue.Les objectifs premiers du RAD sont de conduire à lamélioration de la qualitédes développements tout en réduisant les délais et en facilitant la maîtrisedes coûts. Pour cela, il est nécessaire dassocier méthodologie et relationshumaines. Le RAD est fondamentalement une méthode basée sur la com-munication.Les concepts du RAD ont été définis par James Martin avant dêtre repris etadaptés au contexte français par Jean Pierre Vickoff dès 1989.A ses début, le RAD a souvent été qualifié de "chaotique" et considérécomme une "absence de méthode" plutôt que comme une méthode. Si leRAD a souffert dune si mauvaise image, cest avant tout lié à la notion derapidité quon a souvent tendance à considérer, à tort, comme incompatibleavec celle de qualité. Pour éviter ce malentendu, Jean Pierre Vickoff proposede traduire RAD par "développement maîtrisé dapplications de qualité ap-prouvée par les utilisateurs".2.3.2 Les acteurs du RADDans un projet RAD, la répartition des rôles est très structurée. Comme dansune approche classique, lensemble de lorganisation sappuie sur un principefondamental : la séparation des rôles opérationnels et des responsabilitésentre dune part la maîtrise douvrage (MOA) qui représente lutilisateur et àce titre détermine les fonctionnalités à développer et leur degré de priorité et
  10. 10. Page 11/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1dautre part la maîtrise dœuvre (MOE) qui apporte les solutions techniquesaux problèmes posés par la maîtrise douvrage. (Cette séparation des rôlesest encore renforcée par la présence du Groupe danimation et de RapportRAD qui se charge dorganiser la communication du projet. Son rôle principalest de faciliter lexpression des exigences et de les formaliser en temps réel.La maîtrise douvrageLa maîtrise douvrage a trois responsabilités principales :— Définir les objectifs et les exigences du système : le maître douvrage,qui préside le comité de pilotage est responsable de la rédaction de do-cuments de cadrage dans lesquels sont explicités les objectifs dordrestratégique, fonctionnel, technologique, organisationnel, ainsi que lescontraintes de projet. Ces objectifs, classés par ordre de priorité serventde base pour la prise de décisions de pilotage. Le maître douvrage spé-cifie aussi les exigences en déléguant leur mise en forme à diverses per-sonnes compétentes : par exemple, les exigences fonctionnelles sontexprimées par des représentants dutilisateurs et des experts fonction-nels.— Valider les solutions proposées et élaborées : en collaboration avec lespersonnes qui ont exprimé les exigences, le maître douvrage vérifie quela ou les solutions proposées par la maîtrise dœuvre permettent bien desatisfaire ces exigences.— Préparer et piloter le changement induit : il sagit là dopérations desensibilisation, formation, communication ainsi que dorganisation.Au sein de la maîtrise douvrage, on peut distinguer trois acteurs principaux :— Maître douvrage : prend des décisions sur les objectifs (produit, coût,délai) et les orientations du projet et décide in fine lexpression des exi-gences et la validation des solutions ainsi que les moyens à mettre enœuvre au sein de la maîtrise douvrage.— Coordinateur de Projet Utilisateurs ou Maître dOuvrage délégué : coor-donne et valide les activités de la maîtrise douvrage. Réalise le suivi desobjectifs (produits, coûts / charges, délais) et des activités de la maîtrisedouvrage.— Responsable de la cohérence et de la qualité fonctionnelle : superviselexpression des exigences et de la validation des solutions, contrôle lacohérence des décisions prises dans les domaines fonctionnels. Super-vise la vérification de la qualité fonctionnelle (point de vue utilisateurs)des solutions proposées et élaborées.La maîtrise dœuvreElle a également trois responsabilités principales :— Proposer et réaliser la solution : cela passe notamment par la définitionet la mise en œuvre du planning et des moyens humains et logistiquesnécessaires— Livrer des "fonctionnalités" : on entend par fonctionnalités les produitsfinis mais aussi des produits intermédiaires et diverses informations qui
  11. 11. Page 12/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1permettront à la maîtrise douvrage de préparer et de piloter le change-ment. Les dates de fourniture de ces différents livrables figurent au plan-ning.— Respecter les directives du Plan dAssurance Qualité : en même tempsque la réalisation de lapplication, la maîtrise dœuvre réalise son suivisur des critères tels que les fonctionnalités, la qualité, le planning, lescoûts, la visibilité.Au sein de la maîtrise dœuvre, on peut distinguer trois acteurs principaux :— Maître dœuvre : propose des objectifs (coût, délai en particulier) et desorientations pour le projet. Décide in fine les propositions de solution etles solutions elles-mêmes qui seront élaborées. Décide des moyens etméthodes à mettre en œuvre au sein de la MOE. Se coordonne avec lesMOE des autres projets et les sociétés extérieures participant à la MOEdu projet— Pilote de Projet Informatique : coordonne les travaux de la MOE. Valideles propositions de solution et les solutions elles-mêmes élaborées par laMOE. Estime et met en œuvre les moyens MOE (planning de production,méthodes et outils)— Responsable par domaine : pilote et suit léquipe de production dundomaine.Le Groupe danimation et de Rapport RADLe groupe danimation et de rapport (GAR) a pour responsabilités la prépara-tion des réunions (convocation, logistique et suivi), lorganisation des séan-ces de travail, la formalisation des exigences exprimées, la gestion descomptes-rendus, la planification et lanimation des focus.Lanimateur doit adopter une attitude directive sur la forme et non directivesur le fond. Il se garde démettre un avis personnel, de porter un jugement etde favoriser des opinions. Il najoute rien au discours des participants et secontente de maintenir les discussions bien centrées sur le thème voulu et decanaliser les entretiens. Pour cela, il peut procéder par exemple par synthèse(résumer lessentiel en le reformulant) ou par élucidation (forcer les gens, parle biais de questions, à aller jusquau bout dune idée).Le rapporteur doit être capable de produire une documentation automatiséeet de la maintenir à jour. Cest tout dabord un analyste concepteur, spécia-lement formé aux AGL (Ateliers de génie Logiciel). Lors des réunions portantsur la conception du système, il doit être capable de le modéliser en direct. Ilest aussi responsable de la synthèse des comptes-rendus de réunion.
  12. 12. Page 13/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Figure 2 - Les acteurs du RAD2.3.3 Les cinq phases dun projet RADInitialisation (préparation de l’organisation et communication )Cette phase, qui représente environ 5% du projet, définit le périmètre généraldu projet, établit la structure du travail par thèmes, recense les acteurs perti-nents et amorce la dynamique du projet.Cadrage (analyse et expression des exigences)Cest aux utilisateurs de spécifier leurs exigences et dexprimer leurs besoinslors d’entretiens de groupe. Il est généralement prévu de 2 à 5 jours de ses-sions par commission (thème). Cette phase représente environ 10% du pro-jet.Design (conception et modélisation)Les utilisateurs participent à l’affinage et à la validation des modèles organi-sationnels : flux, traitements, données. Ils valident également un premierprototype ayant pour but de présenter l’ergonomie et la cinématique généralede l’application. 4 à 8 jours de sessions sont prévus par commission. Cettephase représente environ 25% du projet.Construction (réalisation, prototypage)Durant cette phase, l’équipe RAD (SWAT) construit au cours de plusieurssessions itératives l’application module par module. L’utilisateur participetoujours activement aux spécifications détaillées et à la validation des proto-types. Cette phase représente environ 50% du projet.Maîtrise d’ouvrage• Définit les objectifs et exigences du système• Valide le solutions proposées et élaborées• Prépare et pilote le changementMaîtrise d’œuvre• Propose et réalise la solution• Livre des « fonctionnalités»• respecte les directives du Pland’Assurance QualitéGroupe d’animation et de Rapport RADAnimateur• Provoque et conduit les réunions• N’émet pas d’avis personnel• Recadre les discussions• Synthétise et formaliseRapporteur• Produit une documentationautomatisée• Modélise le système en direct lors desréunions de conception• Rédige les comptes-rendus
  13. 13. Page 14/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Finalisation (recette et déploiement)Cette phase, qui représente environ 10% du projet permet une livraison glo-bale et le transfert du système en exploitation et maintenance.Figure 3 - Cycle de vie d’un projet RAD2.3.4 RAD et modélisationSil se veut efficace, le RAD se doit dêtre rapide et donc dutiliser des techni-ques de modélisation rigoureuses mais simplifiées. Le RAD ne préconise pasde technique de modélisation particulière : il est tout à fait possible dutiliserdes modèles objets comme UML ou des modèles de Merise, à condition deles alléger pour nen conserver que ce qui est strictement indispensable.Dans le cadre dune approche "classique" par le haut de type merisienne,tous les modèle dabstraction merisiens ne sont pas utilisés. Dans le casgénéral, ne sont conservés que le modèle de Contexte (MC), le modèleConceptuel de Communication (MCC), la hiérarchie de fonctions (ou MCT),le modèle Conceptuel de Données (MCD), et le modèle Organisationnel deTraitements (MOT).Dans le cas d’un développement orienté objet, il est préconisé d’employer lanotation ULM. Les principaux modèles sont les suivants : modèle de Classes,modèle d’Etat, modèle des Cas d’utilisation, modèle des Interactions, modèlede Réalisation, modèle de Déploiement.2.3.5 Pourquoi le RAD nest il pas à proprement parler une méthode"agile" ?Essayons dexaminer la méthode RAD à la lumière des quatre critères quifont quune méthode est agile ou ne lest pas.Le RAD met bien en avant les ressources humaines et la communication parrapport au côté procédurier, notamment grâce à lexistence du groupe dani-mation et de rapport qui a pour rôle de faciliter la communication entre lamaîtrise dœuvre et la maîtrise douvrage.InitialisationFinalisationCadrageDesignConstructionConstructionDesignConstructionConstruction6 % 9 % 23 % 50 % 12 %• Préparation del’organisation• Communication• Expression desexigences•Analyse• Conception• Modélisation• Réalisation• Prototypage• Constructionitérative• Recette•Déploiement
  14. 14. Page 15/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Le RAD privilégie la production dapplications fonctionnelles par rapport àlécriture massive de documentation.Le RAD implique une collaboration étroite avec le client. Dans un processusRAD, le client est un acteur clé (maîtrise douvrage).Par contre, le dernier critère des méthodes agiles nest pas véritablementrempli par le RAD. En effet, un projet RAD nest pas conçu pour faire preuvedune grande flexibilité par rapport au changement. Au contraire, le RAD seplace plutôt du côté de la planification rigide.Le RAD présente donc trois des quatre caractéristiques des méthodes agiles.Cest donc une méthode proche des méthodes agiles sans pour autant enfaire véritablement partie.2.4 DE UNIFIED PROCESS (UP & RUP) A L’AGILITE,UNEFILIATION?2.4.1 Les 5 principes dUPUP est une méthode générique de développement de logiciels. Cette mé-thode nécessite donc dêtre adaptée à chacun des projets pour lesquels ellesera employée.UP présente sept caractéristiques essentielles, les trois premières étant troiscritères préconisés par UML (Unified Modeling Language) :UP est pilotée par les cas dutilisationLes cas dutilisation (« Use Cases ») sont les véritables pilotes du projet,quelle que soit lactivité et quelle que soit la phase. En effet, le système esttout dabord analysé, conçu et développé pour des utilisateurs. Le systèmene peut pas être développé par des informaticiens nayant aucune idée de ceque sont le métier et lenvironnement des utilisateurs : tout doit donc être faiten adoptant le point de vue utilisateur. Les cas dutilisation sont loutil demodélisation des besoins en termes de fonctionnalités : cest sous cetteforme que sont exprimées les exigences. Les cas dutilisation servent ausside base pour lanalyse, le modèle logique, ainsi que de base pour les testsfonctionnels.UP est centrée sur larchitectureUP se soucie très tôt de larchitecture dans le cycle de vie dune application.Larchitecture du système est décrite à laide de différentes vues. Alors queles modèles cas dutilisation, analyse, conception, implémentation, déploie-ment, sont complets et exhaustifs, les vues définies par larchitecte ne re-prennent que les éléments significatifs. Larchitecte procède de manière in-crémentale : il commence par définir une architecture simplifiée qui répondaux besoins classés comme prioritaires avant de définir à partir de là lessous-systèmes de manière beaucoup plus précise.UP est itérative et incrémentale
  15. 15. Page 16/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1UP procède par itérations par opposition aux méthodes en cascade qui sontplus coûteuses et ne permettent pas une bonne gestion du risque. De plus, ilest toujours difficile de corriger à la fin une erreur commise au début dunprojet. En procédant de manière itérative, il est possible de découvrir leserreurs et les incompréhensions plus tôt. Le feedback de lutilisateur estaussi encouragé et les tests effectués à chaque utilisation permettent davoirune vision plus objective de lavancement du projet. Enfin, le travail itératifpermet à léquipe de capitaliser à chaque cycle les enseignements du cycleprécédent.Figure 4 - UP est une méthode itérative et incrémentaleUP gère les besoins et les exigencesLes exigences du client changent au cours du projet. UP recommande dedécouvrir les besoins, de les organiser et de les documenter de manière àavoir une approche disciplinée de létude des exigences et de pouvoir lesfiltrer, les trier par propriété et réaliser leur suivi pour pouvoir estimer de ma-nière objective les fonctionnalités et les performances du système à dévelop-per.UP est fondée sur la production de composantsUP recommande de structurer larchitecture à base de composants (COM,CORBA, EJB, etc.). Les architectures ainsi construites sont de fait plus ro-bustes et modulaires. De plus, cette approche permet la réutilisation decomposants existants si ceux-ci ont été développés de manière assezgénérique. Enfin, la visualisation à laide des outils de modélisation est facileet automatique.UP pratique la modélisation visuelleUP préconise la modélisation visuelle du système. Un modèle est une simpli-fication de la réalité qui décrit le système selon un certain point de vue. Lamodélisation sous différents points de vue permet une meilleure compréhen-sion et une compréhension globale du système à concevoir. Lutilisation dou-Planning initialPlanningExigencesAnalyse et ConceptionImplémentationTestsÉvaluation Déploiement
  16. 16. Page 17/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1tils visuels augmente encore les capacités de léquipe à gérer la complexitédes systèmes.Figure 5 - Modélisation visuelle selon différentes vuesUP se soucie en permanence de la qualitéPartant du constat que le coût de lacorrection des erreurs augmente expo-nentiellement au fur et à mesure delavancement du projet, il est absolu-ment nécessaire davoir un contrôlepermanent et rigoureux des fonctionna-lités, de la fiabilité, des performancesde lapplication et des performances dusystème. Pour cela, une automatisationdes tests tout au long du cycle de vie simpose. Ainsi, les défauts sont détec-tés très rapidement et le coût de leur correction est minimisé, lestimation delétat davancement du projet est plus objective et la qualité et les performan-ces des parties "à risque" est améliorée.UP gère les risques de façon systématique et permanenteLa phase de pré-étude a pour but didentifier les risques qui pourraient mettrele projet en péril. Tout au long du projet, il est recommandé de maintenir uneliste de risques, issus de la phase de pré-étude, classés selon leur dangerpour léquipe afin davoir une vue plus explicite des choses.2.4.2 Les activités dans la méthode UPUP définit les activités essentielles et propose, pour chacune dentre elles,une liste dintervenants (architecte, analyste...) et une liste de travaux asso-ciés.Diagrammesde composantsDiagrammesde scénarioDiagrammesd’étatDiagrammesde classesDiagrammede déploiementDiagrammesde casd’utilisationModèleAvancement du projetCoût de la correctiondes erreurs
  17. 17. Page 18/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Expression des besoinsUP distingue deux types de modèles : "Domain Model" et "Business Model".Le modèle de domaine ne dépend pas de lapplication : il a pour but dap-prendre un domaine, un métier jusque là méconnu. Le modèle "business"est plutôt une modélisation des procédures en vigueur dans lentreprise etsintéresse directement aux collaborateur et à leurs divers travaux. Cest àpartir de ce modèle que peut alors démarrer lanalyse des cas dutilisation dusystème. Il sagit de mieux connaître le domaine et ses activités avant desintéresser aux fonctionnalités du système par une étude par les cas dutili-sation.AnalyseComprendre et de structurer le logiciel à développer sont les objectifs delanalyse. On construit dans cette activité une représentation interne quasi-idéale du système, sans trop tenir comte des exigences et contraintes deconception. Lanalyse utilise le langage du développeur alors que lexpres-sion des besoins se fait du point de vue utilisateur.ConceptionLa conception consiste à définir larchitecture du système. La conceptionnest non pas une phase du process UP mais une activité qui trouve sa placedans toutes les phases. La conception est ainsi réalisée de manière incré-mentale. Dans une phase de pré-étude elle consiste par exemple à maquet-ter larchitecture, tandis quen phase de construction la conception de gros-sière devient beaucoup plus détaillée. Si lanalyse est une vue purementlogique, la conception est plus physique et se soucie des contraintes quelanalyse avait laissées de côté.Implémentation et TestCette activité consiste à créer à proprement parler les divers composants :sources, scripts, puis exécutables... Les tests se basent sur les cas dutilisa-tion.2.4.3 Les phases du cycle de vieEtude dopportunitéCest durant cette phase quil faut se poser la question de la faisabilité duprojet, des frontières du système, des risques majeurs qui pourraient mettreen péril le projet. A la fin de cette phase, est établi un document donnant unevision globale des principales exigences, des fonctionnalités clés et descontraintes majeures. Environ 10 % des cas dutilisation sont connus à lissuede cette phase. Il convient aussi détablir une estimation initiale des risques,un "Project Plan", un "Business Model".ElaborationCette phase a pour but de préciser larchitecture. A ce stade, 80 % des casdutilisation sont obtenus. Cette phase permet aussi de connaître des exi-
  18. 18. Page 19/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1gences supplémentaires, en particulier des exigences non fonctionnelles, dedécrire larchitecture du système, de le prototyper, de réviser la liste desrisques et de mettre en place un plan de développement. En théorie, cest àce stade quon est à même de faire une offre de réalisation du système.ConstructionLobjectif est de fournir une version beta de la release en cours de dévelop-pement ainsi quune version du manuel utilisateur.TransitionCette phase a pour objectif de peaufiner le système et de corriger les der-niers bugs pour pouvoir passer de la version beta au déploiement sur len-semble des sites. Comme le nom de la phase lindique, il sagit aussi de pré-parer la release suivante et de boucler le cycle soit sur une nouvelle étudedopportunité soit une élaboration ou construction.Figure 6 - Importance des activités au cours des différentes phasesDaprès Rational Software Corporation2.4.4 Pourquoi UP nest pasà proprement parler une méthode agile ?Comme nous lavons fait pour le RAD, positionnons UP par rapport aux qua-tre critères dagilité.UP sefforce de produire des applications fonctionnelles et surtout en coïnci-dence avec les besoins exprimés par le client. Cette caractéristique vient dufait qu UP est pilotée par les cas dutilisation.phasesactivitésEtuded’opportunitéElaboration Construction TransitionEtude du businessExpression des besoinsAnalyse et ConceptionImplémentationTestsDéploiementitérations
  19. 19. Page 20/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1UP insiste sur la nécessité dune collaboration étroite avec le client. Lexpres-sion des besoins se fait en début de projet, mais à chaque itération, la phasede transition permet un retour du client sur ce qui est fait.UP fait aussi un premier pas vers des méthodes souples par rapport auchangement.En revanche, la méthode UP reste très procédurière. De plus UP sancre trèsfortement sur la modélisation UML et ses outils. Cette modélisation parfoisqualifiée de "modélisation à outrance" a tendance à alourdir quelque peu laméthode.En conséquence, UP ne remplit pas pleinement les critères dagilité tout enrestant très proche dune méthode agile.2.5 LASITUATIONENFRANCE : UN FORT ANCRAGE DELAMETHODEMERISEETDELAMODELISATIONENTITE-RELATIONLa conception dun système passe par une phase danalyse qui nécessitedes méthodes permettant de mettre en place un modèle du système à déve-lopper. Parmi les méthodes danalyse, Merise, qui date de la fin des annéessoixante-dix, reste très fortement implantée en France.La méthode Merise est fondée sur la séparation des données et des traite-ments à effectuer en plusieurs modèles conceptuels, logiques et physiques.La séparation des données et des traitements a pour but de donner unecertaine longévité au modèle. En effet, la structure des données na pas àêtre souvent modifiée dans le temps, tandis que les traitements le sont plusfréquemment. La méthode Merise est apparue dans les années 1978-1979, àla suite dune consultation nationale lancée en 1977 par le ministère delIndustrie. Cette consultation avait pour but de choisir des sociétés deconseil en informatique chargées de définir une méthode de conception desystèmes dinformation. Les deux principales sociétés ayant mis au pointcette méthode sont le CTI (Centre Technique dInformatique), et le CETE(Centre dEtudes Techniques de lEquipement).La démarche préconisée par Merise est la suivante :— Schéma directeur : permet de définir les objectifs du projet— Étude préalable : il sagit de référencer les moyens existants, de déter-miner les limites du système existant. Sur la base des besoins futurs,plusieurs scénarios sont proposés. A la fin de cette phase détude, unseul scénario est retenu sur des critères de coûts, limites, impacts, délaiset faisabilité)— Analyse détaillée : le premier modèle à établir est le Modèle Conceptueldes Données (MCD) basé sur une modélisation entités / relations. Aucours de cette phase, on établit aussi le Modèle Organisationnel desTraitements (MOT) puis le Modèle Logique des Données (MLD).— Analyse technique : il sagit de définir les solutions techniques retenuesen établissant le Modèle Physique des Données (MPD) et le ModèleOpérationnel des Traitements (MOPT)
  20. 20. Page 21/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Merise permet de modéliser un système selon différents degrés dabstrac-tion : le modèle conceptuel est théorique et ne se soucie pas ou peu de lim-plémentation, le modèle logique représente un choix logiciel et le modèlephysique représente un choix darchitecture.Merise, méthode vieille dune vingtaine dannées reste particulièrement bienancrée en France, notamment pour la modélisation des données. On a doncune situation un peu particulière dans lhexagone : les méthodologies plusrécentes sont en général modifiées pour pouvoir sadapter à lexistant Meriseencore très utilisé pour ses performances en matière de modélisation desdonnées.
  21. 21. Page 22/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1L’agilité comprend plusieurs courants de pensée qui ont conduit à des mé-thodologies reposant sur les mêmes concepts mais présentant chacune dessingularités. Présentant successivement Xtreme Programming, DSDM, ASD,CRYSTAL, SCRUM, FDD, cette partie se conclut par une vision de synthèsesous la forme d’une comparaison.3.1 EXTREME PROGRAMMING(XP)3.1.1 Aux origines deXtreme ProgrammingLa suppression des risques existants sur un projet représente la philosophied’XP. . En introduisant cette méthode, ses créateurs veulent en finir avec ladérive de délais, lannulation des projets, la non-qualité, la mauvaise com-préhension du métier du client et limpossibilité de suivre les changements.XP a été mis en œuvre pour la première fois en 1996 sur le projet C3, Chry-sler Comprehensive Compensation System, qui consistait à mettre en placeun nouveau système de gestion de la paie des dix mille salariés du fabricantautomobile. Sur ce projet, la méthode XP a été adoptée pour tenter de sau-ver le projet dune dérive annoncée.Les pères de la méthode, Ward Cunningham et Kent Beck définissent eX-treme Programming comme "une méthode basée sur des pratiques qui sontautant de boutons de contrôle poussés au maximum".3.1.2 Les 4 valeurs deXtreme ProgrammingXP met en avant quatre valeurs prenant en considération à la fois les enjeuxcommerciaux et les aspects humains des projets de développement dappli-cations.CommunicationLabsence de communication est certainement lun des défauts les plus gra-ves qui mettent en péril un projet. Diverses pratiques XP tendent à rendre lacommunication omniprésente entre tous les intervenants : entre dévelop-peurs (programmation en binôme), entre développeurs et managers (tests,estimations), entre développeurs et clients (tests, spécifications).Toutes ces pratiques qui forcent à communiquer ont pour but de permettre àchacun de se poser les bonnes questions et de partager linformation.SimplicitéCette valeur de simplicité repose sur le pari quil coûte moins cher de déve-lopper un système simple aujourdhui quitte à devoir engager de nouveauxfrais plus tard pour rajouter des fonctionnalités supplémentaires plutôt que deconcevoir dès le départ un système très compliqué dont on risque de navoirplus besoin dans un avenir proche. XP encourage donc à toujours sorientervers la solution la plus simple qui puisse satisfaire les besoins du client.3. PRINCIPALESMETHODOLOGIES AGILES,ETATDESLIEUX,COMPARAISON
  22. 22. Page 23/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1FeedbackLe retour est immédiat pour les développeurs grâce aux tests unitaires. Pourles clients, le retour se fait à léchelle de quelques jours grâce aux tests fonc-tionnels qui leur permettent davoir une vision permanente de létat du sys-tème.Un feedback permanent est positif pour le client qui a une bonne vision duprojet, peut détecter tout écart par rapport au planning et à ses attentes demanière à les corriger rapidement. Pour les développeurs, un feedback per-manent permet de repérer et de corriger les erreurs beaucoup plus facile-ment.Cette notion de feedback est indispensable pour que le projet puisse accueil-lir le changement.CourageDu courage est nécessaire aussi bien chez le client que chez les dévelop-peurs. Pour mener à bien un projet XP, le client doit avoir le courage de don-ner un ordre de priorité à ses exigences, de reconnaître que certains de sesbesoins ne sont pas toujours très clairs. De son côté, le développeur doitavoir le courage de modifier larchitecture même si le développement est déjàbien avancé, de jeter du code existant et daccepter quil est parfois plusrapide et efficace de réécrire une portion de code à partir de zéro plutôt quede bricoler du code existant.3.1.3 Principes de baseFeedback rapideLidée de base est issue de la psychologie de lapprentissage : plus le retoursuit de près une action, plus lapprentissage qui en résulte est important.Cest pour utiliser au mieux cette caractéristique queXtreme Programmingpréconise des itérations de courte durée et limplication forte du client. Unretour rapide pour le développeur permet une correction ou un changementde direction plus rapide et un retour rapide vers le client lui permet de testeren permanence ladéquation du système à ses besoins et au marché.Assumer la simplicitéXP recommande de traiter tous les problèmes par la solution la plus simplepossible, partant du principe quun travail propre, simple et minimal aujour-dhui est facile à améliorer par la suite.Changements incrémentauxUne série de petits changements progressifs est toujours bien plus sûre etbien plus efficace quun grand chambardement. Ceci est valable à plusieursniveaux : dans un projet XP, larchitecture et la conception changent petit àpetit, de même que le planning et la composition de léquipe.
  23. 23. Page 24/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Accueillir le changement à bras ouvertsLa meilleure stratégie est celle qui préserve le maximum doptions tout enapportant une solution aux problèmes les plus urgents.Un travail de qualitéParmi les quatre variables qui définissent un projet : taille, coûts, délais etqualité, la qualité nest pas vraiment indépendante. Pour la réussite dunprojet, la qualité ne peut qu’être "excellente" si chacun aime le travail quilfait.Apprendre à apprendrePlutôt que de s’en remettre à des théories ou des idées reçues pour répon-dre aux questions comme : quelle quantité de tests est nécessaire ? combiende temps dois-je passer à retravailler et améliorer le code que jai écrit ? etc.,mieux vaut apprendre à chacun à apprendre par soi même en fonction dechaque projet.Faible investissement au départAllouer peu de ressources à un projet au départ force les clients et les déve-loppeurs à aller à lessentiel et à dégager ce qui est réellement prioritaire etporteur de valeur.Jouer pour gagnerLétat desprit dans lequel doit se placer une équipe XP peut être comparée àcelui dune équipe de football ou de basket : jouer pour gagner et non pouréviter de perdre.Des expériences concrètesToute décision abstraite doit être testée. Dans cet ordre didée, le résultatdune séance de conception ne doit pas être un modèle finalisé un peu para-chuté, mais une série de solutions évoquées au cours de la séance.Communication ouverte et honnêteIl est essentiel que chacun puisse dire sans peur quune partie de code nestpas optimale, quil a besoin daide, etc.Travailler avec et non contre les instincts de chacunLes gens aiment réussir, apprendre, interagir avec dautres, faire partie duneéquipe, avoir le contrôle des choses. Les gens aiment quon leur fasseconfiance. Les gens aiment faire un travail de qualité et voir leurs applica-tions fonctionner. XP cherche à offrir à chacun des moyens d’exprimer cesqualités au cours du projet
  24. 24. Page 25/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Responsabilités acceptéesIl est nécessaire de donner à chacun la possibilité de prendre des responsa-bilités (par exemple, les développeurs se répartissent eux mêmes les tâchessur la base du volontariat). Cela permet déviter les frustrations dans le casoù les responsabilités sont imposées et non délibérément choisies.Adaptation aux conditions localesAdopter XP ne signifie pas prendre à lettre la méthode mais intégrer sesprincipes pour ladapter aux conditions particulières de chaque projet.Voyager légerUn développeur a tendance à transporter beaucoup de choses inutiles. Undébat est soulevé à ce sujet à propos des règles de nommage. Si certainessont utiles et même indispensables, dautres sont probablement des contrain-tes inutiles ou non respectées. Les simplifier pour ne garder que celles quisont essentielles et utilisées par tous, cest voyager plus léger.Mesures honnêtesLa volonté de contrôler le déroulement dun projet conduit a évaluer, mesurercertains paramètres. Il faut toutefois savoir rester à un niveau de détail perti-nent. Par exemple, il vaut mieux dire "cela prendra plus ou moins deux se-maines" que de dire "cela prendra 14 176 heures".3.1.4 Les 12 pratiques XPPlanning gameCette pratique a pour but de planifier uniquement les releases. La planifica-tion se fait sous forme de jeu auquel participent les développeurs et le client.Pendant une première phase dite dexploration, le client exprime ses besoinsen termes de fonctionnalités. Pour cela, il les écrit sous forme de "user sto-ries", cest à dire sous forme de courtes descriptions du comportement quilattend du système, exprimées avec un point de vue utilisateur. Au cours decette même phase, les développeurs attribuent à chaque user story un nom-bre de points, fonction du temps quils estiment nécessaire au développe-ment des fonctionnalités contenues dans chaque user story. Sil savère queles user stories nécessitent un temps de développement trop long, elles sontdécoupées en scénarios élémentaires.Dans une deuxième phase dite dengagement, les user stories sont triées enfonction de la valeur quelles apportent au client et des risques encourus lorsde leur développement. Ceci permet daboutir à un classement des userstories par ordre de priorité. En fonction de la vélocité de léquipe, les déve-loppeurs et le client sentendent sur la quantités de user stories qui serontdéveloppées au cours de litération à venir et qui constitueront la prochainerelease. La vélocité évoquée ci-dessus est un indicateur du nombre de pointsqui peuvent être développées au cours dune itération (elle se calcule enfaisant le rapport du nombre de points développés au cours de litération
  25. 25. Page 26/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1précédente et du produit du nombre de développeurs par la durée de litéra-tion).Enfin la phase de direction permet de mettre à jour le planning de la pro-chaine release.Cette pratique permet de combiner les priorités du client avec les estimationsdes développeurs afin de convenir du contenu de la prochaine release et dela date à laquelle elle devra être prête.Petites releasesPour une bonne gestion des risques, la sortie des releases doit intervenir leplus souvent possible. En conséquence, dune version à lautre, lévolutiondoit être la plus petite possible, tout en sefforçant dapporter le plus de valeurajoutée et des fonctionnalités dans leur intégralité.Utilisation de métaphoresXP recommande dutiliser des métaphores pour décrire larchitecture du sys-tème. De telles images permettent à tout le monde (y compris les commer-ciaux qui nont pas forcément de grandes compétences techniques) davoirune vision globale du système et den comprendre les éléments principauxainsi que leurs interactions.Conception simpleLa simplicité est une des valeurs fondamentales dXP. Il faut toujours déve-lopper la solution la plus simple possible et éviter de développer plus que cedont on a besoin. Ceux qui pratiquent XP résument cela sous la phraseYAGNI ("You aint gonna need it", « vous n’en aurez pas besoin »). Les seu-les exigences sont de satisfaire tous les tests, de ne jamais dupliquer unelogique et dutiliser le moins possible de classes et de méthodes.Dans ce même ordre didées, la documentation produite lors dun projet XPse réduit au minimum vital, cest à dire la documentation demandée par leclient.Tests (unitaires et fonctionnels)Les tests unitaires sont écrits et effectués par les développeurs pour vérifierle bon fonctionnement et la non régression des méthodes ou des construc-teurs. Pour une qualité de code encore meilleure, il est recommandé décrireles tests avant le code de lapplication.Les tests fonctionnels sont conçus par le client et lui permettent dune part devérifier le fonctionnement global du système, de contrôler lévolution du pro-jet, et d daffiner lexpression de ses besoins.Refactoring du codeLes développeurs dun projet XP doivent shabituer à retravailler un peu cha-que jour du code existant et fonctionnant parfaitement pour le maintenir pro-pre, le rendre plus lisible et plus robuste.
  26. 26. Page 27/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Le but de cette pratique est de simplifier le code, tout en faisant en sorte quetous les tests soient satisfaits. Dun point de vue purement fonctionnel, cettesimplification nest pas nécessaire puisquelle intervient sur du code qui fonc-tionne parfaitement. En revanche, le refactoring du code assure que lajoutde fonctionnalités supplémentaires sera facilité. Le refactoring tend à pro-duire un code mieux pensé, plus modulaire, sans duplications de code etdonc plus facile à maintenir.Programmation en binômeToute lécriture du code se fait à deux personnes sur une même machine,avec une seule souris et un seul clavier. On distingue deux rôles : le pilote("driver"), celui qui a le clavier, cherche la meilleure approche sur une portionde code bien précise tandis que lautre développeur, le "partner" peut obser-ver avec beaucoup plus de recul et ainsi suggérer dautres solutions ou sou-lever des problèmes dordre plus général.Au premier abord, cette pratique peut sembler être une perte de temps, maisil savère que le travail se fait plus vite, que le code est de meilleure qualité(moins derreurs de syntaxe, meilleur découpage, etc.), avec une meilleurecompréhension du problème. Pour les développeurs, le travail est moinsfatiguant.Les binômes ne doivent pas être statiques : chacun change de partenairerelativement souvent. Ceci pour un meilleur partage des connaissances etpour permettre à chacun davoir une relativement bonne vision sur lensem-ble du code.Appropriation collective du codeToute léquipe est sensée connaître la totalité du code (plus ou moins dans ledétail selon les parties, évidemment). Cela implique que tout le monde peutintervenir pour faire des ajouts ou des modifications sur une portion de codequil na pas écrit lui même si cela savère nécessaire.Intégration continueAprès chaque fin de tâche, cest à dire plusieurs fois par jour, le code nouvel-lement écrit doit être intégré à lexistant de manière à avoir à tout moment unexistant fonctionnel qui passe avec succès tous les tests. Ainsi, quand unetâche est démarrée, elle peut se fonder sur la version la plus à jour de ce quia déjà été fait.Pas de surcharge de travailLobjectif est de ne pas dépasser 40 heures de travail par semaine pour lesdéveloppeurs. Il ne sagit pas de chercher à travailler peu, mais les spécialis-tes d eXtreme Programming ont pris conscience du fait que la surcharge detravail, en plus dêtre désagréable, est néfaste. En effet, le code devientmoins bien pensé, le refactoring est laissé de côté, ce qui conduit à unebaisse de la qualité et à une recrudescence des bugs. En vertu de ce prin-cipe, une équipe ne doit jamais être surchargée de travail plus de deux se-
  27. 27. Page 28/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1maines consécutives. Si cela devait toutefois se produire, léquipe se doit deréagir en redéfinissant la quantité de user stories à implémenter au cours delitération ou en modifiant sa manière de procéder.Client sur siteLimplication forte du client passe par la présence sur site dune personneminimum à temps plein pendant toute la durée du projet. Cette personne doitavoir à la fois le profil type de lutilisateur final et une vision plus globale ducontexte pour pouvoir préciser les besoins, leur donner une ordre de priorité,les transcrire sous forme de user stories, et établir les tests fonctionnels.La présence du client sur site est dictée par des impératifs en matière deréactivité. En effet, au fil de la programmation, les développeurs soulèventfréquemment des questions sur des points non abordés ou restés obscurs.En étant sur place, le client peut ainsi apporter immédiatement des réponsesà ces questions, évitant ainsi que les programmeurs commencent à dévelop-per certaines fonctionnalités sur la base de ce quils supposent être les désirsdu client.La présence à temps plein du client sur site nimplique pas forcément quecette activité occupe la totalité de son temps : il est tout à fait envisageablepour le client de continuer une partie de son activité tout en étant délocaliséauprès de léquipe de développeurs.Standards de codeIl est nécessaire de disposer de normes de nommage et de programmationpour que chacun puisse lire et comprendre facilement le code produit par lesautres. Ceci est dautant plus essentiel que la propriété du code est collectiveet que les programmeurs sont amenés à changer de binôme régulièrement.En général, les conventions adoptées lors des projets XP sont assez intuiti-ves et résultent de pratiques plutôt naturelles chez les développeurs.3.1.5 Cycle de vieCe paragraphe donne une vision du cycle de vie idéal dun projet XP. Plu-sieurs phases composent le cycle de vie dune application.
  28. 28. Page 29/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Figure 7 - Les grandes lignes du cycle de vie dun projet XPExplorationAu cours de cette phase, les développeurs se penchent sur des questionsdordre technique destinées à explorer les différentes possibilités darchitec-ture pour le système et à étudier par exemple les limites au niveau des per-formances présentées par chacune des solutions possibles.Le client de son côté shabitue à exprimer ses besoins sous forme de userstories que les développeurs devront estimer en terme de temps de dévelop-pement.PlanningNous ne détaillerons pas ici les procédures entrant dans la phase de plan-ning, ceci ayant déjà été fait plus haut, dans le paragraphe intitulé "planninggame".Le planning de la première release est fait de telle sorte quun système pour-vu uniquement des fonctionnalités essentielles soit mis en production dansun temps minimum et soit enrichi par la suite.Le planning game dure un ou deux jours et la première release est en géné-ral programmée pour deux à six mois plus tard.Itérations jusquà la première releaseCest la phase de développement à proprement parler de la première versionde lapplication. Celle ci se fait sous forme ditérations de une à quatre se-maines.Exploration Planning MortMaintenanceItérations jusqu’à lapremière releaseitérations de1 à 4 semainesMise enproductionitérations de1 semainemaintenance = ajouter des fonctionnalités à nouvelles releasesutilise le même processus que pour la release 1
  29. 29. Page 30/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Chaque itération produit un ensemble de fonctionnalités passant avec succèsles tests fonctionnels associés. La première itération est dédiée à la mise enplace de larchitecture du système.Ces itérations courtes permettent de détecter rapidement toute déviation parrapport au planning qui a été fait jusquà la sortie de la release. En cas dedéviation, quelque chose est à revoir, soit au niveau de la méthode, soit auniveau des spécifications, soit au niveau du planning.Durant les itérations, de brèves réunions réunissent toute léquipe quotidien-nement pour mettre chacun au courant de lavancement du projet.Mise en productionLes itérations de cette phase sont encore plus courtes, ceci pour renforcer lefeedback. En général, des tests parallèles sont conduits au cours de cettephase et les développeurs procèdent à des réglages affinés pour améliorerles performances (performance tuning).A la fin de cette phase, le système offre toutes les fonctionnalités indispen-sables et est parfaitement fonctionnel et peut être mis à disposition des utili-sateurs.MaintenanceIl sagit dans cette phase de continuer à faire fonctionner le système désor-mais existant et de lui adjoindre les fonctionnalités secondaires qui avaientvolontairement été laissées de côté jusque là.Le développement de nouvelles fonctionnalités sur un système déjà mis enproduction requiert une prudence accrue de la part des développeurs et cettephase est donc cruciale.A chaque nouvelle release, une nouvelle phase dexploration rapide doitavoir lieu.MortLa fin dun projet intervient quand le client narrive plus à écrire de user sto-ries supplémentaires ce qui signifie que pour lui, tous ses besoins ont étésatisfaits ou quand le système nest plus capable de recevoir de modifica-tions pour satisfaire de nouveaux besoins tout en restant rentable.
  30. 30. Page 31/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Figure 8 - Interactions entre les acteurs dun projet XP3.1.6 RôlesDéveloppeurIl est lélément principal dun projet XP. En apparence, le développeur passesimplement son temps à écrire des lignes de code, rajouter des fonctionnali-tés, simplifier, optimiser son code. Mais son rôle ne se limite pas à cela. Laprincipale qualité dun développeur est sa capacité à communiquer. XP re-quiert aussi la capacité à travailler en binôme, aptitude qui nest pas forcé-ment requise pour dautres types de projets. Enfin, un développeur doit sha-bituer à la simplicité : construire la solution la plus simple et ne construire quece qui est absolument nécessaire doit devenir un réflexe.Un développeur doit avoir dautres compétences plus techniques : être capa-ble décrire du code propre, de pratiquer le refactoring, de recourir aux testsunitaires, etc.Enfin, XP requiert du courage de la part des développeurs.ClientLe client est lautre moitié du duo essentiel dans lapproche eXtreme Pro-gramming. Le développeur sait comment programmer et le client sait quoiprogrammer.Pour un projet XP, le client doit apprendre à exprimer ses besoins sousforme de user stories, à leur donner un ordre de priorité et à dégager ce quiest essentiel et valorisant pour lui.Dans lidéal, le client a à la fois le profil de lutilisateur et une vision plus éle-vée sur le problème et lenvironnement du business dans lequel le projetsinclut.Le client doit aussi apprendre à écrire les cas de tests fonctionnels et fairepreuve, lui aussi, de courage.ClientDéveloppeurDéveloppeurClientestime les coûtschoisit ce qui doit êtredéveloppé en prioritéspécifie ses besoinsdéveloppe lesfonctionnalitésdemandéescapitalise lesconnaissances
  31. 31. Page 32/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1TesteurÉtant donné que les tests unitaires sont à la charge des développeurs, letesteur a pour rôle daider le client à choisir et à écrire ses tests fonctionnels.Le testeur nest pas une personne isolée, chargée de mettre le système endéfaut et dhumilier les développeurs : il sagit juste dune personne chargéede faire passer régulièrement la batterie de tests.TrackerCest un peu la conscience de léquipe. Son rôle est daider léquipe à mieuxestimer le temps nécessaire à limplémentation de chaque user story et degarder un œil sur le planning en relation avec lavancement réel du projet.Cest en quelque sorte lhistorien et le rapporteur de léquipe, chargé de col-lecter toutes les informations qui peuvent savérer utiles.CoachLe coach a la responsabilité globale de tout le processus. Son rôle est derecadrer le projet, dajuster les procédures. Toute la difficulté de sa tâcheréside dans le fait quil se doit dintervenir de la manière la moins intrusivepossible. Au fur et à mesure de la maturation de léquipe, sont rôle diminue etléquipe devient plus autonome.ConsultantLa programmation en binôme rend assez peu probable lexistence de domai-nes de compétences dans lesquels seuls un ou deux membres de léquipeont des connaissances suffisantes. Cest une force car cela rend léquipe trèsflexible mais cest aussi une faiblesse car la volonté de simplicité se fait par-fois au détriment de connaissances techniques très poussées. Quand leproblème se présente, léquipe a recours aux services dun consultant. Lerôle dun consultant est dapporter à léquipe les connaissances nécessairespour quils résolvent eux mêmes leur problème et non de leur apporter unesolution toute faite.Big BossLe Big Boss apporte à léquipe courage et confiance.3.1.7 Forces et faiblessesExtreme Programming apparaît comme la plus radicale des méthodes agiles.Cette méthode se révèle particulièrement efficace dans le cadre de petitsprojets. XP réalise des applications de qualité grâce à la rigueur imposée surles tests, qui plus est collent au désirs du client puisque celui-ci est intégré auprojet de A à Z.Aussi efficace quelle soit, la méthode XP nest pas applicable dans tous lescas. Dans le cadre dun projet de type forfaitaire où le prix, les délais et lesbesoins sont fixés, XP ne peut pas réellement être mise en œuvre. Le casdune équipe supérieure à une douzaine de personnes est un autre exemple
  32. 32. Page 33/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1où XP est difficilement adaptable car le nombre risque de ralentir, dalourdirles procédures et de rendre la communication plus difficile et moins efficace.Enfin, XP est sans doute une des plus contraignante des méthodes agiles,aussi bien pour le client que pour les développeurs. En effet, linvestissementdemandé au client est très important puisquil doit déléguer une personne àtemps plein sur le lieu où est développée lapplication, avec toutes lesconséquences que cela induit. En ce qui concerne les développeurs, la prati-que de la programmation en binôme nest pas forcément très bien ressentiepar tous. Or un projet XP ne peut pas être un franc succès si tous ses parti-cipants nadhèrent pas pleinement à la méthode. Avant de se lancer dans untel projet, il faudra tout dabord convaincre le client et motiver léquipe ce quinest pas toujours aisé.3.2 DYNAMICSOFTWAREDEVELOPMENTMETHOD(DSDM)3.2.1 Les origines de DSDMLa méthode DSDM est née du même constat que toutes les méthodes agi-les, à savoir que les temps de développement étaient jusquà présent troplongs, que les applications livrées ne correspondaient pas toujours exacte-ment aux besoins, que les développeurs étaient peu impliqués dans laconception et que personne navait de vue complète des systèmes dévelop-pés.DSDM sappuie aujourdhui sur une association loi 1901, indépendante et àbut non lucratif, dont le but est de développer et de promouvoir une méthodepour le développement rapide dapplications. Il sagit dune approche dyna-mique qui requiert limplication des utilisateurs.Cest à la suite dune initiative britannique en 1994 quest née DSDM. Lap-proche ayant été adoptée par des entreprises prestigieuses comme BritishAirways, Barclays Bank, Marks and Spencer, etc., lassociation a connu unecroissance exponentielle et fait preuve aujourdhui dune volonté de diffusioninternationale.3.2.2 9 principes fondamentaux1. Limplication active des utilisateurs est impérativeDSDM part du principe quune implication forte des utilisateurs est néces-saire pendant tout le cycle de vie pour éviter des retards dans la prise dedécision. Les utilisateurs ne sont pas considérés comme de simples fournis-seurs dinformation mais bien comme des acteurs à part entière de léquipe.2. Les équipes DSDM doivent être autorisées à prendre des décisionsDans le cadre de la méthode DSDM, une équipe regroupe des développeurset des utilisateurs. Cette équipe doit être capable de prendre des décisionssur lévolution et la modification des besoins et de déterminer le niveau defonctionnalité sans demander laval de la direction.
  33. 33. Page 34/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.13. Le produit est rendu tangible aussi souvent que possiblePour des raisons de flexibilité, DSDM se fonde sur la livraison fréquente defournitures. Les délais sont volontairement pris très courts ce qui force àdéfinir quelles sont les activités qui permettront datteindre les résultats priori-taires dans le temps imparti.4. Ladéquation au besoin métier est le critère essentiel pour laccepta-tion des fournituresLobjectif de DSDM est de livrer à temps des fonctions métiers qui permettentde satisfaire les besoins de lentreprise. Lélaboration dun système plus glo-bal nest pas une priorité : elle peut être réalisée après coup.5. Un développement itératif et incrémental permet de converger versune solution appropriéeLe principe dévolution incrémentale des systèmes permet de tirer un meilleurparti du contact entre développeurs et utilisateurs. Cette manière de procéderpermet un retour permanent des utilisateurs vers les développeurs et unemeilleur adéquation des systèmes construits avec les besoins.De plus, le caractère itératif et incrémental de la méthode permet la livraisonde solutions partielles pour répondre à des besoins immédiats.6. Toute modification pendant la réalisation est réversibleIl est nécessaire de maîtriser la gestion de configuration du logiciel en déve-loppement de manière à ce que tout changement effectué soit réversible.Parfois, pour annuler certains changements, il est plus simple de reconstruireque de revenir en arrière. Il importe de sefforcer de rendre toute transforma-tion réversible.7. Les besoins sont définis à un niveau de synthèseLe schéma directeur fixe les exigences du système à un niveau suffisammentélevé pour permettre une évolution itérative des niveaux plus détaillés.8. Les tests sont intégrés pendant tout le cycle de vieLes tests font partie intégrante de lactivité de développement. Ils servent àvalider au fur et à mesure du développement du système que celui-ci estopérationnel tant sur le plan technique que fonctionnel. En fin de cycle, lestests sont les garants du bon fonctionnement du système.9. Un esprit de coopération entre tous les acteurs est primordialDans la démarche DSDM les fonctions détaillées ne sont pas figées dès ledépart. Le demandeur et le réalisateur doivent faire preuve de souplesse toutau long du cycle de vie, ce qui implique la nécessité davoir une procédure degestion des modifications peu contraignante.
  34. 34. Page 35/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.13.2.3 5 phasesDSDM se définit plus comme un "canevas" que comme une méthode, cest àdire quelle ne fournit que "lossature" du processus global et une descriptiondes processus et produits qui devront être adaptés à un projet ou à une en-treprise particulière.Le processus de développement est constitué de cinq phases :— LEtude de Faisabilité— LEtude du " Business "— Le Modèle Fonctionnel itératif— La conception et le développement itératifs— La Mise en œuvre dans lenvironnement de travail.Figure 9 - Cycle de vie dun projet DSDMLEtude de Faisabilité et lEtude du "Business" sont réalisées de manièreséquentielle. Comme elles établissent les règles de base pour le reste dudéveloppement elles doivent être terminées avant que les trois autres phasesitératives ne démarrent. Les trois phases suivantes peuvent converger ou sechevaucher mais cela dépend essentiellement de la nature du système déve-loppé et les outils utilisés. Chaque phase génère un minimum de livrablesrépondant à un besoin bien précis.LEtude de FaisabilitéPremière tâche à accomplir : déterminer si DSDM est lapproche qui convientpour le projet considéré. Cest dans cette phase que le problème à résoudreest posé. Il faut ensuite évaluer les coûts et dun point de vue technique,laptitude du système envisagé à résoudre le problème métier. dans la me-sure où les besoins sont généralement urgents, cette phase est nécessaire-ment courte et ne dépasse pas quelques semaines. Cette phase ne laissepas suffisamment de temps pour produire une documentation volumineuse.Le Rapport de Faisabilité couvre donc les thèmes habituels mais avec peude détails. LEtude de Faisabilité produit aussi un Plan Global de développe-ment, qui vient renforcer lhypothèse que lobjectif fixé est réalisable et, deModèleFonctionnelItératifMise enOeuvreConception etRéalisationItérativesÉtude deFaisabilitéÉtude deBusiness
  35. 35. Page 36/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1manière facultative, un Prototype de faisabilité pour montrer que la solutionest réalisable.LEtude du BusinessLétude du Business ou étude des besoins industriels doit elle aussi êtreaussi courte que possible. Elle a pour but de permettre la compréhensionsuffisamment approfondie des besoins et des contraintes techniques pour nepas mettre en péril la suite du déroulement du projet.Cette phase permet létude des processus à automatiser et des besoins eninformations. Cette étude passe par lorganisation dAteliers Facilités (travailcollectif animé par un médiateur) dont le rôle est de dégager la Définition duDomaine Industriel qui répertorie non seulement les processus de lentrepriseet informations associées mais aussi les classes (ou types) dutilisateur quiseront concernées dune manière ou dune autre par la mise en place dusystème. Ces classes permettent didentifier les utilisateurs qui participerontau développement. Ces utilisateurs auront pour responsabilité dune part defournir les informations nécessaires au projet et dautre part de tenir lensem-ble de la communauté informatique au courant de son évolution. Les AteliersFacilités permettent aussi de classer par ordre de priorité toutes les fonction-nalités à développer. Lordre de priorité repose principalement sur le degrédurgence des besoins métiers, mais il peut aussi intégrer des besoins nonfonctionnels tels que la sécurité par exemple.La Définition de lArchitecture Système, qui décrit aussi bien les plates-formes opérationnelles et de développement que larchitecture du logicieldéveloppé (cest à dire les principaux composants et interfaces associées),est un autre élément essentiel de Létude du Business. La définition de lar-chitecture à ce niveau est indispensable car certains modules commencerontà être développés dès létape suivante. Bien entendu, la Définition de lArchi-tecture Système est susceptible dêtre ajustée au cours des phases ultérieu-res.Enfin, le Plan Global issu de lEtude de Faisabilité est détaillé pour créer leplan Global de Prototypage qui décrit le mode de développement à utiliser aucours des deux phases suivantes ainsi que le mode de contrôle et de tests àmettre en oeuvre.Modèle Fonctionnel ItératifLe Modèle Fonctionnel Itératif a pour but de préciser la définition de tous lesaspects du système qui sont liés au business. Il consiste en une descriptionplus précise des besoins de haut niveau, à la fois en termes de traitement etdinformation. Cette phase produit aussi bien des modèles danalyse stan-dard que des modules logiciels.Les phases "Modèle Fonctionnel Itératif" et "Conception et Réalisation Itérati-ves" reposent toutes deux sur un cycle de quatre activités :1. Identifier ce qui doit être produit.2. Décider comment et à quel moment le faire.3. Créer le produit.
  36. 36. Page 37/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.14. Vérifier quil a été développé de manière appropriée (par le biais de testset à la lumière des documents précédemment produits)Les modules logiciels du Modèle Fonctionnel répondent aux principaux be-soins, y compris les besoins non fonctionnels comme la sécurité ou la facilitédutilisation. Ils subissent des tests au fur et à mesure de leur production :ceci sous-entend les tests techniques unitaires ainsi que des mini-tests derecettes effectués directement par les utilisateurs. Les tests permettent dedéterminer si les composants produits peuvent ou non être réutilisables etservir de base à un ensemble de fonctionnalités. Les aspects non fonction-nels sont testés au cours de la phase suivante.En pratique, il est souvent plus simple et plus intuitif de traiter intégralementun domaine fonctionnel et ses aspects non fonctionnels avant de passer à unautre domaine. Selon la manière dont lapplication a été découpée en diversmodules plus ou moins indépendants, les phases "Modèle Fonctionnel Itéra-tif" et "Conception et Réalisation Itératives" seront plus ou moins imbriquées.Conception et Réalisation ItérativesLe passage du Modèle Fonctionnel à La Conception et au Développementest subordonné à laccord sur un Prototype Fonctionnel présentant tout oupartie du Modèle Fonctionnel. Si ce prototype ne présente quune partie dumodèle fonctionnel, les activités de prototypage et de développement peu-vent être menées en parallèle.La phase Conception et Réalisation Itératives est létape qui a pour but derendre le système conforme à des standards assurant quil peut être placéentre les mains des utilisateurs. Le produit majeur de cette phase est le Sys-tème Testé. Dans des cas particuliers, le client peut exiger lajout dunephase de test à la fin de chaque itération, mais DSDM préconise létalementdes tests au fur et à mesure des phases "Modèle Fonctionnel Itératif" et"Conception et Réalisation Itératives".Le Système testé nest pas forcément complet sur le plan fonctionnel mais ilse doit de satisfaire les besoins qui ont été définis comme prioritaires pourlétape en cours.Mise en ŒuvreCest au cours de la phase de Mise en Oeuvre quest effectuée la migrationdu système de lenvironnement de développement à lenvironnement opéra-tionnel. Cette phase inclut également la formation des utilisateurs nayant paspris part au projet.Le Système Livré et la documentation (y compris la documentation utilisa-teur) font partie des livrables de cette phase. La documentation utilisateur estfinalisée durant cette phase mais elle doit avoir été commencée durant laphase Conception et Réalisation Itératives. Cest lune des responsabilitésdes utilisateurs ambassadeurs que de sassurer de la qualité de la documen-tation et de la formation utilisateur.Le Document de Capitalisation de Projet est lautre produit de cette phase. Ilpermet de faire le point sur les besoins exprimés et la manière dont le sys-tème y répond. Quatre résultats sont possibles :

×