J'ai lu récemment la seconde édition de Extreme Programming Explained de Kent Beck. Cela peut paraître assez incroyable qu'un fan comme moi d'XP n'ait pas encore lu ce livre... Pourtant c'est bien le cas !
Avant de le lire, je pensais que ce serait un texte radical, à la Robert Martin, du genre "si vous voulez faire de l'XP demain, il faut développer en TDD exclusivement et faire du pair programming tout le temps". En fait, Kent Beck n'est pas du tout comme ça. Il a plutôt tendance à dire qu'il faut y aller progressivement. Tester une pratique, constater les bénéfices avant d'aller plus loin. Somme toute, le livre est assez motivant et l'auteur sait bien qu'il propose des pratiques assez, n'ayons pas peur des mots, extrêmes.
Dans sa première partie, le livre se focalise sur les valeurs derrière XP qui sont :
- Communication
- Simplicité
- Feedback
- Courage
- Respect
Déjà, je trouve que ce n'est pas toujours évident de suivre ces valeurs au quotidien !
De ces valeurs découlent des principes et les pratiques qui sont à présent bien connues, si bien qu'elles sont devenues une caricature de l'agilité : un tableau avec des post-its, un ordi pour deux et pas de code avant d'écrire les tests les loulous !
L'hypothèse est que ces pratiques vont bien ensemble. Toutefois, s'il est conseillé de toutes les utiliser, il suffit d'en développer une pour en récolter rapidement les bénéfices. Il est vrai que se mettre au TDD permet d'avoir une meilleure qualité de code. Je le vérifie personnellement tous les jours. Les autres pratiques sont toute aussi intéressantes (même le pair programming, je vous jure !).
Lors de la première édition du livre, on s'aperçoit que les concepts avancés par Beck étaient assez théoriques : ils n'ont, à ce que je crois comprendre, été appliqués que dans le cadre du fameux projet chez Chrysler. Pour la deuxième édition, il a appris des retours des early adopters et des détracteurs. Certains points pour lequel il pensait qu'XP n'était pas adapté ne sont plus un problème, car certains l'on fait (par exemple, utiliser XP dans une équipe dispersées sur plusieurs sites). Certaines fois, son discours s'est radicalisé. La longueur de l'itération est ainsi passé de 2 à 1 semaine.
Enfin, j'ai eu une révélation sur un grand obstacle à l'adoption d'XP et des pratiques Agiles en général développé vers la fin du livre. Bizarrement, je n'en avais pas conscience avant de le lire.
XP ne peut pas marcher si les vraies valeurs de l'entreprise dans laquelle vous travaillez sont en opposition avec les valeurs XP. On ne parle évidemment pas des valeurs communiquées par les équipes marketing, mais ce celles qui sont révélées par le comportement des employés. Si dans votre entreprise, on a l'habitude de cacher des choses aux clients, on est alourdit par des tonnes de procédures et que les gens craignent de prendre leurs responsabilités alors ce n'est peut-être pas une bonne idée de souhaiter investir dans XP. Cela ne pourra pas marcher.
Je pense que c'est un point à méditer, alors que beaucoup d'entreprises se déclarent aujourd'hui expertes Scrum / Agile !
PS : pour terminer le fan service, vous pouvez retrouver sur le podcast Software Engineering Radio une interview de Kent Beck.
PPS : je ne sais pas vous, mais j'ai bien envie de coder en Smalltalk là !
Sur ce à plus tard et n'oubliez pas de lire des livres.
