Processus de dveloppement

LExtreme Programming

Rgis Medina

01/2003

LExtreme Programming

TABLE DES MATIRES

Introduction _____________________________________________________________________ 3 Pourquoi une nouvelle mthode ? ____________________________________________________ 5 Les valeurs d'XP __________________________________________________________________ 6 Les pratiques XP __________________________________________________________________ 7 Gestion des livraisons ___________________________________________________________ 8 L'quipe fournit des livraisons frquentes ___________________________________________ 8 Les dveloppeurs estiment, le client choisit _________________________________________ 8 Gestion des itrations __________________________________________________________ Le logiciel est ralis en une suite de petites itrations ________________________________ L'quipe dtermine et se rpartit les tches raliser _________________________________ A la fin de l'itration, on recommence !____________________________________________ Qualit du design et du code _____________________________________________________ La conception reste la plus simple possible_________________________________________ Le code est remani en permanence ______________________________________________ Chaque classe est crite avec les tests unitaires associs_______________________________ Travail en quipe ______________________________________________________________ Le code est partag par toute l'quipe _____________________________________________ Les dveloppeurs travaillent en binmes___________________________________________ Les dveloppeurs respectent les rgles de codage de l'quipe___________________________ L'intgration se fait de manire quasi-continue ______________________________________ L'quipe adopte un rythme durable _______________________________________________ 10 10 10 11 12 13 13 13 14 14 15 15 16 16

Suivi du projet ________________________________________________________________ 12

Conditions d'utilisation dXP _______________________________________________________ 17 Le client doit tre intgr au projet _______________________________________________ 17 Le logiciel doit rester toujours simple, facilement modifiable et largement test __________ 17 L'quipe doit travailler... en quipe _______________________________________________ 17 Tous les participants doivent tre prts au changement ______________________________ 18 Conclusion _____________________________________________________________________ 19

http://www.design-up.com

2000 Regis Medina

2/19

LExtreme Programming

INTRODUCTION
L'Extreme Programming (XP) est une mthode de dveloppement ddie de petites quipes confrontes un environnement changeant ou des besoins mal connus. Cette mthode est ne sur le terrain, partir des observations et recherches de dveloppeurs expriments soucieux de se concentrer sur les ncessits lmentaires du dveloppement : Dvelopper vite : s'assurer que les changements restent toujours faciles pour conserver une vitesse de dveloppement soutenue tout au long du projet. Dvelopper juste : liminer tout travail inutile en se focalisant sur les besoins rels du client.

La mise au point de XP dure depuis quelques annes, mais XP a rellement dmarr en octobre 1999 avec la parution du livre :

Extreme Programming Explained : Embrace Change, Kent Beck, Addison-Wesley, 1999.

D'autres livres consacrs XP sont parus depuis, dont un en Franais cette anne :

LExtreme Programming (avec deux tudes de cas), Jean-Louis Bnard, Laurent Bossavit, Rgis Medina, Dominic Williams, Eyrolles, 2002.

Par ailleurs, le phnomne continue prendre de l'ampleur : Cre en janvier 2000, la mailing list spcialise compte en janvier 2003 prs de 3800 abonns. XP est dfendu par de grands noms du dveloppement objet, en particulier Kent Beck, Martin Fowler et Robert C. Martin. XP est dj mis en oeuvre dans des domaines aussi varis que la banque (Bayerische Landesbank, Credit Swiss Life, First Union National Bank), l'industrie automobile (DaimlerChrysler, Ford Motor Company), le transport (CSEE Transport), les tlcoms (Nortel), le commerce lectronique (Evant).

http://www.design-up.com

2000 Regis Medina

3/19

LExtreme Programming

Nous vous invitons ici dcouvrir XP travers : Une brve introduction : Pourquoi XP ? Une description des principes XP, Une description plus complte des pratiques XP, Une discussion des conditions de succs de XP dans un projet.

Bien sr, la prsentation qui suit reste reste extrmement synthtique. Il va de soi que la lecture de quelques ouvrages et l'exploration des sites lists dans notre rubrique Ressources demeure indispensable pour qui souhaite rellement comprendre XP et le mettre en oeuvre.

http://www.design-up.com

2000 Regis Medina

4/19

LExtreme Programming

