8 principes pour instaurer une culture d’engineering solide et explicite

Les équipes de développement dynamiques ont un aspect en commun : une culture d’engineering solide et explicite. Elles s’en inspirent pour bâtir, déployer et opérer des produits numériques remarquables, tout en travaillant en équipe.

Voici ma propre définition du concept de culture d’engineering : un ensemble de principes sur lequel une organisation ou une équipe aligne sa vision et ses décisions concernant ses pratiques d’engineering, tant sur le plan humain que technique. Dans cet article, nous présentons un exemple de culture d’engineering tout en vous faisant part de nos propres principes. 

Quelle est la fonction d’une culture d’engineering solide et explicite?

Une culture d’ingénierie solide et explicite répond manifestement à deux questions essentielles : « Comment faisons-nous quelque chose? » et « Pourquoi le fait-on de cette manière? » Si nous ne définissons pas cette culture, ce sera peut-être elle qui finira par nous définir. Dans les équipes plus petites, la culture se formera implicitement et organiquement. Mais, à mesure que les choses évoluent et que l’équipe s’agrandit, la culture risque de ne devenir qu’une habitude plutôt qu’une intention délibérée de réaliser une vision mutuelle, car les gens diront : « On a toujours fait ça comme ça! ».

Explicite vs. implicite

Dans une culture explicite, les choses sont claires. Nous en avons rédigé les concepts et nous en avons discuté ouvertement, nous les remettons constamment en question pour qu’ils s’arriment à l’évolution technologique et aux meilleures pratiques actuelles.

Valeurs abstraites vs. principes concrets

Tout le monde veut de la qualité et de la performance. Ce qui compte, c’est ce qui doit être fait pour y arriver, et que ce soit fait en équipe. Pour que la culture rejoigne les développeurs et les développeuses au quotidien, elle doit être exprimée selon des principes concrets et applicables plutôt que simplement des termes vagues et génériques.

Un exemple de culture d’engineering

Chez Mirego, nous réfléchissons à notre culture d’engineering et nous y travaillons depuis plusieurs années. Nous sommes arrivés à cet ensemble de 8 principes de base qui contribuent à de meilleurs résultats, à un travail plus soigneux, à des processus améliorés et, en fin de compte, à de meilleurs produits numériques.

1.   L’importance des milestones

Écrire du code, c’est awesome. Appuyer sur le bouton « Merge » dans GitHub, c’est gratifiant. Le produit représente la destination finale, mais les milestones du parcours méritent d’être soulignés. Si nous tenons compte des milestones, nous pouvons décomposer un projet important en parties plus petites et plus gérables. Pourquoi passer à côté de la satisfaction et de la confiance que procure le fait de savoir qu’on progresse bien?

2.  L’importance de la recette

Les meilleures équipes ne réinventent pas la roue, mais elles cherchent toujours à l’améliorer. Même la meilleure recette peut être perfectionnée. Nous cherchons à améliorer constamment les cadres de travail et les outils, mais nous le faisons de manière délibérée. Toutes les nouvelles tendances ne sont pas toutes bonnes à suivre. En essayant de nouvelles choses, nous atténuons aussi le risque d’échec. Il faut se donner du temps, ne pas changer tous les ingrédients de la recette à la fois. Il faut aussi être prêt à perdre certaines choses et à en apprendre.   

3.    L’importance de l’autonomie

Les équipes plus larges et dispersées sont confrontées au casse-tête suivant : comment favoriser l’autonomie tout en préservant également une vision commune? La réponse réside dans la différence entre les règles et les lignes directrices. Ces dernières offrent le plus de flexibilité. Elles s’appliquent 90% du temps, tandis que 10% du temps, elles peuvent valoir la peine d’être remises en question. Par exemple, la plupart du temps, nous utilisons Elasticsearch pour bâtir l’outil de recherche pour nos produits. Cependant, à un moment donné, il peut y avoir de bonnes raisons d’envisager un autre outil, elles doivent simplement être exposées. L’établissement de lignes directrices simplifie la prise de décisions tout en laissant assez de place pour prendre les meilleures décisions.

4.   L’importance de l’ownership

Ce principe consiste à trouver l’équilibre idéal entre l’ownership individuel et collectif. Cela prend un village pour faire un bon code (inspiration du fameux dicton). Mais, à quel moment le code cesse-t-il de m’appartenir pour devenir le nôtre? Quand on le révise. Chez Mirego, le code review ne consiste pas à critiquer le code créé par une autre personne, il s’agit d’en arriver ensemble à des idées pour améliorer davantage le code. Tout est question de s’entraider et de partager nos meilleures connaissances. C’est à ce moment-là qu’il devient « notre » code.

5.   L’importance de la constance

Écrire du code nous donne un sentiment de puissance. Quand il en sort un produit utile, c’est de la véritable magie. Mais, on revient vite à la réalité si on estime que 100% du temps notre code sera lu et bonifié par plus de personnes qu’il en a été nécessaire pour l’écrire au départ (une, soit vous). Vous oublierez rapidement pourquoi vous avez rédigé certains passages d’une matière, et les autres se gratteront la tête pour tenter de le déchiffrer. Au nom de la productivité, nous devons nous en tenir aux quatre mots suivants : « éviter le code clever ». Heureusement, il est facile aujourd’hui de garder un code propre et constant au moyen d’outils faciles à mettre en œuvre.

6.   L’importance de la patience

La meilleure partie de l’emploi, c’est d’écrire du nouveau code. Prendre le temps de créer un bon plan détaillé et d’y réfléchir en équipe peut sembler une corvée. Mais, devoir laisser tomber du code exceptionnel parce qu’il a été rédigé (à la hâte) en fonction des mauvaises hypothèses, c’est encore plus embêtant. Si on fait ses devoirs d’abord, qu’on élimine le plus de problèmes prévisibles possible et qu’on tire des leçons des équipes qui ont réglé des difficultés semblables, on se retrouve avec du bien meilleur code. L’étape de code review se fait alors beaucoup plus vite.

7.   L’importance des communautés

Les développeurs et les développeuses n’ont pas à travailler à partir de zéro. Habituellement, nous tirons parti d’une série de technologies open source comme Elixir, React, GraphQL, Kotlin Multiplatform, et Kubernetes. Ces technologies sont soutenues par des communautés fantastiques qui fournissent beaucoup plus que du code : meilleures pratiques, recettes de production et échantillons de code qui ont fait leurs preuves et qui sont prêts à l’emploi. Nous accueillons les contributions des communautés, car elles sont très utiles : elles standardisent les flux de travail parmi les équipes tout en facilitant l’intégration des membres. Cela permet également de redonner au suivant. Nous redonnons à la communauté en partageant notre propre expertise de travail avec ces outils, notamment le code de bibliothèque, les projets types et les contributions à la documentation.

8.   L’importance du craft

Ce dernier principe englobe tous les autres. C’est un état d’esprit sur lequel nous nous basons pour grandir en tant qu’équipe. Nous ne faisons pas que rédiger du code, nous réalisons quelque chose de plus important à l’aide de ce code. Nous devrions donc prendre le temps de bien y réfléchir et d’apprécider chaque étape. Le détail technique le plus insignifiant peut s’avérer décisif pour qu’un produit devienne excellent. Quand on cherche à créer un produit plus performant, on en tire une grande fierté. 

Voilà, nous vous avons présenté un exemple des principes qui favorisent, selon nous, une culture d’engineering solide et explicite. Pour nous, ils se sont avérés concluants au fil des ans et ils peuvent certainement aussi aider votre équipe!