Verdade seja dita, quando escutamos a palavra “métricas”, um muro de pedras já é construído para se preparar para o pior. Por isso, um dos objetivos deste texto é desconstuir uma sólida visão tradicionalista de que métricas remetem a algo pouco maleável. Vamos entender como as metodologias ágeis também utilizam métricas de apoio para avaliar projetos, começando pelo Scrum.
Sem métricas, os times tendem a reagir depois que os problemas já aconteceram, o que os impede de evoluir continuamente. Antecipar as falhas de um projeto por meio de dados mensuráveis e confiáveis nos permite fazer ajustes ao longo do caminho e prever a entrega de resultados.
A seguir apresento algumas das métricas mais utilizadas para avaliar seu Sprint dentro do Scrum (quer entender um pouco mais de como funciona o Scrum? Falamos sobre o assunto neste post, vale a pena conferir).
Velocidade
Com certeza, uma das métricas mais utilizadas dentro do Scrum é a Velocidade. Além de simples de ser medida, também é uma métrica bastante útil quando a intenção é avaliar a capacidade de entrega da equipe.
Velocidade é a quantidade média de trabalho que uma equipe de Scrum conclui durante um Sprint, medida em horas ou pontos, e é muito útil para previsão de entrega de demandas e dimensionamento de equipes.
Novas equipes podem esperar um aumento na velocidade, à medida em que as relações e os processos de trabalho evoluem com o tempo. Equipes que já trabalham juntas devem monitorar sua velocidade para garantir um desempenho consistente ao longo do tempo, além de conseguir ponderar se uma mudança de processo específica se faz necessária ou não. Uma diminuição na velocidade média é, geralmente, um sinal de que alguma parte do processo de desenvolvimento da equipe tornou-se ineficiente e deve ser reavaliado em momento oportuno.
Alguns pontos importantes devem ser considerados ao medir horas ou pontos dentro de um Sprint.
- A velocidade de cada equipe é única! Resista à tentação de comparar a velocidade de equipes distintas. A velocidade de uma equipe deve ser comparada com a própria velocidade do ciclo de trabalho anterior.
- Existe uma tendência de que as horas ou pontos de um Sprint diminuam à medida em que a equipe acumule ciclos de trabalho juntos. A velocidade é maior quando a equipe já trabalha junta há algum tempo.
- A velocidade deve ser avaliada levando em consideração Sprints semelhantes.
Quando o gráfico de velocidade de uma equipe apresentar um desvio inesperado temos um sinal de que alguma parte do processo se desviou do planejado.
É importante analisar o que ocorreu, determinar se a velocidade planejada para o Sprint foi mal dimensionada ou ocorreu algum erro de processo inesperado. Estas avaliações nos permitem redirecionar a rota e entregar um produto mais assertivo e em menor tempo, além de informar ao cliente um prazo de entrega condizente com a realidade de execução.
Burndown Chart
Como vimos anteriormente aqui no blog, as equipes de Scrum organizam o tempo de desenvolvimento de projetos em Sprints. No início da Sprint, o time prevê quanto trabalho pode ser entregue durante um determinado tempo.
Um relatório de Sprint Burndown acompanha a conclusão do trabalho em toda a Sprint. O objetivo é ter todo o trabalho planejado concluído até o final do Sprint.
O Burndown pode ser acompanhado diariamente, representando a evolução do Sprint em relação ao que foi estipulado no inicio. Assim, a cada dia de trabalho finalizado, o gráfico passa a representar uma comparação entre o trabalho já entregue e o trabalho total planejado.
Esta métrica nos permite verificar e prever eventuais atrasos ou implicações no cronograma final (Real x Planejado).
Lead Time/Cycle Time
O Lead Time se refere ao tempo total de uma tarefa, desde sua criação até sua finalização. Já o Cycle Time, é o tempo que essa atividade ficou “em desenvolvimento” até sua finalização.
Se o Lead Time de um projeto for de 5 dias e o Cycle Time de 3 dias, percebemos que, durante grande parte do Lead Time essa tarefa não foi desenvolvida (por falta de tempo ou de equipe, por exemplo). Assim, é possível identificar o que pode ser feito para que esses números fiquem cada vez mais próximos entre si.
O acompanhamento dos ciclos de entrega pode ser feito através de softwares de acompanhamento (Jira, Trello, Azure, etc.) ou, manualmente, em gráficos de real x planejado.
Essas métricas do Scrum, quando analisadas em conjunto, nos permitem identificar melhorias no processo que reduzam tempos de desvio entre planejado e executado, e melhorem a qualidade da entrega dos times ágeis.
O X da questão
Se você chegou até o final deste texto, temos um surpresa: seu muro de pedras está prestes a ser totalmente desconstruído nos próximos parágrafos.
Sabe por que a palavra métricas ainda te provoca uma certa aversão? Certamente você já passou por situações onde elas foram utilizadas para controlar pessoas, times, entregas e validar a qualidade ou quantidade do seu trabalho.
Mas, na verdade, métricas foram desenvolvidas para melhoria contínua! E, se usadas da maneira correta, podem se tornar seu braço direito para um trabalho de qualidade.
Lembre-se, o pior inimigo das métricas é a META! Não atrele metas ao acompanhamento de métricas, acompanhe métricas para melhorar suas entregas! As métricas foram desenvolvidas para apontar problemas, e não para gerar mais!
Precisa de ajuda para implementação dessa ou outra metodologia em sua empresa? Entre em contato com a gente!