POURQUOI UNE NOUVELLE MTHODE ?

Les approches classiques de dveloppement type "waterfall", bases sur la fameuse squence spcification / conception / ralisation / validation, souffrent de problmes chroniques : Les spcifications sont dfinies au dbut du projet, alors qu'on en sait encore peu sur le sujet, Les spcifications diffrencient rarement ce qui est important de ce qui ne l'est pas, L'application se rigidifie progressivement en un produit "final" souvent difficile faire voluer et maintenir, Les activits sont compartimentes en fonction des spcialits des dveloppeurs, ce qui pose des problmes de rpartition des tches et limite la circulation des connaissances dans l'quipe.

Ces approches sont fondes sur l'ide que le cot de modification du logiciel augmente de manire exponentielle dans le temps. Dans une telle logique, il est d'ailleurs normal de chercher dfinir compltement le produit avant de procder sa ralisation. Or, ce qu'ont dcouvert les crateurs de XP, c'est que certaines pratiques de dveloppement permettent de rduire de manire significative le cot de changement du logiciel, tel point qu'il devient plus rentable de prendre les dcisions le plus tard possible, en s'appuyant sur l'exprience acquise au cours du dveloppement lui-mme. Il en rsulte une approche radicalement diffrente du dveloppement, fonde sur une ouverture permanente au changement : Les spcifications sont dfinies au dbut du projet, puis revues, affines et compltes tout au long du dveloppement, Le client arbitre en permanence les priorits pour que l'quipe se focalise d'abord sur les tches les plus importantes, L'application est maintenue simple et volutive travers un ensemble de pratiques de programmation strictes, Les dveloppeurs travaillent toujours ensemble, ce qui favorise le transfert de connaissances, amliore la qualit du produit et rend le travail nettement plus motivant.

http://www.design-up.com

2000 Regis Medina

5/19

LExtreme Programming

LES VALEURS D'XP

XP dfend une approche humaniste et dynamique du dveloppement, fonde sur les valeurs suivantes : Communication o o o XP intgre rellement le client au projet pour qu'il dfinisse mieux ses besoins, arbitre les priorits et apporte ses connaissances mtier l'quipe. XP fait travailler tous les dveloppeurs ensemble et les fait participer toutes les activits du dveloppement, crant ainsi une relle dynamique d'quipe. XP rend accessible tous les intervenants l'ensemble des indicateurs d'avancement du projet. XP fournit des livraisons rgulires au client pour lui permettre d'affiner et de complter la dfinition de ses besoins partir de donnes concrtes. XP met en place des batteries de tests d'acceptation qui mesurent concrtement l'avancement des dveloppements. XP met en place des batteries de tests unitaires qui indiquent rapidement si le code fonctionne et qui dtectent instantanment toute rgression. XP s'assure que seules les fonctionnalits demandes par le client sont implmentes. XP maintient un design et un code toujours aussi simples que possible pour rester ouvert au changement et conserver une grande vitesse de dveloppement tout au long du projet. XP donne au jour le jour une transparence maximale sur l'tat d'avancement rel du projet. XP s'attaque aux problmes ds qu'ils se prsentent, en autorisant des retours en arrire s'ils sont ncessaires.

Feedback o o o

Simplicit o o

Courage o o

Les pages suivantes montrent comment XP supporte ces valeurs travers un ensemble de pratiques prcises et concrtes.

http://www.design-up.com

2000 Regis Medina

6/19

LExtreme Programming

