flow-metrics-vs-dora-metrics Aqui está o veredicto que a maioria das comparações se recusa a dar: DORA diz quais são os seus resultados de entrega, e métricas de flow dizem por que eles são assim.

Elas não são rivais, e você não precisa escolher uma para sempre. Para a maioria dos times, a resposta para "qual primeiro" é DORA, porque é mais simples de instrumentar e os dados vêm direto do Git e CI. Você adiciona métricas de flow quando precisa explicar um número em vez de apenas observá-lo mudar.

Aqui definimos os dois conjuntos, comparamos lado a lado, apontamos onde eles realmente se sobrepõem, respondemos qual acompanhar primeiro para cada tipo de time e mostramos como lê-los juntos, tratando ambos como instrumentos de diagnóstico e não como placares.

Métricas de flow vs métricas DORA: principais conclusões

  • DORA mede resultados de entrega, velocidade e estabilidade, enquanto métricas de flow medem como o trabalho se move por todo o fluxo de valor desde o momento em que entra no sistema.
  • Os dois se sobrepõem: flow time e lead time DORA são parentes próximos, e a diferença real é escopo, já que DORA começa no commit e flow começa quando o trabalho é solicitado.
  • A maioria dos times deve começar com DORA porque não exige mudança de processo, depois adicionar métricas de flow para explicar por que um número DORA se moveu.
  • Lidas juntas, DORA detecta que algo mudou e flow mostra onde e por que, o que realmente direciona uma intervenção.
  • Comece um trial gratuito do DevStats e veja seus resultados de entrega e gargalos lado a lado em menos de 2 minutos, sem mudar código.

O que são métricas DORA?

Métricas DORA são quatro medidas de performance de entrega de software: deployment frequency (com que frequência você entrega), lead time for changes (do commit à produção), change failure rate (parcela de deploys que falham) e time to restore service (quão rápido você recupera o serviço).

Juntas capturam as duas metades da entrega: velocidade e estabilidade. O DevStats mostra as quatro métricas DORA em um dashboard, para que você possa acompanhá-las sem precisar unir os dados manualmente.

Elas vêm da pesquisa DORA do Google e são o benchmark de entrega mais adotado do mercado. Para uma explicação completa, veja o que são as métricas DORA e measuring and improving software delivery with DORA metrics.

O ponto chave para esta comparação é o que DORA é: um placar de resultados. Ela diz que sua entrega ficou mais lenta ou menos estável, e é exatamente por isso que não consegue dizer onde está o problema ou o que fazer a respeito.

O que são métricas de flow?

Métricas de flow medem como o trabalho se move pelo fluxo de valor, desde o momento em que um item é solicitado até o momento em que é entregue. Elas vêm do Flow Framework desenvolvido por Mik Kersten, e são frequentemente chamadas de métricas de value stream, que é a mesma ideia com outro nome.

Enquanto DORA observa o pipeline de entrega a partir do commit, métricas de flow observam toda a jornada que um trabalho percorre, incluindo todo o tempo de espera antes de alguém tocá-lo. São cinco, e cada uma responde a uma pergunta diferente sobre essa jornada. A visão de flow do DevStats é onde elas se reúnem na prática.

Flow time

Flow time é o tempo total decorrido de um item de trabalho do início ao fim, incluindo toda espera pelo caminho. É a resposta de flow para "quanto tempo o trabalho realmente leva", medida do ponto de vista de quem solicitou e não do desenvolvedor.

Como usar: compare com o tempo de mãos na tarefa para ver quanto do total é espera em vez de trabalho. Essa diferença costuma ser maior do que qualquer um espera, e é o que torna o flow time valioso de medir. Ele se relaciona de perto com por que cycle time é a métrica mais importante.

Flow efficiency

Flow efficiency é a parcela do flow time em que um item de trabalho está sendo ativamente trabalhado em vez de parado. É a métrica de flow mais reveladora, porque a maioria dos times descobre que a maior parte do tempo decorrido de um item é espera, não trabalho.

Como usar: uma porcentagem baixa aponta para handoffs, filas de review e dependências bloqueadas, não para desenvolvedores lentos. Essa é a métrica mais facilmente mal interpretada como medida de esforço, por isso vale deixar claro: flow efficiency baixa acusa o sistema, não as pessoas.

Flow velocity

Flow velocity é o número de itens de trabalho concluídos em um período, a visão de throughput do flow. Mostra o ritmo de entrega sem a bagagem de estimativa de story points, porque conta itens finalizados em vez de pontos.

