Novidade do Aviator: a calculadora que avalia a eficiência da engenharia

Medir a produtividade da engenharia é um processo complicado — é difícil ter uma visão completa de como os desenvolvedores gastam seu tempo. Uma forma comum de medir a produtividade é analisar métricas de sistema como DORA ou SPACE. Essas podem ser métricas extremamente úteis para entender a produtividade da equipe em comparação com os padrões do setor. Mergulhar em cada uma dessas métricas também pode fornecer insights sobre o que está atrasando a equipe.

Mas, às vezes, também existem “bolsões ocultos” de tempo que os desenvolvedores passam ao longo do dia e que podem não ser percebidos como impactando a produtividade. No entanto, quando começamos a somar essas coisas, os números podem ser alarmantes.

Por exemplo, considere quanto tempo um desenvolvedor gasta depurando um teste instável tentando descobrir se ele falhou devido à alteração ou não. Ou o tempo gasto por um desenvolvedor tentando resolver uma falha de compilação da linha principal.

Para fornecer essa perspectiva, construímos uma calculadora que avalia a eficiência da engenharia. De forma alguma isso fornece uma análise completa da eficiência da sua equipe de engenharia. O que ele fornece é um vislumbre dos “bolsões ocultos” de tempo desperdiçado que normalmente não aparecem nas métricas de produtividade mais comuns.

A calculadora se concentra em quanto tempo você e sua equipe perdem devido a falhas de construção e teste nos fluxos de trabalho do desenvolvedor.

Se você comparar isso com as métricas DORA, o tempo de espera para mudanças é significativamente afetado pela instabilidade de construção e teste. Esse impacto pode ser avaliado usando esta calculadora.

Como funciona

Pedimos que você insira dados com base em suas atividades no GitHub e em como você usa as ramificações do GitHub. Para explicar os cálculos reais abaixo, vamos atribuir variáveis a cada um deles:

M – PRs mesclados por dia

X – falhas na linha principal em uma semana

T – tempo médio de IC

F – fator de escamação%

Com base nessas informações, estimamos quanto tempo sua equipe de engenharia perde semanalmente gerenciando falhas de construção e lidando com testes instáveis. Vamos examinar os resultados um por um.

Horas desperdiçadas para consertar

Isso calcula quantas horas são desperdiçadas para identificar, fazer a triagem, corrigir e fazer com que a compilação seja aprovada novamente quando uma falha na compilação da linha principal é detectada. Normalmente, em uma equipe grande, alguém notará e relatará a construção da linha principal quebrada.

Presumimos que uma falha de compilação da linha principal envolve uma média de 1 a 3 desenvolvedores para depurar e corrigir. Se considerarmos uma média de uma hora para o tempo que leva para o problema ser relatado e uma correção ser enviada, estamos gastando (2*T + 1) horas para rastrear, investigar e resolver o problema.

Isso significa que se houver X falhas por semana, estamos gastando (( 2 devs * X/5 * (2*T + 1)) horas em tempo de desenvolvedor para combater falhas de compilação da linha principal todos os dias.

Horas desperdiçadas na resolução de conflitos de mesclagem

Reversões e conflitos de mesclagem podem causar outros problemas. Supondo que haja cerca de 2% de PRs que apresentam conflitos de mesclagem durante a janela de tempo de construção interrompido ((2*T + 1) * X/5) e PRs M/8 chegando a cada hora, gastaremos ((2* T + 1) * X/5) * 0,02 * M/8 desperdiçados na resolução desses conflitos.

Falhas semanais de CI devido a compilações quebradas

Se a equipe não estiver usando um ramo dourado para basear seus ramos de recursos, eles provavelmente criarão ramos de recursos sobre um ramo de linha principal com falha. Como o número de PRs criados durante qualquer momento seria semelhante ao número médio de ramificações de recursos baseadas fora da linha principal, isso causaria (2*T + 1 hora) * X/5 * M/8 número de falhas de CI acontecendo todos os dias .

Hora de resolver IC

Com aproximadamente quinze minutos de troca de contexto para lidar com cada falha de build, isso representa (2*T + 1 hora) * X/5 * M/8 * 0,25 horas de tempo do desenvolvedor desperdiçado todos os dias com falhas de CI.

Tempo gasto na reexecução de testes instáveis.

Da mesma forma, com os testes instáveis, o tempo de mudança de contexto necessário para investigar se o teste era instável ou real e a reexecução dos testes em si leva em média quinze minutos por execução. Dependendo do fator de escamação, os desenvolvedores desperdiçariam (0,25*M*F/100) horas todos os dias.

Melhorando a eficiência

Embora a maioria deles tenha impacto nas métricas DORA associadas ao prazo de entrega para mudanças, ainda estamos apenas arranhando a superfície em termos de medição das ineficiências nos fluxos de trabalho da equipe de engenharia. O impacto das falhas de construção e teste também leva a lançamentos atrasados, afetando outras métricas DORA, como frequência de implantação, tempo para restaurar o serviço e persistência de testes instáveis no sistema, o que pode levar a uma maior chance de taxa de falha. Saiba mais sobre as métricas DORA . Ou aprenda mais sobre suas desvantagens.

Construímos o Aviator para resolver alguns desses desafios ocultos para grandes equipes de engenharia. Hoje, usando o Aviator MergeQueue, muitas organizações de engenharia podem dimensionar seu fluxo de trabalho de mesclagem sem interromper a construção. Combinando isso com um sistema de supressão de testes instável como o TestDeck , as equipes podem economizar centenas de horas de engenharia todas as semanas.

Também publicado aqui .