LES PRATIQUES XP
Les pratiques XP sont pour la plupart des pratiques de "bon sens" utilises par des dveloppeurs et des chefs de projets expriments. On retrouve par exemple les tests unitaires, les relectures de code, les livraisons frquentes, une communication accrue avec le client, les "nettoyages" frquents du code, etc. La premire nouveaut d'XP consiste pousser ces pratiques l'extrme, ou comme le disent ses auteurs "tourner tous les boutons jusqu' 10 !" : des tests unitaires sont crits pour chaque classe, la relecture du code est faite au moment mme de son criture par un travail en binme permanent, l'intgration est faite chaque jour, etc. La seconde nouveaut de XP consiste organiser ces pratiques en un tout cohrent, de sorte que chaque pratique renforce les autres. Il en rsulte une mthode complte qui couvre tous les aspects du dveloppement, de la relation avec le client jusqu' l'criture du code en passant par les plannings et l'organisation de l'quipe. Voici les principaux lments du fonctionnement de XP : Gestion des livraisons : L'quipe fournit des livraisons frquentes au client. Le contenu de ces livraisons est dcid par le client lui-mme, partir des estimations fournies par les dveloppeurs. Gestion des itrations : Les livraisons sont ralises en une suite d'itrations de 2 semaines environ, au sein desquelles le projet est gr un niveau de dtail plus fin. Suivi du projet : L'avancement du projet est mesur de manire concrte par une batterie de tests de recette automatiques. Le rythme de progression est rvalu chaque itration, et le plan de dveloppement lui-mme est revu frquemment pour tirer parti de l'exprience acquise au cours du projet. Qualit du design et du code : Des pratiques strictes permettent de garder une vitesse de dveloppement leve tout au long du projet, tout en gardant une ouverture maximale au changement. La conception reste toujours le plus simple possible, le code est nettoy en permanence et des tests unitaires de non-rgression sont crits pour chaque classe. Travail en quipe : L'quipe travaille rellement... en quipe. Le code est partag par tous, les dveloppeurs travaillent systmatiquement en binmes, et l'intgration est quasiment continue.

Les pages qui suivent dcrivent ces pratiques plus en dtail. Il va de soi cependant que cette description reste synthtique, donc superficielle, et que l'tude des ressources cites dans notre section Liens est indispensable pour qui souhaite mettre la mthode en pratique.

http://www.design-up.com

2000 Regis Medina

7/19

LExtreme Programming

Gestion des livraisons

