Rework & Review Health: O Que Medem e Por Que Importam

O que medem

Rework rate é a fatia de código mergeado que é reescrita de forma significativa de novo dentro de uma janela curta (14 dias) da entrega — uma proxy pra código que não resolveu o problema de fato na primeira tentativa. Review health é a fatia de pull requests mergeados que saíram sem nenhum revisor — uma medida direta de quanto do código entregue de um time nunca passou por um segundo par de olhos antes de mergear. Ficam agrupados porque respondem uma pergunta relacionada por dois ângulos diferentes: o que está sendo entregue é de fato sólido, e o processo pensado pra pegar problema antes de entregar está de fato sendo usado.

Por que importa

Os dois sinais pegam um problema de qualidade bem antes de aparecer como incidente, reclamação de cliente, ou pico no change failure rate do DORA. Um rework rate subindo geralmente significa que requisito não estava claro, a primeira tentativa foi apressada, ou um time está acumulando silenciosamente um tipo específico de dívida técnica — tudo isso vale saber antes de compor. Um time que regularmente mergeia PR sem review não está necessariamente fazendo trabalho ruim, mas removeu uma das checagens de qualidade mais baratas disponíveis, e essa decisão é fácil de tomar por acidente, um hotfix urgente de cada vez, sem ninguém decidir que isso devia virar a norma.

Como calcular

Rework rate: pra código mergeado, verifica se uma parte significativa das mesmas linhas é alterada de novo dentro de 14 dias do merge original, e divide a contagem de mudanças retrabalhadas pelo total de mudanças mergeadas no período. Review health: divide a contagem de PRs mergeados sem nenhum revisor aprovando ou comentando pelo total de PRs mergeados no período.

Um exemplo: um time mergeia 40 PRs num mês. Se 6 desses PRs sofrem retrabalho significativo dentro de 14 dias, isso é 15% de rework rate. Se 8 dos 40 mergearam sem nenhum revisor, isso é 20% de taxa sem review — vale checar se esses 8 se sobrepõem com os 6 que precisaram de retrabalho.

Como interpretar os números

Nenhum dos dois tem benchmark publicado pela indústria como as métricas DORA têm — o que conta como "retrabalho" depende de como o próprio fluxo de trabalho e estratégia de branch de um time define uma reescrita, e o que é uma taxa aceitável de sem-review varia conforme quanto um time depende de pareamento ou práticas trunk-based em vez de review formal de PR. A comparação útil é um time contra sua própria tendência recente, e checar se os dois números se correlacionam — um time onde PR sem review e PR retrabalhado se sobrepõem bastante tem uma história bem mais clara do que um onde não se sobrepõem.

Uma armadilha comum

É tentador tratar "zero revisores" sempre como falha de processo, mas um time que pareia em tempo real na maioria das mudanças pode legitimamente pular um review de PR separado sem nenhuma lacuna de qualidade — o review já aconteceu, só não como uma aprovação no GitHub. O número é mais útil como ponto de partida pra uma pergunta ("por que a taxa de review de PR desse time parece diferente das outras?"), não como regra de que todo merge precisa de revisor formal independente de como o time de fato trabalha.

Como o moasy.tech calcula isso

O moasy.tech recalcula os dois sinais a partir do histórico sincronizado de pull requests — sem auditoria manual de PR individual. Rework rate e review health ficam ao lado da concentração de contribuição na mesma visão de qualidade de time, já que os três usam o mesmo dado subjacente de pull request e item de trabalho sincronizado do Jira, Linear, GitHub ou Azure DevOps.

Veja a implementação completa na página de Capacity & Workload, ou volte pra Team Health pros outros sinais desse cluster.

Dado ilustrativo, apenas para demonstração.

Perguntas sobre rework e review health