17 métricas ágeis importantes com as quais sua equipe deve se preocupar

As métricas têm sido um ponto de debate entre os agilistas.

Apesar do desenvolvimento ágil ser empírico devido à entrega contínua de software de qualidade, escritórios de PMO, gerentes de projeto e clientes ainda exigem relatórios de status detalhados como fariam para qualquer projeto baseado em cascata. Embora a necessidade de negócios seja uma razão para a supervisão, o desenvolvimento ágil em si contribui para um nível de incerteza que algumas pessoas sempre querem definir.

Em um esforço para contrariar essa tendência, muitos agilistas afirmam que as medições não devem ser usadas e que apenas a produção de software em si deve ser considerada o critério para o sucesso. Os proponentes dessa abordagem afirmam que as equipes de desenvolvimento e os gerentes de projeto irão instintivamente manipular o sistema manipulando histórias de usuários e estimativas de forma a produzir a aparência de alta eficiência e ocultar os problemas reais. No entanto, há um ditado que afirma que o que é medido, é feito.

A principal razão pela qual esse jogo ocorre é que as organizações confiam demais em uma ou duas métricas em vez de ter uma solução de métricas abrangente. Neste artigo, discutiremos as métricas que comprovadamente produzem a melhor inteligência disponível sobre desempenho, qualidade, valor e até agilidade da equipe. Até falaremos sobre algumas métricas das quais você talvez nunca tenha ouvido falar, com base nas pesquisas mais recentes e nos estudos de caso mais inovadores.

Para que servem as métricas ágeis?

Métricas ágeis são usadas para rastrear status, qualidade, produtividade, eficiência, valor e até mesmo a própria agilidade. Mais importante, eles são usados ​​para informar as decisões de negócios. Não importa em que tipo de projeto você esteja trabalhando, os relatórios sempre serão importantes para as partes interessadas externas e internas. As métricas podem afetar as decisões em todos os níveis, desde o gerenciamento de produtos até o gerenciamento de pessoal e, como tal, precisam ser precisas, informativas e imparciais. Antes de mergulharmos nas métricas, primeiro precisamos estabelecer uma base na qual todas essas medidas se baseiam.

O Triângulo de Ferro vs. Triângulo Ágil

Nas abordagens baseadas em planos, as medições eram baseadas no velho “triângulo de ferro” de escopo, cronograma e custo. Quase todas as métricas se enquadravam em uma dessas três categorias. No mundo ágil, esse triângulo foi virado de cabeça para baixo. Os projetos são definidos pela entrega de valor e qualidade dentro de certas restrições. O orçamento ou custo é apenas uma dessas restrições, entre outras, em vez de ser o foco principal da entrega.

É importante aqui entender a relação entre valor e qualidade. Muitas pessoas lutam para definir valor. Primeiro, existem dois tipos de qualidade: intrínseca e extrínseca.

• A qualidade intrínseca está relacionada à percepção interna do produto pelas equipes de desenvolvimento, teste e gerenciamento. Geralmente é ilustrado com métricas de defeitos, que descreveremos mais adiante.
• A qualidade extrínseca é a qualidade do produto como é percebida pelo usuário final. Quão bem o produto atende às suas necessidades e atende às expectativas. Outro termo para essa qualidade extrínseca é valor.

Portanto, é importante entender que a qualidade descrita no triângulo ágil é qualidade intrínseca ou interna do ponto de vista do desenvolvimento, enquanto o valor no triângulo é realmente uma forma de qualidade extrínseca. Compreender essa relação é importante para desenvolver boas medidas ágeis.

17 principais métricas ágeis para acompanhar

A lista a seguir de dezessete métricas combina as métricas ágeis mais usadas e consagradas pelo tempo com medidas mais recentes baseadas em pesquisas recentes. A principal conclusão aqui é que qualquer solução de métricas ágeis deve ser abrangente.

Confiar em apenas um ou dois não fornecerá uma imagem completa do que está acontecendo. O maior erro que muitos gerentes cometem é se concentrar demais em duas ou três, ou apenas uma métrica para todo o projeto. Algumas organizações não usam nada além de gráficos de velocidade ou burn down.

