L'Extreme Programming ou XP, est une méthode de développement de projet mise au point à la fin des années 90 par Kent Beck, Ward Cunningham et Ron Jeffries.
XP doit son nom au fait qu'elle place l'activité de programmation au centre du projet, et qu'elle obtient ses résultats en combinant et en poussant à l'extrême certaines pratiques de développement.

 

Historique

• 90's : XP est conçu par Kent Beck, Ward Cunningham et Ron Jeffries (projet Chrysler)
• 1999 : premier ouvrage de Kent Beck (Extreme Programming Explained – XPE)
• 2000 : les début en France
  • Adoption confidentielle
  • Pléthore de XP Canada Dry (« j'écris pas de doc donc je fais de l'XP... »)
  • Une progression lente et régulière
• Fin 2004 : XPE 2eme édition
• 2005 : les premiers Xp Days en France

 

La constituion de l'XP

 

Droits

Les droits doivent permettre de s’inventer notre nouvelle attitude dans le projet, que l’on soit client, manager ou développeur.

Client, Manager vous avez le droit de…

• Disposer d'un plan global, de connaître ce qui peut être fait, quand et à quel coût.
• Obtenir le plus possible de chaque semaine de programmation.
• Voir les progrès d'un système exécutable, dont il est prouvé qu'il fonctionne grâce à des tests répétables que vous avez spécifié.
• Changer d'avis, remplacer des fonctionnalités, changer les priorités sans avoir à payer un prix exorbitant.
• Être informé des changements de planning en temps utile de façon à pouvoir changer l'étendue de l'itération pour conserver la date initiale de livraison. Vous pouvez même annuler le projet à n'importe quel moment et disposer d'un système utilisable, qui reflète vos investissements jusqu'à ce jour.
  

Développeur, vous avez le droit de…

• Connaître les besoins, avec une définition précise des priorités.
• Produire un travail de qualité, tout le temps.
• Demander et recevoir de l'aide des binômes, du management, des clients.
• Faire et mettre à jour vos estimations.
• Accepter vos responsabilités plutôt que de vous les voir imposées.

 

Valeurs

Il faut prendre les valeurs qui suivent comme des convictions profondes qui animent les acteurs du projet.
Ce sont de puissants leviers, des motivations qui font avancer.

Communication

La communication est la composante fondamentale de tout travail en équipe. XP installe la communication dans le projet à tous les niveaux.

Feed-back

Le retour d'information permet de tracer et d'ajuster le processus en vue d'améliorer la qualité, la maintenabilité et la productivité. A chacune des tâches de production, XP câble un mécanisme ou une pratique permettant de valider cette production de manière quasiment continue.

Simplicité

Communication et retour d'information : ces dispositions sont menacées, à mesure que le produit évolue et s'accroît, par la lourdeur et l'inertie du processus.

Pour cette raison, XP érige la simplicité en véritable discipline, tant au niveau de la conception que du processus lui-même (scénarios utilisateur, séances de planifications, propriété collective du code, pas de spécialisations techniques).

Courage

La force d'une équipe même dotée d'une approche efficace ne se mesure pas tant à ce qu'elle fait lorsque tout va bien, qu'à la manière dont elle affronte les difficultés. Pour cette raison XP valorise également le Courage.

 

Principes essentiels

• Feed-back rapide
• Assumer la simplicité
• Changement incrémental
  Accueillir le changement
• Travail de qualité

 

13 Pratiques

1. Client sur le Site (On-Site Customer) : Pour une meilleure communication, le client et les développeurs travaillent dans le même espace autant que possible.
2. Séance de Planification (Planning Game) : Le client définit les scénarios utilisateurs prioritaires. Les développeurs discutent le contenu de ces scénarios, définissent les tâches techniques sous-jacentes, estiment ces tâches et y souscrivent.
3. Intégration Continue (Continuous Integration) : Le système est intégralement assemblé et testé une à plusieurs fois par jour.
4. Livraisons Fréquentes (Frequent Releases) : Le rythme des livraisons est de l'ordre de quelques semaines.
5. Rythme Soutenable (Forty-hour Week) : L'équipe ne fait pas d'heures supplémentaires deux semaines de suite. 
6. Tests de Recette (Acceptance Tests) : Retour d'information rapide sur le système, en général automatisé, constitué à partir de critères de tests définis par le client.
7. Tests Unitaires (Unit Tests) : Tests automatisés écrits pour chaque classe, chaque méthode, et pour tout "ce qui pourrait casser" en général. Ces tests doivent passer à 100% continuellement.
8. Conception Simple (Simple Design) : Le code doit passer tous les tests et répondre aux critères de maintenabilité : concision, modularité, cohérence, lisibilité.
9. Métaphore(Metaphor) : Une analogie utilisée comme modèle conceptuel du système en cours de développement.
10. Remaniement Continu ou Refactorisation de Code pratiquée sans relache : modification du code par laquelle on améliore sa conception sans en modifier le comportement.
11. Convention de Code (Coding Standard) : Le code doit suivre une convention de nommage et de présentation afin d'être lisible par tous les membres de l'équipe.
12. Programmation En Binome (Pair Programming) : Le code de production est toujours écrit par deux développeurs : le pilote et le copilote. Les binômes changent au cours du projet.
13. Propriété Collective du Code (Collective Code Ownership) : Chaque développeur peut modifier chaque partie du code si le besoin s'en fait sentir.

 

Sources :

• Thierry Cros -Présentation de l'Extreme Programming
• Association "eXtreme Programming France"

 

Retour