Quando se fala em métricas, a primeira coisa que vem à mente são números, gráficos e relatórios, certo? No entanto, elas vão bem além disso. Vem comigo para descobrir a mágica sobre métricas de testes e desenvolvimento!

Afinal, o que são métricas?

Seja para alcançar metas, garantir a qualidade ou melhorar a performance/produtividade: sem as métricas, ficamos no escuro e no mundo dos “achismos”.

Podemos acreditar que estamos utilizando todo o nosso potencial e gerando várias entregas de valor, quando, na verdade, poderíamos estar extraindo melhores resultados. Podemos, ainda, estar com a sensação de patinar e não sair do lugar, mesmo ao entregar além do esperado.

Trazer a visão de qual está sendo nosso real desempenho com dados empíricos possibilita maior controle sobre o que estamos fazendo e, principalmente, para onde iremos.

Para direcionar nossos esforços àquilo que realmente irá agregar valor e será relevante, é necessário ter visibilidade do que estamos fazendo. É possível supor que as ações estão melhorando nosso processo, mas sempre é preciso avaliar se o que está sendo feito realmente está gerando resultados.

De uma forma simples e objetiva, métricas são números e medidas utilizadas para diagnosticar ou avaliar algo. Sua aplicação é tão versátil que abre inúmeras possibilidades de utilização, como:

• Examinar determinados atributos do sistema/processo/componente;
• Avaliar alcance de metas;
• Embasar tomadas de decisões;
• Acompanhar o andamento do trabalho;
• Identificar oportunidades de melhoria;
• Confirmar ou descartar hipóteses;
• Aferir a qualidade das entregas;
• Ponderar a produtividade.

E a lista segue!

Ou seja, com a visualização das métricas de testes e desenvolvimento, é possível descobrir como está a saúde do processo, diminuir as incertezas para melhores tomadas de decisões e monitorar se tudo está indo pelo caminho certo.

Dados são apenas dados

Muitas equipes de desenvolvimento de software geram uma porção de dados durante seu trabalho, geralmente por ferramentas de gerenciamento de projetos, como Jira, Azure DevOps, Trello, Asana e outros. Já no caso de testes, contam-se comumente com TestLink, ALM, Azure Test Plans, etc. Outras equipes utilizam planilhas, como Excel e Google Sheets.

Os dados mais comuns gerados por equipes de desenvolvimento de software são:

• Datas de início e fim (de tarefas, entregas, etc.);
• Quantidade de entregas/tarefas;
• Bugs/incidentes contados;
• Quantidade de testes;
• Status de execução de testes.

Também é importante ressaltar que deve-se utilizar as métricas com responsabilidade. Acontece que apenas ter esses dados em mãos não trará os potenciais benéficos que eles oferecem.

É preciso utilizá-los de forma coerente e inteligente para que façam sentido.

Ao avaliá-las, é necessário considerar o contexto no qual a equipe/projeto está. Apesar dos dados, existem diversos fatores externos que devem ser considerados ao tirar alguma conclusão.

Métricas e Indicadores

Como foi falado acima, as métricas precisam fazer sentido. Para isso, é fundamental garantir que elas gerem informações relevantes para a equipe e demais stakeholders.

As perguntas que devem ser feitas ao estabelecer as métricas são:

• Para que queremos medir?
• Quais problemas pretendemos resolver?
• O que iremos medir e por quê?
• Qual a relevância das informações geradas para o negócio e a equipe?

Tendo estabelecido essas questões de forma clara, é necessário transformar os dados em pontos mensuráveis, ou seja:

• Quais unidades de medidas utilizar?
• Quais classificações/grupo de dados serão importantes?
• Como iremos atualizar e mantê-los?
• Como iremos gerar um histórico/rastreabilidade dos dados?
• De que modo exibiremos as informações?
• Como estruturar os dados e torná-los comparáveis?

Indicadores

Indicadores representam uma forma padronizada de avaliar as métricas, de modo a qualificar a diferença entre os objetivos e as situações desejadas e a situação atual. 

Utilizamos os indicadores como referência para tomada de decisões, identificação de problemas e priorização e avaliação de esforços para melhorias que gerem valor para o negócio. 

Por isso, os indicadores alinhados com a estratégia da empresa geralmente são compostos por: desempenho, qualidade, performance e produtividade.

Métricas de desenvolvimento de software

Algumas métricas são bem comuns para o acompanhamento tanto da qualidade do que se está produzindo quanto do desempenho da equipe e saúde do processo de desenvolvimento de software. 

Vale lembrar, novamente, que métricas sozinhas são apenas números.

É necessário observá-las com atenção, levando em conta fatores do contexto no qual a equipe está inserida e fazendo o cruzamento das informações para ter uma análise acurada.

Confira alguns exemplos dessas métricas de testes e desenvolvimento.

Começando com as mais tradicionais: as métricas com base nos testes realizados.

Quantidade de testes executados por história, apresentando o status:

Com essa categoria de métrica, conseguimos identificar quais histórias apresentam maior número de casos que passaram e não passaram. Deste modo, é possível focar a análise nas que mais apresentaram problemas e aprofundar a análise por contexto. 

Alguns exemplos de análise por contexto: o tamanho das histórias analisadas; criticidade; tempo em desenvolvimento; escrita dos critérios de aceite e revisões ou testes unitários. 

