Glossário de métricas

O significado de cada indicador da plataforma: o que ele mede, a fórmula exata usada no cálculo e como interpretá-lo. Todas as métricas respeitam os filtros globais de período, repositório e time. As mesmas fórmulas aparecem dentro do produto, no modal "Como é calculado" de cada indicador.

Por que medianas e percentis (P50 / P75 / P95)#

Quase tudo aqui é reportado em percentis, não em média. P50 (mediana) é o valor abaixo do qual ficam 50% dos casos; P95, 95%. A média é distorcida por um único PR atípico (um refactor gigante, um PR esquecido por um mês); a mediana mostra o caso típico, e o P95 mostra a cauda: os casos lentos que merecem atenção. No banco, os percentis são calculados com PERCENTILE_CONT (interpolação contínua entre os dois valores centrais). Pelo mesmo motivo, o tamanho de PR também é reportado como mediana de linhas alteradas, não média.

Cycle time#

O que mede: o tempo do primeiro commit ao merge do pull request, a fluidez do fluxo de código do time. Aparece na Visão geral e na tela Workflow.

Fórmula: cycle time do PR = mergedAt − primeiro commit da branch, sobre os PRs integrados no período; reportado em P50/P75/P95. O "primeiro commit" passa por uma janela de plausibilidade (ver honestidade metodológica).

Estágios do cycle time#

Decompor é o que permite achar o gargalo: onde o tempo realmente vai. Cada estágio é medido como a mediana sobre a sua própria população (um PR sem review não distorce o estágio de review), por isso a soma dos estágios não bate exatamente com o total:

• Coding: do 1º commit à abertura do PR para revisão.
• Pickup: da abertura ao primeiro review (quanto tempo o PR espera alguém pegar).
• Review: do primeiro review à aprovação.
• Deploy: do merge ao deploy em produção (mostrado na composição; usa os deploys do período).

Como interpretar: menor é melhor, mas o valor isolado importa menos que o estágio que domina. Um pickup alto sugere fila/atrito para iniciar a revisão; um review alto sugere PRs grandes ou poucos revisores; um deploy alto sugere gargalo na esteira de entrega.

DORA#

O que mede: as quatro métricas de referência da indústria para performance de entrega de software, definidas pela pesquisa DORA (DevOps Research and Assessment, hoje parte do Google Cloud; ver fontes). Aparecem na tela Deploys, e cada uma recebe um tier (elite / good / fair / poor).

• Deployment frequency: deploys de produção ÷ dias do período.
• Lead time for changes: mediana de (término do deploy de produção − 1º commit do PR), só deploys com sucesso. Cobre também commits diretos (sem PR), casados ao deploy pelo SHA.
• Change failure rate (CFR): deploys que causaram falha ÷ total de deploys de produção. A "falha" vem de incidentes reais quando há PagerDuty/Sentry conectado (ver honestidade metodológica).
• MTTR (mean time to restore): tempo médio para restaurar o serviço após uma falha: da abertura à resolução do incidente (PagerDuty/Sentry) ou, no proxy, do deploy com falha ao próximo deploy com sucesso no mesmo repositório.

Como interpretar: as duas primeiras medem velocidade, as duas últimas medem estabilidade. Times de alta performance conseguem as duas coisas ao mesmo tempo: entregar com frequência sem aumentar a taxa de falhas.

Tiers DORA#

Os limiares que usamos seguem as faixas do relatório DORA 2023 (Accelerate State of DevOps):

Métrica	elite	good	fair	poor
Deployment frequency	≥ 1/dia	≥ 1/semana	≥ 1/mês	< 1/mês
Lead time for changes	≤ 24 h	≤ 1 semana	≤ 1 mês	> 1 mês
Change failure rate	≤ 5%	≤ 10%	≤ 15%	> 15%
MTTR	≤ 1 h	≤ 24 h	≤ 1 semana	> 1 semana

Throughput#

O que mede: o volume de PRs no período. Mostra quanto trabalho está fluindo pelo time.

Fórmula: contagem de PRs integrados e abertos na janela, com série diária e ritmo (integrados ÷ semanas). O tamanho típico de PR reportado junto é a mediana de linhas adicionadas + removidas dos PRs integrados. Commits diretos na branch (sem PR) são mostrados à parte, para o trabalho fora do fluxo de PR não ficar invisível.

Como interpretar: é uma medida de vazão, não de qualidade. Leia em conjunto com cycle time e rework: muito volume com cycle time estável é saudável; volume crescente com rework subindo pode indicar pressa.

Rework#

O que mede: o retrabalho no fluxo de revisão, a fricção antes do merge.

Fórmula: % de PRs integrados que receberam CHANGES_REQUESTED (pedido de alteração na revisão) antes do merge.

Como interpretar: taxas altas sugerem PRs grandes demais, requisitos pouco claros ou alinhamento tardio. Um pouco de rework é saudável (a revisão está funcionando); muito rework custa tempo e energia.

Profundidade de review (review depth)#

O que mede: o engajamento e a qualidade da revisão de código.

Fórmula: comentários por PR, revisores distintos por PR, taxa de aprovação e ranking de revisores, todos sobre os PRs integrados no período.

