Quelques astuces simples pour créer une super ambiance dans votre équipe dev
Un dev ruby, c’est compliqué à recruter. Quand on le trouve, on a envie qu’il reste. On a aussi envie qu’il se donne à fond, qu’il s’investisse pour son équipe et pour la boîte. On veut pouvoir lui faire confiance, et qu’il ait confiance en nous. Et nous, on a envie d’arriver tous les matins sans craindre la journée à venir.
Toutes ces raisons incitent à instaurer une ambiance saine dans une équipe. De bonnes conditions de travail qui donnent envie de s’investir.
On attaque le code, pas le développeur
La code review est une étape importante et nécessaire de notre git flow durant laquelle notre code est relu par deux autres développeurs. Elle permet notamment de ne pas faire passer n’importe quoi en production. Après tout, Martin est tellement tête en l’air qu’il a forcément oublié de retirer des instructions de debug dans son code !
Non. Ce n’est définitivement pas le bon état d’esprit.
L’erreur est humaine comme on dit, et tout le monde peut faire des étourderies. La force de l’équipe c’est justement de pouvoir s’appuyer sur chaque membre, consulter les différents points de vue et augmenter ainsi la pertinence d’un bout de code. Ce n’est pas le développeur que nous jugeons, mais ce qu’il écrit et ce qui existe déjà dans la base de code. Nous pouvons toujours faire mieux, et il vaut mieux donner des pistes pour aller en ce sens plutôt que de se lamenter des compétences de son équipier.
Nous appliquons une autre règle en interne sur Github. Il faut deux validations pour pouvoir fusionner son code, donc il n’est pas utile d’être trop prohibitif. Plutôt que d’interdire une fusion après la relecture, nous laissons des commentaires pour demander des évolutions. Cela évite de voir apparaître une grosse icône rouge après chaque passage d’un relecteur, ce qui pourrait jouer sur le moral. Il n’y a rien de plus déprimant que d’essuyer une série de refus.
Nous appliquons l’interdiction seulement si le code s’apprête à être fusionné, et qu’une erreur vient d’être remarquée.
Il revient à l’auteur de la Pull Request l’honneur et le privilège de merger lui-même sa branche un fois que tous les voyants sont au vert.
Une responsabilité partagée
Il est trop simple de remettre la faute sur une seule et même personne. Alors que la porter à plusieurs épaules la rendrait moins lourde mais tout aussi importante.
L’étape de la code review nous permet de partager la responsabilité entre les développeurs. Si un problème survient sur la plateforme suite à la fusion d’une branche, alors ce n’est pas seulement la faute de celui qui l’a écrite ou celui qui a cliqué sur le bouton pour la merger. Deux autres développeurs sont passés par là, donc ils ne sont pas moins fautifs.
Il en va de même pour les mises en production. Si une action particulière doit être effectuée lors de la procédure, ça ne se devine pas ! Il faut que l’information soit renseignée quelque part. Et cela doit être fait par celui qui envoie sa branche sur le serveur de staging. Les relecteurs aussi peuvent le rappeler au développeur.
Chercher un fautif est une perte de temps et d’énergie et cela peut créer de la frustration dans l’équipe. Ce qui importe, ce sont les leçons que nous en tirons pour ne pas répéter l’erreur une seconde fois. Réaliser un post-mortem est une solution pour historiser l’incident et creuser le contexte du problème : pourquoi est ce que c’est arrivé (personne ne doit être visé), et qu’aurions nous pu faire pour l’éviter.
La responsabilité se manifeste encore d’une autre manière chez Captain. Notre particularité ? Nous sommes 10 développeurs et 1 QA, mais nous n’avons pas de CTO. Pas de manager technique ; notre supérieur direct est l’un des co-fondateurs qui joue principalement un rôle de coach. Notre équipe s’auto-gère, et la parole de chacun vaut autant que la parole des autres car nous prenons les décisions tous ensemble. Les tâches habituellement traitées par un CTO sont réparties entre les membres de l’équipe selon leur bon vouloir : participer à la définition des objectifs trimestriels, recruter, réaliser les perf reviews, formaliser un de nos process…
Au delà de responsabiliser un équipier, cela permet de l’engager et de le valoriser par une participation active à la vie d’équipe.
Accompagner les nouveaux
Accueillir un nouvel équipier prend du temps, qui s’étire en fonction de ses expériences passées. Il est en effet plus coûteux d’onboarder un junior qu’une personne plus expérimentée car elle aura besoin d’être plus encadrée.
La tolérance et la patience sont de mise à cette étape. Il y a des éléments à prendre en compte lors de son arrivée :
- Il ne produira pas de valeur tout de suite ;
- La bande passante des autres sera en partie allouée à son onboarding ;
- Il va devoir s’adapter à une nouvelle base de code, une nouvelle organisation, de nouveaux objectifs, potentiellement de nouveaux outils.
L’arrivée d’un nouveau s’accompagne donc d’une baisse de productivité qu’il faudra anticiper. En abaissant l’engagement du prochain sprint notamment, dans le cas d’une méthodologie Scrum.
Mais il apporte avec lui un regard neuf, de quoi recycler l’air au sein de l’équipe. Certaines des briques de codes lui évoqueront une assiette de spaghettis sauce béchamel, quelques process lui sembleront bancals, ou il trouvera sans doute à la documentation un style très épuré.
C’est l’occasion de remettre les choses en question. Que faisait il dans son ancienne boîte ? Est ce que ça fonctionnerait mieux que ce notre méthodologie actuelle ? Comment pourrait-on transformer, adapter nos méthodes pour que tout le monde soit à l’aise, et donc augmenter notre productivité ?
Ne pas avoir honte de demander de l’aide
Il y a ces nouveaux tout timides qui n’osent pas déranger les développeurs plus anciens ou plus expérimentés pour demander de l’aide. Il y a aussi ces développeurs seniors qui coincent mais qui ressentent le besoin de justifier leur légitimité.
Ils vont bloquer sur un problème plus longtemps que nécessaire, alors que demander de l’aide et / ou faire du pair programming aurait pu les dé-coin-cer.
Oui, ça arrive à tout le monde de faire des erreurs d’inattention, et il n’y a pas de honte à ne pas comprendre quelque chose du premier coup. Le fait d’exposer son problème à quelqu’un, en reprenant depuis le début, nous permet de voir les choses sous un nouvel angle. Très souvent, la solution arrive d’elle même avant même que le deuxième développeur n’ait eu le temps de dire quoi que ce soit.
Et au delà de n’importe quel étourderie, ce blocage, si ça se trouve, c’est une bizarrerie de l’application qui est connue de tous, mais qui n’a été documenté nulle part ! Et ça, ça ne se devine pas.
Alors sors de ta bulle, ravale ton amour propre, et sollicite les autres. Ils hésiteront moins eux aussi à te demander de l’aide en retour.
Le mot de la fin
Des petites choses simples peuvent être mises en place dans une équipe. Quelques défis rigolos, comme réussir à aligner 100 build verts sur notre outil d’Intégration Continue avec la promesse d’une bière à la clé. Des 1–1 entre équipiers, en sortant se balader une demie-heure régulièrement.
Dans une méthodologie Scrum, il ne faut pas oublier que l’équipe ne se limite pas aux développeurs. La team Scrum est la fusion entre cette équipe, et celle du Produit. S’il y a des bienfaits à maintenir une ambiance saine entre devs, il y en a d’autant plus à travailler sur cette symbiose Produit / Dev.
Si vous cherchez une équipe avec des process vertueux, rejoignez-nous !