L'quipe fournit des livraisons frquentes Au dbut du projet, le client et le chef de projet se mettent d'accord sur un rythme de livraison rgulier (typiquement tous les 1 ou 2 mois, pour un projet qui s'tale sur plus de 6 mois). Pourquoi des dates fixes ? XP dfinit quatre variables partir desquelles il est possible de grer un projet : les dates, les ressources, la qualit et le contenu. Or de ces quatre variables, XP considre que le chef de projet ne peut rellement grer que la dernire puisque : les dates de livraison sont souvent dictes par des contraintes ou des opportunits externes au projet, les ressources sont souvent values par la direction et dcides avant le dmarrage du projet, la qualit doit toujours tre maximale.

XP axe donc les efforts de pilotage du projet sur la gestion du contenu, le but tant bien sr d'apporter la plus grande valeur ajoute possible au client chaque livraison. Les dveloppeurs estiment, le client choisit Chaque livraison suit le cycle suivant :

Les trois premires tapes de ce cycle prennent place au cours de "sances de planification de livraisons", dont le but est de dterminer le contenu des livraisons venir. Ces sances runissent le client et les dveloppeurs, l'ensemble tant coordonn et arbitr par le chef de projet (ou coach, dans le vocabulaire XP).
1. Le client dcrit ses besoins sous forme de "scnarios client"

Le client dfinit ses besoins sous la forme de "scnarios client" simples, dcrivant en quelques mots chaque fonctionnalit souhaite du logiciel. Par exemple, pour un logiciel de gestion de carnet d'adresses on pourrait crire les scnarios suivants : http://www.design-up.com
2000 Regis Medina

8/19

LExtreme Programming

"Je rentre un nom ou prnom, et le logiciel affiche la liste de toutes les personnes qui possdent ce nom ou ce prnom", "Je peux enregistrer mon carnet d'adresses au format HTML.", etc.

Les scnarios sont crits dans le langage du client, et dcrivent des fonctionnalits dont l'implmentation parat suffisamment courte (une ou deux semaines maximum). Les scnarios sont nots sur des fiches cartonnes, pour tre facilement manipuls (partags, changs, dchirs, tris...). Si un scnario parat trop vague ou trop complexe, il est dcompos en scnarios plus simples. Un projet complet peut compter une centaine de scnarios ou davantage.
2. Les dveloppeurs estiment le cot d'implmentation de chaque scnario

Les estimations ne se font pas en jours rels mais en units abstraites, dont la dfinition exacte a finalement peu d'importance. Certaines quipes prfreront parler de temps idal (journes de 8 heures de programmation sans interruption), d'autres parleront de points, de "XP units" ou encore de "Gummy Bears"... L'important ce stade est de disposer d'une unit qui permette d'valuer les dures relatives d'implmentation des scnarios sans donner aux dveloppeurs le sentiment de s'engager sur des dures relles. Les estimations sont faites par l'ensemble de l'quipe, le client tant prsent pour rpondre questions que les dveloppeurs peuvent se poser sur chaque scnario. Au besoin, dveloppeurs peuvent procder quelques exprimentations sur machine pour se faire meilleure ide des difficults techniques rencontres. XP nomme ces exprimentations "spike solutions". Au terme de cette phase, chaque fiche de scnario client possde une indication de cot.
3. Le client slectionne les scnarios implmenter pour la livraison suivante

aux les une des

Tous les scnarios tant dcrits et valus, le client procde au choix des scnarios implmenter pour la prochaine livraison. Cependant, du fait que le cot de chaque scnario n'est connu qu'en nombre de "points" abstraits, il faut un moyen pour calculer combien l'quipe pourra traiter de scnarios. Comme nous allons le voir, chaque livraison est prpare en une suite d'itrations, qui durent chacune 2 semaines environ. XP dfinit la notion de vlocit, qui correspond au nombre de points que l'quipe peut traiter en une itration. Cette vlocit est tout d'abord estime par le chef de projet, puis recalcule chaque itration en faisant simplement la somme des points des scnarios qui ont t complts l'itration prcdente. Remarque: Cette vlocit ne reprsente en aucun cas le niveau de "performance" de l'quipe, dans la mesure o elle dpend en grande partie de la faon dont les dveloppeurs font leurs estimations. Cependant, ses variations peuvent indiquer des problmes passagers : si la vlocit baisse brutalement, c'est peut-tre que l'quipe a t ralentie pour une raison ou une autre, et il ne faut pas ignorer cette information. Connaissant le nombre d'itrations jusqu' la prochaine livraison, on est donc capables de dterminer combien l'quipe peut traiter de "points" pour cette livraison. Le client dispose de ce nombre de points pour "acheter" les scnarios implmenter pour cette livraison, et http://www.design-up.com
2000 Regis Medina

9/19

LExtreme Programming

ventuellement les livraisons suivantes. A lui donc de rpartir les scnarios comme il le souhaite dans les livraisons venir pour obtenir la plus grande valeur ajoute au plus tt.
4. Les dveloppeurs implmentent les scnarios choisis

L'implmentation proprement dite se fait en une suite d'itrations, dcrites plus en dtail dans la section suivante. Une fois la livraison effectue, on passe la suivante en rptant le mme cycle : Le client reprend les scnarios restants. Il peut en ajouter, en retirer ou en modifier son gr. Les dveloppeurs restiment les dures de tous les scnarios en se basant sur une meilleure connaissance du contexte technique et fonctionnel, Le client slectionne les scnarios implmenter, Les dveloppeurs implmentent les scnarios, etc.

Ce cycle continue tant que le client souhaite investir dans le projet !

Gestion des itrations

Le logiciel est ralis en une suite de petites itrations Ces itrations durent 2 semaines environ. Si la gestion des livraisons est axe sur la dtermination des estimations et du contenu, celle des itrations est axe sur la dtermination des tches accomplir, la rpartition de ces tches parmi les dveloppeurs et le suivi de la ralisation. L'quipe dtermine et se rpartit les tches raliser Les premiers jours de chaque itration sont ddies la dtermination et l'attribution des tches, sous la forme d'une sance collective de planification d'itration qui runit le client et les dveloppeurs. Le client commence par dterminer les scnarios qu'il souhaite voir raliss au cours de cette itration. Ensuite, les dveloppeurs tudient ces scnarios un par un pour en dduire les tches raliser et se les rpartir entre eux :

http://www.design-up.com

2000 Regis Medina

10/19

LExtreme Programming

1. Les dveloppeurs dterminent la liste des tches raliser

Les dveloppeurs prennent un un les scnarios raliser pour cette itration, et dterminent les tches concrtes qui serviront leur implmentation. Cette activit est mene en groupe, et le client est prsent pour dcrire plus prcisment les scnarios et rpondre toutes les questions d'ordre fonctionnel. Cette activit fait dj intervenir des lments de conception, puisque les tches concernent l'implmentation proprement dite. S'ils le souhaitent, les dveloppeurs peuvent exprimenter quelques "spike solutions" pour se faire une meilleure ide de la difficult de certaines tches. Comme les scnarios, les tches sont notes sur des fiches cartonnes pour tre facilement manipules. A la fin de cette phase, les dveloppeurs disposent d'une liste de tches raliser pour l'itration en cours. Il reste les rpartir entre eux.
2. Les dveloppeurs choisissent les tches qu'ils vont implmenter et valuent leur dure

L'quipe reprend la liste des tches raliser, et les dveloppeurs se les rpartissent progressivement. Chaque fois qu'un dveloppeur s'approprie une tche, il en value lui-mme la dure (en jours cette fois) et s'assure qu'il ne prend pas plus de tches qu'il ne pourra en raliser au cours de l'itration. D'une manire gnrale, les tches d'un mme scnario sont prises en charge par un mme dveloppeur, de sorte que le suivi du scnario soit correctement assur. Les tches ne sont pas affectes arbitrairement par spcialit technique : un dveloppeur peut prendre en charge une tche correspondant une technique qu'il connat peu, sachant que les implmentations se font toujours en binme et qu'il pourra donc s'associer un spcialiste de la technique en question au moment voulu (voir la section "Travail en quipe"). A la fin de cette phase, chaque dveloppeur connat la liste des tches qu'il doit raliser au cours de cette itration. A la fin de l'itration, on recommence ! Une fois l'ensemble des tches ralis, on passe l'itration suivante en reprenant le mme cycle : http://www.design-up.com
2000 Regis Medina

11/19

LExtreme Programming

Le client choisit les scnarios raliser, L'quipe dtermine la liste des tches accomplir pour l'itration, Les dveloppeurs se rpartissent les tches et valuent leurs cots, Les dveloppeurs ralisent les tches, etc.

Suivi du projet
Pour chaque scnario planifi, un ensemble de tests de recette est crit. Ces tests ont pour but de vrifier de manire automatique chacune des fonctionnalits demandes par le client. Le client (ou l'un de ses reprsentants) dfinit ces tests et participe ventuellement leur implmentation, aid de testeurs. L'volution de ces tests forme un indicateur concret de l'avancement des dveloppements : Le nombre de tests crits indique l'avancement des spcifications, Le nombre de tests valids indique l'avancement des dveloppements, Le nombre de tests en chec indique le degr de qualit du logiciel.

Le chef de projet peut ainsi reprsenter de manire trs synthtique l'volution du projet :

Les tests de recette sont lancs frquemment, et tous les participants du projet (client, direction, dveloppeurs) sont informs en permanence de leurs rsultats.

Qualit du design et du code

Rappelons ici que XP repose sur une rduction significative du cot du changement du logiciel. Cette rduction n'est pas le fruit du hasard, elle est le rsultat de l'application l'extrme des pratiques suivantes :

http://www.design-up.com

2000 Regis Medina

12/19

LExtreme Programming

La conception reste la plus simple possible "You ain't gonna need it!" : on ne fait de conception que pour les fonctionnalits existantes, pas pour les fonctionnalits futures. En corollaire : on ne fait de gnralisations dans le design que lorsque les exemples concrets se prsentent. on n'introduit pas d'optimisations si elles ne sont pas demandes par le client.

En somme, plutt que de prparer le logiciel pour le futur, XP s'assure que le travail actuel soit toujours bien fait (lisibilit du code, simplicit, tests) pour que les changements restent faciles et rapides. Le code est remani en permanence L'application est toujours maintenue aussi mallable que possible grce une activit permanente de remaniement (refactoring). Les remaniements consistent par exemple renommer les variables, les mthodes, les classes, dplacer des attributs ou des mthodes vers d'autres classes, dcomposer les grosses mthodes en des mthodes plus petites, factoriser des parties de code, etc. L'une des motivations principales de remaniement est l'absence de duplications dans le code (tout doit apparatre "Once and Only Once"). Lorsqu'un dveloppeur doit utiliser une partie de code qui se trouve dj quelque part dans l'application, il remanie l'application de manire pouvoir utiliser le code existant. De la sorte les modifications de l'application n'impactent gnralement que peu d'endroits dans le code, ce qui est primordial pour que celui-ci reste mallable. Le remaniement est galement utilis pour rendre le code plus clair : lorsqu'un dveloppeur doit comprendre une nouvelle partie du code, il la modifie afin de la rendre plus claire pour ceux qui passeront aprs lui. Une phase de remaniement prcde gnralement l'ajout de toute nouvelle fonctionnalit, de manire ce que le nouveau code s'insre aussi naturellement que possible dans l'application. Le remaniement est plus qu'un moyen de dpoussirer le code : c'est un moyen de faire merger un design aussi adapt que possible aux besoins de l'application, en supprimant au fur et mesure tout ce qui nuit sa simplicit. Chaque classe est crite avec les tests unitaires associs En plus des tests de recette, qui servent prouver que le logiciel remplit ses objectifs, XP utilise intensivement les tests unitaires de non-rgression. Ces tests sont crits par les dveloppeurs en mme temps que le code lui-mme, pour valider chaque portion de code susceptible de comporter des erreurs. Les tests doivent s'excuter sans aucune interprtation de la part du dveloppeur : ils comportent des assertions qui vrifient automatiquement si le code test fonctionne ou non. Quasiment chaque classe de l'application possde une classe "jumelle" de test. Lorsque des dveloppeurs doivent ajouter une nouvelle mthode la classe applicative, ils commencent par ajouter la classe de test un ensemble d'assertions qui dcrivent le comportement de la mthode ajouter. La mthode n'est implmente qu'ensuite, pour que ces tests passent. Bien sr, on ne http://www.design-up.com
2000 Regis Medina

13/19

LExtreme Programming

teste pas toutes les mthodes de l'application. Avec un peu de pratique, il devient facile de savoir ce qui mrite d'tre test, la rgle de base tant qu'on ne teste que ce qui peut casser ("Test everything that could possibly break"). Les classes de tests ne sont bien sr pas jetes aprs usage : elles sont gres par un framework ddi, qui permet de les excuter en groupe ou de manire globale. La batterie de tests de l'application ne cesse donc de s'enrichir, et forme avec le temps un filet de scurit qui permet aux dveloppeurs de garder une grande vitesse de dveloppement sans crainte de rgressions. Ces tests sont ainsi lancs en permanence par les dveloppeurs - en fait, chaque compilation. Tous les tests unitaires doivent passer 100% avant tout report de modifications dans la version d'intgration du logiciel. Cette pratique constitue l'une des pratiques centrales de XP. Ses avantages sont tels que chaque projet, XP ou non, se doit de s'y pencher avec la plus grande attention : Les erreurs sont trs vite dtectes et trs vite localises. Les tests donnent une vision prcise de la tche raliser et aident les dveloppeurs aller droit au but. Les tests placent les dveloppeurs dans un contexte rduit qui leur permet de s'abstraire de la complexit du reste de l'application. Il est possible de s'assurer du fonctionnement global du systme trs rapidement, aprs toute modification du code, avant ou aprs toute intgration dans la version officielle du systme.

Ce que l'on constate au final, c'est que les dveloppeurs qui utilisent les tests unitaires passent plus de temps ecrire du nouveau code, et moins de temps chercher des "bugs" dans du code existant.

Travail en quipe
Lorsque le client a slectionn les scnarios implmenter, les dveloppeurs dcident en groupe de l'affectation des scnarios. Le code est partag par toute l'quipe L'application n'est pas dcoupe en zones rserves chaque dveloppeur : chacun est susceptible de travailler sur toutes les parties de l'application. Chacun a donc la responsabilit d'crire un code aussi clair que possible, sachant que d'autres y travailleront peu aprs. D'autre part le fait qu'une mme portion de code soit visite par plusieurs dveloppeurs diminue les risques d'erreur et augmente sa qualit. Cette pratique va l'encontre du dcoupage classique du travail en domaines techniques (IHM, bases de donnes, etc.). XP exploite les spcialistes, mais en tant que consultants internes et non comme travailleurs spcialiss.

http://www.design-up.com

2000 Regis Medina

14/19

LExtreme Programming

Les dveloppeurs travaillent en binmes Chaque dveloppeur est responsable d'une tche qui lui est propre, mais il doit systmatiquement demander l'aide d'autres dveloppeurs pour la raliser. Le dveloppeur va s'associer : Un dveloppeur ayant des connaissances spcifiques pour la tche en cours. Un dveloppeur plus jeune, pour lui transmettre ses connaissances. Plus gnralement, un dveloppeur intress par la tche.

Le binme travaille sur une seule machine : le dveloppeur qui est aux commandes se concentre plutt sur l'criture du code, l'autre travaille davantage au niveau de la conception ou de la fonctionnalit en cours. En termes militaires, celui qui est au clavier travaille au niveau tactique, et l'autre au niveau stratgique - mais cette rpartition n'a rien de strict : les dveloppeurs s'organisent comme ils le souhaitent pour mener bien la tche en cours. Les binmes changent frquemment, de sorte que chacun est amen travailler avec tous les autres membres de l'quipe. Cette approche peut paratre coteuse au premier abord, mais elle s'avre parfaitement rentable en pratique grce : Une plus grande qualit du design et du code qui limite les retours en arrire et les longues phases de debug. Une concentration accrue des dveloppeurs. Une plus grande vitesse de dveloppement (aprs tout l'criture du code ne reprsente en soi qu'une petite fraction du travail). Une meilleure diffusion de la connaissance dans l'quipe, avec notamment une formation acclre des dbutants.

Les dveloppeurs respectent les rgles de codage de l'quipe Ces rgles sont dfinies par l'ensemble des dveloppeurs. Elles donnent au code un aspect uniforme sur toute l'application, ce qui facilite le partage du code et le travail en binmes. L'homognisation du code ne se limite pas seulement sa prsentation et au respect de rgles de programmation. L'quipe s'appuie en effet sur un systme de mtaphores commun, c'est dire un ensemble d'expressions dcrivant les acteurs du systme et leurs interactions. Ce systme de mtaphores constitue : Un vocabulaire commun qui va permettre toute l'quipe de parler des mmes choses avec les mmes mots. Par exemple, dans le monde des tlcom, il faut dfinir ce qu'est un "noeud" d'un rseau et se servir de ce mot dans le cadre de la dfinition tablie. Une mtaphore de fonctionnement, par exemple : "le logiciel de contrle de cette machine-outil fonctionne comme une machine caf". Il faut bien sr veiller ce que la mtaphore ne devienne pas une simplification abusive du concept initial ! Une source d'inspiration pour la conception d'autres lments fondamentaux d'un projet tels que: o Les structures de donnes utiles au logiciel,
2000 Regis Medina

http://www.design-up.com

15/19

LExtreme Programming

Les mthodes d'accs efficaces ces donnes.

L'intgration se fait de manire quasi-continue L'intgration est faite tous les jours. Ds qu'un dveloppeur finit une tche, il met jour la version d'intgration en s'assurant que tous les tests de non-rgression de l'application passent 100%. La version "livrable" du logiciel volue donc chaque jour, en refltant fidlement l'tat d'avancement des dveloppements. L'quipe adopte un rythme durable D'une part, une quipe fatigue ne fait pas du bon travail. D'autre part, s'il y a trop de retard, c'est qu'il y a un problme de fond et il est illusoire de chercher le camoufler par davantage de travail. Pour ces raisons, l'quipe adopte la rgle suivante : pas d'heures supplmentaires deux semaines de suite.

http://www.design-up.com

2000 Regis Medina

16/19

LExtreme Programming

CONDITIONS D'UTILISATION DXP

XP a fait ses preuves pour des quipes de moins de 10 dveloppeurs ralisant un produit sur mesure pour un client suffisamment accessible. Cependant, du fait que la mthode se montre efficace dans les situations o il est difficile d'tablir des spcifications claires et stables au dbut du projet, diverses entreprises tudient la possibilit d'appliquer XP des contextes diffrents. Les deux points suivants font en particulier l'objet de beaucoup de questions : Comment appliquer XP lorsque le client n'est pas accessible ? Le client peut tre remplac par un reprsentant spcialiste du domaine fonctionnel, mais il est important que celui-ci ait des contacts frquents avec le client final pour s'assurer de l'adquation relle du produit ses besoins. Comment appliquer XP dans des projets de taille importante ? Dans la plupart des cas, ces projets seront dcomposs en quipes de taille adapte. Il reste cependant dterminer comment organiser ces quipes entre elles, mais XP ne propose aujourd'hui rien de prcis dans ce sens.

Dans tous les cas, la mthode doit tre adapte par chaque quipe son contexte particulier. Il est important cependant de respecter un certain nombre de conditions pour bnficier rellement des apports de la mthode et mriter le "label XP" ;-)

Le client doit tre intgr au projet

Le client (ou au moins un reprsentant du domaine fonctionnel) doit tre disponible pour participer la dfinition des scnarios, arbitrer les priorits, apporter ses connaissances mtier et dfinir les tests de recette. Le client doit faire suffisamment confiance l'quipe de dveloppement pour ne pas lui imposer un rsultat priori (il obtient en retour l'opportunit de contrler le produit de manire beaucoup plus fine que par le pass).

