Dans le cadre d'un projet de développement logiciel, le commanditaire et les développeurs se mettent d'accord sur une méthode de travail. L'eXtreme Programming (XP) est une méthode à envisager. L'XP se caractérise par des itérations courtes, centrées sur les fonctionnalités de l'application logicielle. Les développeurs ne travaillent pas sur la base d'un cahier des charges définitif : ils matérialisent des scénarios à mesure des exigences du client. L'équipe n'attend pas de finaliser l'application, elle livre successivement des portions réduites de l'application. L'efficacité de la programmation extrême est liée à la réactivité du commanditaire et des développeurs, qui doivent étroitement communiquer.
Qu'est-ce que l'eXtreme Programming ?
L'eXtreme Programming est une méthode de travail en développement logiciel. Elle se caractérise par des itérations très rapides et une collaboration étroite entre le client et les développeurs. L'XP repose sur des principes agiles, mis en pratique de manière extrêmement aboutie.
Comment fonctionne la méthode programmation extrême ?
La méthode programmation extrême fonctionne par itérations, comme toutes les méthodes agiles. Chaque cycle de développement itératif est particulièrement court.
- Un client ou un chef de projet commande une application logicielle, la tâche est assignée à une équipe de développeurs. Exemple : une entreprise de e-commerce commande une application pour sa boutique en ligne.
- Le commanditaire fournit des scénarios. Un scénario client, à la différence d'un cahier des charges fourni et strict, est une description simple et informelle d'une fonctionnalité requise. Dans l'exemple, l'entreprise fournit trois scénarios : les utilisateurs de l'application doivent pouvoir s'authentifier, payer en ligne et recevoir des notifications push ciblées.
- La phase d'exploration démarre, elle dure de quelques heures à quelques jours. L'équipe de développeurs évalue le temps de travail nécessaire pour chaque scénario, priorise les scénarios et les transforme en tâches. Une tâche doit être réalisable par un binôme de développeurs, en un à deux jours de travail. Si un scénario implique un volume de travail supérieur, il est scindé en plusieurs tâches. Dans l'exemple, le manager de l'équipe priorise le module de paiement en ligne et la fonctionnalité de notifications push. Il estime qu'un binôme peut programmer le module de paiement en deux jours : c'est une première tâche, assignée à un binôme de développeurs. La fonctionnalité de notifications requiert plus de travail : elle est scindée en deux tâches, attribuées à deux binômes.
- Chaque binôme travaille sur la tâche qui lui est assignée. Il programme la fonctionnalité et réalise les tests. Quand la fonctionnalité passe le test, elle est livrée au commanditaire.
- Le commanditaire vérifie les fonctionnalités livrées, puis fournit d'autres scénarios. Dans l'exemple, l'entreprise change ses exigences : elle n'a pas besoin d'espace d'authentification, en revanche elle souhaite une fonctionnalité de géolocalisation pour proposer aux utilisateurs de l'application les options de retrait de produits les plus adaptées.
- Un autre cycle de développement démarre.
Un nouveau cycle démarre chaque fois que le commanditaire a de nouvelles exigences, exprimées par le biais de scénarios. Le premier cycle, en pratique, est le plus long. Les itérations suivantes sont par principe plus courtes : les fonctionnalités avancées et les mises à niveau sont livrées à un rythme très soutenu.
Quand utiliser l'eXtreme Programming ?
Kent Beck, inventeur de la méthode, explicite les raisons d'être de l'eXtreme Programming dans la préface de son ouvrage Extreme Programming Explained : Embrace Change paru en 1999. La méthode s'adresse aux petites et moyennes équipes de développeurs, qui ont affaire à des clients aux exigences vagues ou très changeantes.
- Avec l'eXtreme Programming, le commanditaire n'a pas besoin d'avoir une vision parfaitement claire de son projet dès la commande. Il l'affine au fur et à mesure des livraisons.
- Grâce à l'eXtreme Programming, le projet évolue à mesure qu'il se concrétise. C'est l'opportunité pour le commanditaire de demander des changements fréquents, au gré de ses idées.
- L'eXtreme Programming est très adapté lorsque le niveau de connaissances techniques du client est faible. Les scénarios en effet sont décrits à l'aide de métaphores, le jargon technique est superflu.
Mise en place de la programmation extrême
La programmation extrême se fonde sur cinq principes :
- La communication entre les développeurs, et avec le commanditaire.
- La simplicité pour décrire les scénarios et pour coder les fonctionnalités.
- Le retour d'information, ou feedback, à l'occasion des tests.
- Le courage des développeurs face aux modifications requises par le commanditaire.
- Le respect au sein de l'équipe, un principe ajouté dans la seconde version de l'ouvrage de Kent Beck.
Ces principes paraissent évidents. La particularité de l'eXtreme Programming est de les pousser à l'extrême. Cela se matérialise lors de la mise en place de la programmation eXtreme.
1 - Planification des ressources
La mise en place de la programmation extrême nécessite une phase préalable de planification des ressources. Il s'agit d'organiser les modalités du travail, en poussant à l'extrême les principes de communication, de simplicité et de respect. L'eXtreme Programming suggère à cet effet de bonnes pratiques.
- Commanditaire sur site : le client ou le chef de projet est toujours disponible pour l'équipe de développeurs.
- Jeu du planning, ou « planning game » : à chaque itération, le commanditaire fournit des scénarios simples. L'enjeu porte ici sur la rapidité. Kent Beck, à cet égard, écrit en substance que « si les itérations courtes sont bénéfiques, nous allons les rendre très, très courtes : en secondes, minutes ou heures, et non en semaines, mois ou années ».
- Utilisation de métaphores : la communication est facilitée lorsque les développeurs et le client parlent le même langage.
- Programmation en binôme : le binôme est constitué d'un pilote qui écrit le code et d'un co-pilote qui le relit. Ils sont en permanence à deux devant la machine. Selon Kent Beck, « si revoir le code est bénéfique, nous allons le revoir en permanence ». La composition des binômes a vocation à changer à chaque tâche.
- Rythme soutenable : le respect de l'humain impose de préserver les membres de l'équipe. La productivité s'en ressent.
2 - Programmation et tests
En phase opérationnelle, ce sont les principes de communication et de simplicité qui sont poussés à l'extrême. L'eXtreme Programming décrit les pratiques au moment de programmer et tester les fonctionnalités du logiciel.
- Conception simple : « si la simplicité est bénéfique, nous allons opter pour la conception la plus simple dès lors qu'elle permet de supporter les fonctionnalités », écrit l'inventeur de la méthode. Les développeurs en outre se cantonnent à leur tâche, sans anticiper d'autres fonctionnalités.
- Intégration continue : dès qu'une tâche est terminée, la fonctionnalité est intégrée au logiciel.
- Appropriation collective du code : tous les développeurs de l'équipe peuvent faire des modifications sur le code. À cet effet, une convention de nommage est établie en amont pour nommer uniformément les méthodes, les variables ou encore les objets. Cette approche met en jeu le paradigme de la POO.
- Remaniement du code, ou « refactoring » : comme le code a une conception simple, le remanier est facile. Les binômes améliorent le code en permanence, à mesure des itérations.
- Test unitaire : pour chaque tâche, le binôme de développeurs teste la fonctionnalité pour garantir son fonctionnement.
3 - Livraisons
Une livraison marque le terme d'une itération. C'est le principe du retour d'information qui est mis en œuvre lors de cette phase. Le courage des développeurs est également mobilisé, face aux exigences changeantes du client. L'eXtreme Programming s'illustre par deux pratiques caractéristiques.
- Test fonctionnel : le client teste lui-même chaque fonctionnalité livrée, et fait immédiatement ses retours aux développeurs.
- Petites livraisons : chaque tâche fait l'objet d'une livraison. Comme les scénarios ont été scindés en courtes tâches, les cycles sont courts, permettant de réaliser jusqu'à plusieurs itérations par jour.
L'optimisation finale de l'application logicielle n'est effectuée qu'au terme de tous les cycles de développement itératifs. Le client peut alors introduire l'application dans son environnement d'utilisation, conformément à son plan de déploiement.
Quels sont les avantages et inconvénients de l'eXtreme Programming ?
| Avantages de l'extrême Programming | Inconvénients de l'extrême Programming |
| Rapidité : - Plusieurs résultats concrets par jour - Achèvement rapide du projet peu complexe |
Investissement important de la part du client sur site |
| Simplicité : - Tâches courtes - Exécution de chaque tâche l'une après l'autre |
Mise en œuvre pratique contraignante : - Inadapté aux grandes équipes - Nécessité d'un plateau ouvert - Entente parfaite nécessaire entre les développeurs |
| Méthode incrémentale : - Application évolutive - Adaptation aux exigences du client |
Manque de vision sur le rendu final : - Risque d'anarchie - Découragement face aux changements fréquents |
| Fiabilité : - Application testée en continu - Retours d'informations permanents |
Périmètre contractuel complexe : durée et coûts du projet difficiles à évaluer
|
| Méthode de travail « fun » selon son inventeur | Risques de blocage culturel et de résistance au changement |
eXtreme Programming vs Agile
Agile regroupe des pratiques, alors qu'eXtreme Programming désigne une méthode. L'eXtreme Programming est considéré comme une méthode agile, car l'XP respecte les principes agiles : communication, rapidité, évolutivité, simplicité, rythme soutenable et amélioration continue.
D'autres méthodes agiles de développement logiciel peuvent être envisagées, le test-driven development (TDD) et Scrum, par exemple.
eXtreme Programming vs Scrum
Scrum, pour « mêlée » en anglais, est également une méthode agile de développement logiciel. À la différence de l'eXtreme Programming, un cycle de développement Scrum ne correspond pas à une fonctionnalité mais à un temps de travail, nommé « sprint ». Le découpage du projet Scrum est temporel alors que le découpage du projet XP est fonctionnel.
Pour aller plus loin, découvrez les opportunités liées aux évolutions du web en téléchargeant le guide et la checklist du web 3.0, ou découvrez le logiciel marketing de HubSpot.
