L`Extreme Programming

Transcription

Processus de développement
L’Extreme Programming
Régis Medina
01/2003
TABLE DES MATIÈRES
Introduction _____________________________________________________________________ 3
Pourquoi une nouvelle méthode ? ____________________________________________________ 5
Les valeurs d'XP __________________________________________________________________ 6
Les pratiques XP __________________________________________________________________ 7
Gestion des livraisons ___________________________________________________________ 8
L'équipe fournit des livraisons fréquentes ___________________________________________ 8
Les développeurs estiment, le client choisit _________________________________________ 8
Gestion des itérations __________________________________________________________
Le logiciel est réalisé en une suite de petites itérations ________________________________
L'équipe détermine et se répartit les tâches à réaliser _________________________________
A la fin de l'itération, on recommence !____________________________________________
10
10
10
11
Suivi du projet ________________________________________________________________ 12
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 associés_______________________________
12
13
13
13
Travail en équipe ______________________________________________________________
Le code est partagé par toute l'équipe _____________________________________________
Les développeurs travaillent en binômes___________________________________________
Les développeurs respectent les règles de codage de l'équipe___________________________
L'intégration se fait de manière quasi-continue ______________________________________
L'équipe adopte un rythme durable _______________________________________________
14
14
15
15
16
16
Conditions d'utilisation d’XP _______________________________________________________ 17
Le client doit être intégré 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 prêts au changement ______________________________ 18
Conclusion _____________________________________________________________________ 19
http://www.design-up.com
© 2000 Regis Medina
2/19
INTRODUCTION
L'Extreme Programming (XP) est une méthode de développement dédiée à de petites équipes
confrontées à un environnement 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 concentrer sur les nécessités élémentaires du développement :
•
Développer vite : s'assurer que les changements restent toujours faciles pour conserver
une vitesse de développement soutenue tout au long du projet.
•
Développer juste : éliminer tout travail inutile en se focalisant sur les besoins réels du
client.
La mise au point de XP dure depuis quelques années, mais XP a réellement démarré en octobre
1999 avec la parution du livre :
Extreme Programming Explained : Embrace Change,
Kent Beck,
Addison-Wesley, 1999.
D'autres livres consacrés à XP sont parus depuis, dont un en Français cette année :
L’Extreme Programming (avec deux études de cas),
Jean-Louis Bénard, Laurent Bossavit,
Régis Medina, Dominic Williams,
Eyrolles, 2002.
Par ailleurs, le phénomène continue à prendre de l'ampleur :
•
Créée en janvier 2000, la mailing list spécialisée compte en janvier 2003 près de 3800
abonnés.
•
XP est défendu par de grands noms du développement objet, en particulier Kent Beck,
Martin Fowler et Robert C. Martin.
•
XP est déjà mis en oeuvre dans des domaines aussi variés que la banque (Bayerische
Landesbank, Credit Swiss Life, First Union National Bank), l'industrie automobile
(DaimlerChrysler, Ford Motor Company), le transport (CSEE Transport), les télécoms
(Nortel), le commerce électronique (Evant).
3/19
Nous vous invitons ici à découvrir XP à travers :
•
Une brève introduction : Pourquoi XP ?
•
Une description des principes XP,
•
Une description plus complète des pratiques XP,
•
Une discussion des conditions de succès de XP dans un projet.
Bien sûr, la présentation qui suit reste reste extrêmement synthétique. Il va de soi que la lecture
de quelques ouvrages et l'exploration des sites listés dans notre rubrique Ressources demeure
indispensable pour qui souhaite réellement comprendre XP et le mettre en oeuvre.
4/19
POURQUOI UNE NOUVELLE MÉTHODE ?
Les approches classiques de développement type "waterfall", basées sur la fameuse séquence
spécification / conception / réalisation / validation, souffrent de problèmes chroniques :
•
Les spécifications sont définies au début du projet, alors qu'on en sait encore peu sur le
sujet,
•
Les spécifications différencient 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 activités sont compartimentées en fonction des spécialités des développeurs, ce qui
pose des problèmes de répartition des tâches et limite la circulation des connaissances
dans l'équipe.
Ces approches sont fondées sur l'idée que le coût de modification du logiciel augmente de
manière exponentielle dans le temps. Dans une telle logique, il est d'ailleurs normal de chercher
à définir complètement le produit avant de procéder à sa réalisation.
Or, ce qu'ont découvert les créateurs de XP, c'est que certaines pratiques de développement
permettent de réduire de manière significative le coût de changement du logiciel, à tel point qu'il
devient plus rentable de prendre les décisions le plus tard possible, en s'appuyant sur
l'expérience acquise au cours du développement lui-même.
Il en résulte une approche radicalement différente du développement, fondée sur une ouverture
permanente au changement :
•
Les spécifications sont définies au début du projet, puis revues, affinées et complétées
tout au long du développement,
•
Le client arbitre en permanence les priorités pour que l'équipe se focalise d'abord sur les
tâches les plus importantes,
•
L'application est maintenue simple et évolutive à travers un ensemble de pratiques de
programmation strictes,
•
Les développeurs travaillent toujours ensemble, ce qui favorise le transfert de
connaissances, améliore la qualité du produit et rend le travail nettement plus motivant.
5/19
LES VALEURS D'XP
XP défend une approche humaniste et dynamique du développement, fondée sur les valeurs
suivantes :
•
•
•
•
Communication
o
XP intègre réellement le client au projet pour qu'il définisse mieux ses besoins,
arbitre les priorités et apporte ses connaissances métier à l'équipe.
o
XP fait travailler tous les développeurs ensemble et les fait participer à toutes les
activités du développement, créant ainsi une réelle dynamique d'équipe.
o
XP rend accessible à tous les intervenants l'ensemble des indicateurs d'avancement
du projet.
Feedback
o
XP fournit des livraisons régulières au client pour lui permettre d'affiner et de
compléter la définition de ses besoins à partir de données concrètes.
o
XP met en place des batteries de tests d'acceptation qui mesurent concrètement
l'avancement des développements.
o
XP met en place des batteries de tests unitaires qui indiquent rapidement si le code
fonctionne et qui détectent instantanément toute régression.
Simplicité
o
XP s'assure que seules les fonctionnalités demandées par le client sont
implémentées.
o
XP maintient un design et un code toujours aussi simples que possible pour rester
ouvert au changement et conserver une grande vitesse de développement tout au
long du projet.
Courage
o
XP donne au jour le jour une transparence maximale sur l'état d'avancement réel du
projet.
o
XP s'attaque aux problèmes dès qu'ils se présentent, en autorisant des retours en
arrière s'ils sont nécessaires.
Les pages suivantes montrent comment XP supporte ces valeurs à travers un ensemble de
pratiques précises et concrètes.
6/19
LES PRATIQUES XP
Les pratiques XP sont pour la plupart des pratiques de "bon sens" utilisées par des développeurs
et des chefs de projets expérimentés. On retrouve par exemple les tests unitaires, les relectures
de code, les livraisons fréquentes, une communication accrue avec le client, les "nettoyages"
fréquents du code, etc.
La première nouveauté d'XP consiste à pousser ces pratiques à l'extrême, 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 même de son écriture par un travail en binôme
permanent, l'intégration est faite chaque jour, etc.
La seconde nouveauté de XP consiste à organiser ces pratiques en un tout cohérent, de sorte que
chaque pratique renforce les autres. Il en résulte une méthode complète qui couvre tous les
aspects du développement, 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 éléments du fonctionnement de XP :
•
Gestion des livraisons : L'équipe fournit des livraisons fréquentes au client. Le contenu
de ces livraisons est décidé par le client lui-même, à partir des estimations fournies par
les développeurs.
•
Gestion des itérations : Les livraisons sont réalisées en une suite d'itérations de 2
semaines environ, au sein desquelles le projet est géré à un niveau de détail plus fin.
•
Suivi du projet : L'avancement du projet est mesuré de manière concrète par une
batterie de tests de recette automatiques. Le rythme de progression est réévalué à
chaque itération, et le plan de développement lui-même est revu fréquemment pour tirer
parti de l'expérience acquise au cours du projet.
•
Qualité du design et du code : Des pratiques strictes permettent de garder une vitesse
de développement élevée 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-régression sont écrits pour
chaque classe.
•
Travail en équipe : L'équipe travaille réellement... en équipe. Le code est partagé par
tous, les développeurs travaillent systématiquement en binômes, et l'intégration est
quasiment continue.
Les pages qui suivent décrivent ces pratiques plus en détail. Il va de soi cependant que cette
description reste synthétique, donc superficielle, et que l'étude des ressources citées dans notre
section Liens est indispensable pour qui souhaite mettre la méthode en pratique.
7/19
Gestion des livraisons
L'équipe fournit des livraisons fréquentes
Au début du projet, le client et le chef de projet se mettent d'accord sur un rythme de livraison
régulier (typiquement tous les 1 ou 2 mois, pour un projet qui s'étale sur plus de 6 mois).
Pourquoi des dates fixes ?
XP définit quatre variables à partir desquelles il est possible de gérer un projet : les dates, les
ressources, la qualité et le contenu. Or de ces quatre variables, XP considère que le chef de
projet ne peut réellement gérer que la dernière puisque :
•
les dates de livraison sont souvent dictées par des contraintes ou des opportunités
externes au projet,
•
les ressources sont souvent évaluées par la direction et décidées avant le démarrage 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 sûr
d'apporter la plus grande valeur ajoutée possible au client à chaque livraison.
Les développeurs estiment, le client choisit
Chaque livraison suit le cycle suivant :
Les trois premières étapes de ce cycle prennent place au cours de "séances de planification de
livraisons", dont le but est de déterminer le contenu des livraisons à venir. Ces séances
réunissent le client et les développeurs, l'ensemble étant coordonné et arbitré par le chef de
projet (ou coach, dans le vocabulaire XP).
1. Le client décrit ses besoins sous forme de "scénarios client"
Le client définit ses besoins sous la forme de "scénarios client" simples, décrivant en quelques
mots chaque fonctionnalité souhaitée du logiciel. Par exemple, pour un logiciel de gestion de
carnet d'adresses on pourrait écrire les scénarios suivants :
8/19
•
"Je rentre un nom ou prénom, et le logiciel affiche la liste de toutes les personnes qui
possèdent ce nom ou ce prénom",
•
"Je peux enregistrer mon carnet d'adresses au format HTML.",
•
etc.
Les scénarios sont écrits dans le langage du client, et décrivent des fonctionnalités dont
l'implémentation paraît suffisamment courte (une ou deux semaines maximum). Les scénarios
sont notés sur des fiches cartonnées, pour être facilement manipulés (partagés, échangés,
déchirés, triés...). Si un scénario paraît trop vague ou trop complexe, il est décomposé en
scénarios plus simples. Un projet complet peut compter une centaine de scénarios ou davantage.
2. Les développeurs estiment le coût d'implémentation de chaque scénario
Les estimations ne se font pas en jours réels mais en unités abstraites, dont la définition exacte a
finalement peu d'importance. Certaines équipes préfèreront parler de temps idéal (journées 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 durées relatives d'implémentation des scénarios sans donner aux développeurs le
sentiment de s'engager sur des durées réelles.
Les estimations sont faites par l'ensemble de l'équipe, le client étant présent pour répondre
questions que les développeurs peuvent se poser sur chaque scénario. Au besoin,
développeurs peuvent procéder à quelques expérimentations sur machine pour se faire
meilleure idée des difficultés techniques rencontrées. XP nomme ces expérimentations
"spike solutions".
aux
les
une
des
Au terme de cette phase, chaque fiche de scénario client possède une indication de coût.
3. Le client sélectionne les scénarios à implémenter pour la livraison suivante
Tous les scénarios étant décrits et évalués, le client procède au choix des scénarios à
implémenter pour la prochaine livraison. Cependant, du fait que le coût de chaque scénario n'est
connu qu'en nombre de "points" abstraits, il faut un moyen pour calculer combien l'équipe
pourra traiter de scénarios.
Comme nous allons le voir, chaque livraison est préparée en une suite d'itérations, qui durent
chacune 2 semaines environ. XP définit la notion de vélocité, qui correspond au nombre de
points que l'équipe peut traiter en une itération. Cette vélocité est tout d'abord estimée par le
chef de projet, puis recalculée à chaque itération en faisant simplement la somme des points des
scénarios qui ont été complétés à l'itération précédente.
Remarque: Cette vélocité ne représente en aucun cas le niveau de "performance" de l'équipe,
dans la mesure où elle dépend en grande partie de la façon dont les développeurs font leurs
estimations. Cependant, ses variations peuvent indiquer des problèmes passagers : si la vélocité
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'itérations jusqu'à la prochaine livraison, on est donc capables de
déterminer combien l'équipe peut traiter de "points" pour cette livraison. Le client dispose de ce
nombre de points pour "acheter" les scénarios à implémenter pour cette livraison, et
9/19
éventuellement les livraisons suivantes. A lui donc de répartir les scénarios comme il le souhaite
dans les livraisons à venir pour obtenir la plus grande valeur ajoutée au plus tôt.
4. Les développeurs implémentent les scénarios choisis
L'implémentation proprement dite se fait en une suite d'itérations, décrites plus en détail dans la
section suivante. Une fois la livraison effectuée, on passe à la suivante en répétant le même
cycle :
•
Le client reprend les scénarios restants. Il peut en ajouter, en retirer ou en modifier à son
gré.
•
Les développeurs réestiment les durées de tous les scénarios en se basant sur une
meilleure connaissance du contexte technique et fonctionnel,
•
Le client sélectionne les scénarios à implémenter,
•
Les développeurs implémentent les scénarios,
•
etc.
Ce cycle continue tant que le client souhaite investir dans le projet !
Gestion des itérations
Le logiciel est réalisé en une suite de petites itérations
Ces itérations durent 2 semaines environ. Si la gestion des livraisons est axée sur la
détermination des estimations et du contenu, celle des itérations est axée sur la détermination
des tâches à accomplir, la répartition de ces tâches parmi les développeurs et le suivi de la
réalisation.
L'équipe détermine et se répartit les tâches à réaliser
Les premiers jours de chaque itération sont dédiées à la détermination et l'attribution des tâches,
sous la forme d'une séance collective de planification d'itération qui réunit le client et les
développeurs.
Le client commence par déterminer les scénarios qu'il souhaite voir réalisés au cours de cette
itération. Ensuite, les développeurs étudient ces scénarios un par un pour en déduire les tâches à
réaliser et se les répartir entre eux :
10/19
1. Les développeurs déterminent la liste des tâches à réaliser
Les développeurs prennent un à un les scénarios à réaliser pour cette itération, et déterminent les
tâches concrètes qui serviront à leur implémentation. Cette activité est menée en groupe, et le
client est présent pour décrire plus précisément les scénarios et répondre à toutes les questions
d'ordre fonctionnel.
Cette activité fait déjà intervenir des éléments de conception, puisque les tâches concernent
l'implémentation proprement dite. S'ils le souhaitent, les développeurs peuvent expérimenter
quelques "spike solutions" pour se faire une meilleure idée de la difficulté de certaines tâches.
Comme les scénarios, les tâches sont notées sur des fiches cartonnées pour être facilement
manipulées. A la fin de cette phase, les développeurs disposent d'une liste de tâches à réaliser
pour l'itération en cours. Il reste à les répartir entre eux.
2. Les développeurs choisissent les tâches qu'ils vont implémenter et évaluent leur durée
L'équipe reprend la liste des tâches à réaliser, et les développeurs se les répartissent
progressivement. Chaque fois qu'un développeur s'approprie une tâche, il en évalue lui-même la
durée (en jours cette fois) et s'assure qu'il ne prend pas plus de tâches qu'il ne pourra en réaliser
au cours de l'itération.
D'une manière générale, les tâches d'un même scénario sont prises en charge par un même
développeur, de sorte que le suivi du scénario soit correctement assuré. Les tâches ne sont pas
affectées arbitrairement par spécialité technique : un développeur peut prendre en charge une
tâche correspondant à une technique qu'il connaît peu, sachant que les implémentations se font
toujours en binôme et qu'il pourra donc s'associer à un spécialiste de la technique en question au
moment voulu (voir la section "Travail en équipe").
A la fin de cette phase, chaque développeur connaît la liste des tâches qu'il doit réaliser au cours
de cette itération.
A la fin de l'itération, on recommence !
Une fois l'ensemble des tâches réalisé, on passe à l'itération suivante en reprenant le même cycle
:
11/19
•
Le client choisit les scénarios à réaliser,
•
L'équipe détermine la liste des tâches à accomplir pour l'itération,
•
Les développeurs se répartissent les tâches et évaluent leurs coûts,
•
Les développeurs réalisent les tâches,
•
etc.
Suivi du projet
Pour chaque scénario planifié, un ensemble de tests de recette est écrit. Ces tests ont pour but de
vérifier de manière automatique chacune des fonctionnalités demandées par le client. Le client
(ou l'un de ses représentants) définit ces tests et participe éventuellement à leur implémentation,
aidé de testeurs.
L'évolution de ces tests forme un indicateur concret de l'avancement des développements :
•
Le nombre de tests écrits indique l'avancement des spécifications,
•
Le nombre de tests validés indique l'avancement des développements,
•
Le nombre de tests en échec indique le degré de qualité du logiciel.
Le chef de projet peut ainsi représenter de manière très synthétique l'évolution du projet :
Les tests de recette sont lancés fréquemment, et tous les participants du projet (client, direction,
développeurs) sont informés en permanence de leurs résultats.
Qualité du design et du code
Rappelons ici que XP repose sur une réduction significative du coût du changement du logiciel.
Cette réduction n'est pas le fruit du hasard, elle est le résultat de l'application à l'extrême des
pratiques suivantes :
12/19
La conception reste la plus simple possible
"You ain't gonna need it!" : on ne fait de conception que pour les fonctionnalités existantes, pas
pour les fonctionnalités futures. En corollaire :
•
on ne fait de généralisations dans le design que lorsque les exemples concrets se
présentent.
•
on n'introduit pas d'optimisations si elles ne sont pas demandées par le client.
En somme, plutôt que de préparer 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 malléable que possible grâce à une activité
permanente de remaniement (refactoring). Les remaniements consistent par exemple à
renommer les variables, les méthodes, les classes, déplacer des attributs ou des méthodes vers
d'autres classes, décomposer les grosses méthodes en des méthodes 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 apparaître "Once and Only Once"). Lorsqu'un développeur doit utiliser une partie de
code qui se trouve déjà quelque part dans l'application, il remanie l'application de manière à
pouvoir utiliser le code existant. De la sorte les modifications de l'application n'impactent
généralement que peu d'endroits dans le code, ce qui est primordial pour que celui-ci reste
malléable.
Le remaniement est également utilisé pour rendre le code plus clair : lorsqu'un développeur doit
comprendre une nouvelle partie du code, il la modifie afin de la rendre plus claire pour ceux qui
passeront après lui.
Une phase de remaniement précède généralement l'ajout de toute nouvelle fonctionnalité, de
manière à ce que le nouveau code s'insère aussi naturellement que possible dans l'application.
Le remaniement est plus qu'un moyen de dépoussiérer 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 associés
En plus des tests de recette, qui servent à prouver que le logiciel remplit ses objectifs, XP utilise
intensivement les tests unitaires de non-régression. Ces tests sont écrits par les développeurs en
même temps que le code lui-même, pour valider chaque portion de code susceptible de
comporter des erreurs. Les tests doivent s'exécuter sans aucune interprétation de la part du
développeur : ils comportent des assertions qui vérifient automatiquement si le code testé
fonctionne ou non.
Quasiment chaque classe de l'application possède une classe "jumelle" de test. Lorsque des
développeurs doivent ajouter une nouvelle méthode à la classe applicative, ils commencent par
ajouter à la classe de test un ensemble d'assertions qui décrivent le comportement de la méthode
à ajouter. La méthode n'est implémentée qu'ensuite, pour que ces tests passent. Bien sûr, on ne
13/19
teste pas toutes les méthodes de l'application. Avec un peu de pratique, il devient facile de
savoir ce qui mérite d'être testé, la règle 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 sûr pas jetées après usage : elles sont gérées par un framework
dédié, qui permet de les exécuter en groupe ou de manière globale. La batterie de tests de
l'application ne cesse donc de s'enrichir, et forme avec le temps un filet de sécurité qui permet
aux développeurs de garder une grande vitesse de développement sans crainte de régressions.
Ces tests sont ainsi lancés en permanence par les développeurs - en fait, à chaque compilation.
Tous les tests unitaires doivent passer à 100% avant tout report de modifications dans la version
d'intégration 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 très vite détectées et très vite localisées.
•
Les tests donnent une vision précise de la tâche à réaliser et aident les développeurs à
aller droit au but.
•
Les tests placent les développeurs dans un contexte réduit qui leur permet de s'abstraire
de la complexité du reste de l'application.
•
Il est possible de s'assurer du fonctionnement global du système très rapidement, après
toute modification du code, avant ou après toute intégration dans la version officielle du
système.
Ce que l'on constate au final, c'est que les développeurs 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 sélectionné les scénarios à implémenter, les développeurs décident en groupe
de l'affectation des scénarios.
Le code est partagé par toute l'équipe
L'application n'est pas découpée en zones réservées à chaque développeur : 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 après. D'autre
part le fait qu'une même portion de code soit visitée par plusieurs développeurs diminue les
risques d'erreur et augmente sa qualité.
Cette pratique va à l'encontre du découpage classique du travail en domaines techniques (IHM,
bases de données, etc.). XP exploite les spécialistes, mais en tant que consultants internes et non
comme travailleurs spécialisés.
14/19
Les développeurs travaillent en binômes
Chaque développeur est responsable d'une tâche qui lui est propre, mais il doit
systématiquement demander l'aide d'autres développeurs pour la réaliser. Le développeur va
s'associer à :
•
Un développeur ayant des connaissances spécifiques pour la tâche en cours.
•
Un développeur plus jeune, pour lui transmettre ses connaissances.
•
Plus généralement, un développeur intéressé par la tâche.
Le binôme travaille sur une seule machine : le développeur qui est aux commandes se concentre
plutôt 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 stratégique - mais cette répartition n'a rien de strict : les développeurs
s'organisent comme ils le souhaitent pour mener à bien la tâche en cours. Les binômes changent
fréquemment, de sorte que chacun est amené à travailler avec tous les autres membres de
l'équipe.
Cette approche peut paraître coûteuse au premier abord, mais elle s'avère parfaitement rentable
en pratique grâce à :
•
Une plus grande qualité du design et du code qui limite les retours en arrière et les
longues phases de debug.
•
Une concentration accrue des développeurs.
•
Une plus grande vitesse de développement (après tout l'écriture du code ne représente
en soi qu'une petite fraction du travail).
•
Une meilleure diffusion de la connaissance dans l'équipe, avec notamment une
formation accélérée des débutants.
Les développeurs respectent les règles de codage de l'équipe
Ces règles sont définies par l'ensemble des développeurs. Elles donnent au code un aspect
uniforme sur toute l'application, ce qui facilite le partage du code et le travail en binômes.
L'homogénéisation du code ne se limite pas seulement à sa présentation et au respect de règles
de programmation. L'équipe s'appuie en effet sur un système de métaphores commun, c'est à
dire un ensemble d'expressions décrivant les acteurs du système et leurs interactions. Ce
système de métaphores constitue :
•
Un vocabulaire commun qui va permettre à toute l'équipe de parler des mêmes choses
avec les mêmes mots. Par exemple, dans le monde des télécom, il faut définir ce qu'est
un "noeud" d'un réseau et se servir de ce mot dans le cadre de la définition établie.
•
Une métaphore de fonctionnement, par exemple : "le logiciel de contrôle de cette
machine-outil fonctionne comme une machine à café". Il faut bien sûr veiller à ce que la
métaphore ne devienne pas une simplification abusive du concept initial !
•
Une source d'inspiration pour la conception d'autres éléments fondamentaux d'un projet
tels que:
o
Les structures de données utiles au logiciel,
15/19
o
Les méthodes d'accès efficaces à ces données.
L'intégration se fait de manière quasi-continue
L'intégration est faite tous les jours. Dès qu'un développeur finit une tâche, il met à jour la
version d'intégration en s'assurant que tous les tests de non-régression de l'application passent à
100%.
La version "livrable" du logiciel évolue donc chaque jour, en reflétant fidèlement l'état
d'avancement des développements.
L'équipe adopte un rythme durable
D'une part, une équipe fatiguée ne fait pas du bon travail. D'autre part, s'il y a trop de retard,
c'est qu'il y a un problème de fond et il est illusoire de chercher à le camoufler par davantage de
travail. Pour ces raisons, l'équipe adopte la règle suivante : pas d'heures supplémentaires deux
semaines de suite.
16/19
CONDITIONS D'UTILISATION D’XP
XP a fait ses preuves pour des équipes de moins de 10 développeurs réalisant un produit sur
mesure pour un client suffisamment accessible.
Cependant, du fait que la méthode se montre efficace dans les situations où il est difficile
d'établir des spécifications claires et stables au début du projet, diverses entreprises étudient la
possibilité d'appliquer XP à des contextes différents. 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 représentant spécialiste du domaine fonctionnel,
mais il est important que celui-ci ait des contacts fréquents avec le client final pour
s'assurer de l'adéquation réelle du produit à ses besoins.
•
Comment appliquer XP dans des projets de taille importante ?
Dans la plupart des cas, ces projets seront décomposés en équipes de taille adaptée. Il
reste cependant à déterminer comment organiser ces équipes entre elles, mais XP ne
propose aujourd'hui rien de précis dans ce sens.
Dans tous les cas, la méthode doit être adaptée par chaque équipe à son contexte particulier. Il
est important cependant de respecter un certain nombre de conditions pour bénéficier réellement
des apports de la méthode et mériter le "label XP" ;-)
Le client doit être intégré au projet
Le client (ou au moins un représentant du domaine fonctionnel) doit être disponible pour
participer à la définition des scénarios, arbitrer les priorités, apporter ses connaissances métier et
définir les tests de recette.
Le client doit faire suffisamment confiance à l'équipe de développement pour ne pas lui imposer
un résultat à priori (il obtient en retour l'opportunité de contrôler le produit de manière beaucoup
plus fine que par le passé).
Le logiciel doit rester toujours simple, facilement modifiable et largement testé
Les développeurs doivent avoir la compétence nécessaire pour réaliser des applications
réellement simples et évolutives. Ils ne doivent également pas être trop limités par des
problèmes de compatibilité ascendante qui limiteraient trop fortement les possibilités de
remaniement.
Les tests unitaires sont également un facteur important du succès de la méthode. Ils doivent être
écrits en même temps que le code lui-même, et l'ensemble de ces tests doit passer à 100% en
permanence sur la version d'intégration du produit.
L'équipe doit travailler... en équipe
XP exige une forte cohésion au sein de l'équipe. Cette cohésion ne peut être imposée, elle doit
être le résultat des choix faits lors de la constitution de l'équipe. Ce point est suffisamment
important pour pouvoir nécessiter le remplacement d'un membre de l'équipe en cours de projet.
17/19
D'autre part , les développeurs doivent avoir la capacité et la volonté de participer à toutes les
activités du développement : contact avec le client, évaluation des coûts, design et codage, test,
etc. Dans un tel contexte, il est important que le chef de projet soit prêt à laisser une autonomie
assez importante à l'équipe elle-même, pour se concentrer sur la coordination de l'ensemble.
Tous les participants doivent être prêts au changement
Finalement, le plus gros obstacle à la réussite de XP reste la résistance au changement, qu'elle
vienne des développeurs ou du client. XP apporte un profond changement dans l'approche des
projets de développement, et le changement de méthodes de travail (quelles qu'elles soient) reste
toujours une entreprise difficile.
18/19
CONCLUSION
Au final, on peut se demander si la méthode porte bien son nom. Le terme "extrême" évoque
des prises de risques insensées, alors qu'en pratique XP vise une suppression systématique du
risque. En effet, une équipe XP :
•
s'assure en permanence qu'elle se concentre sur les besoins réels du client,
•
développe 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 développements,
•
utilise un filet (tests unitaires) pour tous ses developpements,
•
pratique une relecture de code immédiate et continue,
•
etc.
Malgré cela, de nombreuses équipes trouveront la méthode extrême dans la mesure où elle
implique un changement profond des mentalités et des habitudes de travail. Mais si le
changement est radical, rien ne dit qu'il doit être brutal. Les auteurs de XP préconisent au
contraire une adoption progressive de la méthode, en partant des pratiques de base telles que les
tests unitaires ou le travail en binômes.
Après avoir pris connaissance des grandes lignes de la méthode, une équipe souhaitant passer à
XP devra commencer par expérimenter progressivement ces pratiques, tout en approfondissant
en parallèle sa compréhension de la méthode. Notre section Ressources fournit à cet effet les
références des principaux livres et sites web disponibles. Cependant, comme rien ne vaut le
contact n'hésitez pas à nous écrire, soit à [email protected] soit sur notre mailing list
[email protected], nous serons ravis de parler XP avec vous !
19/19

L`Extreme Programming

Transcription

Documents pareils

Livre Vigi + Cinéma/Télévision Musique/Spectacles Contenus

Formation Lotus Notes Développement Initiation

Nouveau système de prise de rendez

Diapositive 1

2014 - FP vacation DD - Agence Erasmus+ France / Education

video disney free

Forum du Développement Territorial

Méthode Agile eXtreme Programming