Programmation eXtrême eXtreme Programming

Logiciel et Système informatique

24/05/2011

EL KHECHYNE Sarah

LASRI Ayyoub

ZIANE Bilal

Sommaire

• INTRODUCTION ............................................................................................................................... 3

I. Les méthodologies de développement : ........................................................................................ 3

1) Modèle en cascade : ................................................................................................................... 3

2) Modèle en V : .............................................................................................................................. 4

3) Méthodes Agiles : ....................................................................................................................... 5

i. Présentation ............................................................................................................................ 5

ii. Un peu d’Histoire..................................................................................................................... 5

iii. Valeurs des Méthodes Agiles. ............................................................................................ 7

iv. Principes. ................................................................................................................................. 8

II. Extreme Programming (Programmation Extrême) : .................................................................... 10

1) Définition et Présentation: ...................................................................................................... 10

2) Historique : ................................................................................................................................ 12

3) Pourquoi XP ? : .......................................................................................................................... 13

4) Pour qui ? : ................................................................................................................................ 13

III. Equipe et rôles : ........................................................................................................................ 14

1) Organisation Hiérarchique : ..................................................................................................... 14

2) Répartition des rôles : .............................................................................................................. 16

IV. Les Caractéristiques de l’XP : .................................................................................................... 16

1) Activité cadre de XP : ................................................................................................................ 16

2) Pratiques : ................................................................................................................................. 18

3) Valeurs : .................................................................................................................................... 21

V. Autres Considérations : ................................................................................................................ 26

1) XP et UML : ................................................................................................................................ 26

2) Avantages et inconvénients : ................................................................................................... 26

• CONCLUSION ................................................................................................................................. 27

• INTRODUCTION

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.

I. Les méthodologies de développement :

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.

1) Modèle en cascade :

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.

1 Le secteur économique du Bâtiment et des Travaux Publics

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

2) Modèle en V :

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.

2 Modèle en cascade http://fr.wikipedia.org/wiki/Cycle_de_d%C3%A9veloppement_%28logiciel%29

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.

3) Méthodes Agiles :

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.

i. Présentation

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.

ii. Un peu d’Histoire.

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.

3 La méthode de développement rapide d'applications

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

iii. Valeurs des Méthodes Agiles.

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

4 Méthode Agile

http://fr.wikipedia.org/wiki/M%C3%A9thode_agile#M.C3.A9thodes_Agiles_reconnues_par_date_de_publicati

on_officielle 5 « Le Manifeste Agile a été rendu public en 2001, et plusieurs implémentations de la méthode, comme XP,

SCRUM, et Crystal, existent. », Kieran Conboy et Brian Fitzgerald, Extreme Programming And Méthodes Agiles -

XP/Agile Universe 2004 : 4e Conférence sur Extreme Programming et les Méthodes Agiles, Calgary, Canada, du

15 au 18 août 2004, Actes, chapitre Vers un cadre conceptuel pour les Méthodes Agiles, Springer Verlag, New

York, août 2004, (ISBN 354022839X). 6 Manifeste pour le développement Agile de logiciels [archive]

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.

iv. Principes.

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 »

7 Traduction des principes sous-jacents au manifeste [archive]

• « 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 ».

v. Les Méthodes Agiles reconnues.

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)

II. Extreme Programming (Programmation Extrême) :

1) Définition et Présentation:

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.

8

http://fr.wikipedia.org/wiki/M%C3%A9thode_agile#M.C3.A9thodes_Agiles_reconnues_par_date_de_publicati

on_officielle

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.

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.

2) Historique :

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.

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.

La méthode est née réellement en 1997 après la parution du premier livre de Kent Beck : « eXtreme

Programming Explained », acteur très actif dans domaine de “Design Patterns”, domaine qui a

beaucoup inspiré XP..

3) Pourquoi XP ? :

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 !

4) Pour qui ? :

Petites à moyennes équipes écrivant des logiciels dont les besoins sont vagues ou changent rapidement

III. Equipe et rôles :

1) Organisation Hiérarchique :

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 � Tests unitaires � Conception simple � Remaniement

� Responsabilité collective du code � Règles de codage � Intégration continue � Rythme durable

B. Client :

• Responsabilisation � Description informelle d’une fonctionnalité ou d’une interaction avec l’utilisateur � Le plus simple possible

« Projet »

ClientChef de projet

Analyste Développeur Testeur

� 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)

• 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 !

2) Répartition des rôles :

Plusieurs rôles pour une personne

� Attention aux combinaisons possibles

� Toutefois, pas de règle absolue

� S’assurer qu’une cumulation ne pousse pas à sacrifier une composante

importante d’un rôle

Plusieurs personnes pour un rôle

� Programmeur, le plus grand nombre

� Tracker, une seule personne... à un moment donné

� Coach, une personne unique

� Manager, une personne unique

� Client+Testeur, d’une personne à une équipe

IV. Les Caractéristiques de l’XP :

1) Activité cadre de XP :

i. Planification et gestion :

� É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

b. Les pratiques de l’XP

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.

2) Pratiques :

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

Organisation

Planning Game

Client sur site

Rythme Soutenable

Communication / Feedback

Métaphore

Livraisons rapides

Stand Up

Organisation Technique

Convention de nommage

Appropriation Collective du

Code

Binômage

Développement

Conception Simple

Refactoring

Intégration Continue

Testing

Tests Unitaires

Tests de recette

Organisation

Planning Game

Client sur site

Rythme Soutenable

Communication / Feedback

Métaphore

Livraisons rapides

Stand Up

Organisation Technique

Convention de nommage

Appropriation Collective du

Code

Binômage

Développement

Conception Simple

Refactoring

Intégration Continue

Testing

Tests Unitaires

Tests de recette

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

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

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.

3) Valeurs :

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

Communication

Feedback

Simplicité

Courage

Respect

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.

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é

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é.

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

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

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.

V. Autres Considérations :

1) XP et UML :

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.

2) Avantages et inconvénients :

a) Avantages :

Points forts Points faibles

- Simplicité de la mis en œuvre - Adapté aux changements

- Favorise la communication entre développeurs et développeur/client

- XP n'est pas adapté pour les équipes de développement de plus de dix

personnes - Un client doit être disponible à temps complet pour répondre aux questions

des développeurs

• 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é.

b) Inconvénients :

• 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.

• CONCLUSION

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.