Extreme programming - Définition

Introduction

L'Extreme Programming (XP) est une méthode agile de gestion de projet informatique adaptée aux équipes réduites avec des besoins changeants. Elle pousse à l'extrême des principes simples.

Origine

L'Extreme Programming a été inventée par Kent Beck, Ward Cunningham et Ron Jeffries pendant leur travail sur un projet « C3 » de calcul des rémunérations chez Chrysler. Kent Beck, chef de projet en mars 1996 commença à affiner la méthodologie de développement utilisée sur le projet. La méthode est née officiellement en octobre 1999 avec le livre Extreme Programming Explained de Kent Beck.

Cycle de développement

Le cycle de l'Extreme Programming

L'Extreme Programming repose sur des cycles rapides de développement (des itérations de quelques semaines) dont les étapes sont les suivantes :

• une phase d'exploration détermine les scénarios clients qui seront fournis pendant cette itération ;
• l'équipe transforme les scénarios en tâches à réaliser et en tests fonctionnels ;
• chaque développeur s'attribue des tâches et les réalise avec un binôme ;
• lorsque tous les tests fonctionnels passent, le produit est livré.

Le cycle se répète tant que le client peut fournir des scénarios à livrer. Généralement le cycle de la première livraison se caractérise par sa durée et le volume important de fonctionnalités embarquées. Après la première mise en production, les itérations peuvent devenir plus courtes (une semaine par exemple).

Pratiques extrêmes

Dans le livre Extreme Programming Explained, la méthode est définie comme :

• une tentative de réconcilier l´humain avec la productivité ;
• un mécanisme pour faciliter le changement social ;
• une voie d'amélioration ;
• un style de développement ;
• une discipline de développement d´applications informatiques.

Son but principal est de réduire les coûts du changement. Dans les méthodes traditionnelles, les besoins sont définis et souvent fixés au départ du projet informatique ce qui accroît les coûts ultérieurs de modifications. XP s´attache à rendre le projet plus flexible et ouvert au changement en introduisant des valeurs de base, des principes et des pratiques.

Les principes de cette méthode ne sont pas nouveaux : ils existent dans l'industrie du logiciel depuis des dizaines d'années et dans les méthodes de management depuis encore plus longtemps. L'originalité de la méthode est de les pousser à l'extrême :

• puisque la revue de code est une bonne pratique, elle sera faite en permanence (par un binôme) ;
• puisque les tests sont utiles, ils seront faits systématiquement avant chaque implantation ;
• puisque la conception est importante, elle sera faite tout au long du projet (refactoring) ;
• puisque la simplicité permet d'avancer plus vite, nous choisirons toujours la solution la plus simple ;
• puisque la compréhension est importante, nous définirons et ferons évoluer ensemble des métaphores ;
• puisque l'intégration des modifications est cruciale, nous l'effectuerons plusieurs fois par jour ;
• puisque les besoins évoluent vite, nous ferons des cycles de développement très rapides pour nous adapter au changement.

Environnements défavorables

En lieu et place d'inconvénient de la méthode, on parlera plus aisément d'environnements défavorables dans lesquels la méthode XP n'est pas applicable. Dans ce cas, seule une partie des pratiques peut être réalisée. Les principaux contextes défavorables sont :

• un blocage culturel : quand le client ou les développeurs ont l'habitude de fonctionner autrement. L'ingénieur à qui l'on attribue des mini-tâches quotidiennes et qui doit les réaliser avec un binôme peut avoir le sentiment que sa fonction est déqualifiée. Son principal rôle n'est plus d'être force de proposition, mais bel et bien de produire et d'accroitre sa productivité (Taylorisme, Fordisme). Une telle vision peut en effet provoquer un blocage culturel qui peut conduire à un turn-over important.

• une équipe de vingt développeurs ou plus car la communication devient difficile : Il est fréquent de voir au fil du temps des binômes travailler toujours ensemble, toujours sur les mêmes sujets, et former ainsi des sous-équipes spécialisées, ce que ne veut pas XP. Par ailleurs, les évolutions possibles dans l'entreprise sont très limitées dans la mesure où tous les membres de l'équipe jouent tous les mêmes rôles.

• un coût de changement exponentiel car « XP nécessite du code propre et simple » ;

• un feedback long ou difficile à obtenir : le retour sur investissement est visible sur le moyen/long terme.

• un aménagement qui empêche la communication ou la programmation en binôme (il est nécessaire d'avoir une infrastructure open-space).

• respect d'une discipline collective et travail en binôme au quotidien : cette méthode ne peut pas être appliquée avec n'importe qui, car elle dégage très peu de temps à l'autonomie et au travail individuel, dans la mesure où systématiquement le travail se fait à deux sur un même poste de travail. Les développeurs auront de la difficulté à établir un projet professionnel dans leur entreprise.

• la résistance au changement.