Rapport de l'exposé eXtreme Programming

1. ”‘‰”ƒƒ–‹‘ ‡–”²‡
‡–”‡‡ ”‘‰”ƒ‹‰
^
,,zE ^
^Z/
/ E

2. ‘ƒ‹”‡
• /EdZKhd/KE
/
D
D s
D
W
h ,
s D
W
// W W
W
,
W yW
W
///
K ,
Z
/s yW
yW
W
s
s
yW hD
• KEh^/KE

3. • /EdZKhd/KE
Le développement de logiciels a été pendant longtemps entièrement libre de directives ou
de contraintes, et il n'y avait aucune méthode pour analyser les besoins, produire une
solution, ou même évaluer le succès. Mais depuis les débuts de l'informatique
commerciale dans les années '60,et en 1968, une conférence de l'OTAN a introduit le
terme « génie logiciel » et suggéré d'utiliser les méthodes rigoureuses et éprouvées du
génie civil au chaos du développement de logiciels. L'idée était louable, mais une
différence majeure existe: contrairement à la physique et aux mathématiques,
l'informatique 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 d'un logiciel.
Ces cycles prendront en compte toutes les étapes de la conception d'un logiciel.
D
Le modèle en cascade est hérité de l'industrie du BTP1. Ce modèle repose sur les hypothèses
suivantes :
• On ne peut pas construire la toiture avant les fondations.
• Les conséquences d'une modification en amont du cycle ont un impact majeur sur les
coûts en aval.
d W

4. Les phases traditionnelles de développement sont effectuées simplement les unes après les
autres, avec un retour sur les précédentes, voire au tout début du cycle. Le processus de
dé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 d'une étape de
validation-vérification.2
D s
Le modèle du cycle en V a été imaginé pour pallier le problème de réactivité du modèle en
cascade. Ce modèle est une amélioration du modèle en cascade qui permet en cas d'anomalie,
de limiter un retour aux étapes précédentes. Les phases de la partie montante doivent renvoyer
de l'information sur les phases en vis-à-vis lorsque des défauts sont détectés afin d'améliorer
le logiciel.
De plus le cycle en V met en évidence la nécessité d'anticiper et de préparer dans les étapes
descendantes les « attendus » des futures étapes montantes : ainsi les attendus des tests de
validation sont définis lors des spécifications, les attendus des tests unitaires sont définis lors
de la conception, etc.
D

5. Le cycle en V est devenu un standard de l'industrie du développement de logiciel et de la
gestion 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 n'est
directement relié à aucune méthodologie, mais propose une série de recommandations,
valeurs, et principes qui sont appliquées dans d'autres 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. En 1986, Barry W. Boehm présentait un nouveau modèle de développement itératif et
incrémental.
En 1986 également, Hirotaka Takeuchi et Ikujiro Nonaka publient « the new new product
developpement game » dans la Harvard business review. Leur article présente un modèle de
développement basé sur l'aptitude au changement, l'auto organisation, l'imbrication des phases
de développement, et l'itération (on y fait d'ailleurs mention du mot scrum par analogie au
rugby).
En 1991, James Martin (RAD3), s’appuyant sur cette vision d’une évolution continue, proposa
une méthode de développement rapide d’application. Sa structure, base des approches
actuelles, déterminait le phasage essentiel et mettait en œuvre un principe adaptatif fondé sur
la 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, introduisirent
des 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 Extreme
programming et Scrum sont les principales représentantes) poussa à l’extrême certaines
pratiques de qualité de la construction applicative ainsi que les techniques adaptatives
d’estimation, de planification et de pilotage de projet.

7. En 2001, aux États-Unis, dix-sept figures éminentes du développement logiciel se sont
réunies pour débattre du thème unificateur de leurs méthodes respectives, dites méthodes
agiles. Les plus connus d'entre eux étaient Ward Cunningham, l'inventeur du Wiki via
WikiWikiWeb, Kent Beck, père de l'extreme programming et cofondateur de JUnit, Ken
Schwaber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith, prônant l'ASD, Alistair
Cockburn pour la méthode Crystal clear, Martin Fowler, et Dave Thomas ainsi que Arie van
Bennekum pour DSDM (Dynamic System Development Method). Ces 17 experts venant tous
d'horizons différents réussirent à extraire de leurs concepts respectifs des critères pour définir
une nouvelle façon de développer des logiciels :4
De cette réunion devait émerger le Manifeste Agile, considéré comme la définition canonique
du développement Agile et de ses principes sous-jacents.5
s D
Les quatre valeurs fondamentales (entre parenthèses, les citations du manifeste)6:
• L'équipe (« Personnes et interaction plutôt que processus et outils ») : Dans l'optique
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 d'avoir une équipe soudée et qui
communique, composée de développeurs (éventuellement à niveaux variables), plutôt
qu'une équipe composée d'experts fonctionnant chacun de manière isolée. La
communication est une notion fondamentale.
• L'application (« Logiciel fonctionnel plutôt que documentation complète ») : Il est
vital que l'application 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 D
yW h W D
s D ^ s E
z /^E y
D

