Qu’est-ce que l’Extreme Programming ?

L’Extreme Programming (XP) est un processus agile conçu pour la gestion des projets de développement informatique. L'XP a été proposé par l'ingénieur américain Kent Beck au milieu des années 1990 et représente aujourd’hui l’un des plus célèbres processus agiles.

Qu’est-ce qu’un processus agile ?

Dans le cadre d’XP, la notion de processus recouvre un ensemble d’activités, de bonnes pratiques et de règles dont l’objectif est de mener à bien des développements informatiques. L'XP est qualifié d’agile car il s'appuie sur l'acceptation du changement et sur une réponse rapide à l’évolution des besoins. Cette notion de processus agile est parfois confrontée à d'autres processus qui peuvent être considérés comme un ensemble d'activités trop prescriptives et bureaucratiques. Ce n'est pas l'objet de cette brève présentation mais à ce sujet, il peut être utile de se pencher sur les nombreux débats autour d'XP et du Processus Unifié.

À quoi l'XP aspire-t-il ?

XP est un processus itératif qui se fonde sur la communication, le travail d’équipe et sur la relation client pour répondre aux objectifs suivants :

- Améliorer la satisfaction client.
- Assurer la livraison des logiciels dans les temps.
- Etre capable de répondre aux changements des utilisateurs / clients.
- Livrer un logiciel de qualité.

Comment l'XP s’organise-t-il ?

Pour tenter de répondre aux objectifs précédents, XP s’appuie sur quatre activités principales :

1. La planification
2. Le codage
3. La conception
4. Les tests

Un certain nombre de pratiques et règles composent chacune de ces activités.
L’activité de planification a pour objectif de définir un plan global du projet, ce dernier étant formé d’une dizaine d’itérations de 1 à 3 semaines. Dans les grandes lignes, ce plan prend en compte :

- Les besoins des utilisateurs, qui sont rédigés dans des User Stories. La finalité des User Stories est comparable à celle des Use Cases d’UML.
- Le produit intermédiaire à livrer suite à chaque itération.
- La définition des itérations. A chaque début d’itération, une petite réunion doit permettre d’établir le travail à réaliser et d’intégrer les éventuels changements. C’est seulement à chaque début d’itération que l’équipe décide des tâches qui seront programmées.
- Cette réunion inclut également la révision du planning des itérations. Un changement dans les besoins ou une difficulté inattendue peut bousculer un planning. L'XP prend en compte ces facteurs en se plaçant sous l’hypothèse qu’il n’est pas possible de fixer le travail qui sera réalisée dans deux ou trois itérations. Une vision sage, pragmatique et réaliste, sous certaines conditions.
- La prévision de courtes réunions quotidiennes. Ces réunions sont informelles et peuvent se dérouler debout, à proximité des machines, de façon à impliquer tous les développeurs.
- L’éventuel abandon de règles qui ne fonctionnent pas ou qu’une partie de l’équipe ne comprend pas. Les règles préconisées par l'XP ne doivent en aucun cas constituer un frein au développement du projet.

L’activité de codage comprend les pratiques suivantes :

- La création de tests unitaires. Le test unitaire est l’une des pierres angulaires d’XP. Ces tests doivent être créés et automatisés à l’aide d’outils dédiés aux tests, tels que Visual Studio Team Test ou JUnit. Les tests doivent s’appliquer à toutes les classes de l’application et il est fortement conseillé de les créer en premier, avant le code.
- L’utilisation de standards de codage (meilleures pratiques).
- Le travail en binôme. XP considère que deux développeurs sur une même machine produiront un résultat final de meilleure qualité et auront plus de facilités à intégrer les fonctionnalités du logiciel.
- La phase d’optimisation n’a lieu qu’une fois que l’application finale est terminée.
- Chaque classe peut porter le nom de son créateur afin de faciliter la phase d’intégration et de mise à jour. XP préconise également de faire appel à une équipe d’intégration.
- Les développeurs ne doivent pas faire d’heures supplémentaires (et ce n’est pas une blague !). Le travail supplémentaire mine le moral de l’équipe et ne permet pas de terminer un projet à l’heure.
- Chaque membre de l’équipe doit s’approprier l’ensemble du logiciel en cours de développement. Un développeur créé des morceaux de code qui peuvent être modifiés (correction d’un bug, amélioration d’une idée, ajout d’une fonctionnalité, etc.) par ses collègues.
- Le client ou futur utilisateur du logiciel doit être disponible. Tout au long du processus, l’équipe doit pouvoir communiquer avec le client. En particulier, au début de chaque itération, le client doit pouvoir apporter les détails qui seront nécessaires à la réalisation de l’itération. En fin d’itération, suite à la livraison d’une version intermédiaire du produit, le feedback client est également indispensable.

