Software Craftsmanship : une culture à transmettre

Le manifeste du mouvement Software Craftsmanship est sous-titré par Raising the bar, élever le niveau.

Nous pensons effectivement que c’est l’enjeu principal derrière les motivations de ce mouvement : pour créer des produits qui “déchirent”, il faut s'appuyer sur les personnes qui savent le faire, qui aiment le faire, et qui veulent toujours apprendre à le faire mieux.

Il ne s’agit pas que de pratiques à mettre en oeuvre : c’est une véritable culture du développement, qui implique des changements, dans les mentalités, dans le fonctionnement des équipes et de l’entreprise.

Mais une culture ça ne s’impose pas : comment faire entrer les valeurs du Craftsmanship dans l’entreprise afin qu’elles deviennent le standard et non l’exception ?

Pour approfondir le sujet : téléchargez notre livre blanc Culture Code - Software Craftsmanship, better places with better code (en francais)

Des valeurs et une vision du développement de logiciels

Atteindre un haut niveau de qualité n’est pas un enjeu nouveau, mais il est d’autant plus stratégique dans notre société où le logiciel devient omniprésent. A l’ère du numérique, du digital, il faut aller toujours plus vite et satisfaire ses utilisateurs pour ne pas se faire dépasser par la concurrence.

Le terme de qualité peut être porteur de nombreuses interprétations : je l'utilise ici pour parler d'un logiciel bien conçu qui apporte de la valeur :

• Construire un logiciel de qualité ne veut pas dire rechercher la perfection absolument et bâtir une cathédrale pour chaque produit.
• Il ne s'agit pas non plus de construire au plus vite l'application qui répond au besoin mais risque de s'effondrer à tout instant.

Construire un logiciel de qualité, c'est chercher cet équilibre, créer un système qui réponde à des besoins tout en reposant sur des bases saines.

La non qualité a un coût stratégique, mais aussi financier : une application truffée de défauts sera toujours plus coûteuse à faire évoluer, et les clients qui n’ont plus confiance risquent de ne plus vouloir payer.

Enfin, et on l’oublie souvent, la non qualité a un coût humain : travailler dans ce cadre devient vite démotivant, notamment pour les développeurs, au risque de voir les meilleurs partir dans une autre entreprise. Nous sommes convaincus que la majorité des gens ont la satisfaction du travail bien fait, et qu’il en va de même pour les développeurs, qui voudraient être fiers de leurs réalisations.

Atteindre un haut niveau de qualité, ce n’est pas simplement une question de produire des applications, du code de qualité : c'est une culture, une culture de la qualité logicielle.

S’il est important de regarder les artefacts produits et les pratiques qui permettent de les réaliser, il est surtout vital de s’intéresser aux facteurs qui favorisent cette culture dans nos entreprises.

Tous des Craftsmen ?

Il serait dommage de dire qu'il y a d'un côté des Craftsmen, des sortes de super développeurs qui se regroupent dans les Meetups et recherchent toujours la perfection, et de l'autre côté des développeurs lambda qui ne poursuivraient pas le même but ou n'auraient pas les bonnes compétences.

Il y a des personnes, des développeurs, qui travaillent au sein d'une équipe et d'une entreprise. Certains ont adopté ces valeurs, sont souvent passionnés par leur métier. Quelques uns ont même la possibilité de travailler dans des conditions permettant de réaliser des produits en accord avec leurs valeurs.

Malheureusement beaucoup d'autres développeurs n'ont que peu ou pas conscience qu'on peut réaliser des logiciels autrement. On fait encore aujourd’hui le constat que beaucoup des pratiques de développement qui contribuent à des réalisations de qualité ne sont tout simplement pas enseignées à l'école.

D'autres encore pensent que ce n'est tout simplement pas possible dans leur entreprise, qu’il est impossible de changer les choses.

Alors oui, on pourrait appeler Craftsmen ces développeurs convaincus par les valeurs du mouvement et les différencier des autres. Mais l'objet du mouvement Software Craftsmanship n'est pas de catégoriser les développeurs. Les autres développeurs ne sont pas forcément des mauvais développeurs ou une catégorie différente, ils n’ont simplement pas eu l’occasion d’expérimenter cette culture. Le véritable enjeu n’est pas là : il est culturel.

Quelle réponse apporter à ce problème ? Pour certains, si les valeurs Craft ne sont pas établies dans une entreprise, c’est qu’il faut changer de boîte. C’est parfois une solution, individuelle, mais que faire pour ceux qui restent, que faire si votre nouvelle boîte n’est finalement pas si parfaite ?

