BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias A velocidade está matando o Agile?

A velocidade está matando o Agile?

Favoritos

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.

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

Comentários da comunidade

  • Cliente 1.0

    by Elias Nogueira,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    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,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    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

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

BT