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 , 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:
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.
