As métricas que realmente importam

Desde que comecei a trabalhar com ALM e DevOps, uma das primeiras solicitações que escuto de nossos clientes é “como faço para ter um dashboard com meus indicadores?”

E quando pergunto o que querem medir, a resposta normalmente é “Sei lá. O que você sugere?”

Dá para imaginar que isso nunca acaba bem, né?

É curioso que, de alguma forma, muitas pessoas imaginam que a mera presença de um dashboard baste para se medir a produtividade de um time. Infelizmente, as discussões que realmente importam - como “o que significa produtividade para nós?” já não são tão comuns.

O que medir?

Se por um lado “quem não mede não gerencia”, por outro a pergunta realmente importante é “o que vale a pena medir?”

Como é de se esperar, a resposta não é tão simples. Quando olhamos para o trabalho feito por um time de desenvolvimento, quais são os indicadores de que as coisas estão (ou não) indo bem? Dica: quantidade de linhas de código e bugs por desenvolvedor certamente não estão na lista de boas métricas ;-)

Quando o assunto DevOps começou a se disseminar mais, uma pergunta que começou a ficar mais frequente foi “como DevOps tem ajudado as empresas?” Para responder isso, era preciso analisar o mercado e criar mecanismos que permitissem distinguir as práticas que faziam os bons praticantes de DevOps se diferenciarem das demais empresas.

O principal estudo de mercado sobre DevOps é o State of DevOps, originalmente conduzido pela equipe da DORA (DevOps Research and Assessment) e atualmente sob a tutela do Google.

Com a experiência obtida nas primeiras pesquisas, o pessoal por trás daquilo que viria a ser a DORA lançou um livro chamado “Accelerate - The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations”. Esse livro contém o resultado dos estudos feitos a partir das comparações entre empresas que adotavam DevOps em seus mais diversos níveis, e como essas diferenças influenciavam no resultado dos times de desenvolvimento.

Uma das principais contribuições desse livro é a identificação das Quatro Métricas-Chave (“Four Key Metrics”) - aquilo que realmente deveria ser medido e acompanhado para guiar a melhoria contínua de times praticantes de DevOps.

As Quatro Métricas-Chave

Segundo o livro Accelerate, as “quatro métricas-chave” eram as que realmente diferenciavam empresas de alto, médio e baixo desempenhos no tocante à utilização de DevOps e seus benefícios diretos sobre os times de desenvolvimento. As métricas são:

Lead time

Quanto tempo uma dada demanda leva para ser concluída, desde o momento em que ela foi introduzida no backlog?

Quanto mais tempo leva para ser devidamente implementada, testada e integrada ao sistema em produção, maior a chance de ela sofrer mudanças, apresentar desvios ou mesmo de se tornar completamente obsoleta.

Times de alto desempenho conseguem medir seu lead time em horas, ao passos que times menos maduros normalmente têm lead times de dias ou até mesmo semanas.

Deployment frequency

Com que frequência seu time faz implantações de seus sistemas e aplicações?

A incapacidade de fazer implantações frequentes normalmente denota a ausência de processos automatizados, o que induz a um aumento de erro humano. Por outro lado, o o aumento na frequência só é possível com um alto grau de maturidade nos processos de automação de build, release, teste e monitoramento.

Uma maior frequência indica equipes com processos sólidos de automação e controle de qualidade, que dão a segurança necessária para se implantar um sistemas várias vezes por dia.

Mean time to restore (MTTR)

Qual o tempo médio para que você consiga identificar (e corrigir) um problema em produção?

Times de alto desempenho têm processos e ferramentas para orientar as pessoas quanto ao que fazer numa situação de crise, bem como mecanismos de coleta de dados de telemetria que permitem a análise profunda do problema. Mecanismos de implantação automatizados garantem que as correções são publicadas de maneira rápida e consistente.

Times menos maduros levam muito tempo “batendo cabeça” até que consigam se recuperar de um problema mais sério.

Change fail percentage

Qual a porcentagem do total de alterações em seus sistemas que causa algum tipo de problema?

Com certeza você já viu este filme. Ao fazer uma pequena alteração numa parte do sistema, uma outra misteriosamente pára de funcionar.

Déjà-vu? :-)

Como em “Efeito Borboleta”, a menor mudança ou a refatoração mais inocente parecem, por vezes, causar um enorme caos no sistema. A ausência de testes de unidade, processos falhos e lentos de coleta de feedback e mecanismos arcaicos de implantação podem levar a isso.

Não é por acaso que muitas empresas tenham tanto medo das “subidas para a produção”. Seu histórico diz que a chance de algo ter sido quebrado de maneira inconsciente é muito grande.

Conclusão

Você tem um montão de métricas à sua disposição para medir e acompanhar a evolução de seus times de desenvolvimento. Não acredita? Então dá uma olhada nisto:

Entretanto, se você está começando agora, lembre-se que no fim do dia o que realmente distingue os times de alto desempenho daqueles que não estão tão bem são as quatro métricas-chave.

Que tal começar apenas com elas e, à medida que seus times forem melhorando nesses indicadores, você começa a medir (e melhorar) outros aspectos?

E você, coleta alguma métrica de sua(s) equipes? O que acha dessas quatro métricas? Comente com a gente!

Um abraço,
Igor

29/11/2019 | Por Igor Abade V. Leite | Em Técnico | Tempo de leitura: 5 mins.

As métricas que realmente importam

O que medir?