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."

Avalie esse artigo

Relevância
Estilo/Redação

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 mensagens 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 mensagens dessa discussão

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

Receber mensagens dessa discussão

2 Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.