A qualidade do processo é tão importante quanto a qualidade do produto. Chegamos a essa e outras conclusões quando falamos sobre métricas ágeis em nosso primeiro conteúdo sobre gerenciamento. Nele, esclarecemos a importância de tomar decisões sempre baseando-se em dados gerados pelo processo de desenvolvimento.

Aumentar o ritmo, contratar novos colaboradores, enxugar escopo ou pivotar a abordagem de construção do produto são apenas alguns direcionamentos que podem ser feitos mais assertivamente ao analisar tendências, padrões e a cadência da entrega e qualidade de atividades. Todas essas ferramentas, por padrão, ficam agregadas em um relatório de acompanhamento de métricas.

Organizando as atividades

Antes de efetivamente construirmos as métricas ágeis é necessário ter uma fonte rica e estável de dados a serem utilizados em nosso relatório. Estes dados são sempre baseados no tempo e no fluxo de trabalho de cada uma das atividade relacionadas com o processo que estamos medindo.

Para fazer isso, precisamos  rastrear o tempo de permanência de cada entrega em diferentes fases de uma atividade. As etapas mais utilizadas para mapear o estado das atividades são: em backlog, priorizada, em desenvolvimento, em validação e finalizada. A metodologia kanban facilita esse tipo de análise, uma vez que é possível visualmente analisar como o andam as tasks do projeto.

Buscando uma fonte dos dados que seja estável, como é exigido para que as métricas sejam coerentes com o andamento do projeto, é preciso que todos os envolvidos respeitem este fluxo de atividades. Sistemas como o Pipefy fornecem um ambiente de mais controle para aplicação desse tipo de fluxo, permitindo com que as etapas tenham regras específicas. Inclusive, utilizamos essa plataforma aqui na ateliware. A seguir, apresentamos como exemplo um fluxo de trabalho utilizando o Pipefy.

Relatório de métricas ágeis: acompanhando resultados

Responsável por agregar os resultados das medições, bem como todos os objetos e ferramentas de análise gerados por estes retornos, o relatório de métricas é construído a partir de uma estrutura e uma rotina acordada entre os membros do projeto.

A frequência dessa rotina depende, principalmente, da saúde atual do projeto: se a qualidade de entrega está abaixo da média, com altos índices de retrabalho e problemas nas etapas de validação, considera-se como boa prática a construção e apresentação semanal das métricas geradas. Por outro lado, quando o andamento do projeto mostra-se estável, reuniões quinzenais ou até mensais podem ser também efetivas.

O relatório de métricas, normalmente, passa por um processo evolutivo até atingir seus objetivos. No início do projeto é normal que este seja inconsistente e pareça não estar cumprindo seu papel nas tomadas de decisões. Entretanto, à medida que o projeto amadurece, os dados começam a fazer sentido. Com isso, é possível encontrar situações em que, sem métricas de projeto, alguns dos problemas identificados poderiam ter proporções catastróficas.

Empresas de engenharia de software dos mais diferentes tamanhos e nichos passam por esse tipo de problema.  O motivo? Nem sempre um relatório de métricas antigo pode ser replicado para novos projetos. Cada situação deve ser tratada isoladamente, por mais que a experiência adquirida com sua implementação diminua esse tempo de aprendizagem e amadurecimento.

Mesmo assim, o pontapé inicial da implementação de métricas ágeis de software acontece através de um template que, aos poucos, vai sendo melhorado. Normalmente, esse ‘esqueleto’ segue a seguinte estrutura:

• Farol do projeto comentado, situando o leitor sobre o status, saúde e progresso do projeto no último intervalo de medição;

• Gráficos, tabelas e quadros de detalhamento, ilustrando o que foi medido através de objetos de análise e tendência;

• Plano de ação e conclusão, sintetizando os próximos passos até a próxima medição e indicando a necessidade de ações corretivas ou preventivas.

Abordaremos, a seguir, cada um desses pontos no detalhe, tendo como objetivo facilitar a implementação de um processo de medição e apresentação de resultados em relatório.

Farol do projeto

O objetivo desta seção do relatório de métricas é ser bem direto: sumarizar como anda o projeto. Com transparência, informar aos interessados se existe algum ponto de atenção, qual o progresso das atividades e levantar o status de cada uma das frentes que estão sendo abordadas na construção do produto.

O uso de uma referência de cores (que origina o ‘farol’ do projeto) é bastante comum. A cor verde apresenta uma situação estável, com um ritmo saudável e de acordo com a progressão planejada. Quando identifica-se pontos a serem observados com mais atenção, muda-se o farol para a cor amarela. Em momentos mais críticos, que exigem uma mobilização de toda a equipe, podendo comprometer a viabilidade do projeto, pode-se utilizar o farol vermelho.

Este tipo de padrão visual ajuda a identificar a situação macro do projeto. Entretanto, é bastante importante que essa situação seja explicada e comentada, justificando eventuais mudanças de farol.

É importante salientar que existe uma possibilidade deste relatório acabar sendo consumido por pessoas sem tanto conhecimento técnico ou com entendimento mais raso sobre o projeto. Normalmente, esse tipo de leitor vai se ater mais ao farol de projeto, portanto, essa seção deve ser apresentada em um tom menos formal e mais voltado à transmitir informações independentemente do nível de instrução do leitor.

Gráficos, tabelas e quadros

Em um nível mais ‘macro’ o progresso da construção do produto para análises mais pontuais, técnicas e que mais efetivamente ajudam em tomadas de decisão, surge a necessidade de uma seção de gráficos, tabelas e quadros.

