Dans pas mal d’équipes agiles, la fin de sprint ressemble à un petit sprint dans le sprint. On court partout, on ouvre les dernières pull requests, on essaye de tout boucler à temps. Et souvent, ça donne : - des PR ouvertes à la dernière minute, parfois le jour de la sprint review - des PR de 500 lignes ou plus, impossibles à relire sereinement - des tests qui plantent ou qui n’ont jamais été écrits - des échanges interminables au moment du merge - des features qu’on considère “Done” mais clairement pas prêtes pour la prod Et pourtant, la review de code est une étape essentielle. Elle mérite d’être faite dans de bonnes conditions, pas dans l’urgence. Voilà quelques pratiques que j’essaie de mettre en place ou que j’ai vues marcher : - des PR petites, claires, et créées dès que possible - travailler en feature branch avec une PR en mode “brouillon” dès le début - faire les reviews au fil de l’eau, pas toutes à la fin - ajouter du contexte dans la PR : pourquoi ce code, quels choix, quelles conséquences - définir ce qu’on attend d’une PR avant de la considérer “prête à reviewer” - garder du temps dans le sprint pour faire des reviews de qualité Un sprint bien terminé, ça se prépare dès le début. 🙌