Acredite ou não, isso acontece. Uma boa solução de métricas deve cobrir todos os três pontos do triângulo ágil. Estes 17 fornecerão as ferramentas para fazer exatamente isso e muito mais.

Tempo bloqueado

O tempo bloqueado é definido como a quantidade de tempo que uma história de usuário específica – ou às vezes uma tarefa – é bloqueada. A resolução de bloqueadores é fundamental para facilitar o fluxo de trabalho em um ambiente ágil, e essa métrica pode ajudar a medir o tempo que eles levam para resolver. Os bloqueadores devem ser resolvidos rapidamente.

Aumentos no tempo bloqueado podem significar que uma história de usuário não foi decomposta corretamente ou que há uma dependência de um recurso externo que não foi planejado. O tempo bloqueado pode ser reduzido com uma decomposição mais cuidadosa da história do usuário, priorização e planejamento de sprint.

Momento dos negócios

Muitas das métricas discutidas aqui já existem há algum tempo. A maioria está focada no nível de projeto, equipe ou WIP (trabalho em andamento). No entanto, à medida que a tecnologia está mais integrada em nossas vidas diárias e os mercados para esses produtos se tornam hiperacelerados, as organizações estão buscando métricas mais sofisticadas que possam identificar tendências de mercado, avaliar a melhoria de processos, prever a concorrência e, em essência, medir a agilidade. A dinâmica dos negócios é uma delas. Momentum neste contexto pode ser expresso como o total de pontos de história para um lançamento multiplicado por sua linha do tempo.

À medida que uma organização se torna mais ágil, ela ganha impulso a cada lançamento. Os tempos de ciclo tendem a diminuir e as expectativas em torno da entrega crescem. O impulso dos negócios pode ser usado para o timing do mercado ou como um marcador para a saúde de uma determinada linha de produtos ou programa. Se o impulso começar a diminuir, isso é um indicador para a administração de que um determinado mercado está começando a se desenvolver e uma nova linha de produtos precisa ser desenvolvida. As organizações ágeis devem buscar continuamente novos mercados para se manterem competitivas.

Cobertura de código

Cobertura de código é uma medida de quanto do código está realmente sendo executado durante o teste. Isso geralmente é instrumentado e calculado como parte de uma estratégia de teste automatizada. A métrica deve fornecer a porcentagem geral de código executado durante cada fase de teste (unidade, sistema, etc.), bem como um total de todas as fases.

A cobertura do código não deve ser usada indevidamente como um marcador de quão bem um produto foi testado. Em vez disso, o objetivo dessa métrica é facilitar a automação de testes e monitorar a entrega contínua. As medições de garantia de qualidade devem incluir uma variedade de métricas, entre as quais as ocorrências de defeitos discutidas posteriormente.

Gráfico de controle

Às vezes chamado de gráfico de comportamento do processo ou gráfico de Shewhart, um gráfico de controle monitora o desempenho de um processo para determinar se está sob controle ou fora de controle – dependendo dos limites de controle superior, inferior e médio que foram definidos.

Esses limites são calculados estimando o desvio padrão dos dados da amostra, multiplicando esse desvio por três e adicionando-o à média para criar o limite superior e subtraindo-o da média para criar o limite inferior. O eixo Y do gráfico é o número de ocorrências ou problemas em uma amostra específica, enquanto o eixo X enumera cada amostra. As cartas de controle se originaram na fabricação como uma forma de controle de qualidade e existem há quase 100 anos.

Popular entre os discípulos de seis sigma, os gráficos de controle podem medir o fracasso ou o sucesso do controle de qualidade ou de outros processos de fabricação. Embora não popularizados no mundo ágil, os gráficos de controle podem ser usados ​​para medir os defeitos encontrados por iteração ou versão para identificar problemas de teste de QA ou para avaliar os tempos de ciclo em uma série de versões para garantir que estejam dentro dos níveis aceitáveis.

Diagrama de fluxo cumulativo