8. importante, mais peut pourtant être néfaste si elle n'est 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 à l'importance 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 l'adaptation du
logiciel à ses attentes.
• L'acceptation 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.
W
Ces quatre valeurs se déclinent en douze principes généraux communs à toutes les méthodes
agiles7 :
• « 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 l'art et les développeurs doivent collaborer quotidiennement au projet »
• « Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le
soutien dont elles ont besoin, et croyez en leur capacité à faire le travail »
• « La méthode la plus efficace pour transmettre l'information est une conversation en
face à face »
• « Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet »
d

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 à l'excellence technique et à la qualité de la conception
améliore l'agilité »
• « La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle
»
• « Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui
s'auto-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. 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
W
La programmation eXtrème dite XP (eXtreme Programming) est une méthodologie efficace
de développement rapide de logiciels qui exige que les membres d’une équipe de
développeurs soient physiquement proches les uns des autres.
XP est une méthode de développement dédiée à des 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 :
Se focaliser sur les besoins réels du client.
D D

11. XP définit une discipline de développement qui permet de diminuer le coût du changement
dans le logiciel, à tel point qu'il devient plus avantageux de prendre la décision le plus tard
possible, 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 du
dé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éveloppeurs
sont préparés aux changements des besoins du client, même dans la fin du cycle de
développement.
Managers, clients et développeurs font partie de la même équipe dont le but est de fournir un
logiciel de qualité. XP rend possible simplement et efficacement le développement en groupe
de 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 du
logiciel
Un travail d'équipe (développeurs / chefs de projets / clients)
La qualité du code : elle garantit un gain d'argent pour le client
La qualité des tests effectués au plus tôt
Une intégration permanente
XP : (une méthodologie allégée)
Une méthodologie logicielle est un ensemble de règles et de pratiques mises en œuvre pour la
création de programmes. Ces règles sont trop difficiles à suivre, les procédures complexes et
mal 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 celles
qui contribuent à la qualité et laisser de côté celles qui ralentissent le projet.
L'XP est une méthodologie allégée car elle est constituée de peu de règles et de mises en
pratique. Le travail en équipe, la réactivité, la concision et l'efficacité s'en trouvent renforcés.

12. XP est une méthode basée sur des principes simples, que tout le monde pratique déjà sans le
savoir. Mais alors, où est la « révolution » ?
Rendre moins lourdes les démarches
Le 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 produit
commandé.
Cela, en trouvant un compromis équilibré entre pas de démarche et trop de démarche, tout
en respectant le minimum de discipline nécessaire pour attendre un retour sur investissement
en temps et en effort immédiat et intéressant.
Ainsi, on souhaite réduire radicalement la production de documents en se focalisant sur un
code 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 habile
compromis entre une méthode traditionnelle et le développement « cow boy », sans règles
précises. Par conséquent le travail des informaticiens est totalement tourné vers la technique
où ils se sentiront vraisemblablement plus à l’aise.
Changer les principes
En outre, XP, en tant que méthode agile, se veut adaptative plutôt que prédictive. C’est à dire
qu’à l’inverse des méthodes lourdes qui tentent de dresser un plan au début du projet, XP
indique qu’il vaut mieux agir sur le court terme. Cela, tout simplement parce qu’il n’existe pas
de projet figé où le prédicat de base ou le contexte ne changent pas du tout. Dans ce cas, le
coû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 de
mieux s’y adapter mais permet aussi une meilleure relation avec le client et la livraison d’un
produit 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 les
processus. Alors, le développement tentera d’être une activité agréable plutôt qu’un
cauchemar bureaucratique.
,
La naissance d’une nouvelle méthode arrive rarement sans raisons. Elle fait plutôt suite à une
période difficile...
D’après une étude américaine menée en 1994 sur 8000 projets, 16 % n’ont pas respecté les
délais et le budget initial et, pire, 32 % n’ont jamais abouti.

