L’extreme programming (ou XP) est une des méthodes agile dont le nom est globalement le plus connu. Mais peu en connaissent les fondements et les principes.

La principale source de méprise provient du nom même de la méthode souvent associée avec des notions de désorganisation, d’urgence, de manque de documentation, de code aride et illisible. En clair, extrême est associé à la notion risquée.

En fait, le nom extreme programming vient du fait que les activités de programmation sont au centre de la méthode et que les pratiques qui font le succès des projets sont poussées à leur extrême. Les tests permettent de détecter rapidement les défauts ? Écrivons les tests en premier et automatisons-les ! Il faut privilégier les livraisons fréquentes ? Adoptons un développement avec les cycles le plus court possible. Le client peut être un élément clé du développement ? Intégrons-le à l’équipe de réalisation …

Toutes ces nouvelles contraintes ne s’ajoutent pas aux contraintes des méthodes logicielles traditionnelles, elles les remplacent. L’idée n’est pas d’alourdir le formalisme existant, c’est de ne garder que les points clés. Ainsi au lieu d’avoir pléthore de points de passage plus ou moins facultatif, il ne reste que quelques points importants et qui deviennent incontournables. On ne peut plus se dire qu’une étape peut être oublié en chemin parce qu’elle sera remplacée par une autre, on est obligé de valider chaque étape.

En pratique, que demande cette méthodologie ?

Au niveau de la gestion de projets, il y a deux différences avec une gestion classique : le client sur site et des livraisons fréquentes. La présence du client a un impact direct lors des nécessaires arbitrages sur les priorités et les rendus finaux. Le fait de devoir livrer fréquemment des versions intermédiaires permet de mieux intégrer le retour utilisateur au développement. Par contre, il implique des séances de planification régulière. Au début de chaque nouveau cycle, le client définit les nouvelles priorités et discute avec les développeurs du contenu des nouvelles fonctionnalités.

Au niveau des pratiques collaboratives, les apports de cette méthode sont principalement : travaille en binôme, propriété collective du code et l’intégration continue. Le premier point consiste à faire travailler deux développeurs sur une même machine. Ainsi, le code fourni devrait être de meilleure qualité, le relecteur corrigeant des fautes à la volée, le codeur pouvant se concentrer sur une vue analytique du problème quand le relecteur peut avoir une vue plus synthétique. Cette approche facilite la notion de propriété collective. Le code n’appartient à personne en particulier ; tout le monde peut intervenir sur tous les modules du code. Cela implique aussi une responsabilité collective sur ce code. Bien entendu, pour atténuer les contraintes ci-dessus des règles de codage et tous les autres outils simplifiant la relecture de code et le partage d’informations sont fortement conseillées.

Enfin, au niveau de la programmation en elle-même, la méthode XP se base sur deux concepts : une conception simple, un développement guidé par les tests. La solution la plus simple doit être implémentée, cela facilitera les évolutions futures ainsi que les tests et la documentation. L’idée de devoir redévelopper un module pour ajouter de nouvelles fonctionnalités ne doit pas être limitant, cela permettra de repasser dans ce module et d’en améliorer le code. Le développement guidé par les tests est une pratique suffisamment utilisée pour ne pas en reparler ici.

Toutes ces pratiques ne sont pas aussi simples que ça à appliquer et demande souvent des volontés politiques ou économiques fortes. Le gain est souvent au rendez-vous, mais la mise en pratique n’est pas aisée.

Pour finir cet article sur la pratique de XP, voici un résumé des quatre valeurs cardinales mises en exergue : * Communication * Simplicité * Feedback * Courage

Eric Legay