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 para rastrear, investigar e resolver o problema. (2*T + 1) horas Isso significa que se houver X falhas por semana, estamos gastando (( em tempo de desenvolvedor para combater falhas de compilação da linha principal todos os dias. 2 devs * X/5 * (2*T + 1)) horas 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 e PRs chegando a cada hora, gastaremos desperdiçados na resolução desses conflitos. ((2*T + 1) * X/5) M/8 ((2* T + 1) * X/5) * 0,02 * M/8 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 número de falhas de CI acontecendo todos os dias . (2*T + 1 hora) * X/5 * M/8 Hora de resolver IC Com aproximadamente quinze minutos de troca de contexto para lidar com cada falha de build, isso representa horas de tempo do desenvolvedor desperdiçado todos os dias com falhas de CI. (2*T + 1 hora) * X/5 * M/8 * 0,25 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 horas todos os dias. (0,25*M*F/100) Melhorando a eficiência Embora a maioria deles tenha impacto nas métricas DORA associadas ao 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 e persistência de testes instáveis no sistema, o que pode levar a uma maior chance de taxa de falha. . prazo de entrega para mudanças, frequência de implantação, tempo para restaurar o serviço Saiba mais sobre as métricas DORA Ou aprenda mais sobre suas desvantagens. Construímos 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 , as equipes podem economizar centenas de horas de engenharia todas as semanas. o Aviator o TestDeck Também publicado . aqui
