REPUBLIQUE DEMOCRATIQUE DU CONGO

MINISTERE DE L’ENSEIGNEMNT SUPERIEUR UNIVERSITAIRE

INSTITUT SUPERIEUR, TECHNIQUES DE GESTION ET DE DEVELOPPEMNENT

I.S.T.GE.D

PROVINCE DU KONGO CENTRAL

TRAVAIL PRATIQUE DE PROJET INFORMATIQUE SUR

METHODE XP
TP N° 2

Présenté par :
MBAKIDI-PAUL Emeraude
L3 SYSTEME INFO

Demandé par : Ass Ir Francis LUMINGU

ANNEE ACADEMIQUE 2023-2024

 TRAVAIL PRATIQUE N°3
SUJET : CE QUOI UNE METHODE XP EN INFORMATIQUE ?
DEF : Un XP en informatique (de l'anglais : Extreme Programming) est un ensemble de pratiques
agiles et collaboratives de développement de logiciels. Il s'agit d'une méthode d'ingénierie de logiciels
qui met l'accent sur la collaboration, la livraison fréquente de fonctionnalités, la rétroaction immédiate
et la qualité. Les pratiques clés de l'XP incluent :

1. Les sprints : des périodes de développement courtes, généralement d'une à quatre semaines, au cours
desquelles l'équipe travaille sur une fonctionnalité spécifique.

2. La programmation pairée : une pratique dans laquelle deux développeurs travaillent ensemble sur un
même code en même temps.

3. La rétroaction immédiate : l'équipe teste et valide les changements apportés au code dès leur
création, ce qui permet de détecter et de corriger rapidement les erreurs.

4. La documentation living : au lieu de générer de la documentation séparée, l'équipe documente les

fonctionnalités directement dans le code.

5. La programmation en test : l'équipe écrit des tests unitaires et d'intégration pour vérifier que le code
fonctionne correctement avant et après chaque sprint.

L'objectif de l'XP est de fournir une meilleure qualité de logiciel en réduisant le temps de
développement et en améliorant la communication et la collaboration entre les membres de l'équipe.
 INTRODUCTION

XP est l'un des principaux représentants d'une famille émergente de processus : les processus dits "agiles", qui
se démarquent des démarches traditionnelles en mettant l'accent sur le travail d'équipe et la réactivité. L'heure
est à l'économie et à l'efficacité : « Quelles activités pouvonsnous abandonner tout en produisant des logiciels de
qualité ? ». Ou encore : « Comment mieux travailler avec le client pour nous focaliser sur ses besoins les plus
prioritaires et être aussi réactifs que possible ? »

XP propose une réponse originale à ces questions, avec un ensemble de pratiques organisées autour des
principes suivants :

Le client (maîtrise d'ouvrage) pilote lui-même le projet, et ce de très près grâce à des cycles itératifs
extrêmement courts (1 ou 2 semaines).

L'équipe livre très tôt dans le projet une première version du logiciel, et les livraisons de nouvelles versions
s'enchaînent ensuite à un rythme soutenu pour obtenir un feedback maximal sur l'avancement des
développements.

L'équipe s'organise elle-même pour atteindre ses objectifs, en favorisant une collaboration maximale entre ses
membres.

L'équipe met en place des tests automatiques pour toutes les fonctionnalités qu'elle développe, ce qui garantit au
produit un niveau de robustesse très élevé.

Les développeurs améliorent sans cesse la structure interne du logiciel pour que les évolutions y restent faciles
et rapides.

L'objectif de ce dossier est de donner une vision d'ensemble des principes et des pratiques d'XP, en commençant
par ce qui fait son agilité : l'ouverture au changement.

II. Ouverture au changement▲

Les démarches traditionnelles, basées sur la fameuse séquence « spécification > conception > réalisation >
validation », concentrent la plupart des décisions en début de projet :

L'objectif de cette approche est louable : le client veut des garanties sur ce qu'il obtiendra en fin de projet, et le
chef de projet souhaite disposer des informations nécessaires à l'organisation de son équipe.

Malheureusement, les équipes qui évoluent dans un environnement changeant ou complexe savent à quel point
il est difficile de s'en tenir aux décisions initiales. Le client réalise que ses besoins ont changé, ou bien l'équipe
découvre en phase d'implémentation des erreurs de spécification ou de conception qui compromettent les plans
de développement. Le changement s'impose donc tôt ou tard, mais voilà : cette organisation suppose l'absence
de changement, et celui-ci se révèle bien vite très coûteux - suffisamment parfois pour compromettre la
rentabilité du projet.

Mais puisque le changement est une composante incontournable de tout projet de développement logiciel,
pourquoi ne pas l'accepter ? N'existe-t-il pas un moyen pour que les équipes de développement n'opposent plus
de rigidité excessive aux demandes de leur maîtrise d'ouvrage ?

Les créateurs d'XP ont trouvé une réponse à ces questions en découvrant que certaines pratiques d'organisation
d'équipe et de programmation, appliquées ensemble, permettent de rendre le logiciel extrêmement malléable - à
tel point qu'il devient plus avantageux de le faire évoluer progressivement que de chercher à le spécifier et le
concevoir complètement dès le départ. Partant de ce constat, ils ont conçu une démarche qui diffuse le processus
de décision tout au long du projet grâce à l'enchaînement de cycles itératifs très courts :
Le grand gagnant de cette démarche est d'abord le client du projet. Plutôt que de voir son intervention cantonnée
à la phase initiale de recueil du besoin, il intègre véritablement le projet pour en devenir le pilote. A chaque
itération, il choisit lui-même les fonctionnalités à implémenter, collabore avec l'équipe pour définir ses besoins
dans le détail, et reçoit une nouvelle version du logiciel qui intègre les évolutions en question.

Cette démarche présente de nombreux avantages en termes de conduite de projet :

Le client jouit d'une très grande visibilité sur l'avancement des développements.

Le client utilise le logiciel lui-même comme support de réflexion pour le choix des fonctionnalités à
implémenter - il peut en particulier intégrer très tôt les retours des utilisateurs pour orienter les développements
en conséquence.

La première mise en production du logiciel intervient très tôt dans le projet, ce qui avance d'autant le moment à
partir duquel le client peut en tirer des bénéfices.

L'ordre d'implémentation des fonctionnalités n'est pas guidée par des contraintes techniques, mais par les
demandes du client. Celui-ci peut donc focaliser les efforts de l'équipe sur les fonctionnalités les plus
importantes dès le début du projet, et ainsi optimiser l'utilisation de son budget.

La démarche itérative d'XP est donc son principal atout du point de vue de la maîtrise d'ouvrage. Elle est
présentée plus en détail dans les sections qui suivent.

III. Le cycle de développement XP▲

L'Extreme Programming vise une réduction significative de la durée du cycle de développement, c'est-à-dire du
temps qui s'écoule entre le moment où l'on décide d'implémenter une fonctionnalité et celui où l'on met en
production une nouvelle version du logiciel qui intègre la fonctionnalité en question.

Dans un projet XP, ce temps correspond exactement à la durée d'une itération, c'est-à-dire typiquement deux
semaines. Chaque itération reprend la structure suivante :

Le premier jour de l'itération est consacré à la réunion de planification, au cours de laquelle le client et l'équipe
conviennent de ce qui doit être implémenté au cours de l'itération. A la fin de cette journée, l'équipe dispose de
la liste précise des tâches à réaliser.

Ensuite, l'équipe s'organise pour réaliser les tâches en question. Elle prend en charge le suivi des tâches, ainsi
que les activités d'analyse du besoin, de conception, d'implémentation et de test correspondantes. Il est
important de noter qu'il n'y a pas de changement de cap intermédiaire : l'équipe se focalise sur son objectif sans
interruption jusqu'à la fin de l'itération.
Au terme des deux semaines, l'équipe met une nouvelle version du logiciel à disposition du client. Ce logiciel
est robuste, testé, et sa structure interne est laissée aussi propre que possible pour que les prochaines évolutions
y restent peu coûteuses.

Cette organisation extrêmement réactive impose de nouvelles contraintes sur le fonctionnement de l'équipe,
susceptibles de mettre en défaut les pratiques traditionnelles du développement logiciel. Par exemple :

Puisque le contenu fonctionnel du produit ne se décide précisément qu'au fur et à mesure des itérations, il n'est
plus judicieux de faire reposer l'implémentation sur une conception définie en début de projet. Dans une
démarche purement itérative, l'équipe doit être capable de faire émerger la conception tout au long du
développement pour suivre les directions données par le client.

En termes d'organisation d'équipe, il n'est plus judicieux de séparer l'application en modules réservés à tel ou tel
développeur puisque pour une itération donnée rien n'empêche le client de demander des fonctionnalités
centrées sur un seul module. Tous les développeurs doivent donc être en mesure de travailler sur toute
l'application.
XP apporte des solutions concrètes à ces problématiques, avec un ensemble de pratiques qui forme un système
cohérent et efficace.

IV. 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 automatisés, les livraisons fréquentes ou
encore les relectures de code.

La première nouveauté d'XP consiste à pousser ces pratiques à l'extrême (d'où le nom de la méthode), ou
comme le disent ses auteurs "tourner tous les boutons jusqu'à 10 !" L'équipe utilise des cycles de développement
d'une ou deux semaines, les développeurs écrivent des tests unitaires pour chaque classe, ils se livrent à une
relecture de code permanente via le travail en binômes, etc.

La seconde nouveauté d'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.

2. DEVELOPPEMENT

Le développement sur la méthode XP en informatique est une approche agile de la conception et du

développement de logiciels qui met l'accent sur la collaboration, la flexibilité et la rapidité. Elle est divisée en
plusieurs principes clés, tels que les tests d'intégration, les réunions de code, les paires de programmeurs, les
réunions de design et le travail collatéral. Ces principes sont décrits dans le livre fondateur "Extreme
Programming Explained: Embrace Change" de Kent Beck.
Le livre présente une méthode structurée pour le développement de logiciels qui favorise l'adaptation aux
changements et l'amélioration continue. Il propose une approche collaborative qui implique tous les acteurs
impliqués dans le projet, du développeur au client. Les tests d'intégration sont utilisés pour vérifier que chaque
élément du logiciel fonctionne correctement en tant que partie intégrante du système global. Les réunions de
code et les paires de programmeurs encouragent la collaboration et l'échange d'idées pour résoudre les
problèmes et améliorer le code.
Les réunions de design sont utilisées pour définir les fonctionnalités et l'architecture du logiciel, tandis que le
travail collatéral implique la documentation et la gestion des problèmes. L'approche XP encourage également la
mise en œuvre immédiate des fonctionnalités, ce qui permet d'obtenir des retours utilisateurs rapidement et de
faire évoluer le logiciel en fonction des besoins.
En résumé, la référence bibliographique la plus connue sur la méthode XP en informatique est "Extreme
Programming Explained: Embrace Change" de Kent Beck. Ce livre présente une approche structurée et
collaborative pour le développement de logiciels, qui met l'accent sur la flexibilité, la rapidité et l'adaptation aux
changements.

3. CONCLUSION

Nous mettons en œuvre ces pratiques XP depuis bientôt trois ans dans le cadre d'un grand projet télécom (4), et
les bénéfices de cette démarche nous semblent indéniables :

L'approche itérative nous a permis d'améliorer progressivement le produit dans son ensemble, et nous recevons
aujourd'hui d'excellents retours des clients finaux.

Les développeurs apprécient cette démarche, et les équipes sont jugées très réactives par leurs interlocuteurs.
Nous disposons aujourd'hui d'une batterie de plus de 11.000 tests, grâce auxquels le nombre de « bugs » du
produit est resté très bas.

Notre activité d'amélioration permanente de la conception nous a permis de positionner une partie de l'outil en
tant que Framework utilisé par d'autres équipes de la société.

Bien entendu, tout n'est pas complètement rose. Nous mettons en œuvre l'ensemble des pratiques « internes »
d'XP, celles qui concernent le travail de l'équipe, mais nous avons des difficultés à progresser sur les parties
liées au rôle du client et du testeur - et pour cause, ces rôles sont pris en charges par d'autres équipes, ce qui
exige de notre part un effort d'évangélisation de longue haleine.

Nous avons pu également noter la grande sensibilité de la méthode à l'entente des membres de l'équipe. Cela
impose des contraintes sur le recrutement, et cela peut également nécessiter des remaniements de l'équipe en cas
de dysfonctionnement.

D'une manière générale, nous avons constaté que la mise en œuvre d'XP apportait des résultats indéniables, mais
au prix d'efforts eux aussi indéniables lors de la phase de transition. Une fois la transition effectuée, cependant,
XP se présente comme un processus simple et naturel, qui offre une productivité nettement accrue par rapport à
ce que nous avions connu jusque-là.

Cette difficulté de transition explique certainement pourquoi XP reste encore confidentiel en France. Nous
avons eu ainsi des retours d'équipes ayant essayé « XP mais sans les tests unitaires », ou encore « XP mais sans
le travail en binômes », avant de revenir à leur mode de fonctionnement initial quelques semaines plus tard.

Il faudra donc une impulsion particulière pour que XP se développe davantage dans notre pays. Nous pensons
que cette impulsion viendra de deux directions complémentaires : d'abord des developpeurs eux-mêmes, qui
auront compris en quoi XP constitue une façon plus naturelle et plus efficace de travailler, et ensuite des
maîtrises d'oeuvre, maîtrises d'ouvrage et sociétés de service « visionnaires » qui auront réalisé que ce processus
représente aujourd'hui un réel avantage compétitif dans un monde où l'adaptation au changement est un facteur
primordial de succès.

Les avantages et les inconvénients

Avantages et inconvénients de la méthode XP (eXtreme Programming)

Extreme Programming apparaît comme la plus radicale des méthodes agiles.

Cette méthode se révèle particulièrement efficace dans le cadre de petits projets. XP réalise des applications de
qualité grâce à la rigueur imposée sur les tests, qui plus est collent aux désirs du client puisque celui-ci est
intégré au projet de A à Z.
Aussi efficace qu’elle soit, la méthode XP n’est pas applicable dans tous les cas. Dans le cadre d’un projet de
type forfaitaire où le prix, les délais et les besoins sont fixés, XP ne peut pas réellement être mise en œuvre. Le
cas d’une équipe supérieure à une douzaine de personnes est un autre exemple où XP est difficilement adaptable
car le nombre risque de ralentir, d’alourdir les procédures et de rendre la communication plus difficile et moins
efficace.

Enfin, XP est sans doute une des plus contraignantes des méthodes agiles, aussi bien pour le client que pour les
développeurs. En effet, l’investissement demandé au client est très important puisqu’il doit déléguer une
personne à temps plein sur le lieu où est développée l’application, avec toutes les conséquences que cela induit.
En ce qui concerne les développeurs, la pratique de la programmation en binôme n’est pas forcément très bien
ressentie par tous. Or un projet XP ne peut pas être un franc succès si tous ses participants n’adhèrent pas
pleinement à la méthode. Avant de se lancer dans un tel projet, il faudra tout d’abord convaincre le client et
motiver l’équipe ce qui n’est pas toujours aisé.

Avantages :

– Rapidité
– Réactivité
– Productivité
– Compétence
– Légèreté

Inconvénients :

– Maintenance
– Blocage culturel
– Limite de taille
-Documentation et communication

La façon classique de travailler en génie du logiciel favorise grandement la production de documentation

(document de vision, de spécification, d’assurance qualité, de « configuration management », de métriques,
etc.). Ainsi, ce concept est très difficile à accepter dans le domaine du génie Logiciel.

Le fait d’avoir le client en permanence sur le site de développement est très exigent et difficile à réaliser pour
celui-ci. Ce n’est pas n’importe quelle compagnie qui est prête à sacrifier une personne à plein temps.

L’emphase sur la communication est un point très important qui favorise le bon développement d’un système
adapté. « Plusieurs têtes valent mieux qu’une ! »

Ainsi le travail par paire (le pair programming) oblige les développeurs à bien comprendre leur code. Ils doivent
être en mesure de pouvoir expliquer ce qu’ils font à leur paire. Mettre tous les programmeurs dans même pièce à
aire ouverte est une très bonne idée qui permet une bonne communication. Fini les développeurs qui codent
chacun dans leur coin.

Bien que le programmeur soit un peu réticent à accepter que le code qu’il fait ne lui appartient pas et que
n’importe quel autre développeur à la permission de le modifier durant le projet, il y a cependant beaucoup de
points positifs à cette méthode.

Un autre point important est l’abolition des heures supplémentaires. Souvent le problème du temps
supplémentaire se fait sentir dans les équipes de développements. Selon la prémisse de XP, il ne doit pas avoir
de semaine dépassant largement 40 heures d’ouvrage. En effet, c’est un point très important et qui permet
d’avoir une bonne santé mentale et une vie sociale !

La communication sans délais avec le client, bien que demandant pour le client est très bon pour les
développeurs. Ceux-ci ont besoin à plusieurs reprises d’avoir des réponses à leurs questions pour le bon
déroulement du système.

Les tests sont aussi sans contre doute une nécessité. Autant les tests unitaires que les test de régression, cela doit
être une pratique courante pour les développeurs. Classiquement lors de conception de logiciel l’habitude
consiste à faire des tests à la fin du cycle de développement. Cela fait perdre beaucoup de temps, d’argents et ne
doit pas être une pratique courante.

Un autre point très intéressant, est de dégager la documentation non nécessaire pour les développeurs comme
étant un requis du client et non une nécessité. En fait, plus souvent qu’autrement le développeur se retrouve à
faire de la documentation à plein temps sur un logiciel qu’il développe ou qu’il doit développer. Souvent cette
documentation ne sera jamais utilisée par les programmeurs. Donc, le fait de charger au client pour cette
documentation extra de la même façon que pour de fonctionnalités logicielles est selon moi une bonne pratique.

Le changement

La méthode XP permet au client de modifier ses spécifications en cours de route. Très utile lorsque le client n’a
pas une idée ferme car il peut changer l’orientation que prend le projet à n’importe quel moment. Cela reflète
plus la réalité que ce qui se fait chez les autres pratiques connues. Souvent lorsque le client décide de changer
quelques fonctionnalités en cours de route : plusieurs documents doivent être modifiés, l’architecture doit être
repensé, etc. Enfin tout un processus qui selon moi est très lourd se met en place et coûte très cher au client. XP
par sa méthodologie logicielle allégée destinée à réduire le coût du logiciel est plus adapté à ce type de
modification lors du développement du système

La productivité

La pratique XP est conçue pour une équipe de 2 à 10 personnes. Cela permet aux développeurs de bien
connaître l’ensemble du projet qu’ils développent et aussi d’avoir une belle synergie au sain de leur équipe de
développement.

En plus, elle favorise la productivité des développeurs car ils doivent toujours être alerte aux différentes
questions de leurs pairs concernant le code qu’ils sont en train de faire. Comme le nom de cette méthodologie
peu le laisser sous-entendre, « eXtrème Programming » elle pousse le développeur à l’extrême et l’oblige à
donner sont « 110 pour cent. »

La livraison régulière des versions permet de motiver le client et le développeur. Tout le monde est en mesure
de voir l’évolution du système. Le client peu enfin suivre cette évolution pendant que les développeurs bâtissent
le logiciel. Ils n’ont plus à attendre des mois avant de voir leur logiciel en production. Chaque itération dure de
1 à 4 semaines ce qui donne un haut taux de « feedback ». Cela permet d’avoir assez rapidement des
commentaires de la part du client. Ce processus permet d’avoir du code dynamique et continuellement en
changement. Quiconque est en présence d’un bout de code très compliqué est encouragé et en mesure de le
simplifier. Finalement, l’intégration du code plusieurs fois par jour force les développeurs à communiquer et à
bien comprendre le fonctionnement et le processus de développement du système qu’ils bâtissent.

Le « eXtreme Programming » est une méthode qui ne propose rien de nouveau. Toutes les techniques utilisées
sont déjà connues (utilisation de standards, utilisation des tests unitaires, utilisation de tests de régression, bonne
communication, etc.).

Ce qui est très difficile à accepter dans les processus de XP est :

1. De ne pas documenter le code ;

2. De ne pas avoir de documentation externe ;
3. De dire que les tests unitaires sont plus importants que le code en soit.

Néanmoins la méthode XP (eXtreme Programming) est une méthode ayant de l’avenir et qui devrait s’appliquer
à tous les petits projets où le client n’est pas totalement sûr de ce qu’il veut.
One Response to “Avantages et inconvénients de la méthode XP (eXtreme Programming)”
A l'Ecole de la V.I.E. » Agile et l’eXtreme Programming (XP)

REFERENCE [biblio@uqac.ca

418-545-5011 poste 5630

1-800-463-9880 poste 5630 (sans frais)
Télécopieur : 418-693-5896

Local : P2-8000

Coordonnées des services et répertoire du personnel]