Principes XP

Les valeurs vous disent ce qui est important. Les pratiques vous disent quoi faire. Mais comment les relier? C'est là qu'interviennent les principes.

Les principes sont le pont. Ils sont plus concrets que les valeurs mais plus abstraits que les pratiques. Lorsque vous décidez d'adopter une pratique ou de la modifier pour votre contexte, les principes vous guident.

XP a de nombreux principes, mais nous nous concentrerons sur les plus importants.

Le logiciel est créé par des personnes, pour des personnes.

Ce principe nous rappelle que les développeurs ne sont pas des ressources interchangeables. Les gens ont des besoins :

• Sécurité (physique et psychologique)
• Accomplissement (faire un travail significatif)
• Appartenance (faire partie d'une équipe)
• Croissance (apprendre et s'améliorer)
• Intimité (relations étroites et de confiance)

Les pratiques XP devraient répondre à ces besoins. La programmation en binôme répond aux besoins d'appartenance et d'intimité. Le développement piloté par les tests répond aux besoins d'accomplissement et de sécurité. Le rythme soutenable protège la santé physique et mentale.

Lorsqu'une pratique semble inappropriée, demandez-vous : « Est-ce que cela viole des besoins humains? »

L'argent compte. Le temps a de la valeur. Les options ont de la valeur.

XP prend l'économie au sérieux :

• Valeur temporelle de l'argent : Une fonctionnalité livrée aujourd'hui vaut plus que la même fonctionnalité dans six mois
• Options : Garder des choix ouverts a de la valeur (d'où l'évitement du sur-engagement)
• Coût du délai : Attendre pour livrer de la valeur a des coûts réels

Ce principe soutient les petites versions (livrer de la valeur tôt), la conception incrémentale (ne pas surinvestir dès le départ) et la planification itérative (répondre à ce que vous apprenez).

Il soutient également le rythme soutenable : les développeurs épuisés font des erreurs coûteuses.

Chaque pratique devrait bénéficier à tous les participants.

Les meilleures pratiques XP sont gagnant-gagnant-gagnant :

• Les tests aident le développeur (confiance), l'équipe (documentation) et les futurs développeurs (filet de sécurité)
• La programmation en binôme aide les deux partenaires (apprentissage, détection d'erreurs) et le code (qualité)
• Le code simple aide l'auteur (plus rapide à écrire) et les lecteurs (plus facile à comprendre)

Évitez les pratiques qui aident un groupe au détriment d'un autre. La documentation écrite uniquement pour la conformité, jamais lue par les développeurs, échoue au bénéfice mutuel. Le code écrit pour être astucieux plutôt que clair y échoue aussi.

Si une pratique crée du ressentiment, elle viole probablement le bénéfice mutuel.

Les modèles qui fonctionnent à une échelle fonctionnent souvent à d'autres.

XP applique les mêmes modèles à différentes échelles :

• Rouge-vert-refactorisation (tests) : Faire échouer, faire réussir, rendre propre
• Planifier-faire-étudier-agir (itérations) : Planifier le travail, faire le travail, étudier les résultats, ajuster
• Collecter-regrouper-voter (rétros) : Rassembler les données, trouver des tendances, décider des actions

Lorsque vous trouvez quelque chose qui fonctionne, essayez-le à différentes échelles. Le jeu de planification fonctionne pour la planification de version et la planification d'itération. Les principes de révision de code fonctionnent pour la révision de conception et la révision d'architecture.

Commencez où vous êtes et améliorez-vous continuellement.

XP n'exige pas la perfection dès le premier jour. Il exige du mouvement. Commencez avec ce que vous pouvez faire aujourd'hui, et améliorez-vous à partir de là.

• Vous n'avez pas de tests? Écrivez un test pour le prochain bogue que vous corrigez.
• Vous ne faites pas de programmation en binôme? Essayez-la pendant une heure demain.
• Pas d'intégration continue? Validez plus fréquemment.

L'objectif n'est pas de « faire XP ». L'objectif est de s'améliorer. XP est une direction, pas une destination.

Ce principe soutient également l'échec sécuritaire. Les expériences qui ne fonctionnent pas sont des occasions d'apprentissage, pas des échecs.

Livrez de la valeur continuellement, pas en gros lots.

Ce principe aligne XP avec la pensée lean et Kanban. Les gros lots cachent les problèmes. Les petits lots les révèlent rapidement.

• Petites histoires (jours, pas semaines)
• Versions fréquentes (hebdomadaires, pas trimestrielles)
• Intégration continue (heures, pas jours)
• Tests immédiats (secondes, pas heures)

Le flux réduit le travail en cours, ce qui réduit le changement de contexte, ce qui améliore la concentration et la qualité. Il donne également de la valeur aux clients plus tôt et des commentaires plus rapidement.

La qualité n'est pas négociable.

Cela semble évident, mais les implications sont profondes. XP dit que vous pouvez échanger la portée ou l'échéancier, mais jamais la qualité.

Cela signifie :

• Les tests ne sont pas optionnels lorsque le temps presse
• La refactorisation n'est pas un luxe
• La dette technique n'est pas acceptable
• « Livrer maintenant, corriger plus tard » n'est pas un plan

Pourquoi? Parce que la qualité est le fondement de la rapidité. Une mauvaise qualité crée des bogues qui vous ralentissent. Une mauvaise qualité crée du code difficile à modifier. Une mauvaise qualité crée des systèmes coûteux à maintenir.

La qualité est le moyen le plus rapide d'aller vite.

Faites le plus petit pas qui fait progresser.

Les grands changements sont risqués. Les petits changements sont sûrs. XP préfère toujours les petits pas :

• Écrivez un test qui échoue avant d'écrire du code
• Refactorisez une chose à la fois
• Intégrez après de petits changements, pas de gros
• Publiez de petits incréments, pas de grandes versions

Les petits pas ne signifient pas des progrès lents. Mille petits pas peuvent couvrir plus de terrain que dix grands sauts — et avec moins de risque de tomber.

Lorsque vous êtes bloqué, demandez-vous : « Quelle est la plus petite chose que je peux faire maintenant qui fait progresser? »