Como Usamos Métricas para Potencializar a Eficiência do Time de Engenharia de Software da Loft

Artigo escrito em co-autoria com Romulo Tavares

Como a Loft usa algumas métricas simples para ajudar a aumentar a eficiência dos times de desenvolvimento de software.

Se você é uma pessoa desenvolvedora ou uma pessoa gestora de um time de desenvolvimento já deve ter se deparado com algumas perguntas como as abaixo:

"Temos algum gargalo para entregar um produto em produção?"

"Estamos conseguindo entregar histórias mais rápido do que o sprint anterior?"

"O número de bugs aumentou ou é impressão minha?"

Muitas vezes, quando essas perguntas surgem, o problema já está evidente ou aconteceu alguma mudança muito brusca de uma semana para outra. Mas a verdade é que o tempo para entregar uma história vai crescendo aos poucos sem percebermos, é um build que passou a levar alguns minutos a mais, é uma aprovação de pull request que levou algumas horas, e no fim uma história que parecia que ia levar 2 dias para completar passa a levar 3, e quando a gente menos percebe, levou o sprint inteiro.

Você pode pensar que a culpa é do time que não está sendo disciplinado durante o sprint. Isso até pode ser verdade em alguns casos, mas a maioria dos times que conheci ou trabalhei tinham problemas por conta do excesso de informações e contextos. É difícil manter a disciplina em tantas coisas ao mesmo tempo: priorização, prazos, experiência da pessoa usuária, performance, qualidade de código, arquitetura do sistema…

"E qual a solução afinal? Como podemos resolver isso?" devem ser algumas das perguntas que você está se fazendo. Aqui na Loft, resolvemos colhendo algumas métricas de forma automatizada para ajudar a monitorar a eficiência do time de desenvolvimento. Somos alertados sempre que alguma dessas métricas foge um pouco da curva de tendência, de forma que podemos fazer um checkup para entender o que está acontecendo antes do problema virar uma grande bola de neve (e termos de novo aquela história de 2 dias levar 5 para ser concluída).

Essas métricas que usamos são muito baseadas no excelente livro Accelerate — The Science of Devops e nos relatórios State of Devops que são publicados anualmente (o último, de 2021, acabou de sair do forno e pode ser encontrado aqui). Vem com a gente que vamos passar um pouco por cada uma delas!

Lead time for changes

É o cálculo do tempo que levou entre o primeiro commit e o deploy para produção. É uma métrica bastante abrangente pois ela pega todo o processo de codificação, testes, code review e deploy. Ela pode ser calculada em dias, horas ou minutos, e o objetivo aqui é saber se estamos levando mais ou menos tempo que a nossa média.

Ela pode ser calculada automaticamente, se você estiver usando git e um CI/CD. Aqui na Loft todos os times de desenvolvimento ganham essa métrica por default em cada projeto, temos uma ferramenta que faz essa conta sempre que fazemos merge de um Pull Request na main, vendo quanto tempo havia passado desde o primeiro commit nesse PR.

Podem existir diversas situações onde essa métrica pode sofrer deterioração, como por exemplo o time precisar mexer em outro projeto que não é do contexto habitual, ou participar de uma série de reuniões de alinhamento e planejamento. Aqui nós encaramos essa métrica como um batimento cardíaco, se acelera porque estamos fazendo algum exercício tudo bem, mas se acelera ou despenca sem estarmos fazendo nada diferente pode ser preocupante.

A ideia é que esse número seja bem baixo, ficando abaixo de 1 hora. O motivo por trás disso é que diminuindo esse número, aumentamos o senso de urgência no time e trazemos mais previsibilidade para o nosso Cycle Time, enquanto trazemos uma maior facilidade para entregas mais frequentes e com menor batch size, o que nos ajuda a diminuir os riscos nessas entregas.

Deploy Frequency

É a frequência com que efetuamos deploys, geralmente medida em deploys por dia (mas podemos com esse número extrapolar a métrica para deploys por semana ou mês também).

Também pode ser calculada automaticamente com o uso de alguma ferramenta de CI/CD. Todos os times de desenvolvimento aqui na Loft também já tem o cálculo dessa métrica por default nas nossas actions de deploy, isso também nos ajuda muito a entender como o time está efetuando suas entregas.

Idealmente, esse número deve ser alto, mais que 2 deploys diários. Números mais baixos nessa métrica podem ser sintomas de alguns problemas, como histórias de usuário muito grandes ou times sobrecarregados, demorando para revisar Pull Requests. Assim como a métrica anterior, o número por si só aqui não quer dizer muita coisa, é necessário analisar esse número no contexto do time (se estamos fazendo inner sourcing em outros codebases ou se estamos em uma sprint mais focada em discovery ou enablers, esse número tende a cair naturalmente).

