Un développeur a-t-il besoin d’une permission pour écrire des tests ? Pratiquer le Test-Driven Development ? Faire du refactoring ? Travailler en Pair Programming ? Faut-il un permis à l’image de la légendaire licence to kill de James Bond ?

Ma réponse est NON (sans surprise, comme la plupart des articles qui commencent avec une grande question fermée). Un développeur doit être autonome et décider de lui-même pour ce genre de pratiques. Il n’a pas à demander l’autorisation à un manager, ni un chef, ni un PO, ni un SM, ni même à un tech lead ou un autre développeur.

Encore moins se voir interdire (anecdote récente lors d’un entretien technique, un développeur m’a indiqué que son client lui interdisait d’écrire des tests parce que ça prenait du temps). Au contraire, il faut promouvoir et pousser ces pratiques aux développeurs et aux équipes.

Ça fait partie du job

L’écriture de tests, le TDD, le Refactoring, le Pair Programming, et j’en passe, ce sont des pratiques répandues dans l’industrie. Elles sont reconnues et proviennent de mouvements comme le Software Craftsmanship, l’eXtreme programming, ou le Domain Driven Design. Ce n’est pas le n-ième nouveau super framework à la mode.

On parle ici de pratiques qui améliorent la qualité du code et du produit, qui facilite le changement, qui permettent de mieux collaborer, de mieux retranscrire le métier. Elles font partie intégrante du métier de développeur.

Un développeur n’est pas un exécutant. Il n’est pas là juste pour pisser du code. Il a un (grand) rôle à jouer pour concevoir un produit de qualité. Il existe de nombreux ouvrages sur ces pratiques et également sur la posture de développeur. Pour en citer un, Sandro Mancuso en parle très bien dans son livre The Software Craftsman.

Just do it

Je donnerais comme conseil aux développeurs de faire, de passer à l’action, d’utiliser ces pratiques. Sans attendre une permission officielle, sans aller chercher une approbation quelconque. Faites-le, tout simplement.

Il y a un proverbe qui dit Il vaut mieux demander pardon que demander la permission. Je l’aime bien, et je trouve qu’il a du sens dans cette situation. Vous êtes développeur et vous hésitez ? Lancez-vous, essayez, montrez par l’exemple. Probablement, quelque chose de bon en sortira et on ne viendra pas vous taper sur les doigts. Ce n’est pas parfait ? Vous deviendrez meilleur en continuant d’essayer et de vous améliorer.

Rappelons que le développeur a l’expertise. Il sait comment travailler, il connaît sa boîte à outils. Mon propos n’est pas d’enfermer le développeur dans sa vision - il doit rester ouvert, comme tout le monde - mais de lui faire confiance et de lui donner de l’autonomie.

Ce qui n’empêche pas de le challenger. Et quand on touche à ses limites, à sa zone où il ne maîtrise pas, on se penchera plutôt sur comment former, comment apprendre, comment expérimenter, plutôt que d’empêcher.

Former les équipes

Ça fait partie du job, d’utiliser ces pratiques, ça fait également partie du job de se former. Elles ne tomberont pas soudainement du ciel. Avis aux développeurs qui doivent faire l’effort autant qu’aux managers qui doivent investir ;)

On se forme, on forme les équipes, on expérimente, on s’améliore en continue. Le retour sur l’investissement est positif, on ira plus vite, on délivrera mieux. On veut démarrer un cercle vertueux (on apprend, on améliore le code, on change plus facilement, on livre plus vite, on satisfait davantage l’utilisateur) plutôt que vicieux (on empêche, on n’apprend pas, le code se détériore, les évolutions deviennent difficiles, on cumule des problèmes, on met du temps à livrer à l’utilisateur).

Il y a un tas de moyens pour apprendre. Quelques idées : inviter des personnes à faire un BBL, l’intervention de coachs, faire des katas seul ou en groupe, du mob-programming sur le projet, assister à des conférences, lire des livres, etc.

Casser les idées reçues

Et s’il y a du blocage, des interdictions, des permissions à demander pour utiliser ces pratiques ? J’essaierais de comprendre pourquoi, de challenger, de rappeler que ça fait partie du job, et de casser certaines idées reçues.

En rappelant la vision, la philosophie de certaines pratiques. Le refactoring, ce n’est pas un chantier de 3 mois en tunnel. Ce sont des petites étapes, ce sont des améliorations que l’on fait au quotidien, qui facilitent le changement, qui améliorent la qualité.

L’écriture de tests et le TDD, ce n’est pas plus long. C’est une aide pour le développeur, un guide pour bien retranscrire le métier, le comportement. On obtient en plus de la sérénité quand il faut effectuer des changements. On entre dans des situations où l’on ira plus vite.

Le Pair-Programming, ce n’est pas juste deux ressources humaines qui se mettent sur un poste pour travailler sur un seul problème à la fois. C’est une collaboration poussée, c’est un feedback rapide, c’est une transmission de connaissances, d’informations, c’est de l’amélioration en continue. Là aussi on entre dans des situations où l’on ira plus vite.

On améliore la qualité, on gagne du temps, on gagne de l’argent. Trois arguments que l’on peut aligner en fonction de l’interlocuteur. On pourrait citer en touche finale Accelerate, un livre qui montre, via une étude sur plusieurs années incluant de très nombreuses entreprises, qu’il y a une corrélation entre la performance technique et la performance business.