Chaque semaine, découvrez un chapitre du livre de Sandro Mancuso sur le craftsmanship ! [Chapitre 2]

Il est un terme qui revient de plus en plus souvent dans les tweets, les articles de blog ou les conversations entre développeurs : le software craftsmanship. C’est un terme fédérateur qui regroupe énormément de choses. Mais parle-t-on toujours de la même chose ? Est-ce qu’un développeur aura la même vision du software craftsmanship qu’un manager, qu’un Product Owner ou qu’un CTO ?

C’est pour tenter de répondre à cette question que nous avons réalisé une expérience chez Xebia : la lecture participative. Nous avons chacun choisi de résumer un ou plusieurs chapitres de l’excellent livre Software Craftsmanship – Professionalism Pragmatism Pride de Sandro Mancuso, nous permettant une lecture synthétique et une diffusion plus rapide du contenu.

Au départ seulement destiné à un usage interne, nous vous proposons de retrouver chaque semaine le résumé d’un chapitre dans ce blog avec l’accord de Sandro Mancuso. Vous pourrez d’ailleurs le rencontrer chez Xebia lors d’un évènement exceptionnel mardi 30 septembre. Si ce sujet vous intéresse, il existe également une formation dispensée par Sandro.

Déjà publié:

1. Software Development

En février 2001, aux États-Unis dans la station de ski de Snowbird, dix-sept spécialistes du développement logiciel se sont réunis. De cette réunion devait émerger le Manifeste agile, considéré comme la définition canonique du développement agile.

Plus d’une décennie s’est écoulée et nous sommes forcés de constater que le process ne remplace pas la qualité des personnes, l’agilité est une belle idée mais n’a pas en aucun cas réglé le problème de la qualité logicielle !

L’agilité peut se diviser en 2 sous-groupes : Process-oriented and Technical-oriented.

• Process-oriented, comme Scrum : on établit des règles et on travaille à améliorer la collaboration. Les méthodes orientées « process » aident les équipes à ce concentrer sur les fonctionnalités ayant le plus de valeur pour le business.
• Technical-oriented, comme TDD, pair-programming : on s’attache à améliorer la qualité du code. Ces méthodes se concentrent sur les challenges de faire grossir, maintenir et livrer le logiciel en lui-même.

Être agile, c’est raccourcir la boucle de feedback pour pouvoir réagir au plus vite et s’améliorer. L’agilité ne règle pas les problèmes, elle les met en lumière.

« Être agile »

On ne fait pas de l’agile, on est agile.

L’agilité a changé la donne… Là où les spécifications étaient à rallonge et le « big design up-front  » nous livrons des applications toutes les 2 semaines, là où le changement faisait peur, nous l’embrassons aujourd’hui.

La hiérarchie des équipes de développement devient horizontale, on parle d’auto-organisation. Les développeurs ne voient plus leurs tâches assignées par le manager, ils les choisissent en fonction d’une priorisation définit par le client/le métier. La vision est partagée et l’équipe oeuvre à la réaliser. L’auteur utilise le terme d’empowerment : il s’agit d’un processus par lequel un individu ou un groupe acquiert les moyens de renforcer sa capacité d’action, de s’émanciper.

Pour embrasser ce mode de pensée, le développeur doit devenir un professionnel, un artisan du code. Il doit parfaire sa technique, remettre en cause ses connaissances et se mettre a niveau constamment.

Ndlr: je vous invite à lire An Agile Adoption and Transformation Survival Guide de Michael Sahota en téléchargement libre.

La gueule de bois des transformations agiles

Quand on fait l’état des lieux des transformations agiles faites ces dernières années, nous sommes forcés de reconnaître que nombre d’entreprises créent aujourd’hui de manière constante et itérative des applications de mauvaise qualité ! Être agile implique des notions qui ont été oubliées : le process est devenu plus important que l’excellence technique.

L’auteur fait un constat à propos de ces transformations agiles, elles sont bien souvent partielles : les consultants et les coachs en charge de la transformation ont transformé les process mais n’ont rien fait ou très peu pour aider les entreprises à écrire du code de qualité, rien n’a été fait pour rendre les développeurs meilleurs.

Il y a une réflexion intéressante sur Toyota et le Lean, qui est souvent prise en exemple par les acteurs du changement agile. Toyota fait des voitures, ce qui est très différent de faire des logiciels ! On n’utilise pas une voiture tant qu’elle n’est pas finie, on ne retourne pas chez le concessionnaire après l’achat pour demander une porte en plus ou mettre le moteur dans le coffre !

Un des facteurs de réussite de Toyota, en plus d’un bon process, c’est de faire des voitures de qualité. Pour y arriver, il faut des gens compétents ayant envie de bien faire les choses, faire des points réguliers pour se remettre en question, corriger et améliorer.

Les coaches agiles

Y’a le bon et le mauvais coach… Le bon il connaît le process. Le mauvais il connaît le process… MAIS C’EST PAS PAREIL !

Le mauvais coach il a oublié l’expertise technique. Il faut reconnaître qu’il est bien plus simple de vendre au management du process que de l’expertise technique. Mais quelques mois plus tard quand la transformation agile aura échouée, il y a des chances que le mauvais coach mette en cause les développeurs. Mais est-ce qu’une transformation « process » les a vraiment aidé ?

Il existe de très bon coachs et consultants agile mais quand vient le moment de conseiller des approches comme le pair programing ou le TDD qui – à première vue – semble faire perdre du temps et ralentir le développeur ; quand le manager demande ce qu’il fait de son équipe de Q/A ; quand les développeurs eux-mêmes refusent de tester leurs codes argumentant du célèbre « tester c’est douter » ; il faut éduquer l’organisation et ce travail de longue haleine passe par un changement de culture qui nécessite d’investir dans la connaissance et l’apprentissage.

Agile vs. Software Craftsmanship

Il ne faut pas penser que le Software Craftsmanship remplace l’agile. Les méthodes agiles aident les compagnies à « make the right thing ». Le Software Craftsmanship professionnalise le développement informatique. Il aide les développeurs et les entreprises à « do the thing right ».

Le chapitre suivant sera consacré au Software Craftsmanship