Como usar: observe a tendência em vez do número absoluto, porque o tamanho dos itens varia e a contagem de um único período sozinha diz pouco. O throughput acompanhado ao longo do tempo é o sinal utilizável.

Flow load

Flow load é o número de itens em progresso ao mesmo tempo, a visão de work in progress do sistema. Um flow load alto normalmente puxa o flow time para cima, porque a troca de contexto multiplica a espera e nada termina enquanto tudo está pela metade.

Como usar: combine com flow time para defender limites de WIP. Quando a carga sobe e o flow time sobe junto, você tem evidência para argumentar que é melhor terminar o que começou antes de iniciar mais coisas.

Flow distribution

Flow distribution é a divisão do trabalho por tipo entre features, defeitos, risco e dívida técnica. Revela se o time está construindo novo valor ou absorvendo manutenção, o que frequentemente só fica visível quando medido.

Como usar: leve para conversas de roadmap quando as suposições de capacidade não batem com a realidade. É a métrica que transforma "nunca temos tempo para features" em um número, e combina naturalmente com como lidar com trabalho não planejado.

Métricas de flow vs métricas DORA comparadas

A forma mais clara de enxergar a diferença é lado a lado. DORA e métricas de flow respondem perguntas diferentes a partir de dados diferentes, e cada uma deixa de ver o que a outra captura.

Métricas DORA Métricas de flow
O que medem Resultados de entrega: velocidade e estabilidade Como o trabalho se move pelo fluxo de valor
Pergunta que respondem Quais são nossos resultados de entrega? Onde e por que o trabalho desacelera?
De onde vêm os dados Git e pipelines de CI/CD Issue tracker e fluxo de valor
Escopo Do commit à produção Da solicitação à entrega, incluindo toda a espera
Quem usa Lideranças comparando saúde da entrega Times diagnosticando onde o trabalho trava
O que deixam de ver Onde está o gargalo Estabilidade em produção e taxa de falha

A tabela deixa a relação óbvia. DORA é o resultado, flow é a explicação, e um time que observa apenas um dos lados ou vê resultados sem causa ou vê processo sem a realidade de produção.

Onde os dois conjuntos se sobrepõem

A concessão honesta que a comparação costuma pular: flow time e lead time for changes medem quase a mesma coisa, e flow velocity fica próximo de deployment frequency no espírito. Se você já acompanha um dos conjuntos, parte do outro não é informação nova.

A diferença real é escopo. Lead time DORA começa no commit, enquanto flow time começa quando o trabalho entra no sistema, então flow captura a espera no backlog, o atraso no refinamento e o lag até alguém pegar a tarefa, que DORA nunca vê. Essa é a mesma distinção que exploramos em lead time versus cycle time, e issue cycle time é onde essa janela anterior fica visível.

Então acompanhar os dois não significa dobrar o volume de métricas. Significa ampliar a janela sobre o mesmo pipeline de entrega, desde a jornada completa de solicitação a release até o núcleo de commit a produção, e ler os dois níveis de zoom juntos.

Qual seu time deve acompanhar primeiro?

Responda diretamente, sem meias palavras. O ponto de partida certo depende de onde o time está e onde está a história real:

  • Comece com DORA se você é novo em medição, porque os dados vêm direto do Git e CI e não exigem mudança de processo para coletar.
  • Comece com DORA se precisa de um benchmark de entrega para reportar para cima, porque as faixas de performance dão uma referência externa.
  • Comece com métricas de flow se o time já entrega de forma estável, mas não consegue explicar por que o trabalho fica parado, o que é um problema de wait time que DORA não consegue localizar.
  • Comece com métricas de flow se o issue tracker guarda a história real, ou seja, se a maior parte do seu atraso acontece antes do código ser commitado.

Para a maioria dos times a sequência é DORA primeiro, flow depois. Você instrumenta o resultado, nota um número que não consegue explicar e recorre às métricas de flow para encontrar a causa.

Como usar métricas de flow e DORA juntas

O padrão prático é simples: leia DORA para detectar que algo se moveu, depois leia flow para descobrir onde e por que. DORA é o alarme, flow é a investigação.

Veja um exemplo concreto. Seu lead time DORA sobe ao longo de um trimestre, o que diz que a entrega ficou mais lenta, mas não diz a causa. Você puxa a flow efficiency e vê que ela caiu no mesmo período, o que significa que os itens passaram mais tempo esperando do que sendo trabalhados.

Isso aponta para wait time, então você olha o flow load e vê que o WIP subiu, e agora tem uma hipótese: o time abraçou muita coisa ao mesmo tempo, a troca de contexto aumentou e as coisas ficaram pela metade. Uma visão por estágios do PR cycle time confirma qual estágio absorveu a espera.

