Atualmente é bem comum escutar que um determinado projeto está trabalhando de forma ágil ou que segue um modelo ágil. É inquestionável que trabalhar com ágil em projetos de software traz ganhos significativos para o time e para o cliente .
Mas fica um questionamento, estamos fazendo a coisa certa, ou da forma correta?
Vou um pouco além desta indagação e coloco alguns questionamentos:
- 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?
Poderia listar vários questionamentos sobre condução do projeto, dúvidas que não são de exclusividade da gestão, mas devem ser de todos os envolvidos direta ou indiretamente no projeto.
Mas afinal, como posso descobrir estas informações?
A resposta para este questionamento está justamente nas métricas ágeis. Estas não vão lhe responder tudo assim de bate e pronto 😊, mas vão lhe proporcionar a leitura clara do andamento do projeto e uma rápida verificação de resultados, conforme ações aplicadas.
Existem diversas métricas, mas veremos aqui algumas simples de monitorar:
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 construir e pode ser montado em um excel, caso 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 (pode ser em horas ou story points), 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, observe o gráfico abaixo. Note que a linha azul demonstra o total de pontos sendo descontado (1,4 pontos) até o último dia da sprint, que ficará com 0 (zero). Ou seja, se o time entrega sua meta diária consequentemente entregará os pontos previstos. Note também que a linha vermelha demonstra o valor entregue (real) pelo time, com isso o total de pontos desconta apenas o que realmente foi entregue.
Na leitura do gráfico acima, vemos que o time não entregou sua meta diária no início da sprint, mas que recuperou nos dias seguintes, alcançando a previsão. Manteve-se abaixo da meta em alguns dias, no final da sprint encontrou algumas dificuldades, mas conseguiu concluir o seu objetivo.
A dica que deixo é um acompanhamento diário pelo time, com uma reflexão do que ocorreu no dia anterior para não ter atingido a meta. Mas o mais importante é: o que vamos fazer para recuperá-la.
2. Burndown épico e release
O indicador de burndown de épicos e releases, funciona simular ao burndown de sprint. A diferença é 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;
- Quantos (story points ou horas) foram entregues;
- Quantos (story points ou horas) faltam para a entrega.
O objetivo deste indicador é monitorar o quanto entregamos da versão. Veja abaixo um exemplo simples deste indicador:
É comum a utilização deste indicador em uma versão por sprint, mas quando utilizado neste contexto perde a visão de entrega de versões e demonstra mais a entrega por interações. 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 finaliza o projeto (caso não seja adicionado escopo). Veja o exemplo abaixo:
3. Burnup projeto
Assim como o burndown, este indicador trabalha demonstrando um período de entregas do time de desenvolvimento. Ambos indicadores podem representar uma sprint ou um período do projeto, porém como já 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, onde o prazo planejado é representado no eixo X (horizontal) e as entregas representadas no eito Y (vertical) que exibe em que ponto a equipe está ao longo da sprint/projeto, revelando o progresso na linha ascendente (queimando para cima) em direção ao ponto final.
Conforme mencionei, este gráfico pode ser uma visualização da sprint, mas seu uso mais comum é a visualização do projeto (podendo ser uma visão diária ou por aIterações de sprints).
Note na imagem acima que a linha azul representa o escopo total, enquanto a linha verde demonstra a entrega (pontos ou horas) realizada pelo time ao longo do tempo. Perceba que foi traçada uma linha laranja ao longo do tempo (ponto inicial ao ponto final) que representa 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 notar que o time está abaixo ou acima do planejado quando falamos 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.
Bem pessoal, como disse inicialmente este tema pode ser bem extenso e a leitura das informações pode oferecer muitos benefícios, desde que seja realizada com clareza e de forma correta. Por isso temos que cuidar sempre na representação gráfica das informações, para que quem as leia não precise de um manual.
Este artigo faz uma pausa, mas teremos a parte 2, onde falaremos de:
- Velocidade da equipe
- Gráficos de controle
- Diagrama de fluxo cumulativo
- Throughput
Espero que o conteúdo seja útil para seus projetos. Se você tem algum métrica ágil que deseja um melhor entendimento, deixe seu comentário com sugestão.
Até a próxima!
