eXtreme Programming
Extrait du billet eXtreme
Programming
Qu’est-ce que l’eXtreme Programming ?
L’eXtreme Programming (XP) est un processus
agile pour la gestion des projets de développement logiciel. XP
a été créé au milieu des années 1990 par Kent Beck et représente aujourd’hui
l’un des plus célèbres processus agile.
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 méthodes (ou règles) dont l’objectif est de mener à bien
le développement des logiciels. XP est qualifié d’agile car il est conçu de
façon à accepter le changement et à répondre rapidement à l’évolution des
besoins. Cette notion de processus agile s’oppose à celle de processus « lourd »
tel que le Processus Unifié (ou UP pour Unified Process). Lourd, dans
le sens où certains processus proposent un grand nombre d’activités qui ne sont
pas toujours adaptées à toutes les situations.
|
Vous entendrez parfois parler de méthode agile au lieu de processus
agile. Il ne me semble pas très rigoureux d’employer la première expression dans
une présentation d’eXtreme Programming. L’expérience prouve que la notion de
méthode constitue un véritable fourre-tout lorsqu’on tente de l’appliquer aux
domaines de l’informatique. On entend par exemple parler de méthode pour faire
référence à un langage (UML), ou pour désigner un recueil des meilleures
pratiques de gestion (ITIL, CobiT). Peut-on confondre les notions de processus
et de méthode ? Dans le cadre de l’informatique de gestion cela ne semble pas
vraiment cohérent dans la mesure où un processus ne fait que fournir un cadre
organisationnel. L’organisation en elle-même et le contrôle, autrement dit la
méthode, ne peuvent être qu'un intrinsèques à l’entreprise, à la culture et aux
managers.
|
À 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 :
1. La
planification.
2. Le
codage.
3. La
conception.
4. Les
tests.
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 :
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étaphore pour définir
les différents concepts techniques.
2. Le client
et l’équipe technique rédigent les spécifications fonctionnelles, ou User
Stories, de façons non détaillées.
3. L’équipe
technique définie un planning pour l’ensemble des itérations, en prenant en
compte les User Stories rédigés au point 2.
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
valide (ou non) 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é.
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
Claude-Olivier Fontaine - Vendredi 23 Novembre 2007
|