Qual a importância de mensurar projetos ágeis? Métricas e indicadores para implementar no seu time!

Se você chegou nesse artigo é porque já sabe que a metodologia ágil é um conjunto de ações, valores e princípios que facilitam a tomada de decisões e tornam as estratégias mais adaptáveis e eficientes além de auxiliarem na entrega de valor ao cliente – seja ele interno ou externo. Dentre as metodologias mais comuns estão o Kanban, Scrum, Lean, e muitas outras dos quais consiste o Manifesto Ágil.

Porém, talvez você não saiba que aqui na AMcom temos nosso próprio Guia Ágil. Isso quer dizer que os nossos times não trabalham apenas com uma ou outra metodologia durante um projeto, mas sim que cada projeto tem um apanhado de metodologias e indicadores que fazem sentido para aquele time em específico, e que ainda podem variar de tempos em tempos. E assim também foi conosco: criamos nosso próprio fluxo e indicadores de gestão para nos organizarmos.

Ainda assim, é importante lembrar que, cada vez mais, as metodologias ágeis vêm sendo usadas em diversas áreas e setores, para além das equipes de TI. Assim, as práticas ágeis buscam compreender times multidisciplinares, experimentação de projetos, decisões baseadas em dados, ciclos curtos de desenvolvimento e muito trabalho em rede e cooperação.  E uma vez que os processos começam a rodar, fica nítido para as equipes os ganhos e benefícios.

Mas de forma geral, ao iniciarmos um novo projeto ágil, é comum nos depararmos com algumas dúvidas e questionarmos se o que estamos fazendo está correto. E é sobre isso que queremos conversar hoje: a mensuração dos times e/ou projetos ágeis.

Qual a importância de mensurar projetos ágeis?

É inquestionável que trabalhar com ágil em projetos de software traz ganhos significativos para o time e para o cliente. Mas esses ganhos só podem ser percebidos quando esse mesmo projeto é bem mensurado.

Afinal, é essencial sabermos se:

• Estamos utilizando as ferramentas de apoio da forma correta?
• Estamos conseguindo extrair informações dessas ferramentas?
• Estamos entregando valor ao cliente?
• Estamos no prazo do projeto?
• Será que estamos realmente trabalhando com agilidade?

Poderíamos listar várias outras dúvidas sobre a condução do projeto, mas o intuito aqui é justamente mostrar porque é necessário medir corretamente as práticas.

Inicialmente, é possível dizer que ao se aderir às métricas e indicadores, essas vão proporcionar uma leitura mais clara do andamento do projeto para todo o time! Mais do que isso, será possível analisar e fazer uma rápida verificação de resultados, conforme as ações aplicadas.

Métricas e indicadores que podem te ajudar:

Logicamente, existem diversas métricas, mas veremos aqui algumas das mais praticadas no mercado.

1. Burndown da sprint

Para equipes que trabalham com o framework scrum, este é um dos indicadores que melhor ajuda o gerenciamento do backlog da Sprint, que é de responsabilidade do time de desenvolvimento. É muito simples de se construir e pode ser montado em um excel, caso a equipe não tenha uma ferramenta que o forneça, como por exemplo o Azure Devops.

A cada planejamento de sprint, o time deve determinar o quanto de trabalho assumirá para o período. Esse “quanto”pode ser em horas ou em story points. Com essa informação decida e com base na quantidade de dias úteis, teremos um valor a ser entregue diariamente. Com isso, esse valor deverá ser descontado a cada dia de interação, provisionando o valor previsto.

Vejamos um exemplo:

Período da sprint: 20 dias úteis

Quantidade total de story points (sprint): 28 pontos

Meta diária: 1,4 pontos

Seguindo o exemplo, temos o gráfico abaixo. A linha azul demonstra o total de pontos sendo descontados até o último dia da Sprint (1,4 pontos), que ficará com 0 (zero). Ou seja, se o time entrega sua meta diária consequentemente entregará os pontos previstos. Além disso, a linha vermelha demonstra o valor entregue (real) pelo time. Com isso o total de pontos desconta apenas o que realmente foi entregue.

No gráfico, vemos que o time não entregou sua meta diária no início da sprint, mas que se recuperou nos dias seguintes, alcançando a previsão. O time se manteve abaixo da meta em alguns dias, mas no fim, conseguiu concluir o seu objetivo.

A dica aqui é ter um acompanhamento diário feito pelo time, com a reflexão sobre o ocorreu no dia anterior para não se ter atingido a meta. Mais importante ainda é entender o que o time pode fazer para recuperá-la.

2. Burndown épico e release

O indicador de burndown de épicos e releases, funciona simular ao burndown da sprint. A diferença aqui é que não temos uma média para épico ou release. O que temos é, quantos story points ou horas:

• compõe o épico ou release;
• foram entregues;
• faltam para a entrega.

O objetivo deste indicador é monitorar o quanto foi entregue do projeto. Vejamos um exemplo simples deste indicador:

