Aprendendo com as métricas: otimizando e acompanhando o processo de desenvolvimento de software

Nádia Maciel

Product Manager na SoftDesign | Product Manager | Gerente de Produto

Publicado em 26 de fev. de 2023

Como você mede a eficiência das entregas do time em que trabalha? Seja você pessoa desenvolvedora, gerente de produto ou qualquer outra função em um time de desenvolvimento, tenho certeza que, em algum momento, saber qual a capacidade de entrega de um time e tempo total utilizado para entregar determinada tarefas já foi pauta de discussão por aí.

Vou apresentar como o acompanhamento e ações baseadas nas métricas de Lead Time e Throughput podem aprimorar o processo de desenvolvimento de software.

Antes de abordar as métricas, é fundamental entender que:

estamos avaliando o processo e não uma pessoa específica do time;
os números por si só não têm significado, é importante analisar o contexto completo;
Na maioria dos casos, comparar métricas entre equipes não é relevante;
as métricas não são necessariamente metas.

Por que medir?

Existem diversas razões pelas quais devemos medir a capacidade de entrega do time. Provavelmente, você já foi questionado ou ouviu alguém perguntando:

Quando essa demanda estará pronta?

Quantos itens foram entregues na última sprint?

O que pode estar causando o atraso na entrega?

As métricas nos ajudam a responder a essas perguntas com mais precisão e nos permitem prever alguns problemas, evitando gargalos no processo de desenvolvimento e promovendo a melhoria contínua.

No entanto, não adianta apenas medir sem tomar nenhuma ação diante dos números encontrados. Vamos considerar um exemplo simples do nosso cotidiano:

Se o seu notebook possui um indicador de bateria e você identifica que está próxima de 1%, imediatamente o coloca para carregar, evitando que ele desligue. Somente olhar para o número, não resolve nada, não é mesmo?

Neste artigo, abordaremos duas métricas que podem ajudar equipes de desenvolvimento de software: Lead Time e Throughput.

Antes de começar, é importante falar sobre o conceito de "pronto". Esse conceito pode variar de equipe para equipe, mas em geral é definido como o momento em que um item está finalizado e pronto para ser entregue ao cliente. Para algumas equipes, estar em ambiente de homologação é suficiente, enquanto outras consideram estar em produção como um critério para definir que um item está pronto. Para ambas as métricas, a definição do conceito de pronto é essencial.

Lead Time

Não foi fornecido texto alternativo para esta imagem

O que é?

É o período em que um item de trabalho passa por todas as etapas do processo, desde a entrada da demanda no fluxo até a sua finalização. É importante lembrar que cada equipe pode ter um fluxo diferente e, por isso, o Lead Time pode variar de acordo com as particularidades de cada processo.

Exemplos do dia a dia

Vamos imaginar um exemplo de um time desenvolvimento de software recém-formado, composta por duas pessoas desenvolvedoras e um Product Manager. Nesse time, não há um Analista de Teste — QA. Isso significa que, provavelmente, a responsabilidade pelos testes será compartilhada entre as pessoas desenvolvedoras e de produto.

Vamos dar uma olhada no gráfico acima. No eixo X, podemos ver os diferentes tipos de itens que a equipe trabalhou em paralelo: estórias, bugs e tarefas. Já no eixo Y, temos a quantidade de dias que cada item levou para ser concluído. E a linha laranja que vemos cortando o gráfico representa a média dos últimos cinco Lead Times.

Ao analisar o gráfico, podemos obter algumas informações que nos ajudarão a entender melhor o desempenho do time. Por exemplo:

(i) os primeiros itens trabalhados pela equipe [CORE-28], [CORE-9] e [CORE-14] apresentam uma grande variabilidade e um Lead Time alto. Essa situação é compreensível, considerando que a equipe é nova e ainda está se ajustando às particularidades do processo.

Uma ação que foi tomada para lidar com esse problema foi a escrita de demandas mais detalhadas pela PM do produto, que ajudou a fornecer um contexto mais nítido para as pessoas desenvolvedoras. Esse tipo de ajuste pode ser fundamental para que a equipe consiga entregar com maior eficiência, reduzindo o Lead Time e aumentando a qualidade do trabalho entregue.

