Mas eu não estou fazendo besteira de novo? Como e por que implementar métricas de qualidade

Olá Habr! Uma vez que usamos a métrica “Parece melhor” para avaliar a qualidade de nossos lançamentos. Mas então decidimos confiar em algo mais confiável. Neste artigo, falarei sobre como procurei um guia de métricas, não o encontrei e criei o meu.



Acontece que você faz um trabalho aparentemente útil para um projeto, mas não entende se isso traz benefícios? Então, uma vez escrevemos autotestes, mas não conseguimos dizer objetivamente se os lançamentos do monólito e de outros serviços nos quais o desenvolvimento ativo é melhor se tornaram melhores.

Procurando métricas


Procurei na Internet e, por algum motivo, não encontrei artigos ou guias prontos sobre como escolher as métricas corretas, como coletá-las e o que fazer em seguida. Mas, enquanto procurava informações, encontrei vídeos e artigos úteis que me ajudaram a lidar com essa tarefa difícil. Links para eles aparecerão no artigo.

Espero que este artigo seja útil para quem está pensando em medir algo em seu projeto, mas não sabe por onde começar. O artigo contém experiência pessoal, informações de artigos, vídeos e cursos pagos.

Um segundo antes de criar um sistema de medição da qualidade
Antes de decidirmos criar um sistema de métricas de qualidade, já medimos continuamente:

  • O tempo gasto na liberação do monólito (desde o momento da criação da ramificação de liberação até a mesclagem dessa ramificação no mestre).
  • O número de reversões de liberação de monólito para o mestre devido a erros.
  • Tempo gasto em Stop the Line .
  • O número de lançamentos do estágio de pipeline de monólito no TeamCity com todos os autotestes até ficar verde.

Como você pode ver, medimos apenas o que está conectado ao monólito. Para outros serviços, eles não mediram nada.

Implementamos um sistema de medição da qualidade em 11 etapas


Aqui está uma lista de 11 etapas que ajudarão você a implementar tudo e não perder nada.

Etapa 1. Defina o objetivo de suas medições


Entenda por que você deseja começar a medir algo. Medir assim, por uma questão de medida, não faz sentido.

Por exemplo, queríamos saber como estamos caminhando para as metas de qualidade que estabelecemos anteriormente. Também queríamos ver a dinâmica dos indicadores após o esforço. Sozinhos, os números do estado atual não significam nada. Estes são apenas números. Mas, observando as figuras na dinâmica, podemos ver a influência de nossas ações.

Etapa 2. Definir metas


Você precisa entender o que está buscando. Reduzir o tempo de teste? Reduzir o número de bugs críticos no produto? Aumentar a cobertura do teste?

No meu caso, não houve problemas ao definir indicadores de metas, pois nossa empresa possui metas de qualidade. Esses objetivos se tornaram a base para métricas futuras. Nossos objetivos:

  • Uma liberação de monólito não leva mais de 4 horas.
  • 0 hotfixes e reversões no monólito, site e aplicativos móveis.

Etapa 3. Decida sobre as métricas


Pense em como você percebe que está caminhando em direção a seus objetivos.
Nesta fase do trabalho, o artigo " As métricas de controle de qualidade mais importantes " me ajudou.

Para o nosso sistema, escolhi esses indicadores
  • Hora de liberar . Esse código mede o tempo (em horário de trabalho) entre a mesclagem da ramificação da liberação anterior no mestre e a mesclagem da liberação atual no mestre.

    Dividimos esse tempo em 4 estágios: preparação do estande, paisagismo do estágio do oleoduto, teste de regressão manual, implantação no produto.

    Dividimos esse tempo em estágios para ver em detalhes as conseqüências de nossas ações e poder determinar com precisão o gargalo em nosso processo.

    Etapas da métrica do tempo de liberação
  • O coeficiente de "Liberações de problemas" para todos os serviços . Essa é a proporção de "liberações de problemas" para o número total de liberações, tudo isso multiplicado por 100%. Uma "versão problemática" é uma versão na qual houve uma reversão de uma versão, um hotfix ou um datafix.
    Proporção de lançamentos problemáticos em relação ao total de lançamentos
  • A densidade de hotfixes de um serviço para um monólito é a proporção entre o número de hotfixes de um serviço e o número total de hotfixes.
  • Tempo de regressão manual para o aplicativo móvel . Este é o tempo desde o início da regressão manual até sua conclusão.