13. Ainsi, dans le monde de l’ingénierie logicielle, trois plaies pourtant bien connues enveniment
le développement d’applications.
La première concerne le planning difficilement maîtrisé ou impliquant de nombreuses heures
sup. Le deuxième est issue des besoins souvent mal identifiés ou mal compris en raison d’un
cahier des charges mal étudié ou incomplet.
Tout cela implique des changements au cours du développement, d’autant plus si le client
décide de modifier le produit, après une première maquette par exemple. Enfin, le dernier
problè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 XP
fait partie.
y
W 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. ///
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. Des scénarios initiaux sont dégagés et Présentés, classés par priorité et répartis en
ité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 :
• Responsabilisation
Dé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 XP
Suivi des tests (planification itérative)
Tests de recette
Intégration continue
Rythme durable
D. Tracker :
• Responsabilisation
Pas un supérieur hiérarchique
Quelqu’un a qui on peut se confier
De préférence pas un programmeur, mais quelqu’un d’extérieur
Pour éviter les discussions techniques
A défaut, ce rôle peut tourner entre les programmeurs à chaque itération
• Pratiques XP
Planification itérative
E. Manager :
• Responsabilisation
Il 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. • 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. Écrire des scénarios utilisateur «user stories» avec le client
Segmenter 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 fois
Adopter un codage uniforme: noms, standards…
Ne jamais ajouter de fonctionalité trop tôt
Encourager la reconstruction avant une nouvelle itération
iii. Les activités et processus.
Le client (expert disponible) priorise les histoires
La 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équentiellement
Les tests d’acceptation sont exécutés souvent et publiés

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 XP
dé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
et 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 XP
dé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. 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ès
permettent d’améliorer continuellement la conception et le code de l’application pour qu’elle
reste 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) et
interviennent sur la totalité de l’application. Cela garantit la qualité de cette dernière à travers
les relectures croisées que cela engendre, mais cela rend également le travail plus motivant et

20. offre une plus grande souplesse dans l’affectation des tâches. Les pratiques qui régissent cette
organisation 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 de
créer un contexte dans lequel une démarche de spécification et de conception purement
itérative devient viable. Les pratiques suivantes montrent comment XP exploite cet avantage

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. Z
^
NB : La valeur ‘Respect’ existe dès la deuxiéme version d’XP on se contente d’étudier quatre
autres 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. Il
ne s’agit en définitive que de techniques, destinées à faire émerger un environnement de
travail marqué par les quatre qualités érigées en valeurs par XP et qui en font l’essence : la
communication, 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 de
cré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 deux
conditions dépendent en majeure partie de la qualité de la communication qui lie ces
intervenants 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 communication
directe, sur le contact humain. Certes, la communication orale présente des faiblesses en
termes de structuration de l’information et de traçabilité, mais elle tire sa force de sa

23. simplicité et des interactions rapides entre les interlocuteurs qui permettent de converger
rapidement sur les informations essentielles. En outre, le contact direct permet de véhiculer
des informations beaucoup plus personnelles cela donne ainsi l’occasion d’identifier et de
résoudre des blocages qui relèvent de positions individuelles, qui sans cela pourraient
compromettre 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 ses
pratiques. Ainsi, qu’il s’agisse de l’identification des besoins, de la planification, de la
répartition des tâches ou encore de la programmation proprement dite, la plupart des pratiques
d’XP sont conçues pour amener les intervenants du projet à communiquer directement et
résoudre les problèmes ensemble.
Remarque
Cette approche constitue l’une des forces majeures d’XP, mais c’est aussi d’un certain point de
vue sa principale faiblesse. D’une part, ce besoin de communication est le principal facteur
limitatif au regard de la taille de l’équipe et, d’autre part, cela rend XP très sensible au type de
relations humaines qui ont cours dans le projet : appliquer XP dans un projet marqué par des
antagonismes internes forts, c’est courir à la catastrophe – mais on peut légitimement se
demander 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 écrite
n’est pas laissée de côté pour autant. Mais elle apparaît sous une forme différente : toutes les
informations ayant trait à l’implémentation et la conception se retrouvent dans le code lui
même – dont la clarté fait l’objet de nombreux efforts – et dans la batterie de tests qui
l’accompagne, et celles relatives aux besoins du client sont consignées d’une manière on ne
peut plus formelle, sous la forme de tests de recette automatiques. Si le client souhaite obtenir
des documents supplémentaires, il lui suffit de définir et de planifier les tâches
correspondantes comme pour tout autre besoin.
2) La simplicité comme garantie de productivité

