Cinco melhores KPIs de engenharia de software, e como eles são enganados

Por Bill Harding,Programador/CEO
Publicado em 31 de março de 2020. Última atualização em 17 de abril de 2020.

Quando as pessoas falam de KPIs de engenharia, há dois truísmos contraditórios que se ouve frequentemente:

O que é medido melhora.-Peter Drucker

E

Quando uma medida se torna um alvo, deixa de ser uma boa medida.-Goodhart’s Law

ambas estas afirmações descrevem os KPIs de engenharia em parte, mas no seu conjunto implicam que é possível usar a medida para melhorar. A boa notícia é que as métricas cuidadosamente escolhidas podem e continuam a funcionar, apesar de “se tornarem um alvo”. Na verdade, para muitas das métricas recomendamos, quanto mais um funcionário “joga o sistema”, mais os interesses da empresa a longo prazo são servidos. O objetivo final são métricas que continuem a funcionar bem enquanto são “gamed”. Há cinco métricas que atendem a esta barra.

Target audience: Um manager que tentou arranjar bilhetes mais completos da sua equipa de engenharia conhece a luta. Eles querem tomar acções justas, com base em dados que melhorem a sua velocidade. Eles sabem que tomar decisões com base em instintos instintivos é caro e instintivo. No entanto, quando olham para a sua lista de afazeres, são as tarefas mais urgentes do que “melhorar a medição”. Na prática, abraçar a medição frequentemente acontece após uma falha catastrófica, como um buggy release build ou notar que um desenvolvedor não fechou nenhum ticket em um mês.

Even quando é claro que a medição precisa acontecer, é ambíguo por onde começar. Você pode “projetar KPIs” no Google, clicar em toda a primeira página de resultados e não ficar claro sobre os próximos passos a serem tomados. Tome como exemplo a métrica frequentemente utilizada “Velocidade da equipe”. Quase todos os resultados do Google recomendam medir a “Velocidade da Equipa”, mas ninguém quer dizer se está a ser medida em…bilhetes fechados? Linhas de código? Pontos da história? Seja o que for, os gerentes não têm tempo para descobrir. Eles precisam de se entender a partir desta montanha de 15.000 pés de teoria em algo que eles possam entender, confiar e se beneficiar de… de preferência imediatamente.

A premissa organizadora deste artigo é que você é um gerente que quer entender a engenharia de software – agmetria apenas o suficiente para tornar sua equipe mais eficaz. Ser um gerente significa que você está muito ocupado para aprender sobre a teoria, exceto onde ela se vincula diretamente a como você pode se beneficiar dessa teoria.

Metrics deve ser prático para negócios reais para experimentar

Antes de escrever este artigo, nós digerimos as métricas propostas pelos 20 melhores resultados do Google no domínio das métricas do software. Como você pode imaginar, cada fonte tinha suas próprias teorias sobre quais métricas eram mais importantes. Seus artigos muitas vezes dividiam as métricas em grupos como “métricas de processo” e “métricas de projeto”. Vamos seguir a sua deixa no agrupamento de métricas, mas os nossos grupos serão “métricas de qualidade” e “tudo o resto”

