Quais métricas devem ser comunicadas à gerência em um ambiente ágil de desenvolvimento de software?
Na mailing list do Scrum Development, Charles Bradley questionou:
Um departamento tem 3 times de desenvolvimento que reportam para um gerente sênior. Este gerente sênior reporta juntamento com alguns outros para um VP.
Quais métricas, se houverem, você sugeriria para relatório de equipe para o Sr. Mgr.?
Quais métricas, se houverem, você sugeriria para relatório do Sr. Mgr. até o VP?
George Dinwiddie propôs um solução simples: pergunte a gerência quais métricas eles consideram valiosas. No caso deste exemplo, a gerência nao sabe quais tipos de métricas eles querem. Eles têm receio de pedir métricas que quebrem os princípios e o espírito do Scrum, e eles estão pedindo um conselho ao Bradley.
Existem qualquer tipo de métricas que definitivamente não deveriam ser informadas a gerência em um ambiente ágil de desenvolvimento de software?George Dinwiddie escreve:
No geral, não reporte números brutos. Aquelas pessoas fora do ambiente do trabalho muitas vezes não tem o contexto para interpretá-las razoavelmente. E, gestores superiores não tem tempo para fazer a análise eles mesmos.
Especialmente, de acordo com Dinwiddie, a velocidade do time é um dos número que nao devem ser reportados a gerência. Estimativas sobre o futuro devem ser enviados ao invés de números de velocidade.
Ron Jeffries diz que qualquer métrica cuja intenção é comparar a produtividade entre times é um má idéia:
Tanto faz o que você mede, mesmo que fosse em dólares as receitas recebidas, isto não pode ser usado para avaliar a "produtividade" das equipes comparativa. Isso não funcionará. Isso não pode funcionar. Eu quero dizer não pode, no sentido que uma pedra não pode flutuar no ar sem um suporte. Eu quero dizer não pode, no sentido que um gato não poder construir uma ponte.
Um vendedor de carros vende 30 carros em um mês. Um corretor de imóveis vende três casas em um mês. Qual é mais produtivo, e o que um deveria fazer para tornar-se produtivo tão produtivo quanto o outro?
Então quais tipos de métricas devem ser enviadas para a gerência? Uma abordagem, sugerida por "karatasfamily", é considerar as questões que a gerência tem sobre qualquer projeto de desenvolvimento de software, ágil ou não, e então fornece métricas que dê respostas para estas questões. Algumas simples questões podem ser:
- O que vocês estão fazendo?
- Quando vocês estão fazendo?
- Vocês estão no cronograma?
- Vocês estão dentro do orçamento?
Com esta filosofia, o fato é que um projeto ágil é mais encapsulado da gerência. As métricas de projetos ágeis são projetadas para estar em conformidade com os formatos de relatórios das gestões atuais, ao invés da gerência ter que aprender uma nova maneira. Essa atitude para com as métricas é similar as descritas no livro de Ken Schwaber: Agile Project Management with Scrum.
least-wasteful metric, though, is the one that never has to be created in the first place. In his book How to Measure Anything, Douglas W. Hubbard says,
A última métrica com menos disperdício, embora, é uma que nunca deve ser criada em uma primeira vez. Em seu livro How to Measure Anything, Douglas W. Hubbard diz,
Se a métrica existe é porque ela deve ter algum efeito aceitável na decisão e comportamento. Se nós não podemos identificar quais decisões podem ser afetadas pela métrica proposta e quanto esta métrica poderia afetar nestas decisões, então a métrica simplesmente não tem valor.
Por padrão, toda métrica proposta - em ambientes ágeis ou não - devem ser contestadas com a questão, "Qual é a decisão que esta métrica apoiará?" Se nenhuma decisão será afetada por está métrica, então a métrica é inútil e não deveria se reportada.
E você leitor, que tipo de métricas expõe para seus gestores? Concorda com isso?