Your SlideShare is downloading. ×
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Pmbok methodes agiles
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Pmbok methodes agiles

2,507

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,507
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
178
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Page 2/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Table des matières1. INTRODUCTION .............................................................................................4Business Interactif en quelques mots ....................................................................4Pourquoi un white paper sur les méthodes agiles ?...........................................42. LES METHODOLOGIES AGILES : GENERALITES .........................52.1 CONTEXTE.........................................................................................................52.2 CARACTERISTIQUES COMMUNES DES METHODES AGILES..........................52.2.1 Priorité aux personnes et aux interactions sur les procédures et lesoutils 62.2.2 Priorité aux applications fonctionnelles sur une documentationpléthorique.................................................................................................................72.2.3 Priorité de la collaboration avec le client sur la négociation decontrat 72.2.4 Priorité de l’acceptation du changement sur la planification.........72.3 DES METHODES RAD (RAPID APPLICATION DEVELOPMENT ) AUXMETHODES AGILES, UNE FILIATION ?.......................................................................102.3.1 Origines du RAD ...................................................................................102.3.2 Les acteurs du RAD...............................................................................102.3.3 Les cinq phases dun projet RAD........................................................132.3.4 RAD et modélisation.............................................................................142.3.5 Pourquoi le RAD nest il pas à proprement parler une méthode"agile" ? 142.4 DE UNIFIED PROCESS (UP & RUP) A L’AGILITE, UNE FILIATION ?.......152.4.1 Les 5 principes dUP.............................................................................152.4.2 Les activités dans la méthode UP.......................................................172.4.3 Les phases du cycle de vie....................................................................182.4.4 Pourquoi UP nest pas à proprement parler une méthode agile ?192.5 LA SITUATION EN FRANCE : UN FORT ANCRAGE DE LA METHODE MERISEET DE LA MODELISATION ENTITE-RELATION...........................................................203. PRINCIPALES METHODOLOGIES AGILES, ETAT DES LIEUX,COMPARAISON..........................................................................................................223.1 EXTREME PROGRAMMING (XP) ...................................................................223.1.1 Aux origines deXtreme Programming...............................................223.1.2 Les 4 valeurs deXtreme Programming .............................................223.1.3 Principes de base...................................................................................233.1.4 Les 12 pratiques XP..............................................................................253.1.5 Cycle de vie.............................................................................................283.1.6 Rôles ........................................................................................................313.1.7 Forces et faiblesses ...............................................................................323.2 DYNAMIC SOFTWARE DEVELOPMENT METHOD (DSDM).......................333.2.1 Les origines de DSDM ..........................................................................333.2.2 9 principes fondamentaux....................................................................333.2.3 5 phases...................................................................................................353.2.4 Les rôles ..................................................................................................383.2.5 Forces et faiblesses de la méthode.....................................................413.3 ADAPTIVE SOFTWARE DEVELOPMENT........................................................41
  • 2. Page 3/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.13.3.1 Contexte...................................................................................................413.3.2 Les 6 caractéristiques principales dASD..........................................413.3.3 Le cycle de vie selon Adaptive Software Development...................433.3.4 Forces et faiblesses ...............................................................................453.4 CRYSTAL METHODOLOGIES...........................................................................453.4.1 Origine.....................................................................................................453.4.2 Les valeurs partagées par léquipe.....................................................463.4.3 Processus Crystal..................................................................................473.4.4 Forces et faiblesses ...............................................................................483.5 SCRUM..............................................................................................................493.5.1 Les origines de Scrum...........................................................................493.5.2 Le processus Scrum : vue générale....................................................493.5.3 Les "sprints" ...........................................................................................513.5.4 Forces et faiblesses ...............................................................................533.6 FEATURE DRIVEN DEVELOPMENT ...............................................................543.6.1 Les grandes lignes de la méthode.......................................................543.6.2 La notion de "feature" et de "feature set".........................................543.6.3 Les 5 phases dun projet FDD .............................................................553.6.4 Forces et faiblesses ...............................................................................603.7 RECAPITULATIF : COMPARATIF DES METHODES AGILES...........................603.7.1 Adaptation des méthodes à la taille des projets et des équipes.....603.7.2 Degré dexigence des méthodes agiles pour le client......................623.7.3 Facilité de mise en œuvre et contraintes en interne ........................634. LES METHODES AGILES VUES PAR BUSINESS INTERACTIF664.1 LES METHODES AGILES SONT ELLES VRAIMENT NOUVELLES ?................664.2 LA BONNE METHODE POUR LE BON PROJET ................................................664.2.1 Un exemple : la modélisation de données.........................................674.3 QUELLES SONT LES MAUVAISES METHODES ?............................................674.4 QUELQUES POINTS CLES CROSS METHODES...............................................674.4.1 Petites équipes et outils véloces..........................................................674.4.2 Polyvalence des développeurs.............................................................684.4.3 Feedback client et itérations................................................................684.4.4 Gestion des risques................................................................................684.4.5 Maîtrise d’ouvrage et maîtrise d’œuvre jouent dans le même camp684.4.6 Tester toujours et encore......................................................................694.5 LA CULTURE ET LES VALEURS......................................................................704.5.1 La culture de l’humilité........................................................................704.5.2 Le pragmatisme......................................................................................704.5.3 Le souci de la qualité............................................................................704.5.4 Le partage...............................................................................................704.5.5 Le courage..............................................................................................714.6 CONCLUSION...................................................................................................714.7 CHOISIR ET METTRE EN ŒUVRE LES METHODES.........................................724.8 COLLABORER AVEC BUSINESS INTERACTIF................................................72Les noms de produits ou de sociétés cités dans ce document peuvent faire l’objet d’un dépôt de marque par leurpropriétaires respectifs.
  • 3. Page 4/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Nous sommes heureux de vous présenter notrenouveau white paper sur les méthodes agiles degestion de projet et de développement, ExtremeProgramming étant probablement la plus connue deces méthodes. Dans un contexte économique plustendu, le succès des projets informatiques devienttoujours plus critique. La démarche méthodologiqueadoptée joue pour beaucoup dans le succès de cesprojets. Les méthodes agiles constituent elles lenouvel eldorado ? Business Interactif fait le point surle sujet…Business Interactif en quelques motsBusiness Interactif conçoit et réalise de grands projets e-business à fortecomposante technologique, couvrant les aspects front, middle et back-office.Avec plus de 220 collaborateurs, dont 60% sur les aspects technologiques,Business Interactif accompagne ses clients sur des projets stratégiques enFrance et à l’étranger (Bureaux à Paris, Lyon, New-York, Tokyo et Rio).Deux références symbolisent à elles seules l’étendue du savoir-faire de Bu-siness Interactif : OOSHOP.COM d’un côté (réalisation de l’ensemble duprojet, tant sur les aspects Front que Middle et Back-Office),LANCOME.COM de l’autre. Que ce soit pour des projets à haute technicitéou nécessitant une valeur ajoutée marketing et créatrice hors-pair, BusinessInteractif s’est peu à peu imposé comme l’un des acteurs clé sur le marchéde l’e-business. Pour plus de renseignements, nous vous invitons à consulternotre site : www.businessinteractif.frPourquoi un white paper sur les méthodes agiles?Au cours des huit dernières années, nos équipes ont contribué à la réussitede grands projets E-business, dans une logique de maîtrise d’œuvre. L’unedes étapes clé dans le développement de notre société a été la mise enœuvre d’un Plan Assurance Qualité permettant d’offrir à nos clients un hautniveau de service. La gestion d’un projet et les méthodes de développementoptimales sont des préoccupations récurrentes dans notre métier. Nosgrands projets sont réalisés en s’appuyant sur des méthodes éprouvées,tirées notamment de Merise pour la conception des modèles de données, deRAD pour la gestion de projet et le maquettage, d’UML pour la conceptionobjets/composants. Nous avons au fil des années tiré le meilleur de ces diffé-rentes approches pour les adapter au contexte des projets e-business.La montée en puissance de méthodes dites «nouvelles », les méthodesagiles, ne pouvait nous laisser insensibles. A ce titre, comme nous l’avionsfait pour le Knowledge Management, il nous a paru intéressant de faire par-tager par le biais d’un White Paper notre vision de ce sujet : cartographie desméthodes, mais aussi retours d’expérience!Jean-Louis Bénard, directeur technique de Business Interactif.1. INTRODUCTION
  • 4. Page 5/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.12.1 CONTEXTELes méthodes de gestion de projet informatique connaissent, au même titreque les technologies mises en œuvre, une remise en cause permanente.La proportion importante d’échec des projets vient souvent alimenter desréactions plus ou moins constructives aux méthodes mises en œuvre. Lesévolutions des architectures technologiques et des outils de développement ycontribuent également pour part importante.Ainsi, UML et Unified Process sont venues en réaction aux méthodes dites« merisiennes » (cycle en V, etc.) à la fois poussées par les technologiesobjet et les insuffisances de méthodes préconisant des cycles très longs.Les méthodes agiles n’échappent pas à la règle. Mais elles s’inscrivent dansune démarche plus radicale, que l’on pourrait résumer par «trop de méthodetue la méthode ».De manière générale, leur but est daugmenter le niveau de satisfaction desclients tout en rendant le travail de développement plus facile. Mais les véri-tables fondements des méthodes agiles résident plus précisément dans deuxcaractéristiques :— Les méthodes agiles sont "adaptatives" plutôt que prédictivesSi les méthodes lourdes tentent d’établir dès le début d’un projet un planningà la fois très précis et très détaillé du développement sur une longue périodede temps, cela suppose que les exigences et spécifications de base restentimmuables. Or, dans tous les projets, les exigences changent au cours dutemps et le contexte évolue aussi. Par conséquent, si elles fonctionnent surdes projets courts et de petite taille, ces méthodologies sont trop réfractairesau changement pour pourvoir être appliquées à des projets plus importants.A l’inverse, les méthodes agiles se proposent de réserver un accueil favora-ble au changement : ce sont des méthodes itératives à planification souplequi leur permettent de s’adapter à la fois aux changements de contexte et despécifications du projet.— Les méthodes agiles sont orientées vers les personnes plutôt que versles processusLes méthodes agiles s’efforcent de travailler avec les spécificités de chacunplutôt que contre la nature de chacun pour que le développement soit uneactivité plaisante où chacun se voit confier une part de responsabilité.Nées en réaction aux méthodes traditionnelles, il existe une grande diversitéde méthodes auxquelles ont peut donner le qualificatif d’agile. Avant de pas-ser en revue les spécificités de chacune parmi les principales d’entre ellesdans une seconde partie, essayons tout d’abord de dégager les principalescaractéristiques communes à toutes ces méthodes, autrement dit : qu’est cequi fait qu’une méthode de développement est une méthode agile ?2.2 CARACTERISTIQUESCOMMUNES DES METHODES AGILESTrès récemment, en février 2001, les instigateurs des principales méthodesagiles se sont réunis pour former l’ "Agile Alliance" (http://agilealliance.org).Ensemble, ils ont pu dégager des principes fondamentaux sur lesquels2. LESMETHODOLOGIESAGILES :GENERALITES
  • 5. Page 6/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1s’appuyer pour que le développement puisse se faire rapidement et s’adapterau changement.Leur travail a abouti au "Manifeste pour le développement agiled’applications" :Manifesto for Agile Software DevelopmentWe are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items onthe right, we value the items on the left more.Ce manifeste, comme on peut le voir, comporte quatre valeurs principa-les détaillées ci-dessous.Les paragraphes suivants ont pour objet de présenter les méthodes agiles,telles qu’elles ont été conçues par les membres de l’Agile Alliance, ils netraduisent pas spécifiquement la position de Business Interactif sur lesujet.2.2.1 Priorité aux personnes et aux interactions sur les procédures etles outilsLa meilleure garantie de succès réside dans les personnes : même unebonne méthode, de bonnes procédures ne sauveront pas un projet del’échec si l’équipe n’est pas constituée de personnes adéquates et ouvertes.Par contre, une mauvaise méthode peut conduire une équipe parfaite àl’échec. Pour constituer une équipe, pas besoin de génies du développe-ment : un programmeur moyen, mais doué de capacités à travailler engroupe et à communiquer est un bien meilleur équipier.La gestion de projet a longtemps établi la «méthode » comme le vecteuressentiel de succès d’un projet. Cette méthode a souvent pris la forme deprocédures. L’importance accordée aux outils supports de la gestion de pro-jets s’est également renforcée au détriment de l’individu.Utiliser les outils appropriés (compilateurs, environnements de développe-ment, outils de modélisation, etc.) peut être décisif. En revanche, l’utilisationd’outils surdimensionnés ou faisant de l’homme un simple instrument de ladémarche est aussi néfaste que le manque d’outils appropriés.Opposés à une approche trop outillée, les membres de l’AgileAlliance affir-ment que la meilleure garantie de succès réside dans les personnes : mêmeune bonne méthode, de bonnes procédures ne sauveront pas un projet de
  • 6. Page 7/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1l’échec si l’équipe n’est pas constituée de personnes très impliquées dans leprojet. Pour constituer une équipe, pas besoin de génies du développement :un programmeur moyen, mais doué de capacités à travailler en groupe et àcommuniquer est un bien meilleur équipier. Ce sont avant tout les interac-tions, les initiatives et la communication interpersonnelles qui feront le suc-cès.2.2.2 Priorité aux applications fonctionnelles sur une documentationpléthoriqueLes partisans des méthodes agiles affirment la légitimité d’une certaine formede documentation mais ils dénoncent les effets pervers d’une documentationpléthorique. En effet, l’écriture et le maintien à niveau de la documentationsont extrêmement consommateurs de ressources. Un document qui n’estpas mis à jour régulièrement devient très rapidement totalement inutile, voiremême trompeur. Le manifeste est donc favorable aux documentations suc-cinctes, ne décrivant que les grandes lignes de l’architecture du systèmemais régulièrement tenues à jour, et d’une documentation permanente ducode lui-même. Le meilleur transfert des connaissances sur le systèmes’effectue de toute manière par la participation au travail de l’équipe.2.2.3 Priorité de la collaboration avec le client sur la négociation decontratLe succès d’un projet requiert un feedback régulier et fréquent de la part duclient. Un contrat qui spécifie les exigences, le planning et le coût d’un projeta priori relève d’une vision utopique d’une projet informatique. La meilleuremanière de procéder pour le client est de travailler en étroite collaborationavec l’équipe de développement, pour lui fournir un feedback continu quiassure un meilleur contrôle du projet. Ainsi, des modifications de spécifica-tions peuvent intervenir très tard dans le cycle de développement du projet.C’est en définitive une solution répondant réellement aux attentes du clientqui est réalisée et non une solution répondant aux exigences d’un contratétabli a priori. Nous le verrons en synthèse, ce point ne reste pas simple àmettre en œuvre. Cela nécessite bien sûr une grande maturité du client et duprestataire de service afin d’établir une réelle relation de confiance, ainsiqu’une bonne compréhension de la réalité opérationnelle du projet par lesjuristes en charge du dossier.2.2.4 Priorité de l’acceptation du changement sur la planificationC’est la capacité à accepter le changement qui fait bien souvent la réussiteou l’échec d’un projet. Lors de la planification, il est donc nécessaire de veil-ler à ce que le planning soit flexible et adaptable aux changements qui peu-vent intervenir dans le contexte, les technologies et les spécifications.En effet il est très difficile de penser dès le début à toutes les fonctionnalitésdont on aimerait disposer et il est très probable que le client modifie ses exi-gences une fois qu’il aura vu fonctionner une première version du système.
  • 7. Page 8/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Figure 1 - Positionnement des méthodes par rapport aux quatre critèresagilesLes quatre valeurs ci-dessus sont en fait déclinées sur douze principes plusgénéraux qui caractérisent en détail les méthodes agiles :— "Notre priorité est de satisfaire le client en lui livrant très tôt et régulière-ment des versions fonctionnelles de l’application source de valeur"Les méthodes agiles recommandent de livrer très tôt, dans les premièressemaines si possible une version rudimentaire de l’application puis de livrersouvent des versions auxquelles les fonctionnalités s’ajoutent progressive-ment. De cette manière, le client peut décider à tout moment la mise en pro-duction de l’application, dès qu’il la considère comme assez fonctionnelle. Achaque version (release), un feedback de la part du client est nécessairepour permettre soit de continuer le développement comme prévu, soitd’opérer des changements. De cette manière, les changements dans lesspécifications interviennent tôt dans le processus de développement et sontmoins problématiques.— "Accueillir le changement à bras ouverts, même tard dans le processusde développement. Les méthodologies agiles exploitent les change-ments pour apporter au client un avantage concurrentiel"Ceci est un état d’esprit nécessaire : tout changement des exigences doitêtre perçu comme une bonne chose car cela signifie que l’équipe a compriset appris comment satisfaire encore mieux la demande.Le but des méthodes agiles est de produire des systèmes très flexibles, desorte que l’impact sur le système d’une évolution des spécification resteminimal.Ressourceshumaines etcommunicationProcessuset outilsApplicationsfonctionnellesDocumentationCollaborationétroite avec leclientNégociationde contratAccueil duchangementPlanificationrigide
  • 8. Page 9/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1— "Livrer le plus souvent possible des versions opérationnelles del’application, avec une fréquence comprise entre deux semaines et deuxmois"Ne pas se contenter de livrer des liasses de documents décrivantl’application : il faut constamment garder pour objectif de livrer le plus rapi-dement possible au client une solution qui satisfasse ses besoins.— "Clients et développeurs doivent coopérer quotidiennement tout au longdu projet"Pour qu’un projet puisse être considéré comme agile, il faut qu’il y ait uneinteraction permanente entre le client, les développeurs : c’est ce qui guidecontinuellement le projet.— "Construire des projets autour d’individus motivés. Leur donnerl’environnement et le support dont ils ont besoin et leur faire confiancepour remplir leur mission"Dans un projet agile, les personnes sont considérées comme le facteur cléde succès. Tous les autres facteurs, processus, environnement, manage-ment sont susceptibles d’être changés s’ils s’avèrent être une entrave au bonfonctionnement de l’équipe.— "La méthode la plus efficace de communiquer des informations à uneéquipe et à l’intérieur de celle-ci reste la conversation en face à face"Le mode de communication par défaut au sein d’une équipe agile est laconversation et non l’écrit. Des documents peuvent bien sûr être rédigésmais ils n’ont en aucun cas pour but de consigner par écrit la totalité desinformations relatives au projet. Même les spécifications peuvent très bien nepas être écrites de manière formelle.— "Le fonctionnement de l’application est le premier indicateurd’avancement du projet"Contrairement à d’autres méthodes, l’avancement du projet ne se mesurepas à la quantité de documentation rédigée ni en terme de phase dans la-quelle il se trouve mais bien en terme de pourcentage de fonctionnalitéseffectivement mises en place.— "Les méthodes agiles recommandent que le projet avance à un rythmesoutenable : développeurs et utilisateurs devraient pouvoir maintenir unrythme constant indéfiniment"Il ne s’agit pas de sprinter sur 100 mètres, mais plutôt de tenir la distance surun marathon : l’équipe se doit donc d’adapter son rythme pour préserver laqualité de son travail sur toute la durée du projet.— "Porter une attention continue à l’excellence technique et à la conceptionaméliore l’agilité"La meilleure façon de développer rapidement est de maintenir le code sourcede l’application aussi propre et robuste que possible. Les membres del’équipe doivent donc s’efforcer de produire le code le plus clair et le pluspropre possible. Ils sont invités à nettoyer chaque jour le code qu’ils ont écrit.— "La simplicité – art de maximiser la quantité de travail à ne pas faire – estessentielle"
  • 9. Page 10/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Rien ne sert d’essayer d’anticiper les besoins de demain. Au contraire, il fautconstruire le système le plus simple répondant aux besoins actuels pour quecelui-ci soit facilement adaptable dans le futur.— "Les meilleures architectures, spécifications et conceptions sont le fruitd’équipes qui s’auto organisent"Les responsabilités ne sont pas confiées à quelqu’un en particulier mais àl’équipe dans son intégralité. Les membres de l’équipe prennent ensuite leursresponsabilités et se partagent les tâches sur le principe du volontariat.— "A intervalles de temps réguliers, l’ensemble de l’équipe s’interroge surla manière de devenir encore plus efficace, puis ajuste son comporte-ment en conséquence"Une équipe agile est consciente que son environnement est en perpétuelleévolution. C’est pourquoi elle ajuste continuellement son organisation, sesrègles, son fonctionnement, etc. de manière à rester agile.2.3 DESMETHODESRAD(RAPID APPLICATIONDEVELOPMENT) AUX METHODES AGILES, UNE FILIATION ?2.3.1 Origines du RADLe RAD (Rapid Application Development) est né dans les années 80 à lasuite dun double constat. Dune part, le manque de concertation entre lesinformaticiens en charge de la réalisation dun projet et les utilisateursconduit souvent à la réalisation dapplications mal adaptées aux besoins.Dautre part les méthodes classiques de conduite de projet sont inadaptées àla vitesse des évolutions technologiques et la durée des projets est beaucouptrop longue.Les objectifs premiers du RAD sont de conduire à lamélioration de la qualitédes développements tout en réduisant les délais et en facilitant la maîtrisedes coûts. Pour cela, il est nécessaire dassocier méthodologie et relationshumaines. Le RAD est fondamentalement une méthode basée sur la com-munication.Les concepts du RAD ont été définis par James Martin avant dêtre repris etadaptés au contexte français par Jean Pierre Vickoff dès 1989.A ses début, le RAD a souvent été qualifié de "chaotique" et considérécomme une "absence de méthode" plutôt que comme une méthode. Si leRAD a souffert dune si mauvaise image, cest avant tout lié à la notion derapidité quon a souvent tendance à considérer, à tort, comme incompatibleavec celle de qualité. Pour éviter ce malentendu, Jean Pierre Vickoff proposede traduire RAD par "développement maîtrisé dapplications de qualité ap-prouvée par les utilisateurs".2.3.2 Les acteurs du RADDans un projet RAD, la répartition des rôles est très structurée. Comme dansune approche classique, lensemble de lorganisation sappuie sur un principefondamental : la séparation des rôles opérationnels et des responsabilitésentre dune part la maîtrise douvrage (MOA) qui représente lutilisateur et àce titre détermine les fonctionnalités à développer et leur degré de priorité et
  • 10. Page 11/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1dautre part la maîtrise dœuvre (MOE) qui apporte les solutions techniquesaux problèmes posés par la maîtrise douvrage. (Cette séparation des rôlesest encore renforcée par la présence du Groupe danimation et de RapportRAD qui se charge dorganiser la communication du projet. Son rôle principalest de faciliter lexpression des exigences et de les formaliser en temps réel.La maîtrise douvrageLa maîtrise douvrage a trois responsabilités principales :— Définir les objectifs et les exigences du système : le maître douvrage,qui préside le comité de pilotage est responsable de la rédaction de do-cuments de cadrage dans lesquels sont explicités les objectifs dordrestratégique, fonctionnel, technologique, organisationnel, ainsi que lescontraintes de projet. Ces objectifs, classés par ordre de priorité serventde base pour la prise de décisions de pilotage. Le maître douvrage spé-cifie aussi les exigences en déléguant leur mise en forme à diverses per-sonnes compétentes : par exemple, les exigences fonctionnelles sontexprimées par des représentants dutilisateurs et des experts fonction-nels.— Valider les solutions proposées et élaborées : en collaboration avec lespersonnes qui ont exprimé les exigences, le maître douvrage vérifie quela ou les solutions proposées par la maîtrise dœuvre permettent bien desatisfaire ces exigences.— Préparer et piloter le changement induit : il sagit là dopérations desensibilisation, formation, communication ainsi que dorganisation.Au sein de la maîtrise douvrage, on peut distinguer trois acteurs principaux :— Maître douvrage : prend des décisions sur les objectifs (produit, coût,délai) et les orientations du projet et décide in fine lexpression des exi-gences et la validation des solutions ainsi que les moyens à mettre enœuvre au sein de la maîtrise douvrage.— Coordinateur de Projet Utilisateurs ou Maître dOuvrage délégué : coor-donne et valide les activités de la maîtrise douvrage. Réalise le suivi desobjectifs (produits, coûts / charges, délais) et des activités de la maîtrisedouvrage.— Responsable de la cohérence et de la qualité fonctionnelle : superviselexpression des exigences et de la validation des solutions, contrôle lacohérence des décisions prises dans les domaines fonctionnels. Super-vise la vérification de la qualité fonctionnelle (point de vue utilisateurs)des solutions proposées et élaborées.La maîtrise dœuvreElle a également trois responsabilités principales :— Proposer et réaliser la solution : cela passe notamment par la définitionet la mise en œuvre du planning et des moyens humains et logistiquesnécessaires— Livrer des "fonctionnalités" : on entend par fonctionnalités les produitsfinis mais aussi des produits intermédiaires et diverses informations qui
  • 11. Page 12/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1permettront à la maîtrise douvrage de préparer et de piloter le change-ment. Les dates de fourniture de ces différents livrables figurent au plan-ning.— Respecter les directives du Plan dAssurance Qualité : en même tempsque la réalisation de lapplication, la maîtrise dœuvre réalise son suivisur des critères tels que les fonctionnalités, la qualité, le planning, lescoûts, la visibilité.Au sein de la maîtrise dœuvre, on peut distinguer trois acteurs principaux :— Maître dœuvre : propose des objectifs (coût, délai en particulier) et desorientations pour le projet. Décide in fine les propositions de solution etles solutions elles-mêmes qui seront élaborées. Décide des moyens etméthodes à mettre en œuvre au sein de la MOE. Se coordonne avec lesMOE des autres projets et les sociétés extérieures participant à la MOEdu projet— Pilote de Projet Informatique : coordonne les travaux de la MOE. Valideles propositions de solution et les solutions elles-mêmes élaborées par laMOE. Estime et met en œuvre les moyens MOE (planning de production,méthodes et outils)— Responsable par domaine : pilote et suit léquipe de production dundomaine.Le Groupe danimation et de Rapport RADLe groupe danimation et de rapport (GAR) a pour responsabilités la prépara-tion des réunions (convocation, logistique et suivi), lorganisation des séan-ces de travail, la formalisation des exigences exprimées, la gestion descomptes-rendus, la planification et lanimation des focus.Lanimateur doit adopter une attitude directive sur la forme et non directivesur le fond. Il se garde démettre un avis personnel, de porter un jugement etde favoriser des opinions. Il najoute rien au discours des participants et secontente de maintenir les discussions bien centrées sur le thème voulu et decanaliser les entretiens. Pour cela, il peut procéder par exemple par synthèse(résumer lessentiel en le reformulant) ou par élucidation (forcer les gens, parle biais de questions, à aller jusquau bout dune idée).Le rapporteur doit être capable de produire une documentation automatiséeet de la maintenir à jour. Cest tout dabord un analyste concepteur, spécia-lement formé aux AGL (Ateliers de génie Logiciel). Lors des réunions portantsur la conception du système, il doit être capable de le modéliser en direct. Ilest aussi responsable de la synthèse des comptes-rendus de réunion.
  • 12. Page 13/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Figure 2 - Les acteurs du RAD2.3.3 Les cinq phases dun projet RADInitialisation (préparation de l’organisation et communication )Cette phase, qui représente environ 5% du projet, définit le périmètre généraldu projet, établit la structure du travail par thèmes, recense les acteurs perti-nents et amorce la dynamique du projet.Cadrage (analyse et expression des exigences)Cest aux utilisateurs de spécifier leurs exigences et dexprimer leurs besoinslors d’entretiens de groupe. Il est généralement prévu de 2 à 5 jours de ses-sions par commission (thème). Cette phase représente environ 10% du pro-jet.Design (conception et modélisation)Les utilisateurs participent à l’affinage et à la validation des modèles organi-sationnels : flux, traitements, données. Ils valident également un premierprototype ayant pour but de présenter l’ergonomie et la cinématique généralede l’application. 4 à 8 jours de sessions sont prévus par commission. Cettephase représente environ 25% du projet.Construction (réalisation, prototypage)Durant cette phase, l’équipe RAD (SWAT) construit au cours de plusieurssessions itératives l’application module par module. L’utilisateur participetoujours activement aux spécifications détaillées et à la validation des proto-types. Cette phase représente environ 50% du projet.Maîtrise d’ouvrage• Définit les objectifs et exigences du système• Valide le solutions proposées et élaborées• Prépare et pilote le changementMaîtrise d’œuvre• Propose et réalise la solution• Livre des « fonctionnalités»• respecte les directives du Pland’Assurance QualitéGroupe d’animation et de Rapport RADAnimateur• Provoque et conduit les réunions• N’émet pas d’avis personnel• Recadre les discussions• Synthétise et formaliseRapporteur• Produit une documentationautomatisée• Modélise le système en direct lors desréunions de conception• Rédige les comptes-rendus
  • 13. Page 14/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Finalisation (recette et déploiement)Cette phase, qui représente environ 10% du projet permet une livraison glo-bale et le transfert du système en exploitation et maintenance.Figure 3 - Cycle de vie d’un projet RAD2.3.4 RAD et modélisationSil se veut efficace, le RAD se doit dêtre rapide et donc dutiliser des techni-ques de modélisation rigoureuses mais simplifiées. Le RAD ne préconise pasde technique de modélisation particulière : il est tout à fait possible dutiliserdes modèles objets comme UML ou des modèles de Merise, à condition deles alléger pour nen conserver que ce qui est strictement indispensable.Dans le cadre dune approche "classique" par le haut de type merisienne,tous les modèle dabstraction merisiens ne sont pas utilisés. Dans le casgénéral, ne sont conservés que le modèle de Contexte (MC), le modèleConceptuel de Communication (MCC), la hiérarchie de fonctions (ou MCT),le modèle Conceptuel de Données (MCD), et le modèle Organisationnel deTraitements (MOT).Dans le cas d’un développement orienté objet, il est préconisé d’employer lanotation ULM. Les principaux modèles sont les suivants : modèle de Classes,modèle d’Etat, modèle des Cas d’utilisation, modèle des Interactions, modèlede Réalisation, modèle de Déploiement.2.3.5 Pourquoi le RAD nest il pas à proprement parler une méthode"agile" ?Essayons dexaminer la méthode RAD à la lumière des quatre critères quifont quune méthode est agile ou ne lest pas.Le RAD met bien en avant les ressources humaines et la communication parrapport au côté procédurier, notamment grâce à lexistence du groupe dani-mation et de rapport qui a pour rôle de faciliter la communication entre lamaîtrise dœuvre et la maîtrise douvrage.InitialisationFinalisationCadrageDesignConstructionConstructionDesignConstructionConstruction6 % 9 % 23 % 50 % 12 %• Préparation del’organisation• Communication• Expression desexigences•Analyse• Conception• Modélisation• Réalisation• Prototypage• Constructionitérative• Recette•Déploiement
  • 14. Page 15/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Le RAD privilégie la production dapplications fonctionnelles par rapport àlécriture massive de documentation.Le RAD implique une collaboration étroite avec le client. Dans un processusRAD, le client est un acteur clé (maîtrise douvrage).Par contre, le dernier critère des méthodes agiles nest pas véritablementrempli par le RAD. En effet, un projet RAD nest pas conçu pour faire preuvedune grande flexibilité par rapport au changement. Au contraire, le RAD seplace plutôt du côté de la planification rigide.Le RAD présente donc trois des quatre caractéristiques des méthodes agiles.Cest donc une méthode proche des méthodes agiles sans pour autant enfaire véritablement partie.2.4 DE UNIFIED PROCESS (UP & RUP) A L’AGILITE,UNEFILIATION?2.4.1 Les 5 principes dUPUP est une méthode générique de développement de logiciels. Cette mé-thode nécessite donc dêtre adaptée à chacun des projets pour lesquels ellesera employée.UP présente sept caractéristiques essentielles, les trois premières étant troiscritères préconisés par UML (Unified Modeling Language) :UP est pilotée par les cas dutilisationLes cas dutilisation (« Use Cases ») sont les véritables pilotes du projet,quelle que soit lactivité et quelle que soit la phase. En effet, le système esttout dabord analysé, conçu et développé pour des utilisateurs. Le systèmene peut pas être développé par des informaticiens nayant aucune idée de ceque sont le métier et lenvironnement des utilisateurs : tout doit donc être faiten adoptant le point de vue utilisateur. Les cas dutilisation sont loutil demodélisation des besoins en termes de fonctionnalités : cest sous cetteforme que sont exprimées les exigences. Les cas dutilisation servent ausside base pour lanalyse, le modèle logique, ainsi que de base pour les testsfonctionnels.UP est centrée sur larchitectureUP se soucie très tôt de larchitecture dans le cycle de vie dune application.Larchitecture du système est décrite à laide de différentes vues. Alors queles modèles cas dutilisation, analyse, conception, implémentation, déploie-ment, sont complets et exhaustifs, les vues définies par larchitecte ne re-prennent que les éléments significatifs. Larchitecte procède de manière in-crémentale : il commence par définir une architecture simplifiée qui répondaux besoins classés comme prioritaires avant de définir à partir de là lessous-systèmes de manière beaucoup plus précise.UP est itérative et incrémentale
  • 15. Page 16/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1UP procède par itérations par opposition aux méthodes en cascade qui sontplus coûteuses et ne permettent pas une bonne gestion du risque. De plus, ilest toujours difficile de corriger à la fin une erreur commise au début dunprojet. En procédant de manière itérative, il est possible de découvrir leserreurs et les incompréhensions plus tôt. Le feedback de lutilisateur estaussi encouragé et les tests effectués à chaque utilisation permettent davoirune vision plus objective de lavancement du projet. Enfin, le travail itératifpermet à léquipe de capitaliser à chaque cycle les enseignements du cycleprécédent.Figure 4 - UP est une méthode itérative et incrémentaleUP gère les besoins et les exigencesLes exigences du client changent au cours du projet. UP recommande dedécouvrir les besoins, de les organiser et de les documenter de manière àavoir une approche disciplinée de létude des exigences et de pouvoir lesfiltrer, les trier par propriété et réaliser leur suivi pour pouvoir estimer de ma-nière objective les fonctionnalités et les performances du système à dévelop-per.UP est fondée sur la production de composantsUP recommande de structurer larchitecture à base de composants (COM,CORBA, EJB, etc.). Les architectures ainsi construites sont de fait plus ro-bustes et modulaires. De plus, cette approche permet la réutilisation decomposants existants si ceux-ci ont été développés de manière assezgénérique. Enfin, la visualisation à laide des outils de modélisation est facileet automatique.UP pratique la modélisation visuelleUP préconise la modélisation visuelle du système. Un modèle est une simpli-fication de la réalité qui décrit le système selon un certain point de vue. Lamodélisation sous différents points de vue permet une meilleure compréhen-sion et une compréhension globale du système à concevoir. Lutilisation dou-Planning initialPlanningExigencesAnalyse et ConceptionImplémentationTestsÉvaluation Déploiement
  • 16. Page 17/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1tils visuels augmente encore les capacités de léquipe à gérer la complexitédes systèmes.Figure 5 - Modélisation visuelle selon différentes vuesUP se soucie en permanence de la qualitéPartant du constat que le coût de lacorrection des erreurs augmente expo-nentiellement au fur et à mesure delavancement du projet, il est absolu-ment nécessaire davoir un contrôlepermanent et rigoureux des fonctionna-lités, de la fiabilité, des performancesde lapplication et des performances dusystème. Pour cela, une automatisationdes tests tout au long du cycle de vie simpose. Ainsi, les défauts sont détec-tés très rapidement et le coût de leur correction est minimisé, lestimation delétat davancement du projet est plus objective et la qualité et les performan-ces des parties "à risque" est améliorée.UP gère les risques de façon systématique et permanenteLa phase de pré-étude a pour but didentifier les risques qui pourraient mettrele projet en péril. Tout au long du projet, il est recommandé de maintenir uneliste de risques, issus de la phase de pré-étude, classés selon leur dangerpour léquipe afin davoir une vue plus explicite des choses.2.4.2 Les activités dans la méthode UPUP définit les activités essentielles et propose, pour chacune dentre elles,une liste dintervenants (architecte, analyste...) et une liste de travaux asso-ciés.Diagrammesde composantsDiagrammesde scénarioDiagrammesd’étatDiagrammesde classesDiagrammede déploiementDiagrammesde casd’utilisationModèleAvancement du projetCoût de la correctiondes erreurs
  • 17. Page 18/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Expression des besoinsUP distingue deux types de modèles : "Domain Model" et "Business Model".Le modèle de domaine ne dépend pas de lapplication : il a pour but dap-prendre un domaine, un métier jusque là méconnu. Le modèle "business"est plutôt une modélisation des procédures en vigueur dans lentreprise etsintéresse directement aux collaborateur et à leurs divers travaux. Cest àpartir de ce modèle que peut alors démarrer lanalyse des cas dutilisation dusystème. Il sagit de mieux connaître le domaine et ses activités avant desintéresser aux fonctionnalités du système par une étude par les cas dutili-sation.AnalyseComprendre et de structurer le logiciel à développer sont les objectifs delanalyse. On construit dans cette activité une représentation interne quasi-idéale du système, sans trop tenir comte des exigences et contraintes deconception. Lanalyse utilise le langage du développeur alors que lexpres-sion des besoins se fait du point de vue utilisateur.ConceptionLa conception consiste à définir larchitecture du système. La conceptionnest non pas une phase du process UP mais une activité qui trouve sa placedans toutes les phases. La conception est ainsi réalisée de manière incré-mentale. Dans une phase de pré-étude elle consiste par exemple à maquet-ter larchitecture, tandis quen phase de construction la conception de gros-sière devient beaucoup plus détaillée. Si lanalyse est une vue purementlogique, la conception est plus physique et se soucie des contraintes quelanalyse avait laissées de côté.Implémentation et TestCette activité consiste à créer à proprement parler les divers composants :sources, scripts, puis exécutables... Les tests se basent sur les cas dutilisa-tion.2.4.3 Les phases du cycle de vieEtude dopportunitéCest durant cette phase quil faut se poser la question de la faisabilité duprojet, des frontières du système, des risques majeurs qui pourraient mettreen péril le projet. A la fin de cette phase, est établi un document donnant unevision globale des principales exigences, des fonctionnalités clés et descontraintes majeures. Environ 10 % des cas dutilisation sont connus à lissuede cette phase. Il convient aussi détablir une estimation initiale des risques,un "Project Plan", un "Business Model".ElaborationCette phase a pour but de préciser larchitecture. A ce stade, 80 % des casdutilisation sont obtenus. Cette phase permet aussi de connaître des exi-
  • 18. Page 19/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1gences supplémentaires, en particulier des exigences non fonctionnelles, dedécrire larchitecture du système, de le prototyper, de réviser la liste desrisques et de mettre en place un plan de développement. En théorie, cest àce stade quon est à même de faire une offre de réalisation du système.ConstructionLobjectif est de fournir une version beta de la release en cours de dévelop-pement ainsi quune version du manuel utilisateur.TransitionCette phase a pour objectif de peaufiner le système et de corriger les der-niers bugs pour pouvoir passer de la version beta au déploiement sur len-semble des sites. Comme le nom de la phase lindique, il sagit aussi de pré-parer la release suivante et de boucler le cycle soit sur une nouvelle étudedopportunité soit une élaboration ou construction.Figure 6 - Importance des activités au cours des différentes phasesDaprès Rational Software Corporation2.4.4 Pourquoi UP nest pasà proprement parler une méthode agile ?Comme nous lavons fait pour le RAD, positionnons UP par rapport aux qua-tre critères dagilité.UP sefforce de produire des applications fonctionnelles et surtout en coïnci-dence avec les besoins exprimés par le client. Cette caractéristique vient dufait qu UP est pilotée par les cas dutilisation.phasesactivitésEtuded’opportunitéElaboration Construction TransitionEtude du businessExpression des besoinsAnalyse et ConceptionImplémentationTestsDéploiementitérations
  • 19. Page 20/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1UP insiste sur la nécessité dune collaboration étroite avec le client. Lexpres-sion des besoins se fait en début de projet, mais à chaque itération, la phasede transition permet un retour du client sur ce qui est fait.UP fait aussi un premier pas vers des méthodes souples par rapport auchangement.En revanche, la méthode UP reste très procédurière. De plus UP sancre trèsfortement sur la modélisation UML et ses outils. Cette modélisation parfoisqualifiée de "modélisation à outrance" a tendance à alourdir quelque peu laméthode.En conséquence, UP ne remplit pas pleinement les critères dagilité tout enrestant très proche dune méthode agile.2.5 LASITUATIONENFRANCE : UN FORT ANCRAGE DELAMETHODEMERISEETDELAMODELISATIONENTITE-RELATIONLa conception dun système passe par une phase danalyse qui nécessitedes méthodes permettant de mettre en place un modèle du système à déve-lopper. Parmi les méthodes danalyse, Merise, qui date de la fin des annéessoixante-dix, reste très fortement implantée en France.La méthode Merise est fondée sur la séparation des données et des traite-ments à effectuer en plusieurs modèles conceptuels, logiques et physiques.La séparation des données et des traitements a pour but de donner unecertaine longévité au modèle. En effet, la structure des données na pas àêtre souvent modifiée dans le temps, tandis que les traitements le sont plusfréquemment. La méthode Merise est apparue dans les années 1978-1979, àla suite dune consultation nationale lancée en 1977 par le ministère delIndustrie. Cette consultation avait pour but de choisir des sociétés deconseil en informatique chargées de définir une méthode de conception desystèmes dinformation. Les deux principales sociétés ayant mis au pointcette méthode sont le CTI (Centre Technique dInformatique), et le CETE(Centre dEtudes Techniques de lEquipement).La démarche préconisée par Merise est la suivante :— Schéma directeur : permet de définir les objectifs du projet— Étude préalable : il sagit de référencer les moyens existants, de déter-miner les limites du système existant. Sur la base des besoins futurs,plusieurs scénarios sont proposés. A la fin de cette phase détude, unseul scénario est retenu sur des critères de coûts, limites, impacts, délaiset faisabilité)— Analyse détaillée : le premier modèle à établir est le Modèle Conceptueldes Données (MCD) basé sur une modélisation entités / relations. Aucours de cette phase, on établit aussi le Modèle Organisationnel desTraitements (MOT) puis le Modèle Logique des Données (MLD).— Analyse technique : il sagit de définir les solutions techniques retenuesen établissant le Modèle Physique des Données (MPD) et le ModèleOpérationnel des Traitements (MOPT)
  • 20. Page 21/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Merise permet de modéliser un système selon différents degrés dabstrac-tion : le modèle conceptuel est théorique et ne se soucie pas ou peu de lim-plémentation, le modèle logique représente un choix logiciel et le modèlephysique représente un choix darchitecture.Merise, méthode vieille dune vingtaine dannées reste particulièrement bienancrée en France, notamment pour la modélisation des données. On a doncune situation un peu particulière dans lhexagone : les méthodologies plusrécentes sont en général modifiées pour pouvoir sadapter à lexistant Meriseencore très utilisé pour ses performances en matière de modélisation desdonnées.
  • 21. Page 22/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1L’agilité comprend plusieurs courants de pensée qui ont conduit à des mé-thodologies reposant sur les mêmes concepts mais présentant chacune dessingularités. Présentant successivement Xtreme Programming, DSDM, ASD,CRYSTAL, SCRUM, FDD, cette partie se conclut par une vision de synthèsesous la forme d’une comparaison.3.1 EXTREME PROGRAMMING(XP)3.1.1 Aux origines deXtreme ProgrammingLa suppression des risques existants sur un projet représente la philosophied’XP. . En introduisant cette méthode, ses créateurs veulent en finir avec ladérive de délais, lannulation des projets, la non-qualité, la mauvaise com-préhension du métier du client et limpossibilité de suivre les changements.XP a été mis en œuvre pour la première fois en 1996 sur le projet C3, Chry-sler Comprehensive Compensation System, qui consistait à mettre en placeun nouveau système de gestion de la paie des dix mille salariés du fabricantautomobile. Sur ce projet, la méthode XP a été adoptée pour tenter de sau-ver le projet dune dérive annoncée.Les pères de la méthode, Ward Cunningham et Kent Beck définissent eX-treme Programming comme "une méthode basée sur des pratiques qui sontautant de boutons de contrôle poussés au maximum".3.1.2 Les 4 valeurs deXtreme ProgrammingXP met en avant quatre valeurs prenant en considération à la fois les enjeuxcommerciaux et les aspects humains des projets de développement dappli-cations.CommunicationLabsence de communication est certainement lun des défauts les plus gra-ves qui mettent en péril un projet. Diverses pratiques XP tendent à rendre lacommunication omniprésente entre tous les intervenants : entre dévelop-peurs (programmation en binôme), entre développeurs et managers (tests,estimations), entre développeurs et clients (tests, spécifications).Toutes ces pratiques qui forcent à communiquer ont pour but de permettre àchacun de se poser les bonnes questions et de partager linformation.SimplicitéCette valeur de simplicité repose sur le pari quil coûte moins cher de déve-lopper un système simple aujourdhui quitte à devoir engager de nouveauxfrais plus tard pour rajouter des fonctionnalités supplémentaires plutôt que deconcevoir dès le départ un système très compliqué dont on risque de navoirplus besoin dans un avenir proche. XP encourage donc à toujours sorientervers la solution la plus simple qui puisse satisfaire les besoins du client.3. PRINCIPALESMETHODOLOGIES AGILES,ETATDESLIEUX,COMPARAISON
  • 22. Page 23/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1FeedbackLe retour est immédiat pour les développeurs grâce aux tests unitaires. Pourles clients, le retour se fait à léchelle de quelques jours grâce aux tests fonc-tionnels qui leur permettent davoir une vision permanente de létat du sys-tème.Un feedback permanent est positif pour le client qui a une bonne vision duprojet, peut détecter tout écart par rapport au planning et à ses attentes demanière à les corriger rapidement. Pour les développeurs, un feedback per-manent permet de repérer et de corriger les erreurs beaucoup plus facile-ment.Cette notion de feedback est indispensable pour que le projet puisse accueil-lir le changement.CourageDu courage est nécessaire aussi bien chez le client que chez les dévelop-peurs. Pour mener à bien un projet XP, le client doit avoir le courage de don-ner un ordre de priorité à ses exigences, de reconnaître que certains de sesbesoins ne sont pas toujours très clairs. De son côté, le développeur doitavoir le courage de modifier larchitecture même si le développement est déjàbien avancé, de jeter du code existant et daccepter quil est parfois plusrapide et efficace de réécrire une portion de code à partir de zéro plutôt quede bricoler du code existant.3.1.3 Principes de baseFeedback rapideLidée de base est issue de la psychologie de lapprentissage : plus le retoursuit de près une action, plus lapprentissage qui en résulte est important.Cest pour utiliser au mieux cette caractéristique queXtreme Programmingpréconise des itérations de courte durée et limplication forte du client. Unretour rapide pour le développeur permet une correction ou un changementde direction plus rapide et un retour rapide vers le client lui permet de testeren permanence ladéquation du système à ses besoins et au marché.Assumer la simplicitéXP recommande de traiter tous les problèmes par la solution la plus simplepossible, partant du principe quun travail propre, simple et minimal aujour-dhui est facile à améliorer par la suite.Changements incrémentauxUne série de petits changements progressifs est toujours bien plus sûre etbien plus efficace quun grand chambardement. Ceci est valable à plusieursniveaux : dans un projet XP, larchitecture et la conception changent petit àpetit, de même que le planning et la composition de léquipe.
  • 23. Page 24/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Accueillir le changement à bras ouvertsLa meilleure stratégie est celle qui préserve le maximum doptions tout enapportant une solution aux problèmes les plus urgents.Un travail de qualitéParmi les quatre variables qui définissent un projet : taille, coûts, délais etqualité, la qualité nest pas vraiment indépendante. Pour la réussite dunprojet, la qualité ne peut qu’être "excellente" si chacun aime le travail quilfait.Apprendre à apprendrePlutôt que de s’en remettre à des théories ou des idées reçues pour répon-dre aux questions comme : quelle quantité de tests est nécessaire ? combiende temps dois-je passer à retravailler et améliorer le code que jai écrit ? etc.,mieux vaut apprendre à chacun à apprendre par soi même en fonction dechaque projet.Faible investissement au départAllouer peu de ressources à un projet au départ force les clients et les déve-loppeurs à aller à lessentiel et à dégager ce qui est réellement prioritaire etporteur de valeur.Jouer pour gagnerLétat desprit dans lequel doit se placer une équipe XP peut être comparée àcelui dune équipe de football ou de basket : jouer pour gagner et non pouréviter de perdre.Des expériences concrètesToute décision abstraite doit être testée. Dans cet ordre didée, le résultatdune séance de conception ne doit pas être un modèle finalisé un peu para-chuté, mais une série de solutions évoquées au cours de la séance.Communication ouverte et honnêteIl est essentiel que chacun puisse dire sans peur quune partie de code nestpas optimale, quil a besoin daide, etc.Travailler avec et non contre les instincts de chacunLes gens aiment réussir, apprendre, interagir avec dautres, faire partie duneéquipe, avoir le contrôle des choses. Les gens aiment quon leur fasseconfiance. Les gens aiment faire un travail de qualité et voir leurs applica-tions fonctionner. XP cherche à offrir à chacun des moyens d’exprimer cesqualités au cours du projet
  • 24. Page 25/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Responsabilités acceptéesIl est nécessaire de donner à chacun la possibilité de prendre des responsa-bilités (par exemple, les développeurs se répartissent eux mêmes les tâchessur la base du volontariat). Cela permet déviter les frustrations dans le casoù les responsabilités sont imposées et non délibérément choisies.Adaptation aux conditions localesAdopter XP ne signifie pas prendre à lettre la méthode mais intégrer sesprincipes pour ladapter aux conditions particulières de chaque projet.Voyager légerUn développeur a tendance à transporter beaucoup de choses inutiles. Undébat est soulevé à ce sujet à propos des règles de nommage. Si certainessont utiles et même indispensables, dautres sont probablement des contrain-tes inutiles ou non respectées. Les simplifier pour ne garder que celles quisont essentielles et utilisées par tous, cest voyager plus léger.Mesures honnêtesLa volonté de contrôler le déroulement dun projet conduit a évaluer, mesurercertains paramètres. Il faut toutefois savoir rester à un niveau de détail perti-nent. Par exemple, il vaut mieux dire "cela prendra plus ou moins deux se-maines" que de dire "cela prendra 14 176 heures".3.1.4 Les 12 pratiques XPPlanning gameCette pratique a pour but de planifier uniquement les releases. La planifica-tion se fait sous forme de jeu auquel participent les développeurs et le client.Pendant une première phase dite dexploration, le client exprime ses besoinsen termes de fonctionnalités. Pour cela, il les écrit sous forme de "user sto-ries", cest à dire sous forme de courtes descriptions du comportement quilattend du système, exprimées avec un point de vue utilisateur. Au cours decette même phase, les développeurs attribuent à chaque user story un nom-bre de points, fonction du temps quils estiment nécessaire au développe-ment des fonctionnalités contenues dans chaque user story. Sil savère queles user stories nécessitent un temps de développement trop long, elles sontdécoupées en scénarios élémentaires.Dans une deuxième phase dite dengagement, les user stories sont triées enfonction de la valeur quelles apportent au client et des risques encourus lorsde leur développement. Ceci permet daboutir à un classement des userstories par ordre de priorité. En fonction de la vélocité de léquipe, les déve-loppeurs et le client sentendent sur la quantités de user stories qui serontdéveloppées au cours de litération à venir et qui constitueront la prochainerelease. La vélocité évoquée ci-dessus est un indicateur du nombre de pointsqui peuvent être développées au cours dune itération (elle se calcule enfaisant le rapport du nombre de points développés au cours de litération
  • 25. Page 26/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1précédente et du produit du nombre de développeurs par la durée de litéra-tion).Enfin la phase de direction permet de mettre à jour le planning de la pro-chaine release.Cette pratique permet de combiner les priorités du client avec les estimationsdes développeurs afin de convenir du contenu de la prochaine release et dela date à laquelle elle devra être prête.Petites releasesPour une bonne gestion des risques, la sortie des releases doit intervenir leplus souvent possible. En conséquence, dune version à lautre, lévolutiondoit être la plus petite possible, tout en sefforçant dapporter le plus de valeurajoutée et des fonctionnalités dans leur intégralité.Utilisation de métaphoresXP recommande dutiliser des métaphores pour décrire larchitecture du sys-tème. De telles images permettent à tout le monde (y compris les commer-ciaux qui nont pas forcément de grandes compétences techniques) davoirune vision globale du système et den comprendre les éléments principauxainsi que leurs interactions.Conception simpleLa simplicité est une des valeurs fondamentales dXP. Il faut toujours déve-lopper la solution la plus simple possible et éviter de développer plus que cedont on a besoin. Ceux qui pratiquent XP résument cela sous la phraseYAGNI ("You aint gonna need it", « vous n’en aurez pas besoin »). Les seu-les exigences sont de satisfaire tous les tests, de ne jamais dupliquer unelogique et dutiliser le moins possible de classes et de méthodes.Dans ce même ordre didées, la documentation produite lors dun projet XPse réduit au minimum vital, cest à dire la documentation demandée par leclient.Tests (unitaires et fonctionnels)Les tests unitaires sont écrits et effectués par les développeurs pour vérifierle bon fonctionnement et la non régression des méthodes ou des construc-teurs. Pour une qualité de code encore meilleure, il est recommandé décrireles tests avant le code de lapplication.Les tests fonctionnels sont conçus par le client et lui permettent dune part devérifier le fonctionnement global du système, de contrôler lévolution du pro-jet, et d daffiner lexpression de ses besoins.Refactoring du codeLes développeurs dun projet XP doivent shabituer à retravailler un peu cha-que jour du code existant et fonctionnant parfaitement pour le maintenir pro-pre, le rendre plus lisible et plus robuste.
  • 26. Page 27/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Le but de cette pratique est de simplifier le code, tout en faisant en sorte quetous les tests soient satisfaits. Dun point de vue purement fonctionnel, cettesimplification nest pas nécessaire puisquelle intervient sur du code qui fonc-tionne parfaitement. En revanche, le refactoring du code assure que lajoutde fonctionnalités supplémentaires sera facilité. Le refactoring tend à pro-duire un code mieux pensé, plus modulaire, sans duplications de code etdonc plus facile à maintenir.Programmation en binômeToute lécriture du code se fait à deux personnes sur une même machine,avec une seule souris et un seul clavier. On distingue deux rôles : le pilote("driver"), celui qui a le clavier, cherche la meilleure approche sur une portionde code bien précise tandis que lautre développeur, le "partner" peut obser-ver avec beaucoup plus de recul et ainsi suggérer dautres solutions ou sou-lever des problèmes dordre plus général.Au premier abord, cette pratique peut sembler être une perte de temps, maisil savère que le travail se fait plus vite, que le code est de meilleure qualité(moins derreurs de syntaxe, meilleur découpage, etc.), avec une meilleurecompréhension du problème. Pour les développeurs, le travail est moinsfatiguant.Les binômes ne doivent pas être statiques : chacun change de partenairerelativement souvent. Ceci pour un meilleur partage des connaissances etpour permettre à chacun davoir une relativement bonne vision sur lensem-ble du code.Appropriation collective du codeToute léquipe est sensée connaître la totalité du code (plus ou moins dans ledétail selon les parties, évidemment). Cela implique que tout le monde peutintervenir pour faire des ajouts ou des modifications sur une portion de codequil na pas écrit lui même si cela savère nécessaire.Intégration continueAprès chaque fin de tâche, cest à dire plusieurs fois par jour, le code nouvel-lement écrit doit être intégré à lexistant de manière à avoir à tout moment unexistant fonctionnel qui passe avec succès tous les tests. Ainsi, quand unetâche est démarrée, elle peut se fonder sur la version la plus à jour de ce quia déjà été fait.Pas de surcharge de travailLobjectif est de ne pas dépasser 40 heures de travail par semaine pour lesdéveloppeurs. Il ne sagit pas de chercher à travailler peu, mais les spécialis-tes d eXtreme Programming ont pris conscience du fait que la surcharge detravail, en plus dêtre désagréable, est néfaste. En effet, le code devientmoins bien pensé, le refactoring est laissé de côté, ce qui conduit à unebaisse de la qualité et à une recrudescence des bugs. En vertu de ce prin-cipe, une équipe ne doit jamais être surchargée de travail plus de deux se-
  • 27. Page 28/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1maines consécutives. Si cela devait toutefois se produire, léquipe se doit deréagir en redéfinissant la quantité de user stories à implémenter au cours delitération ou en modifiant sa manière de procéder.Client sur siteLimplication forte du client passe par la présence sur site dune personneminimum à temps plein pendant toute la durée du projet. Cette personne doitavoir à la fois le profil type de lutilisateur final et une vision plus globale ducontexte pour pouvoir préciser les besoins, leur donner une ordre de priorité,les transcrire sous forme de user stories, et établir les tests fonctionnels.La présence du client sur site est dictée par des impératifs en matière deréactivité. En effet, au fil de la programmation, les développeurs soulèventfréquemment des questions sur des points non abordés ou restés obscurs.En étant sur place, le client peut ainsi apporter immédiatement des réponsesà ces questions, évitant ainsi que les programmeurs commencent à dévelop-per certaines fonctionnalités sur la base de ce quils supposent être les désirsdu client.La présence à temps plein du client sur site nimplique pas forcément quecette activité occupe la totalité de son temps : il est tout à fait envisageablepour le client de continuer une partie de son activité tout en étant délocaliséauprès de léquipe de développeurs.Standards de codeIl est nécessaire de disposer de normes de nommage et de programmationpour que chacun puisse lire et comprendre facilement le code produit par lesautres. Ceci est dautant plus essentiel que la propriété du code est collectiveet que les programmeurs sont amenés à changer de binôme régulièrement.En général, les conventions adoptées lors des projets XP sont assez intuiti-ves et résultent de pratiques plutôt naturelles chez les développeurs.3.1.5 Cycle de vieCe paragraphe donne une vision du cycle de vie idéal dun projet XP. Plu-sieurs phases composent le cycle de vie dune application.
  • 28. Page 29/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Figure 7 - Les grandes lignes du cycle de vie dun projet XPExplorationAu cours de cette phase, les développeurs se penchent sur des questionsdordre technique destinées à explorer les différentes possibilités darchitec-ture pour le système et à étudier par exemple les limites au niveau des per-formances présentées par chacune des solutions possibles.Le client de son côté shabitue à exprimer ses besoins sous forme de userstories que les développeurs devront estimer en terme de temps de dévelop-pement.PlanningNous ne détaillerons pas ici les procédures entrant dans la phase de plan-ning, ceci ayant déjà été fait plus haut, dans le paragraphe intitulé "planninggame".Le planning de la première release est fait de telle sorte quun système pour-vu uniquement des fonctionnalités essentielles soit mis en production dansun temps minimum et soit enrichi par la suite.Le planning game dure un ou deux jours et la première release est en géné-ral programmée pour deux à six mois plus tard.Itérations jusquà la première releaseCest la phase de développement à proprement parler de la première versionde lapplication. Celle ci se fait sous forme ditérations de une à quatre se-maines.Exploration Planning MortMaintenanceItérations jusqu’à lapremière releaseitérations de1 à 4 semainesMise enproductionitérations de1 semainemaintenance = ajouter des fonctionnalités à nouvelles releasesutilise le même processus que pour la release 1
  • 29. Page 30/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Chaque itération produit un ensemble de fonctionnalités passant avec succèsles tests fonctionnels associés. La première itération est dédiée à la mise enplace de larchitecture du système.Ces itérations courtes permettent de détecter rapidement toute déviation parrapport au planning qui a été fait jusquà la sortie de la release. En cas dedéviation, quelque chose est à revoir, soit au niveau de la méthode, soit auniveau des spécifications, soit au niveau du planning.Durant les itérations, de brèves réunions réunissent toute léquipe quotidien-nement pour mettre chacun au courant de lavancement du projet.Mise en productionLes itérations de cette phase sont encore plus courtes, ceci pour renforcer lefeedback. En général, des tests parallèles sont conduits au cours de cettephase et les développeurs procèdent à des réglages affinés pour améliorerles performances (performance tuning).A la fin de cette phase, le système offre toutes les fonctionnalités indispen-sables et est parfaitement fonctionnel et peut être mis à disposition des utili-sateurs.MaintenanceIl sagit dans cette phase de continuer à faire fonctionner le système désor-mais existant et de lui adjoindre les fonctionnalités secondaires qui avaientvolontairement été laissées de côté jusque là.Le développement de nouvelles fonctionnalités sur un système déjà mis enproduction requiert une prudence accrue de la part des développeurs et cettephase est donc cruciale.A chaque nouvelle release, une nouvelle phase dexploration rapide doitavoir lieu.MortLa fin dun projet intervient quand le client narrive plus à écrire de user sto-ries supplémentaires ce qui signifie que pour lui, tous ses besoins ont étésatisfaits ou quand le système nest plus capable de recevoir de modifica-tions pour satisfaire de nouveaux besoins tout en restant rentable.
  • 30. Page 31/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Figure 8 - Interactions entre les acteurs dun projet XP3.1.6 RôlesDéveloppeurIl est lélément principal dun projet XP. En apparence, le développeur passesimplement son temps à écrire des lignes de code, rajouter des fonctionnali-tés, simplifier, optimiser son code. Mais son rôle ne se limite pas à cela. Laprincipale qualité dun développeur est sa capacité à communiquer. XP re-quiert aussi la capacité à travailler en binôme, aptitude qui nest pas forcé-ment requise pour dautres types de projets. Enfin, un développeur doit sha-bituer à la simplicité : construire la solution la plus simple et ne construire quece qui est absolument nécessaire doit devenir un réflexe.Un développeur doit avoir dautres compétences plus techniques : être capa-ble décrire du code propre, de pratiquer le refactoring, de recourir aux testsunitaires, etc.Enfin, XP requiert du courage de la part des développeurs.ClientLe client est lautre moitié du duo essentiel dans lapproche eXtreme Pro-gramming. Le développeur sait comment programmer et le client sait quoiprogrammer.Pour un projet XP, le client doit apprendre à exprimer ses besoins sousforme de user stories, à leur donner un ordre de priorité et à dégager ce quiest essentiel et valorisant pour lui.Dans lidéal, le client a à la fois le profil de lutilisateur et une vision plus éle-vée sur le problème et lenvironnement du business dans lequel le projetsinclut.Le client doit aussi apprendre à écrire les cas de tests fonctionnels et fairepreuve, lui aussi, de courage.ClientDéveloppeurDéveloppeurClientestime les coûtschoisit ce qui doit êtredéveloppé en prioritéspécifie ses besoinsdéveloppe lesfonctionnalitésdemandéescapitalise lesconnaissances
  • 31. Page 32/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1TesteurÉtant donné que les tests unitaires sont à la charge des développeurs, letesteur a pour rôle daider le client à choisir et à écrire ses tests fonctionnels.Le testeur nest pas une personne isolée, chargée de mettre le système endéfaut et dhumilier les développeurs : il sagit juste dune personne chargéede faire passer régulièrement la batterie de tests.TrackerCest un peu la conscience de léquipe. Son rôle est daider léquipe à mieuxestimer le temps nécessaire à limplémentation de chaque user story et degarder un œil sur le planning en relation avec lavancement réel du projet.Cest en quelque sorte lhistorien et le rapporteur de léquipe, chargé de col-lecter toutes les informations qui peuvent savérer utiles.CoachLe coach a la responsabilité globale de tout le processus. Son rôle est derecadrer le projet, dajuster les procédures. Toute la difficulté de sa tâcheréside dans le fait quil se doit dintervenir de la manière la moins intrusivepossible. Au fur et à mesure de la maturation de léquipe, sont rôle diminue etléquipe devient plus autonome.ConsultantLa programmation en binôme rend assez peu probable lexistence de domai-nes de compétences dans lesquels seuls un ou deux membres de léquipeont des connaissances suffisantes. Cest une force car cela rend léquipe trèsflexible mais cest aussi une faiblesse car la volonté de simplicité se fait par-fois au détriment de connaissances techniques très poussées. Quand leproblème se présente, léquipe a recours aux services dun consultant. Lerôle dun consultant est dapporter à léquipe les connaissances nécessairespour quils résolvent eux mêmes leur problème et non de leur apporter unesolution toute faite.Big BossLe Big Boss apporte à léquipe courage et confiance.3.1.7 Forces et faiblessesExtreme Programming apparaît comme la plus radicale des méthodes agiles.Cette méthode se révèle particulièrement efficace dans le cadre de petitsprojets. XP réalise des applications de qualité grâce à la rigueur imposée surles tests, qui plus est collent au désirs du client puisque celui-ci est intégré auprojet de A à Z.Aussi efficace quelle soit, la méthode XP nest pas applicable dans tous lescas. Dans le cadre dun projet de type forfaitaire où le prix, les délais et lesbesoins sont fixés, XP ne peut pas réellement être mise en œuvre. Le casdune équipe supérieure à une douzaine de personnes est un autre exemple
  • 32. Page 33/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1où XP est difficilement adaptable car le nombre risque de ralentir, dalourdirles procédures et de rendre la communication plus difficile et moins efficace.Enfin, XP est sans doute une des plus contraignante des méthodes agiles,aussi bien pour le client que pour les développeurs. En effet, linvestissementdemandé au client est très important puisquil doit déléguer une personne àtemps plein sur le lieu où est développée lapplication, avec toutes lesconséquences que cela induit. En ce qui concerne les développeurs, la prati-que de la programmation en binôme nest pas forcément très bien ressentiepar tous. Or un projet XP ne peut pas être un franc succès si tous ses parti-cipants nadhèrent pas pleinement à la méthode. Avant de se lancer dans untel projet, il faudra tout dabord convaincre le client et motiver léquipe ce quinest pas toujours aisé.3.2 DYNAMICSOFTWAREDEVELOPMENTMETHOD(DSDM)3.2.1 Les origines de DSDMLa méthode DSDM est née du même constat que toutes les méthodes agi-les, à savoir que les temps de développement étaient jusquà présent troplongs, que les applications livrées ne correspondaient pas toujours exacte-ment aux besoins, que les développeurs étaient peu impliqués dans laconception et que personne navait de vue complète des systèmes dévelop-pés.DSDM sappuie aujourdhui sur une association loi 1901, indépendante et àbut non lucratif, dont le but est de développer et de promouvoir une méthodepour le développement rapide dapplications. Il sagit dune approche dyna-mique qui requiert limplication des utilisateurs.Cest à la suite dune initiative britannique en 1994 quest née DSDM. Lap-proche ayant été adoptée par des entreprises prestigieuses comme BritishAirways, Barclays Bank, Marks and Spencer, etc., lassociation a connu unecroissance exponentielle et fait preuve aujourdhui dune volonté de diffusioninternationale.3.2.2 9 principes fondamentaux1. Limplication active des utilisateurs est impérativeDSDM part du principe quune implication forte des utilisateurs est néces-saire pendant tout le cycle de vie pour éviter des retards dans la prise dedécision. Les utilisateurs ne sont pas considérés comme de simples fournis-seurs dinformation mais bien comme des acteurs à part entière de léquipe.2. Les équipes DSDM doivent être autorisées à prendre des décisionsDans le cadre de la méthode DSDM, une équipe regroupe des développeurset des utilisateurs. Cette équipe doit être capable de prendre des décisionssur lévolution et la modification des besoins et de déterminer le niveau defonctionnalité sans demander laval de la direction.
  • 33. Page 34/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.13. Le produit est rendu tangible aussi souvent que possiblePour des raisons de flexibilité, DSDM se fonde sur la livraison fréquente defournitures. Les délais sont volontairement pris très courts ce qui force àdéfinir quelles sont les activités qui permettront datteindre les résultats priori-taires dans le temps imparti.4. Ladéquation au besoin métier est le critère essentiel pour laccepta-tion des fournituresLobjectif de DSDM est de livrer à temps des fonctions métiers qui permettentde satisfaire les besoins de lentreprise. Lélaboration dun système plus glo-bal nest pas une priorité : elle peut être réalisée après coup.5. Un développement itératif et incrémental permet de converger versune solution appropriéeLe principe dévolution incrémentale des systèmes permet de tirer un meilleurparti du contact entre développeurs et utilisateurs. Cette manière de procéderpermet un retour permanent des utilisateurs vers les développeurs et unemeilleur adéquation des systèmes construits avec les besoins.De plus, le caractère itératif et incrémental de la méthode permet la livraisonde solutions partielles pour répondre à des besoins immédiats.6. Toute modification pendant la réalisation est réversibleIl est nécessaire de maîtriser la gestion de configuration du logiciel en déve-loppement de manière à ce que tout changement effectué soit réversible.Parfois, pour annuler certains changements, il est plus simple de reconstruireque de revenir en arrière. Il importe de sefforcer de rendre toute transforma-tion réversible.7. Les besoins sont définis à un niveau de synthèseLe schéma directeur fixe les exigences du système à un niveau suffisammentélevé pour permettre une évolution itérative des niveaux plus détaillés.8. Les tests sont intégrés pendant tout le cycle de vieLes tests font partie intégrante de lactivité de développement. Ils servent àvalider au fur et à mesure du développement du système que celui-ci estopérationnel tant sur le plan technique que fonctionnel. En fin de cycle, lestests sont les garants du bon fonctionnement du système.9. Un esprit de coopération entre tous les acteurs est primordialDans la démarche DSDM les fonctions détaillées ne sont pas figées dès ledépart. Le demandeur et le réalisateur doivent faire preuve de souplesse toutau long du cycle de vie, ce qui implique la nécessité davoir une procédure degestion des modifications peu contraignante.
  • 34. Page 35/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.13.2.3 5 phasesDSDM se définit plus comme un "canevas" que comme une méthode, cest àdire quelle ne fournit que "lossature" du processus global et une descriptiondes processus et produits qui devront être adaptés à un projet ou à une en-treprise particulière.Le processus de développement est constitué de cinq phases :— LEtude de Faisabilité— LEtude du " Business "— Le Modèle Fonctionnel itératif— La conception et le développement itératifs— La Mise en œuvre dans lenvironnement de travail.Figure 9 - Cycle de vie dun projet DSDMLEtude de Faisabilité et lEtude du "Business" sont réalisées de manièreséquentielle. Comme elles établissent les règles de base pour le reste dudéveloppement elles doivent être terminées avant que les trois autres phasesitératives ne démarrent. Les trois phases suivantes peuvent converger ou sechevaucher mais cela dépend essentiellement de la nature du système déve-loppé et les outils utilisés. Chaque phase génère un minimum de livrablesrépondant à un besoin bien précis.LEtude de FaisabilitéPremière tâche à accomplir : déterminer si DSDM est lapproche qui convientpour le projet considéré. Cest dans cette phase que le problème à résoudreest posé. Il faut ensuite évaluer les coûts et dun point de vue technique,laptitude du système envisagé à résoudre le problème métier. dans la me-sure où les besoins sont généralement urgents, cette phase est nécessaire-ment courte et ne dépasse pas quelques semaines. Cette phase ne laissepas suffisamment de temps pour produire une documentation volumineuse.Le Rapport de Faisabilité couvre donc les thèmes habituels mais avec peude détails. LEtude de Faisabilité produit aussi un Plan Global de développe-ment, qui vient renforcer lhypothèse que lobjectif fixé est réalisable et, deModèleFonctionnelItératifMise enOeuvreConception etRéalisationItérativesÉtude deFaisabilitéÉtude deBusiness
  • 35. Page 36/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1manière facultative, un Prototype de faisabilité pour montrer que la solutionest réalisable.LEtude du BusinessLétude du Business ou étude des besoins industriels doit elle aussi êtreaussi courte que possible. Elle a pour but de permettre la compréhensionsuffisamment approfondie des besoins et des contraintes techniques pour nepas mettre en péril la suite du déroulement du projet.Cette phase permet létude des processus à automatiser et des besoins eninformations. Cette étude passe par lorganisation dAteliers Facilités (travailcollectif animé par un médiateur) dont le rôle est de dégager la Définition duDomaine Industriel qui répertorie non seulement les processus de lentrepriseet informations associées mais aussi les classes (ou types) dutilisateur quiseront concernées dune manière ou dune autre par la mise en place dusystème. Ces classes permettent didentifier les utilisateurs qui participerontau développement. Ces utilisateurs auront pour responsabilité dune part defournir les informations nécessaires au projet et dautre part de tenir lensem-ble de la communauté informatique au courant de son évolution. Les AteliersFacilités permettent aussi de classer par ordre de priorité toutes les fonction-nalités à développer. Lordre de priorité repose principalement sur le degrédurgence des besoins métiers, mais il peut aussi intégrer des besoins nonfonctionnels tels que la sécurité par exemple.La Définition de lArchitecture Système, qui décrit aussi bien les plates-formes opérationnelles et de développement que larchitecture du logicieldéveloppé (cest à dire les principaux composants et interfaces associées),est un autre élément essentiel de Létude du Business. La définition de lar-chitecture à ce niveau est indispensable car certains modules commencerontà être développés dès létape suivante. Bien entendu, la Définition de lArchi-tecture Système est susceptible dêtre ajustée au cours des phases ultérieu-res.Enfin, le Plan Global issu de lEtude de Faisabilité est détaillé pour créer leplan Global de Prototypage qui décrit le mode de développement à utiliser aucours des deux phases suivantes ainsi que le mode de contrôle et de tests àmettre en oeuvre.Modèle Fonctionnel ItératifLe Modèle Fonctionnel Itératif a pour but de préciser la définition de tous lesaspects du système qui sont liés au business. Il consiste en une descriptionplus précise des besoins de haut niveau, à la fois en termes de traitement etdinformation. Cette phase produit aussi bien des modèles danalyse stan-dard que des modules logiciels.Les phases "Modèle Fonctionnel Itératif" et "Conception et Réalisation Itérati-ves" reposent toutes deux sur un cycle de quatre activités :1. Identifier ce qui doit être produit.2. Décider comment et à quel moment le faire.3. Créer le produit.
  • 36. Page 37/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.14. Vérifier quil a été développé de manière appropriée (par le biais de testset à la lumière des documents précédemment produits)Les modules logiciels du Modèle Fonctionnel répondent aux principaux be-soins, y compris les besoins non fonctionnels comme la sécurité ou la facilitédutilisation. Ils subissent des tests au fur et à mesure de leur production :ceci sous-entend les tests techniques unitaires ainsi que des mini-tests derecettes effectués directement par les utilisateurs. Les tests permettent dedéterminer si les composants produits peuvent ou non être réutilisables etservir de base à un ensemble de fonctionnalités. Les aspects non fonction-nels sont testés au cours de la phase suivante.En pratique, il est souvent plus simple et plus intuitif de traiter intégralementun domaine fonctionnel et ses aspects non fonctionnels avant de passer à unautre domaine. Selon la manière dont lapplication a été découpée en diversmodules plus ou moins indépendants, les phases "Modèle Fonctionnel Itéra-tif" et "Conception et Réalisation Itératives" seront plus ou moins imbriquées.Conception et Réalisation ItérativesLe passage du Modèle Fonctionnel à La Conception et au Développementest subordonné à laccord sur un Prototype Fonctionnel présentant tout oupartie du Modèle Fonctionnel. Si ce prototype ne présente quune partie dumodèle fonctionnel, les activités de prototypage et de développement peu-vent être menées en parallèle.La phase Conception et Réalisation Itératives est létape qui a pour but derendre le système conforme à des standards assurant quil peut être placéentre les mains des utilisateurs. Le produit majeur de cette phase est le Sys-tème Testé. Dans des cas particuliers, le client peut exiger lajout dunephase de test à la fin de chaque itération, mais DSDM préconise létalementdes tests au fur et à mesure des phases "Modèle Fonctionnel Itératif" et"Conception et Réalisation Itératives".Le Système testé nest pas forcément complet sur le plan fonctionnel mais ilse doit de satisfaire les besoins qui ont été définis comme prioritaires pourlétape en cours.Mise en ŒuvreCest au cours de la phase de Mise en Oeuvre quest effectuée la migrationdu système de lenvironnement de développement à lenvironnement opéra-tionnel. Cette phase inclut également la formation des utilisateurs nayant paspris part au projet.Le Système Livré et la documentation (y compris la documentation utilisa-teur) font partie des livrables de cette phase. La documentation utilisateur estfinalisée durant cette phase mais elle doit avoir été commencée durant laphase Conception et Réalisation Itératives. Cest lune des responsabilitésdes utilisateurs ambassadeurs que de sassurer de la qualité de la documen-tation et de la formation utilisateur.Le Document de Capitalisation de Projet est lautre produit de cette phase. Ilpermet de faire le point sur les besoins exprimés et la manière dont le sys-tème y répond. Quatre résultats sont possibles :
  • 37. Page 38/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.11. Tous les besoins ont été satisfaits. Aucune autre tâche supplémentairenest donc nécessaire.2. Un aspect fonctionnel important a été provisoirement ignoré. Il faut dansce 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 lajou-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ôlesDSDM définit de manière très précise des rôles à attribuer aux différentespersonnes qui vont prendre part au projet. Il est important de noter quun rôlene correspond pas nécessairement à une et une seule personne physique.En fonction de la taille du projet, une personne peut se voir attribuer plusieursrôles et un même rôle peut être tenu par plusieurs personnes.Figure 10 - Les rôles dans une équipe DSDMRôles ResponsabilitéSponsor exé-cutifAssurer lefficacité et la rapidité du processus décisionnelRéagir aux questions de progressionAssurer la disponibilité des fonds et autres ressourcesContrôler le maintien de ladéquation du projet au businessEngagement et disponibilité pendant tout le cycle de déve-loppementVisionnaire Promouvoir la traduction de la vision en pratique de travailAvoir une vision plus large de bout en bout du processus duParticipent à temps completChef de projetChef d’équipeUtilisateurAmbassadeurDéveloppeurRapporteurCoordinateurtechniqueDéveloppeurseniorVisionnaireUtilisateurConseillerSponsorExécutifFacilitateurNe participent qu’à temps partiel
  • 38. Page 39/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1businessContribuer aux sessions relatives aux besoins clefsContribuer aux sessions importantes de conceptionContribuer aux sessions importantes de révisionRésoudre les conflits dans lensemble du domaine du busi-nessAssurer la disponibilité des ressources utilisateursContrôler les progrèsEngagement et disponibilité pendant toute la durée du cyclede développementUtilisateurambassadeurFournir les données essentielles aux sessions concernant lesbesoins du business et la conceptionFournir le détail des scénarios du businessCommuniquer avec les autres utilisateurs et obtenir leur avalFournir des données aux sessions de prototypageRéviser la documentationEvaluer et accepter le logiciel livréFournir la documentation pour les utilisateursAssurer que la formation se fait de façon adéquateOrganiser et contrôler les tests utilisateursUtilisateurconseillerFournir linformation à la demandeParticiper au processus de prototypage et de révision par sesconseils et son assistance sur des questions pratiques im-portantesApprouver les conceptions et prototypes dont lutilisation estacceptableContribuer aux tests business et dergonomieChef de projet Rendre compte aux cadres supérieurs et au Comité directeurPlanifier le projetContrôler les progrèsGérer le risqueOrienter et motiver les équipesDéfinir les objectifs des équipesPrésider les réunions du projetGérer la participation des utilisateursTraiter les exceptionsIdentifier et faire appel aux rôles spécialistes lorsque requisTraiter les problèmes de progression des équipes du projetCoordinateurtechniqueDéfinir lenvironnement techniqueContrôler les procédures de gestion de configurationAssurer ladhésion aux standards de bonnes pratiquesConseiller et coordonner les activités techniques de chaque
  • 39. Page 40/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1équipeAssister aux sessions de prototypage pour conseiller surlapplication des standardsAssurer que les objectifs de maintenabilité sont satisfaitsConvenir et contrôler larchitecture logicielIdentifier les possibilités de réutilisationGérer le contrôle de mise en pratiqueChef déquipe Développer et maintenir la conformité à la définition du do-maine dactivité du businessAssurer le traitement des besoins du business formulés parles utilisateursOrganiser les sessions de prototypage et de révision entreles utilisateurs et les développeursEncourager la participation complète des membres deléquipe dans le cadre des rôles et des responsabilités définisConduire les sessions de prototypage à atteindre les objec-tifs fixés dans les délais et dans le cadre des contraintes delordonnancementAssurer la documentation et le contrôle des changementsPromouvoir le bien-être et la motivation de léquipeDéveloppeuret dévelop-peur confirméCréation dune documentation détaillée lorsque nécessaireTravailler avec les utilisateurs pour définir les besoins dubusiness, créer les prototypes et les programmes finalisésCréer dautres composants comme, par exemple, un modèlelogique de donnéesCréer la fiche technique des testsRéviser et tester son propre travail et celui des autresFacilitateur Convenir de la portée de latelier avec le chef de projetPlanifier latelierEtre familiarisé avec le domaine du businessInterviewer les participants pour sassurer quils conviennentainsi que de la réalisation de tout travail préparatoireFaciliter la tâche de latelier pour quil satisfasse à ses objec-tifsFaire une revue de latelier par rapport à ses objectifsRapporteur Enregistrer tous les points formulés qui sont pertinents pourle systèmeAider à linterprétation subséquenteGérer la distribution de la documentation du projetSelon la taille et la nature du projet, le chef de projet peut juger nécessaire defaire appel à des rôles dexperts pour remplir des fonctions particulières.Citons pour exemple quelques-uns de ces rôles : Consultant Business,Consultant Technique, Spécialiste dadéquation du système à lhomme,
  • 40. Page 41/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Chargé de planification capacité/ performance, Expert en matière de sécurité,Architecte données, Responsable de la qualité, Equipiers pour la gestion dusupport et de la maintenance, etc.3.2.5 Forces et faiblesses de la méthodeDSDM présente de nombreux avantages : mise en œuvre rapide de solutionsprioritaires, adéquation du système aux besoins, respect des délais et descoûts, meilleure formation des utilisateurs, implication des utilisateurs dansle développement, tests intégrés, moins de bureaucratie, souplesse face auchangement, conformité avec la norme ISO 9001.Il est pourtant possible de dégager quelques faiblesses ou quelques pointsqui se présentent comme un frein à la méthode DSDM.Limplication des utilisateurs tout dabord soulève un certain nombre de ques-tions. Comment concrètement impliquer lutilisateur si lutilisateur nest pas leclient ? Dans ce cas, comment le client percevra-t-il le pouvoir donné à lutili-sateur de faire évoluer les spécifications ?De plus, léquipe, constituée de développeurs et dutilisateurs, est amenée àprendre des décisions concernant le niveau de fonctionnalités sans laval dela direction. La question qui se pose alors est de savoir si léquipe disposebien de toutes les informations nécessaires, notamment concernant le Busi-ness, pour prendre de telles décisions.Enfin, DSDM préconise de toujours mettre en place la solution la plus simplequi permet de résoudre le problème posé, partant du principe quil est plussimple de rajouter des fonctionnalités par la suite, un peu à la manière d’XP.Il convient peut être de prendre ce point avec modération : sil ne faut claire-ment pas tomber dans les pièges du "trop générique", dans certains casparticuliers, il est parfois plus simple de penser dès le début à déventuellesfonctionnalités futures (par exemple, si on na pas prévu au départ la gestionmultilingues dun système, il est assez difficile dajouter cette fonctionnalitéaprès coup).3.3 ADAPTIVESOFTWAREDEVELOPMENT3.3.1 ContexteAdaptive Software Development est une méthode agile développée par JimHighsmith, président dInformation Architects, Inc. Elle sadresse tout particu-lièrement aux projets e-business. Les plannings traditionnels, associés à uncertain degré de certitude et de stabilité du business, ne conviennent pluspour diriger les projets actuels qui doivent être réalisés en des temps trèscourts, supporter de nombreux changements et incertitudes. Jim Highsmithpropose donc avec Adaptive Software Development un cycle de vie plussouple face aux changements qui surviennent constamment. La capitalisa-tion des connaissances et la collaboration entre développeurs, testeurs etclient sont deux valeurs essentielles de cette méthode.3.3.2 Les 6 caractéristiques principales dASDLe cycle de vie préconisé par ASD sappuie sur six valeurs fondamentales :
  • 41. Page 42/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Focaliser sur une mission ("mission focused")En général, les spécifications ne sont pas définies de manière précise dès ledébut mais le projet est guidé par une mission. La mission est comme unesorte de guide pour le projet : au début, elle encourage lexploration puis aufur et à mesure que le projet se précise et avance, elle le recadre dans ledroit chemin. En fait, on peut voir la mission plutôt comme une frontière quecomme un point précis à atteindre. Cest dailleurs la mission, si elle se pré-cise au cours de lavancement du projet, qui empêche que les itérations nesoient que de simples oscillations sans progrès.Se baser sur des composants ("component-based")Il est nécessaire de se focaliser non sur les tâches mais sur les résultats,cest à dire sur les composants dune application. Dans le cadre dASD, onentend par composant un ensemble de fonctionnalités qui doivent être déve-loppées durant une itération. A ce titre, la documentation peut être considé-rée comme un composant livrable. Si elle a été demandée par le client pourla fin dune itération, elle est considérée comme un composant mais revêtune priorité secondaire par rapport aux fonctionnalités à proprement parlerqui procurent des résultats directs au client.ItérerA la différence du domaine industriel où la production se fait en grandesséries devoir refaire ou retravailler quelque chose est considéré comme unéchec. Dans le cas du développement dapplications, au contraire, la concep-tion se fait de manière itérative et incrémentale : les composants évoluent enfonction du feedback des utilisateurs.Découper le temps et fixer des deadlines ("timeboxing")Un des principe dASD est la nécessité de fixer des dates butoirs de livraisonqui fixent en même temps la fin dune itération ou dun projet. Ces deadlinesne doivent pas pour autant servir de prétexte pour surcharger les dévelop-peurs lorsque la date approche ou pour négliger la qualité ce qui détruit toutle travail collaboratif qui a été fait auparavant. Le timeboxing est en fait unmoyen de forcer la prise de décisions difficiles et de forcer à réévaluer cons-tamment la validité de la mission (ambitions, planning, ressources, etc.)Gérer le risque ("risk-driven")Etant donné que les projets auxquels sadresse ASD sont des projets quonpourrait qualifier d "extrêmes" par leurs délais serrés, leur absence totale destabilité dans les besoins et les exigences de qualité, une bonne gestion desrisques est cruciale. Il est donc nécessaire danalyser précisément tous lesrisques critiques qui pourraient mettre en péril le projet avant de le démarrer.
  • 42. Page 43/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Tolérer le changementLa capacité à supporter des changements de spécifications, de techniquesen cours de développement est vue comme un avantage concurrentiel par laméthode ASD.3.3.3 Le cycle de vie selon Adaptive Software DevelopmentFigure 11 - Le cycle de vie selon Adaptive Software DevelopmentSpéculerLa phase de spéculation comprend les tâches dinitiation et de planificationdu cycle. Cette phase comprend sept étapes :— Conduire la phase dinitiation du projet— Déterminer la date butoir de fin de projet— Déterminer le nombre optimal ditérations et la date de fin de cha-cune dentre elles— Donner une mission objective à chaque itération— Affecter les composants de base aux itérations— Affecter les technologies et les composants support aux itérations— Développer une liste de tâches à réaliserLinitialisation dun projet est assez similaire à celle préconisée par lesapproches de management courantes. Elle prend en compte létablisse-ment de la mission et des objectifs du projet, létude des contraintes,létablissement de lorganisation du projet, lidentification des collabora-teurs clés, lexpression des exigences, une première estimation de lataille et de létendue du projet et lidentification des risques critiques. Pourgagner du temps, les données de linitialisation sont collectées au coursde réunions JAD (Joint Application Development). Pour un projet de pe-tite taille, cette phase peut être accomplie en environ une semaine.La deuxième étape est de déterminer le temps imparti au projet. La datebutoir est établie sur la base des résultats de la phase dinitialisation. LeSPECULER COLLABORER APPRENDREinitialisationPlanningdu cycleadaptatifRéunionFinale+ReleaseDéveloppementdes composantsContrôleQualitéBoucle d’apprentissage
  • 43. Page 44/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1verbe "spéculer" donné à la phase ne signifie pas pour autant que léta-blissement des délais abandonne toute estimation : il signifie juste uneprise de conscience de la fragilité des estimations.En troisième lieu, léquipe doit décider le nombre idéal ditérations et af-fecter à chacune une certaine durée. Pour des projets de petite àmoyenne taille, celles-ci durent en général entre 4 et 8 semaines maisces chiffres ne sont donnés quà titre indicatifs et doivent être adaptés àchaque projet.Léquipe doit ensuite associer à chaque itération une thématique ou unobjectif. Cest ce qui assure la visibilité du projet. Chaque cycle produit unensemble de composants livrables qui rendent le produit visible aux yeuxdu client. A lintérieur de chaque itération, lapplication est construite,compilée ce qui la rend visible aux yeux de léquipe de développement.Enfin, il faut affecter les différents composants à développer aux différen-tes itérations. La décision de cette affectation se fait en sassurant quechaque itération produit quelque chose dutile au client, en identifiant eten gérant les risques, en prenant en compte les interdépendances natu-relles entre les composants, et en équilibrant lutilisation des ressources.Le meilleur outil pour réaliser cette répartition reste encore un tableaudont la première colonne contient tous les composants identifiés classéspar catégories (fonctionnalités de base, composants technologiques,support, etc.) et comprenant une colonne par cycle. Lexpérience prouveque lorsque ce type de planning est réalisé par léquipe et non unique-ment par le chef de projet, la compréhension du projet est améliorée.CollaborerCest cette phase qui délivre réellement les composants en état de fonc-tionnement. Durant cette phase, le chef de projet soccupe plus de veillerà ce que les développeurs collaborent efficacement entre eux plutôt quede concevoir, tester et coder. Comment les personnes interagissent etcomment elles gèrent leurs interdépendances sont toujours des problè-mes critiques. Dans le cas de petits projets, particulièrement si les mem-bres de léquipe travaillent à proximité les uns des autres, ces relationspeuvent être gérées de manière informelle. La communication se fait biensouvent par des discussions de couloir ou par des bribes de schémasdessinés sur un tableau blanc. Dans le cas dun projet plus importantimpliquant une équipe géographiquement disséminée, le problème estplus épineux. ASD nest pas une méthode fermée sur elle même. JimHighsmith lui même reconnaît que dans le cadre de projets de petitetaille, le développement collaboratif peut être amélioré par lutilisation decertaines des pratiques issues deXtreme Programming, comme parexemple la programmation en binôme ou la propriété collective du code.ApprendreUne pratique clé de la méthode ASD est un examen minutieux de la qualité,ce qui est un élément clé de la capitalisation des connaissances.
  • 44. Page 45/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1A la fin de chaque cycle de développement, quatre catégories de connais-sance peuvent être complétées :— Qualité du point de vue de lutilisateur / client : fournir une certaine visibi-lité au client et obtenir un feedback de sa part est un facteur clé de capi-talisation des connaissances et des expériences. Pour ce faire, ASD re-commande de procéder à des réunions appelées "customer focus group"à la fin de chaque itération. Le but de ces séances est dexplorer uneversion fonctionnelle de lapplication et de lister les demandes demodifications émanant du client.— Qualité du point de vue technique : une méthode standard pour évaluerla qualité dun point de vue technique est la revue technique ("technicalreview"). Une revue de la conception doit être faite à la fin de chaque ité-ration alors que des révisions du code et des plans de tests doivent avoirlieu tout au long du cycle.— Le fonctionnement de léquipe et les pratiques utilisées. Il sagit decontrôler les performances de léquipe. Ceci est fait au cours de réunionsqui portent le nom de "postmortems" à la fin de chaque itération et à lafin du projet. Ces réunions sont de véritables autopsies du projet aucours desquelles se posent quatre questions : quest ce qui fonctionnebien ? quest ce qui ne fonctionne pas encore ? sur quelle pratique de-vons nous insister ? que devons nous réduire ? Ce type de réunions for-cent les collaborateurs à apprendre sur eux mêmes et sur la manièredont ils travaillent.— Létat davancement du projet. Ceci na pas strictement de lien avec laqualité : il sagit simplement de revoir le planning au début de chaque ité-ration. Le questionnement basique porte sur : où en est le projet ? où enest le projet par rapport à ce qui était prévu ? où devrait-on en être ?Dans une approche à base de composants, létat davancement dun pro-jet ne peut pas se résumer en un seul document terminé ou un seul li-vrable, mais il consiste en un ensemble de composants dans divers étatsdavancement.3.3.4 Forces et faiblessesCette méthode fait preuve des qualités de méthodes agiles, à savoir sou-plesse face au changement, rapidité, respect des coûts et de délais, implica-tion du client pour une application qui correspond mieux aux besoins, etc.Il nen reste pas moins quASD reste un cadre très général qui demande àêtre adapté à chaque projet, et éventuellement à être enrichi déléments etde pratiques venus dautres méthodes agiles.3.4 CRYSTALMETHODOLOGIES3.4.1 OriginePlus quune méthodologie, Crystal est un cadre méthodologique très forte-ment adaptable aux spécificités de chaque projet. Ces méthodes ont étédéveloppées par Alistair Cockburn. Nous nous intéresserons ici à une desdéclinaisons de Crystal, Crystal Clear, qui rentre parfaitement dans le cadre
  • 45. Page 46/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1de notre étude et se prête à la comparaison avec les autres méthodes men-tionnées dans cette partie.3.4.2 Les valeurs partagées par léquipeCommunicationLa communication est omniprésente dans une équipe qui travaille avec laméthode Crystal. Ceci est une condition sine qua non pour réussir le "jeucoopératif" quest le projet. En effet, Alistair Cockburn écrit :"Software development is a cooperative game, in which the participants helpeach other in reaching the end of the game – the delivery of the software"La communication est tellement cruciale que le nombre de membres duneéquipe est limité à 6 personnes pour que léquipe puisse fonctionner. Il estrecommandé que tous les membres de léquipe soient placés dans la mêmepièce ou, au pire, dans deux pièces voisines afin de faciliter la communica-tion par la proximité.Toujours dans lidée que la communication et la collaboration produisent untravail de meilleure qualité, les schémas de modélisation sont généralementfaits en groupe sur un tableau blanc.Enfin, la collaboration avec les clients / utilisateurs est très serrée. Ce sontles utilisateurs qui expriment leurs besoins en écrivant des cas dutilisationtrès sommaires. Toutes les précisions seront apportées par la suite au coursde conversation entre utilisateurs et développeurs.Releases fréquentesDans un souci de souplesse face au changement, il est très important des-pacer au minimum les releases. Cette pratique permet en outre au clientdavoir au moins une partie utilisable de son application sans attendre la findu projet.Les livraisons fréquentes contraignent toutefois à réduire les livraisons austrict minimum utile : le code source commenté et le manuel dutilisation.SouplesseCrystal est une méthode très souple, tant au niveau des procédures à suivreque des normes à utiliser. Par exemple, les normes de codage et de nom-mage sont très peu contraignantes voire inexistantes pour certains points :ceci nest pas problématique dans la mesure où la taille de léquipe resteinférieure à 6 personnes et où ces personnes ont lhabitude de travailler en-semble, daider les autres à revoir leur code ce qui rend les normes quasinaturelles. Léquipe est relativement libre de sorganiser à sa guise : parmiles développeurs par exemple, on peut distinguer deux types dapproche.Certains commenceront par prendre une feuille de papier et un crayon pouressayer de schématiser la manière dont ils vont construire et organiser leurcode avant de démarrer réellement la programmation. Dautres au contrairefonceront tête baissée dans lécriture du code ce qui implique pour eux deconsacrer plus de temps par la suite au refactoring du code. La méthodeCrystal nest pas directive sur la manière de procéder : les personnalités de
  • 46. Page 47/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1chacun sont prises en compte et tant que le travail résultant est le même à lafin, la méthode reste dune grande souplesse.3.4.3 Processus CrystalSpécificationsUne première phase consiste à interroger le client et les utilisateurs pourquils expriment leurs besoins. Une pratique assez répandue consiste à ob-server les utilisateurs dans leur travail pour mieux connaître leurs besoins etleur environnement. Les spécifications sont collectées sous forme de casdutilisation sommaires : il sagit de décrire en une phrase une interactionentre lutilisateur et le système. En collaboration avec les utilisateurs, lesdifférents cas dutilisation sont classés par ordre de priorité ce qui permet desavoir quelles fonctionnalités ont le plus de valeur et quelles fonctionnalitéssont à développer en premier.Conception et planningUne première ébauche de conception est faite dans cette phase, cest à direau tout début du projet. Cela inclut le choix des technologies qui seront utili-sées pour la réalisation et une première ébauche de larchitecture pour sedonner une vision globale.Enfin, juste avant dentrer dans la phase itérative, il convient de planifier lesitérations qui vont suivre. Crystal recommande des itérations dune longueurdenviron 2 ou 3 mois, chacune produisant un livrable fonctionnel.ItérationsCest au cours de cette phase que se fait la réalisation proprement dite delapplication.Le premier travail consiste à clarifier et préciser les spécifications au cours dediscussions plutôt informelles entre utilisateurs et développeurs.Ensuite, les développeurs font tous ensemble un travail de conception pourdéterminer la manière dont ils vont mettre en place les objets de base surlesquels va sappuyer le système.Les développeurs se répartissent les différentes parties. Dans les deux se-maines qui suivent le début dune itération, il convient de mettre en place unemaquette qui permettra de faire une démonstration aux utilisateurs. Cettepratique permet bien souvent de déceler des incompréhensions dans lesbesoins exprimés.Les développeurs sont ensuite libres de procéder comme ils lentendent pourdévelopper la partie dont ils ont la charge.Les tests sont omniprésents dans le processus de développement : larchi-tecture est conçue de manière à pouvoir supporter des tests régressifs et destests automatiques. Les classes de tests font partie intégrante du code etsont souvent écrite avant le code lui même.Le refactoring du code est lui aussi permanent. Il se fait en général en bi-nôme pour optimiser la qualité du code.
  • 47. Page 48/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Deux ou trois fois par itérations, des démonstrations sont faites aux clients /utilisateurs ce qui permet de toujours bien recadrer le projet en conformitéavec les exigences du client.Lécriture du manuel utilisateur est effectuée soit juste avant la livraison dunerelease, soit dès le début de litération ce qui force les développeurs à définirplus précisément dès le début ce vers quoi ils sengagent.Litération se termine par lintégration et la mise en production de lapplicationqui est testée une fois de plus avant dêtre livrée au client.Figure 12 - Processus Crystal3.4.4 Forces et faiblessesCrystal Clear présente tous les avantages des méthodes agiles : flexibilitépar rapport au changement, rapidité, livraisons fréquentes, etc.Par contre, dans la version que nous avons décrite ici, elle reste limitée à deséquipes de taille inférieure à 6 personnes, en raison de labsence dune per-sonne ou dun groupe chargé de la coordination. Les processus et pratiquesde Crystal sont très souples et conviennent parfaitement pour des petitesstructures. Mais ce qui fait leur efficacité dans les projets de petite taillecause leur inadéquation pour des projets plus importants.En fait, les approches Crystal et eXtreme Programming sont très proches, àceci près queXtreme Programming nécessite beaucoup plus de discipline etest plus contraignante. Dun côté, cette particularité rend eXtreme Program-ming certainement un peu plus productive que Crystal Clear, mais dun autrecôté, tout le monde nest pas forcément prêt à en accepter les principes alorsque Crystal Clear sera certainement acceptée plus facilement.MaquetteDémoDémoClarification desspécificationsConceptioncollectiveSpécifications Ebauche deconceptionPlanningProgrammationTests en continuRefactoring du codeReleaseRédactiondu manuelutilisateur
  • 48. Page 49/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.13.5 SCRUM3.5.1 Les origines de ScrumLa méthode Scrum est née de la coopération de deux sociétés : AdvancedDevelopment Methods (ADM) et WMARK Software (éditeur d’environnementde développement orienté objet). Ces deux compagnies déploraient le man-que d’adéquation des anciennes méthodologies avec la programmationorientée objet et les architectures à base de composants. Scrum est le résul-tat de la volonté de mettre en place des processus empiriques, contrôlés pardes mesures quantitatives.Note : le terme Scrum est emprunté au rugby et signifie "mêlée". La méthodeporte ce nom car dans un processus Scrum se tient chaque jour une réunioninformelle, appelée Scrum, pour faire le point sur ce qui a été fait, ce qui vaêtre fait le lendemain et ce quil reste à faire pour la suite.3.5.2 Le processus Scrum : vue généraleLe cycle de vie d’un projet Scrum peut être divisé en trois parties :— La phase d’initiation est une phase linéaire aux processus explicitementconnus, et dont les inputs et outputs sont bien déterminés.— Le "sprint" de développement est un processus empirique : beaucoupdes processus de la phase de sprint sont inconnus et non identifiés. Cenest pas pour autant le chaos car des contrôles, incluant notamment laprise en compte du risque, encadrent chaque itération de la phase desprint pour ne pas tomber dans le chaos, tout en préservant la flexibilité.Le projet est ouvert sur son environnement jusquà la phase de clôture.Les livrables peuvent être modifiés à tout moment pendant les deuxpremières phases.— La phase de clôture est aussi une phase linéaire dont les processus sontclairement définis.Figure 13 - Vue globale du processus ScrumPhase dinitiation
  • 49. Page 50/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1La phase dinitiation comporte tout dabord une activité de planning. Dans lecas du développement dun nouveau système, il sagit de réaliser la concep-tualisation et lanalyse du système. La phase de planning doit aboutir à lamise en place dun "backlog", cest à dire une liste de tâches restant à effec-tuer, à la définition de la date de livraison et des fonctionnalités à livrer ainsiquà la formation de léquipe de développement. Cest à loccasion de cettephase que les aspects de management du risque et des coûts sont traités.Cette phase est en général relativement courte et ne met pas plus de 10personnes à contribution. Elle requiert pourtant des compétences variées,allant de la connaissance du marché, des utilisateurs potentiels, à des res-sources techniques issues dautres développement similaires ou utilisant lesmêmes technologies.Un travail sur larchitecture permet en outre de déterminer de quelle manièreles éléments du backlog seront implémentés. Il sagit en fait dune part dedéterminer larchitecture du système et dautre part de débuter la conceptiondétaillée.Phase de "sprints"Cest la phase de développement itératif. Elle sera décrite dans la partiesuivante.Phase de clôtureQuand léquipe de management estime que les variables de temps, exigen-ces, coûts et qualités concordent pour permettre le passage à une nouvellerelease, ils déclarent la clôture de la release en cours. Cette phase de clôtureprépare le produit pour une livraison : intégration, tests systèmes, documen-tation utilisateur, préparation de supports de formation, préparation de sup-ports marketing, etc.1 jourSprint30 joursscrumPlanning &Architecture• phases linéaires• processus bien définis• backlog• conceptualisation• analyse - conception• architecture systèmeSprints de développement• phase non linéaire• processus empirique• flexibilité• accueil du changement• contrôles permanents pour éviterle chaos, notamment managementdu risqueClôture• préparation de larelease• documentation finale• derniers tests• livraison
  • 50. Page 51/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.13.5.3 Les "sprints"Le développement à proprement parler se fait au cours de ce que la méthodeScrum appelle des "sprints". Les sprints sont guidés par des listes de tâchesà réaliser, classées par ordre de priorité : les "backlogs". Un sprint est unepériode de 30 jours environ durant laquelle léquipe est isolée de toute in-fluence extérieure, cest à dire quaucun travail supplémentaire ne peut êtreajouté à un sprint en cours, ni aucun modification du backlog ne peut êtrefaite pour le sprint en cours. Léquipe est libre de déterminer le meilleurmoyen de développer les fonctionnalités qui ont été retenues pour former laliste des tâches à effectuer pendant le sprint. Chaque jour, léquipe entièreparticipe à une réunion Scrum pour partager les connaissances acquises,faire un point sur lavancement et donner au management une certaine visibi-lité sur la progression du projet.Figure 14 – Itérations de la phase de "sprints"Backlog globalLe backlog global regroupe toutes les caractéristiques, fonctionnalités, tech-nologies, améliorations et corrections qui constitueront la future release delapplication. Au cours dun processus Scrum, le backlog nest pas statiquemais il évolue au fur et à mesure que lenvironnement évolue. Les managersfont constamment évoluer les spécifications pour sassurer que le produitsera le plus approprié possible.Tous les éléments qui constituent le backlog doivent être classés par ordrede priorité décroissante.Chaque élément du backlog est estimé en termes de coût de développe-ment, temps de développement (en jours), risque, complexité, etc. Les élé-ments du backlog peuvent avoir diverses origines et être dictés par des be-soins du marché, des contraintes de marketing, des contraintes techniques,etc.1jourSprint30 joursprototypeRéunion etdémonstrationspost-sprintRéunion deplanificationdu sprintBacklogglobalBacklog àréaliserpendant lesprintNormes, outils dedéveloppement,techniques,processus, etc.
  • 51. Page 52/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Sprint BacklogAprès chaque sprint, le suivant se prépare au cours dune réunion de planifi-cation réunissant toute léquipe. A cette occasion, développeurs et managersréunis définissent le backlog qui devra être réalisé au cours de litérationsuivante. Sur la base du backlog global qui aura été préalablement mis à jouret reclassé par ordre de priorité, léquipe sélectionne les tâches qui serontaccomplies au cours des 30 jours suivants. Si plusieurs équipes travaillent enparallèle, un backlog est établi pour chacune dentre elles de manière cohé-rente. La sélection des tâches à accomplir et des fonctionnalités à dévelop-per se fait dabord en fonction de lordre de priorité mais ce dernier peut êtremodifié pour des raisons de développement (par exemple, plusieurs tâchespréalablement disjointes peuvent être rapprochées si leur développement estfacilité par la mise en place dune interface commune ou dun module com-mun). Tout au long du sprint, chaque membre de léquipe a la responsabilitéde mettre à jour les éléments du backlog dont il est le propriétaire, ceci dansun souci de suivi permanent de lavancement du projet.SprintUn sprint, cest à dire une itération de 30 jours de la phase de développe-ment, est lui aussi subdivisé en itérations dune journée terminées par uneréunion quotidienne qui porte le nom de scrum (mêlée).Au cours dun sprint, léquipe ne peut recevoir aucun changement du backlogvenu de lextérieur. Toutes les modifications qui interviennent ne prendronteffet quà litération suivante. Cette disposition a pour but de protéger le tra-vail de développement fourni par léquipe du chaos qui règne à lextérieur etde permettre aux développeurs de se focaliser sur un certain ensemble defonctionnalités fixes à mettre en place. Par contre, les membres de léquipepeuvent modifier le backlog pour atteindre lobjectif du sprint fixé au départen termes de fonctionnalités.Tout au long du sprint, le travail réalisé est mesuré et contrôlé de manièreempirique. Chacun doit se focaliser sur les trois mêmes points : quest ce quia été fait pendant la journée ? que reste-il à faire ? quels sont les obstaclesqui gênent lavancement du projet ? Lavancement du projet est évalué àtravers quatre variables : coût, planning, fonctionnalités et qualité. Ces quatrevariables ne sont pas indépendantes, cest à dire quon ne peut pas fixerarbitrairement une valeur pour chacune dentre elles. Grâce à cette surveil-lance de lavancement, les déviations sont repérées assez tôt pour pouvoirêtre corrigées. Si le sprint devait demander plus de temps que prévu, on peutchoisir soit daugmenter le temps imparti, soit diminuer les fonctionnalités,soit de diminuer la qualité. En général, le coût ne peut pas subir daugmenta-tion pendant un sprint.La productivité est améliorée par la petite taille des équipes (4 à 7 personnesincluant concepteurs, architectes, développeurs, responsables qualité) et parlisolation des équipes pendant le sprint (espace de travail isolé, mais aussiperturbations extérieures éliminées). De plus, le travail collaboratif permet lepartage des connaissances et du savoir-faire.
  • 52. Page 53/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Le développement se fait de manière itérative : à lintérieur de chaque sprintse retrouvent les activités de planification, architecture, conception, dévelop-pement et implémentation.Chaque sprint produit un livrable visible et fonctionnel (voir démonstrationpost-sprint)Scrum (réunion quotidienne)Au cours dun sprint, une réunion quotidienne informelle de toute léquipe alieu, si possible toujours à la même heure et au même endroit. Ne peuventintervenir que les personnes qui travaillent effectivement sur le développe-ment. Les extérieurs y sont invités pour suivre lavancement du projet maisninterviennent pas, toujours dans ce souci de ne pas perturber le travail deléquipe par le chaos venu de lextérieur.Cette réunion nest pas sensée durer plus de 30 minutes et consiste en untour de table où chacun doit répondre aux trois questions : quest ce qui a étéfait depuis la veille ? que reste-il à faire ? comment le faire ?Le manager ou Scrum Master a pour rôle de prendre les décisions queléquipe est incapable de prendre par elle même et sengage à apporter unesolution à tout ce qui entrave le développement du projet, soit par ses pro-pres connaissances, soit en faisant appel à des ressources extérieures.Lutilité de telles réunions est assez évidente : elle permet dune part, unesynchronisation quotidienne de léquipe et dautre part, le partage desconnaissances.Réunion et démonstration post-sprintLa réunion post-sprint est loccasion dune part de montrer au client ce qui aété développé pendant les 30 jours précédents et dautre part de confronterles résultats du travail de léquipe avec la complexité et le chaos de lenviron-nement dans lequel lapplication sera utilisée.Cette réunion se déroule de manière informelle. Léquipe y présente ce qui aété fait, la manière dont elle a procédé pour atteindre les objectifs fixés et faitune démonstration de lapplication, en létat où elle est à la fin du sprint.En se basant sur le backlog, cest à dire sur ce quil reste à faire, sur un nou-vel état des lieux du marché et des besoins des utilisateurs et sur le proto-type issu du sprint précédent, cette réunion aboutit à la décision de publier ounon une release du logiciel et à la formulation des objectifs à atteindre à la finde litération suivante.3.5.4 Forces et faiblessesScrum présente des avantages certains par rapport aux méthodes plus tradi-tionnelles : cette méthode permet effectivement de répondre au changementavec une certaine souplesse et permet de modifier le projet et les livrables àtout moment, de façon à livrer la release la plus appropriée possible.Dautre part, bien que flexible, cette méthode se veut rigoureuse puisque lecontrôle des processus est omniprésent. En effet, le projet est constamment
  • 53. Page 54/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1managé à la lumière des quatre variables précédemment citées que sontdélais, coûts, fonctionnalités, et qualité.Du point de vue de la progression, Scrum accorde une place importante aupartage des connaissances au sein dune équipe, notamment au cours desréunions quotidiennes. Ceci est bien entendu un facteur qui améliore la pro-ductivité et la capitalisation des savoirs.Enfin, la pratique qui consiste à isoler léquipe du chaos extérieur pendant lesprint autorise les développeurs à se concentrer pleinement sur les fonction-nalités quils ont à développer, sans être perturbés par des changementsincessants des spécifications dictés par le client ou les exigences du marché.Ainsi, les développeurs peuvent conserver toute leur énergie à concevoir lessolutions les plus astucieuses pour atteindre leurs objectifs.On peut toutefois se demander si cette pratique nest pas en contrepartie unesorte de frein à lagilité. En effet, si on imagine quune modification des spéci-fications est ordonnée par le client en cours de sprint, est-il nécessaire decontinuer à développer en ignorant cela jusquau bout du sprint ? Prendre encompte les modifications au fur et à mesure de leur arrivée conduit, certes, àune baisse de productivité, mais dun autre côté, limite la production de codevoué à la destruction. Ce point particulier mérite donc dêtre examiné attenti-vement avant de mettre en place cette méthode.3.6 FEATUREDRIVENDEVELOPMENT3.6.1 Les grandes lignes de la méthodeFeature Driven Development est une méthode agile développée par Jeff deLuca et Peter Coad pour mieux gérer les risques existants dans les projetsde développement. Lidée de base de la méthode est de procéder par itéra-tions très courtes, de deux semaines, avec production à la fin de chaqueitération dun livrable fonctionnel. Les spécifications sont découpées le pluspossibles en caractéristiques simples : les "features" que lon peut regrouperen "feature sets".Pour les développeurs, procéder par itérations est très motivant puisquilsdoivent être capables de livrer toutes les deux semaines des composants quisont utiles au client, qui fonctionnent et sont porteurs de valeur pour lui.Du point de vue des managers, cette façon de procéder permet de connaîtrefacilement létat davancement du projet et davoir du concret à montrer auclient à chaque fin ditération. Le fait de délivrer fréquemment des compo-sants fonctionnels permet aussi une bonne gestion du risque.Les clients ont une vue claire sur le planning et les différentes étapes duprojet. Ils ont aussi des résultats concrets qui leur prouvent lavancée duprojet.3.6.2 La notion de "feature" et de "feature set"Cette notion est au centre de la méthode FDD puisque toute la conception etle développement sont faits autour des caractéristiques ("features") de lap-plication.
  • 54. Page 55/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Feature désigne une fonctionnalité porteuse de valeur pour le client, suscep-tible dêtre implémentée en deux semaines ou moins. Le formalisme utilisépour les décrire est le plus simple possible : <ac-tion> the <result> <by, for, of, to> a(n) <object> (ex : calculate the total of asale). Ce découpage en fonctionnalités simplissimes permet au client dex-primer ce quil attend de manière très simple.Ces features sont regroupées en groupes qui participent à une même fonc-tion plus globale. Le formalisme utilisé pour décrire les feature sets est alors :<action><-ing> a(n) <object> (ex : making a product sale to a customer).Au cours du développement du modèle global, une liste informelle de featu-res est établie sur consultation de personnes qui connaissent le domainedapplication et de divers documents. Par la suite, une liste détaillée est éta-blie. Cette façon de procéder permet de confronter des gens du métier pourdévelopper un business model commun avant détablir une liste détaillées defonctionnalités. Cela permet aussi aux développeurs de connaître un peumieux le domaine et la façon dont les choses sont liées. Cette pratique en-courage la créativité, linnovation et lexploration et conduit à la découverte denouvelles fonctionnalités qui apporteront un avantage concurrentiel.3.6.3 Les 5 phases dun projet FDDCe paragraphe passe en revue les différentes étapes qui structurent le projetet la façon dont elles senchaînent.Figure 15 - Les 5 phases dun projet Feature Driven DevelopmentPhase 1 : Développer un modèle globalCritère dentréeLe client doit être prêt à débuter le projet. A ce stade, il peut avoir une ébau-Construireun modèleglobalEtablir uneliste de« features »Planifierà partir desfeaturesConcevoirà partir desfeaturesDévelopperà partir desfeatures10 %4 %4 %1 %2 %2 %77 %Chiffre du haut : pourcentage de la partie linéaire (phases 1 à 3)Chiffre du bas : pourcentage de la partie itérative (phases 4 et 5)linéaire itératif
  • 55. Page 56/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1che de liste de besoins mais il nest pas sensé savoir précisément quelssont ses attentes. Souvent il ne sait pas faire la différence entre les fonc-tionnalités dont il un besoin absolu et celles quil serait bien davoir.TâchesFormer léquipe de modélisation Managers ObligatoireLéquipe modélisation est constituée à temps plein de développeurs et depersonnes connaissant le domaine. Il est conseillé de faire participer à tourde rôle tous les membres de léquipe de façon à ce que chacun ait une op-portunité dobserver et de participer.Etude du domaine Equipe modélisation ObligatoireUne personne du métier fait un court topo expliquant aux développeurs lescaractéristiques du domaine pour lequel ils devront développer lapplication.Etude documentaire Equipe modélisation OptionnelLéquipe parcourt tous les documents à sa disposition (modèles, exigencesfonctionnelles, modèles de données, manuels utilisateurs, etc.)Elaborer une liste informelle de featu-resArchitecteDéveloppeurs seniorObligatoireCette liste informelle est une première ébauche de celle qui sera établie aucours de la phase n°2.Développer un modèle en petits grou-pesEquipe modélisation ObligatoireChaque sous groupe établit un diagramme de classes pour un composant.Développer un modèle Equipe modélisationArchitecteObligatoireChaque sous groupe présente le résultat de son travail. Larchitecte peutproposer dautres alternatives. Lensemble de léquipe choisit une modélisa-tion pour base et, en reprenant ce qui a été fait, élabore un diagramme glo-bal clair et annoté.Lister les alternatives Equipe modélisation ObligatoirePour faire référence plus tard, un des participants note toutes les alternati-ves qui ont été considérées lors de la modélisation.VérificationValidation interne et externe Equipe modélisation ObligatoirePermet de clarifier et de vérifier la bonne compréhension du domaine, desbesoins en terme de fonctionnalités et létendue du projet.Critère de sortieLéquipe doit fournir les diagrammes de classes, une liste informelle de fea-tures, et de notes sur des modélisations alternatives. Tout ceci est soumis àrévision et acceptation par le chef de projet de développement et larchi-tecte.
  • 56. Page 57/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Phase 2 : Établir une liste détaillée de features classées par prioritéCritère dentréeLéquipe chargée de la modélisation doit avoir passé avec succès la pre-mière phase.TâchesFormer léquipe chargée détablir laliste détaillée des featuresChef de projet ObligatoireLéquipe feature est constituée de développeurs et de personnes connais-sant le domaine.Identifier les featuresFormer les feature setsEquipe features ObligatoireSur la base de la liste informelle établie à létape 1, léquipe transforme lesméthodes en features et surtout, lors de brainstormings, sélectionne etajoute des features qui correspondent encore mieux aux besoins et deman-des du client.Les features sont regroupées en features sets et en major feature sets.Classer les feature sets et les featurespar ordre de prioritéEquipe features ObligatoireUn sous groupe de léquipe se charge de classer les features en 4 catégo-ries : A (indispensable), B (intéressant à ajouter), C (à ajouter si possible), D(futur).Eclater les features trop complexes Equipe features ObligatoireLes développeurs et larchitecte sont chargés de découper les features quine peuvent pas être développées en moins de deux semaines en plusieursfeatures plus légères.VérificationValidation interne et externe Equipe features ObligatoirePermet de clarifier et de vérifier la bonne compréhension du domaine, desbesoins en terme de fonctionnalités et létendue du projet.Critère de sortieLéquipe doit fournir une liste détaillée de features, regroupées en featuresets et classées par ordre de priorité. Celle-ci est soumise à révision et ac-ceptation par le chef de projet de développement et larchitecte.Phase 3 : Planifier à partir des featuresCritère dentréeLétape 2 a été terminée avec succèsTâchesFormer léquipe planning Chef de projet ObligatoireLéquipe est constituée du chef de projet développement et des dévelop-
  • 57. Page 58/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1peurs seniors.Séquencer les features Equipe planning ObligatoireLéquipe planning détermine lordre dans lequel les diverses fonctionnalitésseront développées et fixe les dates auxquelles chacun des feature setsdevra être implémenté.Affecter des classes à leurs propriétai-resEquipe planning ObligatoireEn utilisant comme guide la séquence et le poids des différentes features,léquipe planning désigne les propriétaires des différentes classes.Affecter les feature sets aux dévelop-peurs seniorsEquipe planning ObligatoireEn utilisant comme guide la séquence et le poids des différentes features,léquipe planning désigne les développeurs seniors propriétaires des diffé-rents feature sets.VérificationAuto validation Equipe planning ObligatoireUne validation externe est faite si besoin par des managers seniors.Critère de sortieLéquipe doit fournir un planning détaillé et les dates butoirs de chaque itéra-tion. Tout ceci est soumis à révision et acceptation par le chef de projet dedéveloppement et larchitecte.Phase 4 : Concevoir à partir des featuresCritère dentréeLétape 3 a été passée avec succès.TâchesFormer léquipe DBF (Design By Fea-ture)Développeur senior ObligatoireFormation dun groupe responsable du design détaillé pour chaque feature.Etude du domaine Equipe DBF, do-maineOptionnelUne personne du métier fait un court tour dhorizon expliquant aux dévelop-peurs les caractéristiques du domaine pour lequel ils devront développerlapplication.Etude des documents référencés Equipe DBF OptionnelLéquipe passe en revue tous les documents se rapportant à la feature dontils ont en charge la conception.Construire un diagramme de séquence Equipe DBF ObligatoireLéquipe construit un diagramme de séquence formel et détaillé pour lafeature en question. Ce diagramme viendra sajouter au modèle du projet.
  • 58. Page 59/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Etablir les prologues de classes etméthodesEquipe DBF ObligatoireChaque propriétaire de classe met à jour les types de paramètres, les typesrenvoyés, les exceptions, les envois de messages…Inspection du design Equipe DBF ObligatoireLéquipe feature, aidée si besoin de personnes extérieures, révise laconception qui a été faiteLister les actions dinspection du de-signScripte ObligatoirePour chaque propriétaire de classe, les étapes de la révision sont consi-gnées.VérificationVérification Equipe feature ObligatoireFait en interne sur la base des diagrammes de séquence.Critère de sortieLéquipe doit fournir le diagramme de séquence détaillé, les diagrammes declasses mis à jour ainsi quune trace dautres alternatives de design intéres-santes.Phase 5 : Construire à partir des featuresCritère dentréeLétape 4 a été passée avec succès, cest à dire que les features qui doiventêtre implémentées au cours de litération en cours ont été conçues..TâchesImplementer classes et méthodes Equipe Features ObligatoireDéveloppement, conformément au diagramme de séquence et de classes.Des classes de tests sont ajoutées systématiquement.Inspection du code Equipe Features ObligatoireLe code est passé en revue, avant ou après les tests unitaires. Si besoin,cette tâche peut recevoir une aide extérieure.Liste des modifications apportées aucodeScripte ObligatoirePour chaque classe, les modifications sont listées et devront être mises àjour par le propriétaire de la classe.Tests unitaires Equipe Features ObligatoireChaque propriétaire de classe teste son propre code.Préparation pour lintégration Equipe DBF ObligatoireUne fois toutes les classes testées, on procède à leur intégration.Vérification
  • 59. Page 60/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Inspection du code et tests unitaires Equipe feature ObligatoireCritère de sortieLéquipe doit délivrer un composant fonctionnel, conformément aux spécifi-cations.3.6.4 Forces et faiblessesFDD présente les avantages des méthodes agiles, à savoir gestion des ris-ques, flexibilité par rapport au changement, rapidité, livraisons fréquentes,etc.FDD a déjà été utilisé avec des équipes de taille conséquente pouvant allerjusquà une vingtaine de développeurs. Le facteur limitant cependant la tailledune équipe est le nombre de développeurs seniors à disposition.La propriété du code revenant aux propriétaires de classes a lavantage dene permettre des modifications que par une personne qui a une vision glo-bale dune classe. On peut opposer à cela le principe de propriété collectivedu code en vigueur dans eXtreme Programming qui nécessite une plusgrande discipline mais peut savérer plus rapide si un développeur a besoinde modifier du code écrit par un autre membre de léquipe.Linspection du code permet dapporter un regard neuf sur chaque portion ducode et permet ainsi de produire un code de meilleur qualité. Cependant, lapersonne qui inspecte le code ne le connaît pas a priori et il lui faut donc unminimum de temps pour se familiariser avec ce code. Encore une fois, il peutsavérer plus judicieux de passer à la programmation en binôme pour évitercette perte de temps et faire la révision du code en même temps que sonécriture. FDD nest dailleurs par fermée à ce genre de pratiques qui pous-sent lagilité encore plus loin.3.7 RECAPITULATIF : COMPARATIFDESMETHODES AGILES3.7.1 Adaptation des méthodes à la taille des projets et des équipesToutes les méthodes mentionnées dans les paragraphes précédents ne sontpas applicables dans toutes les situations. En effet, selon quelles prévoientdes rôles bien définis, notamment des rôles chargés de coordonner et defaciliter la communication ou quelles laissent au contraire léquipe assezautonome, ces méthodes seront plus ou moins efficaces en fonction de lataille de léquipe et donc de la taille du projet.eXtreme Programming conseille de limiter la taille des équipes à une dou-zaine de personnes, ceci pour plusieurs raisons. Premièrement, XP laisseaux développeurs une très forte dose dautonomie et de responsabilités. Sicela se révèle particulièrement productif avec une équipe de taille réduite,dès que la taille de léquipe augmente, une telle autonomie devient aucontraire un frein. En outre, la communication est une valeur clé dXP. Elle sefait de manière informelle mais devient beaucoup plus délicate lorsqueléquipe sagrandit. Notons aussi que la pratique de la programmation enbinôme et surtout la rotation des binômes nécessite que tous les membres
  • 60. Page 61/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1de léquipe sentendent bien et se connaissent bien ce qui est dautant plusimprobable que la taille de léquipe est grande.DSDM de son côté est plus facilement adaptable à des équipes plus impor-tantes, grâce à une définition très précise des rôles et des responsabilités.Qui plus est, la méthode DSDM prévoit, en plus des rôles de sponsor exécu-tif et de chef de projet, un facilitateur et un rapporteur qui se chargent dorga-niser et de formaliser la communication au sein de léquipe (organisation etanimation des ateliers, synthèse, capitalisation et diffusion de linformation).Adaptive Sofware Development peut aussi bien être utilisée sur de petitsprojets que sur de gros projets, à condition dêtre correctement adaptée. Eneffet, plus que des processus bien définis, ASD véhicule des principes et desidées directrices qui restent valables sur de larges échelles. Ensuite, il fautbien évidemment définir la manière dont la méthode sera mise en œuvre demanière plus ou moins précise et formelle.Crystal Clear est certainement la moins formalisée des méthodes passées enrevue dans cette étude. Pour cela, elle ne sadapte quaux petites équipes(moins de 6 personnes). Par contre, il existe dautres méthodes non détail-lées ici appartenant à la famille des méthodes Crystal qui permettent desadapter à de plus vastes projets.Scrum nest applicable que pour des petits projets, ceci parce que les procé-dures et les interactions qui ont lieu dans le cadre dun sprint de 30 jours sonttrès implicites et empiriques. Si le cadre général du cycle de vie est assezprécis, il règne une certaine liberté à lintérieur même de chaque phase cequi rend difficile lutilisation de cette méthode dans le cadre déquipe degrande taille.Quant au RAD, en raison de la présence du groupe danimation et de rapportet de la possibilité de paralléliser les tâches (cest à dire de former plusieurspetites équipes travaillant chacune sur un point précis), il peut sappliqueraussi bien à des petits projets quà de plus importants.Figure 16 - Adaptabilité des méthodes à la taille des projetsRADRUPFDDScrumCrystal ClearASDDSDMXPÉquipe = 6 (Mise sur les pratiques les moins contraignantes à méthode très peu formalisée)Équipe = 12 (Importance de la communication informelle et de l’autonomie de l’équipe)(Nombreux processus empiriques et définis implicitement)Équipe = 20Extensible grâce aux rôles et aux responsabilités bien définis (facilitateur, etc.)Extensible mais reste très générale à nécessite une adaptation au cas par casImportance des processus bien définis à supporte de gros projetsPrésence d’un groupe de coordination et de rapport à encadre et formalise la communicationtaille du projet
  • 61. Page 62/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.13.7.2 Degré dexigence des méthodes agiles pour le clientToutes les méthodes agiles étudiées dans ce document présentent des simi-litudes au niveau de la relation entre le client et léquipe de développement.Bien souvent, avec les méthodes traditionnelles, le client nétait en contactquavec le chef de projet qui se chargeait, avec le client de collecter, clarifieret synthétiser les exigences pour établir les spécifications. Avec les nouvellespratiques des méthodes agiles, le client entre en relation non seulement avecle chef de projet, mais aussi avec le développeurs. Une des caractéristiquescommunes des méthodologies agiles est de renforcer la proximité entre leclient et léquipe de développement. En effet, le client est amené à travaillerdirectement avec les développeurs à la fois pour lexpression de ses exigen-ces et pour le suivi de lavancement à la fin de chaque itération. En rentrantplus dans les détails, les processus mis en œuvre dans chacune des métho-des diffèrent légèrement mais le principe reste le même : dans tous les cas leclient met ses exigences et ses besoins par écrit sous une forme assezsommaire qui décrit les interactions entre lutilisateur et le système puis lesprécisions se font au fur et à mesure de lavancement du projet. Dans tousles cas aussi, le feedback du client vers les développeurs est très importantpuisque toutes les méthodologies mettent en place des pratiques permettant,à la fin de chaque itération courte, de faire le point, de recadrer et repréciserles besoins.Ensuite, au niveau de la mise en œuvre, chaque méthode propose ses pro-pres pratiques avec un degré dimplication plus ou moins fort du client.eXtreme Programming, par exemple, est la méthode qui met en place lesrelations les plus étroites entre le client et les collaborateurs du projet puis-que le client est intégré à léquipe. Il prend en charge lexpression de sesbesoins sous la forme de user stories, établit ses priorités, participe au plan-ning game, conçoit et met en œuvre les tests fonctionnels. Le client prenddonc part activement dans le projet, ceci dautant plus que sa présence estrequise sur site à plein temps tout au long du projet.DSDM insiste plus sur la notion dutilisateur que sur la notion de client. Enréalité, il sagit juste de mettre en lumière le fait que le client doit apporter unevision dutilisateur par son implication dans le projet. Limplication active desutilisateurs est essentielle pour éviter des retards dans la prise de décision. Ace propos, DSDM préconise la simplification des procédures de gestion desmodifications et de prise de décision pour les rendre moins contraignantes etplus souples. Le rôle du client dans le projet est important : il ne se contentepas de fournir les informations nécessaires au déroulement du projet, il prenden charge des mini tests de recette, sassure de la qualité de la documenta-tion utilisateur et de la formation des utilisateurs nayant pas participé auprojet.Pour Adaptive Software Development, le client intervient sur la phase dinitia-lisation pour la définition des spécifications. Il participe aussi, à la fin de cha-que itération aux réunions des "customer focus groups" qui ont pour butdexplorer une version fonctionnelle de lapplication et de lister les demandesde modifications émanant du client. ASD, ne définit pas de tâches aussi pré-cises pour le client queXtreme Programming ou DSDM, ce qui nempêche
  • 62. Page 63/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1pas que son implication reste essentielle et permanente du fait de la progres-sion itérative.Dans un projet Crystal, la communication et la collaboration entre les déve-loppeurs et le client / utilisateur est primordiale, et se fait de manière très peuformalisée. Le client exprime ses besoins sous forme de cas dutilisationsommaires, toutes les précisions étant apportées par la suite au fur et à me-sure des itérations. Au cours de chaque itération, des démonstrations sontfaites au client pour lui permettre de recadrer les spécifications du projet.Lintervention du client dans un projet Scrum est beaucoup plus ponctuelle. Ilintervient pour la définition des exigences dans la phase dinitiation puis par-ticipe tous les 30 jours aux réunions et démonstrations post-sprints poursuivre le projet et faire part des modifications éventuelles à apporter. Sonintervention apparaît beaucoup moins permanente et continue que dans lesautres méthodes, puisque personne ne peut modifier les spécifications pen-dant un sprint, ceci pour préserver léquipe des développeurs du chaos quirègne à lextérieur.Enfin, Feature Driven Development procède sensiblement de la même ma-nière. Le client exprime ses besoins non pas sous forme de cas dutilisation,mais sous forme de features, et toutes les deux semaines, un point est faitsur lavancement. Étant donné que ce passage en revue a lieu tous lesquinze jours, il permet un bon feedback du client et une bonne souplesse parrapport à des changements de spécifications.Pour résumer, les méthodes agiles misent toutes sur une implication forte duclient. La clé du succès réside dans une présence fréquente et régulière,voire quasi permanente du client auprès des développeurs. Chaque méthodea ensuite ses propres pratiques plus ou moins formalisées et laisse plus oumoins de tâches à la charge du client.3.7.3 Facilité de mise en œuvre et contraintes en interneLes différentes méthodes que nous avons passées en revue présentent tou-tes des contraintes plus ou moins fortes qui font quelles sont plus ou moinsfaciles à mettre en œuvre.eXtreme Programming est généralement reconnue comme étant la méthodeprésentant les pratiques les plus exigeantes. XP demande de la part desdéveloppeurs beaucoup de courage : courage daccepter le changement, deprendre ses responsabilités, dêtre autonome, de sastreindre à un processusde tests contraignant. Les ingénieurs de développement doivent aussi accep-ter de programmer en binôme ce qui nest pas une pratique naturelle pourtous et sastreindre à reprendre tous les jours le code quils ont écrit pour lerendre plus propre, même sil fonctionne déjà. En terme de compétences, lesingénieurs de développement se doivent dêtre polyvalents puisquils doiventavoir la double compétence de développeur et de concepteur. Le rôle ducoach est aussi assez difficile à tenir dans un projet XP. En effet, son rôle estimportant puisquil porte la responsabilité globale du projet mais la difficultéréside dans le fait quil doit se montrer le moins intrusif possible et savoirdonner progressivement de lautonomie à léquipe.
  • 63. Page 64/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1La méthode DSDM est, elle aussi, assez exigeante en termes de mise enœuvre. Léquipe constituée de développeurs et dutilisateurs se voit confiéeune certaine autonomie puisquelle doit être autorisée à prendre des déci-sions, notamment concernant la modification des spécifications. Commedans XP les tests sont présents à tous les stades du cycle de vie ce qui estcontraignant. DSDM nécessite aussi des compétences particulières commecelle de médiateur, chargé de lanimation des ateliers facilités au cours de laphase dEtude du Business. DSDM prévoit des rôles définis très précisément(sponsor exécutif, visionnaire, facilitateur, rapporteur, etc.) et nécessitantcertaines compétences précises ce qui joue en faveur de la méthode mais encontrepartie rend plus contraignante sa mise en œuvre.Pour mettre en œuvre Adaptive Software Development, seule la phase dap-prentissage nécessite un état desprit particulier. Par ailleurs, le cycle de viedASD est bien défini tout en laissant à léquipe une grande souplesse dor-ganisation et les exigences en termes de compétences et de rôles particu-liers sont bien moindres que dans les deux cas précédemment cités.Crystal Clear insiste sur le caractère crucial de la communication et imposeque lensemble de léquipe soit localisée sur un même lieu. Hormis cettecontrainte dorganisation, léquipe reste relativement libre de sorganisercomme bon lui semble. En termes de processus, cette méthode est contrai-gnante en raison de lomniprésence des tests et du refactoring du code quedoivent simposer les développeurs.Scrum est une méthode assez peu contraignante en terme de processuspuisque dans le cadre du sprint, beaucoup de procédures sont empiriques.Feature Driven Development présente des processus très clairement définis,avec des phases explicitant clairement les tâches élémentaires à réaliser etdes indicateurs bien définis permettant de passer dune phase à une autre.De même, les rôles sont définis de manière précise (class owner, chief pro-grammer, etc). FDD est donc relativement contraignante à mettre en place.A partir de cette comparaison, il est possible de resituer qualitativement surun graphique les méthodes les unes par rapport aux autres en terme dedegré dexigence en interne et de difficulté de mise en œuvre. La mêmereprésentation peut être faite pour classer les méthodes en fonctions de leurdegré dexigence par rapport au client.
  • 64. Page 65/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Figure 17 - Positionnement des méthodes agiles en fonction descontraintes de mise en œuvreIl est difficile dévaluer ensuite lefficacité de chacune de ces méthodes. SieXtreme Programming est actuellement la méthode qui monte en force, ilfaut bien garder à lesprit quil nexiste stricto sensu ni bonne ni mauvaiseméthode. Il est impossible de porter une méthode au rang de meilleure mé-thode agile, pour la simple et bonne raison que la réussite dun projet dépendavant tout de ladaptation de la méthode au contexte.Contraintes sur le clientDSDMContraintes en interneASDCrystalScrumFDDXP
  • 65. Page 66/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1Les méthodes agiles présentées dans ce document appellent naturellementà réaction. Nous avons souhaité dans cette section vous faire part de notreretour sur le sujet, de nos expériences. Plus que tout, c’est le terrain qui estle véritable juge.4.1 LESMETHODES AGILES SONT ELLES VRAIMENTNOUVELLES?Les méthodes agiles introduisent en fait un certain nombre de concepts quisont pour beaucoup du bon sens en action. Bon nombre d’équipes mettentdéjà en œuvre une partie de ces principes, pas nécessairement de manière« extreme », mais avec des résultats sensibles. L’importance des tests, lanécessité de travailler en itérations courtes, le feedback client sont des élé-ments clés dans la réussite d’un projet. Les équipes mettent souvent en œu-vre un certain nombre de principes « agiles » sans même le savoir, un peu àla manière de Mr Jourdain.D’autres principes, plus extrêmes, comme le pair programming, constituentpar contre un saut quantique important.4.2 LABONNEMETHODEPOURLEBONPROJETIl nous semble essentiel de ne pas s’enfermer dans une méthode, qu’elle soitagile ou non. L’expérience montre que l’on ne peut calquer un schéma iden-tique sur l’ensemble des projets. La typologie des clients, la compétence etl’expérience des équipes, la nature de la relation entre la maîtrise d’ouvrageet la maîtrise d’œuvre sont des paramètres qui vont considérablement influersur le plan assurance qualité qui va être mis en œuvre. Cela ne veut pas direqu’il ne faut pas de méthode, bien au contraire. Simplement le cadre métho-dologique doit être adapté à chaque contexte. Difficile de mettre en placeUnified Process et UML sur des équipes Junior avec un projet informatiquede gestion en VB, par exemple.Les méthodes agiles obéissent à la règle. Adaptées à certains contextes,elles sont en revanche à proscrire dans d’autres. Nous restons persuadés àBusiness Interactif qu’un facteur de succès dans la mise en œuvre de cesméthodes est l’expérience forte de l’équipe, et notamment sa connaissancede méthodes dites «traditionnelles ». Sinon il y a fort à parier que le projetparte directement dans le mur. Extreme Programming, en particulier. Le ni-veau de responsabilité des développeurs nécessite une grande maturité.Même si le pair-programming permet de mettre dans la boucle un débutanten binôme avec un expérimenté, la présence de «vieux brisquards » estindispensable.Nous préconisons une adaptation du plan assurance qualité générique enchoisissant les «best practices » issues des différentes méthodes pour seconstituer un cadre adapté aux projets mis en œuvre.4. LES METHODES AGILES VUESPAR BUSINESS INTERACTIF
  • 66. Page 67/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.14.2.1 Un exemple : la modélisation de donnéesL’exemple le plus frappant concerne la modélisation de données. Sur desprojets d’informatique de gestion, la modélisation de données Entités-Relations (pour ne pas dire Merisienne) est à notre avis incontournable. C’estun facteur clé de succès, pour la réalisation du projet mais aussi pour samaintenance. Le risque de partir sur des méthodes complètement novatrices,appuyées sur UML ou même agiles (ces dernières préconisant de voyager« léger », et notamment de minimiser la documentation) est d’abandonner cetype de modélisation au profit unique de diagrammes UML ou autres. Seule-ment voilà : les outils gérant la persistance objet sont encore inadaptés auxgrands projets d’informatique de gestion et peu répandus ; le risque d’échecest alors non négligeable.Lors de son recrutement chez Business Interactif, chaque candidat passequelques tests de modélisation de données. Soyons clairs : les résultats destests sont souvent «extrêmes » dans leur faiblesse. Y compris chez despersonnes qui pourtant pratiquent le développement d’applications de ges-tion depuis plusieurs années…inquiétant, et pourtant révélateurs d’un rejetde méthodes qui ont fait leurs preuves.4.3 QUELLESSONTLESMAUVAISESMETHODES?Les méthodes agiles ont vu le jour en réaction à de grands échecs de pro-jets, souvent attribués aux méthodes qui avaient été mises en œuvre.Nous sommes persuadés qu’il n’y a pas de mauvaises méthodes. Commenous le disions, les échecs sont souvent liés au choix d’une méthode inadap-tée à un contexte, ou a à une mauvaise mise en œuvre de la méthode :insuffisance de la formation, inexpérience de l’équipe.4.4 QUELQUESPOINTSCLES CROSS METHODESAu delà de la méthode sélectionnée, il nous a semblé important de remonterquelques points clés dictés par l’expérience des projets, qui restent valablespratiquement dans tous les cas.4.4.1 Petites équipes et outils vélocesCe sont les petites équipes qui font les grands projets. Un exemple frappanta retenu notre attention dès la création de notre société. Nous sommes issusd’une culture C++ très forte, et à l’époque nous travaillions (comme beau-coup de développeurs C++) avec Borland C++ (devenu depuis C++ Builder).L’équipe qui réalisait le compilateur chez Borland était constituée d’uneéquipe de plus de 30 développeurs, tous reconnus comme des gourous duC++. Borland a sorti à ce moment de son chapeau Delphi, un outil de déve-loppement révolutionnaire, alliant la puissance du C++, la facilité de VB, avecla qualité syntaxique et objet du Pascal Objet. Delphi a été réalisé en untemps record par une équipe de 7 développeurs (le père de Delphi est au-jourd’hui le papa de C#), prenant de court l’équipe C++ sur tous les fronts.Delphi a été écrit d’abord en C++, puis rapidement les développeurs Borlandont utilisé Delphi lui même pour écrire Delphi. Cet événement est resté clédans notre histoire. Outre le fait que nous avons à l’époque adopté Delphi,nous avons compris que des équipes de 5-6 personnes armées des bons
  • 67. Page 68/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1outils, avec la bonne formation et la motivation pouvaient rivaliser avec deséquipes de 20 personnes. Car en informatique 1+1 n’ont jamais fait 2. De-puis, nos projets, à l’image d’OOSHOP, se sont toujours appuyés sur deséquipes qui tenaient plus des « voltigeurs » que des « artilleurs ». Nous res-tons persuadés qu’il s’agit d’un facteur clé de succès dans les projets, mêmesi cela implique de découper les grands projets en plusieurs sous-projets.4.4.2 Polyvalence des développeursLa polyvalence des développeurs est également un point clé. Même si cha-cun, de par ses affinités et son expérience a un domaine de prédilection, lesuccès des projets passe par la polyvalence des développeurs. Front-office,back-office, développement deux-tiers, trois-tiers, delphi, java, VB, C#…Unbon développeur est un développeur qui s’adapte rapidement à tous lescontextes, et qui accepte ces changements avec enthousiasme.Cela ne veut pas dire qu’il faille survoler tout sans rentrer en profondeur.C’est malheureusement un symptôme trop fréquent chez les développeurs :deux mois passés sur un langage et l’impression d’être un expert…les prossavent que même après 10 ans passés sur un outil ou un langage on endécouvre encore des facettes inexplorées. Mais il est important de tourner,de voir d’autres contextes, des technologies différentes…pour finalementpasser à un niveau « meta » où les patterns cross-outils sont tellement maî-trisés que le temps d’adaptation à un nouveau contexte se fait en deux troisjours.Polyvalence des développeurs signifie-t-elle propriété collective du code,comme le prône XP ? Cela reste un sujet d’interrogation. Nous pensons qu’ilest essentiel qu’un développeur puisse comprendre le code d’un autre déve-loppeur, même si c’est sur un langage différent. En revanche la modificationdu code écrit par un autre doit être prise avec précaution. Des effets de borddus à une maîtrise insuffisante du contexte sont fréquents.Aujourd’hui cette polyvalence est insuffisamment pratiquée par les entrepri-ses, alors qu’elle est essentielle.4.4.3 Feedback client et itérationsLe concept d’itérations courtes est essentiel. L’effet tunnel est à bannir. Unprojet, même un grand chantier, doit aboutir rapidement à des livrables surlesquels le client peut donner un feed-back. Maquettes, prototypes, modu-les : une livraison étagée est souvent clé.4.4.4 Gestion des risquesLa gestion des risques est un point clé du plan assurance qualité. Le chef deprojet doit avoir l’œil rivé sur les risques, en permanence. En particulier lesrisques en termes d’architecture et d’intégration, qui doivent être traités demanière prioritaire : inutile de partir bille en tête sur des parties maîtrisées sides risques d’architecture globale ne sont pas cernés et éliminés.4.4.5 Maîtrise d’ouvrage et maîtrise d’œuvre jouent dans le mêmecampLes relations entre la maîtrise d’ouvrage et la maîtrise d’œuvre sont essen-tielles. Ce sont souvent elles qui conditionnent le succès d’un projet. Pro-blème : les deux parties ne jouent pas toujours dans le même camps semble-
  • 68. Page 69/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1t-il. Seul un partenariat gagnant-gagnant et une réelle confiance entre lesdeux parties garantissent un avancement sûr des travaux.Les contrats forfaitaires ne jouent pas forcément en faveur d’une mise enœuvre des méthodes agiles. Le forfait présuppose un accord préalable surce qui doit être réalisé, alors que les méthodes agiles, XP notamment, sontpour une redéfinition possible du périmètre : « le client a le droit de modifierses exigences »…pas simple dans un cadre forfaitaire, ou chacun est entrain de vérifier si l’autre ne déborde pas de son périmètre. Lorsqu’une réelleconfiance s’instaure entre la maîtrise d’ouvrage et la maîtrise d’œuvre, il estpossible de tisser des liens étroits entre client et équipe de développement :un objectif global à atteindre est défini pour une date donnée, et une équipe« projet » travaille pour atteindre cet objectif global, sur des modalités à mi-chemin entre le forfait et l’assistance technique.4.4.6 Tester toujours et encoreLes méthodes agiles insistent sur un point qui est effectivement fondamen-tal : le test. Tests unitaires, tests d’intégration, tests de performance : le testdoit être une véritable culture, un exercice permanent. Que les tests soientécrits avant le développement (comme le préconise XP) ou non, que l’ons’appuie sur un framework de test de type Junit ou non, le test est incontour-nable. Malheureusement, des calendriers trop serrés et aussi une tropgrande confiance se soldent souvent par une insuffisance du test. En avoirconscience, c’est déjà parcourir la moitié du chemin.Dans le même registre, la prise en compte rapide des incidents est indispen-sable. Lorsque nous avons mis en place un Extranet clients permettantd’effectuer du reporting d’incident, clients et développeurs y ont trouvé leurcompte : incidents formalisés et prise en compte « industrielle » des incidentsaccélèrent le processus d’aboutissement du projet.L’extranet client de Business Interactif permet aux client de suivre en temps réel le traite-ment des incidents en cours.
  • 69. Page 70/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.14.5 LACULTUREETLES VALEURSIndépendamment des méthodes mises en œuvre, la culture d’entreprise et laphilosophie dans laquelle travaillent les équipes est probablement le pointessentiel. Les chantiers informatiques sont des chantiers d’hommes, et unemise en œuvre appliquée et besogneuse de recettes de cuisine ne sert à riensi elle ne s’insère dans un mouvement plus global, qui est au cœur de laculture d’entreprise. A chacun de construire la sienne.Chez Business Interactif, voici quelques valeurs clé qui sous-tendent la réali-sation de nos projets. Nous restons persuadés, depuis la création de nospremières applications Internet en 1994, que ces valeurs sont fondamentalesdans la réussite des projets.4.5.1 La culture de l’humilitéDémarrer un projet avec des chevilles un peu trop musclées et une confianceaveugle en soi sont des facteurs d’échec. L’humilité, la remise en causepermanente de ses méthodes, de son savoir sont essentielles pour avancer.4.5.2 Le pragmatismeFaire simple, toujours simple. Les usines à gaz ne mettent jamais très long-temps à exploser. Le refactoring est un travail permanent, que ce soit auniveau du code ou des architectures. A ce titre, une méthode trop formalistefinit par nuire à la simplicité et à la réactivité. «Voyagez léger » : voilà proba-blement l’une des meilleures pratiques d’Extreme Programming.4.5.3 Le souci de la qualitéUn projet n’aboutit pas si l’équipe toute entière ne maintient pas un niveaud’exigence très élevé vis à vis de ses travaux : a-t-on fait vraiment ce qu’onpouvait faire de mieux ? Le mieux n’étant pas nécessairement la solution leplus belle techniquement parlant mais la plus optimale. Cela demande beau-coup d’énergie et beaucoup de motivation, en particulier lorsque le contextedevient difficile (délais tendus, relation complexe et politique entre la maîtrised’œuvre et la maîtrise d’ouvrage…).4.5.4 Le partagePartager les connaissances est essentiel. Méthodes de développement,incidents rencontrés, le temps perdu a redécouvrir des éléments déjà maîtri-sés doit être minimisé. La mise en place d’une plate-forme de gestion desconnaissances à destination des équipes techniques est de ce fait capitale.Au delà du partage des connaissance, une communication permanente etsouvent informelle est indispensable entre tous les membres d’une équipe.Cela implique une culture forte du partage.
  • 70. Page 71/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.1L’intranet de Business Interactif permet aux équipes de partager en temps réel leursconnaissances sur l’ensemble des technologies et des méthodes mises en œuvre.4.5.5 Le courageLe développement, c’est comme le bâtiment. La tâche est souvent difficile etingrate, frustrante. Seul le résultat transcende le travail accompli. Bref, il fautdu courage, pour tenir sur la durée, et accepter de faire des choses pas tou-jours drôles. Tous les développeurs le disent : c’est dans les moments diffici-les que le rythme d’apprentissage est le plus rapide, encore faut il avoir unminimum de volonté pour affronter les difficultés.4.6 CONCLUSIONLes méthodes agiles ne sont probablement pas le dernier soubresaut quiagite les monde de la gestion de projet. A l’image des technologies, les ap-proches méthodologiques obéissent à des cycles. Les méthodes agiless’inscrivent dans une phase de réaction à un formalisme trop poussé.Faut-il pour autant rejeter les méthodes traditionnelles ? Rien n’est moinssûr. La meilleure méthode reste celle qui est le mieux adaptée au contexte.Merise, Unified Process, Extreme Programming : chacune apporte un regarddifférent sur la gestion de projet et le développement.Toutes, en tout cas, convergent vers deux principes : celui de la modularité(les méthodes sont des boîtes à outils) et celui de la complémentarité (lesméthodes ne sont plus systémiques et peuvent travailler de concert). A cha-cun de sélectionner les meilleurs outils…Voilà finalement l’un des enseigne-ments que l’on peut tirer des méthodes agiles.
  • 71. Page 72/72Business InteractifEXTREME PROGRAMMING - METHODES AGILES : LETAT DES LIEUX Référence : MethodesAgiles2001-V1.1.doc© Business Interactif – 2001 – www.businessinteractif.fr Version : 1.14.7 CHOISIRETMETTREENŒUVRELESMETHODESBusiness Interactif propose des formations sur la mise en œuvre des métho-des, que ce soit dans des contextes traditionnels ou agiles. N’hésitez pas àprendre contact avec nous sur le sujet.Business Interactif intervient également dans l’accompagnement des Direc-tions des Systèmes d’Information sur les aspects méthodologiques : quelleméthode choisir pour quelle projet ? Comment peut-on mettre en place unPlan Assurance Qualité adapté à un contexteprécis ? Comment améliorer lacommunication au sein des équipes de développement ? Autant de sujetssur lesquels Business Interactif peut apporter un éclairage, souvent par lamise en œuvre et l’animation de sessions de quelques jours regroupant desacteurs clés dans l’entreprise. Contactez nous pour en savoir plus.4.8 COLLABORER AVEC BUSINESSINTERACTIFCe white paper vous a donné envie de collaborer avec Business Interactif ?N’hésitez pas à nous contacter….Contact commerciaux :Alban Neveux – alban.neveux@businessinteractif.frPierre-Edouard de Leusse – pdl@businessinteractif.frRessources Humaines:Hélène Helffer – recrutement@businessinteractif.fr

×