Como interpretar: profundidade muito baixa pode indicar revisões "carimbo" (aprovação sem leitura); profundidade muito alta e concentrada em poucos revisores pode indicar gargalo. O ideal é revisão distribuída e proporcional ao risco da mudança.

Value stream#

O que mede: o lead time do planejamento à produção, a jornada completa de uma ideia, incluindo a parte que o Git sozinho não enxerga (a espera no backlog).

Fórmula: tempo da criação da issue/ticket ao primeiro deploy de produção que a entrega, decomposto em estágios (planejamento → código → deploy) e acompanhado da cobertura (% de issues fechadas com rastro completo até produção). O início do trabalho ("dev start") vem da transição real do ticket para em andamento no tracker; sem ela, usamos o 1º commit como fallback, sempre identificado. Fica mais rico com um issue tracker conectado (veja Insights do Jira).

Como interpretar: revela onde o tempo realmente vai. Frequentemente o maior atraso está antes do código (espera no backlog), algo invisível em métricas só de Git.

Saúde de CI#

O que mede: a confiabilidade e a velocidade da sua integração contínua.

Fórmula: execuções com sucesso ÷ total, duração mediana e taxa de re-execução dos workflows no período.

Como interpretar: taxa de sucesso baixa ou muitas re-execuções são sinal de flakiness (testes instáveis), que mina a confiança do time na esteira. Durações longas atrasam o feedback e inflam o estágio de deploy do cycle time.

Segurança#

O que mede: a postura de segurança via alertas (ex.: Dependabot e code scanning).

Como é calculado: alertas agrupados por severidade, estado e aging (há quanto tempo estão abertos), com tendência e SLA de resolução por faixa (7/30/60/90 dias).

Como interpretar: o foco deve estar em alertas de alta severidade abertos há muito tempo. É um recurso do plano Starter.

Benchmarks#

O que mede: como as suas métricas-chave se comparam a faixas de referência.

Como é calculado: suas métricas são posicionadas contra as faixas do relatório DORA 2023 (para as métricas DORA) e faixas de referência de engenharia (cycle time, tamanho de PR, rework).

Como interpretar: use como bússola, não como meta absoluta: o contexto do seu time importa. É um recurso do plano Starter.

PRs parados (stale)#

O que mede: os PRs abertos sem progresso, trabalho em risco de ser esquecido.

Como é calculado: identifica PRs abertos parados, normalmente ordenados do mais antigo ao mais recente. Aparecem na tela Workflow.

Como interpretar: uma lista de PRs parados crescente é um sinal de fila de revisão entupida ou de trabalho que perdeu prioridade. Quanto antes resolvidos (revisar, mergear ou fechar), melhor o fluxo.

Honestidade metodológica#

Preferimos mostrar "sem dado" a mostrar um número bonito e errado. As regras que sustentam isso:

• CFR e MTTR têm uma cadeia de fonte explícita: incidentes do PagerDuty > erros do Sentry > proxy pelo status do deploy. A tela de Deploys mostra qual fonte está em uso. No proxy, zero falhas só vira "0%" quando há evidência de que o seu CI/CD reporta falhas; sem evidência, o CFR fica sem dado (nunca um "elite" falso). Repositórios sem serviço mapeado ao PagerDuty/Sentry aparecem sem dado, não com 0%.
• Deploys sintéticos são marcados. Sem um CI/CD de deploy conectado, inferimos deploys por regras que você configura por repositório (merge de PR, commit na branch, run de CI). Eles são identificados como sintéticos e nunca duplicam um deploy real da mesma release.
• Datas derivadas têm janela de plausibilidade. O "1º commit" de um PR ignora datas herdadas de rebase/cherry-pick antigos (mais de 90 dias antes da abertura); quando não há commit plausível, usamos a abertura do PR como início e registramos a origem do dado.
• Bots ficam fora das métricas humanas. Contas automatizadas (dependabot, renovate, build services etc.) são detectadas e excluídas de métricas de pessoas e de assentos, com selo "Bot" nas listas.
• A proveniência é auditável. A tela Saúde dos dados (seção Dados, dentro do produto) mostra, para a sua organização, quanto de cada métrica vem de dado real, estimado ou pendente, e onde corrigir.

Fontes#

As definições e faixas usadas aqui seguem as referências públicas da área:

• DORA / Google Cloud: a pesquisa e os relatórios anuais Accelerate State of DevOps: dora.dev. As quatro métricas e os tiers vêm daqui (edição 2023).
• Accelerate: Nicole Forsgren, Jez Humble e Gene Kim (2018): o livro que consolidou a ligação entre as métricas DORA e performance organizacional.
• SPACE: Forsgren et al., The SPACE of Developer Productivity (ACM Queue, 2021): queue.acm.org. É o lembrete de que produtividade tem múltiplas dimensões. Por isso a plataforma combina fluxo (DORA/cycle time) com colaboração (review), bem-estar do fluxo (PRs parados, rework) e comunicação (rede de review), e nunca reduz pessoas a um ranking.

Próximos passos#

• Dashboards e telas: onde cada métrica aparece e como filtrar.
• Insights do Jira: métricas de planejamento (value stream, velocity, épicos).
• Assistente de IA: pergunte sobre qualquer métrica em linguagem natural.