As métricas de throughput ajudam a acompanhar quanto trabalho passa pelo processo de entrega de software ao longo do tempo. Ao contar o que chega a uma etapa definida, como o merge ou a produção, você consegue comparar períodos e investigar mudanças no volume de trabalho entregue pelo time. Entender o que cada métrica conta ajuda a avaliar se um número maior reflete mais trabalho concluído ou apenas uma forma diferente de dividi-lo e acompanhá-lo.
A diferença começa em onde o trabalho termina. Pull requests mergeados mostram o que chegou à integração, enquanto issues concluídas indicam o que atendeu à definição de concluído do time. Já a frequência de deploy mostra com que frequência as mudanças chegaram à produção, então essas contagens respondem a perguntas diferentes mesmo quando aparecem no mesmo dashboard.
Para interpretar um aumento, confira a regra de contagem junto do tempo de entrega e da qualidade. Throughput contribui para essa avaliação, mas não mede sozinho a produtividade, que o framework SPACE trata como multidimensional.
Métricas de throughput na entrega de software
Throughput conta itens de trabalho concluídos por unidade de tempo, o que exige definir o que é um item e onde ele começa e termina. O Kanban Guide inclui essas definições no fluxo de trabalho.
Throughput = itens de trabalho concluídos ÷ período
Suponha que um time hipotético conclua 12 issues em duas semanas, com média de seis por semana. Essa taxa descreve o período observado, mas não promete o mesmo resultado na semana seguinte nem informa quanto valor essas issues geraram para o cliente.
Se o seu fluxo termina no merge, PRs mergeados são uma métrica de throughput válida. Para medir a entrega em produção, porém, você precisa confirmar que essas mudanças chegaram à produção.
Alguns dashboards usam “métricas de throughput” de forma mais ampla. A LinearB, por exemplo, agrupa commits e reviews com PRs abertos, merges e deploys, embora sua documentação diferencie atividade de saída. Vale conferir as definições individuais antes de tratar essas medidas como equivalentes.
Escolhendo métricas de throughput
Use a tabela para escolher a métrica de acordo com a decisão que você precisa tomar. Ela aplica as distinções de Kanban, DORA e SPACE a eventos comuns da entrega.
| Métrica | O que é contado | Pergunta que ajuda a responder | O que um aumento não permite concluir sozinho | Sinal complementar útil |
|---|---|---|---|---|
| PRs mergeados por período | PRs no evento de merge, nos repositórios escolhidos | Quanto trabalho chega à integração? | Que as mudanças chegaram à produção ou entregaram mais valor | Tempo de review e evidências que relacionem mudanças a deploys |
| Issues concluídas por período | Issues que atendem a uma política de conclusão definida | Quanto trabalho acompanhado chega à conclusão? | Que o trabalho tem o mesmo tamanho, tipo ou critério de aceitação de antes | Tipo de issue, tempo de ciclo e trabalho reaberto |
| Deploys por período | Eventos de deploy de uma aplicação ou serviço | Com que frequência as mudanças chegam à produção? | Quantas funcionalidades foram entregues ou se a entrega ficou mais confiável | Change lead time, change fail rate e deployment rework rate |
| PRs abertos por período | PRs que entram no fluxo de review acompanhado | Quanto trabalho novo está entrando nesta etapa? | Que o review ou a entrega acompanharam esse ritmo | Merges, PRs em aberto e tempo de espera por review |
| Reviews concluídos por período | Eventos de review conforme uma regra de contagem explícita | Quanta atividade de review ocorreu? | Que a qualidade do review melhorou ou que mais mudanças foram concluídas | Duração do review, revisões repetidas e trabalho que chega ao merge |
PRs abertos e reviews concluídos descrevem a atividade em torno do trabalho, assim como commits e linhas alteradas. Use esses números para investigar mudanças no volume concluído, sem transformar metas de atividade em medidas de produtividade.
Mantenha unidades diferentes separadas. PRs, issues e deploys são registros distintos, então não dá para presumir uma relação de um para um sem verificar o mapeamento. Somar suas contagens produz um total pouco claro, assim como subtrair deploys de PRs abertos não calcula um backlog de entrega.
Como o DORA usa o termo throughput
O modelo atual do DORA usa cinco métricas de entrega de software, divididas entre throughput e instabilidade. Deployment frequency, change lead time e failed deployment recovery time medem throughput, enquanto change fail rate e deployment rework rate medem instabilidade.
Mais deploys por semana significam que mudanças chegam à produção com maior frequência. Já um aumento no lead time ou no failed deployment recovery time significa que a entrega ou a recuperação demora mais, então aumentar nem sempre significa melhorar.
Ao ler por que as métricas DORA mudaram, confira se o gráfico mostra itens por período ou tempo decorrido. Manter essa unidade visível evita interpretar uma espera maior como uma taxa de entrega mais alta.
Medindo throughput de forma consistente
A comparação depende de uma definição consistente de conclusão e de quais trabalhos entram na contagem. Kanban exige definir o fluxo, enquanto o DORA recomenda medir no contexto de uma aplicação ou serviço. Os passos abaixo ajudam a aplicar esses princípios.
- Defina se você precisa medir o trabalho que chega ao merge ou as mudanças que chegam à produção e escolha o ponto de conclusão correspondente.
- Defina o escopo pelos repositórios, aplicação, tipos de issue ou time. No caso das issues, inclua o status e a política de aceitação que significam conclusão, para que itens cancelados não entrem silenciosamente na contagem de entregas.
- Escolha o timestamp de conclusão e a regra de contagem, incluindo como tratar eventos duplicados e conclusões repetidas. Se cada issue for contada apenas uma vez, acompanhe as reaberturas separadamente para manter o retrabalho visível.
- Use janelas de tempo equivalentes ou mostre o denominador ao calcular uma taxa. A média semanal não informa quantos itens terminaram em cada semana.
- Anote mudanças na composição do time, nos repositórios incluídos, nos tipos e tamanhos dos itens e na política de conclusão para levá-las em conta ao comparar os números.
Para medir o throughput observado, conte diretamente os eventos de conclusão. Substituir essa contagem pelo trabalho em andamento (WIP) dividido pelo tempo de ciclo pode esconder pressupostos sobre o sistema e os períodos comparados, dificultando a conferência do resultado.
O fluxo pode mudar. Se o ponto de conclusão passar de “desenvolvimento concluído” para “aceito”, marque quando isso aconteceu para que o leitor consiga distinguir uma nova definição de uma mudança de desempenho.
Interpretando um aumento no throughput
Uma taxa de conclusão maior significa que mais itens terminaram por unidade de tempo, desde que a definição e a cobertura tenham permanecido iguais. Para entender se a entrega melhorou, ainda é preciso examinar o trabalho por trás da contagem, como mostram estes exemplos hipotéticos.
Um time divide mudanças grandes em PRs menores, e a contagem de merges aumenta. O DORA recomenda lotes menores para apoiar uma entrega rápida e estável, então essa pode ser uma mudança útil na forma de trabalhar. Para avaliá-la, confira o tempo de review e a qualidade, depois confirme o que chegou à produção. A contagem sozinha não informa quanto do aumento veio da divisão do trabalho, e PRs menores não são evidência de manipulação.
Um time que encerra mais issues enquanto dedica mais tempo a corrigir bugs concluiu mais itens acompanhados, mas pode não ter entregue mais funcionalidades. Separe a contagem por tipo de trabalho e confira por que a composição mudou. As correções podem vir de um backlog antigo ou de novos problemas, e o total não permite distinguir os dois casos.
Se uma aplicação recebe deploys com mais frequência enquanto uma proporção maior deles responde a incidentes em produção, a parcela de trabalho corretivo também está crescendo. Leia a frequência junto de change fail rate e deployment rework rate dessa aplicação antes de avaliar o aumento.
Use métricas ágeis complementares para decidir onde investigar e confira os itens envolvidos antes de atribuir uma causa à tendência.
Throughput estável também pode acompanhar uma melhoria se um volume comparável terminar mais cedo ou com menos falhas. Mesmo assim, o valor para o cliente exige evidências além das contagens de conclusões ou deploys, conforme a visão multidimensional de produtividade do SPACE.
Escolha uma métrica que ajude a agir
Antes de usar um gráfico de throughput na revisão de entrega, confira se o time sabe o que foi contado e em qual período. Mantenha ao lado dele uma medida de tempo e um sinal de qualidade relevantes.
Quando a contagem mudar, use a definição para decidir o que conferir. Mais PRs mergeados pedem uma checagem do que chegou à produção, enquanto mais issues concluídas pedem uma checagem do tipo de trabalho e da política de conclusão.