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

Estatísticas e gráficos são ferramentas potentes. Devem ser usadas para sempre, agilistas... para sempre. 

Dan Radigan Dan Radigan
Buscar tópicos

Métricas são um assunto delicado.

De um lado, todo mundo já trabalhou em um projeto sem nenhum tipo de dado monitorado, com dificuldade para dizer se aquele era o caminho certo para o lançamento da versão nova ou se a eficiência aumentava com o tempo. Por outro lado, muitos já tiveram a infelicidade de trabalhar em projetos cujas estatísticas foram usadas como uma estratégia bélica, para colocar uma equipe contra a outra ou justificar a necessidade de trabalhar durante o fim de semana. Então, não é surpresa que a maioria das equipes tenha uma relação de amor e ódio com as métricas.

Mas não precisa ser assim. Acompanhar e compartilhar métricas ágeis sólidas pode reduzir a confusão e mostrar o progresso (e retrocesso) da equipe durante todo o ciclo de desenvolvimento. Veja como.

Conheça o seu próprio negócio

"Concluído" conta apenas metade da história. Tem a ver com criar o produto certo, no momento certo, para o mercado certo. Manter o rumo durante todo o programa implica em 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 indicam se a solução está atendendo às necessidades do mercado, enquanto as métricas ágeis avaliam os aspectos do processo de desenvolvimento.

As métricas empresariais de um programa devem estar enraizadas em 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 por 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, mais elas conseguem se adaptar e evoluir. 

Como usar métricas ágeis para otimizar sua entrega

As métricas ágeis discutidas abaixo se concentram na entrega de software. Cada uma delas ajuda as equipes de Scrum ou Kanban a entender melhor o processo de desenvolvimento, tornando o lançamento de software mais fácil.

Gráfico de burndown do sprint

Equipes Scrum organizam o desenvolvimento em sprints com duração pré-determinada. No início do sprint, a equipe prevê quanto trabalho pode fazer durante um sprint. O relatório do gráfico de burndown do sprint monitora a conclusão do trabalho durante todo o sprint. O eixo x representa o tempo e eixo y, a quantidade de trabalho ainda não concluída, medida em pontos da história ou horas. O objetivo é concluir todo o trabalho previsto até o final do sprint.

Uma equipe que atende com consistência sua previsão é uma propaganda convincente de agilidade em sua organização. Mas caia em tentação de contornar os números dizendo que um item foi concluído antes do tempo. Pode parecer bom em um primeiro momento, mas, a longo prazo, isso só dificulta a aprendizagem e a melhoria.  

Antipadrões que devem ser observados
  • A equipe termina rápido em vários sprints seguidos porque não está se comprometendo com trabalho suficiente. 
  • A equipe não consegue cumprir a previsão em vários sprints seguidos porque está se comprometendo com trabalho demais. 
  • A linha do gráfico de burndown tem quedas bruscas em vez de um burndown mais gradual porque o trabalho não foi dividido em partes granulares.
  • O proprietário do produto adiciona ou altera o escopo no meio do sprint.

Burndown da versão e do epic

Os gráficos de burndown de epics e lançamentos (ou versões) monitoram o progresso do desenvolvimento de uma parte do trabalho maior que o gráfico de burndown do sprint, e orientam o desenvolvimento nas equipes de 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, epics e versões.

"Desvio 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 desvio de escopo seria solicitar novos recursos após os requisitos iniciais serem esboçados. Embora não seja uma boa prática tolerar o desvio 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. 

Antipadrões que devem ser observados
  • As previsões de epic ou lançamento não são atualizadas à medida que a equipe avança com o trabalho.
  • Não se faz progresso ao longo de um período de várias iterações. 
  • Desvio de escopo crônico, o que pode ser um sinal de que o proprietário do produto não entende bem o problema que se está tentando resolver.
  • O escopo cresce mais rápido do que a equipe consegue absorver.
  • A equipe não está enviando lançamentos incrementais 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 a previsão. O proprietário do produto pode usar a velocidade para prever a rapidez com que uma equipe pode trabalhar em um backlog, porque o relatório monitora 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 no backlog. Sabemos que a equipe de desenvolvimento costuma concluir 50 pontos da história por iteração. O proprietário do produto pode presumir que a equipe vai precisar de 10 iterações (mais ou menos) para concluir o trabalho necessário.