A utilização deste indicador é muito comum em uma versão por Sprint. Ainda assim, quando utilizado neste contexto perde a visão de entrega de versões e demonstra mais a entrega por interações. O uso pode ser mesclado com visão de projeção, afinal o time já estará coletando informações de quanto entrega a cada sprint e com isso consegue provisionar quando finalizará o projeto (caso não seja adicionado escopo), como vemos no exemplo abaixo.

3. Burnup projeto

Assim como o burndown, este indicador trabalha demonstrando um período de entregas do time de desenvolvimento. Ambos podem representar uma sprint ou um período do projeto. Porém como dito anteriormente, o burndown é muito utilizado para a visualização de esforço necessário para a entrega da Sprint, enquanto o burnup vai demonstrar o quanto foi entregue do escopo total.

A construção deste gráfico é extremamente simples. O prazo planejado é representado no eixo X e as entregas representadas no eito Y, que exibe em que ponto a equipe está ao longo da sprint/projeto, revelando o progresso na linha ascendente, em direção ao ponto final.

Neste gráfico pode-se ter uma visualização da Sprint. Ainda assim, seu uso mais comum é na visualização do projeto, podendo ser uma visão diária ou por aIterações de sprints.

Assim, a linha azul representa o escopo total, enquanto a linha verde demonstra a entrega (pontos ou horas) realizada pelo time ao longo do tempo. Uma linha laranja foi traçada ao longo do tempo, representando uma média de entrega diária (total de pontos ou horas / total de dias úteis). Com isso a leitura do gráfico fica muito simples e fácil de entender que o time está abaixo ou acima do planejado quando se fala de entrega.

Obs.: É comum, em projetos ágeis, que a linha azul sofra alterações ao decorrer do tempo (para cima ou para baixo), indicando a adição ou remoção de escopo.

4. Velocidade da equipe

Quando trabalhamos com sprints, o nosso maior desejo é entregar o que planejamos. E depois de algumas sprints entregues conforme o planejado, questionamentos sobre a capacidade de entrega podem surgir.Isso porque é muito comum que times ágeis comecem a puxar mais demandas durante as sprints.

À medida que o projeto avança, as entregas sofrem alteração de quantidade, devido ao escopo, complexidade, impedimentos e tamanho do time. Dessa forma, quando falamos em velocidade, nos referimos a quantidade média de trabalho que uma equipe pode concluir em uma sprint, seja medida em story points ou horas.

Vejamos um exemplo abaixo:

Podemos ver além do quanto a equipe vem entregando, o quanto do trabalho entregue foi homologado pelo cliente, ou seja, realmente completo.

Após a leitura a cada iteração, o time deve refletir sobre os números obtidos. Um bom momento é a reunião de retrospectiva. Vejamos alguns questionamentos que podem agregar com base na leitura deste gráfico:

• Existe uma pressão inerente ao negócio que estica a equipe além de seus limites?
• Houve algum desafio imprevisto, que não consideramos durante a estimativa?
• Estamos sendo otimistas demais ao prever a sprint?
• Houve algum fator que justifique a baixa ou alta entrega extrema?

Assim, a velocidade média será um guia para o time planejar as próximas sprints. Para rodar várias sprints com assertividade, recomenda-se então, descartar a menor e a maior entrega.

5. Gráficos de controle

Os gráficos de controle podem auxiliar de diversas formas., mas sempre conforme o que se precisa monitorar. O mais comum na sua utilização é a identificação de um padrão ao longo do tempo, seja a quantidade, tamanho das entregas ou o monitoramento da aplicação após a liberação da versão.

Equipes ágeis com ciclos mais curtos terão um resultado maior ao tempo que equipes com ciclos consistentes terão uma entrega de trabalho previsível.

Diferente do modelo acima que demonstra um volume ao longo do tempo, podemos também encontrar gráficos de controle para avaliar indicadores que possuem limites, tanto para um valor máximo quanto para mínimo. Veja o exemplo:

Aqui podemos demonstrar o % entregue x planejado com um % médio de assertividade no planejamento, atingindo altos ou baixos valores. Isso significa estar fora do limite superior ou do limite inferior, demonstrando uma anomalia do projeto.

Lembrando que a métrica não é uma caça às bruxas, mas sim usada para identificar as causas dos números relatados e corrigi-los! Assim, podemos encontrar e entender uma falha na execução ou planejamento do processo para poder repará-la.

6. Diagrama de fluxo cumulativo

O diagrama de fluxo cumulativo (CFD) é uma das mais avançadas análises para a gestão Lean. Ele fornece uma visualização concisa das três métricas mais importantes para o seu fluxo. São elas:

• Tempo de ciclo
• Taxa de transferência
• Trabalho em progresso

É super comum o time não compreender este gráfico, mas não há com o que se preocupar! A regra básica do CDF é identificar os gargalos do processo para que possamos atacá-los e gerar mais fluidez no processo.

