Métricas Ágeis
No mundo da agilidade, existem diversas métricas que podem ser colhidas de um time. Mas o que são as métricas ágeis?
Métricas ágeis são dados relacionados ao time e às entregas em todo o ciclo de desenvolvimento ágil de um projeto. Esses dados podem nos gerar insights para melhoria de produtividade da equipe. As métricas podem mostrar o progresso de um time, assim como o regresso.
Quais métricas são importantes?
A importância de um dado colhido depende do que você quer analisar no time, mas segue algumas dicas:
1. Gráfico de Burndown:
Quando se fala de Scrum, estamos falando de desenvolvimento por sprints, que são ciclos de desenvolvimento de um produto. O gráfico de burndown mede o quanto falta para entregar em uma sprint, ou seja, a quantidade de trabalho que ainda precisa ser concluída. A sua visualização e montagem é simples e de fácil entendimento .Ele é composto de dois eixos, sendo o eixo x representando o tempo da sprint, e o eixo y representando o trabalho em horas ou pontos, de acordo com o dado que o time usa.
Com esses dados, são feitas duas medições: Quanto deveria ser concluído no decorrer do ciclo, e quanto realmente está sendo concluído. Em outras palavras, o ritmo ideal/planejado de entregas, e o ritmo real. Segue abaixo um exemplo desse gráfico, onde ele está contando 75 dias, e foi planejado entregar 30 pontos de esforço nesses 75 dias:
Como preencher o gráfico?
> Tenha em mãos a quantidade de pontos ou horas planejados no início da sprint, e a quantidade de dias que ela terá.
> A linha ideal/planejada é criada da seguinte forma: Traça-se uma linha reta, começando no primeiro dia e na quantidade de pontos planejados na sprint, e finalizando no último dia da sprint e no ponto 0 do eixo y, ou seja, 0 pontos a serem concluídos (100% de entrega). A conta feita é a divisão entre quantidade de esforço planejada e quantidade de dias do ciclo (começando em 0), e em cada dia, subtrai-se esse resultado, da quantidade de pontos. Exemplo:
- 30 pontos planejados em 15 dias de trabalho.
- Dividindo 30 por 15, resulta em 2 pontos entregues por dia.
- Cada dia finalizado, subtrai-se 2 pontos. Então no dia 0 temos 30 pontos restantes. No dia 1, o ideal é que tenhamos 28 pontos restantes, no dia 2, 26 pontos restantes e assim sucessivamente, até chegar no dia 15 e termos 0 pontos.
> A linha real é alimentada diariamente. Ao final de cada dia, pegamos o planejado e subtraimos a quantidade de horas ou pontos já entregues, resultando no total de trabalho restante. Exemplo:
- 30 pontos planejados.
- Dia 1 temos 0 pontos entregues, então calculamos 30–0, resultando em 30 pontos de trabalho restantes.
- Já no dia 2, temos um total de 3 pontos entregues. Calculamos 30–3, resultando em 27 pontos de trabalho restantes.
- No dia 3, entregamos 1 ponto, então temos 4 pontos entregues no total (3 do dia anterior + 1 do dia atual). 30–4, 26 pontos restantes.
2. Gráfico de Burnup
Apesar de parecer o gráfico de burndown, e ambos mostrarem o progresso do time, o gráfico de Burnup é um pouco diferente.
Enquanto o Burndowm mostra quanto falta para chegar na meta planejada, Burnup mostra quanto o time já progrediu para alcançar o objetivo. Esse gráfico geralmente é usado para medir o progresso do projeto como um todo, mas pode também ser montado para ter a visualização apenas da sprint.
Da mesma forma que o gráfico de Burndown é criado, o Burnup parte de dois eixos, sendo o eixo horizontal representando o tempo, e o eixo vertical representando horas/pontos de esforço. A diferença é que o Burnup cresce, assim como seu nome diz. Ele começa em zero no primeiro dia da sprint (ou do projeto), e corre até a meta planejada, chegando último dia da sprint. Conforme os dias vão correndo, vai sendo relatado quantos pontos ou horas foram entregues. Segue exemplo:
3. Velocidade do time
A velocidade do time é uma das métricas mais importantes para o planejamento de entregas. É bastante usado quando é preciso prever a média de quanto a equipe consegue entregar em uma sprint, por exemplo.
Os dados usados geralmente são das últimas sprints finalizadas. Quanto mais dados coletados, maior é a precisão da velocidade, mas é mportante lembrar também que dados muito antigos podem não ser tão úteis, pois a chance de ser mais assertivo usando dados mais “novos”, é maior do que quando usamos dados de sprints finalizadas a mais tempo! Além disso, os times evoluem, pessoas entram e saem, então é necessário se atentar a isso também.
A ideia é olhar para as sprints passadas e analisar quanto o time conseguiu entregar, fazendo uma média e levando em conta alguns pontos importantes, como:
- Tivemos ausências significativas de membros do time (férias, atestado, entrada ou saída de colaboradores…)?
- Tivemos impedimentos que impactaram nos resultados?
- Quão assertivas foram nossas estimativas de pontos nas histórias das sprints analisadas?
O time precisa estar envolvido nessa análise, pois ele, mais do que ninguém, consegue responder essas perguntas e discutir a velocidade de entrega. O que não pode ser feito, é comparar a velocidade entre times diferentes. Não se esqueçam: a velocidade de entrega de um time é única! Se um time com 5 pessoas entrega 40 pontos em uma sprint, não necessariamente outro time, também com 5 pessoas, precisa entregar 40 pontos. São pessoas diferentes, com ritmos de trabalho, conhecimento e senioridade diferentes!
4. Cycle Time e Lead Time
Ao falar de cycle time e lead time, estamos falando de histórias, features e epics. Esses dois indicadores medem diferentes etapas do processo.
Mas o que são esses indicadores?
Vamos lá! Pensando em histórias de usuário:
Cycle Time:
- Cycle time é o tempo que uma história leva desde o inicio do desenvolvimento, até o momento da entrega. Pensando num quadro de tarefas, o cycle time se inicia quando a história entra na coluna in progress e finaliza quando a história vai para a coluna done (essas nomenclaturas podem mudar de acordo com o que o time julga melhor). Segue uma imagem para facilitar o entendimento:
- Com o cycle time medido, podemos tirar algumas informações que sejam importantes para a melhoria do time, por exemplo: conseguir mensurar quanto tempo o time demora para implementar uma determinada tarefa ou funcionalidade, seja para estimar prazos de um novo projeto de forma mais assertiva, ou para ter como meta diminuir o tempo de desenvolvimento.
- Estimar prazos de entrega é uma das etapas mais importantes para o cliente, pois ele quer o produto/projeto pronto. Então, ter esses dados de projetos anteriores, para usar de base em um novo projeto, evita que aconteça da estimativa de entrega ser muito diferente da realidade. Lembrando que cada projeto e cada equipe tem seu ritmo de trabalho, mas esses dados mensurados ajudam na estimativa.
Lead Time:
- Já o lead time, é o tempo levado desde quando a história ficou pronta para ser iniciada, até o momento da entrega. Pensando nas sprints, quando a história entra no backlog da sprint, o lead time é iniciado, e só finaliza quando a história for entregue. Como pode-se observar na imagem anterior, quando a tarefa entrar na coluna to do, ou seja, quando o time se comprometer a fazer, o lead time é iniciado, e encerra quando a história for entregue (coluna done).
- Essa métrica pode medir o tempo que uma tarefa leva para passar em todas as etapas até ser concluída, como aespera para ser iniciada, desenvolvimento, testes e homologação. Assim, é possível levantar alguns questionamentos, por exemplo se o tempo estiver muito alto. Essa tarefa que está gerando um lead time alto, ainda é importante para o cliente? A tarefa se tornou “velha” ou ainda faz sentido de ser desenvolvida?
- Com esses questionamentos, é possível eliminar histórias e tarefas que foram criadas e não fazem mais sentido para o produto, por exemplo, evitando que o time foque no desenvolvimento de funcionalidades que não serão mais utilizadas. Além disso, assim como o cycle time, o lead time ajuda a medir prazos de entrega, o que facilita na gestão dos projetos de uma empresa como um todo.
É importante ressaltar que uma história/tarefa não volta para colunas anteriores, então se uma história começou a ser desenvolvida e foi bloqueada, ela permanece na coluna de desenvolvimento e o cycle time e lead time continuam contando.
Para finalizar, basicamente o cycle time está englobado dentro do lead time, e a diferença entre os dois indicadores é que o cycle time não pega o tempo que a história está esperando pra ser iniciada, enquanto o lead time pega. Ambas as métricas são importantes para se estimar a entrega de um projeto, visto que o cliente quer saber o tempo de entrega desde quando ele solicitar a funcionalidade, o que seria a medição do lead time, enquanto o time técnico está mais focado no cycle time, que é o tempo gasto para desenvolver.
Bom, agora você consegue colher boas métricas para começar a analisar melhor as entregas do time! Existem outras métricas, como o gráfico CFD (Cumulative Flow Diagram), mas se você está começando a estudar sobre as métricas, não é o melhor caminho começar por ele, pois ele tem uma complexidade um pouco maior, e merece uma explicação bem detalhada!
Espero ter te ajudado no entendimento das métricas mais conhecidas, e que coloque em prática! 🚀🚀
Ficou com alguma dúvida? Pode comentar aqui embaixo, que a gente se ajuda 💙
Referências:
https://www.digite.com/pt-br/agile/tempo-de-lead-e-tempo-de-ciclo/
