Critique de livre : Practices of an Agile Developer

Quand j'étais en fac, la qualité logicielle n'était pas vraiment au programme. Plus globalement, les notions d'agilité qui sont chères à bon nombre de programmeurs aujourd'hui, et qui ont été résumées dans un manifeste signé par les plus grands noms des méthodologies modernes de programmation, n'étaient pas très diffusées. Cette diffusion a l'air d'être encore relativement faible de nos jours, même si certaines formations spécifiques commencent à proposer des programmes en ce sens, comme le master I2L (Ingénierie du Logiciel Libre). (La qualité en génie logiciel serait-t-elle réservée au monde des logiciels libre ? ;))

Bref, le développeur a interêt à se former sur le tas, par son expérience bien sûr, mais aussi par des lectures adéquates.

Le problème des livres traitant de méthodologie est qu'ils sont là pour vendre un concept global: un gros sac de RUP, un colis d'UML ou un set de table complet d'XP. Bref les développeurs ont tendance à être noyés dans ces guides, surtout que dans la réalité il est quasiment impossible d'appliquer telle ou telle méthodologie de A à Z.

Le développeur préfère picorer et se forger avec son vécu sa propre méthodologie. C'est peut-être la définition de l'agilité, finalement: réussir à surfer sur la vague des méthodologies.

Dans cet exercice, il y a aussi le problème culturel. Dans les entreprises agile-friendly, qui ont forgé grâce à des champions XP par exemple, une culture de la qualité qui est insufflée à chaque nouvel arrivant, perpetrée et continuellement enrichie par tous, l'adoption et la compréhension ne se posent pas. A contrario, dans les environnements de travail hostiles à l'agilité, où il est par exemple commun d'entendre que "les tests unitaires ca ne sert à rien", le développeur qui souhaite progresser dans la méthodologie a une marge de manoeuvre restreinte et doit parfois se transformer lui-même en évangéliste pour continuer à progresser.

Bon mais pourquoi je raconte tout ça ? J'aurais pu vous parler de politique et vous inviter à prendre contact avec la présipauté de Groland pour préparer votre fuite en tant que réfugié politique si Sarkozy est élu. Non, je vous parle de méthodologie car j'ai trouvé ma bible sur le sujet !

"Practices of an Agile Developer", écrit Venkat Subramaniam et Andy Hunt himself, est un livre issu de la collection de Pragmatic Programmers, célèbre pour le livre "Pragmatic Programmer: from Journey Man to master", entre autres.



En ouvrant le livre et en lisant le sommaire, on se rend tout de suite compte de sa qualité: il est architecturé en conseils regroupés dans des chapitres à thème.

Chaque conseil est présenté suivant ce plan:

• Le conseil, en une phrase très courte. Exemple: "Keep it releasable"
• Un petit logo de diable qui critique ce conseil. Exemple: "On a trouvé un bug bloquant, arrête tout ce que tu fais et corrige-le sans te soucier de la procédure habituelle, on va envoyer un patch vite fait, personne ne le saura"
• Une section qui développe sur le sujet en quelques pages, et argumente contre la critique.
• Un petit logo d'ange qui conclu. Exemple: "soyez sûr qu'à tout moment votre projet est compilable, testable, et déployable"
• Une section "What it feels like", qui résume le gain de l'approche
• Une section "Keeping your balance", qui pondère la règle. Exemple: si vous devez envoyer un patch au plus vite, pensez à faire une branche dans subversion, pour ne pas rendre le système dans un état instable"

La seule chose qui manque pour que le livre soit parfait est une dernière section à chaque conseil, qui propose au lecteur un ou des conseils à lire ensuite, car l'ordre des conseils dans chaque chapitre m'a paru totalement arbitraire. Mais c'est minime.

Pour conclure, "Practices of an Agile Developer" devrait être lu par tous les développeurs, quelle que soit leur expérience. C'est un outil formidable pour progresser, mais aussi pour évangéliser vos amis: toutes les critiques faites à l'agilité sont décortiquées et démontées de manière intelligente, en suivant un argumentaire parfait.

Je lis maintenant "Interface Oriented Design" du même éditeur qui, je l'espère, me donnera autant de plaisir.