É importante monitorar como a velocidade evolui ao longo do tempo. Novas equipes podem querer ver um aumento na velocidade à medida que as relações e o processo de trabalho são otimizados. Equipes atuais podem monitorar sua velocidade para garantir um desempenho consistente ao longo do tempo e confirmar se uma mudança de processo específica fez melhorias ou não. Uma diminuição na velocidade média é um sinal de que alguma parte do processo de desenvolvimento da equipe está ineficiente e deve ser avaliada na próxima retrospectiva.

Antipadrões que devem ser observados

Quando a velocidade é errática durante um longo período de tempo, sempre revisite as práticas de estimativa da equipe. Durante a retrospectiva da equipe, faça as seguintes perguntas:

  • Há desafios de desenvolvimento imprevistos que não consideramos ao estimar o trabalho? Como podemos dividir melhor o trabalho para descobrir alguns desses desafios?
  • Há pressão externa aos negócios forçando a equipe a ir além de seus limites? O resultado está sendo uma adesão menor às melhores práticas de desenvolvimento?
  • Como equipe, somos zelosos demais na previsão do 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 uniformes 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, sem importar o tipo de trabalho (novo recurso, débito técnico etc.).

Antipadrões que devem ser observados

Os gráficos de controle podem parecer inconstantes no início. Não se preocupe demais com cada valor atípico. Procure tendências. Aqui estão duas áreas para ficar atento:

  • Tempo de ciclo aumentado : aumentar o tempo do ciclo tira da equipe a agilidade conseguida com tanto esforço. Na retrospectiva da equipe, demore o necessário para entender um aumento. Uma exceção: se a definição de “concluído” da equipe foi ampliada, o tempo do ciclo deve ser ampliado também.
  • Tempo de ciclo errático : o objetivo é ter tempos de ciclo uniformes para itens de trabalho que tenham valores de ponto da história semelhantes. Filtre o gráfico de controle para cada valor do ponto da história para verificar a uniformidade. Se os tempos de ciclo são erráticos em valores de ponto da história pequenos e grandes, dedique tempo na retrospectiva examinando as falhas e melhorando estimativas futuras. 

Diagrama de fluxo cumulativo

O diagrama de fluxo cumulativo é um recurso importante para as equipes de Kanban, ajudando a garantir que o fluxo de trabalho na equipe seja uniforme. Com o número de itens no eixo Y, tempo no eixo X e cores para indicar os vários estados do fluxo de trabalho, ele aponta, visualmente, as deficiências e os gargalos 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 deficiências e gargalos. Assim, quando vir uma, procure por modos de suavizar as faixas de cores no gráfico.

Antipadrões que devem ser observados
  • Problemas de bloqueio criam grandes backups em algumas partes do processo e inanição em outras.
  • Crescimento de backlog não verificado ao longo do tempo, resultado de os proprietários de produtos não estarem fechando itens obsoletos ou apenas com prioridade muito baixa para serem ativados. 

Mais métricas ainda

Boas métricas não se limitam aos relatórios discutidos acima. Por exemplo, a qualidade é uma métrica importante para as equipes ágeis e há diversas métricas tradicionais que podem ser aplicadas ao desenvolvimento ágil:

  • Quantos defeitos são encontrados...
    • durante o desenvolvimento?
    • após o lançamento para os clientes?
    • por pessoas fora da equipe?
  • Quantos defeitos são adiados para uma versão futura?
  • Quantas solicitações de suporte ao cliente estão chegando?
  • Qual é a porcentagem de cobertura dos testes automatizados?

As equipes ágeis também devem analisar a velocidade de entrega e a frequência de liberação. No final de cada sprint, a equipe deve liberar o software para produção. Com que frequência isso acontece de verdade? A maioria das versõ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 proporcionam insight quantitativo no desempenho da equipe e oferecem metas mensuráveis para a equipe. Embora sejam importantes, não se preocupe apenas com isso. Ouvir os comentários da equipe durante as retrospectivas é tão importante quanto o fortalecimento da confiança na equipe, a qualidade do produto e a velocidade de desenvolvimento durante o processo de liberação. Use os comentários quantitativos e qualitativos para impulsionar a mudança. 

a seguir
Gantt Chart