Guias DevStats / Interpretando suas métricas

Mediana vs. Média: Como Usá-las nas Métricas de Engenharia?

Alguns PRs demorados podem alterar a média do tempo de ciclo do seu time. Compare com a mediana para decidir o que analisar.

Cinco durações fictícias de PRs: 2, 3, 4, 5 e 31 horas. Todos os valores contribuem para a média de 9 horas. O valor central dá uma mediana de 4 horas.CINCO PULL REQUESTSDADOS ILUSTRATIVOS / HORAS2h 3h 4h 5h 31h MÉDIA 9 hSOMA ÷ QUANTIDADEMEDIANA 4 hORDENE → CENTRO
01

Afinal qual é a diferença?

Se você trabalha com métricas de engenharia, provavelmente vê médias o tempo todo: tempo médio de revisão, cycle time médio das pull requests, throughput médio…

Mas a média nem sempre mostra o que realmente está acontecendo no seu processo.

Charge em um bar. O bartender anuncia que, com a chegada de Bill Gates, todos são bilionários em média. Um cliente pergunta se pode ver seu bilhão. A legenda diz que média não é o mesmo que típico.

Um ou dois casos muito fora do padrão podem puxar o número para cima ou para baixo e alterar completamente a interpretação.

A mediana, também conhecida como percentil 50 (P50), ajuda exatamente nisso. Ela mostra o valor no meio da distribuição e, muitas vezes, representa melhor o comportamento normal dos processos.

Charge comparando mediana e média. Um cliente no meio do grupo representa a mediana, enquanto Bill Gates, com uma bolsa de dinheiro, ilustra como um valor extremo altera a média.

Isso não quer dizer que a média seja uma métrica ruim. Ela considera todos os valores, incluindo os extremos (outliers), e isso pode ser exatamente o que você precisa em certas situações.

O problema surge quando usamos a média para responder perguntas que ela não consegue responder bem. Entender quando olhar para a média e quando olhar para a mediana pode mudar não só como você interpreta os números, mas também as decisões que você toma com base neles.

Veja como um único valor pode influenciar a média

Tempos de ciclo fictícios de PRs / horas
Cada pull request
  1. PR A20h
  2. PR B24h
  3. PR C24hP50
  4. PR D28h
  5. PR E24h
Média24h
Mediana24h
Como a assimetria muda a médiaMédia 24h. Mediana 24h. Curva ilustrativa da assimetria. Os valores são calculados com os cinco PRs.MedianaMédia

Distribuição simétrica

Curva ilustrativa da assimetria. Os valores são calculados com os cinco PRs.

Como calculamos?
Some as durações e divida por cinco

(20 + 24 + 24 + 28 + 24) ÷ 5 = 24h

Ordene os valores e encontre o centro
  1. 20h
  2. 24h
  3. 24h
  4. 24h
  5. 28h

O valor central deste grupo continua em 24h, mesmo quando o PR E se torna o mais rápido ou o mais lento.

A média nem sempre representa o comportamento da maioria.

02

Entenda os cenários

Mesmos dados, leituras diferentes. Veja como cada medida pode mudar a interpretação e a decisão. Os exemplos são ilustrativos, e as decisões mostram o que uma leitura isolada pode sugerir. As durações usam dias corridos, e cada semana equivale a 7 dias.

Situação 01

Nosso processo de code review está lento?

Review Time
1d, 2d, 2d, 3d, 1sem

Média

3d

Considerando todos os PRs, o Review Time ficou em 3 dias. O review que levou uma semana teve bastante peso nesse resultado.

Decisão possível

Entender por que alguns PRs específicos demoram muito mais que outros.

Mediana

Mais útil para esta pergunta

2d

O review de um PR típico leva aproximadamente 2 dias.

Decisão possível

Verificar se os 2 dias típicos atendem à necessidade do time antes de mudar todo o processo.

Situação 02

Quanto trabalho devemos planejar para o próximo sprint?

Throughput por sprint de 2 semanas
18, 19, 20, 23, 100 issues
Sprint excepcional
Uma migração dividida em muitas issues pequenas levou a 100 conclusões.

Média

36 issues

Um único sprint puxa a média para 36 issues, embora os outros quatro tenham ficado entre 18 e 23.

Decisão possível