(ii) podemos notar que o item [CORE-47] é um caso extremo, com um Lead Time muito alto em relação aos demais itens. O time, ao analisar o motivo para essa variação, identificou que a tarefa ficou parada por um longo período durante os testes.

Uma das razões para essa paralisação foi a falta de um Engenheiro de Qualidade (QA) na equipe, o que fazia com que todas as atividades relacionadas a testes fossem realizadas pela Product Manager. Além disso, houve um período em que a PM ficou ausente por alguns dias, o que pode ter impactado ainda mais o tempo necessário para finalizar o item.

Para lidar com esse problema, o time decidiu criar um calendário compartilhado para alinhar os próximos eventos e ausências. Essa ação pode ajudar a garantir que todos os membros do time estejam cientes das ausências de outros membros e possam se preparar para cobrir as tarefas em caso de necessidade. Dessa forma, o time pode evitar atrasos desnecessários e garantir que o processo de desenvolvimento seja o mais eficiente possível.

(iii) podemos concluir que somente um item não foi finalizado dentro do período da sprint, que teve duração de 10 dias corridos. Esse é um resultado muito positivo para o time, indicando que ele conseguiu entregar as demandas dentro do prazo estabelecido e manter um ritmo constante de trabalho ao longo da sprint.

É importante lembrar que algumas situações podem ter influenciado nas variações do Lead Time no periodo analisado. Dentre essas situações, podemos citar:

Throughput

O que é?

Representa a quantidade de itens de trabalho que foram concluídos em um determinado período de tempo, como por exemplo, em uma sprint (2 semanas).

Exemplos do dia a dia

Uma forma muito útil de visualizar o Throughput é por meio de um gráfico de barras. Nesse tipo de gráfico, o eixo X representa o período de tempo que está sendo avaliado, como por exemplo, por mês, por sprint, por semana, etc. Já o eixo Y representa a quantidade de itens concluídos pela equipe em cada período.

Ao analisarmos o gráfico, podemos obter alguns insights:

(i) nas semanas [1] e [2], o time não conseguiu entregar nenhuma história, tarefa ou bug. No entanto, o time compreendeu que essas foram duas semanas de aprendizado da nova tecnologia, da arquitetura e do negócio.

É muito comum que times que estejam trabalhando com uma nova tecnologia ou com um novo negócio precisem de um período de adaptação para se familiarizar com as novas ferramentas e processos.

(ii) nas semanas [3] a [7], o time se questionou sobre o motivo de tantos bugs estarem sendo entregues. Como possuiam algumas aplicações legadas, isso gerou alguns problemas. Entendemos que isso poderia estar impossibilitando a equipe de trabalhar em novas funcionalidades.

(iii) Nas semanas [3] a [7], o time percebeu que havia entregue apenas uma estória. Então, surgiu a seguinte pergunta: estamos realmente gerando valor para a nossa pessoas usuária? A equipe notou que havia confusão de conceito entre 'estória de usuário' e 'tarefa', o que acabou resultando na criação de tarefas em vez de estórias.

Algumas situações que podem causar variações no Throughput ao longo do tempo são:

Mudanças na composição do time;
Aumento do número de entregas à medida que o final do quarter se aproxima;
Gargalos em alguma etapa do processo;
Ausência de membros do time por férias ou outros motivos;
Muitos bugs urgentes surgindo e demandando prioridade.

Conclusão

Para garantir a eficiência do time e melhorar o processo de desenvolvimento de software, o uso de métricas é essencial. Com elas, podemos prever resultados, tornar as atividades mais visíveis e identificar oportunidades de melhoria.

Deixar todas as informações disponíveis e visíveis para o time é fundamental. É importante que todos saibam ler esses gráficos e, se alguém do seu time tiver dúvidas, minha cara pessoa leitora, pode mostrar este post. :)

Para facilitar a interpretação ao longo do tempo, é importante fazer anotações sempre que houver uma alteração na composição do time ou alguma discrepância no gráfico, registrando fatores como ausência por motivos diversos.

Se notar alguma variação brusca em alguma métrica, tanto para cima quanto para baixo, é importante parar e analisar o que pode ter causado essa mudança. E não adianta analisar cada métrica separadamente! É sempre bom analisar as métricas em conjunto e com o contexto do seu time. Isso ajuda a ter uma visão mais completa do que está acontecendo e a tomar decisões mais acertadas.