Rapport exposé eXtreme Programming XP


Published on

Rapport de l'exposé eXtreme Programming

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Rapport exposé eXtreme Programming XP

  1. 1. ”‘‰”ƒƒ–‹‘ ‡–”²‡ ‡–”‡‡ ”‘‰”ƒ‹‰ ^ ,,zE ^ ^Z// E
  2. 2. ‘ƒ‹”‡• /EdZKhd/KE/ D D s D W h , s D W// W W W , W yW W/// K , Z/s yW yW W ss yW hD• KEh^/KE
  3. 3. • /EdZKhd/KE Le développement de logiciels a été pendant longtemps entièrement libre de directives ou de contraintes, et il ny avait aucune méthode pour analyser les besoins, produire une solution, ou même évaluer le succès. Mais depuis les débuts de linformatique commerciale dans les années 60,et en 1968, une conférence de lOTAN a introduit le terme « génie logiciel » et suggéré dutiliser les méthodes rigoureuses et éprouvées du génie civil au chaos du développement de logiciels. Lidée était louable, mais une différence majeure existe: contrairement à la physique et aux mathématiques, linformatique ne repose sur aucune loi et ne peut être vérifiée scientifiquement. Par après plusieurs méthodologies de développement de logiciel ont vu le jour. Le modèle en cascade et ses dérivés ont connu un grand succès, mais leur lourdeur et rigidité sont de sérieux handicaps. Extreme Programming propose de remplacer certaines notions acquises par des idées révolutionnaires, et de rendre le développement de logiciel efficace et agile. / Il existe différents types de cycles de développement entrant dans la réalisation dun logiciel.Ces cycles prendront en compte toutes les étapes de la conception dun logiciel. DLe modèle en cascade est hérité de lindustrie du BTP1. Ce modèle repose sur les hypothèsessuivantes : • On ne peut pas construire la toiture avant les fondations. • Les conséquences dune modification en amont du cycle ont un impact majeur sur les coûts en aval. d W
  4. 4. Les phases traditionnelles de développement sont effectuées simplement les unes après lesautres, avec un retour sur les précédentes, voire au tout début du cycle. Le processus dedéveloppement utilisant un cycle en cascade exécute des phases qui ont pour caractéristiques : • De produire des livrables définis au préalable. • De se terminer à une date précise. • De ne se terminer que lorsque les livrables sont jugés satisfaisants lors dune étape de validation-vérification.2 D sLe modèle du cycle en V a été imaginé pour pallier le problème de réactivité du modèle encascade. Ce modèle est une amélioration du modèle en cascade qui permet en cas danomalie,de limiter un retour aux étapes précédentes. Les phases de la partie montante doivent renvoyerde linformation sur les phases en vis-à-vis lorsque des défauts sont détectés afin daméliorerle logiciel.De plus le cycle en V met en évidence la nécessité danticiper et de préparer dans les étapesdescendantes les « attendus » des futures étapes montantes : ainsi les attendus des tests devalidation sont définis lors des spécifications, les attendus des tests unitaires sont définis lorsde la conception, etc. D
  5. 5. Le cycle en V est devenu un standard de lindustrie du développement de logiciel et de lagestion de projet depuis les années 1980. D Ce mouvement est apparu au milieu des années 90 il avait pour but de rendre le processus de développement plus efficace, en utilisant des concepts très simples et reconnus. Il nest directement relié à aucune méthodologie, mais propose une série de recommandations, valeurs, et principes qui sont appliquées dans dautres méthodes. W Les méthodes agiles sont des méthodes de gestion de projets informatiques et de développement qui se positionnent en réaction à des méthodes traditionnelles jugées trop lourdes. XP fait partie de cette catégorie dont la première idée a été de réagir face à la bureaucratie où toute démarche exige une grande quantité de temps. C’est aussi la plus populaire des méthodes agiles mais on peut aussi citer : ASD (Adaptative Software Development), SCRUM, Crystal, FDD (Feature Driven Development) et DSDM (Dynamic System Development Method) qui peuvent chacune être adaptée à une situation particulière, fonction de la taille de l’équipe. h ,
  6. 6. En 1986, Barry W. Boehm présentait un nouveau modèle de développement itératif etincrémental.En 1986 également, Hirotaka Takeuchi et Ikujiro Nonaka publient « the new new productdeveloppement game » dans la Harvard business review. Leur article présente un modèle dedéveloppement basé sur laptitude au changement, lauto organisation, limbrication des phasesde développement, et litération (on y fait dailleurs mention du mot scrum par analogie aurugby).En 1991, James Martin (RAD3), s’appuyant sur cette vision d’une évolution continue, proposaune méthode de développement rapide d’application. Sa structure, base des approchesactuelles, déterminait le phasage essentiel et mettait en œuvre un principe adaptatif fondé surla validation permanente des utilisateurs.À partir de 1994, Jean-Pierre Vickoff en France, notamment avec le Processus RAD publiépar le Gartner Group, et Jennifer Stapleton en Grande-Bretagne, avec DSDM, introduisirentdes compléments tels que : • la spécialisation des rôles, • l’instrumentation des communications, • l’organisation des divers types de réunions, • le groupe de facilitation et de rapport, • les « raccourcis méthodologiques » de modélisation, • l’architecture de réalisation (imbrication des itérations), • la formalisation de processus légers de mise en œuvre.Dans la seconde moitié des années 1990, une vague d’une dizaine de méthodes (dont Extremeprogramming et Scrum sont les principales représentantes) poussa à l’extrême certainespratiques de qualité de la construction applicative ainsi que les techniques adaptativesd’estimation, de planification et de pilotage de projet.
  7. 7. En 2001, aux États-Unis, dix-sept figures éminentes du développement logiciel se sontréunies pour débattre du thème unificateur de leurs méthodes respectives, dites méthodesagiles. Les plus connus dentre eux étaient Ward Cunningham, linventeur du Wiki viaWikiWikiWeb, Kent Beck, père de lextreme programming et cofondateur de JUnit, KenSchwaber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith, prônant lASD, AlistairCockburn pour la méthode Crystal clear, Martin Fowler, et Dave Thomas ainsi que Arie vanBennekum pour DSDM (Dynamic System Development Method). Ces 17 experts venant tousdhorizons différents réussirent à extraire de leurs concepts respectifs des critères pour définirune nouvelle façon de développer des logiciels :4De cette réunion devait émerger le Manifeste Agile, considéré comme la définition canoniquedu développement Agile et de ses principes sous-jacents.5 s DLes quatre valeurs fondamentales (entre parenthèses, les citations du manifeste)6: • Léquipe (« Personnes et interaction plutôt que processus et outils ») : Dans loptique agile, léquipe est bien plus importante que les outils (structurants ou de contrôle) ou les procédures de fonctionnement. Il est préférable davoir une équipe soudée et qui communique, composée de développeurs (éventuellement à niveaux variables), plutôt quune équipe composée dexperts fonctionnant chacun de manière isolée. La communication est une notion fondamentale. • Lapplication (« Logiciel fonctionnel plutôt que documentation complète ») : Il est vital que lapplication fonctionne. Le reste, et notamment la documentation technique, est une aide précieuse mais non un but en soi. Une documentation précise est utile comme moyen de communication. La documentation représente une charge de travail D D D D yW^ZhD W DyW h W D s D ^ s Ez /^E y D
  8. 8. importante, mais peut pourtant être néfaste si elle nest pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de léquipe (on en revient à limportance de la communication). • La collaboration (« Collaboration avec le client plutôt que négociation de contrat ») : Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec léquipe et fournir un feed-back continu sur ladaptation du logiciel à ses attentes. • Lacceptation du changement (« Réagir au changement plutôt que suivre un plan ») : La planification initiale et la structure du logiciel doivent être flexibles afin de permettre lévolution de la demande du client tout au long du projet. Les premières releases du logiciel vont souvent provoquer des demandes dévolution. WCes quatre valeurs se déclinent en douze principes généraux communs à toutes les méthodesagiles7 : • « Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles » • « Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client » • « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte » • « Les gens de lart et les développeurs doivent collaborer quotidiennement au projet » • « Bâtissez le projet autour de personnes motivées. Donnez leur lenvironnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail » • « La méthode la plus efficace pour transmettre linformation est une conversation en face à face » • « Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet » d
  9. 9. • « Les processus agiles promeuvent un rythme de développement durable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment »• « Une attention continue à lexcellence technique et à la qualité de la conception améliore lagilité »• « La simplicité - lart de maximiser la quantité de travail à ne pas faire - est essentielle »• « Les meilleures architectures, spécifications et conceptions sont issues déquipes qui sauto-organisent »• « À intervalles réguliers, léquipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens ». D
  10. 10. Il existe de nombreuses méthodes agiles telles que8 : • Rapid Application Development (RAD, 1991) • Dynamic systems development method (DSDM, 1995, consortium anglais commercialisant le RAD) • Scrum (1996) • Feature Driven Development (FDD) (1999) • Extreme programming (XP, 1999) • Adaptive software development (ASD, 2000) • Test Driven Development (TDD, 2002) • Crystal clear (2004) // W W WLa programmation eXtrème dite XP (eXtreme Programming) est une méthodologie efficacede développement rapide de logiciels qui exige que les membres d’une équipe dedéveloppeurs soient physiquement proches les uns des autres.XP est une méthode de développement dédiée à des petites équipes confrontées à unenvironnement changeant ou des besoins mal connus. Cette méthode est née sur le terrain, àpartir des observations et recherches de développeurs expérimentés soucieux de se concentrersur les nécessités élémentaires du développement : • Développer vite : S’assurer que les changements restent toujours faciles pour conserver une vitesse dedéveloppement soutenue tout au long du projet. • Développer juste :Se focaliser sur les besoins réels du client. D D
  11. 11. XP définit une discipline de développement qui permet de diminuer le coût du changementdans le logiciel, à tel point quil devient plus avantageux de prendre la décision le plus tardpossible, en attendant les résultats concrets issus du développement lui-même.Les spécifications peuvent alors être élaborées progressivement tout au long dudéveloppement en enchaînant des itérations rapides de spécification / développement /livraison. Le client peut ainsi guider le développement tout au long du projet.La méthodologie a été établie pour livrer le logiciel dans les délais impartis. Les développeurssont préparés aux changements des besoins du client, même dans la fin du cycle dedéveloppement.Managers, clients et développeurs font partie de la même équipe dont le but est de fournir unlogiciel de qualité. XP rend possible simplement et efficacement le développement en groupede travail.XP est basé sur des principes essentiels : Une forte réactivité au changement des besoins du client au plus tôt dans le cycle de vie dulogiciel Un travail déquipe (développeurs / chefs de projets / clients) La qualité du code : elle garantit un gain dargent pour le client La qualité des tests effectués au plus tôt Une intégration permanenteXP : (une méthodologie allégée)Une méthodologie logicielle est un ensemble de règles et de pratiques mises en œuvre pour lacréation de programmes. Ces règles sont trop difficiles à suivre, les procédures complexes etmal comprises et la quantité de documentation à produire hors de contrôle.Pour essayer de rester dans le planning, il est nécessaire de simplifier les règles, garder cellesqui contribuent à la qualité et laisser de côté celles qui ralentissent le projet.LXP est une méthodologie allégée car elle est constituée de peu de règles et de mises enpratique. Le travail en équipe, la réactivité, la concision et lefficacité sen trouvent renforcés.
  12. 12. XP est une méthode basée sur des principes simples, que tout le monde pratique déjà sans lesavoir. Mais alors, où est la « révolution » ?Rendre moins lourdes les démarchesLe but d’XP est de trouver des solutions plus ou moins simples, basées sur des principeséprouvés, pour tenter de diminuer les risques pour respecter les délais et la qualité du produitcommandé.Cela, en trouvant un compromis équilibré entre pas de démarche et trop de démarche, touten respectant le minimum de discipline nécessaire pour attendre un retour sur investissementen temps et en effort immédiat et intéressant.Ainsi, on souhaite réduire radicalement la production de documents en se focalisant sur uncode bien commenté plutôt que sur des documentations techniques très formelles.XP évite donc avec cela les lourdeurs des méthodes classiques et est donc un habilecompromis entre une méthode traditionnelle et le développement « cow boy », sans règlesprécises. Par conséquent le travail des informaticiens est totalement tourné vers la techniqueoù ils se sentiront vraisemblablement plus à l’aise.Changer les principesEn outre, XP, en tant que méthode agile, se veut adaptative plutôt que prédictive. C’est à direqu’à l’inverse des méthodes lourdes qui tentent de dresser un plan au début du projet, XPindique qu’il vaut mieux agir sur le court terme. Cela, tout simplement parce qu’il n’existe pasde projet figé où le prédicat de base ou le contexte ne changent pas du tout. Dans ce cas, lecoût du changement a une croissance logarithmique en fonction du temps.Le simple fait de ne pas être réticente aux changements permet dans un premier temps demieux s’y adapter mais permet aussi une meilleure relation avec le client et la livraison d’unproduit conforme totalement aux exigences de ce dernier.Enfin, le dernier but d’XP est de se vouloir orienter sur les personnes plutôt que sur lesprocessus. Alors, le développement tentera d’être une activité agréable plutôt qu’uncauchemar bureaucratique. ,La naissance d’une nouvelle méthode arrive rarement sans raisons. Elle fait plutôt suite à unepériode difficile...D’après une étude américaine menée en 1994 sur 8000 projets, 16 % n’ont pas respecté lesdélais et le budget initial et, pire, 32 % n’ont jamais abouti.
  13. 13. Ainsi, dans le monde de l’ingénierie logicielle, trois plaies pourtant bien connues envenimentle développement d’applications.La première concerne le planning difficilement maîtrisé ou impliquant de nombreuses heuressup. Le deuxième est issue des besoins souvent mal identifiés ou mal compris en raison d’uncahier des charges mal étudié ou incomplet.Tout cela implique des changements au cours du développement, d’autant plus si le clientdécide de modifier le produit, après une première maquette par exemple. Enfin, le dernierproblème concerne la livraison finale du produit qui est parfois buguée.XP est né lors d’une récente vague de création de nouvelles méthodes parallèlement àl’explosion de l’informatique dans les entreprises et de l’émergence du freeware.Lors de cette vague, sont essentiellement apparues des méthodes qualifiées d’agile dont XPfait partie. yW W yW W yW La méthode est très attentive à l’activité en dernière analyse essentielle dans un projet de logiciel : la programmation. Le codage produit la documentation principale : les fichiers sources. Pourquoi « extrême » programming ? Kent Beck, qui structure et présente XP, explique que les pratiques sur lesquelles est bâtie XP sont autant de boutons de contrôle… qu’il pousse au maximum. De ce point de vue, XP est la réunion cohérente de pratiques efficaces, telles que le test omniprésent, l’esprit d’équipe, le rôle prépondérant du client dans l’équipe, etc. Le bon sens est poussé à son extrême ! W Petites à moyennes équipes écrivant des logiciels dont les besoins sont vagues ou changent rapidement
  14. 14. /// K , W d A. Programmeur Développeur : • Responsabilisation Retour du programmeur comme rôle central A la fois : codeur, testeur, concepteur et analyste Apprentissage Qualités humaines nécessaires XP : Ecole de l’excellence Responsabilisés pour donner le meilleur d’eux même ex. : estimation des charges et délais • Pratiques XP Programmation en binôme Responsabilité collective du code Tests unitaires Règles de codage Conception simple Intégration continue Remaniement Rythme durable B. Client : • Responsabilisation Description informelle d’une fonctionnalité ou d’une interaction avec l’utilisateur Le plus simple possible
  15. 15. Des scénarios initiaux sont dégagés et Présentés, classés par priorité et répartis enitérations • Pratiques XP Planification itérative Rédaction des scénarios clients Séances de planification Tests de recette Intégration continue Rythme durable C. Testeur : • ResponsabilisationDéfinit et automatise les tests de recette Conseille le client sur la testabilité d’une Fonctionnalité. Utilisation d’outils différents pour scripter.Garant du sentiment de réussite sur le projet Test fonctionnel réussi→ Progression. Communiquer pour motiver (graphique de progression...). • Pratiques XPSuivi des tests (planification itérative)Tests de recetteIntégration continueRythme durable D. Tracker : • ResponsabilisationPas un supérieur hiérarchiqueQuelqu’un a qui on peut se confierDe préférence pas un programmeur, mais quelqu’un d’extérieurPour éviter les discussions techniquesA défaut, ce rôle peut tourner entre les programmeurs à chaque itération • Pratiques XPPlanification itérative E. Manager : • ResponsabilisationIl s’occupe matériellement de l’équipe Il demande des comptes (sur les engagements pris) Interface avec l’extérieur (dans le cadre d’un sous-projet)
  16. 16. • Pratiques XP Scénarios client Planification itérative Rythme durable F. Coach, le chef de projet : • Responsabilisation Il réunit tout les autres rôles Vérifie que chaque rôle est respecté Ses buts ultimes : o Equipe autonome o Chaque programmeur est en amélioration continue Ses qualités o Expert de la méthode XP o Expert technique o Programmeur chevronné o Architecte o Pédagogue et sensible o Sang-froid • Pratiques XP Toutes ! Z W d ^ W W d D d/s yW yW i. Planification et gestion :
  17. 17. Écrire des scénarios utilisateur «user stories» avec le clientSegmenter le projet en itérations (exemple: livraisons aux X semaines)Débuter chaque jour par une réunion d’équipe debout !Déplacer les personnes (inter changer les paires)Le code appartient à toute l’équipe ( egoless prog., Weinberg, 1971)Ne pas faire de temps supplémentaire «ideal week» ii. Conception :KIS = «keep it simple»: utiliser des cartes CRC (ou léger UML)Représenter une histoire utilisateur à la foisAdopter un codage uniforme: noms, standards…Ne jamais ajouter de fonctionalité trop tôtEncourager la reconstruction avant une nouvelle itération iii. Les activités et processus.Le client (expert disponible) priorise les histoiresLa vitesse du projet est mesurée (et adapte les itérations)Le test unitaire est produit avant le code (+1 par bogue)Le code pour livraison est programmé par binômes (paire)L’intégration est fréquente et se fait séquentiellementLes tests d’acceptation sont exécutés souvent et publiés
  18. 18. b. Les pratiques de l’XP K K d d W d D ^ h d Z Z / ^ h ^ Dans cette partie nous aller présenter les treizes pratiques «canoniques» dont XPdéfinit, et que nous classons en trois grandes catégories: celles relatives à la programmation,celles relatives au fonctionnement interne de l’équipe et celles qui sont liées à la planificationet aux relations avec le client. W K K d d W D d h ^ d Z Z / ^ h ^ Dans cette partie nous aller présenter les treizes pratiques «canoniques» dont XPdéfinit, et que nous classons en trois grandes catégories: celles relatives à la programmation,celles relatives au fonctionnement interne de l’équipe et celles qui sont liées à la planification
  19. 19. et aux relations avec le client. 1. Les pratiques de programmation Au cœur des pratiques XP, les pratiques de programmation que nous présentons ci-aprèspermettent d’améliorer continuellement la conception et le code de l’application pour qu’ellereste toujours aussi claire et simple que possible : • Conception simple (simple design) : les développeurs implémentent toujours la solution la plus simple qui puisse fonctionner. En particulier, ils n’inventent pas de mécanismes génériques si le besoin immédiat ne l’exige pas. • Remaniement (refactoring) : les développeurs n’hésitent pas à revenir sur le code écrit pour le rendre plus «propre», le débarrasser d’éventuelles parties inutilisées, et le préparer à l’ajout de la fonctionnalité suivante. D’une manière plus générale, cette pratique propose une démarche de conception continue qui fait émerger la structure de l’application au fur et à mesure du développement. • Développement piloté par les tests unitaires (test-first programming, unit tests, developer tests) : les développeurs écrivent des tests automatiques pour le code qu’ils produisent, et ce au moment même d’écrire le code en question. Cela leur permet d’une part de mieux cerner le problème avant d’écrire le code, et d’autre part de constituer progressivement une batterie de tests qui les autorise ensuite à apporter rapidement des changements dans l’application, tout en conservant une certaine sérénité. • Tests de recette (acceptance tests, customer tests) : le client précise très explicitement ses besoins et les objectifs des programmeurs – en participant à la rédaction de tests de recette. Comme les tests unitaires, les tests de recette doivent être automatiques afin de pouvoir vérifier tous les jours la non-régression du produit. 2. Les pratiques de collaboration Dans une équipe XP, tous les développeurs travaillent ensemble (voir chapitre 5) etinterviennent sur la totalité de l’application. Cela garantit la qualité de cette dernière à traversles relectures croisées que cela engendre, mais cela rend également le travail plus motivant et
  20. 20. offre une plus grande souplesse dans l’affectation des tâches. Les pratiques qui régissent cetteorganisation sont les suivantes : • Programmation en binôme (pair programming) : lorsqu’ils écrivent le code de l’application, les développeurs travaillent systématiquement à deux sur la même machine – il s’agit là d’une forme «extrême» de relecture de code, dans laquelle les deux développeurs collaborent activement pour résoudre les problèmes qu’ils rencontrent. Les binômes changent fréquemment, ainsi chacun est amené à travailler tôt ou tard avec tous les autres membres de l’équipe. • Responsabilité collective du code (collective code ownership) : tous les développeurs de l’équipe peuvent être amenés à travailler sur toutes les parties de l’application. De plus, ils ont le devoir d’améliorer le code sur lequel ils interviennent, même s’ils n’en sont pas les auteurs initiaux. • Règles de codage (coding standards) : les développeurs se plient à des règles de codage définies par l’équipe elle-même, de manière à garantir l’homogénéité de leur code avec le reste de l’application, et ainsi à faciliter l’intervention d’autres développeurs. • Métaphore (metaphor) : les développeurs n’hésitent pas à recourir aux métaphores pour décrire la structure interne du logiciel ou ses enjeux fonctionnels, de façon à faciliter la communication et à assurer une certaine homogénéité de style dans l’ensemble de la conception, l’idéal étant de décrire le système dans son ensemble par une métaphore unique. • Intégration continue (continuous integration) : les développeurs synchronisent leurs développements aussi souvent que possible – au moins une fois par jour. Cela réduit la fréquence et la gravité des problèmes d’intégration, et permet de disposer à tout moment d’une version du logiciel qui intègre tous les développements en cours. 3. Les pratiques de gestion de projet Les pratiques de programmation et de collaboration (voir chapitre 6) permettent decréer un contexte dans lequel une démarche de spécification et de conception purementitérative devient viable. Les pratiques suivantes montrent comment XP exploite cet avantage
  21. 21. afin de s’assurer que l’équipe et son client restent en phase tout au long du projet, de façon àconverger au plus tôt vers un produit adapté aux besoins du client : • Livraisons fréquentes (frequent releases) : l’équipe livre des versions du logiciel à un rythme régulier, aussi élevé que possible – la fréquence précise étant fixée par le client. Cela permet à l’équipe comme au client de s’assurer que le produit correspond bien aux attentes de ce dernier et que le projet est sur la bonne voie. • Planification itérative (planning game) : la planification du projet est réalisée conjointement par le client et l’équipe de développement, au cours de séances dédiées, organisées régulièrement tout au long du projet. • Client sur site (on-site customer, whole team) : le client est littéralement intégré à l’équipe de développement pour arbitrer les priorités, et définir précisément ses besoins,notamment en répondant en direct aux questions des programmeurs et en bénéficiant du feedback immédiat d’une application aux livraisons fréquentes. • Rythme durable (sustainable pace) : l’équipe adopte des horaires qui lui permettent de conserver tout au long du projet l’énergie nécessaire pour produire un travail de qualité et mettre en œuvre efficacement les autres pratiques. s
  22. 22. Z ^ NB : La valeur ‘Respect’ existe dès la deuxiéme version d’XP on se contente d’étudier quatreautres valeurs. Après si elles sont indispensables aujourd’hui pour mettre l’Extreme Programming enœuvre, les pratiques que nous venons de présenter ne suffisent pas pour autant à le définir. Ilne s’agit en définitive que de techniques, destinées à faire émerger un environnement detravail marqué par les quatre qualités érigées en valeurs par XP et qui en font l’essence : lacommunication, la simplicité, le feedback et le courage. 1) La communication pour une meilleure visibilité Du point de vue d’XP, un projet de développement est avant tout un effort collectif decréation, dont le succès dépend d’une part de la capacité de ses différents intervenants às’accorder sur une vision commune de ce qui doit être produit, et d’autre part de leur capacitéà synchroniser leurs actions individuelles pour atteindre l’objectif commun. Or, ces deuxconditions dépendent en majeure partie de la qualité de la communication qui lie cesintervenants entre eux. Mais sur le fond, il n’y a finalement pas grand-chose de spécifique àXP sur ce point. Ce qui démarque l’approche XP dans ce domaine, c’est l’accent mis sur la communicationdirecte, sur le contact humain. Certes, la communication orale présente des faiblesses entermes de structuration de l’information et de traçabilité, mais elle tire sa force de sa
  23. 23. simplicité et des interactions rapides entre les interlocuteurs qui permettent de convergerrapidement sur les informations essentielles. En outre, le contact direct permet de véhiculerdes informations beaucoup plus personnelles cela donne ainsi l’occasion d’identifier et derésoudre des blocages qui relèvent de positions individuelles, qui sans cela pourraientcompromettre les chances de succès du projet. Au quotidien, la communication directe permet donc d’obtenir une «bande passante»nettement supérieure à l’écrit, et XP exploite largement cet avantage dans la plupart de sespratiques. Ainsi, qu’il s’agisse de l’identification des besoins, de la planification, de larépartition des tâches ou encore de la programmation proprement dite, la plupart des pratiquesd’XP sont conçues pour amener les intervenants du projet à communiquer directement etrésoudre les problèmes ensemble.RemarqueCette approche constitue l’une des forces majeures d’XP, mais c’est aussi d’un certain point devue sa principale faiblesse. D’une part, ce besoin de communication est le principal facteurlimitatif au regard de la taille de l’équipe et, d’autre part, cela rend XP très sensible au type derelations humaines qui ont cours dans le projet : appliquer XP dans un projet marqué par desantagonismes internes forts, c’est courir à la catastrophe – mais on peut légitimement sedemander comment un tel projet peut bien réussir, indépendamment du processus adopté. Cependant, si l’accent est placé sur la communication directe, la communication écriten’est pas laissée de côté pour autant. Mais elle apparaît sous une forme différente : toutes lesinformations ayant trait à l’implémentation et la conception se retrouvent dans le code luimême – dont la clarté fait l’objet de nombreux efforts – et dans la batterie de tests quil’accompagne, et celles relatives aux besoins du client sont consignées d’une manière on nepeut plus formelle, sous la forme de tests de recette automatiques. Si le client souhaite obtenirdes documents supplémentaires, il lui suffit de définir et de planifier les tâchescorrespondantes comme pour tout autre besoin. 2) La simplicité comme garantie de productivité
  24. 24. Une personne qui arrive sur un projet XP ne doit pas s’étonner de s’entendre répéter lesquelques «mantras» suivants : «La chose la plus simple qui puisse marcher» (The simplestthing that could possibly work), «Tu n’en auras pas besoin» ( You ain’t gonna need it – etson acronyme YAGNI), ou encore «Une fois et une seule» (Once and only once). Tous troissont l’expression d’une même valeur : la simplicité. Cette simplicité touche d’abord à la réalisation même du logiciel, dans laquelle un soinparticulier est apporté au code pour le débarrasser de toute complexité superfiue. Enparticulier,les mécanismes de généricité – le «péché mignon» des développeurs – ne sontencouragés que lorsqu’ils servent un besoin concret et immédiat, et en aucun cas un besoinfutur plus ou moins imaginaire. Les développeurs sont donc invités à implémenter la chose laplus simple qui puisse marcher et, en ce qui concerne ces fameux mécanismes génériques, ouencore ces outils «magiques» qui en font plus que ce qu’on leur demande, ils n’auront pasbesoin! En revanche, simple ne veut pas dire simpliste : les solutions adoptées doivent êtreaussi simples que possible, mais toutes les duplications doivent être éliminées de sorte quechaque information, chaque mécanisme ne soit exprimé qu’une fois et une seule – ce principeest garant de la facilité de modification du code sur le long terme. Cet effort de simplicité s’applique également au client, à qui l’équipe demandera dedéfinir ses besoins et ses priorités avec une grande précision pour éviter d’implémenter deschoses inutiles et pour pouvoir se focaliser sur les besoins réellement importants. Lasimplicité est également recherchée dans le choix des outils (de programmation ou de gestionde projet) et dans la méthode de travail elle-même. En définitive, XP est fondé sur un pari : «faire simple un jour, avec la possibilité derevenir en arrière le lendemain si un besoin différent apparaît. Léventuel coût supplémentaireinduit sera, d’une part réduit parce que l’application est restée assez simple pour évoluerfacilement, et d’autre part sera bien peu de choses au regard des économies réalisées à ne pasfaire ce qui naurait servi à rien. » C’est au succès de ce pari qu’une équipe XP doit sa vitessede développement et son ouverture au changement. 3) Le feedback comme outil de réduction du risque Malgré ce que peuvent laisser supposer son nom et ses apparences immédiates, l’ExtremeProgramming est avant tout un processus de réduction du risque dans le projet. Le risque est
  25. 25. en effet soigneusement contrôlé à tous les niveaux, par la mise en place de boucles defeedback qui permettent à l’équipe de développement, comme à son client, de savoir à toutmoment dans quel état se trouve réellement le projet, et de pouvoir rectifier le tir au fur et àmesure pour mener le projet à son terme avec succès. L’exemple le plus saillant de ce principe concerne la pratique des livraisons fréquentes,qui donne à tous les intervenants du projet un feedback régulier sur l’état d’avancement duprojet et l’état réel du produit. Mais le feedback ne se borne pas à l’observation : la pratiquede la planification itérative permet de tirer parti des informations recueillies pour, à la fois,améliorer la planification elle-même et faire converger le produit vers une solution mieuxadaptée aux besoins réels du client. L’activité de programmation fait également l’objet de divers mécanismes de feedback,tout d’abord à travers les tests unitaires mis en place, qui donnent aux développeurs desindications immédiates sur le fonctionnement du code qu’ils écrivent. Le feedback estégalement intégré à l’activité de conception, qui est menée tout au long de la réalisation pours’appuyer sur l’état réel de l’application plutôt que sur l’idée que l’on pourrait en avoir apriori. Enfin,les développeurs s’appuient en permanence sur le feedback de leur binôme pours’assurer de la validité et de la qualité du code qu’ils produisent. Ce feedback permanent est un facteur de qualité, puisque les intervenants du projetaméliorent sans cesse leur travail à partir de l’expérience qu’ils accumulent. Mais c’estégalement un facteur de vitesse : une équipe XP peut programmer vite, tout en restant sereineparce qu’elle sait qu’elle dispose de nombreux mécanismes pour s’assurer que le projet restesur la bonne voie. 4) Le courage de prendre les bonnes décisions L’expérience fait apparaître que la mise en œuvre des pratiques XP requiert une certainedose de cran. En effet, il faut du courage pour se lancer dans un projet sans avoir au préalabletout spécifié et conçu dans le détail, même si l’on sait que le processus suivi comporte denombreux mécanismes de feedback. Il faut également du courage pour se borner à réaliser des choses simples, se focaliseruniquement sur les besoins du moment en se disant qu’on pourra adapter l’application à de
  26. 26. nouveaux besoins, le moment venu. Il en faut aussi pour accepter de jeter une partie du codequi est devenue inutile, ou récrire une partie de code jugée trop complexe. Enfin, il faut du courage pour appliquer les principes de communication et de feedback, enparticulier lorsqu’il s’agit de maintenir une transparence complète, même lorsque lesnouvelles ne sont pas bonnes, ou encore lorsqu’il s’agit de travailler ouvertement avec sonbinôme en acceptant de lui montrer nos propres limites ou lacunes. Plus généralement, nous avons pu constater qu’il faut du courage pour mettre en place desméthodes nouvelles sur des projets dont les enjeux sont toujours stratégiques. s yW hDUML est un langage graphique de modélisation des besoins des utilisateurs, des conceptsmétier, des concepts techniques dans le cadre d’un développement informatique. UML estgénéralement associé à une méthodologie globale de gestion de projets fondée, si possible, surles grandes activités : spécification, analyse, conception et développement, éventuellementitérative comme par exemple l’eXtreme Programming, selon les besoins et la maturité deséquipes. UML peut aussi aider à organiser le travail des équipes. Points forts Points faibles - XP nest pas adapté pour les équipes - Simplicité de la mis en œuvre de développement de plus de dix - Adapté aux changements personnes - Favorise la communication entre - Un client doit être disponible à temps développeurs et développeur/client complet pour répondre aux questions des développeurs
  27. 27. • Le client étant présent dans l’équipe, l’importance des documents liés au projet est réduite. • Grande satisfaction du client et efficacité plus importante. • Le code source est la principale production du projet. • Le programmeur est un acteur essentiel, il accède à une certaine reconnaissance et il n’est pas seulement un simple exécutant. • Présence d’un coach potentiel afin de former une équipe capable de travailler. • Hiérarchie consentante. • Culture d’entreprise adaptée, pas de mérite basé sur les heures supplémentaires et pas d’attachement aux méthodes linéaires et aux tonnes de documents comme reflet de la qualité. / • Méthodologie déroutante. • Trop d’anarchie. • Pas assez de documentation. • Concerne les petits et moyens projets seulement. • Elle nécessite une forte implication du client. • KEh^/KE L’eXtreme Programming, ou XP, est basé sur des principes très simples, mais souventignorés par lindustrie. Une des idées révolutionnaires est que le coût du changement nest pasvariable mais plutôt constant; XP accepte donc le changement comme une réalité et lintègredans le processus de développement. Aussi, la programmation en paire, où deuxprogrammeurs travaillent ensemble sur le même ordinateur, permet daugmenter la qualité àdes niveaux encore jamais vus. Une autre idée consiste à mettre lemphase sur lacommunication constante entre léquipe de développement et le client, par le biais de bouclesrapides développement-test-feedback. Certaines de ces idées ne sont pas nouvelles, mais ellessont assemblées dans XP pour former une méthodologie efficace et qui présente des résultatsconcrets, plutôt que des résultats sur papier.