Retrospectiva de Code Review Template (Free)

O que é uma Retrospectiva de Code Review?

Uma retrospectiva de code review é uma reunião em que o time analisa como revisa código, e não o código em si. Pull requests parados por dias, comentários sem contexto, revisões que só verificam estilo: esses problemas raramente aparecem em uma retro de sprint comum, porque estão espalhados pela semana de todo mundo em vez de ligados a um único evento. O quadro tem quatro colunas. "O que está indo bem?" reúne os hábitos de revisão que vale a pena manter, como um checklist útil ou um tom respeitoso. "O que não está indo bem?" cobre os pontos de dor, de pull requests grandes demais a padrões inconsistentes. "O que podemos melhorar?" transforma esses pontos em mudanças específicas, como um limite para o tamanho das alterações ou um prazo de resposta combinado. "Que perguntas surgiram?" registra as dúvidas em aberto que o time precisa investigar antes de decidir. Faça essa retrospectiva depois de uma release importante, quando a demora nas revisões começar a travar as entregas ou quando novas pessoas entrarem no time e os padrões de revisão não escritos precisarem ser documentados. Mantenha um clima sem culpados: o assunto é o processo, não os comentários de alguém em um pull request específico.

Formato da Retrospectiva de Code Review

O que está indo bem? O que está funcionando bem nos nossos code reviews?: Comece pelo que está funcionando. Peça exemplos de práticas de revisão específicas que ajudaram e reconheça as pessoas cujas revisões fizeram diferença.
O que não está indo bem? Que desafios ou pontos de dor enfrentamos nos code reviews?: Crie um ambiente seguro para levantar problemas sem culpar ninguém. Peça exemplos específicos, como uma revisão que levou dias ou um comentário difícil de colocar em prática.
O que podemos melhorar? Como podemos melhorar nosso processo e nossas práticas de code review?: Peça sugestões específicas e acionáveis. "Revisões melhores" não é uma ação; "dividir pull requests que mexem em mais de uma funcionalidade" é.
Que perguntas surgiram? Que novas perguntas ou temas para investigar surgiram?: Anote as perguntas que o time não consegue responder hoje e combinem quem vai investigar cada uma antes da próxima retro.

Quando utilizar esta análise retrospectiva

Quando as revisões estão atrasando as entregas ou causando atrito e você quer descobrir o porquê.
Quando você quer que os desenvolvedores compartilhem as práticas de revisão que funcionam para eles.
Depois de releases ou projetos importantes, para avaliar como as revisões se saíram sob pressão.
Quando novas pessoas entram no time e é preciso alinhar padrões, expectativas e prazos de resposta das revisões.

Perguntas sugeridas para quebra-gelo

Qual foi o código mais interessante que você revisou recentemente?
Se você pudesse adicionar um recurso ao seu editor de código, qual seria?

Quer um exercício de aquecimento que sua equipe faça, e não apenas responda em voz alta? Veja quebra-gelos gratuitos →

Ideias e dicas para sua reunião de retrospectiva

Mantenha a conversa livre de culpados para que as pessoas deem feedback honesto sobre as revisões que acharam difíceis.
Reconheça as boas revisões, como comentários claros ou respostas rápidas, e não só os problemas.
Envolva todo mundo que escreve ou revisa código, incluindo testers.
Combinem uma ou duas mudanças concretas em vez de uma longa lista de boas intenções.
Acompanhe os itens de ação e o progresso nas próximas retrospectivas.
Faça rodízio de facilitador para que diferentes perspectivas conduzam a conversa.

Perguntas frequentes

O que é uma retrospectiva de code review?

É uma reunião em que o time reflete sobre como revisa código: o que está indo bem, o que não está, o que melhorar e quais perguntas seguem em aberto. O objetivo são revisões mais rápidas e mais úteis para quem as recebe.

Quando fazer uma retrospectiva de code review?

Faça depois de uma release ou projeto importante, quando a demora nas revisões começar a travar as entregas ou periodicamente, para alinhar padrões de revisão antes que os hábitos se consolidem.

Que perguntas fazer em uma retrospectiva de code review?

Comece pelas quatro do quadro: o que está indo bem, o que não está indo bem, o que podemos melhorar e que perguntas surgiram. Perguntas complementares úteis incluem quanto tempo os pull requests esperam pela primeira revisão e se os comentários explicam por que uma mudança é necessária.

Quanto tempo dura uma retrospectiva de code review?

Reserve de 45–60 minutos. Se o time tiver muitos problemas de revisão para discutir, foque nos dois ou três mais votados.

Qual a diferença para uma retrospectiva de sprint?

Uma retrospectiva de sprint cobre tudo o que aconteceu na sprint. Uma retrospectiva de code review analisa uma única prática a fundo, então problemas que parecem pequenos em cada sprint, como revisões lentas, recebem atenção suficiente para serem resolvidos.

O que é uma Retrospectiva de Code Review?

Formato da Retrospectiva de Code Review

O que está indo bem?

O que não está indo bem?

O que podemos melhorar?

Que perguntas surgiram?

Quando utilizar esta análise retrospectiva

Perguntas sugeridas para quebra-gelo

Ideias e dicas para sua reunião de retrospectiva

Perguntas frequentes

Modelos relacionados