Veja como é simples: seu objetivo é demonstrar a estabilidade do fluxo ao longo do tempo. Ele fornece dados quantitativos e qualitativos sobre o projeto e pode visualizar quantidade enorme de dados.

Exemplo 1

O gráfico mostra que as faixas estão ocorrendo em paralelo, ou seja, o projeto está saudável. O que o time recebe, ele desenvolve e homologa, sem gargalos.

Exemplo 2

Já neste exemplo, vemos uma faixa rapidamente se estreitando, indicando que a transferência do estágio que ela representa é maior do que a taxa de entrada. Este é um sinal de que você possui mais capacidade do que precisa neste estágio.

Isso indica que nesse momento é possível realocar os esforços para otimizar o fluxo. Podemos colocar como exemplo, que o PO não está incluindo muitas estórias no projeto e que você possui mais desenvolvedores do que precisa para dar vazão.

Exemplo 3

Já neste gráfico, podemos ver o inverso do exemplo 2. Aqui as faixas estão se alargando no decorrer do tempo. Neste caso nota-se que o time tem recebido demandas demasiadas e que não consegue dar vazão nas que estão em andamento, criando um gargalo.

Este é um problema comum, que geralmente é causado por multitarefas e outras atividades que não geram valor.

7. Throughput

O throughput refere-se ao número de unidades que podemos processar em um período tempo, seja por dia, semana ou mês. O uso comum de sua utilização é a análise da vazão de estórias diárias/semanais ou por sprint em um time de desenvolvimento.

Uma observação importante a respeito o throughput é que a métrica difere da de velocidade do time, utilizado no Scrum. Geralmente, analisamos este indicador para obter algumas respostas aos questionamentos abaixo:

• Quantos itens de trabalho a equipe entrega por semana?
• O time está criando uma tendência crescente de entrega?
• Algum fator tem bloqueado a capacidade de entrega da equipe?

Vamos ao exemplo:

Como pode ser visto, nas primeiras iterações do time, não houve entrega. Percebe-se também que após certo período o time iniciou uma entrega em ascendência até encontrar uma constante.

Caso o throughput esteja em linha crescente, a equipe está aumentando o número de itens entregues em uma semana. Se a tendência é de queda, pode colocar em risco o prazo de entrega de um projeto. Um limite inferior pode ser estipulado como forma de fornecer um indicador de quantas ações corretivas podem ser necessárias.

Mas afinal, qual indicador você deve usar?

Costumamos brincar que indicador bom é aquele que aponta as falhas. Isso porque é por meio dele que podemos identificar problemas e corrigi-los a tempo. Caso contrário teremos de arcar com as consequências de não termos monitorado o projeto ao fim dele. Vale comentar que você não precisa iniciar com todas as métricas de uma vez só. Ou seja, analise com calma as informações que o seu projeto precisa, mapeie essas necessidades e aí sim inicie a mensuração.

Inicialmente, o tema pode parecer extenso, mas ao se realizar a leitura das informações rotineiramente, os benefícios serão percebidos.

Jeito AMcom de fazer agile

Como falamos anteriormente, aqui na AMcom já trabalhamos com as metodologias ágeis há algum tempo, uma vez que identificamos que são nessas práticas que encontramos o caminho para a produtividade das nossas equipes, além de todos os outros benefícios que apresentamos anteriormente.

E assim, ao passar do tempo, acabamos criando a nossa própria forma de “fazer agile“, onde estruturamos um processo exclusivo, baseado em diversas práticas do manifesto ágil e também na nossa experiência com a metodologia e com as suas métricas. E quem já trabalhou conosco sabe como é a experiência.

Inclusive, um grande cliente do setor de energia passou por um processo de mudança no modelo de gestão de um dos projetos e, contando com o uso de práticas ágeis, obteve 100% de aproveitamento, entregando o dobro de funcionalidades, em menos tempo do que o planejado. Leia mais sobre aqui!

Mas o que queremos dizer com o nosso próprio jeito de fazer agile?  

Bom, primeiramente isso significa que os nossos times não trabalham apenas com uma ou outra metodologia durante um projeto, mas sim que cada projeto tem um apanhado de metodologias e indicadores que fazem sentido para aquele time em específico (e que ainda podem variar de tempos em tempos).

Além disso, a cada nova squad novos fluxos e indicadores de gestão são criados, especificamente para a organização do projeto. E para nós, é apenas por meio dessas definições específicas de cada time que se torna possível atingir os benefícios que citamos anteriormente.

Nosso Framework 

E é claro que derivado da nossa forma de trabalhar com as metodologias ágeis também surgiu o nosso próprio framework, que se baseia em 5 etapas principais. Veja nesse artigo!

No mais, nosso time de especialistas em Ágil também estão à disposição para colaborar nesse processo, que realmente muda nosso jeito de fazer entregas e trabalhar como time. 

Esperamos que você tenha aproveitado a leitura! Conte conosco para colocar em prática as metodologias ágeis na sua empresa.