Resumo: as métricas ágeis proporcionam insights sobre a produtividade durante os diferentes estágios do ciclo de vida de desenvolvimento de um software. Isso ajuda a avaliar a qualidade de um produto e monitorar o desempenho da equipe.
Métricas são um assunto delicado.
De um lado, todos já tivemos um projeto no qual não havia nenhum tipo de dado monitorado, e era difícil dizer se estávamos no caminho certo para a liberação ou ficando mais eficientes à medida que avançávamos. Por outro lado, muitos já tiveram a infelicidade de trabalhar em um projeto cujas estatísticas foram usadas como uma estratégia, colocando uma equipe contra a outra ou justificando a necessidade de trabalhar durante o fim de semana. Então não é surpresa que a maioria das equipes tem uma relação de amor e ódio com as métricas.
Mas não precisa ser assim. Acompanhar e compartilhar métricas ágeis pode reduzir a confusão e mostrar o progresso da equipe (e retrocessos) durante todo o ciclo de desenvolvimento. Veja como.
Conheça o seu próprio negócio
"Concluído" conta apenas metade da história. É criar o produto certo, no momento certo, para o mercado certo. Ficar em dia durante todo o programa é coletar e analisar dados relevantes ao longo do processo. Em qualquer programa ágil, é importante monitorar as métricas de negócios e as métricas de times ágeis. As métricas de negócios têm como foco observar se a solução está atendendo as necessidades do mercado, e as métricas de times ágeis mensuram os aspectos do processo de desenvolvimento.
"As métricas de negócios de um programa devem estar enraizadas no roteiro."
Para cada iniciativa no roteiro, inclua vários indicadores-chave de desempenho (KPIs) que levem até as metas do programa. Além disso, inclua critérios de sucesso para cada requisito do produto, como taxa de adoção dos usuários finais ou porcentagem do código coberta pelos testes automatizados. Esses critérios de sucesso alimentam as métricas ágeis do programa. E, quanto mais as equipes aprendem, melhor elas conseguem se adaptar e evoluir.
Como usar métricas ágeis de KPI para otimizar a entrega
Gráfico de burndown do sprint
Equipes scrum organizam o desenvolvimento em sprints com intervalos de tempo. Desde o início do sprint, a equipe prevê quanto trabalho pode fazer durante um sprint. O relatório de burndown então monitora a conclusão do trabalho durante todo o sprint. O eixo x representa o tempo e o eixo y refere-se à quantidade de trabalho ainda não concluída, medida em pontos de história ou horas. O objetivo é ter todo o trabalho previsto concluído até o final do sprint.
Uma equipe que demonstra consistência no cumprimento das previsões é uma propaganda convincente para a agilidade em sua organização. Mas não caia na tentação de contornar os números declarando um item como completo antes que esteja mesmo. Pode parecer bom no curto prazo, mas, a longo prazo, essa abordagem só dificulta a aprendizagem e a melhoria.
- A equipe finaliza mais cedo do que o esperado, sprint após sprint, porque está se comprometendo a fazer menos do que poderia.
- A equipe perde a previsão, sprint após sprint, porque está se comprometendo a fazer mais do que poderia.
- A linha de burndown mostra quedas bruscas em vez de um burndown mais gradual porque o trabalho não foi dividido em partes menores.
- O proprietário do produto adiciona ou altera o sprint intermediário do escopo.
Burndown da versão e do epic
Os gráficos de burndown de epic e liberação (ou versão) monitoram o progresso de desenvolvimento de uma grande parte do trabalho do que em relação ao burndown de sprint, e orientam o desenvolvimento de equipes scrum e kanban. Como um sprint (para equipes scrum) pode conter trabalho de vários epics e versões, é importante monitorar o progresso de sprints individuais, bem como epics e versões, para visualizar as métricas kanban.
"Deslizamento de escopo" é a inserção de mais requisitos em um projeto que já havia sido definido. Por exemplo, se a equipe está entregando um novo site para a empresa, o deslizamento de escopo seria solicitar novos recursos após os requisitos iniciais serem esboçados. Embora não seja uma boa prática tolerar o deslizamento de escopo durante um sprint, a alteração do escopo em epics e versões é uma consequência natural do desenvolvimento ágil. À medida que a equipe passa pelo projeto, o proprietário do produto pode decidir assumir ou remover o trabalho com base no que estão aprendendo. Os gráficos de burndown de epic e lançamento mantêm todos conscientes sobre o que está acontecendo e sobre o fluxo de trabalho dentro do epic e da versão.
- Previsões de liberação ou epic não são atualizadas à medida que a equipe trabalha.
- Nenhum progresso é feito ao longo de várias iterações.
- O deslizamento de escopo crônico, que pode ser um sinal de que o proprietário do produto não entende completamente o problema que a parte do trabalho está tentando resolver.
- O escopo cresce mais rapidamente do que a equipe pode absorvê-lo.
- A equipe não está enviando liberações adicionais durante o desenvolvimento de um epic.
Velocidade
Velocidade é a quantidade média de trabalho que uma equipe de scrum conclui durante um sprint, medida em horas ou pontos de história, e é muito útil para previsão. O proprietário do produto pode usar velocidade para prever o quão rapidamente uma equipe pode trabalhar em uma lista de pendências, porque o relatório rastreia o trabalho previsto e o concluído ao longo de várias iterações – quanto mais iterações, mais precisa a previsão.
Digamos que o proprietário do produto quer concluir 500 pontos de história na lista de pendências. Sabemos que a equipe de desenvolvimento geralmente conclui 50 pontos de história por iteração. O proprietário do produto pode assumir, razoavelmente, que a equipe precisará de dez iterações (mais ou menos) para concluir o trabalho necessário.
É importante monitorar como a velocidade evolui ao longo do tempo. Novas equipes podem esperar ver um aumento na velocidade à medida que as relações e o processo de trabalho são otimizados. Equipes existentes podem monitorar sua velocidade para garantir um desempenho consistente ao longo do tempo e podem confirmar se uma mudança de processo específica fez melhorias 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 avaliada na próxima retrospectiva.
Quando a velocidade for errática durante um longo período, sempre reveja as práticas de estimativa da equipe. Durante a retrospectiva da equipe, faça as perguntas seguintes:
- Há desafios imprevistos de desenvolvimento com os quais não contávamos ao estimar este trabalho? Como podemos dividir melhor o trabalho para descobrir alguns desses desafios?
- Há alguma pressão de negócios levando a equipe para além de seus limites? Há uma piora na adesão às melhores práticas de desenvolvimento em decorrência disso?
- Como equipe, estamos sendo cuidadosos demais na previsão para o sprint?
A velocidade de cada equipe é única. Se a equipe A tiver uma velocidade de 50 e a equipe B tiver uma velocidade de 75, isso não significa que a equipe B tenha maior produtividade. Uma vez que a cultura de estimativa de cada equipe é única, sua velocidade também vai ser. Resista à tentação de comparar a velocidade entre equipes. Meça o nível de esforço e os resultados do trabalho com base na interpretação única que cada equipe faz dos pontos da história.
Gráfico de controle
Os gráficos de controle trazem o tempo de ciclo de itens individuais, o tempo total de “em andamento” para “concluído”. É provável que as equipes com tempos de ciclo mais curtos tenham produtividade maior, e as equipes com tempos de ciclo consistentes por muitos itens são mais previsíveis na entrega de trabalho. Embora o tempo de ciclo seja uma métrica primária para equipes de Kanban, as equipes de Scrum também podem se beneficiar do tempo de ciclo otimizado.
Medir o tempo de ciclo é um modo eficiente e flexível de melhorar os processos de uma equipe, pois os resultados das mudanças são perceptíveis quase imediatamente, permitindo que a equipe faça quaisquer ajustes necessários. A meta final é ter um tempo de ciclo curto e consistente, independentemente do tipo de trabalho (novo recurso, débito técnico, etc.).
Os gráficos de controle podem parecer instáveis no início. Não fique tão preocupado com todos os valores atípicos. Procure por tendências. Aqui estão duas áreas para observar:
- Aumentar o tempo de ciclo - aumentar o tempo de ciclo diminui a agilidade que a equipe trabalhou muito para obter. Na retrospectiva da equipe, reserve um tempo para entender um aumento desse tipo. Uma exceção: se a definição da equipe de "concluído" tiver sido expandida, o tempo de ciclo provavelmente também vai ser expandido.
- Tempo de ciclo irregular – a meta é ter um tempo de ciclo consistente para os itens de trabalho que têm valores de ponto da história parecidos. Filtre o gráfico de controle para cada valor do ponto da história para verificar a consistência. Se o tempo de ciclo for irregular em valores de ponto da história pequenos e grandes, passe um tempo da retrospectiva examinando as falhas e melhorando a estimativa futura.
Diagrama de fluxo cumulativo
O diagrama de fluxo cumulativo deve parecer mais suave da esquerda para a direita. Bolhas ou lacunas de uma cor indicam carências e obstáculos, então, quando vir uma, procure por modos de suavizar a faixa de cor no gráfico.
- Problemas de bloqueio criam backups grandes em algumas partes do processo e ausências em outros.
- Crescimento do backlog não verificado ao longo do tempo. Isto acontece quando os proprietários do produto não encerram os itens que estão obsoletos ou apenas com prioridade muito baixa para serem abordados.
Mais métricas ainda
Boas métricas não são limitadas aos relatórios discutidos acima. Por exemplo, a qualidade é uma métrica importante para as equipes ágeis e há um número de métricas tradicionais e métricas kanban que podem ser aplicadas ao desenvolvimento ágil:
- Quantos defeitos são encontrados?
- durante o desenvolvimento?
- após a liberação para os clientes?
- por pessoas fora da equipe?
- Quantos defeitos são adiados para uma liberação futura?
- Quantos pedidos de suporte ao cliente estão chegando?
- Qual é a porcentagem de cobertura de teste automatizado?
As equipes ágeis também devem analisar a velocidade de de entrega e a frequência da liberação. No final de cada sprint, a equipe deve liberar o software para produção. Com que frequência isso realmente acontece? A maioria das liberações está sendo enviada? Na mesma linha, quanto tempo leva para a equipe liberar uma correção de emergência para produção? A liberação é fácil para a equipe ou exige muito trabalho?
Encontre dados contextualizados
O Insight é uma excelente ferramenta para as equipes acessarem métricas ágeis quando for necessário: durante o planejamento de sprints, em verificações nas reuniões rápidas diárias ou na otimização de entregas. Você pode encontrar dados no canto superior direito da visualização de quadro, backlog e implementações do Jira.
O Insight oferece imagens instantâneas das seguintes métricas ágeis e kanban:
- Progresso do sprint
- Detalhamento do tipo de item
- Compromisso de sprint
- Frequência de implementação
- Tempo de ciclo
Use estas métricas e indicadores ágeis para otimizar sem interrupções o desempenho da equipe. Saiba mais sobre o Insight.
Conclusão...
As métricas ágeis e KPIs são apenas uma parte da criação da cultura da equipe. Elas proporcionam insights quantitativos do desempenho da equipe e oferecem objetivos mensuráveis para ela. Essas métricas são importantes, mas não precisa se preocupar tanto com isso. Ouvir o feedback da equipe durante as retrospectivas é tão importante quanto elas para aumentar a confiança da equipe, a qualidade do produto e a velocidade de desenvolvimento no processo de lançamento. Use os feedbacks quantitativos e qualitativos para impulsionar a mudança.
Recursos relacionados
