À quoi XP aspire-t-il ?

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

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

Comment XP s’organise-t-il ?

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

Un certain nombre de pratiques et de 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. XP prend en compte ces facteurs en sous 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)
• 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 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 faciliter à 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é.
• La réfactorisation du code est une étape indispensable à la création d’un logiciel de qualité 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 du code doit pouvoir être testée.
• 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 ses tests fonctionnels sont satisfaisants pour le client.

Voilà, la liste des règles et bonnes pratiques est assez longue (il manque ici quelques éléments) mais au final, le processus offre une vision très simple :

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

Que penser d’XP ?

eXtreme Programming offre une vision intéressante de la façon dont un manager peut gérer une petite équipe projet (15-20 personnes au maximum). De plus, XP tente de répondre intuitivement aux deux grands défis lancés par les projets informatiques depuis plus de trente ans : la satisfaction client et la communication. Cependant, les pratiques XP sont-elles vraiment adaptées à nos organisations (en France) ?
Un client peut-il constamment se trouver face aux équipes techniques ? En théorie oui mais il y a une forte probabilité pour que cela ne soit pas le cas en pratique (point à méditer en intégrant la composante culturelle).
En interne, le partage du code et la possibilité de modifier la tâche d’un pair est fortement susceptible de déresponsabiliser les individus. Enfin, le développement en binôme est une pratique qui peut être stimulante mais est-elle réellement rentable pour le projet ?
Ces interrogations sont importantes sur le plan pratique mais ne peuvent remettre en cause le processus XP qui véhicule une vision moderne de la gestion des projets. Un petit approfondissement du sujet vous permettra d'en être convaincu : Extreme Programming Explained : Embrance Change

Bonne lecture :-)