[tweet]O problema de estabelecer indicadores ruins é que eles, invariavelmente, vão conduzir as ações do time, causando efeitos colaterais indesejados.[/tweet] Sabendo disso, como identificar se a performance de um time desenvolvendo software está boa ou não?

A recomendação vigente, em conformidade com as práticas de mercado, é que a análise da performance seja feita considerando quatro indicadores:

1. Delivery lead time
2. frequência de deploy;
3. tempo médio de recuperação em falhas (MTTR);
4. Change fail percentage;

Empresas bem sucedidas desenvolvendo software tem ótimos desempenhos em todos estes indicadores. Um estudo aprofundado sobre isso é apresentado em um excelente livro que recomendamos outro dia.

#1 – Delivery lead time

Lead time é o tempo consumido desde o momento em que um cliente solicita uma mudança no software até o instante em que essa solicitação é plenamente atendida. Trata-se de uma métrica importante para demonstrar a performance organizacional e a excelência global dos processos, entretanto, frequentemente é impactada por setores externos às de engenharia.

Para analisar a performance dos times de engenharia, especificamente, é recomendável decompor o lead time em duas métricas relacionadas:

1. Design and validation lead time, que começa no momento em que a demanda do cliente é identificada e encerra quando há consenso sobre o design da solução;
2. Delivery lead time, que inicia quando há uma consenso sobre o que deve ser implementado até que a solução esteja disponível para o cliente.

O delivery lead time é mais fácil de medir e apresenta menor variabilidade.

[tweet]Quando menor for o delivery lead time maiores serão as interações com os clientes e, consequentemente, mais qualificados serão os feedbacks.[/tweet]

#2 – Frequência de Deploy

Considerando deploy toda modificação de uma aplicação em ambiente produtivo, organizações mais performáticas são aquelas que o efetuam mais frequentemente.

[tweet]Deploys mais frequentes implicam em menos modificações por ocorrência. Por isso, são mais favoráveis para detecção de causas de falhas e têm impacto menor para o negócio quando um rollback ou hotfix for necessário.[/tweet]

Deploys mais frequentes implicam em menores volumes de modificações (batch size) e, por isso, são mais fáceis de gerenciar em caso de falhas e tem menos impacto para o negócio caso um rollback seja necessário. Além disso, quando implicam em modificações, como em esquemas de bancos de dados, geralmente são mais simples de operacionalizar.

Importante destacar que nem todo deploy implica, necessariamente, em mudanças percebidas pelos usuários. Assim, delivery lead time e a frequência de deploy, embora correlatas, não tem relação causal.

#3 – Tempo médio para recuperação de falhas

[tweet]A abordagem conservadora de medir o tempo entre incidentes (erros) em produção acaba gerando pressão contrária ao baixos delivery lead times e altas frequências de deploy.[/tweet] Afinal, quanto maiores as modificações em ambientes produtivos, maiores as chances de gerar alguma instabilidade.

Modernamente, mais relevante do que impedir falhas em ambiente produtivos é reduzir seus impactos, geralmente, minimizando o tempo necessário para a recuperação.

Tanto DevOps quanto SRE dão ênfase a reversibilidade dos deploys através da automação. Aliás, essa é a estratégia comum para combater a complexidade (a terceira fonte comum de complexidade é a irreversibilidade).

#4 – Change fail percentage

Uma modificação é considerada falha quando implicar em uma intervenção ativa para ser remediada em ambiente produtivo. Essa intervenção poderá ser, por exemplo, um hotfix ou rollback.

[tweet]Percentuais elevados de falhas em mudanças geralmente apontam para problemas no processo de desenvolvimento, como cobertura inadequada de testes; diferenças acentuadas entre ambientes produtivos, homologação e desenvolvimento ou; problemas de gestão do ambiente produtivo.[/tweet]

Fortes quando isolados, imbatíveis quando combinados

Os quatro indicadores apresentados aqui, isoladamente, conduzem a melhorias dos processos de desenvolvimento de software e melhoram a performance. Entretanto, combinados, se reforçam mutuamente e compensam eventuais exageros.

Empresas com culturas generativas, utilizam esses quatro indicadores de maneira combinada para terem segurança de acelerarem entregas e maximizar a geração de valor. Assumindo que a mudança da cultura começa pela mudança de comportamento, adotar esses quatro indicadores ajuda as organizações a desenvolverem cultura apropriada.

Lideranças técnicas mais competentes, primeiro observam esses indicadores e, depois, estabelecem metas consistentes para eles impulsionando o aperfeiçoamento de resultados – direcionando de forma positiva a atuação da gestão.