Le logiciel doit rester toujours simple, facilement modifiable et largement test

Les dveloppeurs doivent avoir la comptence ncessaire pour raliser des applications rellement simples et volutives. Ils ne doivent galement pas tre trop limits par des problmes de compatibilit ascendante qui limiteraient trop fortement les possibilits de remaniement. Les tests unitaires sont galement un facteur important du succs de la mthode. Ils doivent tre crits en mme temps que le code lui-mme, et l'ensemble de ces tests doit passer 100% en permanence sur la version d'intgration du produit.

L'quipe doit travailler... en quipe

XP exige une forte cohsion au sein de l'quipe. Cette cohsion ne peut tre impose, elle doit tre le rsultat des choix faits lors de la constitution de l'quipe. Ce point est suffisamment important pour pouvoir ncessiter le remplacement d'un membre de l'quipe en cours de projet.

http://www.design-up.com

2000 Regis Medina

17/19

LExtreme Programming

D'autre part , les dveloppeurs doivent avoir la capacit et la volont de participer toutes les activits du dveloppement : contact avec le client, valuation des cots, design et codage, test, etc. Dans un tel contexte, il est important que le chef de projet soit prt laisser une autonomie assez importante l'quipe elle-mme, pour se concentrer sur la coordination de l'ensemble.

