Como medir a produtividade de um time de engenharia de software?
A resposta é simples, DORA Metrics!
Imagine você, como Engenheiro/a DevOps ou Engenheiro/a de Software, como você mediria seu desempenho, do seu time ou da engenharia como um todo? Existe algum framework ou método para isso? A resposta é “sim”, como o SPACE e o DevEx, mas o framework que vou abordar hoje é o DORA Metrics.
Medir a eficácia das práticas de DevOps vai além de apenas implementar CI/CD e afirmar que se está praticando DevOps. As DORA Metrics, desenvolvidas pela DevOps Research and Assessment, são fundamentais para obter uma visão precisa e baseada em dados sobre o desempenho de entrega de software. Elas se concentram em quatro métricas principais que revelam o desempenho real das equipes de engenharia, destacando de forma clara as áreas que precisam de melhorias. Com essas métricas, você consegue ir direto ao ponto, identificando gargalos e oportunidades para otimizar processos e entregar mais valor.
Além disso, as DORA Metrics podem ser alinhadas com os objetivos estratégicos da empresa, garantindo que as práticas de DevOps estejam em sintonia com as metas de negócio. Por exemplo, ao melhorar a Frequência de Deploys e reduzir o tempo médio de recuperação de um incidente, a empresa pode acelerar o tempo de lançamento de novos produtos no mercado e consequentemente aumentando sua competitividade e satisfação do cliente.
As quatro métricas
Entendido o que são as DORA Metrics, vamos passar por cada uma delas e dar mais contexto:
Deployment Frequency
Deployment Frequency mede quantas vezes novas versões de código sobem para produção em um determinado período. É um indicador que mede a agilidade da equipe de desenvolvimento e da capacidade de entregar valor continuamente aos usuários e ao negócio. Ou seja, uma alta frequência de deploy corresponde a equipes que respondem rapidamente a feedbacks (feedback loops) e mudanças nas regras de negócios.
Para medir, basta calcular o número de deploys realizados em um período específico, como por dia ou semana. Um processo importante, que minimiza dependências e “burocracias” no processo de deploy e que já é bem difundido é o CI/CD. Vale ressaltar que CI/CD não é ter um Jenkins ou GitHub Actions rodando, CI/CD é de fato o processo contínuo e sem intervenções manuais para rodar uma suíte de testes, processo de build e deploy.
Lead Time for Changes
Mede o tempo que leva desde o commit inicial até o deploy para produção. Essa métrica reflete a eficiência das pipelines, fluxos de desenvolvimento e a capacidade e velocidade de entregar valor.
Diferente do deployment frequency, a ideia é ter essa métrica com indicadores baixos, ou seja, subir pequenas alterações para produção e com mais frequência. A utilização de metodologias ágeis, também ajuda muito no processo.
Mean Time to Recovery ou MTTR
O MTTR mede o tempo médio que um time leva para recuperar um sistema após uma falha em produção. É um indicador da resiliência e estabilidade do sistema. Adotar práticas SRE, como a criação de playbooks para incidentes, observabilidade, e chaos engineering, pode melhorar significativamente o MTTR.
Ter um bom processo de gerenciamento de incidentes, com revisão de post-mortems e ferramentas que alertem a qualquer comportamento anômalo e que possam indicar uma possível falha, ajudam na identificação de melhorias e recuperação/correção mais rápida.
Change Failure Rate
Mede a porcentagem de deploys que resultam em falhas em produção. É um indicador importante para avaliar a qualidade do processo de desenvolvimento e a estabilidade do sistema.
Implementar suíte de testes automatizados, realizar revisões de código de forma mais regular e utilizar pipelines de CI/CD para validação contínua são métodos eficazes para reduzir a taxa de falhas.
Como implementar
A maior parte das ferramentas de CI/CD e observabilidade atualmente conseguem demonstrar os indicadores das quatro métricas. Por exemplo, a Datadog possui em beta uma funcionalidade para extração e análise, a Harness tem algo um pouco mais sólido, porém mais simples. Já o GitLab oferece uma análise bem mais completa, porém apenas no plano Ultimate.
Porém, ambas soluções são pagas e isso vai muito da ferramenta que você utiliza, por isso, recomendo uma ferramenta que tenho estudado há algumas semanas, o Apache DevLake. Nela, é possível plugar várias soluções de mercado e centralizar a extração e visualização de métricas em um só lugar. Outro ponto bem positivo, é que caso na sua empresa seja utilizado alguma ferramenta desenvolvida internamente, o DevLake aceita Webhooks.
Além das quatro métricas, o DevLake consolida várias outras adicionais, como tamanho das Pull Requests, duração dos builds, linhas adicionadas ou deletadas em um commit e por aí vai.
Obviamente, que conseguir integrar a medição das métricas no dia a dia, requer práticas e processos bem definidos. Uma dica é incorporar revisar essas métricas durante as dailies ou em retrospectivas. Criar uma dashboard para que todo time possa acompanhar as métricas pode aumentar a transparência e incentivar a responsabilidade compartilhada.
Estabilidade e Velocidade
Todo mundo quer uma baixa taxa de erros e que sistemas sejam restaurados rapidamente em caso de falha, é uma verdade que todo mundo também quer colocar features de forma mais rápida em produção. E inicialmente, parece que há uma divergência entre elas, certo? Se o time colocar mais features em produção sem bons testes ou controle de qualidade, a taxa de erros pode aumentar.
Algo muito importante, é que observabilidade vai muito de encontro com o tema. Quando há um incidente em produção, é possível entender de forma mais rápida, o problema olhando para qual foi a mudança. Com um lead time mais curto, a compreensão da mudança é mais fácil e consequentemente, sabemos qual é o problema. Ou seja, entender a causa raíz reduz o MTTR, que também reduz a taxa de falhas em mudanças (Change Failure Rate).
O contexto e os recursos são importantes nesses momentos. Porém, essas quatro métricas se influenciam mutuamente e muitas vezes ajudam dar insights que seriam mais difíceis de compreender de outra forma. Analisar essa “dualidade” entre velocidade e estabilidade é uma abordagem eficaz para avaliar o desempenho das práticas DevOps.
Vou deixar alguns livros que recomendo demais para quem quer se aventurar mais na melhoria de fluxo de entrega de software e DevOps.
Boa leitura e até a próxima.