Devido às mudanças provocadas pela transformação digital, atualmente, empresas de todos os segmentos usam softwares e programas em Cloud para atender seus clientes digitalmente, gerenciar processos e atividades. Porém, ainda são poucas as que sabem como medir e aprimorar a maturidade da equipe DevOps e dos softwares, e é aí que entram as DORA Metrics!
Usando dados objetivos, as DORA Metrics propõem o acompanhamento de quatro métricas que indicam como anda o desempenho da equipe DevOps e dos softwares desenvolvidos por uma empresa. Com isso, os gestores têm melhores informações para embasar decisões sobre mudanças na organização e processos da equipe.
Neste artigo, você pode entender em apenas alguns minutos o que são DORA Metrics, quais os benefícios em acompanhar essas métricas e os desafios na sua adoção. Aproveite a leitura!
O que são DORA metrics?
Primeiramente, é preciso explicar que DORA é a sigla para “DevOps Research and Assessment”, ou, em tradução livre, “Pesquisa e Avaliação de DevOps”. Os dados base dessa análise são coletados desde 2014, em uma pesquisa chamada State of DevOps.
Se você não está familiarizado com o conceito de equipes DevOps, basta entender que se trata da integração da equipe de colaboradores responsáveis, em uma empresa, pelo desenvolvimento de operações e processos que envolvem softwares.
Logo, DORA Metrics, basicamente, são métricas utilizadas para pesquisar e avaliar o desempenho das equipes DevOps, permitindo identificar pontos passíveis de melhorias ou a necessidade de mudanças mais profundas.
No estudo de oito anos que deu origem às DORA Metrics, os pesquisadores chegaram a quatro métricas consideradas ideais para acompanhar e medir o desempenho das equipes DevOps e dos softwares utilizados. Confira a seguir quais são!
- Deployment Frequency (“Frequência de Implantação”);
- Lead Time for Changes (“Tempo para Implantações”), também denominada “Delivery Lead-Time”;
- Change Failure Rate (“Taxa de Falhas em Implantações”);
- Time to Restore Service ( “Tempo para Restauração de Serviço”), também denominada Mean-Time-to-Restore ou Mean-time-to-Recover.
Deployment Frequency
A métrica Deployment Frequency mede a frequência que a equipe atualiza seus softwares em Produção, disponibilizando melhorias ou correções nas aplicações usadas pela empresa ou por seus clientes.
Normalmente, essa métrica é acompanhada dia a dia e, em geral, quanto mais ações de deployment são realizadas, melhor o time está trabalhando.
Porém, em empresas de pequeno e médio porte, não é todos os dias que a equipe realiza ações que causam mudanças nas aplicações utilizadas. Nesses casos, a Deployment Frequency pode ser medida por semana, mês ou semestre, conforme o fluxo de trabalho de cada time.
Uma ocorrência de deployment por semana ou por mês é o valor referência para empresas de médio porte. Empresas de alta performance, contudo, registram uma média de sete ocorrências por dia.
Assim, em geral, aplicações mais simples, que lançam novas versões de atualização para download dos usuários, entregam uma ou duas novas aplicações por trimestre, enquanto soluções complexas de softwares como serviço podem entregar diversas novas aplicações por dia.
Portanto, os valores de referência para interpretar e avaliar essa métrica de forma precisa dependem também do nível de complexidade dos produtos digitais modificados, da efetividade das mudanças propostas ou da frequência de registro de falhas que deverão ser corrigidas.
A quantidade de ocorrências pode ser aprimorada por medidas como automatização e investimento em um sistema de entregas integradas e contínuas, além da criação de um processo automatizado de passagem da fase de testes para a fase de lançamento das implantações.
Lead Time for Changes
No caso da Lead Time for Changes, o objetivo é acompanhar o tempo necessário para que a equipe DevOps desenvolva melhorias ou correções nas suas aplicações.
Ou seja, trata-se de uma métrica que mede a velocidade de desenvolvimento dos códigos e softwares, ajudando a compreender melhor o ciclo de vida das soluções criadas pela equipe. Naturalmente, o ideal é que as adaptações sejam realizadas o mais rápido possível.
Para calcular essa métrica, é necessário saber em qual momento a demanda de adaptação foi identificada e o tempo investido para executá-la.
Em empresas de alta performance, o valor de referência para essa métrica é de um dia ou menos. Já empresas de média performance, o tempo médio é de uma semana a um mês.
Entre as soluções para reduzir o tempo de resposta para corrigir problemas e falhas nas aplicações estão o trabalho em mais automatizações nas implantações, a divisão delas em produtos mais compactos para gerenciá-los separadamente e a criação de um processo de revisão contínua dos códigos das aplicações.
Change Failure Rate
A Change Failure Rate, como o próprio sugere, aponta qual é a taxa de falhas nas adaptações e mudanças propostas pela equipe DevOps. Logo, é um excelente indicador de qualidade e estabilidade das soluções desenvolvidas.
Basicamente, a taxa é obtida dividindo o número de falhas e problemas apresentados pelo número total de mudanças e implantações realizadas, ajudando a balancear a métrica Deployment Frequency. Queremos fazer implantações com a maior frequência possível, porém não a qualquer custo.
Uma ótima métrica de Deployment Frequency só deve ser comemorada caso a métrica de Change Failure Rate esteja baixa.
Das DORA metrics, a Change Failure Rate é a que oferece valores de referência mais objetivos, pois sua interpretação depende menos da análise de outras métricas.
Para empresas de média e alta performance, o valor referência para taxa de falhas nas mudanças é de 0 a 15%. Já para empresas de pequeno porte, o valor é de 46% a 60%.
Entre as ações para manter dentro dos valores de referência, a mais indicada é garantir que todo novo código ou aplicação passe por testes antes do seu lançamento. Também é essencial criar um processo de revisão contínua dos códigos.
Time to Restore Service
Por fim, Time to Restore Service é uma métrica bastante direta, que indica a média de tempo necessário para que a equipe restaure falhas e problemas que tiram os sistemas e aplicações do ar.
Em empresas que atendem seus clientes digitalmente, essa é uma métrica especialmente crítica, pois quanto mais tempo leva para solucionar problemas que tiram os sistemas do ar, mais insatisfeitos ficam os clientes e mais dúvidas eles terão para expandir o relacionamento com sua empresa.
A métrica é facilmente obtida, calculando a soma de tempo entre a indicação dos problemas e as resoluções, depois dividindo o resultado pela quantidade de problemas relatados.
Normalmente, empresas que oferecem produtos digitais e softwares como serviço mantêm operações extremamente bem preparadas para lidar com as falhas, fazendo com que o valor de referência para o Time to Restore Service, mesmo em empresas de médio porte, seja entre uma e 24 horas.
Contudo, as empresas de pequeno porte, em início de desenvolvimento, têm particular dificuldade em manter essa métrica em níveis baixos. Para elas, o valor de referência fica entre uma semana e um mês.
Para reduzir ao máximo o tempo necessário para recuperação do sistema e correção das falhas, a empresa deve investir em medidas como construção de um sistema de entregas integradas e contínuas, que rapidamente possam detectar e imediatamente trabalhar nas correções.
Outras medidas incluem treinar e manter equipes on call para lidar com as falhas e aprimorar o Deployment Frequency.
Leia também – Team Topologies: aumente a eficiência do time de DevOps
Benefícios de acompanhar as DORA Metrics
Embora as empresas digitais tenham ganhado muito espaço no mercado nos últimos anos, ainda são tímidos os esforços para medir o desempenho das iniciativas digitais.
Contudo, quando monitoram as DORA Metrics, os gestores têm à disposição dados e informações para compreender como é de fato o desempenho da equipe de DevOps, além de pontos fortes e fracos.
Disso, resultam alguns benefícios diretos, como:
Decisões tomadas com base em dados concretos
As informações ajudam a identificar tendências e a decidir como e onde interferir para obter um melhor desempenho.
Maior valor na entrega de produtos e serviços
Ao acompanhar as métricas sugeridas, a equipe consegue perceber de forma imediata como aumentar a qualidade do trabalho e agregar mais valor aos produtos e serviços oferecidos aos clientes.
Criação de um círculo virtuoso de desenvolvimento e aprimoramento
O acompanhamento seguido de intervenções pontuais, que visam a melhoria do trabalho, cria um círculo de aprendizado e aprimoramento constantes.
Desafios na adoção das métricas
O acompanhamento das DORA Metrics é essencial para aprimorar o trabalho da equipe de DevOps, mas existem alguns desafios que podem dificultar a sua adoção.
Então, ao considerar adotar essas métricas, é importante se atentar aos seguintes fatores:
Informações dispersas
Muitas empresas, especialmente as de grande porte, têm diversas fontes de dados, o que pode dificultar o levantamento de todas as informações pertinentes para o cálculo das métricas.
Extração e processamento de dados
Também é muito comum que os dados não estejam preparados para o processamento automatizado de um software, sendo necessário um processo de preparação prévia para análise.
Análise das informações
Contextos são sempre relevantes para interpretar métricas e dados, por isso, tenha sempre em mente qual é a realidade do segmento em que seu negócio está inserido e o porte da empresa no momento.
Acompanhar as DORA Metrics é uma das formas de garantir que a equipe de DevOps trabalhe para aprimorar as soluções oferecidas, porém, essa análise deve vir acompanhada de um conjunto de ações. Por isso, sugerimos que você se informe sobre o papel das equipes DevOps na transformação digital no nosso conteúdo exclusivo sobre o assunto: “Agile e DevOps: impulsionando a inovação e a transformação digital?”.
Clique aqui para ver todos os vídeos da nossa série sobre DORA Metrics em nosso canal no YouTube!
Conheça nossa plataforma que viabiliza a medição das DORA Metrics de forma automática.
