Blog Arolla

Le Software Craftsmanship, pour la professionnalisation du métier de développeur.

Le Software Craftsmanship est un mouvement qui vise à professionnaliser notre métier pour développer les méthodes de travail reconnues et pour enfin pouvoir tenir nos engagements. Nous sommes vus comme des « geeks » et non pour des partenaires, nos projets ne tiennent pas assez souvent les trois fameux critères que sont le coût, la qualité et le délai. C'est plaisant d'être geek, mais nos arguments manquent de poids face aux managers. Nous sommes souvent en retard dans nos projets, mais est-ce toujours de notre fait ? Pourquoi sommes-nous parfois tenus responsables de ne pas avoir satisfait une contrainte que l'on nous a imposée ? Comment pouvons-nous améliorer notre image dans l'entreprise jusqu'au point d'être vu comme des partenaires et ainsi avoir une influence réelle sur notre façon de travailler et sur nos engagements ? Le Software Craftsmanship veut la professionnalisation de notre métier et c'est une solution à notre plus gros problème actuel.

L’ingénieur n’est pas un technicien

L'informatique a débuté par de l'électronique, a continué par de la programmation en assembleur. Le métier était alors cantonné aux domaines techniques. Les langages de programmation ont offert une abstraction de ces contraintes techniques. Avec l'orienté objet, nous pouvons modéliser le métier de nos clients. Avec l'agile, nous pouvons faire le minimum de logiciel suffisant pour les satisfaire. Avec les pratiques XP, nous garantissons que le logiciel est maintenable et qu'il fonctionne dans tous les cas prévus. Et nous avons gardé cette image de technicien, de geek qui ne s'intéresse qu'à la technique et qui ignore les enjeux de l'éditeur du logiciel. Nous sommes vus comme des « cols bleus » et cela semble être une « zone de confort » pour nombre d'entre nous. Sauf que lorsque les décideurs arrivent avec des contraintes (évolution de dernière minute, délai raccourci, etc.), nous ne sommes pas vus comme des partenaires, des légaux ou des « cols blancs ». Ces contraintes nous sont souvent presque imposées parce qu'avec notre image de col bleu, nous manquons souvent de poids pour la négocier. Nous aurions pu négocier un délai qui nous aurait permis d'implémenter correctement une nouvelle évolution ou retirer une évolution de faible valeur de la version en cours de développement, etc. Nous nous retrouvons a essayer de tenir des engagements pris pour nous par des managers qui ne sont actuellement pas des développeurs. Régulièrement, nous ne tenons pas ces engagements et notre image en souffre...

Être un professionnel du développement

Qu'est-ce qu'un professionnel du développement logiciel ? C'est ici que le flou de la définition du Software Craftsmanship commence. Cette question est un débat ouvert que je ne vais pas clore ici tout seul, il y a une communauté de Craftsmen pour cela. Même si nous n'avons pas de consensus sur une définition, nous pouvons reconnaître un professionnel. J'en ai croisé de nombreux dans divers meetups, sur des groupes de discussions (mailling lists), en mission et ailleurs qui avaient chacun leur propre style, leurs qualités et défauts. Les qualités les plus fréquentes et appréciées étant le savoir-faire, l'engagement et le pragmatisme. En bref, ils sont fiables, donc les autres développeurs les écoutent lorsqu'ils parlent.
Par contre, être le seul professionnel du développement de l'équipe ne suffit pas. A moins d'avoir un poste de représentation de l'équipe (scrum master, tech lead, référent technique, etc.) et encore... Comme tout le monde n'a pas la même productivité sur chaque élément du logiciel, il n'est pas toujours facile de s'engager correctement à la place des autres. De plus, lorsqu'une contrainte extérieure survient, il est utile d'avoir des collègues pour aider à la négocier et argumenter un point de vue.
Le mouvement Craftsmanship se distingue des professionnels sur un détail. Le mouvement souhaite que tous les acteurs du métier deviennent professionnels et que cela deviennent la norme. Il faut donc que chacun soit capable de se professionnaliser, puis d'aider tout ceux qui le souhaitent à se professionnaliser.

Soyons tous professionnels

Donc nous devons aider tous ceux qui souhaitent se professionnaliser. Mes objectifs sur ce thème sont simplement de partager mon point de vue et d 'écouter celui des autres sur ce qu'est un professionnel, comment le devenir et comment en faire un normalité dans notre métier de développeur. Un bon point des Craftsmen est qu'ils nous aident à devenir professionnels ! Nous ne sommes pas seuls. Des communautés de professionnels adressent nos problèmes d'organisation, de technique, de production, d'outillages divers. De manière générale, nous avons besoin de maîtriser notre temps, nos outils et nos méthodes, être soucieux du résultat de notre travail et être capable de s'engager et probablement être à jour...
Lorsqu'on nous demande une estimation, elle doit être fiable, donc transformable en échéance (deadline, pour les geeks). Tant pis si les commerciaux ignorent vos avertissements, vous aurez une trace écrite et une preuve de bonne foi.