Je prends pour exemple ma propre expérience et je suis convaincu que beaucoup s’y reconnaîtront : pendant mes premières années en tant que développeur, je connaissais tout juste l’existence des tests unitaires ou de l’intégration continue. C’est simple, je ne l’avais pas appris à l’école, et les gens avec qui je travaillais non plus. Pourtant j’essayais de faire de mon mieux, de produire des applications dont j’étais fier. Puis j’ai rencontré un développeur passionné, qui m’a transmis certaines pratiques et exhortait ses collègues à les utiliser. J’ai ensuite participé à un autre projet où cette culture était centrale. Et ainsi de suite, jusqu’à vouloir moi-même transmettre cette culture, convaincu que c’est une bonne manière d’exercer mon métier.

Je ne suis surtout pas en train de dire que tout le monde doit changer et se plier à une sorte de "religion" Software Craftsmanship. Tous n’adhéreront peut être pas stricto sensu, mais ce n'est pas l'objet de cet article : je suis simplement convaincu que ces valeurs ont intérêt à être partagées et qu'il y a encore du chemin à faire dans beaucoup d'entreprises.

Alors, comment diffuser cette culture ? Comment influencer le cours des choses ?

Adopter la culture de l'artisanat logiciel

Lorsque nous parlons de Craftsmanship, nous pensons professionnalisme du développement logiciel et responsabilité de chacun dans l'accomplissement de son métier. Une certaine vision du métier de développeur permet la réalisation de produits de qualité qui répondent au mieux à un besoin donné, le bon aboutissement des projets et le maintien de ces produits dans la durée. C'est aussi une posture pragmatique : on ne cherche pas absolument la perfection, on cherche à faire au mieux en tenant compte du contexte.

Certaines pratiques nous semblent vitales pour atteindre cette qualité efficacement, telles que le développement dirigé par les tests (TDD, BDD…), l'application de standards de code propre (Clean Code) ou la pratique du Design Emergent pour citer quelques exemples.

Enfin, on cherche à apprendre, encore et toujours, car nous pratiquons un métier en perpétuelle et rapide évolution :

• en lisant des livres, des blogs,
• en s'entraînant, en pratiquant de nouveaux outils, de nouveaux langages,
• en rencontrant d'autres développeurs à des conférences, des meetups,
• en trouvant des mentors.

Mais adopter cette culture, chacun, individuellement, n'est pas suffisant : ils ont beau pratiquer TDD assidûment, aller à des meetups régulièrement, de nombreux développeurs se sentent seuls dans leur entreprise. Ils ont l'impression de ne pas partager les valeurs de certains collègues ou de se heurter à un mur lorsqu'ils parlent de ces valeurs avec le management.

Transmettre ses valeurs et ses pratiques

La plupart des produits sont réalisés en équipe, et ces réalisations sont le fruit d’un travail commun.

Pour diffuser la culture de la qualité au sein de l’équipe, on peut s’appuyer sur plusieurs pratiques :

• Apprendre et transmettre les pratiques de développement via le binômage, l’organisation de dojos.
• Garantir une propriété collective du code en organisant des revues de code par paires ou collectivement, mais aussi en évitant que chaque développeur travaille seul sur son périmètre.
• Établir ensemble des standards de développement et les faire vivre.
• S’appuyer sur les outils de l’intégration continue pour réduire la boucle de feedback.

Un exemple parmi d’autres : sur un précédent projet, nous avions mis en place un créneau de Coding Dojo ritualisé toutes les deux semaines, au cours duquel nous partagions nos pratiques en prenant du recul par rapport au quotidien du projet. Selon les séances, c’était l’occasion d’expérimenter de nouvelles technologies et décider de leur usage futur sur le projet, de partager de nouvelles techniques de code et de faire évoluer nos standards ensemble.

Ces pratiques sont essentielles pour favoriser la culture de la qualité, mais pour y parvenir, il est nécessaire de rompre avec certaines habitudes qui se sont ancrées dans l’entreprise.

L’activité de développeur est encore trop souvent perçue comme une activité solitaire, ce qui provoque deux biais :

