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)
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é, 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.
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 ?
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 :
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.
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 :
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 :
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.
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 :
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.
Que se passe-t-il ? Qu'est-il ressorti de ces rencontres ? Qu'avez-vous appris ou transmis ?
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.