Tous les participants doivent tre prts au changement

Finalement, le plus gros obstacle la russite de XP reste la rsistance au changement, qu'elle vienne des dveloppeurs ou du client. XP apporte un profond changement dans l'approche des projets de dveloppement, et le changement de mthodes de travail (quelles qu'elles soient) reste toujours une entreprise difficile.

http://www.design-up.com

2000 Regis Medina

18/19

LExtreme Programming

CONCLUSION
Au final, on peut se demander si la mthode porte bien son nom. Le terme "extrme" voque des prises de risques insenses, alors qu'en pratique XP vise une suppression systmatique du risque. En effet, une quipe XP : s'assure en permanence qu'elle se concentre sur les besoins rels du client, dveloppe le plus important en premier, ce qui limite au maximum l'impact d'un retard eventuel, fournit une grande visibilit sur l'avancement concret des dveloppements, utilise un filet (tests unitaires) pour tous ses developpements, pratique une relecture de code immdiate et continue, etc.

Malgr cela, de nombreuses quipes trouveront la mthode extrme dans la mesure o elle implique un changement profond des mentalits et des habitudes de travail. Mais si le changement est radical, rien ne dit qu'il doit tre brutal. Les auteurs de XP prconisent au contraire une adoption progressive de la mthode, en partant des pratiques de base telles que les tests unitaires ou le travail en binmes. Aprs avoir pris connaissance des grandes lignes de la mthode, une quipe souhaitant passer XP devra commencer par exprimenter progressivement ces pratiques, tout en approfondissant en parallle sa comprhension de la mthode. Notre section Ressources fournit cet effet les rfrences des principaux livres et sites web disponibles. Cependant, comme rien ne vaut le contact n'hsitez pas nous crire, soit contact@design-up.com soit sur notre mailing list design-up@egroups.com, nous serons ravis de parler XP avec vous !

http://www.design-up.com

2000 Regis Medina

19/19