Métricas ágeis: quais são as principais e como acompanhar?

Métricas ágeis: quais são as principais e como acompanhar?

Não há dúvidas de que para medir o progresso de um time ágil é necessário utilizar métricas tão ágeis quanto. Isso porque as métricas ágeis facilitam o acompanhamento da evolução de um projeto. S o progresso dos projetos, não conseguimos tomar decisões corretas e ter ações claras e estratégicas. Não é uma ferramenta de penalização individual, mas sim da capacidade de um time para entender mais a fundo 

Ou como diria o estatístico norte-americano William Deming: “não se gerencia o que não se mede, não se mede o que não se define, não se define o que não se entende e, por isso, não há sucesso no que não se gerencia”

Mas, antes de se preocupar com a estatística é, preciso saber quais perguntas queremos responder usando as métricas ágeis.Para te ajudar nesta jornada, o time Orbia separou algumas métricas que são voltadas para entrega de softwares, independentemente do time usar o Scrum ou Kanban. Assim, será possível medir desde o desenvolvimento até o lançamento final do produto.

Por que usar métricas ágeis?

As métricas ágeis ajudam os times a mapearem um projeto e detectarem, mais facilmente, problemas que possam aparecer durante o desenvolvimento de um determinado produto. Afinal, com os números certos em mãos é possível fazer análises mais completas, encontrar respostas com mais agilidade e, é claro, ganhar tempo de trabalho. Tudo isso resulta em um crescimento mais sustentável, rápido e eficiente. 

Nesse sentido, as métricas ágeis:

  • Entregam valores aos clientes;
  • Deixam mais transparentes os processos;
  • Incentivam a cooperação e a colaboração do time;
  • Respondem perguntas de forma eficiente, com dados qualitativos e quantitativos;
  • Favorecem o surgimento de insights;
  • E são essenciais para um crescimento efetivo.

Sprint Burndown e Burnup

A Sprint Burndown e a Sprint Burnup são as principais métricas ágeis utilizadas, pelas metodologias Scrum e Kanban e são responsáveis por acompanhar cada ciclo de desenvolvimento de um projeto, desde o andamento até a conclusão. Além disso, essas métricas permitem analisar o nível de maturidade de uma determinada equipe. 

O Burndown, por exemplo, é o gráfico utilizado pelas equipes de Scrum para representar o progresso diário de um desenvolvimento. Ou seja, a cada dia de trabalho finalizado, o gráfico é atualizado e passa a apresentar uma comparação entre o trabalho que já foi entregue e o trabalho total planejado. Já o Burnup, assim como o Burndown, apresenta um cronograma com as entregas planejadas. No entanto, ele mostra em que ponto a equipe está ao longo do sprint, revelando assim quanto progresso já foi feito.

Nesse sentido,  tanto o Burndown quanto o Burnup ajudam os gestores a acompanharem o andamento das entregas e o desenvolvimento do time, usando parâmetros como agilidade, cumprimento dos prazos e qualidade de execução. Facilitando também a percepção de eventuais atrasos ou implicações no cronograma final.

O gráfico de Burndown, por exemplo, é representado por duas linhas. A primeira é a linha planejada que representa a demanda completa de trabalho. Ela começa no topo do projeto e vai até onde fica a previsão de conclusão do mesmo. Já a segunda, é a linha real, que revela como a equipe lidou com o desenvolvimento e os prazos da demanda

Fonte: Artia

 Geralmente, a linha real representa uma dessas três possibilidades:
  • Linha sem fim: nunca alcança o ponto zero, o que significa que o trabalho entregue pela equipe passou bem longe do que foi planejado no cronograma. Isso mostra também que o time não seguiu o planejamento (seja por desunião, sobrecarga ou expectativas irreais de trabalho). Dessa forma, é preciso implementar mudanças.
  • Linha instável: chega ao ponto zero e, portanto, cumpre o prazo. Mas também apresenta uma instabilidade em relação ao que foi planejado, fazendo uma curva pra longe da linha ideal. Isso pode indicar que alguns membros da equipe não conseguirão cumprir o prazo ou que as estimativas não foram atualizadas. 
  • Linha real-ideal: apesar de não ter a mesma precisão da linha ideal ou planejada, a realidade segue com pequenas variações, mas priorizando sempre o cumprimento das demandas. Representando assim um bom desempenho de métricas ágeis.

 

Fonte: Artia

No gráfico de burnup, por outro lado, a linha ideal representa aquilo que realmente foi desempenhado pela equipe. Mas também pode ser visualizada de três formas:

  • A linha que não chega no fim da demanda e nem no fim do cronograma;
  • A que chega, mas não segue o planejamento idealizado;
  • A real-ideal que segue o planejamento dentro do prazo estipulado.