Lorsque l'on nous demande d'estimer quelque chose que l'on n'a jamais fait, il est difficile de s'engager sauf en prenant en compte l'incertitude et, notamment, la diffuser aux manager qui ont, de toutes façons, besoin d'échéances. En dehors de l'estimation d'une activité inconnue, vous devez pouvoir fournir des estimations fiables et, hum, cela fait partie de mes axes d'améliorations personnels.

Il existe une métaphore de l'artisan à propos des méthodes et outils. Comme un artisan a de bons outils, un développeur connaît bien ses outils dont les raccourcis clavier. On lit les documentations des outils qu'on utilise, etc.
Les bonnes idées apparaissent et ré-apparaissent n'importe quand, Il nous faut donc réaliser une veille technologique où l'on cherche les grandes idées, les grands auteurs, les grands livres, bref les mots-clefs des bonnes pratiques dont vous entendez parler (BDD, TDD, DDD, XP, Craftsmanship, CI, CD, Scrum, Kanban, …). Il suffit de mon point de vue de savoir ce qui existe et de s'en faire une opinion vis à vis de notre projet actuel. Cela peut sembler trivial, mais tout le monde ne fait pas ce travail.
Un Software Craftsman, en plus de devenir (ou être) professionnel, essaie de propager ce professionnalisme. A défaut d'attendre que les autres changent, il peut, comme disait Gandhi, « être le changement qu'il souhaite voir dans ce monde » et donc être le moteur de la professionnalisation de son équipe, le but étant d'améliorer la qualité du travail de l'équipe pour se donner les moyens de tenir des engagements pris par l'équipe elle-même.

Soyons le changement au service de notre équipe

Par exemple, une fois que l'on a découvert une pratique, une méthode, un outil pertinent pour améliorer notre quotidien professionnel, il faut l'essayer. Les plus motivés peuvent le faire chez eux, mais les nombreux meetups ouverts ou réveillés cette année vous fourniront des gens expérimentés capables de vous proposer des exercices (Kata), des références et tutoriels de qualités, voire d'organiser des travaux pratiques courts (Dojo) ou long (code retreat). Libre à vous de les interviewer selon vos besoins. Ces meetups s'orientent aussi bien sur des méthodes agiles, des pratiques XP, TDD ou des technologies, outils comme Docker ou Ansible et bien d'autres. Si cet essai est convaincant, vous allez naturellement l'essayer dans un coin de votre projet professionnel et le montrer à vos collègues pour qu'ils profitent aussi de cette avancée.
En fait, avoir un exemple de la nouveauté dans le contexte de votre projet professionnel au lieu d'une copie d'écran d'un tutoriel venu d'un site web « publicitaire » peut faire la différence. L'exemple n'est plus théorique, n'est plus une promesse, mais c'est alors un cas pratique, réel, concret, une démonstration d'un résultat que l'on sait obtenir ! Ce cas pratique est aussi un moyen d'aider vos collègues à évaluer et s'approprier votre proposition. Une fois l'équipe avec vous, ou au moins un allié, vous n'avez plus qu'à expliquer à celui qui tient le portefeuille que vous souhaitez travailler d'une nouvelle façon... En même temps, si la nouveauté ne coûte rien, le débat est clos quand l'équipe de développeurs a décidé d'utiliser votre idée (ou non).
Si votre proposition a un réel intérêt et un coût, les problèmes commencent : vous devez convaincre vos managers de financer l'investissement nécessaire. Je parle ici d'investissement en coût comme pour une formation, mais aussi en temps comme pour une nouvelle pratique s'ajoutant aux existantes (ie : BDD en plus du TDD). Un investissement est censé apporter plus que ce qu'il ne coûte et non faire plaisir aux gentils geeks. Vous devrez montrer que les tests garantissent une non-régression, que le BDD évite les mal-entendus sur des subtilités d'une spécification complexe, etc. Avoir comparé vos arguments avec un groupe de personnes ayant eu les mêmes défis que vous, vous donnera confiance en vous et en vos arguments. Il est donc très utile de faire part de ces réussites à votre équipe. Cela appuiera votre discours et vos arguments à coup sûr.

Soyons des professionnels de confiance

