Voici, avec deux niveaux de détail, une synthèse des 12 pratiques fondamentales de XP dont l’influence sur l’estimation et la planification doit être prise en compte. Dans la première présentation les pratiques sont organisées par type d’usage (leur numérotation est liée à la chronologie de leur apparition dans un projet tel que listé dans le second exemple).

1 - Le planning est un consensus entre le client et le développeur. Comme pour le Risk Driven Development, il est procédé par priorités (parfois techniques, mais plus fréquemment fonctionnelles). Le développeur se focalise uniquement sur les buts principaux et diffère le traitement des objectifs secondaires. Le principe de Courage s’applique dans les négociations avec le client, lors des éventuelles divergences.

2 - Les équipes XP emploient des métaphores. La métaphore est une abstraction de niveau élevé. La métaphore ne doit pas être une simplification abusive du concept initial, mais doit permettre de simplifier l'expression d'une chose complexe comme, par exemple, clarifier des fonctionnalités. Le mérite d’une métaphore est d'être synthétique et parlante. Exemple : utiliser la métaphore de la " recette de cuisine " pour expliquer un processus sophistiqué. Dans XP, la plupart des métaphores concernent le fonctionnement de l’application ou l’architecture.

4 - Le design est simple et focalisé sur les besoins actuels. Sans préfigurer des évolutions fonctionnelles ultérieures (non exprimées), le développeur code l'essentiel, en se basant sur les besoins immédiats et dans l’ordre de leurs priorités.

5 - Développement en binôme. Deux ressources de développement travaillent simultanément sur l’implémentation du même code. A tour de rôle, elles programment et valident la qualité afin de produire un code propre, robuste et fiable. Dans certains projets, les développeurs s'associent en binômes uniquement lors des séances de refactoring (comme pour la méthode RAD), ou lorsque le problème est particulièrement ardu.

8 - Le client collabore en permanence et en direct. Afin d'assurer une meilleure réactivité et un feedback rapide, un représentant du client doit être présent pendant toute la durée du projet. Cette ressource dédiée au projet est chargée de déterminer les besoins, de fixer les priorités, de valider les recettes et de fournir l’information utile.

9 - Standards de codage. Pour faciliter l'appropriation collective de l’applicatif, la réutilisation et la communication, les programmeurs code dans un style et des règles identiques (normes de nommage pour les variables, méthodes, objets, classes, fichiers, etc.).

11 - Intégration continue : Les modules développés sont assemblés journalièrement ou à la fin du codage de chaque jalon. La version de départ d’une nouvelle implémentation de code à jour s’effectue ainsi sur un applicatif stabilisé.

Comme il est justement souligné sur le site de Design-Up " Au final, on peut se demander si la méthode porte bien son nom. Le terme extrême évoquant des prises de risques insensées, alors qu'en pratique XP vise une suppression systématique du risque. " Dans XP, c’est en fait le bon sens qui est poussé à son extrême !

Figure 1. - Cycle de vie itératif incrémental de XP

Ce sont généralement les petites équipes confrontées à des besoins volatiles qui obtiennent les plus grands profits de XP, car cette méthode s’affirme plus comme un ensemble de pratiques à dimension humaine que comme un processus rigide.

En résumé, XP propose un ensemble cohérent de techniques répondant à la grande majorité des problèmes de la construction d’application.

Dans sa pratique, XP préconise un déroulement par itérations courtes (Figure 1) mettant en œuvre un ensemble de bonnes pratiques de développement, dans une implication collective du développeur et du client. Il découle de ce principe collaboratif une redéfinition naturelle de la relation client-fournisseur, avec des résultats positifs en termes d’évolution des exigences " client ", de qualité du code, de délais de livraisons, et, en général, de satisfaction des deux parties.

Les approches classiques de développement sont fondées sur l'idée que le coût de modification du logiciel augmente de manière exponentielle dans le temps. Dans une telle logique, il est normal de chercher à définir complètement le produit avant de procéder à sa réalisation. Pour les praticiens d’XP, certaines techniques de développement permettent de réduire le coût des changements, à tel point qu'il devient plus rentable de retarder au maximum la prise de décisions, pour l’appuyer finalement sur les certitudes déterminées par la maturité du projet. Il en résulte de ces divergences de vision des approches de développement radicalement différentes.

L’approche classique, cartésienne et industrielle, se fonde sur la maîtrise de la composition du produit et sur le respect d’un processus formel de production (prédictivité). Pragmatique et empiriste, XP se fonde sur une ouverture permanente au changement (réactivité).

Lors d’un projet XP, les spécifications initiales sont revues, affinées et complétées tout au long du développement. Le client arbitre en permanence les priorités et l’équipe projet oriente son travail en conséquence. L'application est maintenue simple et évolutive par la systématisation d’un ensemble de techniques de conception et de construction.

Les développeurs travaillent en mode projet et en mode plateau en s’appuyant sur des pratiques collaboratives qui favorisent le transfert de connaissances, améliorent la qualité du produit et accroissent la motivation.