O motivo que nos leva a buscar um número alto nessa métrica é muito similar ao da Lead Time for Changes, fazendo mais deploys em um período de tempo, tendemos a ter um cycle time e batch size menores, o que por conseguinte nos traz mais previsibilidade sobre entregas, feedbacks e senso de urgência para o time. Além disso, no caso da ocorrência de algum problema, como tivemos um pacote menor sendo entregue, acaba sendo mais fácil e rápido o processo de investigação e correção.

Change Failure Rate e Mean Time to Recover

Com essas duas últimas métricas, a mensagem que gostaríamos de passar é Commit to Production! Pode ser que isso gere pequenos problemas ou bugs nos nossos serviços, mas está tudo bem! Esses pequenos bugs são o que nos vão trazer insumos para que sigamos no nosso processo de melhoria contínua, podemos nos dar ao luxo de errar e aprender com os nossos erros. Para essas duas métricas, é de suma importância o uso de uma ferramenta para monitorar a performance de aplicações (ou APM). Aqui na Loft, usamos o Datadog para isso.

Porém, temos duas métricas que nos auxiliam a mensurar quão bem estamos fazendo esse processo. O Change Failure Rate é a porcentagem de deploys que geraram algum alerta em nossa ferramenta de APM. Embora nós possamos cometer esses pequenos erros eventualmente, não seria saudável se todos os deploys feitos gerassem problemas nos quais alguém precise atuar. Usamos essa métrica nesse sentido, para ver quão bem estamos validando nossos experimentos e hipóteses antes de lançá-los em produção. Idealmente, esse número deveria estar abaixo dos 5%.

Além dessa métrica, temos também a métrica de Mean Time to Recover, que é o tempo médio que demoramos para resolver algum problema em nossas aplicações. O que essa métrica traz para nós é o tempo médio entre um alerta ser lançado na nossa ferramenta de APM e a resolução dele. Esse tempo também deveria ser baixo, abaixo de 1 hora, porém isso não é uma regra escrita em pedra, não é esperado que nenhuma pessoa fique monitorando esses alertas 24/7, caso uma aplicação tenha um alerta em um domingo (ou qualquer outro momento fora do horário comercial) e não tenhamos um time trabalhando de sobreaviso (spoiler: não temos isso para quase nenhum time aqui na Loft), não é esperado de nenhuma pessoa que se conecte para resolver esse problema.

Embora esse tempo deva ficar abaixo de 1 hora, números muito baixos também podem ser sintomas de problemas. Se um time em média demora 3 minutos para resolver seus alertas, temos um forte indício de que os alertas são resolvidos por conta própria, sem que alguém precise intervir, o que pode ser causado por uma falha na configuração dos níveis do alerta. Um dos pontos que seguimos aqui é que alerta não deve ser ruído, então só deveríamos ter alertas para situações nas quais é necessário que alguém atue, essa métrica nos auxilia nesse ponto também!

O que fazer com essas métricas?

Aqui na Loft trabalhamos muito com o princípio de autonomia nos nossos squads de tecnologia. Isso significa dizer que não temos nenhuma pessoa (ou grupo de pessoas) monitorando esses números e cobrando cada squad que tenha algum número fora do que seria esperado. A única monitoria que temos nesses números diz respeito ao consolidado de toda a área de tecnologia, o que é esperado dos times é que olhem para esses números e encontrem cada um o melhor caminho para ter essa cultura de melhoria contínua.

Temos alguns squads aqui que possuem uma dependência de aprovações da área de operação para subir novas funcionalidades em aplicações. Nesse caso, é virtualmente impossível ter o Lead Time for Changes abaixo de 1 hora e tudo bem, podemos conviver com isso! Da mesma forma, temos um squad aqui que possui um Job, uma aplicação que roda de tempos em tempos para efetuar uma série de ações. Esse Job tem uma dependência muito forte com uma aplicação externa, não desenvolvida por nós, que é bem instável, o que causa uma grande quantidade de falhas nele. Como ele demora 2–3 horas em cada execução, é impossível termos para ele o Mean Time to Recover abaixo de 1 hora, uma vez que o alerta só seria normalizado após o término da próxima execução com sucesso.

Conclusão

Essas métricas todas nos ajudam a medir quão bem nós estamos desenvolvendo e entregando nosso software. A nossa ideia com isso não é de forma alguma trazer dificuldades ou empecilhos para os times envolvidos, muito pelo contrário, é apenas ajudá-los a entender possíveis pontos de melhoria, buscando ter um processo cada vez mais ágil e eficiente. As únicas pessoas que deveriam tomar conclusões com base nessas métricas são as pessoas envolvidas de fato no dia a dia do time que as está produzindo!

Se você gostou das ideias propostas aqui, chega mais em https://jobs.lever.co/loft, lá tem um montão de detalhes sobre as váááárias vagas que a gente tem abertas! Vem fazer parte desse processo com a gente! Comentários e feedbacks são, como sempre, muito bem vindos!

Créditos de todas as imagens: https://www.shutterstock.com/