Cinco métricas ágeis que você não odiará

Estatísticas e gráficos são ferramentas importantes. Use-os para executar um bom trabalho. 

Dan Radigan Dan Radigan

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.

Conhecer o seu negócio

"Concluído" conta apenas metade da história. É sobre criar o produto certo, no momento correto, para o mercado certo. Permanecer no controle durante todo o programa significa coletar e analisar dados ao longo do caminho. Em qualquer programa ágil, é importante monitorar as métricas de negócios e as métricas ágeis. As métricas de negócios têm como foco se a solução está atendendo as necessidades do mercado, e as métricas ágeis mensuram os aspectos do processo de desenvolvimento.

As métricas de negócio de um programa devem estar enraizadas no seu roteiro.

Para cada iniciativa no roteiro, inclua vários indicadores-chave de desempenho (KPIs) que fazem o mapeamento até as metas do programa. Além disso, inclua critérios de êxito 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 êxito 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 para otimizar sua entrega

The agile metrics discussed below focus on the delivery of software. Whether you are a scrum or kanban team, each of these agile metrics will help the team better understand their development process, making releasing software easier.

Sprint burndown

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 atende consistentemente sua previsão é uma propaganda convincente para agilidade em sua organização. Mas não deixe isso tentá-lo a contornar os números declarando um item como completo antes que esteja. Pode parecer bom no curto prazo, mas, a longo prazo, isso só dificulta a aprendizagem e a melhoria.  

Antipadrões que devem ser observados
  • A equipe finaliza, antecipadamente, sprint após sprint porque ela está se comprometendo a fazer muito trabalho. 
  • A equipe perde sua previsão de sprint após sprint porque está se comprometendo a fazer muito trabalho. 
  • 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 de liberação e 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.

"Deslizamento de escopo" é a inserção de mais requisitos em um projeto definido anteriormente. 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 planejando. Os gráficos de burndown de epic e liberação mantêm todos conscientes sobre o que está acontecendo e o fluxo de trabalho dentro do epic e da versão. 

Antipadrões que devem ser observados
  • 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.

Antipadrões que devem ser observados

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 tendo muito cuidado na previsão para o sprint? 

Each team’s velocity is unique. If team A has a velocity of 50 and team B has a velocity of 75, it doesn't mean that team B has higher throughput. Since each team's estimation culture is unique, their velocity will be as well. Resist the temptation to compare velocity across teams. Measure the level of effort and output of work based on each team's unique interpretation of story points. 

Gráfico de controle

Control charts focus on the cycle time of individual issues–the total time from "in progress" to "done". Teams with shorter cycle times are likely to have higher throughput, and teams with consistent cycle times across many issues are more predictable in delivering work. While cycle time is a primary metric for kanban teams, scrum teams can benefit from optimized cycle time as well.

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.).

Antipadrões que devem ser observados

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. Uma exceção: se a definição da equipe de "concluído" tiver sido expandida, o tempo de ciclo provavelmente também será expandido.
  • Tempo de ciclo irregular – a meta é ter um tempo de ciclo consistente para os itens de trabalho que têm valores similares de ponto de história. Filtre o gráfico de controle para cada valor do ponto de história para verificar a consistência. Se o tempo de ciclo for irregular em valores de ponto de história pequenos e grandes, passe um tempo na retrospectiva examinando as falhas e melhorando a estimativa futura. 

Diagrama de fluxo cumulativo

O diagrama de fluxo cumulativo é um recurso importante para as equipes kanban , ajudando a garantir que o fluxo de trabalho na equipe seja consistente. Com vários problemas no eixo Y, tempo no eixo X e cores para indicar os vários estados do fluxo de trabalho , ele aponta, visualmente, os défices e os obstáculos e trabalha em conjunto com os limites de WIP.

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.

Antipadrões que devem ser observados
  • Problemas de bloqueio criam backups grandes em algumas partes do processo e ausências em outros.
  • Crescimento da lista de pendências não verificada ao longo do tempo. Isto acontece quando os proprietários do produto não encerram os problemas que estão obsoletos ou simplesmente com prioridade muito baixa para serem abordados. 

Ainda mais métricas

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 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?

As métricas são apenas uma parte da criação da cultura da equipe. Elas fornecem insight quantitativo no desempenho da equipe e fornecem metas mensuráveis para a equipe. Embora sejam importantes, não se preocupe apenas com isso. Ouvir o feedback da equipe durante as retrospectivas é igualmente importante no fortalecimento da confiança na equipe, qualidade do produto e velocidade de desenvolvimento durante o processo de liberação. Use os feedbacks quantitativos e qualitativos para impulsionar a mudança. 

Up Next
Advantage