Um diagrama de fluxo cumulativo ilustra quanto trabalho, segmentado por tipo, está sendo alocado a uma equipe ao longo do tempo. Seu objetivo é monitorar o quão bem o trabalho está fluindo em todo o sistema. Neste diagrama, o trabalho é dividido em diferentes tipos, por exemplo: a fazer, em andamento e feito. Também pode ser dividido em requisitos, desenvolvimento, teste e assim por diante. Independentemente da segmentação, o fluxograma cumulativo mostra uma linha para cada tipo de trabalho, sendo o número de itens de trabalho no eixo Y e no eixo X uma função do tempo.

O bom fluxo é ilustrado por todas essas linhas funcionando em paralelo. Se uma das linhas sofrer uma alta acentuada ou cruzar outra, isso pode indicar um gargalo. Alcançar um bom fluxo é o conceito central por trás do Kanban. O diagrama de fluxo cumulativo ajuda a identificar gargalos para facilitar o fluxo contínuo e garantir que o WIP não fique fora de controle em nenhum ponto do sistema.

Tempo de ciclo

O tempo de ciclo pode ser definido como quanto tempo leva para produzir uma versão de software, desde o conceito até a conclusão. Juntamente com o lead time e a velocidade, o tempo de ciclo é um indicador de alto nível muito bom da saúde ágil e do sucesso da transformação ágil. À medida que uma organização progride em sua jornada ágil, os tempos de ciclo devem diminuir gradualmente, normalmente para seis meses ou muito menos. Aumentos no tempo de ciclo, especialmente quando observados consistentemente em uma ou duas versões, devem ser motivo de preocupação e revisão.

Burndown épico e de lançamento

Os gráficos de burndown épico e de lançamento são semelhantes ao sempre popular burndown de sprint discutido abaixo. Um gráfico de burndown ilustra quanto trabalho resta para um determinado período de tempo ou, neste exemplo, para um determinado épico. No desenvolvimento ágil, um épico é uma história de usuário maior composta de histórias de usuário menores ou pedaços de trabalho.

À medida que o trabalho é concluído, o número de histórias de usuário no épico é reduzido gradualmente até chegar a zero. Isso pode ser útil nos casos em que os marcos devem ser alcançados para atender aos requisitos contratuais e faturar o cliente. Da mesma forma, um burndown de versão pode rastrear o progresso do trabalho confirmado para uma versão específica. Isso pode ser usado para ajudar a garantir a entrega no prazo ou identificar a necessidade de alterar um prazo antecipadamente.

Implantações com falha

Uma implantação com falha é aquela que resulta em qualquer um dos seguintes:

• Serviço que afeta a interrupção
• Falha em atender às expectativas do cliente, muitas vezes resultando na rejeição do lançamento.
• Afeta seriamente a usabilidade, operação ou experiência do usuário do produto.
• Resulta em uma reversão para a versão anterior.

Obviamente, a taxa de implantação com falha, exibida como uma porcentagem do total de implantações, deve ser reduzida ao mínimo. Qualquer pico nessa métrica deve ser motivo de preocupação. Taxas de mudança e ocorrências de defeitos devem ser revisadas para isolar as causas-raiz.

Tempo de espera

O lead time mede o tempo que leva para concluir uma tarefa, desde o momento em que é criada até o ponto em que é finalizada. Em suma, identifica quanto tempo leva para fazer as coisas. Popular entre os praticantes de Kanban, essa métrica pode ajudar a identificar eficiências para mover tarefas mais rapidamente pelo sistema. Também pode ser usado como uma métrica de alto nível para determinar como a entrega contínua está funcionando. O tempo de entrega, juntamente com o tempo de ciclo e a velocidade, podem ser usados ​​juntos para fornecer uma visão holística do desempenho da entrega.

Pontuação líquida do promotor (NPS)

A pontuação do promotor líquido destina-se a ajudar a avaliar a satisfação do cliente. Geralmente é calculado com base em dados obtidos por meio de uma pesquisa. O objetivo é descobrir quantos clientes recomendariam seu produto. A porcentagem de respondentes que votam “não” é subtraída dos eleitores “sim” para criar a pontuação.

Além de medir a satisfação do cliente, o Net Promoter Score pode ajudar a identificar clientes mais dispostos a colaborar em produtos ou tecnologias inovadoras para lançamentos futuros. Esses clientes podem se tornar uma vantagem competitiva, pois seu feedback e suporte podem ajudar as empresas a colocar novos produtos no mercado antes da concorrência.

