Extreme programming

L’extreme programming (ou XP), en français « la programmation extrême », est une méthode agile de génie logiciel privilégiant l'aspect réalisation d'une application, sans pour autant négliger l'aspect gestion de projet. Elle pousse à l'extrême des principes simples, d'où son nom.

La programmation poussée à l'extrême est adaptée aux équipes réduites ayant des besoins changeants.

Origine

La programmation extrême 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éthode de développement utilisée sur le projet. Celle-ci est née officiellement en octobre 1999 avec la parution du livre Extreme Programming Explained de Kent Beck.

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. La programmation extrême vise à 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 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 :

• la revue de code sera faite en permanence (par un binôme) ;
• les tests seront faits systématiquement avant chaque mise en œuvre ;
• le code sera retravaillé tout au long du projet (refactoring ou remaniement du code) ;
• la solution la plus simple sera toujours celle qui sera retenue ;
• des métaphores seront définies et évolueront en concomitance ;
• les modifications seront faites plusieurs fois par jour ;
• des cycles de développement très rapides faciliteront l'adaptation au changement.

Cycle de développement

Le cycle de l'Extreme Programming.

La programmation extrême 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 « client » 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 le produit satisfait aux tests fonctionnels, il est livré.

Le cycle se répète tant que le client peut fournir des scénarios à livrer. Généralement le cycle qui précè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).

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 s'appliquer. 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’accroître sa productivité (Taylorisme, Fordisme). Une telle vision peut en effet provoquer un blocage culturel qui peut conduire à une rotation importante ;
• 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.

Voir aussi

Articles connexes

• Méthode agile
• Cycle de développement (logiciel)
• Scrum
• Test Driven Development

Bibliographie francophone

• Jean-Louis Bénard, Laurent Bossavit, Régis Médina et Dominic Williams, L'Extreme Programming : Avec deux études de cas, Paris, Eyrolles, 2002, 298 p. (ISBN 2-212-11051-0), nouvelle édition du même ouvrage sous le nom Gestion de projet eXtreme Programming (ISBN 2-212-11561-X)
• Thierry Cros, Maîtrisez les projets avec l'Extreme Programming, Toulouse, Cépadues éd., 2004, 186 p. (ISBN 2-85428-639-1)

• Jean-Pierre Vickoff, Méthode Agile, Les meilleures pratiques, Compréhension et mise en œuvre, QI, 2009 (ISBN 978-2912843074)

Bibliographie anglophone

• Extreme Programming Refactored: The Case Against XP, Matt Stephens et Doug Rosenberg (Apress, 2003) (ISBN 1590590961)

Liens externes

• (en) ExtremeProgrammingRoadmap, un wiki très complet
• (fr) Un autre article sur l'XP
• (fr) Un exposé succinct de la méthode : historique, fondements et mise en œuvre
• (en) Do You Understand XP? de Manuel Klimek
• (en) Extreme programming.org