Extreme programming - Définition

Source: Wikipédia sous licence CC-BY-SA 3.0.
La liste des auteurs est disponible ici.

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 (L'Extreme Programming (XP) est une méthode agile de gestion de projet informatique...) a été inventée par Kent Beck (Kent Beck est l'inventeur du concept d'eXtreme Programming et l'auteur du livre « Extreme...), Ward Cunningham (Ward Cunningham (né le 26 mai 1949) est un informaticien américain, connu entre autres, pour...) et Ron Jeffries pendant leur travail sur un projet (Un projet est un engagement irréversible de résultat incertain, non reproductible a...) "C3" de calcul des rémunérations chez Chrysler. Kent Beck, chef de projet (Un chef de projet, en informatique est la personne chargée de contrôler le bon déroulement du...) en mars 1996 commenca à affiner la méthodologie de développemment utilisée sur le projet. La méthode est née officiellement en octobre 1999 avec le 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 infomatique, 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 (En informatique, un logiciel est un ensemble d'informations relatives à des traitements...) 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 fait systématiquement avant chaque implémentation ;
  • puisque la conception est importante, elle sera faite tout (Le tout compris comme ensemble de ce qui existe est souvent interprété comme le monde ou...) 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 (En théorie des ensembles, un ensemble désigne intuitivement une collection...) 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.

Cycle de développement (Il existe différents types de cycles de développement entrant dans la réalisation...)

Le cycle de l'Extreme Programming
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 (Le mot phase peut avoir plusieurs significations, il employé dans plusieurs domaines et...) d'exploration (L'exploration est le fait de chercher avec l'intention de découvrir quelque chose d'inconnu.) 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 (En informatique, un développeur (ou programmeur) est un informaticien qui réalise des...) 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 (Le mot client a plusieurs acceptations :) peut fournir des scénarios à livrer. La première livraison est généralement plus importante et n'est réalisée qu'après quelques itérations. Après la première mise en production, les itérations peuvent devenir plus courtes (une semaine par exemple).

La programmation (La programmation dans le domaine informatique est l'ensemble des activités qui permettent...) comme discipline collective

Tout en mettant l'accent sur les bonnes pratiques de programmation, XP préconise un déroulement par itération courte et géré collectivement, avec une implication constante du client. Il en découle une redéfinition de la relation entre client et fournisseur, avec de surprenants résultats en termes de qualité de code, de délais et de satisfaction de la demande du client.

Valeurs

L'Extreme Programming repose sur 4 valeurs fondamentales :

La communication 
C'est le moyen fondamental pour éviter les problèmes. Les pratiques que préconise l'XP imposent une communication (La communication concerne aussi bien l'homme (communication intra-psychique, interpersonnelle,...) intense. Les tests, la programmation en binôme ( en mathématique, binôme, une expression algébrique ; voir aussi binôme de Newton et...) et le jeu du planning obligent les développeurs, les décideurs et les clients à communiquer. Si un manque apparait malgré tout, un coach se charge (La charge utile (payload en anglais ; la charge payante) représente ce qui est effectivement...) de l'identifier et de remettre ces personnes en contact.
La simplicité 
La façon la plus simple d'arriver au résultat est la meilleure. Anticiper les extensions futures est une perte de temps (Le temps est un concept développé par l'être humain pour appréhender le...). Une application simple sera plus facile à faire évoluer.
Le feedback 
Le retour d'information est primordial pour le programmeur (En informatique, un développeur (ou programmeur) est un informaticien qui réalise du logiciel en...) 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.
Le courage 
Certains changements demandent beaucoup de courage. Il faut parfois changer l'architecture (L’architecture peut se définir comme l’art de bâtir des édifices.) d'un projet, jeter du code pour en produire un meilleur ou essayer une nouvelle technique. Le courage permet de sortir d'une situation (En géographie, la situation est un concept spatial permettant la localisation relative d'un...) inadaptée. C'est difficile, mais la simplicité, le feedback et la communication rendent ces tâches accessibles.

Pratiques

Ces 4 valeurs se déclinent en 13 pratiques qui se renforcent mutuellement :

Client sur site 
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 
Le client crée des scénarios pour les fonctionnalités qu'il souhaite obtenir. L'équipe évalue le temps nécessaire pour les implémenter. Le client sélectionne ensuite les scénarios en fonction des priorités et du temps disponible.
Intégration continue 
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 
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 
L'équipe ne fait pas d'heures (L'heure est une unité de mesure  :) supplémentaires deux semaines de suite. Si le cas se présente, il faut revoir le planning. Un développeur fatigué travaille mal.
Tests de recette (ou tests fonctionnels
À partir des scénarios définis par le client, l'équipe créé 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.
Tests unitaires 
Avant d'implémenter 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.
Conception simple 
L'objectif d'une itération est d'implémenter les scénarios sélectionnés par le client, et uniquement cela. Envisager les prochaines évolutions nous ferait perdre du temps sans avoir la garantie qu'on en gagnera plus tard. Les tests nous 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. De même, la documentation doit être minimale : on préfèrera un programme simple qui nécessite peu d'explications à un système complexe.
Utilisation de métaphores 
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.
Refactoring (ou remaniement du 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 
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 
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.
Programmation en binôme 
La programmation se fait par deux. Le premier, appelé driver (ou pilote), a le clavier. C'est lui qui va travailler sur la portion de code à écrire. Le second, appelé partner (ou co-pilote), 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 partenaires, 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

  • Ne pas ajouter de fonctionnalités plus tôt que prévu ;
  • N'optimiser qu'à la toute 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

La méthode XP n'est pas utilisable dans tous les environnements et, parfois, seule une partie des pratiques peut être réalisée. Les principaux contextes défavorables sont[1] :

  • un blocage culturel, quand le client ou les développeurs ont l'habitude de fonctionner autrement et ne veulent rien changer ;
  • une équipe de 20 développeurs ou plus car la communication devient difficile ;
  • un coût de changement exponentiel car " XP nécessite du code propre et simple " ;
  • un feedback long ou difficile à obtenir ;
  • et un aménagement qui empèche la communication ou la programmation en binôme.
Page générée en 0.073 seconde(s) - site hébergé chez Contabo
Ce site fait l'objet d'une déclaration à la CNIL sous le numéro de dossier 1037632
A propos - Informations légales | Partenaire: HD-Numérique
Version anglaise | Version allemande | Version espagnole | Version portugaise