Olá! Há algum tempo nós publicamos o texto sobre o que é DevOps. Nesse artigo apresentamos o conceito, propósito e serventia do DevOps.
Neste Artigo
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
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.
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!
