A comunidade ágil precisa mudar o modo como mede sucesso. Tanto os dados coletados quanto as informações resultante das análises destes dados são, hoje, obstáculos ao que realmente importa: o desenvolvimento de software que funcione. Dar foco a algumas métricas individuais pode desencorajar a colaboração dentro da equipe e afetar o que se está medindo, prejudicando o propósito da métrica. Dois problemas principais podem ser citados, o efeito do observador e o efeito luz do poste.
Efeito do observador
Diz-se que a simples observação de um processo pode alterar seu comportamento. Comunicar à equipe, por exemplo, que a velocidade será acompanhada de perto pode fazer a equipe sobrestimar os itens com o intuito de aumentar a velocidade. Trata-se de algo especialmente perigoso quando se trabalha com pontos de história, já que não há como conferir a validade de uma estimativa.
A tirinha acima (fonte) mostra um exemplo do efeito do observador. Há, porém, um exemplo melhor: em um callcenter, um técnico costumava ajudar os colegas em ligações difíceis tecnicamente e as resolvia de forma correta, geralmente na primeira ligação. Os feedbacks dos clientes eram positivos, mas a duração das ligações era longa e a gerência dava importância muito grande para a métrica de duração das chamadas. Após ser ameaçado com a perda do emprego caso não baixasse os tempos das ligações, o técnico logo se colocou entre os cinco melhores na métrica de rapidez. Mas o resultado foi obtido em detrimento do objetivo do negócio: o técnico passou a chegar uma hora mais cedo ao trabalho, e atendia ligações e imediatamente as desligava.
Esse comportamento não teria ocorrido se a métrica de ligações curtas não tivesse sido considerada mais importante que o próprio desempenho do funcionário. Medir os tempos de ligação afetou o resultado negativamente. Era uma métrica infeliz. Mesmo em casos não tão extremos quanto o citado, é comum ligar para o suporte e perceber que tudo que o atendente quer é finalizar a ligação. A questão fundamental é saber, portanto, quais ligações a equipe está desligando para conseguir atingir as metas?
Efeito luz do poste
Os seres humanos possuem a tendência de procurar respostas onde é mais fácil e não onde provavelmente a resposta estaria. Número de linhas de código é algo fácil de se obter, mas não nos diz nada sobre a qualidade da aplicação, da funcionalidade, nem da sua efetividade. Veja um exemplo na figura abaixo (fonte).
Trabalhei em uma equipe que lidava com diversos produtos, cada um com diferentes padrões de qualidade. O produto A possuía padrões de qualidade muito mais difíceis de se cumprir que os do produto B, C ou D. Isso não seria um problema normalmente, mas se tornou um problema, dado o foco excessivo da gerência em qualidade, ao avaliar os resultados
Qualidade é um conceito subjetivo e difícil de se medir. Taxa de defeitos é muito mais fácil de medir. Como os padrões do produto A eram mais elevados, havia mais possibilidade de a taxa de defeitos ser maior, ainda que com a mesma qualidade que os outros produtos. Por isso, o produto acabou sendo desenvolvido por estagiários, temporários e terceirizados.
A taxa de defeitos, apesar de fácil de medir, não gerava informações de valor, pois o número de defeitos era muito mais ligado ao produto do que às pessoas realizando o trabalho. Ao dar ênfase demasiada nessa métrica, acabamos inconscientemente optando por desperdiçar boas oportunidades de contratação. Perdemos um cliente, e ainda baixamos a moral da equipe, pois o trabalho se tornou menos voltado a "fazer algo de valor" e mais voltado a "evitar erros".
Vamos aplicar, agora, estes conceitos a algumas métricas ágeis comuns:
Quantidade de testes unitários escritos: A maioria dos desenvolvedores ágeis escreve testes unitários; o desenvolvimento orientado a testes (TDD) leva à codificação de ainda mais testes (ambos levam à produção de código de melhor qualidade). Assim pode ser uma boa ideia medir a produtividade dos desenvolvedores com base no número de testes criados. Na realidade, o Efeito do Observador faz com que o desenvolvedor, caso saiba que está sendo medido pelo número de testes escritos, preocupe-se em gerar o maior número possível de testes, sem se preocupar com a qualidade destes. Mas como o objetivo é criar software que funcione e não a entrega de testes, é preferível ter menos testes, porém com boa qualidade.
Velocidade individual: A velocidade é outra métrica ruim, devido ao Efeito do Observador. Caso um desenvolvedor saiba que seu desempenho está sendo medido apenas por itens com os quais trabalhou diretamente, diminui o empenho em contribuir com o grupo. Chega-se a uma situação muito pouco ágil: a de competir ao invés de contribuir com a equipe.
Em um ambiente perfeito, uma equipe ágil colabora, interage, discute e revisa praticamente todo o seu trabalho. Isso é benéfico na construção de software de qualidade e na resolução rápida de problemas, mas torna quase impossível separar a produtividade individual da coletiva. O melhor é não tentar fazer essa separação, pois o resultado será o de prejudicar a capacidade da equipe em criar software de qualidade.
Velocidade de equipe: Trata-se de uma das métricas mais mal compreendidas do Scrum. A velocidade de uma equipe é apenas dela; não pode ser comparada com a de outras equipes. Suponhamos que duas equipes estimem o mesmo esforço de trabalho para uma iteração, uma em 50 pontos e a outra em 150. Digamos que ambas concluam suas iterações com sucesso, entregando 50 e 150 pontos respectivamente. Qual equipe foi mais produtiva? Nenhuma, pois ambas concluíram a mesma quantidade de esforço de trabalho.
Essa métrica é particularmente perigosa, pois encoraja as equipes a adulterar as estimativas, o que pode prejudicar a habilidade em planejar a próxima iteração. Se a equipe não for capaz de estimar devidamente uma iteração, o lançamento pode ser atrasado.
Então, quais métricas deveríamos utilizar?
A produtividade deve ser medida por entrega de software funcionando. Medimos a produção, e não os fatores que contribuem para a produção. Essa é uma abordagem mais ágil, porque libera a equipe para construir software da maneira que melhor contribui para o sucesso - e não para obter melhores resultados em certas métricas. É muito mais lógico medir o software entregue, pois ele é o que gera retornos financeiros.
Quais seriam estas novas métricas, então?
Valor entregue: Peça a seu Product Owner (PO) que, para cada história de usuário, estime um valor que represente o impacto para as partes interessadas (stakeholders). Esse valor pode ser monetário ou qualquer outro número. Ao final de cada iteração, haverá um número indicativo do valor entregue aos clientes, na visão do PO.
Essa métrica não mede desempenho, mede impacto. Idealmente, seu PO priorizará os itens de maior valor, para que cada iteração entregue o máximo de valor possível. Caso se esteja trabalhando com um projeto (com começo, meio e fim), as iterações começarão entregando um valor alto e tenderão gradualmente a produzir menor valor, conforme se consome o backlog. Em algum ponto, o custo do desenvolvimento terá superado o valor potencial de executar mais uma iteração. Este é um bom momento para realocar a equipe em outro produto.
Entregas na data: Muitos alegam que a adoção do Agile falhou nas suas empresas devido à incapacidade de oferecer datas de entrega mais precisas para seus clientes. No entanto, as equipes ágeis devem ser capazes de entregar software em prazos determinados. É possível que algumas poucas histórias não sejam implementadas, mas elas serão em geral as de menor valor, com menor impacto para o cliente. A velocidade de uma equipe deve ser razoavelmente constante; a variação, se houver, deve ser gradual. Variações drásticas na velocidade entre iterações prejudicam a capacidade de planejamento de longo prazo.
Explico a métrica com exemplos. Se uma equipe prevê a entrega de cinco histórias até o final da iteração e a entrega inclui exatamente as cinco histórias, a equipe recebe dois pontos para a métrica. Caso entregue quatro histórias ou entregue dois dias antes, ganha um ponto. Se entregar mais de dois dias antes, ou menos de quatro das cinco histórias, nenhum ponto é recebido. Ao final de um trimestre ou no fim de uma release, ou mesmo depois de um ano, a equipe será julgada pela acurácia de suas previsões para as iterações.
O que sugerimos medir, portanto, é o valor entregue ao cliente e a entrega de software nas datas previstas. Isso porque são as únicas métricas que realmente trazem algum benefício ao produto - mas sem estimular comportamentos que prejudiquem o projeto.