Como você sabe se seu time de engenharia está performando bem? Por muito tempo, a resposta era subjetiva: "parece que estamos indo bem" ou "sinto que estamos lentos". As métricas DORA mudaram esse cenário ao oferecer um framework científico e validado para medir a performance de entrega de software.
Desenvolvidas pelo programa DORA (DevOps Research and Assessment), liderado por Nicole Forsgren, Jez Humble e Gene Kim, essas métricas são resultado de anos de pesquisa com milhares de organizações ao redor do mundo. Elas demonstraram que é possível ser simultaneamente rápido e estavel, desmentindo o mito de que velocidade e qualidade são mutuamente exclusivas.
As 4 métricas DORA
O framework DORA e composto por exatamente quatro métricas, divididas em duas categorias: velocidade (throughput) e estabilidade. Essa simplicidade e proposital. Em vez de tentar medir tudo, as métricas DORA capturam os sinais mais significativos da saude de um time de engenharia.
Métricas de velocidade
1. Deployment Frequency (Frequência de Deploy)
Mede com que frequência o time faz deploy para produção. Está métrica reflete a capacidade do time de entregar mudanças pequenas e frequentes, que são fundamentais para reduzir riscos e acelerar feedback.
Por que importa: deploys frequentes significam mudanças menores, que são mais fáceis de testar, revisar e reverter se necessario. Times que fazem deploy uma vez por mes acumulam semanas de mudanças em um único release, aumentando dramaticamente o risco e a complexidade.
| Nível de performance | Deployment Frequency |
|---|---|
| Elite | Sob demanda (múltiplos deploys por dia) |
| Alta | Entre 1 por dia e 1 por semana |
| Media | Entre 1 por semana e 1 por mes |
| Baixa | Menos de 1 por mes |
2. Lead Time for Changes (Tempo de Entrega de Mudanças)
Mede o tempo entre um commit de código e esse código rodando em produção. Inclui o tempo de code review, testes automatizados, aprovações e o processo de deploy em si.
Por que importa: um lead time curto significa que o time consegue responder rapidamente a necessidades do negócio, bugs críticos e feedback de usuários. Um lead time longo indica gargalos no processó que estão travando o fluxo de entrega.
| Nível de performance | Lead Time for Changes |
|---|---|
| Elite | Menos de 1 hora |
| Alta | Entre 1 dia e 1 semana |
| Media | Entre 1 semana e 1 mes |
| Baixa | Mais de 6 meses |
Métricas de estabilidade
3. Change Failure Rate (Taxa de Falha de Mudanças)
Mede o percentual de deploys que resultam em falha, degradação de serviço ou necessidade de rollback. Uma mudança "falha" quando causa um incidente, requer um hotfix imediato ou precisa ser revertida.
Por que importa: não adianta fazer deploy 10 vezes por dia se metade dos deploys quebra algo. A change failure rate equilibra a equação, garantindo que a velocidade não vem as custas da estabilidade.
| Nível de performance | Change Failure Rate |
|---|---|
| Elite | 0-15% |
| Alta | 16-30% |
| Media | 16-30% |
| Baixa | 46-60% |
4. Time to Restore Service (Tempo de Restauração do Serviço)
Mede quanto tempo o time leva para restaurar o serviço após uma falha em produção. Isso inclui o tempo para detectar o problema, diagnostica-lo e implementar a correcao.
Por que importa: falhas vao acontecer, independentemente de quao cuidadoso o time seja. O que diferencia times de elite não e a ausência de falhas, mas a velocidade com que se recuperam. Um time que restaura o serviço em 10 minutos causa muito menos impacto do que um que leva 2 dias.
| Nível de performance | Time to Restore Service |
|---|---|
| Elite | Menos de 1 hora |
| Alta | Menos de 1 dia |
| Media | Entre 1 dia e 1 semana |
| Baixa | Mais de 6 meses |
A grande descoberta: velocidade e estabilidade não são trade-offs
A descoberta mais surpreendente da pesquisa DORA e que os times de elite são melhores em todas as quatro métricas simultaneamente. Eles fazem deploy mais frequentemente, com lead time menor, taxa de falha menor e recuperação mais rápida.
Isso contradiz a crenca convencional de que existiria um trade-off entre velocidade e estabilidade: "se quisermos ser mais rápidos, vamos ter mais bugs" ou "se quisermos mais qualidade, vamos ser mais lentos". Os dados mostram o oposto: as práticas que aumentam a velocidade (deploys pequenos, automação, CI/CD) também aumentam a estabilidade.
"Os dados são claros: não ha trade-off entre velocidade e estabilidade. Times de elite são melhores em ambas. A pergunta não e 'velocidade ou qualidade?', e 'como conseguimos ambas?'"
Como comecar a medir as métricas DORA
Passo 1: Defina o que conta como deploy
A definição de "deploy" pode variar entre times. Para alguns, e qualquer merge na branch principal. Para outros, e quando o código chega efetivamente ao ambiente de produção. Escolha uma definição consistente e mantenha-a.
Passo 2: Identifique as fontes de dados
Cada métrica tem fontes de dados diferentes:
- Deployment Frequency: logs do pipeline de CI/CD, registros de deploy
- Lead Time: timestamps de commits no Git e timestamps de deploys
- Change Failure Rate: registros de incidentes, rollbacks, hotfixes
- Time to Restore: sistema de alertas, registros de incidentes, timestamps de resolução
Passo 3: Automatize a coleta
Coletar métricas manualmente e insustentável. Integre suas ferramentas para capturar os dados automaticamente. A integração entre o GalagoWork e o GitHub, por exemplo, permite rastrear o fluxo desde a criação da tarefa até o merge do pull request, fornecendo dados para calcular lead time automaticamente.
Passo 4: Visualize e comunique
Crie um dashboard visível para todo o time com as quatro métricas. Atualize-o regularmente (idealmente automaticamente) e discuta os números nas retrospectivas. A transparência é fundamental para gerar engajamento e motivação para melhorar.
Estratégias para melhorar cada métrica
Melhorando Deployment Frequency
- Automatize o pipeline de deploy (elimine passos manuais)
- Use feature flags para separar deploy de release
- Quebre features grandes em incrementos menores deployáveis
- Elimine aprovações manuais desnecessárias no processo de deploy
- Adote trunk-based development em vez de branches de longa duração
Melhorando Lead Time for Changes
- Reduza o tamanho dos pull requests (PRs menores são revisados mais rápido)
- Estabeleca SLAs para code review (ex: máximo 4 horas)
- Otimize o tempo de execução dos testes automatizados
- Elimine filas e gargalos no pipeline de CI/CD
- Reduza o número de ambientes intermediários
Melhorando Change Failure Rate
- Invista em testes automatizados abrangentes (unitarios, integração, e2e)
- Implemente deploys canary ou blue-green
- Use feature flags para rollouts graduais
- Melhore o processo de code review com foco em riscos
- Implemente testes de contrato para integração entre serviços
Melhorando Time to Restore
- Implemente alertas proativos baseados em SLIs
- Crie runbooks detalhados para problemas comuns
- Automatize rollbacks
- Pratique resposta a incidentes com game days regulares
- Invista em observabilidade (logs, métricas, traces)
Armadilhas ao usar métricas DORA
Goodhart's Law: quando a métrica vira meta
A Lei de Goodhart diz: "Quando uma medida se torna uma meta, ela deixa de ser uma boa medida." Se o time for pressionado a aumentar a frequência de deploy a qualquer custo, pode comecar a fazer deploys vazios ou triviais para inflar o número. As métricas devem ser usadas como diagnóstico, não como meta de desempenho individual.
Comparação entre times diferentes
Cada time opera em um contexto diferente. Um time que trabalha em um sistema legado de 15 anos terá métricas diferentes de um time que trabalha em um microserviço greenfield. Comparações diretas são injustas e improdutivas. Use as métricas para acompanhar a evolucao do mesmo time ao longo do tempo.
Foco excessivo em uma única métrica
As quatro métricas funcionam como um sistema. Otimizar uma as custas das outras cria desequilibrios. Aumentar a frequência de deploy sem investir em testes vai aumentar a change failure rate. Reduzir a change failure rate adicionando aprovações manuais vai aumentar o lead time. O objetivo é melhorar todas as quatro de forma equilibrada.
Métricas complementares
As métricas DORA capturam a performance de entrega, mas não contam toda a história. Considere complementa-las com:
- Cycle Time: tempo desde o início do trabalho em uma tarefa até sua conclusão. Complementa o lead time ao capturar o tempo de desenvolvimento, não apenas o tempo de deploy.
- Flow Efficiency: percentual do cycle time em que a tarefa está sendo ativamente trabalhada (vs. esperando em filas). Revela gargalos no processo.
- Developer Experience (DevEx): pesquisas qualitativas sobre satisfação, produtividade percebida é fácilidade de uso das ferramentas.
- Cobertura de testes: percentual do código coberto por testes automatizados. Indicador de saude técnica.
DORA e a cultura do time
As métricas DORA não são apenas sobre ferramentas e processos. A pesquisa DORA também identificou práticas culturais que se correlacionam com alta performance:
- Segurança psicológica: membros do time se sentem seguros para correr riscos e cometer erros.
- Colaboração: desenvolvimento e operações trabalham juntos, não em silos.
- Aprendizado continuo: o time tem tempo e incentivo para experimentar e aprender.
- Autonomia: o time pode escolher suas ferramentas e processos.
Tentar melhorar as métricas sem abordar esses aspectos culturais e como tentar correr mais rápido com sapatos amarrados. As práticas técnicas são necessarias, mas não suficientes.
Conclusão
As métricas DORA oferecem uma lente poderosa e científicamente validada para entender a performance do seu time de engenharia. Elas são simples o suficiente para serem comúnicadas a qualquer stakeholder, mas profundas o suficiente para guiar decisões estrategicas sobre investimentos em engenharia.
Comece medindo onde você está hoje. Não se preocupe se os números iniciais forem ruins. O valor está na tendência, não no valor absoluto. Meca, melhore, meca novamente. Com consistência e foco, qualquer time pode progredir significativamente nas métricas DORA.
O GalagoWork, com sua integração nativa com GitHub e rastreamento visual do fluxo de trabalho, oferece a base perfeita para comecar a coletar dados e acompanhar a evolucao das suas métricas de entrega.