Importante! Não tome muitas métricas de uma só vez. Três ou quatro são suficientes para começar. Quando o processo melhorar, você poderá adicionar mais, se necessário.

Muitas métricas são difíceis de gerenciar. Está aumentando a probabilidade de o sistema não decolar. E se o processo não decolar na primeira vez, na próxima vez será mais difícil começar, pois você e os funcionários terão experiência negativa.

Etapa 4. Decida sobre as unidades


Diferentes indicadores podem ser lidos em diferentes unidades. Imediatamente, você precisa escolher para que todas as métricas tenham uma unidade de medida; caso contrário, você poderá encontrar mal-entendidos e más interpretações.

Temos problemas com este item. Contamos o tempo de lançamento em horas, incluindo o horário noturno, mas excluindo os finais de semana. Ao mesmo tempo, o valor alvo foi liberado em 4 horas. Muitas vezes, havia situações em que criamos a ramificação release-xxx às 16:00 de hoje e terminamos às 10:00 do dia seguinte. Em nossa métrica, foram consideradas 18 horas, mas, de fato, as ações ativas foram realizadas em apenas 3 horas, se não menos.

Se continuássemos contando dessa maneira, nunca teríamos atingido o indicador "4 horas" em nossa métrica. Tendo enfrentado a escolha, aumentado a meta para 12 horas ou levando em consideração apenas o horário de trabalho, escolhemos a segunda.

Etapa 5. Análise das métricas selecionadas para adequação


No vídeo " Métricas simples de teste prático " , o palestrante sugeriu uma maneira interessante de analisar as métricas de adequação. Você precisa responder 9 perguntas para cada métrica e tomar uma decisão.

Hora de liberar análise métrica sobre adequação
  • O objetivo da medição . Este indicador deve estar relacionado ao objetivo do negócio. A métrica "Hora do lançamento" está relacionada ao objetivo do negócio - lançamento em 4 horas.
  • Para quem essa métrica se destina . Quem analisará essa métrica? Fornecedor de produtos, desenvolvedores, gerentes, testadores, mestres de scrum?

    O fornecedor do produto (porque é importante para ele entender quantas liberações por sprint conseguimos), desenvolvedores (porque eles querem entender quando o código estará no produto) e testadores (já que o tempo está chegando) o teste afeta diretamente essa métrica).
  • Que pergunta é respondida pela métrica do usuário . Formule as perguntas que você recebe com esta métrica. A métrica "Release Time" responde à pergunta: "Com que frequência lançamos?"
  • Declare a ideia da métrica e sua descrição. Breve, mas claramente, descreva a métrica. Descrevi a métrica “Hora de liberar” da seguinte maneira: “Queremos ser lançados o mais rápido possível, essa métrica mostrará a rapidez com que lançamos. Horário de liberação é o horário comercial das 9:00 às 18:00, excluindo fins de semana e feriados. O início de uma liberação é considerado a criação de uma ramificação de liberação ou mesclagem da liberação anterior no mestre; o final do release é a injeção da ramificação de liberação no mestre. Divida o tempo em estágios separados, por exemplo: preparação para liberação, aprovação de autoteste, teste manual, cálculo para prod. ”
  • Condições necessárias . Liste as condições ou restrições para coletar métricas aqui. De quem, quando, de onde virão os dados para métricas. No meu caso, eu sei onde assistir lançamentos de todas as partes. Monólito - mesclar ramificações release-xxx no mestre. Site - batatas em Kaiten.io na placa de lançamento. Aplicativos - ainda não sei, mas vou descobrir "
  • Medições iniciais. Mas não entendi esse ponto e não sei como descrevê-lo. Quem entendeu ou sabe o que pode ser discutido aqui, escreva nos comentários.
  • Indique a fórmula para calcular a métrica. Para a métrica “Time to Release”: quanto tempo decorreu desde a mesclagem da versão anterior ao mestre até a mesclagem da versão atual ao mestre (excluindo fins de semana e feriados). Como resultado, obtemos o horário de trabalho que gastamos no lançamento.
  • Critérios de decisão. Determine o que você fará quando vir alterações nessa métrica. Descreva sua reação. Minha resposta na métrica é "Hora de liberar": "Você precisa responder à métrica pesquisando gargalos e eliminando esses gargalos"
  • Frequência Quantas vezes coletaremos a métrica. Íamos verificar nossa métrica semanalmente, mas, na verdade, fazemos isso com mais frequência.


