Cycle time é uma métrica-chave para equipes de engenharia. Emprestado da manufatura lean, em software ele mede quanto tempo o código leva para se mover pelo pipeline de desenvolvimento do primeiro commit até produção.
Por que se importar com cycle time?
Melhorar o cycle time significa entregar mais rápido, fazer deploy em lotes menores e evitar código obsoleto. Pesquisas como Accelerate vinculam cycle times mais curtos a maior inovação, competitividade e eficiência organizacional.
Cycle time mais baixo permite:
- Mudanças menores e mais seguras
- Feedback mais rápido dos usuários
- Menos risco e overhead
- Revisões e merges em tempo hábil
No DevStats, focamos na porção de pull request da entrega porque é a etapa que os desenvolvedores podem influenciar diretamente.
Como o DevStats mede o PR cycle time
O DevStats calcula o PR cycle time como o tempo total que um pull request gasta nessas etapas:
- Coding Time do primeiro commit à criação do PR
- Pickup Time da criação do PR à primeira revisão
- Review Time da primeira revisão à última revisão
- Merge Time da última revisão ao primeiro merge
- Deploy Time do primeiro merge até o PR ser mergeado na branch de deploy
Você pode visualizar PRs mergeados e em andamento para entender o desempenho atual e tempos esperados de conclusão. Fechar PRs antigos reduz o cycle time, enquanto manter PRs obsoletos abertos o aumenta.
Use essas visualizações para investigar:
- PR Cycle Time dashboard para agregados semanais, decomposições por etapa e uma visualização Scatter para identificar outliers
- Code Review dashboard para rastrear PR Size, comentários e profundidade de revisão
- Aging Branches relatório para ver branches ativas por etapa e há quanto tempo estão ali. Clique em qualquer círculo para abrir detalhes da branch
- Benchmarks na seção Snapshot para comparar com padrões da indústria
O que é um bom cycle time?
Use os Benchmarks como guia:
- Elite abaixo de 42 horas
- Forte 42–95 horas
- Regular 96–188 horas
- Precisa de Foco acima de 188 horas
Selecionar o percentil 85 nas configurações de PR Cycle Time dá uma base estável e realista que filtra outliers extremos.
O que contribui para o cycle time?
Foque nas alavancas que sua equipe controla:
- Trabalho em progresso muitos PRs abertos aumentam troca de contexto e espera
- Tempo em progresso divida o trabalho em lotes menores que são fáceis de revisar e fazer deploy
- Tempo em revisão mantenha PRs pequenos, atribua revisores prontamente e defina expectativas claras de revisão
- Tamanho do PR PRs menores fluem mais rápido e são mais seguros para deploy
- Tempo para merge priorize PRs aprovados e mantenha filas de merge curtas. Invista em automação para reduzir handoffs entre merge e deploy
Reduzindo cycle time com o DevStats
Comece com uma limpeza Identifique PRs obsoletos nas visualizações de Open PRs e Aging Branches. Feche ou faça merge do que ainda é relevante e arquive o resto. Use filtros de data para focar em trabalho recente.Adote um acordo de equipe
Revise o PR Cycle Time em conjunto e defina metas práticas:
- Meta de cycle time total, por exemplo 7–14 dias para começar
- Limitar PRs abertos por squad
- Definir SLAs de revisão, por exemplo revisar dentro de 24 horas e fazer merge dentro de 2 dias
- Manter PRs pequenos por padrão
Construir um loop de feedback- Observe a visualização Scatter para detectar outliers cedo
- Verifique o dashboard de Code Review semanalmente para monitorar PR Size e Review Time e identificar tendências cedo.
- Verifique Aging Branches para priorizar branches que esperaram mais tempo
- Compare com Benchmarks para definir metas de melhoria realistas