Après avoir choisi votre flow Git, et donc défini comment vous allez échanger avec vos collègues, il est temps de passer à la seconde étape de la cohésion technique de votre projet, de votre équipe. Comment s’assurer que votre équipe va grandir, s’améliorer, et surtout produire du code de qualité ? Voyons ensemble la seconde étape de la cohésion technique : la culture de l’apprentissage.

Un objectif à atteindre

Quel est l’objectif numéro 1 lorsqu’on crée un projet de développement ?

D’un côté, les uns vont vous dire qu’il s’agit de produire un projet d’une qualité parfaite, un projet exempt de bugs, et bien organisé, respectant le clean code, la clean architecture.

De l’autre, nous entendrons au contraire une volonté de respecter les besoins client-e-s à tout prix. La qualité de code n’étant pas une nécessité. Des arguments qui peuvent d’ailleurs s’entendre à l’heure du No code : la qualité n’est pas un but en soi, seule la réponse aux besoins client-e est respectée.

Bon, si on partait ensemble sur un développement custom, spécifique, permettant de répondre précisément aux besoins du client, de la cliente ?
N’est-ce pas un mixte des deux : respect des besoins et qualité de code ?
C’est par exemple ce que tente de proposer DDD comme approche, avec un Ubiquitous langage, un event storming, des domain models, …

Oui, et pourtant, il y a un mais, un vrai gros MAIS.
La qualité ne se produit pas directement, elle s’acquière avec le temps, avec l’expérience, la remise en question, l’apprentissage.
Le développement logiciel est, était, et sera toujours un état de l’art (vive l’artisanat du code).

AINSI, ON POURRAIT RACCOURCIR TOUTES NOS DÉCISIONS, EN VALIDANT CECI : POUR UN CODE DE QUALITÉ, PRENEZ QUE DES DEVS SENIORS, AVEC UNE VRAIE BONNE EXPÉRIENCE, ET LE TOUR EST JOUÉ. NON ?

La tentation du diable

Créer une équipe que de séniors est une bonne piste pour amener qualité, cohésion technique, et respect des besoins du client, de la cliente.
Et pourtant, rien ne vous garantira que le projet réussira, et c’est une autre histoire … (nous en reparlerons dans une autre série d’articles au sujet de la cohésion humaine).

C’est, pourtant, ce que j’inclus dans ce que j’appelle « la tentation du diable« . Pourquoi ?
Comment construire ensemble un monde où tous les devs, toutes les devs font de la qualité logicielle, apprennent, et s’améliore ?

Bien intégrer les juniors

MÊME SI ÇA PEUT ÉPUISER, OU DÉGOÛTER CERTAINS, OU CERTAINES, L’ÉTAT D’ESPRIT DU MENTORING FAIT PARTIE INTÉGRANTE DE LA CULTURE D’APPRENTISSAGE.

Intégrer un junior, une junior, sans la-le guider

La tentation ici aussi, c’est de prendre un-e junior et de se dire : aller hop, je suis débarrassé-e, il-elle va pouvoir tout faire tout-e seul-e.
Croyez-vous que l’école permette d’apprendre tout ce qu’il faut pour :

• faire du code de qualité direct
• savoir écouter et traduire les besoins client
• améliorer son code en continue
• intégrer des philosophies de design de code comme le TDD

C’est tout bonnement impossible ! Et quand bien même l’école l’enseignerait (ce qui encore hélas trop rare), il y a un vrai gap avec la vie en entreprise, sur le terrain.
Une image qui me vient ici c’est un militaire qui se forme dans son équipe, tranquillement « au chaud » dans sa caserne (pas sur du nom ici), et qu’on envoie au frond pour la première fois ….

Mentorer, accompagner, guider

Dans une équipe, la plupart du temps, nous avons des niveaux hétérogènes. Et ce n’est pas un mal, si la culture d’apprentissage est présente, et est mise en place rigoureusement tout le temps, tous les jours.

UNE ÉQUIPE S’AUTO-ORGANISE DANS L’ÉTAT D’ESPRIT AGILE, SOIT.
JE PENSE QUE L’ON DOIT ALLER PLUS LOIN DANS LA RÉFLEXION : UNE ÉQUIPE S’ENTRAIDE, SE CHALLENGE, ENSEMBLE, SANS MANAGER, JUSTE L’ÉQUIPE.

• Un-e junior demande du soutien sans devenir une sangsue des seniors,
• Le-la senior apporte ses connaissances, sans faire du Top-down supérieur d’information
• Chacun, chacune, va se challenger pour améliorer tout le monde
• Chacun apprend, s’améliore, quelque soit le niveau

Veille et apprentissage

Alors comment met-on en place cette culture d’apprentissage ?

Il existe plusieurs stratégies, complémentaires, s’alignant sur un but commun : faire grandir, et grandir ensemble.

• Mettre en place une veille continue
• Mentorer, et se faire mentorer, même les seniors
• Faire de la review technique
• Oser la critique bienveillante
• Oser l’erreur, accepter l’erreur, surtout quand elle est intégrée avec le socle 1 : Git

Un temps pour tout

OK, et on l’applique quand cette culture de l’apprentissage ? Un point par semaine ? Un point par mois ?

Dans l’idéal, le but final, on ne doit pas y penser, ça se fait naturellement, si la culture de l’apprentissage est déjà intégrée dans l’entreprise.
Ca c’est la vision de cette étape 2.

Dans la vie de tous les jours, dans une entreprise qui souhaite acquérir les bonnes habitudes, il va être nécessaire de s’obliger à prendre un temps, régulier pour y arriver.

COMME TOUT ACTIVITÉ QU’ON SOUHAITE TRANSFORMER EN HABITUDE, EN RÉFLEXE, C’EST DANS LA DISCIPLINE, LA RIGUEUR, ET LA RÉPÉTITION QU’ON Y ARRIVER, PAS À PAS.

Alors, oui fixons-nous une heure par semaine, déjà.
Puis, autorisons-nous une review de code à chaque fin de sprint, d’itération. Même si ça ne sera pas assez, ça permettra de voir ce que c’est.
Et après, améliorons ça, passons à la seconde vitesse : à chaque push, proposons une merge request / pull request, et échangeons, plutot que de juste valider sans rien dire.
Et ajoutons, une heure de veille technique hebdomadaire, ....

Pas à pas !