BT

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

Seu cadastro no InfoQ está atualizado? Poderia rever suas informações?

Nota: se você alterar seu email, receberá uma mensagem de confirmação

Nome da empresa:
Cargo/papel na empresa:
Tamanho da empresa:
País:
Estado:
Você vai receber um email para validação do novo endereço. Esta janela pop-up fechará em instantes.