• les pratiques de développement collectives comme le binômage sont perçues par les acteurs non techniques des projets comme un surcoût conséquent alors que certaines études tendent à prouver le contraire ;
• les développeurs qui ont été habitués à travailler seuls peuvent avoir des difficultés à travailler à plusieurs, ne serait-ce que montrer leur code ou en parler. Sur cet aspect, il est nécessaire d’adopter une posture positive, d’apprendre à donner et recevoir du feedback sans pointer les autres du doigt. Les principes d’Egoless programming vont dans ce sens.

Favoriser la culture de la qualité à l’échelle de l’équipe n’est pas une chose aisée, c’est une véritable conduite du changement à mener. Une simple formation de quelques jours aux pratiques ne fera pas une équipe d’artisans aguerris. Cela prend du temps et on ne peut pas forcer les gens à changer.

Pour cela, il est utile de s’appuyer sur les personnes qui maîtrisent le mieux les pratiques, de s’appuyer sur un Tech Lead qui va aider l’équipe à progresser jusqu’à ce qu’elle devienne autonome. Et si cette personne n’est pas présente au sein de l’équipe, on peut faire appel à une personne extérieure à l’équipe, qui pourra la sensibiliser, la former, l’accompagner.

Une culture à l’échelle de l’entreprise

On a vu que le développement de cette culture est favorisé par des rencontres, par des personnes qui souhaitent partager leur savoir-faire et leur savoir-être, et qui souhaitent apprendre encore et toujours dans notre métier en perpétuelle évolution.

À l’échelle de l’entreprise, développer cette culture peut sembler une tâche titanesque pour quelques individus, c’est pourquoi il est vital que les décideurs permettent les conditions favorables à ces rencontres.

Plusieurs actions concrètes peuvent être mises en place :

• soutenir les démarches d’amélioration continue comme les revues de code, en laissant les équipes s’organiser. Les développeurs sont des professionnels du développement, il est indispensable de leur accorder une certaine autonomie dans leurs pratiques,
• créer des espaces de rencontre entre les équipes, favoriser l’émergence de communautés de pratiques. Par exemple chez OCTO, des BBLs sont organisés presque tous les midis, et le troisième jeudi de chaque mois est réservé pour l’organisation des BOFs, au cours desquels chacun peut partager un retour d’expérience,
• dédier un budget à l’apprentissage dans tout projet, afin que chacun ait un autre choix que prendre sur son temps personnel pour apprendre, et surtout, que les gens puissent apprendre collectivement,
• revoir l’organisation de l’espace et des bureaux pour favoriser un travail collectif,
• identifier les leaders d’influence et leur donner le mandat pour diffuser leurs valeurs et leurs pratiques, en animant la communauté, en accompagnant et en coachant d’autres équipes.

Au risque de me répéter, il faut néanmoins être vigilant et ne pas chercher à passer à l’échelle trop rapidement : ce n’est pas parce qu’une équipe a adopté un certain nombre de pratiques qu’il faut chercher à les imposer à toute l'organisation. On ne peut pas changer les gens, mais on peut les inspirer, et une culture d’entreprise y contribue grandement.

Par où commencer ?

• La prochaine fois que vous rencontrez une difficulté sur votre code, demandez de l'aide à vos collègues et proposez une séance de binômage ou une revue de code collective.
• Faites de même la prochaine fois que vous pratiquez TDD (remplacer par n'importe quelle pratique), proposez de binômer à un collègue qui n'a pas l'habitude de cette pratique.
• Prenez le temps de discuter avec des collègues d'un article qui vous a marqué.
• Organisez un dojo sur cette nouvelle librairie que vous souhaitez mettre en place sur votre projet.
• Allez voir cette autre équipe qui travaille sur des sujets et des technologies proches des vôtres et échangez sur vos pratiques.

Que se passe-t-il ? Qu'est-il ressorti de ces rencontres ? Qu'avez-vous appris ou transmis ?

Conclusion

Le mouvement Software Craftsmanship propose une vision du métier de développeur, et celle-ci ne doit pas seulement considérer les individus, mais apporter une vision du métier dans l'entreprise, qui promeut une culture de la qualité et de l’apprentissage permanent. La création de logiciel est un métier passionnant et même plutôt fun, pour peu qu'on puisse l'exercer avec application et professionnalisme.

Ça tombe bien, c'est un enjeu absolument crucial pour l'entreprise : notre société toute entière repose sur des logiciels, et la tendance n'est pas près de s'inverser. Il est de notre responsabilité d'adopter des valeurs et des pratiques permettant de réaliser des logiciels de qualité, et le mouvement Software Craftsmanship en est une bonne expression.