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
[modifier | modifier le code]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[1],[2]. 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
[modifier | modifier le code]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
[modifier | modifier le code]
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).
Programmation comme discipline collective
[modifier | modifier le code]Tout en mettant l'accent sur les bonnes pratiques, la programmation extrême préconise un déroulement par itérations courtes et gérées collectivement, avec une implication constante du client. Il en découle une redéfinition de la relation entre client et fournisseur.
Valeurs
[modifier | modifier le code]L'extreme programming repose sur cinq valeurs fondamentales.
Communication
[modifier | modifier le code]C'est le moyen fondamental pour éviter les problèmes. Les pratiques que préconise l'XP imposent une communication intense. Les tests, la programmation en binôme et le jeu du planning obligent les développeurs, les décideurs et les clients à communiquer. Si un manque apparaît malgré tout, un coach se charge de l'identifier et de remettre ces personnes en contact.
Simplicité
[modifier | modifier le code]La façon la plus simple d'arriver au résultat est la meilleure. Anticiper les extensions futures est une perte de temps. Une application simple sera plus facile à faire évoluer.
Feedback
[modifier | modifier le code]Le retour d'information est primordial pour le programmeur et le client. Les tests unitaires indiquent si le code fonctionne. Les tests fonctionnels donnent l'avancement du projet. Les livraisons fréquentes permettent de tester les fonctionnalités rapidement.
Courage
[modifier | modifier le code]Certains changements demandent beaucoup de courage. Il faut parfois changer l'architecture d'un projet, jeter du code pour en produire un meilleur ou essayer une nouvelle technique. Le courage permet de sortir d'une situation inadaptée. C'est difficile, mais la simplicité, le feedback et la communication rendent ces tâches accessibles.
Respect
[modifier | modifier le code]Cette valeur fut ajoutée dans la deuxième édition de Extreme Programming Explained de K. Beck. Cette valeur inclut le respect pour les autres, ainsi que le respect de soi. Les programmeurs ne devraient jamais valider les modifications qui cassent la compilation, qui font échouer les tests unitaires existants ou qui retardent le travail de leurs pairs. Les membres respectent leur propre travail en cherchant toujours la qualité et la meilleure conception pour la solution et cela grâce au refactoring.
Pratiques
[modifier | modifier le code]Ces cinq valeurs se déclinent en treize pratiques qui se renforcent mutuellement :
Client sur site
[modifier | modifier le code]Un représentant du client doit, si possible, être présent pendant toute la durée du projet. Il doit avoir les connaissances de l'utilisateur final et avoir une vision globale du résultat à obtenir. Il réalise son travail habituel tout en étant disponible pour répondre aux questions de l'équipe.
Jeu du planning ou planning poker
[modifier | modifier le code]Le client crée des scénarios pour les fonctionnalités qu'il souhaite obtenir. L'équipe évalue le temps nécessaire pour les mettre en œuvre. Le client sélectionne ensuite les scénarios en fonction des priorités et du temps disponible.
Lorsqu'une tâche est terminée, les modifications sont immédiatement intégrées dans le produit complet. On évite ainsi la surcharge de travail liée à l'intégration de tous les éléments avant la livraison. Les tests facilitent grandement cette intégration : quand tous les tests passent, l'intégration est terminée.
Petites livraisons
[modifier | modifier le code]Les livraisons doivent être les plus fréquentes possible. L'intégration continue et les tests réduisent considérablement le coût de livraison.
Rythme soutenable
[modifier | modifier le code]L'équipe ne fait pas d'heures supplémentaires. Si le cas se présente, il faut revoir le planning. Un développeur fatigué travaille mal.
Tests de recette (ou tests fonctionnels)
[modifier | modifier le code]À partir des scénarios définis par le client, l'équipe crée des procédures de test qui permettent de vérifier l'avancement du développement. Lorsque tous les tests fonctionnels passent, l'itération est terminée. Ces tests sont souvent automatisés mais ce n'est pas toujours possible.
En effet, seuls les tests de non-régression peuvent être potentiellement automatisés du fait de leur récurrence.
La recette fonctionnelle d'une application est de plus en plus souvent confiée à des experts du test indépendants des développeurs.
Avant de mettre en œuvre une fonctionnalité, le développeur écrit un test qui vérifiera que son programme se comporte comme prévu. Ce test sera conservé jusqu'à la fin du projet, tant que la fonctionnalité est requise. À chaque modification du code, on lance tous les tests écrits par tous les développeurs, et on sait immédiatement si quelque chose ne fonctionne plus correctement.
Conception simple
[modifier | modifier le code]L'objectif d'une itération est de mettre en œuvre les scénarios sélectionnés par le client et uniquement cela. Envisager les prochaines évolutions ferait perdre du temps sans avoir la garantie d'un gain ultérieur. Les tests permettront de changer l'architecture plus tard si nécessaire. Plus l'application est simple, plus il sera facile de la faire évoluer lors des prochaines itérations.
Utilisation de métaphores
[modifier | modifier le code]On utilise des métaphores et des analogies pour décrire le système et son fonctionnement. Le fonctionnel et le technique se comprennent beaucoup mieux lorsqu'ils sont d'accord sur les termes qu'ils emploient.
Remaniement du code
[modifier | modifier le code]Amélioration régulière de la qualité du code sans en modifier le comportement. On retravaille le code pour repartir sur de meilleures bases tout en gardant les mêmes fonctionnalités. Les phases de refactoring n'apportent rien au client mais permettent aux développeurs d'avancer dans de meilleures conditions et donc plus vite.
Appropriation collective du code
[modifier | modifier le code]L'équipe est collectivement responsable de l'application. Chaque développeur peut faire des modifications dans toutes les portions du code, même celles qu'il n'a pas écrites. Les tests diront si quelque chose ne fonctionne plus.
Convention de nommage
[modifier | modifier le code]Puisque tous les développeurs interviennent sur tout le code, il est indispensable d'établir et de respecter des normes de nommage pour les variables, méthodes, objets, classes, fichiers, etc.
La programmation se fait par deux. Le premier appelé driver (ou pilote) tient le clavier. C'est lui qui va travailler sur la portion de code à écrire. Le second appelé partner (ou copilote) est là pour l'aider en suggérant de nouvelles possibilités ou en décelant d'éventuels problèmes. Les développeurs changent fréquemment de partenaire et de rôle, ce qui permet d'améliorer la connaissance collective de l'application et d'améliorer la communication au sein de l'équipe.
Autres principes
[modifier | modifier le code]- Ne pas ajouter de fonctionnalités plus tôt que prévu.
- N'optimiser qu'à la fin.
Cette méthode s'appuie sur :
- une forte réactivité au changement des besoins du client ;
- un travail d'équipe ;
- la qualité du code ;
- la qualité des tests effectués au plus tôt.
Environnements défavorables
[modifier | modifier le code]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[3] :
- 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
[modifier | modifier le code]Articles connexes
[modifier | modifier le code]Bibliographie francophone
[modifier | modifier le code]- Jean-Louis Bénard, Laurent Bossavit, Régis Médina et Dominic Williams, L'Extreme Programming : Avec deux études de cas, Paris, Eyrolles, , 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., , 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
[modifier | modifier le code]- Extreme Programming Explained: Embrace Change, Kent Beck (Addison-Wesley, 1999), 978-0201616415 (ISBN 978-0201616415)
- Extreme Programming Refactored: The Case Against XP, Matt Stephens et Doug Rosenberg (Apress, 2003) (ISBN 1590590961)
Liens externes
[modifier | modifier le code]- (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
Notes et références
[modifier | modifier le code]- (en) « Case Study : Crysler Goes To Extremes » (version du sur Internet Archive) [PDF], The C3 Team, xprogramming.com, octobre 1998.
- (en) Martin Fowler, « C3 », martinfowler.com, 3 août 2004.
- eXtreme Programming - La référence, Kent Beck, chapitre 25 - Quand faut-il éviter XP.