Inteligência de qualidade

No início do artigo discutimos o triângulo ágil e o papel que a qualidade desempenha nele. A inteligência de qualidade pode assumir muitas formas, mas normalmente é composta por uma variedade de métricas de rastreamento de defeitos. Os defeitos podem ser monitorados com base em onde e quando ocorrem, sua frequência e gravidade.

Uma das mais populares é a taxa de escape de defeitos, que é a proporção de defeitos encontrados pelo cliente para o número total de defeitos descobertos em uma versão. Embora um alto número de defeitos deva ser preocupante, não importa como eles sejam encontrados, é sempre melhor detectá-los antes que o cliente o faça.

Burndown do sprint

Os gráficos de burndown do sprint fornecem uma medida diária do trabalho concluído e do trabalho que ainda precisa ser feito em um determinado sprint. Ele compara a quantidade de trabalho concluído com as estimativas originais. Devido à natureza empírica do desenvolvimento ágil, o valor do gráfico de burndown é bastante limitado.

Apesar de sua popularidade, muitos coaches ágeis estão deixando de usá-lo tanto quanto antes. Ele pode servir como um bom guia ou ponto de status para onde as equipes de desenvolvimento se posicionam em relação aos seus compromissos, mas deve ser usado em conjunto com outras métricas para obter uma visão geral do que está acontecendo.

Taxa de transferência

A quantidade de produto (número de itens de trabalho) entregue ao cliente por uma determinada unidade de tempo é chamada de rendimento. Isso pode ser medido mensalmente, trimestralmente, por versão, iteração e assim por diante. O valor dessa métrica é que ela pode ser usada para determinar quanto software pode ser entregue em um período de tempo específico. Ele também pode ser usado para rastrear a consistência da entrega de uma perspectiva organizacional e de equipe.

A análise empírica de dados históricos pode ser usada para prever o desempenho da entrega. Quanto mais dados históricos estiverem disponíveis, mais precisas serão as projeções. Mais importante, essa métrica também pode ser usada para prever receita, uma vez que o valor da funcionalidade do recurso entregue é bem compreendido em termos financeiros. Para que essa métrica funcione, a definição de “pronto” deve ser bem definida. Somente o software entregue ao cliente atende a esse requisito.

Valor entregue

No início do artigo discutimos como o valor consiste na qualidade extrínseca, ou seja, na percepção do produto pelo usuário final. Como o produto impacta o negócio do cliente? Boas métricas ágeis são baseadas em resultados e, no mundo dos negócios, normalmente se traduzem em dólares e centavos. Assim como atribuímos pontos de história a cada história de usuário como forma de estimar o trabalho necessário, também podemos adicionar pontos de valor como uma medida relativa para indicar o que o usuário final está obtendo quando o trabalho é concluído.

Uma maneira de fazer isso é com um gráfico de queima que ilustra o número de pontos de valor acumulados à medida que cada história é concluída. Pontos de valor podem ser atribuídos a cada história ou recurso com base na percepção do cliente à medida que os critérios de aceitação estão sendo criados. A receita esperada (ou dinheiro economizado) para o cliente no projeto pode ser dividida pelo número total de pontos de valor na versão.

Por exemplo, se há 200 pontos de valor em um projeto e espera-se que o cliente ganhe 1 milhão de dólares em receita, então cada ponto de valor vale US$ 5.000. A soma total de cada história e seu valor acumulado podem ser ilustrados no gráfico de queima. Embora o impacto real do produto possa não ser aparente até que ele seja lançado, esse método pode fornecer inteligência financeira convincente tanto para a administração quanto para os clientes.

Velocidade

A velocidade é provavelmente a primeira métrica sobre a qual a maioria de nós ouve falar depois de ser apresentado ao desenvolvimento ágil. Embora indiscutivelmente a métrica ágil mais popular, também é a mais mal utilizada. As equipes de sprint são notórias pela velocidade do jogo porque são muito utilizadas para relatar seu desempenho. A velocidade é definida como a quantidade de software produzida em cada iteração, ou sprint. Essa quantidade geralmente é expressa como pontos de história e o software produzido deve ser uma fatia de código funcional pronta para produção.