Le fait d'être vu comme un professionnel, donc d'avoir des partenaires qui ont confiance dans votre parole et vos engagements change la donne. En effet, il est difficile encore aujourd'hui de tout chiffrer et justifier un retour sur investissement sans études quantifiées. Par exemple, les tests montrent qu'un logiciel a un fonctionnement nominal (un fonctionnement correct dans les cas prévus) et que ces tests assurent une protection contre des régressions (pertes de fonctionnalités). Un décideur doit juste vous croire quand vous lui annoncez que sans test, il est impossible de garantir qu'un bon fonctionnement existe. Comment faites-vous ou font-ils pour chiffrer le coût d'une régression détectée en production ?
Un artisan, un médecin, un avocat, un professionnel fait quelque chose que les autres ne sont pas ou peu capables de faire, voire de comprendre. On prend des garanties, là où on peut, on se met d'accord sur un devis, un contrat ou un engagement et on les laisse faire à peu près comme ils l'entendent... Être vu comme un professionnel fiable est « l'argument massue » qui nous manque. Pour être vu comme cela, il faut d'abord le devenir, l'être et le faire savoir ! Pour accélérer ce mouvement, si vous avez les épaules, certains disent « faites semblant, jusqu'à le faire vraiment ». C'est un mot d'ordre pour imiter les autres partenaires (métier comme technique) pour apprendre d'eux. Cela permet de s'intégrer, d'améliorer sa communication et d'être une personne avec qui on parle. Vous aurez ainsi plus d'informations sur les enjeux des autres et leurs contraintes. Un autre moyen est de commencer par des petits succès faciles et visibles (quick-wins). J'ai vu un collègue arriver sur un projet et corriger tous les petits bugs qui traînent et qui étaient faciles à corriger au lieu de prendre ceux qu'on lui demandait et qui avaient une urgence ou de la valeur... On le lui aurait bien reproché (y compris notre chef), mais en passant de 150 bugs à 75, la pression sur notre projet est étrangement retombée ! Le fait d'avoir des succès visibles, de parler un même langage que vos interlocuteurs aide ces derniers à vous faire confiance. N'hésitez pas à faire ce que vous dites, à dire ce vous faites et à réussir ce que vous faites.
Les Software Craftsmen cherchent à se professionnaliser et à aider les autres à faire de même. C'est importants à mes yeux car nous avons de quoi mieux faire notre travail, dans de meilleures conditions et avec de meilleurs résultats. Les bonnes pratiques XP et devops font consensus dans le métier, dans les conférences, mais elles sont rarement enseignées dans les écoles et universités. Les acteurs du logiciel ne s'approprient pas toujours les méthodes agiles. Vous devez exercer vos talents dans un contexte professionnel, en montrer les résultats et améliorer le travail de votre équipe. Si cela ne suffit pas, vous aurez parfois besoin de vous appuyer sur une communauté de professionnels pour asseoir la légitimité de ces pratiques.

Être capable de s’engager et être l’auteur de ses engagements

Bref, nous devons devenir les auteurs des engagements qui nous impactent ou qui impactent nos logiciels. Les décideurs ont des contraintes légitimes qui doivent être satisfaites. Nous aussi ! Leurs nouvelles contraintes ont des impacts sur nos échéances ou sur les fonctionnalités à livrer ou sur la durée de vie du logiciel, c'est-à-dire le temps durant lequel nous seront capables de le faire évoluer avec des délais et des coûts raisonnables, voire en maintenant simplement la rentabilité. Nous devons avoir notre mot à dire pour accepter leurs contraintes, et ce mot sera un engagement à tenir. C'est ainsi que l'on aura des réussites, puis de la confiance et une écoute de plus en plus bienveillante. Nous apprécierons cette écoute lorsque l'on souhaitera apporter un moyen d'obtenir des gains de qualité qui ne sont pas chiffrables et invisibles pour le commun des mortels comme des gains de lisibilité du code et de maintenabilité. Nous devrions tous être craftsmen pour améliorer notre savoir-faire au travail, devenir plus fiables et faire progresser notre métier pour passer des huttes aux cathédrales. Les écoles et universités explorent la science des technologies de l'information, mais certaines sont à l'écoute du marché pour adapter leurs programmes comme Thalès université, l'école 42, des écoles d'ingénieurs privées et/ou en alternances, mais aussi les universités comme Marne-La-Valée ou Paris Diderot. Nous devons promouvoir des communautés de professionnels pour diffuser les bonnes pratiques, ensuite faire établir un consensus dans le métier sur l'emploi de ces pratiques et enfin, faire enseigner ces pratiques dès l'école.

 
 
 

Quelques liens pour en savoir plus:

https://fr.wikipedia.org/wiki/Software_craftsmanship

http://manifesto.softwarecraftsmanship.org/

http://www.meetup.com/fr/paris-software-craftsmanship/

http://www.amazon.com/Software-Craftsmanship-The-New-Imperative/dp/0201733862

Plus de publications

2 comments for “Le Software Craftsmanship, pour la professionnalisation du métier de développeur.