L’activité de conception prend en compte les pratiques suivantes :

- Privilégier la simplicité à la complexité. Lorsqu’il est possible d’implanter deux solutions, toujours choisir la solution la moins complexe. Une solution simple est toujours moins coûteuse, plus rapide à mettre en place et plus simple à modifier.
- Communiquer avec le monde fonctionnel via l’utilisation de métaphores afin de favoriser la compréhension entre les parties prenantes.
- Ne jamais rajouter des fonctionnalités trop tôt ou qui n’ont pas été exigées par le client. C’est une perte de temps inutile qui bouscule le planning et qui réduit le potentiel de flexibilité.
- Indispensable à la création d’un logiciel de qualité, la réfactorisation du code est une étape qui doit se reproduire tout au long du projet. La réfactorisation consiste à affiner le code déjà créé en éliminant les parties redondantes et fonctionnalités inutilisées, et en retouchant éventuellement certaines parties susceptibles de simplifier l’architecture du logiciel.

Enfin, l’activité de test inclut les règles suivantes :

- Nous l’avons déjà évoqué plus haut, tout morceau de code doit pouvoir être testé.
- Un code qui ne passe pas un test avec succès est un code qui ne doit pas être mis en production.
- La découverte d’un bug entraîne systématiquement la création d’un test visant à le corriger.
- La création de tests fonctionnels créés à partir des spécifications fonctionnelles (les User Stories) représente l’un des fondements  d’XP. Ces tests permettent d’impliquer le client dans le projet puisqu’il a la responsabilité de valider l’exactitude des tests fonctionnels. Les tests fournissent-ils le résultat escompté ? Si oui, les résultats sont-ils satisfaisants ? Un User Story ne peut être validé que lorsque ces tests fonctionnels sont satisfaisants pour le client.

La liste des règles et bonnes pratiques peut sembler longue (la list suivante n'est pas exhaustive) mais au final, le processus offre une vision plutôt pragmatique :

1. Le client et l’équipe technique se mettent d’accord sur les grandes lignes du projet à réaliser. La communication est simplifiée via l’usage de métaphores pour définir les différents concepts techniques.
2. Le client et l’équipe technique rédigent les spécifications fonctionnelles (User Stories) de façon non détaillée.
3. L’équipe technique définie un planning pour l’ensemble des itérations, en prenant en compte les User Stories.
4. Le travail de la première itération est défini puis celle-ci est lancée. Le développeur et les utilisateurs communiquent en face-à-face pour obtenir une vision plus fine des User Stories.
5. Les développements, tests et débogages sont réalisés.
6. Une version intermédiaire du produit est livrée au client.
7. Le client contrôle/valide les tests fonctionnels et fournit un feedback sur la version intermédiaire livrée.
8. Quel que soit le résultat, la seconde itération est lancée. Celle-ci se précède d’une réunion qui consiste à valider le travail réalisé, à prendre en compte les difficultés rencontrées et à modifier le planning des itérations si nécessaire.

Les itérations se succèdent jusqu’à ce que le produit final soit livré.

Pour en savoir plus : Extreme Programming Explained : Embrace Change

Claude-Olivier Fontaine

Date de publication : vendredi 23 novembre 2007