Rétrospective de revue de code Template (Free)

Qu'est-ce qu'une rétrospective de revue de code ?

Une rétrospective de revue de code est une réunion où votre équipe examine sa façon de relire le code, et non le code lui-même. Des pull requests qui attendent pendant des jours, des commentaires sans contexte, des revues qui ne vérifient que le style : ces problèmes ressortent rarement lors d'une rétro de sprint classique, parce qu'ils sont répartis sur la semaine de chacun au lieu d'être liés à un événement précis. Le tableau comporte quatre colonnes. « Qu'est-ce qui fonctionne bien ? » rassemble les habitudes de revue à conserver, comme une checklist utile ou un ton respectueux. « Qu'est-ce qui ne fonctionne pas ? » couvre les points de friction, des pull requests trop volumineuses aux standards incohérents. « Que pouvons-nous améliorer ? » transforme ces constats en changements précis, comme une limite sur la taille des modifications ou un délai de traitement convenu. « Quelles questions ont émergé ? » met de côté les questions ouvertes que l'équipe doit approfondir avant de pouvoir trancher. Organisez-la après une release majeure, lorsque les délais de revue commencent à ralentir les livraisons, ou quand de nouvelles personnes arrivent et que les standards de revue implicites de l'équipe doivent être mis par écrit. Restez dans une démarche sans reproche : le sujet, c'est le processus, pas les commentaires de quelqu'un sur une pull request en particulier.

Format de rétrospective de revue de code

Qu'est-ce qui fonctionne bien ? Qu'est-ce qui marche bien dans nos revues de code ?: Commencez par ce qui fonctionne. Demandez quelles pratiques de revue précises ont aidé, et saluez les personnes dont les revues ont fait la différence.
Qu'est-ce qui ne fonctionne pas ? Quelles difficultés ou points de friction avons-nous rencontrés pendant les revues ?: Faites en sorte que chacun puisse soulever des problèmes sans accuser personne. Demandez des exemples précis, comme une revue qui a pris plusieurs jours ou un commentaire difficile à mettre en pratique.
Que pouvons-nous améliorer ? Comment améliorer notre processus et nos pratiques de revue de code ?: Demandez des suggestions précises et applicables. « De meilleures revues » n'est pas une action ; « découper les pull requests qui touchent plus d'une fonctionnalité » en est une.
Quelles questions ont émergé ? Quelles nouvelles questions ou pistes à explorer sont apparues ?: Notez les questions auxquelles l'équipe ne peut pas répondre aujourd'hui, et convenez de qui se penchera sur chacune avant la prochaine rétro.

Dans quels cas recourir à cette étude rétrospective ?

Quand les revues ralentissent les livraisons ou créent des tensions et que vous voulez comprendre pourquoi.
Quand vous voulez que les développeurs partagent les pratiques de revue qui leur réussissent.
Après une release ou un projet majeur, pour voir comment les revues ont tenu sous pression.
Quand de nouvelles personnes rejoignent l'équipe et qu'il faut s'accorder sur les standards de revue, les attentes et les délais de traitement.

Exemples de questions pour brise-glace

Quel est le code le plus intéressant que vous ayez relu récemment ?
Si vous pouviez ajouter une fonctionnalité à votre éditeur de code, laquelle serait-ce ?

Vous souhaitez un exercice d'échauffement que votre équipe puisse pratiquer, et pas seulement répondre à voix haute ? Découvrez des brise-glaces gratuits →

Idées et conseils pour votre réunion de rétrospective

Gardez une discussion sans reproche pour que chacun parle honnêtement des revues qu'il a trouvées difficiles.
Saluez les bonnes revues, avec des commentaires clairs ou un traitement rapide, et pas seulement les problèmes.
Impliquez toutes les personnes qui écrivent ou relisent du code, y compris les testeurs.
Mettez-vous d'accord sur un ou deux changements concrets plutôt que sur une longue liste de bonnes intentions.
Assurez le suivi des actions et faites le point sur leur avancement lors des prochaines rétrospectives.
Faites tourner le rôle de facilitateur pour que différents points de vue mènent la discussion.

Foire aux questions

Qu'est-ce qu'une rétrospective de revue de code ?

C'est une réunion où votre équipe réfléchit à sa façon de relire le code : ce qui fonctionne bien, ce qui ne fonctionne pas, ce qu'il faut améliorer et les questions encore ouvertes. L'objectif est d'avoir des revues plus rapides et plus utiles pour la personne qui les reçoit.

Quand organiser une rétrospective de revue de code ?

Organisez-la après une release ou un projet majeur, lorsque les délais de revue commencent à ralentir les livraisons, ou régulièrement pour vous accorder sur les standards de revue avant que les habitudes ne s'installent.

Quelles questions poser lors d'une rétrospective de revue de code ?

Commencez par les quatre du tableau : ce qui fonctionne bien, ce qui ne fonctionne pas, ce que nous pouvons améliorer et les questions qui ont émergé. Parmi les relances utiles : combien de temps les pull requests attendent-elles une première revue, et les commentaires expliquent-ils pourquoi une modification est nécessaire ?

Combien de temps dure une rétrospective de revue de code ?

Prévoyez 45 à 60 minutes. Si l'équipe a beaucoup de difficultés à traiter, concentrez-vous sur les deux ou trois sujets qui ont recueilli le plus de votes.

En quoi est-elle différente d'une rétrospective de sprint ?

Une rétrospective de sprint couvre tout ce qui s'est passé pendant le sprint. Une rétrospective de revue de code examine une seule pratique en profondeur, si bien que des problèmes qui paraissent mineurs sur un sprint donné, comme la lenteur des revues, reçoivent assez d'attention pour être résolus.

Qu'est-ce qu'une rétrospective de revue de code ?

Format de rétrospective de revue de code

Qu'est-ce qui fonctionne bien ?

Qu'est-ce qui ne fonctionne pas ?

Que pouvons-nous améliorer ?

Quelles questions ont émergé ?

Dans quels cas recourir à cette étude rétrospective ?

Exemples de questions pour brise-glace

Idées et conseils pour votre réunion de rétrospective

Foire aux questions

Modèles associés