Podemos analisar essas medidas em todas as etapas de testes, como testes de revisão, testes unitários, testes de usuário, entre outros. Elas não são exclusivas da fase de testes e, portanto, ao expandir sua aplicação, tem-se ainda mais visibilidade do que ocorre durante o processo.

Quantidade de bugs/incidentes por criticidade:

Essa é uma métrica muito importante para saber a predominância de problemas de alta criticidade. 

Se há muitos bugs, por exemplo, considerar apenas a quantidade destes não seria uma forma efetiva de avaliar a qualidade. Isso porque, é possível ter muitos defeitos de criticidade baixa e baixíssima - o que, dependendo da quantidade, até poderia ser aceitável. Valeria efetuar um cruzamento desse dado com outros, como os citados acima.

Outro ponto importante para avaliar é a cadência dos bugs críticos e não-críticos.

Se muitos bugs de criticidade baixa de layout acontecem com frequência, por exemplo, talvez seja interessante repensar como apresentar o design para o desenvolvedor. Logo, verificar a causa raiz e uma possível ação para melhorar esse índice.

Tipos de bugs/incidentes:

Classificar bugs e incidentes por tipo pode agregar mais valor na análise dos dados - como é o caso de bugs de melhorias, que possuem fatores diferentes de bugs funcionais.

Por exemplo, quando o índice de bugs de melhoria é alto, é possível pensar em rever o processo e em envolver os desenvolvedores e testadores na etapa de desenho para ajudar a reduzir a quantidade de melhorias necessárias. 

Já um alto índice de bugs funcionais pode abranger outra categoria de causa raiz, como ambientes diferentes para os quais a função não está preparada, uma complexidade alta que gerou erro técnico, etc.

Então, temos uma necessidade de ação diferente da mencionada anteriormente para bugs de melhoria. 

Medidas por período:

Obter um histórico das métricas não só possibilita uma análise de tendências e variações, mas também ajuda a monitorar se as ações tomadas estão dando resultado ou se algo está influenciando negativamente elas.

Cumulative Flow Diagram (CFD) - Diagrama de fluxo acumulado:

Esta é uma ferramenta muito utilizada em times ágeis, já que auxilia na visualização da saúde do processo e revela dados importantes, como:

• Tempo que levamos para entregar algo;
• Cadência (podemos verificar se é estável ou instável);
• Diferença entre entradas e saídas, o que pode auxiliar na identificação de uma disparidade da capacidade do time em relação ao que é demandado;
• Possíveis gargalos em etapas específicas;
• Sobrecargas;
• Tendências.

Gerenciamento de métricas de testes e desenvolvimento

Levantados os dados, definidas as métricas e a qual objetivo cada uma delas irá atender, deve-se verificá-las com uma certa frequência.

O ideal é estipular de quanto em quanto tempo serão realizadas as avaliações: diariamente; semanalmente; a cada sprint; ao final de cada projeto; a cada mês, etc.

Essa frequência precisa estar alinhada com o time e de acordo com os objetivos traçados, uma vez que as métricas são utilizadas para monitorar e avaliar algo que necessita atingir uma meta/resposta.

As reuniões de review ou booking de métricas são excelentes momentos para realizar uma análise em conjunto, pois dão abertura para questionamentos e discussões construtivas. Da mesma forma, ajudam a esclarecer questões e também identificar possíveis necessidades de ações. 

Algumas vezes, até se identifica que as métricas precisam ser reformuladas ou refinadas para que obtenham mais informações, e a presença do time é essencial para essa análise.

Realizar reuniões com stakeholders para discutir as métricas é muito mais eficaz do que apenas enviar um relatório. Não que este não seja uma boa forma de avaliação, mas, para a diminuição de ruídos na informação, as apresentações e discussões são ainda mais efetivas. 

Objetivos

Logo, as métricas de testes e desenvolvimento podem dar embasamento para a apresentação de resultados da equipe e são de extrema importância para mostrar com dados empíricos o que se tem conquistado.

Em alguns times ágeis, são utilizados painéis que ficam em telas ou quadros, para que todos possam ver os dados a qualquer momento. Este tipo de ferramenta é mais utilizado para dados constantes e de alcance de metas. 

Quando é realizado apenas o envio de relatórios e gráficos, onde não ocorrerão reuniões para os apresentar, analisar ou discutir, é interessante colocar um breve “laudo” do que foi identificado/diagnosticado.

Assim, as partes interessadas podem se situar melhor e ter maior visibilidade do que está ocorrendo.

Outro ponto importante é a comparação com dados de períodos anteriores, para ter evidência do rumo que as coisas estão tomando.

Por fim, são inúmeras as possibilidades de aplicação de métricas de testes e desenvolvimento e cada uma tem sua forma de ser utilizada/monitorada e apresentada - cabe ao time decidir a melhor forma para o seu contexto. 

Desde que se tenha em mente o que se procura de informação, qual é o objetivo e quais ações as métricas irão possibilitar, todas podem ser de grande utilidade. 

Porém, se forem mal definidas ou não tiverem objetivos claros, serão apenas um punhado de números que não agregam ao negócio e ao desenvolvimento da equipe.

Tenha cuidado ao utilizar métricas, pois elas geram comportamentos. E é este o objetivo principal delas: possibilitar ações e tomadas de decisões com base em dados, assim, diminuindo riscos e imprecisões.