As equipes geralmente jogam a velocidade manipulando o tamanho e a estimativa de histórias de usuários ou decompondo o trabalho horizontalmente, em vez de verticalmente, criando histórias para alterações de banco de dados, trabalho de front-end, middleware e muito mais. para eliminar dependências de outros e obter crédito por concluir o trabalho. O problema com essa abordagem é que esses tipos de histórias de usuários são realmente tarefas e, embora as equipes recebam crédito, o valor comercial para o cliente não foi entregue.

A velocidade do jogo pode ser evitada usando uma série de outras métricas como verificação e equilíbrio entre si. Muitas vezes, as organizações confiam apenas na velocidade ou em um conjunto muito pequeno de métricas, em vez de um conjunto maior de medidas, para formar uma solução de gerenciamento de PPM, programa e projeto.

Vorticidade (ágil)

Uma pergunta com a qual muitos agilistas e gerentes de projeto lutam é “quão ágeis somos?” Na verdade, a busca pela resposta para medir a agilidade em si tem sido o santo graal dos agilistas em todos os lugares. A vorticidade ágil é uma nova medida que faz exatamente isso. Com base em mais de 10 anos de pesquisa de estudo de caso, a vorticidade ágil foi desenvolvida por meio de um método qualitativo sofisticado chamado teoria fundamentada.

Usando um conjunto abrangente de medidas, a agilidade do mercado e do processo organizacional pode ser comparada entre si para determinar sua vorticidade ou ponto em que convergem. Vorticidade zero significa que a agilidade da organização está à altura do mercado. Alta vorticidade significa que o mercado está se movendo muito mais rápido do que sua organização ou equipes e, portanto, há muito trabalho a fazer. O infográfico abaixo demonstra esse relacionamento usando um experimento mental de redemoinho para ilustrar os mercados hiper-acelerados de hoje.

Idade do item de trabalho

Um item de trabalho pode ser definido como um pacote de trabalho, recurso utilizável ou, como seria na maioria dos contextos ágeis, uma história de usuário. O relógio começa a contar a idade de um item de trabalho assim que ele é concebido. O rastreamento da idade dos itens de trabalho, estejam eles em andamento ou no backlog, pode ajudar a identificar problemas com os requisitos.

Se um item de trabalho parece estar ficando mais velho do que seu parente porque está sendo empurrado de um sprint para outro, pode haver um problema de decomposição. Talvez precise ser redefinido ou melhor compreendido? Os itens de trabalho que ficam no backlog por longos períodos podem precisar ser selecionados ou redefinidos.

A preparação contínua do backlog é fundamental para o planejamento e a priorização do sprint. Um número crescente de requisitos antigos no backlog pode significar problemas com a forma como os requisitos estão sendo desenvolvidos e decompostos. O gerenciamento de requisitos deficiente é uma das principais causas de falha nas transformações ágeis.

Requisitos mal escritos podem tornar a priorização e a estimativa extremamente difíceis, resultando em dívida técnica fora de controle, baixa utilização de recursos e perda financeira. Desenvolver requisitos bem compreendidos, priorizados e de alto valor é muito mais uma forma de arte e mal compreendido até mesmo pelos melhores agilistas. Na verdade, é sem dúvida um dos maiores bloqueadores para o sucesso da transformação ágil.

Conclusão

Neste artigo, estabelecemos a base para métricas ágeis, a necessidade de uma solução abrangente e 17 recomendações para criar uma. Quer você use todas as medidas discutidas ou apenas um subconjunto, é importante que qualquer solução considere o público-alvo dos dados. Algumas métricas, como velocidade, são melhor mantidas nas equipes de scrum. Outras métricas, como vorticidade ágil e impulso de negócios, são projetadas para gerenciamento executivo ou de produto, respectivamente.

Certifique-se sempre de entender e comunicar com precisão o que as métricas estão dizendo e seguir para onde os dados levam. Uma maneira de impulsionar e dar suporte a boas métricas é com uma estrutura ágil robusta.