BT

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?

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

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