24. Une personne qui arrive sur un projet XP ne doit pas s’étonner de s’entendre répéter les
quelques «mantras» suivants : «La chose la plus simple qui puisse marcher» (The simplest
thing that could possibly work), «Tu n’en auras pas besoin» ( You ain’t gonna need it – et
son acronyme YAGNI), ou encore «Une fois et une seule» (Once and only once). Tous trois
sont l’expression d’une même valeur : la simplicité.
Cette simplicité touche d’abord à la réalisation même du logiciel, dans laquelle un soin
particulier est apporté au code pour le débarrasser de toute complexité superfiue. En
particulier,les mécanismes de généricité – le «péché mignon» des développeurs – ne sont
encouragés que lorsqu’ils servent un besoin concret et immédiat, et en aucun cas un besoin
futur plus ou moins imaginaire. Les développeurs sont donc invités à implémenter la chose la
plus simple qui puisse marcher et, en ce qui concerne ces fameux mécanismes génériques, ou
encore ces outils «magiques» qui en font plus que ce qu’on leur demande, ils n’auront pas
besoin! En revanche, simple ne veut pas dire simpliste : les solutions adoptées doivent être
aussi simples que possible, mais toutes les duplications doivent être éliminées de sorte que
chaque information, chaque mécanisme ne soit exprimé qu’une fois et une seule – ce principe
est 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 de
définir ses besoins et ses priorités avec une grande précision pour éviter d’implémenter des
choses inutiles et pour pouvoir se focaliser sur les besoins réellement importants. La
simplicité est également recherchée dans le choix des outils (de programmation ou de gestion
de 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é de
revenir en arrière le lendemain si un besoin différent apparaît. L'éventuel coût supplémentaire
induit sera, d’une part réduit parce que l’application est restée assez simple pour évoluer
facilement, et d’autre part sera bien peu de choses au regard des économies réalisées à ne pas
faire ce qui n'aurait servi à rien. » C’est au succès de ce pari qu’une équipe XP doit sa vitesse
de 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’Extreme
Programming est avant tout un processus de réduction du risque dans le projet. Le risque est

25. en effet soigneusement contrôlé à tous les niveaux, par la mise en place de boucles de
feedback qui permettent à l’équipe de développement, comme à son client, de savoir à tout
moment 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 du
projet et l’état réel du produit. Mais le feedback ne se borne pas à l’observation : la pratique
de 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 mieux
adapté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 des
indications 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 pour
s’appuyer sur l’état réel de l’application plutôt que sur l’idée que l’on pourrait en avoir a
priori. Enfin,les développeurs s’appuient en permanence sur le feedback de leur binôme pour
s’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 projet
amé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 sereine
parce qu’elle sait qu’elle dispose de nombreux mécanismes pour s’assurer que le projet reste
sur 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 certaine
dose de cran. En effet, il faut du courage pour se lancer dans un projet sans avoir au préalable
tout spécifié et conçu dans le détail, même si l’on sait que le processus suivi comporte de
nombreux mécanismes de feedback.
Il faut également du courage pour se borner à réaliser des choses simples, se focaliser
uniquement sur les besoins du moment en se disant qu’on pourra adapter l’application à de

26. nouveaux besoins, le moment venu. Il en faut aussi pour accepter de jeter une partie du code
qui 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, en
particulier lorsqu’il s’agit de maintenir une transparence complète, même lorsque les
nouvelles ne sont pas bonnes, ou encore lorsqu’il s’agit de travailler ouvertement avec son
binô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 des
méthodes nouvelles sur des projets dont les enjeux sont toujours stratégiques.
s
yW hD
UML est un langage graphique de modélisation des besoins des utilisateurs, des concepts
métier, des concepts techniques dans le cadre d’un développement informatique. UML est
généralement associé à une méthodologie globale de gestion de projets fondée, si possible, sur
les grandes activités : spécification, analyse, conception et développement, éventuellement
ité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 n'est 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. • 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 souvent
ignorés par l'industrie. Une des idées révolutionnaires est que le coût du changement n'est pas
variable mais plutôt constant; XP accepte donc le changement comme une réalité et l'intègre
dans le processus de développement. Aussi, la programmation en paire, où deux
programmeurs travaillent ensemble sur le même ordinateur, permet d'augmenter la qualité à
des niveaux encore jamais vus. Une autre idée consiste à mettre l'emphase sur la
communication constante entre l'équipe de développement et le client, par le biais de boucles
rapides développement-test-feedback. Certaines de ces idées ne sont pas nouvelles, mais elles
sont assemblées dans XP pour former une méthodologie efficace et qui présente des résultats
concrets, plutôt que des résultats sur papier.