Présentation de l’eXtreme Programming

L’eXtreme Programming, créé par Kent Beck en 1999, est une méthodologie légère qui se concentre sur l’activité de codage. Contrairement à ce que l’on pourrait croire il ne s’agit pas de laisser tomber modélisation, assurance qualité et documentation. L’XP est disciplinée et fondée sur des bases sérieuses.

Cette méthodologie est basée sur :

• des revues de code constantes
• des tests fréquents
• l’implication du client
• des feedbacks fréquents et rapides
• un refactoring et une conception continus
• une intégration continue
• une planification sans cesse remise à jour

Je ne compte pas réécrire ce qui a déjà été dit sur l’XP, j’espère juste apporter un peu d’eau au moulin et faire profiter le lecteur de mes réflexions et de mon expérience.
Pour une introduction au sujet, je vous conseille : ce lien sur Wikipedia et ce lien. XP est une des méthodes agiles (voir manifeste Agile, les principes Agiles et un peu de doc sur les autres méthodes agiles)
Je voudrais juste vous exposer les valeurs, principes et pratiques d’XP.

Les valeurs

• la communication : la communication doit circuler librement dans l’équipe de développement et, d’une manière plus générale, entre les différents intervenants comme le client et le management
• la simplicité : coder et concevoir de façon simple
• le feedback : c’est le contraire de l’effet tunnel : des retours répétés et fréquents sur l’application en cours de développement permettent de découvrir les problèmes plus rapidement, ce qui coûte moins cher et vous stresse moins
• le courage : de modifier le code sans vergogne grâce aux tests unitaires

• assurer un retour dès que possible : le coût de résolution d’un problème est d’autant plus faible qu’il est découvert tôt
• préférer la simplicité, ne faire que ce qui et nécessaire, inutile de se compliquer la vie ; comme disait Einstein : "everything should be made as simple as possible, but no simpler", c’est le principe de parcimonie, peut-être plus connu sous le nom de KISS
• avancer par incréments : c’est le principe du "petit à petit l’oiseau fait son nid" ! ou "diviser pour régner"
• accueillir le changement : grâce aux tests unitaires un changement n’est plus un facteur de risque
• la qualité : je crois qu’aujourd’hui il va de soi qu’écrire du code de qualité réduit les coûts

• Planning game
• Releases de petite taille
• Conception simple
• Tests
• Intégration continue
• Refactoring
• Pair programming
• Propriété collective du code
• Semaine de travail de 40 heures (bon, 35 heures en France !)
• Client disponible
• Un langage commun partagé par l’équipe de développement et le client
• Normes de codage