L’ (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 , , xprogramming.com, octobre 1998. Martin Fowler, « C3 », martinfowler.com, 3 août 2004.. Kent Beck, chef de projet en , 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 , Kent Beck (Addison-Wesley, 1999), 978-0201616415 ., 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
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 - La référence, Kent Beck, chapitre 25 - Quand faut-il éviter XP. :
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 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 ) ; 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
, nouvelle édition du même ouvrage sous le nom Gestion de projet eXtreme Programming
Jean-Pierre Vickoff, Méthode Agile, Les meilleures pratiques, Compréhension et mise en œuvre, QI, 2009
Bibliographie anglophone , Matt Stephens et Doug Rosenberg (Apress, 2003)
Liens externes ExtremeProgrammingRoadmap, un wiki très complet Un autre article sur l'XP Un exposé succinct de la méthode : historique, fondements et mise en œuvre Do You Understand XP? de Manuel Klimek Extreme programming.org
Notes et références
Catégorie:Gestion de projet Catégorie:Méthode de développement logiciel Catégorie:Méthode agile