Como eu disse no artigo “Por que as métricas não importa no desenvolvimento de software (a menos que você emparelhá-los com os objetivos de negócio),” a escolha de métricas requer uma quantidade considerável de pensamento e de cuidados para apoiar as questões específicas que uma empresa realmente precisa responder. Aqui está o ponto crítico: as medições devem ser projetadas apenas como uma maneira de responder às perguntas do negócio. E essas perguntas nunca são: “quantos KLOCs temos até agora?”
este artigo pega onde o anterior parou, discutindo primeiro as métricas específicas que cada equipe deve começar a usar, ou pelo menos planejar usar logo que uma maneira de melhorar o desempenho perceptível. Note que o título deste artigo afirma que existem ” 9 métricas que podem fazer a diferença…”—porque o que é realmente importante, o que realmente fará a diferença, é como essas métricas são realmente usadas para melhorar o valor do negócio. Esse uso depende de ti. Em seguida, este artigo conclui explicando como você pode combinar essas métricas para criar significado, bem como formular e testar uma hipótese de valor de Negócio.
comece por medir as coisas certas
Aqui estão nove métricas objetivas (marcadas por pontos de bala) que você deve monitorar continuamente, para fazer melhorias incrementais nos processos e ambientes de produção. Melhorias nestes números não garantirão que os níveis de satisfação do seu cliente aumentarão por saltos e limites. Mas, pelo menos, estas são as coisas certas a medir. Em uma seção posterior deste artigo, “Juntando tudo”, você verá o porquê.
métricas de processo ágil
para processos ágeis e magros, as métricas básicas são o tempo de chumbo, o tempo de ciclo, a velocidade de equipe e taxas abertas/próximas. Estas métricas ajudam a planejar e informar as decisões sobre a melhoria do processo. Enquanto eles não medem sucesso ou valor acrescentado, e eles não têm nada a ver com a qualidade objetiva do software, você deve medi-los de qualquer maneira. Vou explicar porquê lá em baixo.
- Leadtime-quanto tempo leva para passar da ideia ao software entregue. Se você quiser ser mais sensível aos seus clientes, Trabalhe para reduzir o seu tempo de espera, normalmente simplificando a tomada de decisões e reduzindo o tempo de espera. O tempo de chumbo inclui o tempo de ciclo.
- velocidade de equipe-quantas ” unidades “de software a equipe normalmente completa em uma iteração (t. c. p.”sprint”). Este número só deve ser utilizado para planear iterações. Comparar velocidades de equipe é um disparate, porque a métrica é baseada em estimativas não objetivas. Tratar a velocidade como uma medida de sucesso é inapropriado, e fazer uma velocidade específica em um objetivo distorce seu valor para estimativa e planejamento.
- taxas abertas/próximas – quantas emissões de produção são reportadas e encerradas num determinado período de tempo. A tendência geral é mais importante do que os números específicos.
quando qualquer ou todas estas métricas estão fora do alcance esperado ou tendendo em direções alarmantes, não assumem uma causa. Fale com a equipa, fique com a história toda, e deixe a equipa decidir se há motivo de preocupação, e em caso afirmativo, como resolvê-la.
você não pode saber ou assumir causas raiz a partir dos números, mas estas métricas lhe dão uma visão sobre onde seus processos essenciais precisam de atenção. Uma alta taxa de abertura e uma baixa taxa de encerramento em algumas iterações, por exemplo, pode significar que os problemas de produção são actualmente uma prioridade mais baixa do que novos recursos, ou, talvez, que a equipe está focada em reduzir a dívida técnica para corrigir toda a classes de problemas, ou que a única pessoa que sabia como corrigi-los sair, ou qualquer outra coisa. Você não pode saber ou assumir causas raiz a partir dos números.
Produção analytics
- tempo Médio entre falhas (MTBF)
- tempo Médio de recuperação/reparação (MTTR)
Ambos são, em geral, as medidas de seu software de desempenho do sistema no seu ambiente de produção.
- taxa de colisão da aplicação—quantas vezes uma aplicação falha dividida por quantas vezes foi usada. Esta métrica está relacionada com MTBF e MTTR.
Note que nenhuma destas três métricas lhe diz sobre características individuais ou usuários afetados. Ainda assim, quanto menores forem os números, melhor. Operações modernas – software de monitoramento torna a coleta de métricas detalhadas em programas individuais e transações bastante fácil, mas leva tempo e cuidado para configurar intervalos adequados para alertas e/ou gatilhos para escalar para cima ou para baixo (para sistemas baseados em nuvem). Gostaríamos que o nosso software nunca falhasse, mas isso é estatisticamente improvável. Quando o nosso software falhar, gostaríamos que ele nunca perdesse quaisquer dados críticos e recuperasse instantaneamente, mas isso pode ser extraordinariamente difícil de alcançar. Se o seu software é a sua fonte de receita, no entanto, o esforço vale a pena.
para além do MTBF e do MTTR, as medições mais refinadas baseiam-se em transacções individuais, aplicações, etc., e reflectem o valor comercial entregue e o custo da reparação de falhas. Se o seu aplicativo de processamento de transações cai uma vez em uma centena, mas recupera em um segundo ou dois e não perde qualquer informação crítica, que a taxa de queda de 1 por cento pode ser bom o suficiente. Mas se cada acidente é de um aplicativo que executa 100.000 transações por dia, perde uma venda de US $100, e custa US $50 para remediá-lo na parte de trás, essa taxa de queda de 1 por cento vai ser uma prioridade. Corrigi-lo irá impactar significativamente o resultado final.
métricas de segurança
segurança é um aspecto da qualidade do software que é muitas vezes ignorado até mais tarde (ou tarde demais). Ferramentas de análise de segurança podem ser usadas no processo de construção, além de avaliações mais especializadas e testes de esforço. Os requisitos de segurança são muitas vezes simples e sensoriais em comum, mas a equipe de desenvolvimento de software precisa estar atenta a eles, e às métricas derivadas deles.
a gama completa de práticas de segurança e métricas relacionadas está além do âmbito deste artigo, mas como com métricas de processo ágil e métricas de produção, existem algumas métricas específicas que podem significar muito para a satisfação geral dos seus clientes.
- Endpoints-quantos endpoints (dispositivos móveis, estações de trabalho, etc.) experimentaram uma infecção viral durante um determinado período de tempo?
- MTTR (tempo médio de reparação)—em métricas de segurança, este é o tempo entre a descoberta de uma falha de segurança e uma solução de trabalho implantada. Como acontece com a métrica de produção MTTR mencionado acima, o MTTR de segurança deve ser rastreado ao longo de intervalos de tempo específicos. Se o valor do MTTR ficar menor ao longo do tempo, então os desenvolvedores estão se tornando mais eficazes na compreensão de problemas de segurança, como bugs e como corrigi-los.
para ambas estas métricas, números menores ao longo do tempo significam que você está se movendo na direção certa. Menos incidentes finais falam por si. À medida que o valor MTTR cresce menor, os desenvolvedores estão se tornando mais eficazes na compreensão de problemas de segurança, como bugs e como corrigi-los.
pode encontrar mais formas de aplicar métricas de segurança ao desenvolvimento de software nos artigos Segurança Aplicação para projetos ágeis e modelos de ameaça de segurança: Uma Introdução ágil.
a note on source-code metrics
Today it is easy to plug a source-code scanner into your build pipeline and produce reams of objective metrics. Existem médias empíricas e gamas sugeridas e argumentos lógicos sobre a importância relativa destas métricas. Mas, na prática, essas ferramentas são muito úteis na aplicação de estilos de codificação, sinalizando certos anti-padrões, e identificando anómalos e tendências. Não vale a pena ficar preso aos números. Aqui está um exemplo, a título de explicação.
suponha que você encontre um método em uma classe com uma métrica ridícula, como uma complexidade NPATH de 52 milhões. Isso significa que seriam precisos 52 milhões de casos de teste para exercer plenamente todos os caminhos através do Código. Você poderia refazer o código em uma estrutura mais simples, mas antes de fazer isso, considere qual seria o impacto do negócio. As Chances são, o código velho, feio funciona bem o suficiente (embora sua cobertura de teste pode ser inadequada). Chamar o anti-padrão para a equipe para que eles possam evitar repeti-lo é uma aprendizagem valiosa, mas corrigi-lo provavelmente não iria mover a agulha em qualquer métrica de Negócio relevante.
é melhor que a equipa concorde com o nível de cumprimento e regras a que o seu código está sujeito, mas esteja ciente de que examinar os casos anómalos e ficar preocupada com as tendências blips pode perder muito tempo.
depois junta tudo: Success is the ultimate metric
The joy of using automated tools for tracking and measuring quality metrics and user analytics is that it frees up time to focus on the metrics that really matter: success metrics.
como usar métricas para o sucesso
as empresas têm objetivos. Objetivos implicam em perguntas, como “Como é o sucesso?”ou” como isso afetará o comportamento do cliente?”Perguntas devidamente quantificadas implicam métricas.
dito de outra forma, as métricas só devem ser usadas para responder a perguntas, para testar hipóteses que suportam um objetivo de negócio específico. E isso deve ser feito apenas enquanto as perguntas e Respostas ajudam a conduzir mudanças positivas.
Now, don’t all projects in general have some set of invariant goals, questions, and hypotheses, and thus metrics?
Sim, mas apenas do ponto de vista da empresa. Medidas a nível de negócios de coisas como envolvimento do Usuário, taxas próximas, geração de receita, e assim por diante fornecer feedback sobre como o negócio está fazendo no mundo real. Mudanças no software que afetam o negócio também afetará estes tipos de métricas.
a um nível mais fino de resolução, cada recurso e história de usuário pode ter sua própria métrica de sucesso—preferencialmente apenas um, e um que está diretamente relacionado a uma medida de valor entregue ao cliente. Completar nove em cada dez andares em um sprint para recursos que nunca são entregues é desperdício, Não sucesso. Entregar histórias que os clientes não querem ou usam é desperdício, Não sucesso. Entregar uma história que melhora algum aspecto da felicidade do Usuário é um sucesso. Entregar uma história que comprovadamente não melhora o engajamento do usuário também é um sucesso, porque você terá aprendido algo que não funcionou, invalidou uma hipótese de negócio, e liberou recursos para perseguir outras avenidas.
How to formulate a value hypothesis
A value hypothesis is a statement about what you think will happen as a result of the delivery of a specific feature. A relação entre o software, o resultado desejado, e as métricas forma a hipótese de valor para a característica (ou sistema, ou história, ou atualização, etc.). A hipótese deve expressar como se espera que a métrica alvo mude, em que período de tempo, e por quanto a ser considerada eficaz. Você terá que falar com a equipe e proprietário do produto, no mínimo, para descobrir a coisa específica que esta característica ou história se destina a criar ou melhorar com relação ao negócio, a fim de formular a sua hipótese de valor. Você pode ter que perguntar “Por que” algumas vezes (como um de três anos de idade) para descascar para trás as camadas de pressupostos imparáveis; seja paciente. Quando você entender qual é o valor comercial suposto ser, você pode começar a fazer as perguntas que o levarão às métricas que respondem à pergunta.
por exemplo, uma história” técnica ” para melhorar a velocidade de um processo de checkout e-commerce pode ter como pressuposto subjacente que um checkout mais rápido levará a mais vendas. Mas porque pensamos isso? São muitas pessoas abandonando seus carrinhos de compras durante o processo de checkout? Se esse é o consenso (porque esse consenso é apoiado por dados de base), então a hipótese do valor pode ser “acreditamos que um processo de checkout mais rápido resultará em taxas de abandono do carro, levando a vendas mais elevadas e experiência de usuário melhorada.”
você provavelmente pode assumir que os usuários vão gostar de checkout mais rápido, mas não faz mal perguntar se eles notaram. As taxas de abandono do carrinho e as vendas podem ser medidas antes e depois do novo processo estar em vigor, por um período de tempo. Se a taxa de abandono do carrinho diminuir e as vendas aumentarem (para além das flutuações estatísticas), a evidência corrobora a hipótese e poderá considerar se são necessárias melhorias ainda mais rápidas. Se não estiverem, deixe esta métrica desvanecer-se no fundo (ou removê-la, se é que distrai), e vire a sua atenção para a próxima hipótese. Se a taxa de abandono do carrinho diminuir, mas as vendas permanecerem inalteradas, medir durante um período mais longo ou repensar a relação presumida entre abandono do carrinho e vendas. Em outras palavras, use métricas para aprender, e apenas enquanto eles se revelarem úteis para melhorias de condução.
em alguns casos, a hipótese pode estar claramente errada, por isso largamos as métricas (e desfazemos as mudanças de software!) depois de alguns dias. Em outros casos, a hipótese pode estar correta, por isso continuamos a impulsionar melhorias nesta área por anos.
seis heurísticas para o uso efetivo de métricas
vimos como as métricas de software subjetivo importam muito mais para o sucesso dos negócios do que as métricas de qualidade tradicional e objetiva dos antigos. O esforço necessário para encontrar e medir as métricas de negócio relevantes para as características é superado pelas percepções e oportunidades de aprendizagem adquiridas. As condições e oportunidades de Negócio mudam constantemente, então, em vez de resumir uma fórmula a seguir, que pode ser frágil, Aqui estão seis regras de polegar, ou heurísticas, para ajudar a manter o foco e flexibilidade. Que eles ajudem a guiá-lo em sua jornada para o sucesso de software de qualidade e Negócios!
- métricas não podem contar a história; apenas a equipe pode fazer isso (com uma ponta de chapéu para Todd DeCapula).A comparação dos flocos de neve é um desperdício.Você pode medir quase tudo, mas não pode prestar atenção a tudo.
- Business success métrics drive melhorias de software, não o contrário.
- cada recurso acrescenta valor; ou mede-o ou não o faz.
- medir apenas o que importa agora.