Accelerate metrics

A maioria dos líderes de engenharia consegue sentir quando o pipeline de entrega está desacelerando, mas não consegue identificar onde. As accelerate metrics oferecem um framework preciso, baseado em pesquisa, para medir a performance de entrega de software em quatro dimensões. Definidas originalmente no livro Accelerate, de Nicole Forsgren, Jez Humble e Gene Kim, essas métricas são a base do que a indústria chama hoje de DORA metrics. Esta página cobre a definição, como medir cada métrica, os benchmarks publicados, um exemplo real e como o DevStats apresenta os dados para você agir.

• Accelerate metrics são um conjunto de quatro indicadores de performance de engenharia derivados de seis anos de pesquisa do time do DORA. Elas importam porque são as únicas métricas de entrega de software empiricamente ligadas à performance organizacional e a resultados de negócio, não apenas à velocidade de engenharia.
• As quatro métricas são deployment frequency (com que frequência você faz deploy em produção), lead time for changes (tempo do commit até a produção), change failure rate (percentual de deployments que causam incidentes) e mean time to restore (velocidade de recuperação). Times de elite fazem deploy várias vezes por dia com lead time abaixo de uma hora, segundo o DORA State of DevOps Report de 2023.
• O erro mais comum dos times é otimizar uma métrica isoladamente. Squads que aumentam a deployment frequency sem investir em infraestrutura de testes costumam ver a change failure rate subir junto, o que anula os ganhos.
• O DevStats rastreia as accelerate metrics automaticamente conectando ao seu provedor Git, ao pipeline de CI/CD e à ferramenta de incidentes, com benchmarks comparados a mais de 1.000 times de engenharia. Comece um teste gratuito e veja seus números em menos de dois minutos.

Definição de accelerate metrics

Accelerate metrics são quatro indicadores de performance de entrega de software usados para medir a velocidade e a confiabilidade com que um time de engenharia leva valor para produção. São elas: deployment frequency, lead time for changes, change failure rate e mean time to restore (MTTR). Os times as usam para comparar a saúde da entrega com dados do setor, em vez de depender apenas da intuição interna.

Cada métrica vem de uma fonte de dados diferente. A deployment frequency vem do seu pipeline de CI/CD ou dos logs de deploy. O lead time for changes mede o tempo decorrido do primeiro commit até o deployment em produção. A change failure rate é o número de deployments que causaram falha dividido pelo total de deployments, expresso como percentual. O MTTR mede o tempo entre a detecção do incidente e a restauração completa do serviço. Juntas, as quatro métricas refletem throughput e estabilidade. A pesquisa do Accelerate mostra que essas duas dimensões não estão em conflito para times de alta performance. Quando o seu squad melhora as quatro ao mesmo tempo, é um sinal confiável de um sistema de entrega saudável, e esse sinal se traduz diretamente em entrega de features mais rápida e menor custo operacional para o negócio. Você pode ver como o DevStats apresenta as quatro métricas pelo seu recurso de DORA metrics, que mapeia cada indicador para as suas fontes de dados conectadas automaticamente.

Por que accelerate metrics importam para times de engenharia

Sem um framework de medição compartilhado, líderes de engenharia recorrem a métricas proxy: story points, linhas de código ou contagem de tickets. Nenhuma delas diz se o seu squad está entregando valor mais rápido ou com mais segurança. Times que ignoram as accelerate metrics costumam descobrir problemas de entrega por meio de compromissos de sprint não cumpridos, aumento de incidentes ou stakeholders frustrados, não por dados proativos.

As accelerate metrics se conectam diretamente aos KPIs pelos quais líderes de engenharia são cobrados. Deployment frequency e lead time for changes determinam a velocidade com que decisões de produto chegam aos usuários. Change failure rate e MTTR determinam quanto da capacidade do seu squad é consumida por trabalho não planejado. Quando esses quatro números estão visíveis, você consegue ter uma conversa baseada em dados com o CTO ou com a liderança de produto sobre onde investir, seja em cobertura de testes, automação de deployment ou processos de plantão. As métricas se alinham ao framework de pesquisa do DORA e complementam a ênfase do SPACE framework em medir sistemas, não indivíduos.

A medição é o ponto de partida. Os dados mostram onde está o atrito. O líder de engenharia decide o que fazer a respeito.

Como medir accelerate metrics