Após uma análise tão simples, fica imediatamente claro se você precisa ou não dessa métrica. Há um entendimento mais profundo da métrica em si e de seu valor para a empresa e você.

Etapa 6. Alinhar métricas com as partes interessadas


Mostre as métricas selecionadas àquelas que elas afetarão. Discuta as limitações que você descobriu durante a fase de análise, bem como maneiras de eliminá-las ou pelo menos reduzi-las. É especialmente importante obter o consentimento e a aprovação daqueles que coletarão e preencherão essas métricas.

Discuti minhas métricas em três etapas: com testadores, desenvolvedores e produtos excedentes. Somente depois que todos concordaram explicitamente que essas métricas mostravam a qualidade do sistema, pude seguir para a próxima etapa.

Etapa 7. Visualize os resultados


As pessoas não vão ler as tabelas e assistir a dinâmica por conta própria. Portanto, você precisa cuidar da visibilidade.

Fiz uma mesa no Planilhas Google, escrevi fórmulas e tive o prazer de apresentá-la aos meus colegas. Nosso CTO sugeriu a visualização dessas métricas. Mais precisamente, para garantir que o estado atual do sistema fique claro em 15 segundos: ele se tornou melhor em comparação com o sprint anterior ou a qualidade diminuiu.

Juntos, visualizamos os indicadores. Depois, pedi às pessoas para contar o que viram nesse gráfico. A julgar pelas respostas, alcançamos o objetivo.



É assim que a visualização da métrica de qualidade da versão se parece. Tudo está claro, você pode ver imediatamente como está agora e como foi, se o número de problemas excede o número de lançamentos, se tornou melhor ou pior em comparação aos lançamentos anteriores. Em uma programação ideal, a linha azul deve tender ao infinito e a linha vermelha deve ir a 0.


Visualização do relacionamento de “releases problemáticos” com o número total de releases

Etapa 8. Observe a frequência de coleta de métricas


É importante estabelecer o processo de coleta de métricas, para trabalhar com a frequência. Se não houver processo, seu painel perderá sua relevância e morrerá. É importante que haja partes interessadas que farão isso. Mas se você está preocupado com isso, a pessoa em questão já está lá.

Etapa 9. Informe novamente as pessoas sobre os resultados.


Não importa o quão bonito seja o seu painel, as pessoas não vão lá e analisam as métricas. Uma vez que todos verão, isso é algo novo, mas não de forma contínua.

Resolvemos esse problema de três maneiras.
  • Uma história sobre métricas na parte comum de nossa revisão do sprint.
  • Conclusão de gráficos no monitor no corredor, que todo mundo vê todos os dias, para que os números e gráficos estejam sempre diante de seus olhos.
  • Publicar Resumo do Painel Slash. O principal é mostrar a dinâmica ao publicar esses relatórios: ficou melhor ou pior em comparação com o sprint anterior. E se você publicar isso antes que o time seja retro, ele poderá dar aos caras tópicos para discussão.


Etapa 10. Analise e tome decisões


Você precisa examinar as métricas, tomar decisões com base nelas. Você pode usar métricas como argumento adicional em favor de escrever testes adicionais ou se concentrar em dívidas técnicas, em vez de recursos de negócios etc.

Etapa 11. Automatize


Automatize a coleta de métricas o máximo possível. Se você usar os populares sistemas de controle de versão TaskMS e TestMS, sistemas de CI / CD, provavelmente todos eles têm uma API aberta com a qual você pode extrair facilmente essas informações. Se você não pode fazer isso sozinho, peça ajuda aos desenvolvedores. Pode ser necessário alterar alguns processos para isso. Isso é normal. E esse é um preço baixo pelos benefícios que você obtém ao começar a coletar métricas.

Por exemplo, temos um bot que ajuda os liberadores a liberar lançamentos e reduz sua rotina.

Resumo e Conclusões


Tomar decisões que afetam a qualidade do produto com base em seus sentimentos internos é uma má idéia. Os sentimentos podem enganar e levá-lo à decisão errada. Portanto, basta obter o sistema de métricas e avaliação da qualidade.

Mas lembre-se de que um estabelecimento métrico é como um estabelecimento para animais de estimação. Além do lucro de se comunicar com um novo amigo, você recebe uma certa responsabilidade e obrigações com ele. Portanto, inicie as métricas conscientemente, com um entendimento de suas necessidades e prontidão para superar as dificuldades que o aguardam no caminho.

Source: https://habr.com/ru/post/pt468007/


All Articles