Consultures e Agile Coaches frequentemente alertam a seus clientes que métricas tradicionais como Valor Agregado, Horas Trabalhadas, Linhas de Código, Cobertura de Código por Testes não são muito adequadas a Projetos Ágeis. Mas então nossos clientes ficam com a pergunta sobre o que vem a ser uma boa Métrica Ágil? Como poderíamos distinguir uma métrica boa de uma ruim? Existem contextos em que uma métrica boa torne-se ruim?
Obviamente, a métrica clássica para uma Equipe XP/Scrum é a velocidade, ou o quanto do trabalho a equipe concluiu na última iteração? Tal métrica foi originalmente criada para ajudar uma equipe a decidir o quanto deve ser planejado para a próxima iteração. Entretanto, a questão é frequentemente deturpada para: podemos usar a velocidade para medir a produtividade de uma equipe? Ou ainda para comparar duas equipes? Hiren Doshi, destaca que a velocidade é uma métrica muito específica da 'equipe'. Adicionalmente, o Consultor Ágil, Peter Stevens, questiona se as equipes deveriam ter um motivo para lidar com esta medida: "Questionar-se se esta é uma história 2 ou uma 3 é algo que depende puramente do julgamento da equipe. Se a equipe sentir a necessidade de entregar o máximo de pontos por história possível, isto afeta o julgamento e ela passa a ser uma história três, ou talvez até uma cinco."
Dave Nicolette, um Agile/Lean Coach, nos alerta que métricas mal concebidas nos levam a maus resultados. Por exemplo, práticas que incentivem os desenvolvedores a caçar bugs e apagar incêndios acabam resultando em pessoas que introduzem bugs e iniciam incêndios.
No artigo Appropriate Agile Measurement, a Agile Coach Deborah Hartmann Preuss e o Consultor de Gestão Agile Robin Dymond, oferecem algumas heurísticas para se identificar boas métricas ágeis:
- Afirmam e reforçam os princípios de Lean e Agile
- Medem os objetivos, não as saídas
- Buscam tendências, não números
- Pertencem a um pequeno conjunto de métricas e diagnósticos
- São fáceis de coletar
- Revelam, mais do que escondem, o seu contexto e as variáveis significativas
- Fornecem assunto para uma conversação significativa
- Podem medir Valor (Produto) ou Processo
- Incentivam o nível de qualidade do "suficientemente bom"
E o que são boas métricas ágeis?
Ron Jeffriesapresenta como métrica as Características Testadas e em Execução, ou Running Tested Features, RTF:
- O software é subdividido em termos de suas características (requisitos, histórias) que são parte do que se pretende entregar para o sistema desejado.
- Para cada uma das características, há um ou mais testes de aceitação automatizados e que, quando eles funcionam, evidenciam que a característica em questão está implementada.
- A métrica RTF mostra, a cada momento, quantas características do software estão passando em todos os seus testes de aceitação.
Já o Scrum Coach, Peter Hundermark, aponta que a métrica de Testes Automatizados em Execução (Running Automated Tests) é aquela que mede:
Dentro de alguns limites, quanto mais testes automatizados em execução (i.e., que estejam passando) uma equipe estiver num momento é uma medida positiva
de qualidade. Se extrapolado além de um determinado nível, isto pode deixar de ser verdade, mas nós ainda estamos por conhecer uma
equipe que tenha chegado neste cenário. (Mas esperamos que aconteça!)
...
Curiosamente, esta foi uma das principais métricas que o salesforce.com utilizou durante sua
transição para Agile.
Peter fala também sobre o trabalho em andamento:
Itens (histórias) em andamento é uma métrica de produtividade. Ela visa ajudar uma equipe a identificar se
estão trabalhando colaborativamente ou não. Dentro do possível, uma ideia em uma equipe ágil deve ser para a equipe toda,
para colaborar em um único item de trabalho até que ele esteja 'pronto'. Isto aumenta a
a taxa de entrega, a qualidade e o aprendizado mútuo, e também diminui o risco de se ter itens não finalizados ao final
do Sprint, que significa desperdício.
Fazendo monitoramentos apenas diários de quantos itens a equipe estão em andamento pode dar
uma ideia de seu grau de colaboração. Um gráfico relacionando as histórias em andamento por dias de trabalho. Isto
não precisa necessariamente se ater ao período do Sprint. Isto deve tender para 1 ao longo do tempo. Qualquer valor maior que 2
demandar uma ação do ScrumMaster.
Por fim, Deborah e Robin nos lembram que ao se definir uma métrica, devemos considerar não apenas sua utilização, mas quando parar de usá-la e no que ela pode ser útil.
Veja também no InfoQ: Metrics in an Agile World e Agile EVM