Cada uma das quatro accelerate metrics exige uma fonte de dados diferente. A deployment frequency vem do seu pipeline de CI/CD, scripts de deploy ou ferramenta de gestão de releases. O lead time for changes precisa de timestamps de commits do Git cruzados com timestamps de deployment. A change failure rate precisa de dados de incidentes ou alertas cruzados com eventos de deployment. O MTTR precisa de dados de gestão de incidentes com timestamps de detecção e resolução. A maioria dos squads precisa conectar pelo menos três sistemas para ter uma visão completa: um provedor Git, uma ferramenta de CI/CD e uma plataforma de gestão de incidentes.

Os benchmarks abaixo vêm do DORA State of DevOps Report de 2023. Os benchmarks variam conforme o tamanho do time, a maturidade do codebase e o modelo de release. Use-os como referências direcionais, não como metas fixas. O recurso de benchmarks do DevStats permite comparar seus números com times de tamanho e estágio semelhantes.

Fonte: DORA State of DevOps Report 2023. Os limites de change failure rate e MTTR são faixas aproximadas consistentes com a pesquisa publicada pelo DORA.

Accelerate metrics na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que o squad entregava features dentro do prazo durante os sprints, mas ainda gerava incidentes frequentes reportados por clientes. Ela consultou os dados das accelerate metrics e descobriu que a deployment frequency estava saudável, com várias ocorrências por semana, mas a change failure rate estava em 18%, bem dentro da faixa de baixa performance. O lead time for changes também estava mais longo do que o esperado, em torno de três semanas, o que apontava para um gargalo em algum ponto entre o code review e a produção. Os dados deram a ela uma pergunta específica para investigar, em vez de uma sensação vaga de que algo estava errado.

Ela conduziu uma retro focada no pipeline de deployment e descobriu que o squad não tinha testes de integração automatizados. Os players faziam merge de PRs que passavam nos testes unitários, mas quebravam pontos de integração mais adiante. Ela priorizou dois sprints de trabalho em infraestrutura de testes e atribuiu a responsabilidade pelo pipeline de CI a um player sênior. Seis semanas depois, a change failure rate caiu para 8% e o lead time diminuiu à medida que os players ganharam confiança no pipeline. Os dados de rastreamento de deploy tornaram a comparação antes e depois visível para todo o time.

Como melhorar as accelerate metrics

1. Reduza o tamanho dos lotes para melhorar a deployment frequency e o lead time. PRs grandes são a causa mais comum de lead times longos. Defina um padrão de tamanho de PR para o squad. Algo abaixo de 400 linhas alteradas é um ponto de partida razoável. Acompanhe o PR cycle time como indicador antecedente. Lotes menores passam pelo review mais rápido e falham de forma mais contida.
2. Invista em cobertura de testes automatizados antes de aumentar a cadência de deploy. Aumentar a deployment frequency sem infraestrutura de testes aumenta a change failure rate de forma consistente. Faça uma auditoria no seu pipeline de CI para identificar lacunas de cobertura antes de se comprometer com uma meta maior de deploy. Use a tendência da change failure rate como métrica de controle.
3. Crie um runbook definido de resposta a incidentes para reduzir o MTTR. O MTTR raramente é apenas um problema técnico. A maioria dos atrasos na recuperação vem de responsabilidades pouco claras e etapas manuais de escalada. Documente um runbook passo a passo para os cinco tipos de incidente mais comuns e defina uma rotação. Meça o tempo até o reconhecimento separado do tempo até a resolução para identificar onde o atraso realmente está.
4. Analise os dados de throughput e de deployment juntos. Um squad que entrega um alto volume de trabalho, mas faz deploy com pouca frequência, está acumulando risco em um lote grande de release. Alinhe a cadência do sprint com a cadência de deploy para que o trabalho seja entregue continuamente, em vez de em um único push no final do sprint.
5. Use dados de code review para identificar gargalos no lead time. Filas longas de review são um dos principais fatores de lead times estendidos. Analise os dados de code review para identificar onde os PRs ficam parados e se a carga de review está distribuída de forma desigual no squad.

Accelerate metrics vs. DORA metrics

Accelerate metrics e DORA metrics se referem aos mesmos quatro indicadores. O termo "accelerate metrics" vem do livro Accelerate, enquanto "DORA metrics" se refere ao mesmo framework mantido e publicado pelo time de DevOps Research and Assessment do Google. A distinção importa apenas na conversa: quando alguém fala "DORA metrics", está se referindo ao mesmo framework de deployment frequency, lead time for changes, change failure rate e MTTR.

Use "DORA metrics" ao referenciar benchmarks atuais do relatório anual, e "accelerate metrics" ao citar o framework de pesquisa original ou o livro.