Nesse sentido, o gráfico de burnup, diferentemente do gráfico de burndown, deixa o ponto final no alto e busca alcançá-lo através do cumprimentos de etapas. Assim, o gestor pode visualizar o que falta ou em que etapa sua equipe se encontra.

Velocidade

É uma das métricas mais básicas para avaliar o desempenho de um time ágil. Afinal de contas, a velocidade serve, basicamente, para mensurar a qualidade e a rapidez nas entregas. Além disso, através da mensuração de velocidade, é possível identificar em quais os momentos o projeto precisará acelerar ou diminuir seus passos. Aproximando, assim, os resultados obtidos com o ritmo e a capacidade real da equipe de desenvolvimento.

Nesse sentido, ao utilizar a velocidade como uma de suas métricas ágeis, o gerente de projeto pode determinar a aceleração com que sua equipe trabalhará em backlogs. Por exemplo, imagine que o gestor quer atingir 800 pontos de história no backlog. Por intermédio da métrica de velocidade é possível perceber que a equipe, geralmente, alcança  40 pontos de história em cada interação. Assim, o gestor do projeto pode prever que a equipe precisará de, mais ou menos, 20 interações para alcançar o resultado esperado.

Mas atenção: alguns fatores não devem ser esquecidos ao mensurar a velocidade. s ferramentas e os equipamentos disponibilizados para a equipe, bem como o grau de entrosamento e de qualificação dos membros envolvidos neste time.

 

Diagrama de fluxo cumulativo

A função deste diagrama é ajudar a identificar algumas brechas existentes durante o desenvolvimento de um produto, garantindo assim mais estabilidade e eficiência para equipe. Para isso, ele analisa algumas métricas ágeis, como a quantidade de trabalho em andamento, a taxa de transferência e também a duração de cada ciclo do projeto.

No diagrama abaixo, por exemplo, o número de problemas está no eixo Y e o tempo está no eixo X, além disso, as cores diferentes indicam as deficiências e os gargalos encontrados no fluxo de trabalho. Nesse sentido, todo o diagrama deve parecer suave da esquerda para a direita. Se houver alguma lacuna em qualquer cor, isso significa que há gargalos e escassez. Então, é preciso sempre suavizar as faixas de cores no gráfico.

Fonte: FM2S

Assim, os gestores podem visualizar quais etapas estão demandando mais tempo para serem entregues, bem como se a taxa de saída está sendo maior ou menor do que taxa de entrada. O que pode dizer se a equipe está ou não sobrecarregada. 

Lead Time e Cycle Time

De forma resumida, o lead time é o nome que se dá ao tempo que uma atividade tem para ser entregue, ou seja, o seu tempo total de vida. O cycle time, por outro lado, diz respeito ao tempo que essa atividade, realmente, levou para ser produzida. 

Juntas, essas duas métricas ágeis, ajudam a identificar grandes variações de tempo, bem como a melhorar os projetos de desenvolvimento até que eles atinjam uma versão ideal. Isso porque elas permitem que o time realize ajustes durante todo processo. 

Com o Lead Time, podemos analisar o tempo total de uma tarefa, desde sua criação até sua finalização. Nesse sentido, em um cenário em que os usuários necessitam de atualizações constantes, é importante temos um Lead Time baixo, pois assim saberemos que estamos entregando valores ao cliente em um período curto de tempo.

Já o Cycle Time é o momento em que a tarefa se encontra em “progresso” até o momento em que ela entra em seu estado final. Assim, podemos analisar o período em que a tarefa foi realmente trabalhada, desde o momento que alguém começou modificá-la.

Por exemplo, digamos que o Lead Time médio de um projeto seja: 2 dias, 20 horas e 14 minutos. E o Cycle Time seja: 1 dia, 9 horas e 33 minutos

Quando falamos em métricas ágeis, podemos perceber que, durante metade do Lead Time, a tarefa ficou parada, esperando que algum membro da equipe iniciasse seu desenvolvimento. Isso significa que a equipe deve otimizar seu Cycle Time para entregar tarefas mais rapidamente ou incluir novos membros na equipe para dividir o trabalho.

Vale ressaltar também que adotar métricas ágeis podem ajudar os times a visualizarem quanto esforço já foi gasto em um determinado produto, motivando assim as equipes de desenvolvimento, que podem manter ou melhorar um determinado ritmo de entregas. Além disso, tal como as metodologias ágeis, as métricas também permitem a eliminação de erros e o crescimento ordenado e sustentável de uma empresa. 

Para saber mais:

CompartilharFacebookTwitter
Entrar na conversa