BT

A velocidade está matando o Agile?

por Michael Floyd , traduzido por Paulo Rebelo em 16 Nov 2011 |

Jim Highsmith, um dos signatários originais do Manifesto Ágil, escreveu em seu blog um artigo intitulado "A velocidade está matando o Agile", onde comenta sobre a atual fixação dos gerentes em usar a velocidade como medida de produtividade.

Os gerentes se tornaram maníacos em medir a velocidade: velocidade do time, velocidade entre times, velocidade organizacional, ou até mesmo velocidade por desenvolvedor.

Highsmith destaca que a velocidade está cada vez mais sendo utilizada para medir a produtividade, e é fácil entender a razão. Qualquer medida de produtividade que ajuda na identificação do que está funcionando e do que não está permite os ajustes correspondentes. Além disso, informações de velocidade são facilmente coletadas e fáceis de calcular, e a velocidade é vista como uma medida do volume de saída. Mas, Highsmith adverte que a medida se concentra muito no volume de pontos das histórias (story points) entregues: esse volume diminui a qualidade da experiência entregue ao cliente, focando em vez disso no que ele chama de "máquina de entregas."

Agravando esse problema, o movimento Agile tem se concentrado em altos níveis de envolvimento dos clientes, o que é geralmente bom. Mas fomos longe demais. Um grande número de agilistas reclamam que não conseguem manter as organizações focadas em práticas técnicas; mas por que a surpresa, se encorajamos os Gerentes de Produto e Product Owners a fazerem todas as priorizações necessárias e depois medir o desempenho usando a velocidade? Para compensar a falta de foco no cliente das metodologias tradicionais, terminamos exagerando ao passar o controle da priorização para o Gerente de Produto ou Product Owner.

Highsmith não é o primeiro a questionar a utilização da velocidade nas práticas ágeis. Em seu post "O mau uso da velocidade em projetos ágeis", publicado no ano passado, Mark Levison define velocidade como a quantidade de trabalho realizado pela equipe, dividida pelo tempo necessário para completá-la. Ele lembra que "a quantidade de trabalho geralmente é medida em pontos da história (uma medida relativa de tamanho)."

Levison fala sobre o uso da velocidade para comparar a produtividade de duas equipes:  

Equipes Scrum/Agile usam estimativas relativas (ou seja, essa história/funcionalidade é maior ou menor que a nossa história padrão?), em vez da abordagem tradicional de estimativa absoluta. O problema com as comparações, benchmarking, ou outras tentativas de comparar a velocidade surge porque os pontos de história de cada pessoa são diferentes; porque os diferentes projetos usam diferentes histórias padrão. Eles trabalham em domínios de problemas diferentes e têm pessoas diferentes. 

Scott Ambler também escreveu sobre o assunto há alguns anos, tratando dos perigos de comparar as velocidades entre as equipes, e sugeriu que se calculasse a aceleração de cada equipe. Entre as vantagens indicadas por Ambler estão a facilidade de calcular e automatizar e a dificuldade de burlar as regras. Por outro lado, a aceleração é uma medida indireta que pode depender de ajustes que Ambler chama de "fatores de imprecisão". 

Embora o título do post de Highsmith possa ser visto como sensacionalista, nem ele  nem Levison indicam que o uso da velocidade é totalmente nocivo. Highsmith escreve que "o uso apropriado da velocidade é como ferramenta de calibração, uma maneira de apoiar o planejamento baseado em capacidade". Levison sugere que "o real valor do planejamento de velocidade e de releases vem de oferecer ao Product Owner uma boa ideia do que pode ser atingido antes do próximo release."

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Cliente 1.0 by Elias Nogueira

Total verdade... apesar de termos ótimos times quem no final quer comparar é o cliente, que ainda não está 100% com a mentalidade na linha ágil
Logo que li esse artigo pensei até em uma comparação com a Lei Seca: todo mundo diz que é bom mas a grande maioria sai, bebe e pega o volante...
Mesma coisa para a medida de velocidade de um time: todo mundo diz que faz isso com precaução mas muitos acabam comparando o que não devem.

Manifesto ágil by Noaldo Sales

Parabéns pelo post! Concordo plenamente. Acredito que algumas pessoas não estão levando em consideração o manifesto ágil.
"Software funcional é a medida primária de progresso.", Mas também "Contínua atenção à excelência técnica e bom design, aumenta a agilidade."

Agilidade não quer dizer quantidade de estórias entregues, mas sim valor entregue ao cliente.
" a arte de maximizar a quantidade de trabalho que não precisou ser feito."

Acho que falta um pouco mais de atenção para com a agilidade em si.

Grandes abraço!!

@noaldofilho

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT