As métricas ágeis são instrumentos de avaliação que acompanham o avanço e o êxito de um grupo de trabalho em projetos ágeis.
Quando definidas corretamente, essas métricas revelam informações sobre o desempenho, a qualidade, a eficiência dos testes e a eficácia geral da equipe, bem como sua evolução ao longo do tempo.
O propósito principal das métricas ágeis é auxiliar as equipes na identificação de pontos de melhoria e na tomada de decisões baseadas em dados que impulsionem a criação de produtos superiores à medida que a equipe progride.
Frequentemente, as empresas estabelecem métricas superficiais ou números brutos, com progressão linear da esquerda para a direita. Embora esses números possam parecer atraentes em alguns painéis, geralmente são inúteis para a própria equipe.
O objetivo dessas métricas não é auxiliar a equipe de forma alguma, mas sim preencher relatórios para a liderança, culminando em decisões estratégicas. Infelizmente, a equipe frequentemente não compreende a razão por trás dessas decisões.
Na ânsia de alcançar essas métricas equivocadas, as equipes manipulam seus processos, visando apresentar resultados aparentemente positivos. Contudo, a produtividade da equipe permanece estagnada.
Métricas Essenciais
Existem várias formas de classificar as métricas. Uma das mais básicas é a abordagem de cima para baixo versus de baixo para cima.
➡️ Top-down: Nesta abordagem, os líderes definem as métricas que consideram relevantes para todos, sendo o objetivo principal da equipe alcançar as metas estabelecidas. A opinião da equipe sobre essas métricas não é levada em consideração, pois o foco é o rastreamento de dados.
➡️ Bottom-up: Aqui, a equipe identifica as áreas que necessitam de aprimoramento e define as métricas que possibilitarão o acompanhamento do seu progresso em direção aos objetivos. Assim, a equipe pode demonstrar à liderança como seu trabalho melhorou ao longo do tempo.
Definindo uma Boa Métrica
Quais características uma boa métrica deve ter e como descrevê-la?
A característica mais importante é a capacidade de promover mudanças no comportamento. Ou seja, ao analisar os resultados da métrica, deve ficar claro o que a equipe precisa ajustar para obter melhorias.
Além disso, a métrica deve ser simples. Se não for possível explicá-la em poucas frases para que todos os interessados a compreendam, ela precisa ser repensada.
Uma boa métrica é comparável ao longo do tempo. Ao analisar os resultados em diferentes momentos, é necessário conseguir estabelecer comparações entre eles. Caso contrário, a métrica precisa ser reavaliada.
Por fim, sempre que possível, prefira usar proporções ou porcentagens em vez de números brutos. Por exemplo, “10 novos defeitos abertos durante o sprint” não fornece informações úteis. O significado desse número depende de quantos defeitos são abertos normalmente.
Apresento a seguir alguns exemplos de métricas que considero que atendem a esses critérios. Elas são voltadas para equipes ágeis e se dividem em três categorias principais: desempenho, qualidade e moral.
Categorias de Métricas
Métricas de Desempenho
O objetivo aqui é avaliar a capacidade da equipe de cumprir as tarefas acordadas durante um sprint. É importante verificar se o excesso de compromisso é um problema recorrente ou se a transição de tarefas é um padrão a cada sprint.
Em termos de desempenho ágil, a equipe deve se esforçar para entregar o conteúdo do sprint planejado, com o qual se comprometeu no início do sprint.
Isso não significa que não podemos ser flexíveis na troca de tarefas durante o sprint. Mas qualquer alteração deve ser resultado de uma negociação, não de acréscimos. A capacidade da equipe não aumentará simplesmente porque novas tarefas foram adicionadas durante o sprint.
Essa métrica visa monitorar esses casos e orientar a equipe a proteger a sua capacidade durante o sprint.
Isso aumenta a confiabilidade e a previsibilidade da equipe.
#1. Capacidade do Sprint vs. Pontos de História Entregues
Analise o histórico da capacidade do sprint em relação aos pontos de história entregues ao longo dos sprints.
- Pequenos desvios entre sprints são normais. Grandes variações em qualquer direção indicam que algo está errado.
- A Capacidade Total do Sprint é calculada somando-se os dias disponíveis de cada membro da equipe. Por exemplo, se uma equipe tem 10 pessoas e todos estão disponíveis durante todo o sprint, a capacidade total será de 100.
Compare a capacidade do sprint com os pontos de história concluídos em cada sprint. Se a equipe estiver se comprometendo com um número significativamente maior de pontos de história do que normalmente consegue concluir, esse risco deve ser levado em consideração.
O objetivo deve ser que o total de pontos de história planejados seja igual ou inferior ao total de pontos de história concluídos por sprint.
É possível ter mais pontos de história concluídos do que planejados caso a equipe conclua todas as tarefas planejadas e ainda tenha capacidade para assumir tarefas adicionais.
- Se a equipe entregar consistentemente menos pontos de história do que o planejado, é necessário ajustar o planejamento e reduzir a carga para o próximo sprint.
Ferramentas como monday.com, Atlassian Jira ou Asana facilitam o registro e a extração dos pontos de história de cada tarefa nos sprints. Elas podem até gerar essa informação automaticamente após o planejamento de cada sprint.
#2. Gráfico de Burndown
Este gráfico é uma métrica comum em muitas equipes scrum, muitas vezes presente em algum lugar do painel. Alguns podem considerá-lo inútil, e a equipe raramente o leva em conta. Em vez disso, os gerentes geralmente se concentram em como as tarefas parecem incompletas, já que muitas vezes permanecem abertas durante todo o sprint.
Entretanto, como equipe, você deve verificar o gráfico de burndown para seu próprio benefício. Se todas as tarefas são deixadas em aberto durante todo o sprint e só fechadas no último dia, isso gera incerteza na equipe quanto ao cumprimento dos objetivos do sprint.
- Analise o quadro do sprint para as tarefas concluídas.
- Converse com a equipe para entender por que algumas tarefas pequenas permanecem em aberto, mesmo tendo começado no início do sprint.
- Incentive a equipe a não manter as tarefas abertas por mais tempo do que o necessário.
- O gráfico de burndown ideal é geralmente um conceito teórico. No entanto, quanto mais nos aproximarmos dele, mais eficiente será o gerenciamento das tarefas.
Ferramentas de gestão ágil como o Asana podem gerar um gráfico de burndown automaticamente para cada sprint.
Fonte: asana.com
#3. Conclusão da Meta do Sprint
Esta métrica rastreia a porcentagem de metas de sprint que foram alcançadas durante cada sprint.
As Metas do Sprint devem ser documentadas separadamente, por exemplo, em uma página do Confluence/Jira, para cada sprint. O status deve indicar se a meta foi alcançada ou não dentro do sprint.
Mesmo que a equipe não conclua todas as tarefas dentro de um sprint, ela pode atingir a meta do sprint (por exemplo, faltando apenas tarefas secundárias).
O objetivo é atingir 100% das Metas do Sprint a cada sprint. Se isso não acontecer, é fundamental identificar o que está impedindo a equipe.
- Se houver muitas tarefas paralelas em cada sprint, reduza o número delas.
- Se muitas tarefas ad hoc forem adicionadas durante o sprint, reduza-as para que não afetem os objetivos originais do sprint.
- Se as metas do sprint forem muito ambiciosas, simplifique-as. Não faz sentido ter metas grandes que não serão atingidas no final do sprint.
Métricas de Qualidade do Código
O objetivo aqui é monitorar a qualidade do código ao longo do tempo. Isso ajuda a manter processos de desenvolvimento saudáveis e reduz o tempo gasto na resolução de problemas ou o tempo ocioso dos desenvolvedores causado pela espera na execução do código durante as atividades de desenvolvimento e teste.
Fonte: azuredevopslabs.com
#1. Testes Automatizados
Implemente testes unitários automatizados para cada alteração de código feita pelos desenvolvedores.
- Meça a cobertura do código por testes automatizados, utilizando ferramentas como Azure Pipelines ou SonarCloud. O objetivo é alcançar uma cobertura de 85%. Uma cobertura acima de 90% pode não ser eficiente.
- Certifique-se de que a criação de testes unitários automatizados faça parte da definição de “concluído” para as novas tarefas.
- Acompanhe a cobertura de teste de código antigo como parte das tarefas de dívida técnica no backlog.
#2. Complexidade do Código
Avalie o aumento desnecessário da complexidade do código ao longo do tempo e corrija-o por meio de tarefas de dívida técnica ou evite que ele ocorra sempre que possível.
Defina padrões e diretrizes de código para educar os desenvolvedores sobre como segui-los. Certifique-se de que eles sigam as regras de codificação para minimizar o aumento desnecessário na complexidade do código. Atualize regularmente as diretrizes com base na experiência da equipe.
Identifique Code Smells – indicadores de possíveis problemas no código, como código duplicado, métodos longos e variáveis não utilizadas.
As revisões de código por pares devem garantir que os padrões de código sejam aplicados ao código recém-criado.
Utilize ferramentas como painéis e relatórios do Azure Ado ou SonarCloud para detectar problemas de código.
#3. Etapas Manuais na Implantação
Monitore quantas etapas manuais a equipe precisa executar para liberar o código em ambientes de teste ou produção.
- O objetivo é alcançar zero etapas manuais ao longo do tempo.
- Crie tarefas de dívida técnica, se necessário, para automatizar o pipeline de implantação/liberação. Reduza gradualmente as etapas manuais restantes nos processos a cada sprint.
Métricas de Moral
Esta métrica visa acompanhar como a equipe se sente em relação ao seu trabalho e aos processos com os quais lida diariamente.
#1. Cumprimento Retrospectivo do Sprint
Monitore quantos itens de ação foram realmente concluídos no próximo sprint.
- O Scrum Master deve registrar os resultados da reunião Retrospectiva nas páginas da equipe para rastrear os itens de ação acordados.
- A equipe então acompanhará o progresso desses itens.
- O gerenciamento de projetos poderá verificar se os itens de ação estão progredindo e identificar o que está impedindo a equipe de concluí-los. Em seguida, crie um ambiente que permita que a equipe avance com os itens de ação acordados.
Pelo menos 33% ou 1 (o que for maior) dos itens de ação do sprint anterior devem ser adotados nos próximos sprints.
Se esse percentual for menor, é necessário fazer ajustes para permitir que a equipe implemente as melhorias acordadas.
As ferramentas de gerenciamento de projetos oferecem modelos prontos para atividades de retrospectiva de sprint. Aqui está um exemplo de monday.com:
Fonte: monday.com
#2. Colaboração em Equipe
Promova a programação em pares.
- Forme pares naturais por tarefa para que os membros trabalhem juntos, compartilhando conhecimento e experiências. Crie subtarefas em histórias pertencentes a diferentes membros da equipe.
Monitore as revisões de código por colegas.
- Incentive os colegas a revisar proativamente o código de outras pessoas.
Essa métrica pode ser extraída do quadro monday.com/Asana/Jira por meio das subtarefas.
Pelo menos 50% das tarefas do sprint devem ser compartilhadas entre os membros da equipe. Se esse número for menor, investigue os motivos e tome as medidas cabíveis.
Para as revisões de código voluntárias, rastreie as tarefas com subtarefas dedicadas. Começar com 20% das tarefas revisadas dessa maneira é um bom ponto de partida. Gradualmente, ao longo dos sprints, incentive a equipe a trabalhar de forma mais colaborativa e aumente esse percentual para 50% das tarefas de código por sprint como meta.
#3. Dívida Técnica vs. Novas Tarefas de Funcionalidade
Fonte: atlassian.com
Oferecer à equipe a oportunidade de resolver suas próprias tarefas de dívida técnica aumentará a satisfação com o trabalho.
- Por outro lado, o acúmulo de dívidas técnicas sem um plano para resolvê-las progressivamente irá desmotivar a equipe ao longo do tempo. E a solução se tornará mais instável, complexa e difícil de resolver sem retrabalho substancial.
A equipe sabe melhor o que não está funcionando bem na solução, mesmo que as partes interessadas ou os usuários finais não percebam. Essas tarefas têm o maior impacto na própria equipe de desenvolvimento. Para as partes interessadas, elas podem ser invisíveis. Por isso, é fundamental oferecer à equipe a oportunidade de trabalhar em tarefas que os ajudem a organizar as atividades de desenvolvimento.
O objetivo é acompanhar quantas tarefas de dívida técnica levantadas são resolvidas ao longo do tempo e se o acúmulo dessas tarefas só aumenta ou não.
A equipe pode marcar as tarefas como “TechDebt” no backlog e dar a elas prioridade para que elas possam ser selecionadas nos sprints.
Dependendo do estado do projeto e de quantas dívidas técnicas são identificadas no backlog, o ideal é garantir que o backlog de TechDebt não cresça mais de 10% de sprint para sprint.
Priorize as tarefas de dívida técnica e inclua-as nos sprints para controlar o crescimento do backlog e garantir que a equipe trabalhe nessas tarefas por 10 a 20% do tempo de cada sprint.
Considerações Finais
Eventualmente, todo projeto precisará de algumas métricas, seja por solicitação da liderança ou por decisão da equipe para avaliar seu próprio sucesso.
O ideal é começar a construir sua biblioteca de métricas o quanto antes, para que elas possam ser escolhidas e usadas quando necessário. Ao fazer isso, certifique-se de priorizar métricas que promovam mudanças no comportamento.
Finalmente, fique atento a processos não saudáveis que podem prejudicar o seu sprint.