Por que as Métricas DORA Importam Mais do que a Velocidade
Cada sprint planning a que assisti tem o mesmo ritual. Alguém mostra o gráfico de velocidade, a equipa debate se os 42 pontos do último sprint foram "bons", e toda a gente se compromete a 45 desta vez. Duas semanas depois, o ciclo repete-se. Ninguém faz a pergunta que importa: estamos a melhorar na entrega de software?
A velocidade mede atividade. Não diz nada sobre se esses pontos se traduziram em valor, se o código foi estável, ou se a equipa está a melhorar. Já vi equipas com velocidade a disparar que não conseguiam entregar uma funcionalidade fiável para salvar a vida. E equipas pequenas com um throughput modesto que faziam deploy com confiança várias vezes por dia com quase zero incidentes.
A diferença? O segundo grupo estava a acompanhar as métricas DORA.
O que São as Métricas DORA?
Em 2018, Nicole Forsgren, Jez Humble e Gene Kim publicaram Accelerate: The Science of Lean Software and DevOps. O livro destilou anos de investigação em quatro métricas que preveem as performances de entrega de software. Não opiniões — indicadores validados por dados em milhares de organizações.
Frequência de Deploy — com que frequência a tua equipa faz deploy em produção. As equipas de élite fazem deploy a pedido, várias vezes por dia. Os low performers fazem deploy mensalmente ou menos. Isto captura a tua capacidade de entregar mudanças pequenas e incrementais em vez de grandes lançamentos arriscados.
Lead Time para Mudanças — o tempo desde o commit do código até estar a correr em produção. Élite: menos de uma hora. Low performers: de um a seis meses. Cada gargalo no teu pipeline — revisão de código, CI/CD, testes, aprovações — aparece aqui.
Tempo Médio de Restauração (MTTR) — quando a produção quebra, quanto tempo demora a recuperar? A élite restaura em menos de uma hora. Os low performers demoram uma semana ou mais. Isto reflete diretamente o teu monitoring, alerting e resposta a incidentes.
Taxa de Falha de Mudanças — que percentagem de deploys causa uma falha em produção. A élite fica entre 0-15%. Os low performers excedem 46%. Isto captura a qualidade do código, a cobertura de testes e a fiabilidade do pipeline.
A descoberta contraintuitiva: velocidade e estabilidade não são compromissos. As equipas de maior desempenho são simultaneamente as mais rápidas e as mais estáveis. Fazem deploy mais frequentemente, recuperam mais depressa e quebram menos.
Por que a Velocidade Te Falha
É um número relativo e interno. Os story points significam coisas diferentes para equipas diferentes. Uma velocidade de 60 não te diz nada sem um contexto profundo sobre o que esses pontos representam. Não há benchmark externo.
Incentiva o comportamento errado. Quando o management observa a velocidade, as equipas otimizam-na. Inflacionam estimativas, dividem histórias para aumentar contagens, e evitam refactoring porque não produz pontos "visíveis". A métrica torna-se um alvo, e uma vez que uma métrica se torna um alvo, deixa de ser uma boa métrica — a Lei de Goodhart.
Mede outputs, não outcomes. Um sprint em que a equipa queima 50 pontos mas quebra a produção dois dias? A velocidade diz ótimo sprint. DORA diz desastre.
Como Começar a Acompanhar
Não precisas de uma plataforma. Começa de forma simples.
Frequência de Deploy. Conta os deploys em produção por semana nos teus logs CI/CD. Se estás a fazer deploy menos de uma vez por semana, os teus lançamentos são demasiado grandes, as tuas branches vivem demasiado tempo, ou o teu processo de deploy é demasiado doloroso.
Lead Time para Mudanças. Timestamp do merge commit menos o primeiro commit na branch. Se for mais de uma semana, encontra o constrangimento: atrasos na revisão de código? CI lento? Gargalo de QA manual?
MTTR. Acompanha os incidentes de produção: quando detetados, quando resolvidos. Mesmo uma folha de cálculo funciona. Aponta para menos de 24 horas inicialmente; menos de uma hora é élite.
Taxa de Falha de Mudanças. Deploys que causaram incidentes dividido pelo total de deploys. Abaixo de 15% é élite. Acima de 30% significa que o teu pipeline de testes tem buracos.
A Conversa Muda
Quando as equipas mudam para métricas DORA, as conversas mudam. Em vez de "cumprimos o nosso compromisso de sprint?" perguntam "porque é que o nosso lead time disparou na semana passada?" Em vez de discutir 3 pontos versus 5, os engenheiros investigam porque é que o deploy de quinta falhou.
As métricas DORA são indicadores avançados. Uma taxa de falha de mudanças crescente avisa-te antes do próximo incidente. Um lead time a aumentar sinaliza um gargalo antes de se tornar uma crise. A velocidade é um indicador atrasado do esforço no melhor caso — uma métrica de vaidade no pior.
Os story points ainda podem ser úteis para o planeamento do sprint dentro de uma equipa. Mas nunca devem ser a métrica que reportas ao leadership, usas para comparar equipas, ou tratas como saúde de engenharia. Para isso existem as métricas DORA.
Para que Resulte
Acompanha as quatro métricas semanalmente. Coloca-as num dashboard visível. Discute tendências nas retros. Define objetivos direcionais: "lead time abaixo de 3 dias este trimestre" é útil. "Aumentar a velocidade em 20%" não é.
Para a investigação mais aprofundada, lê Accelerate de Forsgren, Humble e Kim. É o livro mais baseado em dados sobre a entrega de software que encontrei, e suficientemente curto para um fim de semana.
Na Conectia, quando integramos engenheiros sénior na equipa de um cliente, uma das primeiras coisas que olhamos juntos é como a equipa mede o seu próprio desempenho. Os engenheiros que percebem as métricas DORA não escrevem apenas código — melhoram o sistema que entrega o código. Essa mentalidade é o que separa um programador que ocupa uma cadeira de um que eleva a capacidade da equipa.
Procuras engenheiros que se preocupem com o desempenho de entrega, não apenas com linhas de código? Fala com um CTO — os nossos engenheiros sénior LATAM trazem as práticas e a mentalidade que fazem as tuas métricas DORA moverem-se na direção certa.