Planejar 36 issues e assumir que o volume excepcional da migração pode se repetir no próximo sprint.

Mediana

Mais útil para esta pergunta

20 issues

O throughput típico está mais próximo de 20 issues por sprint de duas semanas.

Decisão possível

Usar aproximadamente 20 issues como referência inicial e verificar se o próximo sprint tem trabalho de tamanho semelhante.

Situação 03

Como nosso Cycle Time se compara ao benchmark?

Nosso PR Cycle Time
1d, 2d, 2d, 3d, 2sem
Benchmark hipotético
Média de 3d por PR
Escopo comparável
Mesma definição da métrica, etapas incluídas, período de medição e trabalho semelhante.

Média

Mais útil para esta pergunta

4,4d

Nossa média supera os 3d do benchmark. O PR que levou 2sem contribui para esse resultado.

Decisão possível

Usar a diferença para examinar as esperas mais longas e testar mudanças que reduzam o Cycle Time médio.

Mediana

2d

Um PR típico leva 2d. Comparar esse valor com a média de 3d do benchmark faria o time parecer mais rápido, mas mistura medidas diferentes.

Decisão possível

Usar 2d para acompanhar o fluxo típico. Usar nossa média na comparação com esse benchmark.

Use a mesma medida publicada pelo benchmark. Se a referência apresentar uma mediana, compare medianas.

Situação 04

Nossa mudança de processo melhorou o Cycle Time?

Use as duas
Antes
1sem, 2sem, 2sem, 3sem, 12sem
Depois
4d, 1sem, 1sem, 10d, 12sem

Média

4sem → 3,2sem

Considerando todos os itens, a média caiu de 4 para 3,2 semanas. O caso de 12 semanas continua pesando no resultado.

Decisão possível

Concluir que a mudança teve pouco impacto.

Mediana

2sem → 1sem

Para o trabalho típico, o Cycle Time caiu de 2 semanas para 1 semana.

Decisão possível

Reconhecer que o fluxo melhorou para a maior parte das entregas.

A mediana mostra a melhoria no fluxo típico, enquanto a média mostra que ainda existem casos muito lentos que precisam ser analisados.

Situação 05

Qual time tem o processo de review mais saudável?

Use as duas
Squad A
1d, 1d, 2d, 2d, 2sem
Squad B
3d, 3d, 3d, 4d, 4d

Média

A 4d · B 3,4d

Pela média, a Squad B parece mais rápida.

Decisão possível

Analisar o tempo de review da Squad A, que apresenta uma média maior.

Mediana

A 2d · B 3d

O review de um PR típico termina mais rapidamente na Squad A.

Decisão possível

Examinar as práticas da Squad A para entender o review típico mais rápido.

Não transforme isso em ranking de times. A Squad A tem um fluxo típico mais rápido, mas com uma cauda problemática, enquanto a Squad B é mais consistente.

Métricas de fluxo ajudam a entender os processos, não a criar rankings entre times.

03

Compare no DevStats

1. Compare a média e a mediana

  • No PR Cycle Time, comece pela média para ver o resultado considerando todos os PRs.

Abrindo Controls no DevStats, selecionando Average e salvando para atualizar PR Cycle Time.

  • Compare com a mediana para ver o tempo de um PR típico. Use o mesmo time, período e filtros nas duas medidas.

Trocando Average por Median (50th Percentile) em Controls e salvando para comparar PR Cycle Time com os mesmos filtros.

2. Identifique PRs fora do padrão (outliers)

  • Observe quais PRs levaram muito mais tempo que os demais. Eles podem ajudar a entender a diferença entre a média e a mediana.

Selecionando Scatter no relatório PR Cycle Time e passando o cursor sobre um PR com tempo de ciclo mais longo.

3. Investigue os PRs com maior tempo de ciclo

  • Examine um desses PRs para descobrir em quais etapas o tempo se concentrou.

Abrindo os detalhes de um PR no DevStats para analisar as etapas do tempo de ciclo e as informações da entrega.

Com isso, você pode identificar se os atrasos são casos isolados ou se há um padrão que merece atenção.

Para saber mais: consulte a documentação de Controls e a definição de PR Cycle Time.

As preferências de Controls são reutilizadas entre métricas compatíveis. Ao finalizar, selecione novamente a medida que deseja manter.