Les origines de XP

En 1996, Kent Beck a été embauché pour sauver un projet de paie en difficulté chez Chrysler appelé C3 (Chrysler Comprehensive Compensation). Le projet était en difficulté — le développement en cascade classique avait produit un système qui ne fonctionnait pas et ne pouvait pas être corrigé.

Beck n'a pas seulement corrigé le projet. Il a synthétisé des décennies de sagesse en génie logiciel en une méthodologie cohérente. Il a pris des pratiques que les développeurs expérimentés savaient efficaces — les tests, la revue de code, le développement itératif — et les a poussées à leurs extrêmes logiques.

Si les tests sont bons, testez constamment. Si la revue de code est bonne, révisez en continu via la programmation en binôme. Si l'intégration est bonne, intégrez plusieurs fois par jour. Si les itérations courtes sont bonnes, rendez-les encore plus courtes.

Le projet C3 a été livré. Plus important encore, il a créé un modèle qui allait remodeler le développement logiciel.

En 1999, Kent Beck a publié « Extreme Programming Explained » — souvent appelé « le livre blanc » pour sa couverture. Cela est devenu le document fondateur de XP et l'un des premiers manifestes agiles.

Le livre était controversé. Programmer en binôme tout le temps ? Pas de grande conception initiale ? Des clients sur place ? Beaucoup dans l'industrie pensaient que Beck était fou. Mais les équipes qui ont essayé XP ont rapporté des résultats remarquables :

• Beaucoup moins de bogues atteignant la production
• Rythme soutenable au lieu de marches forcées
• Logiciel fonctionnel au lieu de promesses documentées
• Développeurs heureux qui se sentaient en contrôle

Deux ans plus tard, en 2001, Beck a rejoint seize autres praticiens du logiciel à Snowbird, Utah. Ensemble, ils ont écrit le Manifeste Agile. L'influence de XP est visible partout — les individus plutôt que les processus, le logiciel fonctionnel, la collaboration avec le client, la réponse au changement.

XP a été la première méthodologie agile complète, et à bien des égards, elle reste la plus rigoureuse.

La vision traditionnelle du développement logiciel était que le changement coûte cher. Le coût de correction d'un bogue croît de façon exponentielle des exigences à la conception, au codage, aux tests et à la production. Par conséquent, vous devriez tout faire pour bien faire du premier coup — d'où l'accent mis par la cascade sur une conception initiale exhaustive.

Beck a proposé une alternative radicale : Et si vous pouviez aplatir la courbe du coût du changement ?

Si vous avez :

• Des tests automatisés exhaustifs (les changements peuvent être validés instantanément)
• Une conception simple (moins à changer)
• Une propriété collective du code (n'importe qui peut apporter des changements)
• Une intégration continue (les changements sont intégrés immédiatement)
• Des compétences en refactorisation (le code peut évoluer en toute sécurité)

Alors le coût du changement devient à peu près constant dans le temps. Et si le changement est peu coûteux, vous n'avez pas besoin de prédire l'avenir. Vous pouvez embrasser le changement comme un avantage concurrentiel.

C'est l'intuition fondamentale de XP : les pratiques techniques peuvent rendre le changement peu coûteux, et un changement peu coûteux change tout.