Por padrão, cada componente acompanha seu título, seu conteúdo e uma breve explicação dos pontos de atenção que o elemento gráfico aponta. Isso é importante para que haja uma interpretação mais profunda mesmo por leitores que não dominem tanto técnicas de análises de dados. O responsável por construir estes relatórios deve ter em mente que nem tudo é claro para olhos mais leigos e menos ‘treinados’.

Os componentes que mais são aproveitados para tomadas de decisão estão listados a seguir, e serão brevemente explicados e exemplificados.

Gráfico de Lead time

Análise do lead time define-se pela identificação do período entre o início de uma atividade até seu término, buscando entender quanto tempo cada atividade (ou micro-entrega) está levando para ser disponibilizada para o cliente validar.

Tendo em mãos a data/hora de início e término de cada atividade, pode-se traçar um gráfico que dita o ritmo de trabalho da equipe, permitindo inclusive que, baseado no lead time, possam ser feitas estimativas de outras entregas ou análises referentes à demandas infladas que, sem ações pontuais, podem não ser entregues dentro de um prazo específico.

O gráfico acima, por exemplo, consegue transmitir quanto tempo leva para cada atividade ser concluída, traçando inclusive uma média móvel para análise de tendência de entrega. A partir dele, podemos tomar decisões como: incluir ou remover um colaborador do projeto, identificar porque  a equipe não está rendendo tanto, entre outras análises. O dimensionamento e priorização das atividades abordadas pode ser revisto a partir deste gráfico.

Lead time breakdown

O lead time breakdown busca detalhar, para cada atividade a proporção de tempo gasto em cada uma das etapas de construção. Esta análise é útil, principalmente, quando busca-se identificar em quais são as principais razões para determinada atividade estar demorando para ser entregue.

O gráfico acima permite que seja monitorado, por exemplo, quanto tempo está sendo gasto detalhando uma atividade em comparação com seu efetivo desenvolvimento.

Gráfico de Throughput

O gráfico de throughput mostra, entre períodos de tempo, quantas funcionalidades foram entregues. A partir dela, busca-se manter o rastreamento de um ritmo saudável de entrega de atividades, ao mesmo tempo que possibilita que sejam analisados os riscos de, por exemplo, dar férias de um mês a um membro da equipe.

O gráfico acima permite fazer a análise de ritmo de entrega, ao mesmo tempo que permite que sejam adicionados elementos estatísticos para refinar a análise e obter outros indicativos, como média móvel, desvio padrão, variância e linhas de tendência.

Diagrama de fluxo cumulativo (CFD)

A análise do diagrama de fluxo cumulativo busca rastrear a saúde do projeto. Uma vez que ele é composto pela distribuição dos status das atividades semana a semana, é possível observar quais os principais gargalos de acordo com as proporções entre os estados das entregas.

O exemplo acima mostra como as funcionalidades definidas são consumidas a cada iteração de medição. Além disso, pode-se observar aumento de funcionalidades mapeadas enquanto o projeto progride. Esse tipo de comportamento deve sempre ser rastreado de perto para que haja uma proporção saudável entre as fases.

Estimativa de Monte Carlo

O método de Monte Carlo utiliza estimativas estatísticas para definir a probabilidade de entrega de um projeto (ou parte de um projeto, como por exemplo uma milestone ou entrega parcial específica). Para aplicá-lo em um ambiente monitorado por kanban, por exemplo, definem-se tempos médios de consumo de cards, a quantidade de cards totais e o grau de incerteza destas definições.

Na estimativa acima, por exemplo, entende-se que existe 80% de chance do projeto ser concluído em seu 90º dia de construção. Este acompanhamento pode ser feito a cada iteração, analisando se a estimativa de entrega aumenta ou diminui à medida que a janela de medição muda.

Caso um atraso esteja sendo identificado, decisões podem ser tomadas para que a produtividade da equipe aumente, como eventuais contratações, remanejamentos de colaboradores ou re-alinhamento de expectativas.

Plano de ação

Baseado no resultado tanto do farol do projeto quanto das informações mais detalhadas, eventualmente serão identificadas ações corretivas ou preventivas para manutenção da saúde do projeto. Essas ações, se rastreadas ou já implementadas, podem ser documentadas em uma seção do relatório de plano de ação.

Por exemplo, caso uma consultoria de uma tecnologia específica tenha sido contratada para resolver problemas pontuais, pode-se rastrear o efeito que ela teve a partir de determinada data, uma vez que está registrado o momento de sua contratação.

Cultura

É impossível concluir essa discussão sem salientar que todos os envolvidos são peças-chave para que o hábito de rastreamento de métricas seja efetivo. É necessário que forme-se uma cultura voltada à tomada de decisão não mais baseada em achismos.

Com os dados gerados, não utilizá-los pode ser resultado de um problema de cultura dos colaboradores e stakeholders. Pode existir, em algumas empresas, uma resistência à essa mudança de abordagem de novos direcionamentos. Mesmo assim, vale a insistência. Sabe-se que o uso de métricas é uma prática que só gera mais assertividade em decisões, mais índice de sucesso do projeto, aumento na viabilidade da construção da solução e menores gastos com retrabalhos.

Esta postagem foi uma continuação de um primeiro artigo sobre a importância de métricas no desenvolvimento de software. Caso você não tenha lido, aqui você pode ter um entendimento de que forma é possível ‘virar o jogo’ quando o assunto é sucesso e qualidade de entrega de soluções digitais.