Notre problème : quand la revue coince

Lors de la dernière rétrospective, nous avons identifié tous ensemble que le principal point de contention de l’équipe se situe lorsque les développements sont terminés, au moment de faire une revue du code par les pairs, pour que la story puisse ensuite passer en recette.

Nous avons discuté sur le fait d’éviter de bloquer trop longtemps l’auteur de cette pull request (nous utilisons git). En effet si la story n’est pas revue rapidement le cout du switch et du travail parallèle devient très fort. En contrepartie, l’équipe ne peut pas s’arrêter immédiatement pour la valider afin de ne pas casser son flot et dans ce cas-là, elle aussi switcher…

Nous avons essayé plusieurs méthodes : 

• Je me lève pour faire le tour : « Hé, tu me valides ma PR (pull request) dès que tu as le temps? », « Dis, t’a pu voir ma PR ? », « T’oublie pas ma PR »…  Cela ne marche pas plus que ça, car dès que la personne retourne à sa tâche elle oublie instantanément…
• L’intégration Bitbucket -> Slack. Lorsqu’une demande de revue est créé, un message automatique arrive sur notre channel de discussion d’équipe. C’est très cool! Mais au bout d’une semaine on n’y fait plus vraiment attention.
• En parler au standup meeting : « Ah oui, mince, j’ai carrément zappé de la regarder, je te fais ça ce matin! ». En pratique c’est trop long et il arrive que les personnes oublient entre le board et leur bureau…

Donc lors de cette rétrospective nous sommes sceptiques. Faut-il modifier notre board et notre flot de travail pour faire explicitement apparaître cette étape? Notre flot devient assez complexe et nous craignons de l’alourdir inutilement.

Faut-il considérer qu’au bout de 24h tout le monde s’en fout et que l’auteur à le droit de valider son changement tout seul? Nous n’y croyons pas vraiment, car justement nous avons introduit cette bonne pratique afin d’être sûr que tout le monde suive l’ensemble des développements, afin d’éviter des bugs et pour partager nos meilleures pratiques.

Nous convenons donc de simplement faire plus attention et à nous astreindre à plus de rigueur.

On essaye !

Une semaine passe et force est de constater que la simple bonne volonté ne suffit pas…

Alors que faire? (vous avez le droit d’interrompre votre lecture pour réfléchir ou sinon partager vos solutions en commentaire si vous avez déjà trouvé des réponses!)

Parmi l’éventail de solution que j’imagine le point commun est le même : centré sur le problème.

C’est alors que je repense aux émissions de Dan Pink (foule sous contrôle sur National Geographics). Dans ses émissions Dan Pink essaye de régler un problème de comportement en « ludifiant » l’action et en tachant de renforcer une action positive et plutôt sympa plutôt que de pointer du doigt l’action qui ne convient pas.

Si vous ne connaissez pas les travaux de Dan Pink je vous conseille le visionnage de ces deux exemples :

• Comment inciter les gens à se laver la main lors d’un match de baseball :

Rendre les actions bien visibles et fun avec des effets sonores.

• Comment encourager les gens à prendre les escaliers et faire de l’exercice plutôt que prendre les escalators :

Rendre la montée amusante et agréable grâce à la création d’un escalier « beat box ».

Dans le même genre je vous conseille d’aller voir funthéorie, c’est plus tout récent mais les idées sont très bonnes.

La solution : tous aux vert!

Il se trouve que tout récemment Philippe (un membre de l’équipe) m’avait montré Dashing et m’avait soumis l’idée d’avoir un dashboard avec des widgets verts/rouges (vert : tout va bien, rouge : il y a une action à prendre de toute urgence). J’avais fait un premier embryon de dashboard en intégrant notamment notre teammood (voir ici ) et je me suis dis que cela pourrait être une bonne idée de voir nos pull request sur notre dashboard. Si toutes nos pull requests ont été validées, le widget sera vert. S’il y a une ou plusieurs pull requests celles-ci s’afficheront en devenant bleu puis jaune puis rouge si elles ne sont pas validées rapidement. 

Exemple :

Et alors ?

Après deux mois d’expérimentation, nous avons remarqué que l’équipe aimait faire en sorte de garder le dashboard au vert (d’autant plus que nous l’avons toujours sous les yeux sur un écran dédié). En conséquence, lorsqu’une pull request est ouverte, celle-ci se retrouve donc en général revue au bout de quelques minutes à quelques heures, c’est-à-dire trois à quatre fois plus rapidement qu’auparavant!

Comme quoi, il vaut souvent mieux ne pas trop se focaliser sur le problème, mais au contraire chercher d’autres pistes de résolution, si possible rendant l’action plus naturelle, plus agréable à faire!

Vous pouvez récupérer le widget pull request bitbucket ici. Enfin si le sujet Dashing vous intéresse je vous prépare un nouvel article sous peu! 😉