Aqui está o que se qualifica como Métrica de Qualidade:

  • Valor do negócio.É possível traçar uma linha recta a partir da métrica => valor do negócio criado?
  • Mensurável.Podemos definir um número específico e as suas unidades de medida (por exemplo, É possível definir um número específico e suas unidades de medida (por exemplo, pontos, porcentagem), para que possa ser rastreado ao longo do tempo e correlacionado com eventos e experiências?
  • Acionável. É possível informar regularmente as ações que levam a resultados positivos? De preferência com o mínimo de falsos positivos?
  • Disponível/conveniente.Pode uma equipa média de engenharia de software ter acesso a esta métrica sem alterar os seus processos de desenvolvimento existentes?
  • Popular.Tem um número suficiente de seguidores para ser bem documentado e credível?
  • Inclusão no balde “Métricas de Qualidade” requer todos os cinco acima, mais uma resposta satisfatória à nossa pergunta: se confiarmos nesta métrica, e os desenvolvedores subseqüentemente otimizarem para ela, o que acontece então? Em nossos anos de construção e iteração da nossa própria métrica de desenvolvimento (“Line Impact”), aprendemos que os subprodutos tóxicos são uma consequência esperada da medição, a menos que a métrica esteja precisamente alinhada com o valor do negócio a longo prazo.Como exemplo, mais tarde mostraremos como os desenvolvedores que tentam jogar a métrica “Lead Time” causam redução de transparência para a gestão.

    KPIs de engenharia de qualidade

    Aqui estão cinco métricas de software que marcam todas as caixas para ajudar os gerentes a executar uma equipe mais eficiente.

    🏦 OKR-driven

    Exemplo OKR template

    Um dos muitos exemplos de templates OKR disponíveis via Weekdone em Okrexamples.com

    Any list that’s focused on maximizing business value should to start here. Empresas líderes como aGoogle usam o OKRsas como eixo principal para avaliar os engenheiros seniores. A desvantagem das métricas orientadas pelo OKR é que elas são, por definição, específicas para os detalhes do negócio. Isto impossibilita a generalização de uma fórmula através da qual se pode capturá-los, ou generalizar o caminho pelo qual eles serão gamed.

    Como jogá-lo? O risco de OKRs serem gamed é baixo, uma vez que eles são normalmente centrados nos negócios. O principal perigo das métricas orientadas pelo OKR é que, como são tipicamente formuladas de uma só vez (ou periodicamente), talvez sejam menos confiáveis do que as métricas que têm sido verificadas ao longo dos anos. Por exemplo, configurar um OKR para “introduzir menos de 10 bugs por mês” pode ser evitado ao não lançar nenhuma nova funcionalidade. Assumindo que ambas as partes estão agindo de boa fé, os jogos OKR deveriam na prática ser raros.

    Como obtê-lo… Através de painéis de medição existentes, ou trabalhando com empresas como a Weekdonewhow que ajudam a fornecer inspiração OKR.

    📐Line Impact

    Exemplo de engenharia KPI Line Impact: métrica do código fonte confiável

    10 repos graphed by their Line Impact, uma métrica que quantifica o ritmo em que o código fonte está evoluindo,imagem cortesia GitClear

    Line Impact é uma métrica projetada para medir quanta energia cognitiva está sendo colocada no desenvolvimento de software.Este vídeo oferece uma explicação ilustrada de como isso é possível. A pequena explicação é que o Line Impact cancela toda a atividade intersticial (“churn”) que acontece asa característica é desenvolvida, deixando uma encarnação concentrada do trabalho que ocorreu. Line Impact é conservedacross, portanto leva um tempo consistente para gerar Line Impact se o desenvolvedor está escrevendo Java, Python, Javascript, ou qualquer outra linguagem de programação principal (30+ suportada).

    Em termos de valor de negócio, Line Impact paralela Story Points: ilustra como o custo de uma tarefa flutua dependendo do desenvolvedor a quem ela é atribuída. A partir disso, um gerente engajado pode usar o relatório de Especialistas em Domínios para combinar Jiras com especialistas no assunto, o que pode acelerar drasticamente a velocidade do produto.

    Como jogá-lo… Qualquer métrica que reclame “Linhas de Código” (LoC) como uma fonte de dados (como faz Line Impact) merece ser abordada com precaução. Implementado de forma descuidada, imperfeições sutis em processingget ampliam a intonoise que afasta o sinal. Por isso GitClear construiu as melhores ferramentas de revisão de código do mercado:para que gerentes e desenvolvedores possam revisar como Line Impact está sendo dado por compromisso, por arquivo.Transparência é um potente antídoto para combater jogos.

    Proteção adicional vem na forma de notificações que são acionadas quando um desenvolvedor contribui com trabalho a uma velocidade incomum. Estas e outras medidas tornaram suficientemente difícil para o jogo Line Impact que GitClear ainda não recebeu um cliente relatando que o Line Impact foi lançado com sucesso pela sua equipe.Dito isto, seria desonesto afirmar que a métrica é de alguma forma impermeável ao jogo, sohere’s é uma lista de caminhos conhecidos pelos quais acumular o Line Impact. A essência é que se um desenvolvedor escreve testes, apaga código antigo e adiciona documentação, ele ganhará uma parte anatômica do Line Impact.

    Como obtê-lo… Cadastre-se para um teste gratuito de 15 dias. Se você gostar,os preços começam em $9 por desenvolvedor ativo.Veja um breve vídeo explicativo sobre o Line Impact aqui.Na versão pré disponível.

    🎲 Story Points

    KPIs de engenharia: Jira burndown report

    Story Point-based “release burndown” report,disponível via Jira

    Story Points could lay claim to be the most “classic” of engineering KPIs. Existem diversas formas de calcular os Pontos de História. Todos os formulários mapeiam de volta para uma estimativa do tempo esperado do desenvolvedor para completar alguma tarefa. Gerentes podem usar Story Points para calcular os custos implícitos por uma tarefa, por exemplo, se um desenvolvedor ganha $10k/mês, o ticket é estimado em 10 Story Points = meio mês, então o custo é $10.000 * 0.5 = $5.000.Usar alguma versão desse cálculo ajuda a priorizar tarefas com base na maior relação entre o Valor Projeitado/Custo de Implementação Projetado.

    Como jogá-lo… A maior parte da atenção aqui pertence a como os Story Points são calculados. A maneira mais fácil de “jogar” Story Points é a equipe de desenvolvedores enviesar a escala de classificação, geralmente no sentido de superestimar a dificuldade. Uma opção para resolver isso é permitir que tarefas sejam beselecionadas em um “mercado de tarefas”, onde tarefas supervalorizadas podem ser distribuídas uniformemente entre os desenvolvedores para manter a calibragem. Outra maneira de endereçá-la é recalibrar regularmente a constante usada para traduzirStory Points em “dias do desenvolvedor”. Note que como a implementação de Story Points muitas vezes difere pela equipe, não é aconselhável usá-los para comparar o desempenho entre as equipes.

    Como obtê-lo… A maioria dos rastreadores de problemas deste lado do GitHub permite especificar Story Points. Em termos de visualização, Jira fornece um “next-gen velocity report” dedicado ao propósito de mostrar os Story Points completados ao longo do tempo. Eles também oferecem um “release burndown report” que usa os Story Points para estimar como a equipe está seguindo em direção aos seus objetivos para o sprint. GitClear também oferece gráficos rudimentares (de momento) que ilustram Story Points completados ao longo do tempo.

    🐞 Bug Rate / Escaped Defects

    Esta métrica é definida de várias maneiras por várias fontes, mas todos eles chegam à mesma pergunta essencial: quantos bugs estão saindo para o mundo, e quão bem estamos respondendo a eles?Stackify relaciona-a em termos numéricos específicos:

    A sua taxa de fuga de defeitos é expressa como uma percentagem baseada em quantos defeitos você encontra antes de eles chegarem à produção ou quantos chegam à produção, como você preferir. Cada projeto e equipe de software será diferente, mas sugerimos que se esforce para encontrar 90% de todos os defeitos antes que eles cheguem à produção.

    A definição de Stackify faz a suposição de que um willdesignate um campo em seu trackerto de problema capture em que fase de desenvolvimento o bug ocorreu. Para equipes que não têm tempo para configurar e acompanhar as fases de desenvolvimento, uma definição substituta pode ser:

    Quantas vezes o código criado em uma nova funcionalidade se torna código alterado no curso da resolução de um bug?

    Uma resposta vinculada a esta pergunta é fornecida aos usuários do GitClear, mas é difícil de calcular manualmente (se você não é um usuário do GitClear). Uma medida de recuperação de erro disponível pode ser “qual é a proporção de bugs criados vs bugs resolvidos”?

    Como jogar?Esta métrica é difícil de jogar. Um desenvolvedor pode aceitar mais bilhetes pequenos, mas cada bilhete introduz um risco incremental de bugs se eles não forem cuidadosos. Este risco de usar Bug Rate é que ele precisa de um contrapeso para “progresso” como Story Points ou Line Impact, caso contrário um desenvolvedor poderia permanecer em um único problema para o sprint do theentire, garantindo uma taxa de erro de 0%.

    Como obtê-lo? Se a sua equipe tem a largura de banda para rotular os problemas pela fase de desenvolvimento em que eles ocorreram, então oEscaped Defects pode ser calculado manualmente através de qualquer rastreador de problemas. GitClear é outra opção disponível para calcular a percentagem de funcionalidades que se tornam bugs.

    ✅ Pull Request Completion Rate

    Exemplo de solicitações de puxar KPI de engenharia: estatísticas no GitClear

    Uma amostra das estatísticas de solicitação de puxar fornecidas por GitClear

    Que percentagem de solicitações de puxar foram fechadas dentro de uma semana após terem sido abertas? Isto enrola várias outras perguntas granulares, como “a equipe está empenhada em responder prontamente a novos pedidos de puxar”, “eles são capazes de cooperar”, e “os desenvolvedores poliram seu código antes de submetê-lo para fusão?”

    Como jogar? Acessando o teste “Taxa de conclusão de pedidos de puxar” significa sempre fechar PRs dentro de uma semana. Este é um jogo relativamente difícil, mas deve ser contrabalançado por uma força propulsiva como Story Points ou Line Impact, caso contrário todos os incentivos da equipe serão para polir o trabalho em vez de enviá-lo (ou enviá-lo para revisão de PR).

    Como obtê-lo?Todos os fornecedores da “marca do nome” Engineering Insight (GitClear, Pluralsight, Code Climate, Pinpoint) oferecem estatísticas que ilustram a eficiência do processo de solicitação de puxar uma equipe. Nós ajudamos a comparar os fornecedores aqui.

    Menções honrosas

    Baixo da métrica “top tier”, encontramos uma camada intersticial. Estas são métricas que apresentam características desejáveis juntamente com importantes deficiências. Eles ainda podem fornecer valor, por tanto tempo asa Manager sabe o suficiente para explicar suas limitações.

    Lead Time/Cycle Time

    Lead Time gráfico como visualizado via Azure Devops

    Apesar de ser listado (duas vezes!) inPluralsight’s list of Top 5 Metrics,Cycle Time is a good idea that is highly susceptible to gaming.

    “Lead Time” is most often defined as “What is the interval between when a task is filed in the issue trackerand when it is delivered to the customer? O seu primo, “Cycle Time”, é um subconjunto do Lead Time, definido como “o tempo entre quando a equipa do produto o arrancou da fila e quando atingiu a produção”.

    Como jogá-lo… O desempenho do Lead Time depende em certa medida do mecanismo pelo qual o Jiras é arquivado, o que significa que a sua aplicabilidade entre equipas é baixa. O tempo de ciclo depende das convenções pelas quais o committer escolhe o primeiro commit. Assim, esta métrica é simples de jogar se um desenvolvedor salva seus commits localmente e os libera em uma explosão de trabalho imediatamente antes de enviar o PR. Esta falha é o que relega o Tempo de Ciclo para a seção “Menções Honrosas”. Também não é o ideal: ao incentivar um desenvolvedor a salvar seus compromissos sem empurrar, é impossível para os colegas de equipe intervir enquanto esse trabalho está em andamento.Este efeito secundário reduz a transparência entre um gerente e seus desenvolvedores.

    Como obtê-lo… Azure Devops Services fornece o gráfico acima.Jira oferece uma versão do mesmo também.Todas as principais ofertas daEngineering Insight (GitClear, Pluralsight, Code Climate Velocity, Pinpoint) implementam um cálculo de someversion do Lead Time.

    Test coverage

    Trying para capturar alguma medida de cobertura de teste é um objetivo razoável a ser considerado. No entanto, não faz bem o corte como uma métrica Top Tier por duas razões:

  1. É uma solução incompleta. Testes adequados devem incluir testes funcionais e de integração junto com testes unitários, e nenhuma solução automatizada pode saber quais páginas precisam ser visitadas no aplicativo ou website, isto ainda toma a direção humana
  2. É muito difícil ligar de volta à métrica de negócio de primeira linha. A cobertura de teste é avaliada como parte do plano de um Desenvolvedor Líder para monitorar a qualidade do código, mas não se conecta diretamente ao valor do negócio o suficiente para fazer o corte a si mesmo. Uma métrica relacionada mas mais funcional para rastrear defeitos de código é “Bug Rate / Escaped Defects”

“Everything Else” Metrics

A lista acima é relativamente curta comparada com o corpus de métricas passadas que foram propostas por outros autores.Por uma questão de completude, vamos rever algumas das métricas mais comumente mencionadas em outros artigos, e porque elas não fizeram o corte.

Velocidade da equipe

Esta foi uma das métricas mais populares citadas por outros artigos. É recomendada porTechBeacon,InfoPulse,eSeaLights.io. No entanto, os autores parecem desconfiados em definir as unidades desta importante métrica.TechBeacon a define como “quantas ‘unidades’ de software a equipe normalmente completa em uma iteração”. Não é sotangível. InfoPulse não tenta especificar unidades. SeaLights diz que as unidades são “Story Points” (Pontos de História). Assim, nós concluímos que a noção de “velocidade” é adequadamente capturada por Story Points, ou Impacto de Linha por proxy.

Code Churn

O CEO do GitPrime (agora adquirido pela Pluralsight) foi entre aqueles que defendiam a consideração do Code Churn.Nós argumentamos em resposta que as implicações do Code Churn estão em todo o mapa, o que torna muito difícil agir em alta rotatividade. O sistema de métricas precisa ser acionável.

Release/Sprint Burndown

SeaLights and InfoPulse recomendam prestar atenção a como uma equipe está tendendo para seus objetivos de sprint.Nós concordamos que isso é importante, mas já está coberto pela seção “Story Points” acima.

Mean time to repair / Mean time between failures

Dentre os poucos artigos que defendem essas métricas, nenhum se aventura a descrever em que unidades as métricas se baseiam, ou que serviço pode ser usado para reunir esses pontos de dados. A pesquisa descobre que a Atlassian oferece um artigo de ajuda sobre o assunto. Se esse artigo ainda não tivesse 2.500 palavras, o MTTR poderia fazer a seção “Menções Honrosas”. Mas não é fácil ligar ao valor do negócio, e não é fácil para uma equipa média ter acesso sem mudar as suas rotinas.

Evitei qualquer coisa?

Leave a Reply

Deixe uma resposta

O seu endereço de email não será publicado.