Les cinq valeurs XP

XP n'est pas qu'une collection de pratiques — c'est un système de valeurs. Les pratiques n'ont de sens que dans le contexte des valeurs. Sans les valeurs, vous obtenez du XP cargo-culte : des équipes qui suivent les mouvements sans l'esprit.

Les cinq valeurs XP sont : Communication, Simplicité, Rétroaction, Courage et Respect.

Ce ne sont pas des affiches aspirationnelles. Ce sont des outils de prise de décision. Quand vous ne savez pas quoi faire, demandez-vous quel choix incarne le mieux ces valeurs.

La communication est la première valeur parce que le développement logiciel est fondamentalement un problème de communication. Nous n'écrivons pas seulement du code — nous traduisons des besoins humains en instructions machine.

Les malentendus sont la cause première de la plupart des bogues. Le client dit « rapide », le développeur implémente la mise en cache, mais le client voulait dire « moins de clics ». Les approches traditionnelles tentent de résoudre cela avec de la documentation. XP le résout avec une communication continue.

Dans XP, la communication signifie :

• Programmation en binôme (communication technique constante)
• Client sur place (communication constante des exigences)
• Mêlées quotidiennes (communication constante de l'équipe)
• Code simple (code qui communique son intention)

L'opposé de la communication : supposer que vous savez ce qui est nécessaire, travailler en isolation, écrire du code astucieux et lancer des spécifications par-dessus le mur.

La simplicité signifie faire la chose la plus simple qui pourrait possiblement fonctionner. Pas la plus élégante, pas la plus extensible, pas la plus générale — la plus simple.

Cela se résume dans le mantra XP YAGNI : You Aren't Gonna Need It (Vous n'en aurez pas besoin). Ne construisez pas de frameworks. N'ajoutez pas de points d'extension. Ne généralisez pas. Construisez exactement ce qui est nécessaire aujourd'hui.

Pourquoi ? Parce que :

• Le code simple a moins de bogues
• Le code simple est plus facile à modifier
• Le code simple est plus facile à comprendre
• La moitié de ce que vous pensez avoir besoin, vous n'en aurez pas besoin

Cela ne signifie pas bâclé ou approximatif. Le code simple est souvent plus difficile à écrire que le code complexe. Il nécessite de réfléchir profondément à ce qui est réellement essentiel.

L'opposé de la simplicité : construire pour des exigences futures hypothétiques, ajouter de la flexibilité « au cas où », créer des abstractions avant d'en avoir besoin.

La rétroaction est la façon dont vous apprenez si vous faites la bonne chose. XP crée des boucles de rétroaction à toutes les échelles :

• Secondes : Les tests unitaires vous disent si votre code fonctionne
• Minutes : Le partenaire de binôme détecte les erreurs pendant que vous tapez
• Heures : L'intégration quotidienne révèle les problèmes d'intégration
• Jours : Les itérations hebdomadaires montrent les progrès aux clients
• Semaines : Les cycles de livraison confirment que vous construisez la bonne chose

Plus la rétroaction est rapide, moins la correction coûte cher. Un bogue détecté en quelques secondes ne coûte rien. Un bogue détecté en production coûte du temps, de l'argent et de la réputation.

Les pratiques XP sont conçues pour créer une rétroaction rapide et honnête. Les tests ne mentent pas. Le logiciel fonctionnel ne ment pas. Les métriques de production ne mentent pas.

L'opposé de la rétroaction : travailler en isolation pendant des semaines, attendre la fin pour tester, éviter le contact avec le client, ignorer les métriques de production.

Le courage signifie faire ce qui doit être fait, même quand c'est inconfortable. Dans XP, le courage se manifeste par :

• Refactoriser sans relâche : Modifier du code fonctionnel pour le rendre plus simple
• Jeter du code : Supprimer du code qui ne tire pas son poids
• Demander de l'aide : Admettre que vous ne savez pas quelque chose
• S'exprimer : Dire au client quand les estimations sont fausses
• Essayer de nouvelles choses : Expérimenter même quand vous pourriez échouer

Le courage n'est pas de l'imprudence. Il est soutenu par les autres valeurs. Vous pouvez refactoriser avec courage parce que vous avez des tests (rétroaction). Vous pouvez vous exprimer parce que vous avez des relations avec le client (communication).

L'opposé du courage : laisser des fenêtres brisées, gonfler les estimations pour être « sûr », cacher les mauvaises nouvelles, faire ce qui a toujours été fait.

Le respect a été ajouté dans la deuxième édition du livre de Kent Beck, reconnaissant ce qui était toujours implicite : XP ne fonctionne que lorsque les membres de l'équipe se respectent mutuellement.

Le respect signifie :

• Faire confiance à la compétence des collègues (ne pas microgérer)
• Valoriser la contribution de chacun (développeurs, testeurs, clients)
• Donner une rétroaction honnête avec gentillesse (ne pas écraser les esprits)
• Prendre soin de son propre travail (ne pas créer de fardeaux pour les autres)

En programmation en binôme, le respect signifie écouter les idées de votre partenaire. En planification, le respect signifie donner des estimations honnêtes. En revue de code, le respect signifie critiquer le code, pas les personnes.

L'opposé du respect : rejeter des idées sans considération, attribuer des blâmes, traiter certains rôles comme moins importants, se soucier plus d'avoir raison que d'être efficace.