Chp1 - Introduction à l'AGL by Lilia Sfaxi 2810 views\nChp4 - Diagramme de Séquence by Lilia Sfaxi 8686 views\n1. Page 2/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Table des matières 1. INTRODUCTION .............................................................................................4 Business Interactif en quelques mots ....................................................................4 Pourquoi un white paper sur les méthodes agiles ?...........................................4 2. LES METHODOLOGIES AGILES : GENERALITES .........................5 2.1 CONTEXTE.........................................................................................................5 2.2 CARACTERISTIQUES COMMUNES DES METHODES AGILES..........................5 2.2.1 Priorité aux personnes et aux interactions sur les procédures et les outils 6 2.2.2 Priorité aux applications fonctionnelles sur une documentation pléthorique.................................................................................................................7 2.2.3 Priorité de la collaboration avec le client sur la négociation de contrat 7 2.2.4 Priorité de l’acceptation du changement sur la planification.........7 2.3 DES METHODES RAD (RAPID APPLICATION DEVELOPMENT ) AUX METHODES AGILES, UNE FILIATION ?.......................................................................10 2.3.1 Origines du RAD ...................................................................................10 2.3.2 Les acteurs du RAD...............................................................................10 2.3.3 Les cinq phases d'un projet RAD........................................................13 2.3.4 RAD et modélisation.............................................................................14 2.3.5 Pourquoi le RAD n'est il pas à proprement parler une méthode "agile" ? 14 2.4 DE UNIFIED PROCESS (UP & RUP) A L’AGILITE, UNE FILIATION ?.......15 2.4.1 Les 5 principes d'UP.............................................................................15 2.4.2 Les activités dans la méthode UP.......................................................17 2.4.3 Les phases du cycle de vie....................................................................18 2.4.4 Pourquoi UP n'est pas à proprement parler une méthode agile ?19 2.5 LA SITUATION EN FRANCE : UN FORT ANCRAGE DE LA METHODE MERISE ET DE LA MODELISATION ENTITE-RELATION...........................................................20 3. PRINCIPALES METHODOLOGIES AGILES, ETAT DES LIEUX, COMPARAISON..........................................................................................................22 3.1 EXTREME PROGRAMMING (XP) ...................................................................22 3.1.1 Aux origines d'eXtreme Programming...............................................22 3.1.2 Les 4 valeurs d'eXtreme Programming .............................................22 3.1.3 Principes de base...................................................................................23 3.1.4 Les 12 pratiques XP..............................................................................25 3.1.5 Cycle de vie.............................................................................................28 3.1.6 Rôles ........................................................................................................31 3.1.7 Forces et faiblesses ...............................................................................32 3.2 DYNAMIC SOFTWARE DEVELOPMENT METHOD (DSDM).......................33 3.2.1 Les origines de DSDM ..........................................................................33 3.2.2 9 principes fondamentaux....................................................................33 3.2.3 5 phases...................................................................................................35 3.2.4 Les rôles ..................................................................................................38 3.2.5 Forces et faiblesses de la méthode.....................................................41 3.3 ADAPTIVE SOFTWARE DEVELOPMENT........................................................41\n2. Page 3/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 3.3.1 Contexte...................................................................................................41 3.3.2 Les 6 caractéristiques principales d'ASD..........................................41 3.3.3 Le cycle de vie selon Adaptive Software Development...................43 3.3.4 Forces et faiblesses ...............................................................................45 3.4 CRYSTAL METHODOLOGIES...........................................................................45 3.4.1 Origine.....................................................................................................45 3.4.2 Les valeurs partagées par l'équipe.....................................................46 3.4.3 Processus Crystal..................................................................................47 3.4.4 Forces et faiblesses ...............................................................................48 3.5 SCRUM..............................................................................................................49 3.5.1 Les origines de Scrum...........................................................................49 3.5.2 Le processus Scrum : vue générale....................................................49 3.5.3 Les "sprints" ...........................................................................................51 3.5.4 Forces et faiblesses ...............................................................................53 3.6 FEATURE DRIVEN DEVELOPMENT ...............................................................54 3.6.1 Les grandes lignes de la méthode.......................................................54 3.6.2 La notion de "feature" et de "feature set".........................................54 3.6.3 Les 5 phases d'un projet FDD .............................................................55 3.6.4 Forces et faiblesses ...............................................................................60 3.7 RECAPITULATIF : COMPARATIF DES METHODES AGILES...........................60 3.7.1 Adaptation des méthodes à la taille des projets et des équipes.....60 3.7.2 Degré d'exigence des méthodes agiles pour le client......................62 3.7.3 Facilité de mise en œuvre et contraintes en interne ........................63 4. LES METHODES AGILES VUES PAR BUSINESS INTERACTIF 66 4.1 LES METHODES AGILES SONT ELLES VRAIMENT NOUVELLES ?................66 4.2 LA BONNE METHODE POUR LE BON PROJET ................................................66 4.2.1 Un exemple : la modélisation de données.........................................67 4.3 QUELLES SONT LES MAUVAISES METHODES ?............................................67 4.4 QUELQUES POINTS CLES CROSS METHODES...............................................67 4.4.1 Petites équipes et outils véloces..........................................................67 4.4.2 Polyvalence des développeurs.............................................................68 4.4.3 Feedback client et itérations................................................................68 4.4.4 Gestion des risques................................................................................68 4.4.5 Maîtrise d’ouvrage et maîtrise d’œuvre jouent dans le même camp 68 4.4.6 Tester toujours et encore......................................................................69 4.5 LA CULTURE ET LES VALEURS......................................................................70 4.5.1 La culture de l’humilité........................................................................70 4.5.2 Le pragmatisme......................................................................................70 4.5.3 Le souci de la qualité............................................................................70 4.5.4 Le partage...............................................................................................70 4.5.5 Le courage..............................................................................................71 4.6 CONCLUSION...................................................................................................71 4.7 CHOISIR ET METTRE EN ŒUVRE LES METHODES.........................................72 4.8 COLLABORER AVEC BUSINESS INTERACTIF................................................72 Les 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 leur propriétaires respectifs.\n3. Page 4/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Nous sommes heureux de vous présenter notre nouveau white paper sur les méthodes agiles de gestion de projet et de développement, Extreme Programming étant probablement la plus connue de ces méthodes. Dans un contexte économique plus tendu, le succès des projets informatiques devient toujours plus critique. La démarche méthodologique adoptée joue pour beaucoup dans le succès de ces projets. Les méthodes agiles constituent elles le nouvel eldorado ? Business Interactif fait le point sur le sujet… Business Interactif en quelques mots Business Interactif conçoit et réalise de grands projets e-business à forte composante 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 en France 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 du projet, 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, Business Interactif 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 à consulter notre site : www.businessinteractif.fr Pourquoi un white paper sur les méthodes agiles? Au cours des huit dernières années, nos équipes ont contribué à la réussite de grands projets E-business, dans une logique de maîtrise d’œuvre. L’une des é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 haut niveau de service. La gestion d’un projet et les méthodes de développement optimales sont des préoccupations récurrentes dans notre métier. Nos grands 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, de RAD pour la gestion de projet et le maquettage, d’UML pour la conception objets/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éthodes agiles, ne pouvait nous laisser insensibles. A ce titre, comme nous l’avions fait 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 des méthodes, mais aussi retours d’expérience! Jean-Louis Bénard, directeur technique de Business Interactif. 1. INTRODUCTION\n4. Page 5/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 2.1 CONTEXTE Les méthodes de gestion de projet informatique connaissent, au même titre que les technologies mises en œuvre, une remise en cause permanente. La proportion importante d’échec des projets vient souvent alimenter des réactions plus ou moins constructives aux méthodes mises en œuvre. Les évolutions des architectures technologiques et des outils de développement y contribuent é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 technologies objet 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 dans une démarche plus radicale, que l’on pourrait résumer par «trop de méthode tue la méthode ». De manière générale, leur but est d'augmenter le niveau de satisfaction des clients 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 deux caractéristiques : — Les méthodes agiles sont "adaptatives" plutôt que prédictives Si 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ériode de temps, cela suppose que les exigences et spécifications de base restent immuables. Or, dans tous les projets, les exigences changent au cours du temps et le contexte évolue aussi. Par conséquent, si elles fonctionnent sur des projets courts et de petite taille, ces méthodologies sont trop réfractaires au 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 souple qui leur permettent de s’adapter à la fois aux changements de contexte et de spécifications du projet. — Les méthodes agiles sont orientées vers les personnes plutôt que vers les processus Les méthodes agiles s’efforcent de travailler avec les spécificités de chacun plutôt que contre la nature de chacun pour que le développement soit une activité 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 elles dans une seconde partie, essayons tout d’abord de dégager les principales caractéristiques communes à toutes ces méthodes, autrement dit : qu’est ce qui fait qu’une méthode de développement est une méthode agile ? 2.2 CARACTERISTIQUESCOMMUNES DES METHODES AGILES Très récemment, en février 2001, les instigateurs des principales méthodes agiles se sont réunis pour former l’ "Agile Alliance" (http://agilealliance.org). Ensemble, ils ont pu dégager des principes fondamentaux sur lesquels 2. LESMETHODOLOGIES AGILES :GENERALITES\n5. Page 6/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 s’appuyer pour que le développement puisse se faire rapidement et s’adapter au changement. Leur travail a abouti au "Manifeste pour le développement agile d’applications" : Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the 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 ne traduisent pas spécifiquement la position de Business Interactif sur le sujet. 2.2.1 Priorité aux personnes et aux interactions sur les procédures et les outils La meilleure garantie de succès réside dans les personnes : même une bonne méthode, de bonnes procédures ne sauveront pas un projet de l’é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 en groupe et à communiquer est un bien meilleur équipier. La gestion de projet a longtemps établi la «méthode » comme le vecteur essentiel de succès d’un projet. Cette méthode a souvent pris la forme de procé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’utilisation d’outils surdimensionnés ou faisant de l’homme un simple instrument de la dé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ême une bonne méthode, de bonnes procédures ne sauveront pas un projet de\n6. Page 7/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 l’échec si l’équipe n’est pas constituée de personnes très impliquées dans le projet. 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 documentation pléthorique Les partisans des méthodes agiles affirment la légitimité d’une certaine forme de documentation mais ils dénoncent les effets pervers d’une documentation pléthorique. En effet, l’écriture et le maintien à niveau de la documentation sont extrêmement consommateurs de ressources. Un document qui n’est pas mis à jour régulièrement devient très rapidement totalement inutile, voire même trompeur. Le manifeste est donc favorable aux documentations suc- cinctes, ne décrivant que les grandes lignes de l’architecture du système mais régulièrement tenues à jour, et d’une documentation permanente du code lui-même. Le meilleur transfert des connaissances sur le système s’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 de contrat Le succès d’un projet requiert un feedback régulier et fréquent de la part du client. Un contrat qui spécifie les exigences, le planning et le coût d’un projet a priori relève d’une vision utopique d’une projet informatique. La meilleure manière de procéder pour le client est de travailler en étroite collaboration avec l’équipe de développement, pour lui fournir un feedback continu qui assure 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 client qui 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 du prestataire de service afin d’établir une réelle relation de confiance, ainsi qu’une bonne compréhension de la réalité opérationnelle du projet par les juristes en charge du dossier. 2.2.4 Priorité de l’acceptation du changement sur la planification C’est la capacité à accepter le changement qui fait bien souvent la réussite ou 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és dont 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.\n7. Page 8/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Figure 1 - Positionnement des méthodes par rapport aux quatre critères agiles Les quatre valeurs ci-dessus sont en fait déclinées sur douze principes plus gé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ères semaines si possible une version rudimentaire de l’application puis de livrer souvent 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. A chaque version (release), un feedback de la part du client est nécessaire pour permettre soit de continuer le développement comme prévu, soit d’opérer des changements. De cette manière, les changements dans les spécifications interviennent tôt dans le processus de développement et sont moins problématiques. — "Accueillir le changement à bras ouverts, même tard dans le processus de 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 compris et appris comment satisfaire encore mieux la demande. Le but des méthodes agiles est de produire des systèmes très flexibles, de sorte que l’impact sur le système d’une évolution des spécification reste minimal. Ressources humaines et communication Processus et outils Applications fonctionnelles Documentation Collaboration étroite avec le client Négociation de contrat Accueil du changement Planification rigide\n8. Page 9/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT 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 de l’application, avec une fréquence comprise entre deux semaines et deux mois" Ne pas se contenter de livrer des liasses de documents décrivant l’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 long du projet" Pour qu’un projet puisse être considéré comme agile, il faut qu’il y ait une interaction permanente entre le client, les développeurs : c’est ce qui guide continuellement le projet. — "Construire des projets autour d’individus motivés. Leur donner l’environnement et le support dont ils ont besoin et leur faire confiance pour 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 bon fonctionnement 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 la conversation et non l’écrit. Des documents peuvent bien sûr être rédigés mais ils n’ont en aucun cas pour but de consigner par écrit la totalité des informations relatives au projet. Même les spécifications peuvent très bien ne pas être écrites de manière formelle. — "Le fonctionnement de l’application est le premier indicateur d’avancement du projet" Contrairement à d’autres méthodes, l’avancement du projet ne se mesure pas à 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és effectivement mises en place. — "Les méthodes agiles recommandent que le projet avance à un rythme soutenable : développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment" Il ne s’agit pas de sprinter sur 100 mètres, mais plutôt de tenir la distance sur un marathon : l’équipe se doit donc d’adapter son rythme pour préserver la qualité de son travail sur toute la durée du projet. — "Porter une attention continue à l’excellence technique et à la conception améliore l’agilité" La meilleure façon de développer rapidement est de maintenir le code source de l’application aussi propre et robuste que possible. Les membres de l’équipe doivent donc s’efforcer de produire le code le plus clair et le plus propre 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 – est essentielle"\n9. Page 10/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Rien ne sert d’essayer d’anticiper les besoins de demain. Au contraire, il faut construire le système le plus simple répondant aux besoins actuels pour que celui-ci soit facilement adaptable dans le futur. — "Les meilleures architectures, spécifications et conceptions sont le fruit d’é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 leurs responsabilité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 sur la 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, ses règles, son fonctionnement, etc. de manière à rester agile. 2.3 DESMETHODESRAD(RAPID APPLICATION DEVELOPMENT) AUX METHODES AGILES, UNE FILIATION ? 2.3.1 Origines du RAD Le RAD (Rapid Application Development) est né dans les années 80 à la suite d'un double constat. D'une part, le manque de concertation entre les informaticiens en charge de la réalisation d'un projet et les utilisateurs conduit souvent à la réalisation d'applications mal adaptées aux besoins. D'autre part les méthodes classiques de conduite de projet sont inadaptées à la vitesse des évolutions technologiques et la durée des projets est beaucoup trop longue. Les objectifs premiers du RAD sont de conduire à l'amélioration de la qualité des développements tout en réduisant les délais et en facilitant la maîtrise des coûts. Pour cela, il est nécessaire d'associer méthodologie et relations humaines. 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 et adapté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 le RAD a souffert d'une si mauvaise image, c'est avant tout lié à la notion de rapidité qu'on a souvent tendance à considérer, à tort, comme incompatible avec celle de qualité. Pour éviter ce malentendu, Jean Pierre Vickoff propose de traduire RAD par "développement maîtrisé d'applications de qualité ap- prouvée par les utilisateurs". 2.3.2 Les acteurs du RAD Dans un projet RAD, la répartition des rôles est très structurée. Comme dans une approche classique, l'ensemble de l'organisation s'appuie sur un principe fondamental : la séparation des rôles opérationnels et des responsabilités entre d'une part la maîtrise d'ouvrage (MOA) qui représente l'utilisateur et à ce titre détermine les fonctionnalités à développer et leur degré de priorité et\n10. Page 11/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 d'autre part la maîtrise d'œuvre (MOE) qui apporte les solutions techniques aux problèmes posés par la maîtrise d'ouvrage. (Cette séparation des rôles est encore renforcée par la présence du Groupe d'animation et de Rapport RAD qui se charge d'organiser la communication du projet. Son rôle principal est de faciliter l'expression des exigences et de les formaliser en temps réel. La maîtrise d'ouvrage La maîtrise d'ouvrage a trois responsabilités principales : — Définir les objectifs et les exigences du système : le maître d'ouvrage, 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 d'ordre stratégique, fonctionnel, technologique, organisationnel, ainsi que les contraintes de projet. Ces objectifs, classés par ordre de priorité servent de base pour la prise de décisions de pilotage. Le maître d'ouvrage spé- cifie aussi les exigences en déléguant leur mise en forme à diverses per- sonnes compétentes : par exemple, les exigences fonctionnelles sont exprimées par des représentants d'utilisateurs et des experts fonction- nels. — Valider les solutions proposées et élaborées : en collaboration avec les personnes qui ont exprimé les exigences, le maître d'ouvrage vérifie que la ou les solutions proposées par la maîtrise d'œuvre permettent bien de satisfaire ces exigences. — Préparer et piloter le changement induit : il s'agit là d'opérations de sensibilisation, formation, communication ainsi que d'organisation. Au sein de la maîtrise d'ouvrage, on peut distinguer trois acteurs principaux : — Maître d'ouvrage : prend des décisions sur les objectifs (produit, coût, délai) et les orientations du projet et décide in fine l'expression des exi- gences et la validation des solutions ainsi que les moyens à mettre en œuvre au sein de la maîtrise d'ouvrage. — Coordinateur de Projet Utilisateurs ou Maître d'Ouvrage délégué : coor- donne et valide les activités de la maîtrise d'ouvrage. Réalise le suivi des objectifs (produits, coûts / charges, délais) et des activités de la maîtrise d'ouvrage. — Responsable de la cohérence et de la qualité fonctionnelle : supervise l'expression des exigences et de la validation des solutions, contrôle la cohé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'œuvre Elle a également trois responsabilités principales : — Proposer et réaliser la solution : cela passe notamment par la définition et la mise en œuvre du planning et des moyens humains et logistiques nécessaires — Livrer des "fonctionnalités" : on entend par fonctionnalités les produits finis mais aussi des produits intermédiaires et diverses informations qui\n11. Page 12/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 permettront à la maîtrise d'ouvrage 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 d'Assurance Qualité : en même temps que la réalisation de l'application, la maîtrise d'œuvre réalise son suivi sur des critères tels que les fonctionnalités, la qualité, le planning, les coû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 des orientations pour le projet. Décide in fine les propositions de solution et les solutions elles-mêmes qui seront élaborées. Décide des moyens et méthodes à mettre en œuvre au sein de la MOE. Se coordonne avec les MOE des autres projets et les sociétés extérieures participant à la MOE du projet — Pilote de Projet Informatique : coordonne les travaux de la MOE. Valide les propositions de solution et les solutions elles-mêmes élaborées par la MOE. 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 d'un domaine. Le Groupe d'animation et de Rapport RAD Le groupe d'animation et de rapport (GAR) a pour responsabilités la prépara- tion des réunions (convocation, logistique et suivi), l'organisation des séan- ces de travail, la formalisation des exigences exprimées, la gestion des comptes-rendus, la planification et l'animation des focus. L'animateur doit adopter une attitude directive sur la forme et non directive sur le fond. Il se garde d'émettre un avis personnel, de porter un jugement et de favoriser des opinions. Il n'ajoute rien au discours des participants et se contente de maintenir les discussions bien centrées sur le thème voulu et de canaliser les entretiens. Pour cela, il peut procéder par exemple par synthèse (résumer l'essentiel en le reformulant) ou par élucidation (forcer les gens, par le biais de questions, à aller jusqu'au bout d'une idée). Le rapporteur doit être capable de produire une documentation automatisée et de la maintenir à jour. C'est tout d'abord un analyste concepteur, spécia- lement formé aux AGL (Ateliers de génie Logiciel). Lors des réunions portant sur la conception du système, il doit être capable de le modéliser en direct. Il est aussi responsable de la synthèse des comptes-rendus de réunion.\n12. Page 13/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Figure 2 - Les acteurs du RAD 2.3.3 Les cinq phases d'un projet RAD Initialisation (préparation de l’organisation et communication ) Cette phase, qui représente environ 5% du projet, définit le périmètre général du 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) C'est aux utilisateurs de spécifier leurs exigences et d'exprimer leurs besoins lors 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 premier prototype ayant pour but de présenter l’ergonomie et la cinématique générale de l’application. 4 à 8 jours de sessions sont prévus par commission. Cette phase représente environ 25% du projet. Construction (réalisation, prototypage) Durant cette phase, l’équipe RAD (SWAT) construit au cours de plusieurs sessions itératives l’application module par module. L’utilisateur participe toujours 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 changement Maîtrise d’œuvre • Propose et réalise la solution • Livre des « fonctionnalités» • respecte les directives du Plan d’Assurance Qualité Groupe d’animation et de Rapport RAD Animateur • Provoque et conduit les réunions • N’émet pas d’avis personnel • Recadre les discussions • Synthétise et formalise Rapporteur • Produit une documentation automatisée • Modélise le système en direct lors des réunions de conception • Rédige les comptes-rendus\n13. Page 14/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Finalisation (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 RAD 2.3.4 RAD et modélisation S'il se veut efficace, le RAD se doit d'être rapide et donc d'utiliser des techni- ques de modélisation rigoureuses mais simplifiées. Le RAD ne préconise pas de technique de modélisation particulière : il est tout à fait possible d'utiliser des modèles objets comme UML ou des modèles de Merise, à condition de les alléger pour n'en conserver que ce qui est strictement indispensable. Dans le cadre d'une approche "classique" par le haut de type merisienne, tous les modèle d'abstraction merisiens ne sont pas utilisés. Dans le cas général, ne sont conservés que le modèle de Contexte (MC), le modèle Conceptuel de Communication (MCC), la hiérarchie de fonctions (ou MCT), le modèle Conceptuel de Données (MCD), et le modèle Organisationnel de Traitements (MOT). Dans le cas d’un développement orienté objet, il est préconisé d’employer la notation 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èle de Réalisation, modèle de Déploiement. 2.3.5 Pourquoi le RAD n'est il pas à proprement parler une méthode "agile" ? Essayons d'examiner la méthode RAD à la lumière des quatre critères qui font qu'une méthode est agile ou ne l'est pas. Le RAD met bien en avant les ressources humaines et la communication par rapport au côté procédurier, notamment grâce à l'existence du groupe d'ani- mation et de rapport qui a pour rôle de faciliter la communication entre la maîtrise d'œuvre et la maîtrise d'ouvrage. Initialisation Finalisation Cadrage Design Construction Construction Design Construction Construction 6 % 9 % 23 % 50 % 12 % • Préparation de l’organisation • Communication • Expression des exigences •Analyse • Conception • Modélisation • Réalisation • Prototypage • Construction itérative • Recette •Déploiement\n14. Page 15/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Le RAD privilégie la production d'applications fonctionnelles par rapport à l'écriture massive de documentation. Le RAD implique une collaboration étroite avec le client. Dans un processus RAD, le client est un acteur clé (maîtrise d'ouvrage). Par contre, le dernier critère des méthodes agiles n'est pas véritablement rempli par le RAD. En effet, un projet RAD n'est pas conçu pour faire preuve d'une grande flexibilité par rapport au changement. Au contraire, le RAD se place plutôt du côté de la planification rigide. Le RAD présente donc trois des quatre caractéristiques des méthodes agiles. C'est donc une méthode proche des méthodes agiles sans pour autant en faire véritablement partie. 2.4 DE UNIFIED PROCESS (UP & RUP) A L’AGILITE,UNE FILIATION? 2.4.1 Les 5 principes d'UP UP 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 elle sera employée. UP présente sept caractéristiques essentielles, les trois premières étant trois critères préconisés par UML (Unified Modeling Language) : UP est pilotée par les cas d'utilisation Les cas d'utilisation (« Use Cases ») sont les véritables pilotes du projet, quelle que soit l'activité et quelle que soit la phase. En effet, le système est tout d'abord analysé, conçu et développé pour des utilisateurs. Le système ne peut pas être développé par des informaticiens n'ayant aucune idée de ce que sont le métier et l'environnement des utilisateurs : tout doit donc être fait en adoptant le point de vue utilisateur. Les cas d'utilisation sont l'outil de modélisation des besoins en termes de fonctionnalités : c'est sous cette forme que sont exprimées les exigences. Les cas d'utilisation servent aussi de base pour l'analyse, le modèle logique, ainsi que de base pour les tests fonctionnels. UP est centrée sur l'architecture UP se soucie très tôt de l'architecture dans le cycle de vie d'une application. L'architecture du système est décrite à l'aide de différentes vues. Alors que les modèles cas d'utilisation, analyse, conception, implémentation, déploie- ment, sont complets et exhaustifs, les vues définies par l'architecte ne re- prennent que les éléments significatifs. L'architecte procède de manière in- crémentale : il commence par définir une architecture simplifiée qui répond aux besoins classés comme prioritaires avant de définir à partir de là les sous-systèmes de manière beaucoup plus précise. UP est itérative et incrémentale\n15. Page 16/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 UP procède par itérations par opposition aux méthodes en cascade qui sont plus coûteuses et ne permettent pas une bonne gestion du risque. De plus, il est toujours difficile de corriger à la fin une erreur commise au début d'un projet. En procédant de manière itérative, il est possible de découvrir les erreurs et les incompréhensions plus tôt. Le feedback de l'utilisateur est aussi encouragé et les tests effectués à chaque utilisation permettent d'avoir une vision plus objective de l'avancement du projet. Enfin, le travail itératif permet à l'équipe de capitaliser à chaque cycle les enseignements du cycle précédent. Figure 4 - UP est une méthode itérative et incrémentale UP gère les besoins et les exigences Les exigences du client changent au cours du projet. UP recommande de dé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 les filtrer, 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 composants UP recommande de structurer l'architecture à 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 de composants existants si ceux-ci ont été développés de manière assez générique. Enfin, la visualisation à l'aide des outils de modélisation est facile et automatique. UP pratique la modélisation visuelle UP 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. La modélisation sous différents points de vue permet une meilleure compréhen- sion et une compréhension globale du système à concevoir. L'utilisation d'ou- Planning initial Planning Exigences Analyse et Conception Implémentation TestsÉvaluation Déploiement\n16. Page 17/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 tils visuels augmente encore les capacités de l'équipe à gérer la complexité des systèmes. Figure 5 - Modélisation visuelle selon différentes vues UP se soucie en permanence de la qualité Partant du constat que le coût de la correction des erreurs augmente expo- nentiellement au fur et à mesure de l'avancement du projet, il est absolu- ment nécessaire d'avoir un contrôle permanent et rigoureux des fonctionna- lités, de la fiabilité, des performances de l'application et des performances du système. Pour cela, une automatisation des tests tout au long du cycle de vie s'impose. Ainsi, les défauts sont détec- tés très rapidement et le coût de leur correction est minimisé, l'estimation de l'état d'avancement 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 permanente La phase de pré-étude a pour but d'identifier les risques qui pourraient mettre le projet en péril. Tout au long du projet, il est recommandé de maintenir une liste de risques, issus de la phase de pré-étude, classés selon leur danger pour l'équipe afin d'avoir une vue plus explicite des choses. 2.4.2 Les activités dans la méthode UP UP définit les activités essentielles et propose, pour chacune d'entre elles, une liste d'intervenants (architecte, analyste...) et une liste de travaux asso- ciés. Diagrammes de composants Diagrammes de scénario Diagrammes d’état Diagrammes de classes Diagramme de déploiementDiagrammes de cas d’utilisation Modèle Avancement du projet Coût de la correction des erreurs\n17. Page 18/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Expression des besoins UP distingue deux types de modèles : "Domain Model" et "Business Model". Le modèle de domaine ne dépend pas de l'application : il a pour but d'ap- 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 l'entreprise et s'intéresse directement aux collaborateur et à leurs divers travaux. C'est à partir de ce modèle que peut alors démarrer l'analyse des cas d'utilisation du système. Il s'agit de mieux connaître le domaine et ses activités avant de s'intéresser aux fonctionnalités du système par une étude par les cas d'utili- sation. Analyse Comprendre et de structurer le logiciel à développer sont les objectifs de l'analyse. On construit dans cette activité une représentation interne quasi- idéale du système, sans trop tenir comte des exigences et contraintes de conception. L'analyse utilise le langage du développeur alors que l'expres- sion des besoins se fait du point de vue utilisateur. Conception La conception consiste à définir l'architecture du système. La conception n'est non pas une phase du process UP mais une activité qui trouve sa place dans 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 l'architecture, tandis qu'en phase de construction la conception de gros- sière devient beaucoup plus détaillée. Si l'analyse est une vue purement logique, la conception est plus physique et se soucie des contraintes que l'analyse avait laissées de côté. Implémentation et Test Cette activité consiste à créer à proprement parler les divers composants : sources, scripts, puis exécutables... Les tests se basent sur les cas d'utilisa- tion. 2.4.3 Les phases du cycle de vie Etude d'opportunité C'est durant cette phase qu'il faut se poser la question de la faisabilité du projet, des frontières du système, des risques majeurs qui pourraient mettre en péril le projet. A la fin de cette phase, est établi un document donnant une vision globale des principales exigences, des fonctionnalités clés et des contraintes majeures. Environ 10 % des cas d'utilisation sont connus à l'issue de cette phase. Il convient aussi d'établir une estimation initiale des risques, un "Project Plan", un "Business Model". Elaboration Cette phase a pour but de préciser l'architecture. A ce stade, 80 % des cas d'utilisation sont obtenus. Cette phase permet aussi de connaître des exi-\n18. Page 19/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 gences supplémentaires, en particulier des exigences non fonctionnelles, de décrire l'architecture du système, de le prototyper, de réviser la liste des risques et de mettre en place un plan de développement. En théorie, c'est à ce stade qu'on est à même de faire une offre de réalisation du système. Construction L'objectif est de fournir une version beta de la release en cours de dévelop- pement ainsi qu'une version du manuel utilisateur. Transition Cette 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 l'en- semble des sites. Comme le nom de la phase l'indique, il s'agit aussi de pré- parer la release suivante et de boucler le cycle soit sur une nouvelle étude d'opportunité soit une élaboration ou construction. Figure 6 - Importance des activités au cours des différentes phases D'après Rational Software Corporation 2.4.4 Pourquoi UP n'est pasà proprement parler une méthode agile ? Comme nous l'avons fait pour le RAD, positionnons UP par rapport aux qua- tre critères d'agilité. UP s'efforce de produire des applications fonctionnelles et surtout en coïnci- dence avec les besoins exprimés par le client. Cette caractéristique vient du fait qu' UP est pilotée par les cas d'utilisation. phases activités Etude d’opportunité Elaboration Construction Transition Etude du business Expression des besoins Analyse et Conception Implémentation Tests Déploiement itérations\n19. Page 20/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 UP insiste sur la nécessité d'une collaboration étroite avec le client. L'expres- sion des besoins se fait en début de projet, mais à chaque itération, la phase de transition permet un retour du client sur ce qui est fait. UP fait aussi un premier pas vers des méthodes souples par rapport au changement. En revanche, la méthode UP reste très procédurière. De plus UP s'ancre très fortement sur la modélisation UML et ses outils. Cette modélisation parfois qualifiée de "modélisation à outrance" a tendance à alourdir quelque peu la méthode. En conséquence, UP ne remplit pas pleinement les critères d'agilité tout en restant très proche d'une méthode agile. 2.5 LASITUATIONENFRANCE : UN FORT ANCRAGE DELA METHODEMERISEETDELAMODELISATIONENTITE- RELATION La conception d'un système passe par une phase d'analyse qui nécessite des méthodes permettant de mettre en place un modèle du système à déve- lopper. Parmi les méthodes d'analyse, Merise, qui date de la fin des années soixante-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 une certaine longévité au modèle. En effet, la structure des données n'a pas à être souvent modifiée dans le temps, tandis que les traitements le sont plus fréquemment. La méthode Merise est apparue dans les années 1978-1979, à la suite d'une consultation nationale lancée en 1977 par le ministère de l'Industrie. Cette consultation avait pour but de choisir des sociétés de conseil en informatique chargées de définir une méthode de conception de systèmes d'information. Les deux principales sociétés ayant mis au point cette méthode sont le CTI (Centre Technique d'Informatique), et le CETE (Centre d'Etudes Techniques de l'Equipement). 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 s'agit 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, un seul scénario est retenu sur des critères de coûts, limites, impacts, délais et faisabilité) — Analyse détaillée : le premier modèle à établir est le Modèle Conceptuel des Données (MCD) basé sur une modélisation entités / relations. Au cours de cette phase, on établit aussi le Modèle Organisationnel des Traitements (MOT) puis le Modèle Logique des Données (MLD). — Analyse technique : il s'agit de définir les solutions techniques retenues en établissant le Modèle Physique des Données (MPD) et le Modèle Opérationnel des Traitements (MOPT)\n20. Page 21/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Merise permet de modéliser un système selon différents degrés d'abstrac- tion : le modèle conceptuel est théorique et ne se soucie pas ou peu de l'im- plémentation, le modèle logique représente un choix logiciel et le modèle physique représente un choix d'architecture. Merise, méthode vieille d'une vingtaine d'années reste particulièrement bien ancrée en France, notamment pour la modélisation des données. On a donc une situation un peu particulière dans l'hexagone : les méthodologies plus récentes sont en général modifiées pour pouvoir s'adapter à l'existant Merise encore très utilisé pour ses performances en matière de modélisation des données.\n21. Page 22/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 L’agilité comprend plusieurs courants de pensée qui ont conduit à des mé- thodologies reposant sur les mêmes concepts mais présentant chacune des singularités. Présentant successivement Xtreme Programming, DSDM, ASD, CRYSTAL, SCRUM, FDD, cette partie se conclut par une vision de synthèse sous la forme d’une comparaison. 3.1 EXTREME PROGRAMMING(XP) 3.1.1 Aux origines d'eXtreme Programming La suppression des risques existants sur un projet représente la philosophie d’XP. . En introduisant cette méthode, ses créateurs veulent en finir avec la dérive de délais, l'annulation des projets, la non-qualité, la mauvaise com- préhension du métier du client et l'impossibilité 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 place un nouveau système de gestion de la paie des dix mille salariés du fabricant automobile. Sur ce projet, la méthode XP a été adoptée pour tenter de sau- ver le projet d'une 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 sont autant de boutons de contrôle poussés au maximum". 3.1.2 Les 4 valeurs d'eXtreme Programming XP met en avant quatre valeurs prenant en considération à la fois les enjeux commerciaux et les aspects humains des projets de développement d'appli- cations. Communication L'absence de communication est certainement l'un des défauts les plus gra- ves qui mettent en péril un projet. Diverses pratiques XP tendent à rendre la communication 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 l'information. Simplicité Cette valeur de simplicité repose sur le pari qu'il coûte moins cher de déve- lopper un système simple aujourd'hui quitte à devoir engager de nouveaux frais plus tard pour rajouter des fonctionnalités supplémentaires plutôt que de concevoir dès le départ un système très compliqué dont on risque de n'avoir plus besoin dans un avenir proche. XP encourage donc à toujours s'orienter vers la solution la plus simple qui puisse satisfaire les besoins du client. 3. PRINCIPALES METHODOLOGIES AGILES, ETATDESLIEUX, COMPARAISON\n22. Page 23/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Feedback Le retour est immédiat pour les développeurs grâce aux tests unitaires. Pour les clients, le retour se fait à l'échelle de quelques jours grâce aux tests fonc- tionnels qui leur permettent d'avoir une vision permanente de l'état du sys- tème. Un feedback permanent est positif pour le client qui a une bonne vision du projet, peut détecter tout écart par rapport au planning et à ses attentes de maniè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. Courage Du 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 ses besoins ne sont pas toujours très clairs. De son côté, le développeur doit avoir le courage de modifier l'architecture même si le développement est déjà bien avancé, de jeter du code existant et d'accepter qu'il est parfois plus rapide et efficace de réécrire une portion de code à partir de zéro plutôt que de bricoler du code existant. 3.1.3 Principes de base Feedback rapide L'idée de base est issue de la psychologie de l'apprentissage : plus le retour suit de près une action, plus l'apprentissage qui en résulte est important. C'est pour utiliser au mieux cette caractéristique qu'eXtreme Programming préconise des itérations de courte durée et l'implication forte du client. Un retour rapide pour le développeur permet une correction ou un changement de direction plus rapide et un retour rapide vers le client lui permet de tester en permanence l'adé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 simple possible, partant du principe qu'un travail propre, simple et minimal aujour- d'hui est facile à améliorer par la suite. Changements incrémentaux Une série de petits changements progressifs est toujours bien plus sûre et bien plus efficace qu'un grand chambardement. Ceci est valable à plusieurs niveaux : dans un projet XP, l'architecture et la conception changent petit à petit, de même que le planning et la composition de l'équipe.\n23. Page 24/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Accueillir le changement à bras ouverts La meilleure stratégie est celle qui préserve le maximum d'options tout en apportant 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 et qualité, la qualité n'est pas vraiment indépendante. Pour la réussite d'un projet, la qualité ne peut qu’être "excellente" si chacun aime le travail qu'il fait. Apprendre à apprendre Plutô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 ? combien de temps dois-je passer à retravailler et améliorer le code que j'ai écrit ? etc., mieux vaut apprendre à chacun à apprendre par soi même en fonction de chaque projet. Faible investissement au départ Allouer peu de ressources à un projet au départ force les clients et les déve- loppeurs à aller à l'essentiel et à dégager ce qui est réellement prioritaire et porteur de valeur. Jouer pour gagner L'état d'esprit dans lequel doit se placer une équipe XP peut être comparée à celui d'une équipe de football ou de basket : jouer pour gagner et non pour éviter de perdre. Des expériences concrètes Toute décision abstraite doit être testée. Dans cet ordre d'idée, le résultat d'une 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ête Il est essentiel que chacun puisse dire sans peur qu'une partie de code n'est pas optimale, qu'il a besoin d'aide, etc. Travailler avec et non contre les instincts de chacun Les gens aiment réussir, apprendre, interagir avec d'autres, faire partie d'une équipe, avoir le contrôle des choses. Les gens aiment qu'on leur fasse confiance. Les gens aiment faire un travail de qualité et voir leurs applica- tions fonctionner. XP cherche à offrir à chacun des moyens d’exprimer ces qualités au cours du projet\n24. Page 25/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Responsabilités acceptées Il 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âches sur la base du volontariat). Cela permet d'éviter les frustrations dans le cas où les responsabilités sont imposées et non délibérément choisies. Adaptation aux conditions locales Adopter XP ne signifie pas prendre à lettre la méthode mais intégrer ses principes pour l'adapter aux conditions particulières de chaque projet. Voyager léger Un développeur a tendance à transporter beaucoup de choses inutiles. Un débat est soulevé à ce sujet à propos des règles de nommage. Si certaines sont utiles et même indispensables, d'autres sont probablement des contrain- tes inutiles ou non respectées. Les simplifier pour ne garder que celles qui sont essentielles et utilisées par tous, c'est voyager plus léger. Mesures honnêtes La volonté de contrôler le déroulement d'un projet conduit a évaluer, mesurer certains 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 XP Planning game Cette 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 d'exploration, le client exprime ses besoins en termes de fonctionnalités. Pour cela, il les écrit sous forme de "user sto- ries", c'est à dire sous forme de courtes descriptions du comportement qu'il attend du système, exprimées avec un point de vue utilisateur. Au cours de cette même phase, les développeurs attribuent à chaque user story un nom- bre de points, fonction du temps qu'ils estiment nécessaire au développe- ment des fonctionnalités contenues dans chaque user story. S'il s'avère que les user stories nécessitent un temps de développement trop long, elles sont découpées en scénarios élémentaires. Dans une deuxième phase dite d'engagement, les user stories sont triées en fonction de la valeur qu'elles apportent au client et des risques encourus lors de leur développement. Ceci permet d'aboutir à un classement des user stories par ordre de priorité. En fonction de la vélocité de l'équipe, les déve- loppeurs et le client s'entendent sur la quantités de user stories qui seront développées au cours de l'itération à venir et qui constitueront la prochaine release. La vélocité évoquée ci-dessus est un indicateur du nombre de points qui peuvent être développées au cours d'une itération (elle se calcule en faisant le rapport du nombre de points développés au cours de l'itération\n25. Page 26/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 précédente et du produit du nombre de développeurs par la durée de l'ité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 estimations des développeurs afin de convenir du contenu de la prochaine release et de la date à laquelle elle devra être prête. Petites releases Pour une bonne gestion des risques, la sortie des releases doit intervenir le plus souvent possible. En conséquence, d'une version à l'autre, l'évolution doit être la plus petite possible, tout en s'efforçant d'apporter le plus de valeur ajoutée et des fonctionnalités dans leur intégralité. Utilisation de métaphores XP recommande d'utiliser des métaphores pour décrire l'architecture du sys- tème. De telles images permettent à tout le monde (y compris les commer- ciaux qui n'ont pas forcément de grandes compétences techniques) d'avoir une vision globale du système et d'en comprendre les éléments principaux ainsi que leurs interactions. Conception simple La simplicité est une des valeurs fondamentales d'XP. Il faut toujours déve- lopper la solution la plus simple possible et éviter de développer plus que ce dont on a besoin. Ceux qui pratiquent XP résument cela sous la phrase YAGNI ("You ain't gonna need it", « vous n’en aurez pas besoin »). Les seu- les exigences sont de satisfaire tous les tests, de ne jamais dupliquer une logique et d'utiliser le moins possible de classes et de méthodes. Dans ce même ordre d'idées, la documentation produite lors d'un projet XP se réduit au minimum vital, c'est à dire la documentation demandée par le client. Tests (unitaires et fonctionnels) Les tests unitaires sont écrits et effectués par les développeurs pour vérifier le 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'écrire les tests avant le code de l'application. Les tests fonctionnels sont conçus par le client et lui permettent d'une part de vérifier le fonctionnement global du système, de contrôler l'évolution du pro- jet, et d' d'affiner l'expression de ses besoins. Refactoring du code Les développeurs d'un projet XP doivent s'habituer à retravailler un peu cha- que jour du code existant et fonctionnant parfaitement pour le maintenir pro- pre, le rendre plus lisible et plus robuste.\n26. Page 27/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Le but de cette pratique est de simplifier le code, tout en faisant en sorte que tous les tests soient satisfaits. D'un point de vue purement fonctionnel, cette simplification n'est pas nécessaire puisqu'elle intervient sur du code qui fonc- tionne parfaitement. En revanche, le refactoring du code assure que l'ajout de fonctionnalités supplémentaires sera facilité. Le refactoring tend à pro- duire un code mieux pensé, plus modulaire, sans duplications de code et donc plus facile à maintenir. Programmation en binôme Toute 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 portion de code bien précise tandis que l'autre développeur, le "partner" peut obser- ver avec beaucoup plus de recul et ainsi suggérer d'autres solutions ou sou- lever des problèmes d'ordre plus général. Au premier abord, cette pratique peut sembler être une perte de temps, mais il s'avère que le travail se fait plus vite, que le code est de meilleure qualité (moins d'erreurs de syntaxe, meilleur découpage, etc.), avec une meilleure compréhension du problème. Pour les développeurs, le travail est moins fatiguant. Les binômes ne doivent pas être statiques : chacun change de partenaire relativement souvent. Ceci pour un meilleur partage des connaissances et pour permettre à chacun d'avoir une relativement bonne vision sur l'ensem- ble du code. Appropriation collective du code Toute l'équipe est sensée connaître la totalité du code (plus ou moins dans le détail selon les parties, évidemment). Cela implique que tout le monde peut intervenir pour faire des ajouts ou des modifications sur une portion de code qu'il n'a pas écrit lui même si cela s'avère nécessaire. Intégration continue Après chaque fin de tâche, c'est à dire plusieurs fois par jour, le code nouvel- lement écrit doit être intégré à l'existant de manière à avoir à tout moment un existant fonctionnel qui passe avec succès tous les tests. Ainsi, quand une tâche est démarrée, elle peut se fonder sur la version la plus à jour de ce qui a déjà été fait. Pas de surcharge de travail L'objectif est de ne pas dépasser 40 heures de travail par semaine pour les développeurs. Il ne s'agit pas de chercher à travailler peu, mais les spécialis- tes d' eXtreme Programming ont pris conscience du fait que la surcharge de travail, en plus d'être désagréable, est néfaste. En effet, le code devient moins bien pensé, le refactoring est laissé de côté, ce qui conduit à une baisse 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-\n27. Page 28/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 maines consécutives. Si cela devait toutefois se produire, l'équipe se doit de réagir en redéfinissant la quantité de user stories à implémenter au cours de l'itération ou en modifiant sa manière de procéder. Client sur site L'implication forte du client passe par la présence sur site d'une personne minimum à temps plein pendant toute la durée du projet. Cette personne doit avoir à la fois le profil type de l'utilisateur final et une vision plus globale du contexte 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 de réactivité. En effet, au fil de la programmation, les développeurs soulèvent fré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 qu'ils supposent être les désirs du client. La présence à temps plein du client sur site n'implique pas forcément que cette activité occupe la totalité de son temps : il est tout à fait envisageable pour le client de continuer une partie de son activité tout en étant délocalisé auprès de l'équipe de développeurs. Standards de code Il est nécessaire de disposer de normes de nommage et de programmation pour que chacun puisse lire et comprendre facilement le code produit par les autres. Ceci est d'autant plus essentiel que la propriété du code est collective et 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 vie Ce paragraphe donne une vision du cycle de vie idéal d'un projet XP. Plu- sieurs phases composent le cycle de vie d'une application.\n28. Page 29/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Figure 7 - Les grandes lignes du cycle de vie d'un projet XP Exploration Au cours de cette phase, les développeurs se penchent sur des questions d'ordre technique destinées à explorer les différentes possibilités d'architec- 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é s'habitue à exprimer ses besoins sous forme de user stories que les développeurs devront estimer en terme de temps de dévelop- pement. Planning Nous 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é "planning game". Le planning de la première release est fait de telle sorte qu'un système pour- vu uniquement des fonctionnalités essentielles soit mis en production dans un 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 release C'est la phase de développement à proprement parler de la première version de l'application. Celle ci se fait sous forme d'itérations de une à quatre se- maines. Exploration Planning MortMaintenanceItérations jusqu’à la première release itérations de 1 à 4 semaines Mise en production itérations de 1 semaine maintenance = ajouter des fonctionnalités à nouvelles releases utilise le même processus que pour la release 1\n29. Page 30/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Chaque itération produit un ensemble de fonctionnalités passant avec succès les tests fonctionnels associés. La première itération est dédiée à la mise en place de l'architecture du système. Ces itérations courtes permettent de détecter rapidement toute déviation par rapport au planning qui a été fait jusqu'à la sortie de la release. En cas de déviation, quelque chose est à revoir, soit au niveau de la méthode, soit au niveau 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 l'avancement du projet. Mise en production Les itérations de cette phase sont encore plus courtes, ceci pour renforcer le feedback. En général, des tests parallèles sont conduits au cours de cette phase et les développeurs procèdent à des réglages affinés pour améliorer les 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. Maintenance Il s'agit dans cette phase de continuer à faire fonctionner le système désor- mais existant et de lui adjoindre les fonctionnalités secondaires qui avaient volontairement été laissées de côté jusque là. Le développement de nouvelles fonctionnalités sur un système déjà mis en production requiert une prudence accrue de la part des développeurs et cette phase est donc cruciale. A chaque nouvelle release, une nouvelle phase d'exploration rapide doit avoir lieu. Mort La fin d'un projet intervient quand le client n'arrive 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 n'est plus capable de recevoir de modifica- tions pour satisfaire de nouveaux besoins tout en restant rentable.\n30. Page 31/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Figure 8 - Interactions entre les acteurs d'un projet XP 3.1.6 Rôles Développeur Il est l'élément principal d'un projet XP. En apparence, le développeur passe simplement 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. La principale qualité d'un développeur est sa capacité à communiquer. XP re- quiert aussi la capacité à travailler en binôme, aptitude qui n'est pas forcé- ment requise pour d'autres types de projets. Enfin, un développeur doit s'ha- bituer à la simplicité : construire la solution la plus simple et ne construire que ce qui est absolument nécessaire doit devenir un réflexe. Un développeur doit avoir d'autres compétences plus techniques : être capa- ble d'écrire du code propre, de pratiquer le refactoring, de recourir aux tests unitaires, etc. Enfin, XP requiert du courage de la part des développeurs. Client Le client est l'autre moitié du duo essentiel dans l'approche eXtreme Pro- gramming. Le développeur sait comment programmer et le client sait quoi programmer. Pour un projet XP, le client doit apprendre à exprimer ses besoins sous forme de user stories, à leur donner un ordre de priorité et à dégager ce qui est essentiel et valorisant pour lui. Dans l'idéal, le client a à la fois le profil de l'utilisateur et une vision plus éle- vée sur le problème et l'environnement du business dans lequel le projet s'inclut. Le client doit aussi apprendre à écrire les cas de tests fonctionnels et faire preuve, lui aussi, de courage. Client DéveloppeurDéveloppeur Client estime les coûts choisit ce qui doit être développé en priorité spécifie ses besoins développe les fonctionnalités demandées capitalise les connaissances\n31. Page 32/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 Testeur Étant donné que les tests unitaires sont à la charge des développeurs, le testeur a pour rôle d'aider le client à choisir et à écrire ses tests fonctionnels. Le testeur n'est pas une personne isolée, chargée de mettre le système en défaut et d'humilier les développeurs : il s'agit juste d'une personne chargée de faire passer régulièrement la batterie de tests. Tracker C'est un peu la conscience de l'équipe. Son rôle est d'aider l'équipe à mieux estimer le temps nécessaire à l'implémentation de chaque user story et de garder un œil sur le planning en relation avec l'avancement réel du projet. C'est en quelque sorte l'historien et le rapporteur de l'équipe, chargé de col- lecter toutes les informations qui peuvent s'avérer utiles. Coach Le coach a la responsabilité globale de tout le processus. Son rôle est de recadrer le projet, d'ajuster les procédures. Toute la difficulté de sa tâche réside dans le fait qu'il se doit d'intervenir de la manière la moins intrusive possible. Au fur et à mesure de la maturation de l'équipe, sont rôle diminue et l'équipe devient plus autonome. Consultant La programmation en binôme rend assez peu probable l'existence de domai- nes de compétences dans lesquels seuls un ou deux membres de l'équipe ont des connaissances suffisantes. C'est une force car cela rend l'équipe très flexible mais c'est aussi une faiblesse car la volonté de simplicité se fait par- fois au détriment de connaissances techniques très poussées. Quand le problème se présente, l'équipe a recours aux services d'un consultant. Le rôle d'un consultant est d'apporter à l'équipe les connaissances nécessaires pour qu'ils résolvent eux mêmes leur problème et non de leur apporter une solution toute faite. Big Boss Le Big Boss apporte à l'équipe courage et confiance. 3.1.7 Forces et faiblesses Extreme 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 petits projets. XP réalise des applications de qualité grâce à la rigueur imposée sur les tests, qui plus est collent au désirs du client puisque celui-ci est intégré au projet de A à Z. Aussi efficace qu'elle soit, la méthode XP n'est pas applicable dans tous les cas. Dans le cadre d'un projet de type forfaitaire où le prix, les délais et les besoins sont fixés, XP ne peut pas réellement être mise en œuvre. Le cas d'une équipe supérieure à une douzaine de personnes est un autre exemple\n32. Page 33/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 où XP est difficilement adaptable car le nombre risque de ralentir, d'alourdir les 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, l'investissement demandé au client est très important puisqu'il doit déléguer une personne à temps plein sur le lieu où est développée l'application, avec toutes les conséquences que cela induit. En ce qui concerne les développeurs, la prati- que de la programmation en binôme n'est pas forcément très bien ressentie par tous. Or un projet XP ne peut pas être un franc succès si tous ses parti- cipants n'adhèrent pas pleinement à la méthode. Avant de se lancer dans un tel projet, il faudra tout d'abord convaincre le client et motiver l'équipe ce qui n'est pas toujours aisé. 3.2 DYNAMICSOFTWAREDEVELOPMENTMETHOD(DSDM) 3.2.1 Les origines de DSDM La 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 trop longs, que les applications livrées ne correspondaient pas toujours exacte- ment aux besoins, que les développeurs étaient peu impliqués dans la conception et que personne n'avait de vue complète des systèmes dévelop- pés. DSDM s'appuie aujourd'hui sur une association loi 1901, indépendante et à but non lucratif, dont le but est de développer et de promouvoir une méthode pour le développement rapide d'applications. Il s'agit d'une approche dyna- mique qui requiert l'implication des utilisateurs. C'est à la suite d'une initiative britannique en 1994 qu'est née DSDM. L'ap- proche ayant été adoptée par des entreprises prestigieuses comme British Airways, Barclays Bank, Marks and Spencer, etc., l'association a connu une croissance exponentielle et fait preuve aujourd'hui d'une volonté de diffusion internationale. 3.2.2 9 principes fondamentaux 1. L'implication active des utilisateurs est impérative DSDM part du principe qu'une implication forte des utilisateurs est néces- saire pendant tout le cycle de vie pour éviter des retards dans la prise de décision. Les utilisateurs ne sont pas considérés comme de simples fournis- seurs d'information mais bien comme des acteurs à part entière de l'équipe. 2. Les équipes DSDM doivent être autorisées à prendre des décisions Dans le cadre de la méthode DSDM, une équipe regroupe des développeurs et des utilisateurs. Cette équipe doit être capable de prendre des décisions sur l'évolution et la modification des besoins et de déterminer le niveau de fonctionnalité sans demander l'aval de la direction.\n33. Page 34/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 3. Le produit est rendu tangible aussi souvent que possible Pour des raisons de flexibilité, DSDM se fonde sur la livraison fréquente de fournitures. Les délais sont volontairement pris très courts ce qui force à définir quelles sont les activités qui permettront d'atteindre les résultats priori- taires dans le temps imparti. 4. L'adéquation au besoin métier est le critère essentiel pour l'accepta- tion des fournitures L'objectif de DSDM est de livrer à temps des fonctions métiers qui permettent de satisfaire les besoins de l'entreprise. L'élaboration d'un système plus glo- bal n'est pas une priorité : elle peut être réalisée après coup. 5. Un développement itératif et incrémental permet de converger vers une solution appropriée Le principe d'évolution incrémentale des systèmes permet de tirer un meilleur parti du contact entre développeurs et utilisateurs. Cette manière de procéder permet un retour permanent des utilisateurs vers les développeurs et une meilleur 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 livraison de solutions partielles pour répondre à des besoins immédiats. 6. Toute modification pendant la réalisation est réversible Il 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 reconstruire que de revenir en arrière. Il importe de s'efforcer de rendre toute transforma- tion réversible. 7. Les besoins sont définis à un niveau de synthèse Le 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 vie Les tests font partie intégrante de l'activité de développement. Ils servent à valider au fur et à mesure du développement du système que celui-ci est opérationnel tant sur le plan technique que fonctionnel. En fin de cycle, les tests sont les garants du bon fonctionnement du système. 9. Un esprit de coopération entre tous les acteurs est primordial Dans la démarche DSDM les fonctions détaillées ne sont pas figées dès le départ. Le demandeur et le réalisateur doivent faire preuve de souplesse tout au long du cycle de vie, ce qui implique la nécessité d'avoir une procédure de gestion des modifications peu contraignante.\n34. Page 35/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 3.2.3 5 phases DSDM se définit plus comme un "canevas" que comme une méthode, c'est à dire qu'elle ne fournit que "l'ossature" du processus global et une description des 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 : — L'Etude de Faisabilité — L'Etude du " Business " — Le Modèle Fonctionnel itératif — La conception et le développement itératifs — La Mise en œuvre dans l'environnement de travail. Figure 9 - Cycle de vie d'un projet DSDM L'Etude de Faisabilité et l'Etude du "Business" sont réalisées de manière séquentielle. Comme elles établissent les règles de base pour le reste du développement elles doivent être terminées avant que les trois autres phases itératives ne démarrent. Les trois phases suivantes peuvent converger ou se chevaucher 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 livrables répondant à un besoin bien précis. L'Etude de Faisabilité Première tâche à accomplir : déterminer si DSDM est l'approche qui convient pour le projet considéré. C'est dans cette phase que le problème à résoudre est posé. Il faut ensuite évaluer les coûts et d'un point de vue technique, l'aptitude 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 laisse pas suffisamment de temps pour produire une documentation volumineuse. Le Rapport de Faisabilité couvre donc les thèmes habituels mais avec peu de détails. L'Etude de Faisabilité produit aussi un Plan Global de développe- ment, qui vient renforcer l'hypothèse que l'objectif fixé est réalisable et, de Modèle Fonctionnel Itératif Mise en Oeuvre Conception et Réalisation Itératives Étude de Faisabilité Étude de Business\n35. Page 36/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 manière facultative, un Prototype de faisabilité pour montrer que la solution est réalisable. L'Etude du Business L'étude du Business ou étude des besoins industriels doit elle aussi être aussi courte que possible. Elle a pour but de permettre la compréhension suffisamment approfondie des besoins et des contraintes techniques pour ne pas mettre en péril la suite du déroulement du projet. Cette phase permet l'étude des processus à automatiser et des besoins en informations. Cette étude passe par l'organisation d'Ateliers Facilités (travail collectif animé par un médiateur) dont le rôle est de dégager la Définition du Domaine Industriel qui répertorie non seulement les processus de l'entreprise et informations associées mais aussi les classes (ou types) d'utilisateur qui seront concernées d'une manière ou d'une autre par la mise en place du système. Ces classes permettent d'identifier les utilisateurs qui participeront au développement. Ces utilisateurs auront pour responsabilité d'une part de fournir les informations nécessaires au projet et d'autre part de tenir l'ensem- ble de la communauté informatique au courant de son évolution. Les Ateliers Facilités permettent aussi de classer par ordre de priorité toutes les fonction- nalités à développer. L'ordre de priorité repose principalement sur le degré d'urgence des besoins métiers, mais il peut aussi intégrer des besoins non fonctionnels tels que la sécurité par exemple. La Définition de l'Architecture Système, qui décrit aussi bien les plates- formes opérationnelles et de développement que l'architecture du logiciel développé (c'est à dire les principaux composants et interfaces associées), est un autre élément essentiel de L'étude du Business. La définition de l'ar- chitecture à ce niveau est indispensable car certains modules commenceront à être développés dès l'étape suivante. Bien entendu, la Définition de l'Archi- tecture Système est susceptible d'être ajustée au cours des phases ultérieu- res. Enfin, le Plan Global issu de l'Etude de Faisabilité est détaillé pour créer le plan Global de Prototypage qui décrit le mode de développement à utiliser au cours des deux phases suivantes ainsi que le mode de contrôle et de tests à mettre en oeuvre. Modèle Fonctionnel Itératif Le Modèle Fonctionnel Itératif a pour but de préciser la définition de tous les aspects du système qui sont liés au business. Il consiste en une description plus précise des besoins de haut niveau, à la fois en termes de traitement et d'information. Cette phase produit aussi bien des modèles d'analyse 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.\n36. Page 37/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 4. Vérifier qu'il a été développé de manière appropriée (par le biais de tests et à 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é d'utilisation. Ils subissent des tests au fur et à mesure de leur production : ceci sous-entend les tests techniques unitaires ainsi que des mini-tests de recettes effectués directement par les utilisateurs. Les tests permettent de déterminer si les composants produits peuvent ou non être réutilisables et servir 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égralement un domaine fonctionnel et ses aspects non fonctionnels avant de passer à un autre domaine. Selon la manière dont l'application a été découpée en divers modules 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ératives Le passage du Modèle Fonctionnel à La Conception et au Développement est subordonné à l'accord sur un Prototype Fonctionnel présentant tout ou partie du Modèle Fonctionnel. Si ce prototype ne présente qu'une partie du modè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 de rendre le système conforme à des standards assurant qu'il 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 l'ajout d'une phase de test à la fin de chaque itération, mais DSDM préconise l'étalement des tests au fur et à mesure des phases "Modèle Fonctionnel Itératif" et "Conception et Réalisation Itératives". Le Système testé n'est pas forcément complet sur le plan fonctionnel mais il se doit de satisfaire les besoins qui ont été définis comme prioritaires pour l'étape en cours. Mise en Œuvre C'est au cours de la phase de Mise en Oeuvre qu'est effectuée la migration du système de l'environnement de développement à l'environnement opéra- tionnel. Cette phase inclut également la formation des utilisateurs n'ayant pas pris 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 est finalisée durant cette phase mais elle doit avoir été commencée durant la phase Conception et Réalisation Itératives. C'est l'une des responsabilités des utilisateurs ambassadeurs que de s'assurer de la qualité de la documen- tation et de la formation utilisateur. Le Document de Capitalisation de Projet est l'autre produit de cette phase. Il permet 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 :\n37. Page 38/72 Business Interactif EXTREME PROGRAMMING - METHODES AGILES : L'ETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc © Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1 1. Tous les besoins ont été satisfaits. Aucune autre tâche supplémentaire n'est donc nécessaire. 2. Un aspect fonctionnel important a été provisoirement ignoré. Il faut dans ce cas revenir à la phase Etude du business et re-dérouler le processus à partir de là. 3. Une fonctionnalité à faible priorité a été délibérément ignorée. Pour l'ajou- ter, il suffit de revenir à la phase Modèle fonctionnel itératif. 4. Un aspect technique mineur a également été délaissé : il peut à présent être traité en revenant à la phase Conception et Réalisation Itératives. 3.2.4 Les rôles DSDM définit de manière très précise des rôles à attribuer aux différentes personnes qui vont prendre part au projet. Il est important de noter qu'un rôle ne correspond pas nécessairement à une et une seule personne physique. En fonction de la taille du projet, une personne peut se voir attribuer plusieurs rôles et un même rôle peut être tenu par plusieurs personnes. Figure 10 - Les rôles dans une équipe DSDM Rôles Responsabilité Sponsor exé- cutif Assurer l'efficacité et la rapidité du processus décisionnel Réagir aux questions de progression Assurer la disponibilité des fonds et autres ressources Contrôler le maintien de l'adéquation du projet au business Engagement et disponibilité pendant tout le cycle de déve- loppement Visionnaire Promouvoir la traduction de la vision en pratique de travail Avoir une vision plus large de bout en bout du processus du Participent à temps complet Chef de projet Chef d’équipe Utilisateur Ambassadeur Développeur Rapporteur Coordinateur technique Développeur senior Visionnaire Utilisateur Conseiller Sponsor Exécutif Facilitateur Ne participent qu’à temps partiel