Extreme programming is the new Voldemort ?

Durant la soirée des communautés qui a eu lieu après le premier jour des TechDays 2015, j’ai posé la question suivante : XP = Voldemort ? Passée la déception chez certains parce que je ne parlais pas de Windows XP, la discussion fut fort intéressante.

Je partais du constat suivant :

• l’intégration continue fait maintenant partie intégrante de l’immense majorité des projets dignes de ce nom.
• la qualité du logiciel que l’on développe tend à être de moins en moins négociable.
• le code est le seul artéfact ayant une réelle valeur intrinsèque. Le reste est périphérique.
• on développe des User Stories…
• … parfois en pair programming.
• on chiffre durant un Planning Poker.
• les tests ne sont plus relégués en fin de projet. Ils tendent à être automatisés. Mieux, on parle de plus en plus souvent de TDD, BDD, FDD…
• le business s’est singulièrement rapproché de l’équipe technique. D’ailleurs, on partage un même vocabulaire, ce qui a pour effet de limiter fortement les ambiguïtés et incompréhensions.
• on parle fréquemment de valeurs : courage, simplicité, communication…
• on recherche du feedback le plus tôt possible.
• quand une dérive pointe le bout de son nez, il n’est pas rare d’entendre “YAGNI”, “KISS” ou “DRY”
• on livre souvent, et par petits incréments.
• et enfin, on accueille avec bienveillance le changement : welcome change !

Bref : au final, ne pratique-t-on pas “tous” Extreme Programming sans le dire ou sans le savoir ? La question a fait sourire les vieux barbus dans la salle. Je ne sais pas pour vous, mais j’ai l’impression de croiser pas mal de ces “vieux” développeurs qui ont une certaine tendresse pour XP, à laquelle s’ajoute une défiance pour Scrum. Ça avait déjà fait l’objet de beaucoup de discussions aux ScrumDay l’an dernier. Et on arrive souvent à la conclusion qu’Extreme Programming n’a pas connu le succès mérité, bien que, comme nous venons de le voir, une très grande partie de ses valeurs et pratiques se sont diffusées dans nos projets (mais peut-être est-ce ça le véritable succès).

Donc pourquoi ne parle-t-on pas plus d’Extreme Programming ? La première réponse tient au fait que le nom de la méthodo est pourri et difficilement vendable. Allez expliquer à une hiérarchie de décideurs que dorénavant, vos programmeurs seront des programmeurs DE L’EXTRÊME… C’est dommage, car la seule chose de réellement extrême dans XP est de pousser au maximum les bonnes pratiques et d’éliminer le superflu (DRY ! YAGNI !). Mais au delà de ça, il semble que XP a été débordé par sa gauche et par sa droite par d’autres méthodologies.

D’abord par Scrum. Jeff Sutherland et Kent Beck, les créateurs de Scrum sont signataires du Manifeste Agile, tout comme Kent Beck qui a créé XP. Les deux méthodologies partagent donc un ensemble de valeurs et de principes. Ensuite, Scrum a poussé bien plus loin les principes de gestion de projet d’XP. Le Client est devenu le Product Owner. Les itérations sont devenues des Sprints. Les User Stories sont regroupées dans un Backlog produit. On a rajouté des cérémonies qui permettent de cadencer les Sprints et des artefacts permettant de mesurer l’avancement. Scrum est aujourd’hui la méthode agile la plus répandue et le principal ambassadeur de l’agilité. En revanche, si Scrum décrit dans quelles conditions le logiciel est développé, rien n’est dit sur le comment. La méthode se contente de dire que Scrum doit forcément s’accompagner “d’excellence technique”. Voilà voilà… XP va bien plus loin sur ce plan-là.

Sauf que sur le plan technique, le Software Craftsmanship a des choses à dire. Il n’y a qu’à lire le manifeste pour y lire le souhait d’aller plus loin sur le plan technique, en se basant sur le manifeste agile. Le mouvement se base beaucoup sur deux ouvrages : Clean Code d’Uncle Bob et Pragmatic Programmer de Andrew Hunt et David Thomas. Et le sujet fait actuellement l’objet d’un fort engouement. La London Software Craftsmanship Community de Sandro Mancuso a vu l’arrivée de son spin-off parisien avec le Software Crafstmanship Paris qui se réunit une fois par mois. Le Software Craftsman se définit comme son nom l’indique : c’est un artisan. L’artisan a des méthodes et des outils. Les outils sont pour beaucoup issus de la boîte à outils XP : Intégration Continue, voire Déploiement Continu, tests automatisés. Les méthodes sont issues des deux livres mentionnés plus haut, et là encore d’XP : TDD, Pair Programming… Par ailleurs, un axe très fort du Craftsman est de livrer du code lisible, maintenable et testé. C’est le Clean Code. On oublie trop souvent qu’un programmeur passe bien plus de temps à lire du code qu’à en écrire. Tout ceci contribue à optimiser le temps du programmeur de façon à lui faire exécuter des tâches où il a une réelle valeur ajoutée : écrire du code. Et pour en revenir à la question initiale, Bruno Boucard a justement fait remarquer que le “déclin” de XP date de la sortie du livre Clean Code.

Donc au final, je pense avoir eu la réponse à ma question. Non, XP n’est pas Voldemort. C’est simplement que ses outils, techniques et valeurs sont aujourd’hui vus comme des acquis dans beaucoup de projets, et perdurent au travers de méthodes plus récentes et plus spécialisées. C’est pourquoi nous voyons aussi souvent associés les couples Scrum + Craftsman et Kanban + Craftsman.