BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

Pontos de história e velocidade são prejudiciais?

por Anand Vishwanath , traduzido por Leonardo Campos em 25 Jan 2013 |

A utilização de pontos de história e de velocidade vem sendo discutida por alguns agilistas da comunidade, que questionam se seriam ferramentas adequadas para as estimativas e medidas de progresso, pois seriam métricas propensas a abuso, raramente utilizadas de maneira efetiva.

Joshua Kerievsky escreveu um relato detalhado das suas experiências na utilização de pontos de história (story points) e sobre como a técnica é sujeita a abusos. Kerievsky cita um exemplo em que os pontos sofreram aumento irracional:

Um dia uma equipe foi cobrada a desempenhar melhor. Essa equipe tinha uma velocidade média bastante estável, por volta dos 52 pontos por iteração; havia flutuação, mas era de poucos pontos. Apesar disso, após uma cobrança por desempenho, a velocidade da equipe saltou para mais de 80 pontos! Perguntei o que havia acontecido. "Hoje em dia aqui um espirro conta como ponto de história", responderam. Como podia uma equipe madura como aquela, avaliada e treinada por mim e dois excelentes coaches da Industrial Logic, inflacionar as estimativas simplesmente para a equipe parecer mais rápida.

Minha confiança nos pontos de história e nos cálculos de velocidade começou a cair rapidamente após essa experiência.

Joshua Kerievsky também ressalta o anti-padrão de se comparar equipes por pontos.

Há muitos anos, venho sendo perguntado, por vários gerentes de empresas diferentes, "Por que a equipe X consegue fazer 24 pontos por sprint, enquanto a Y produz apenas 12? As duas equipes têm aproximadamente o mesmo tamanho, então qual a razão de tanta diferença?" Em vez de tratar a velocidade como específica à equipe, um indicador de capacidade, esses gerentes caem na armadilha de pensar na velocidade com medida geral de desempenho.

Uncle Bob Martin reforça essa visão, em comentário ao artigo de Kerievsky:

Muitas equipes têm problemas com pontos de história. Já vi equipes desvalorizarem a pontuação quando seus gerentes de projeto pedem mais velocidade; também já vi adulterarem gráficos de velocidade para satisfazer gerentes de projeto mais interessados na forma que na funcionalidade. Para equipes como essas, deve-se considerar uma nova abordagem.

Em uma discussão na lista de emails da Scrum Alliance Group, Ron Jeffries criticou a utilização da velocidade como métrica.

  • A velocidade pode ser mal utilizada, e geralmente é;
  • A velocidade pode ser utilizada como um jogo, e geralmente é.

Há um foco na parte errada da equação. O que o Agile considera importante no direcionamento de um projeto é a seleção das coisas a fazer e das que devem ser adiadas - e não em trabalhar no lado do custo dessa equação para tentar melhorá-lo. Uma equipe com enfoque na velocidade não está dando importância suficiente ao valor. Gostaria de nunca ter criado a métrica "velocidade", se é que o fiz.

Ron Jeffries elabora seu pensamento:

As questões sobre velocidade, na sua maioria, têm o objetivo de melhorar as estimativas. Mas quando investigamos mais detalhadamente, vemos equipes definindo quando terão finalizado o trabalho, e então se obrigando a concluir tudo. Vemos as equipes sendo medidas pela acurácia. Vemos também Product Owners distribuindo itens do backlog com pouco ou nenhum critério, apenas para "seguir o plano".

O Scrum funciona melhor quando o Product Owner utiliza o backlog de forma criativa, para entregar o melhor produto possível. Tenho percebido que um enfoque nas estimativas não ajuda a atingir esse objetivo.

Mike Cohn postou recentemente em seu blog um exemplo de conversa com um cliente que considera as estimativas importantes. O cliente diz:

Antes de tudo, para que eu sequer pense se continuo custeando o projeto, preciso saber se nossas estimativas foram boas nessa última fase. Se só fizermos metade do prometido, quando eu pedir mais recursos vão pensar que o dinheiro está indo para um buraco negro. Preciso saber se estamos com a abordagem adequada para conseguir boas estimativas e ter uma ideia de quanto precisaremos. Temos que melhorar as estimativas se elas não estiverem com a qualidade mínima.

Vou lutar para conseguir o financiamento, mas o dinheiro não vem de graça. É preciso haver algum nível de métricas dizendo como estamos em relação ao planejado. Em outras palavras, vou olhar o gráfico de burndown do projeto e acompanhar de perto todos os custos.

Vasco Duarte sugere uma alternativa aos pontos de história: estimar pelo número de histórias.

Considerando as estimativas e o progresso do projeto no longo prazo (note que isso só se aplica no longo prazo, por exemplo, mais de três iterações no futuro), pode-se considerar que todas as histórias sejam do mesmo tamanho e que podem, portanto, ter o progresso medido pelo número de itens concluídos por sprint.

Mike Cohn apresenta ideias semelhantes:

Concordo que equipes Kanban fazem menos estimativas explícitas. Isso porque partem do suposto que todo o trabalho tem aproximadamente o mesmo tamanho.

Neil Killick oferece outra abordagem para custeio que não envolve estimativas. Um exemplo utilizado é o da construção de um website, em que o fornecedor cria a melhor solução possível dado um orçamento pré-estabelecido; ao final, o cliente pode escolher se quer cancelar o contrato caso esteja insatisfeito, a qualquer momento. Sobre essa ideia, Killick argumenta:

Essa opção dispensa estimativas, permite que o design mude no meio do caminho, aceita mudanças conforme o andamento do trabalho, e mostra que a empresa está querendo trabalhar próxima ao cliente para atingir um resultado excelente. Mostra que a empresa está disposta a aceitar um risco maior (de perder dinheiro no contrato), porque confia na qualidade do que faz e no relacionamento que cria com seus clientes.

Você já percebeu práticas como velocidade e pontos de história induzirem a comportamentos inadequados? O que acha das alternativas sugeridas?

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

Comprometimento acima de tudo by DANILO RAMALHO

Acredito que quando o time esta comprometimento com o projeto não haverá problemas "story points", pois todos querem alcançar o objetivo o mais breve possível.

Percepções by Rodrigo Bela

Gostei demais da matéria.
Tenho sentido cada vez mais uma pressão por "produtividade" e entrega, mesmo trabalhando longas jornadas.
Esse texto veio colaborar com algumas conversas de corredor que tive: o foco está errado! Devemos entregar software bom, útil, que gere valor, não números que impressionam (e escondem futuros bugs e aborrecimentos para o futuro).
Bom saber que a comunidade percebe algo semelhante!

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

Conteúdo educacional

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