Métricas DORA: 4 indicadores que medem o sucesso do seu DevOps

Olá! Há algum tempo nós publicamos o texto sobre o que é DevOps. Nesse artigo apresentamos o conceito, propósito e serventia do DevOps. 

O que é DORA?

Agora, temos que torná-lo prático. Um programa que se dedica a isso é o DevOps Research and Assessment (DORA). Em português, Pesquisa e Avaliação em DevOps. É o maior e mais antigo programa de pesquisa nessa área. Ele busca compreender o que impulsiona a entrega de software e o desempenho das operações. Fazendo uma comparação um tanto grosseira, o Kanban possui a Kanban University, o Scrum a Scrum Alliance, Gerência de Projetos o PMI, DevOps tem o DORA.

DORA Core Model

O modelo do Dora é formado por algumas camadas. A primeira são as capacidades: Infraestrutura Flexível e Qualidade da Documentação. Abaixo delas as capacidades técnicas: Manutenibilidade do código, Integração Contínua, Gestão de Mudança de Banco de Dados, Automação da Entrega, Empoderamento dos times para escolher ferramentas, Baixo Acoplamento da Arquitetura, Acompanhamento e Monitoramento, Automação de Testes, Gerenciamento de Dados de Testes, Desenvolvimento baseado no Trunk (ramo principal), Controle de Versão. Essas capacidades predizem outras capacidades. Elas são a Shifting left on security (integração da segurança com o desenvolvimento), Entrega contínua, Cultura Organizacional Generativa e Aprovação Simplificada de Mudança. Elas são medidas pela performance que são as métricas DORA Lead Time para mudanças, Frequência de Entrega, Taxa de falha em mudança, Tempo de Restauração do Serviço. Essas métricas medem os resultados que são: Performance organizacional comercial ou não comercial e bem estar que é subdividida em três subáreas: reduzir a “dor” da entrega, menos retrabalho, menos burnout
DORA Core Model v1.2.2

A DORA criou o modelo Core (Nuclear, Essencial, Cerne, Central). Ele é o resultado da pesquisa do DORA que criou uma coleção de capacidades, métricas e resultados que representam as descobertas mais bem estabelecidas. Ele tem como objetivo servir como um guia em contextos profissionais. 

As Métricas DORA

Dentro do modelo Core, há uma parte específica para métricas. Elas são fundamentais para estabelecermos o estado de adoção da cultura DevOps na organização. Elas são um conjunto de métricas que servem para avaliar o desempenho e a maturidade do processo de entrega, operação e manutenção de software. Elas medem a frequência de implantações, o tempo de entrega das mudanças, a taxa de falha das mudanças e o tempo de restauração do serviço caso haja algum problema. 

As métricas são: Lead Time para mudanças, Frequência de Entrega, Taxa de falha em mudança, Tempo de Restauração do Serviço. As detalho na sequência.

Lead Time para mudanças (Lead time for changes)

Como já vimos em outros artigos, o Lead Time é o tempo de espera de um consumidor para a entrega de um serviço. No caso, o serviço medido aqui é a entrega do software. Aqui utilizo o conceito de lead time que o DORA publicou no seu Relatório State of Devops 2022, página 10. 

tempo da confirmação do código até o lançamento na produção”.

DORA, State of Devops 2022, p.10.

Em outras palavras, após os desenvolvedores terminarem de programar uma funcionalidade, adicionam o novo código-fonte no repositório principal, no informatiquês: “commitam o código na main (branch)”, o tempo começa a correr e termina quando o produto está disponível para o uso do cliente. Não confunda esse conceito com o Customer Lead Time que vai desde o surgimento da ideia até a entrega. O Lead Time para mudanças está contido no Customer Lead Time.

É uma métrica interessante, pois pode ser toda ela medida de forma automatizada. Isso, é claro, dependerá do nível de automação de entrega. O básico com um servidor de integração / entrega contínua como Jenkins já pode te ajudar. As empresas que prestam serviço de computação na nuvem (cloud) também costumam oferecer esse serviço.

Etapas da entrega de produtos o Básico do DevOps para automação.
Etapas básicas para entrega automatizada de produtos

Claro, quanto menos automatizada for essa entrega, maior será o seu Lead Time de entrega. Caso tenha dependências externas (outras unidades de negócio) e processos como GMud (Gestão de Mudanças) que necessitam de várias autorizações, esse lead time será ainda maior. Se tiver que esperar um trem que só sai uma vez a cada trimestre aí seu tempo será gigantesco 😈

Frequência de entrega (Deployment frequency)

Mede quantas entregas (deploy em produção) são feitas em um intervalo de tempo. A ideia é a seguinte. Imagine dois times. O Time Alfa realiza 1 entrega por mês. Já o Time Ômega realiza 30 entregas por mês. O Time Ômega tem algumas vantagens frente ao Alfa. Eles fazem mais entregas do que o Alfa. Provavelmente são lotes menores e com isso qualquer problema que eles tenham é mais fácil de ser resolvido. Eles experimentam mais e se adaptam mais às necessidades do negócio.

Taxa de falha em mudança (Change failure rate)

A porcentagem de alterações na produção ou liberadas para os clientes que resulta em degradação do serviço (bugs, erros ou interrupção do serviço) e requer correção (hotfix, reversão para o estado anterior, correção futura, patch). É uma equação 

iFalha =entregas que degradam o serviço ÷ entregas 100

Tempo de Restauração do Serviço (Time to restore service)

Uma vez que um erro tenha sido detectado ou reportado, quanto tempo leva para que ele seja consertado. O interessante que esse é o Customer Lead Time para o tipo de demanda erros e incidentes, pois é o tempo em que o cliente fica esperando a correção do problema ou restabelecimento do serviço.

Conclusão

As métricas do DORA são simples e se você as tem, pode inclusive fazer uma avaliação no site do programa: Avaliação (em inglês). O objetivo de você ter bons números estão descritos nos resultados do DORA Core: Performance Organizacional, reduzir a “dor” da entrega, menos retrabalho, menos burnout.

Espero que tenha curtido. Não deixe de fazer os nossos treinamentos de Kanban para saber como reduzir esses tempos do ciclo de construção.

Nos vemos em breve!

Sobre o autor(a)

Trainer na K21

Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21

Artigos relacionados

O Guia do Scrum fala sobre o refinamento do Product Backlog: “O Product Backlog é refinado conforme necessário” (p. 9). Todavia ele não descreve exatamente o que é o refinamento. Uma reunião, uma atividade, um processo. Neste artigo vamos jogar…

Marcos Garrido, Sócio-fundador e Trainer na K21

Existem muitas formas de organizar as métricas de seu produto / empresa. Aqui neste blog já escrevemos sobre as Métricas do Pirata, Fit For Purpose (F4P) e Métricas nas Quatro Áreas de Domínio da Agilidade. Todavia, agora, queremos falar sobre…

Após alguns anos desenvolvendo produtos e ajudando outras empresas a fazer tal, gostaria de listar com vocês alguns erros comuns que percebi ao longo dessa jornada. Olhando para as 4 Áreas de Domínio da Agilidade (Negócio, Cultural, Organizacional e Técnica)…

Uma das principais habilidades que desenvolvemos enquanto consultores é a de fazer boas perguntas. Uma vez que as pessoas percebem o poder que tem uma boa pergunta, colocada ali na hora certa e que muda o destino de uma reunião,…