Você continua sendo quem decide. Os dois conjuntos de métricas entregam uma hipótese; você decide a intervenção, seja um limite de WIP ou uma mudança no roteamento de reviews, e depois verifica se os números se moveram.

Erros comuns ao acompanhar métricas de flow e DORA

Alguns erros previsíveis transformam dois conjuntos úteis em ruído. Cada um tem uma consequência que vale a pena pegar cedo:

  • Acompanhar os dois sem decidir qual pergunta cada um responde, o que produz um dashboard lotado que ninguém lê em vez de um diagnóstico.
  • Comparar flow efficiency entre times diferentes, já que um time de plataforma e um time de features têm perfis legítimamente distintos e a comparação só induz ao erro.
  • Tratar qualquer métrica como alvo, o que convida a gamificação e faz o número parar de refletir a realidade.
  • Usar qualquer um dos conjuntos para avaliar indivíduos, o que mede a coisa errada e quebra a confiança.

Esse último é a linha dura. Métricas de flow e DORA medem processos, não pessoas, e flow efficiency em particular é uma afirmação sobre o wait time do sistema e não sobre o esforço de nenhum desenvolvedor. Mantenha ambas no nível do time, onde descrevem um fluxo de trabalho que vocês podem melhorar juntos.

Acompanhe métricas de flow e DORA com DevStats

Ler os dois conjuntos juntos significa costurar dados do Git e do issue tracker em uma única visão, o que é tedioso de fazer manualmente e fácil de fazer errado.

O DevStats é uma plataforma de engineering intelligence que conecta suas ferramentas existentes de Git, issue e incidentes e mostra métricas DORA ao lado de sinais de cycle time e flow, com benchmarks.

O enquadramento permanece diagnóstico. O DevStats mostra o resultado e o onde: o lead time subiu e a espera se concentrou na etapa de review, e você decide a intervenção.

Tudo é medido no nível de processo, nunca como ranking individual, porque o objetivo é ampliar sua visão do pipeline e não pontuar as pessoas que trabalham nele.

Veja os dois lados do seu pipeline de entrega

Pare de adivinhar por que a entrega desacelerou. Conecte suas ferramentas de Git, issue e incidentes e o DevStats mostra seus resultados DORA ao lado dos seus gargalos de flow, comparados com mais de 1.000 times de engenharia, para que você veja exatamente onde o trabalho para e decida o que mudar.

A configuração leva menos de 2 minutos e não exige mudanças de código, e times que leem os dois lados entregam até 30% mais rápido.

Comece um trial gratuito e coloque os dois lados do seu pipeline para trabalhar para você hoje.

Perguntas frequentes

Qual é a diferença entre métricas de flow e métricas DORA?

Métricas DORA medem resultados de entrega, velocidade e estabilidade, usando dados de Git e CI, enquanto métricas de flow medem como o trabalho se move por todo o fluxo de valor, da solicitação à entrega. DORA diz quais são seus resultados; flow diz onde e por que o trabalho desacelera. A principal diferença de escopo é que DORA começa no commit e flow começa quando o trabalho entra no sistema.

Você deve acompanhar métricas de flow e DORA?

A maioria dos times se beneficia dos dois conjuntos, mas não ao mesmo tempo. Comece com DORA porque não exige mudança de processo e dá um benchmark de entrega, depois adicione métricas de flow quando precisar explicar por que um número DORA se moveu. Acompanhar os dois não é dobrar o trabalho, porque os conjuntos se sobrepõem e ampliam a mesma visão em vez de duplicá-la.

O que é flow efficiency?

Flow efficiency é a parcela do tempo total decorrido de um item de trabalho que ele passa sendo ativamente trabalhado em vez de parado. Uma porcentagem baixa significa que a maior parte do tempo é espera, causada por handoffs, filas de review ou dependências bloqueadas, o que aponta para o sistema e não para o esforço do desenvolvedor. É frequentemente a métrica de flow mais reveladora porque a parcela de espera costuma ser muito maior do que os times esperam.

Métricas de flow são a mesma coisa que métricas de value stream?

Sim, métricas de flow e métricas de value stream se referem ao mesmo conjunto de medidas de como o trabalho se move pelo sistema de entrega. As cinco vêm do Flow Framework: flow time, flow efficiency, flow velocity, flow load e flow distribution. O nome "value stream" enfatiza que elas acompanham toda a jornada do trabalho, e não apenas a etapa de código.