Pontos da história e estimativas

Uma estimativa bem feita permite que os proprietários de produtos otimizem os processos para ter mais eficiência e impacto. É por isso que ela é tão importante. 

Dan Radigan Dan Radigan
Buscar tópicos

Fazer estimativas é difícil. Para os desenvolvedores de software, é um dos aspectos mais difíceis do trabalho, talvez até o mais difícil. É preciso levar em conta uma série de fatores que ajudam os proprietários de produtos a tomar decisões que afetam toda a equipe e a empresa. Com tudo isso em jogo, não é de admirar que todos, de desenvolvedores ao gerenciamento de alto nível, estão propensos a exagerar no empenho com isso, o que é um erro. A estimativa ágil é só isso mesmo: uma estimativa, não um pacto de sangue. 

Não há necessidade de trabalhar nos fins de semana para compensar quando uma parte do trabalho é subestimada. Dito isso, vejamos algumas maneiras de fazer as estimativas ágeis o mais precisas possível. 

Colaboração com o proprietário do produto

No desenvolvimento ágil, o proprietário do produto tem como tarefa priorizar o backlog – a lista ordenada de trabalho com descrições curtas de todos os recursos e correções desejados para um produto. Os proprietários de produto registram os requisitos da empresa, mas nem sempre entendem os detalhes da implementação. Uma boa estimativa dá ao proprietário do produto um insight novo em relação ao nível de esforço necessário para cada item de trabalho, o que, então, alimenta a avaliação da prioridade relativa de cada item.

Quando a equipe de engenharia começa seu processo de estimativa, normalmente surgem perguntas sobre os requisitos e as histórias de usuários. E isso é bom: essas perguntas ajudam toda a equipe a entender melhor o trabalho completo. Os proprietários do produto, especificamente, podem dividir os itens de trabalho em partes menores e fazer estimativas por meio de pontos de histórias para ajudar a ordenar todas as áreas de trabalho, inclusive as que podem estar ocultas. E, assim que recebem as estimativas da equipe de desenvolvimento, não é incomum para um proprietário de produto reordenar os itens no backlog. 

A estimativa ágil é um trabalho em equipe

Envolver todos (desenvolvedores, designers, testadores, implementadores, etc.) na equipe é fundamental. Cada membro da equipe traz uma perspectiva diferente sobre o produto e o trabalho necessário para entregar uma história de usuário. Por exemplo, se o gerenciamento de produto quer fazer algo que pareça simples, como oferecer compatibilidade com um navegador novo, as equipes de desenvolvimento e QA precisam dar sua opinião, pois têm experiência para saber quais abacaxis podem precisar ser descascados a qualquer momento.

Da mesma forma, as alterações de design exigem não só comentários da equipe de design, mas também das equipes de desenvolvimento e controle de qualidade. Deixar a maior parte da equipe de produtos fora do processo de estimativa cria estimativas de qualidade menores, reduz o incentivo, pois os principais colaboradores não se sentem incluídos, e compromete a qualidade do software.

Então, não deixe que sua equipe seja vítima de estimativas feitas a partir do nada. É um caminho rápido para o fracasso! 

Pontos de história versus horas

Equipes de software tradicionais dão estimativas em tempo: dias, semanas, meses. Muitas equipes ágeis, contudo, fizeram a transição para pontos de história, que classificam o esforço relativo da tarefa em um formato Fibonacci: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Pode parecer despropositado, mas essa abstração é realmente útil porque faz a equipe tomar decisões mais difíceis em relação à dificuldade do trabalho. Veja alguns motivos para usar pontos de história:

  • Datas não consideram o trabalho não relacionado ao projeto e que inevitavelmente invade nossos dias, como e-mails, reuniões e entrevistas.
  • As pessoas têm um apego emocional às datas. A estimativa relativa elimina o apego emocional.
  • Cada equipe vai estimar o trabalho em uma escala um pouco diferente, o que significa que a velocidade (medida em pontos) também vai ser diferente. Assim, fica impossível fazer política usando a velocidade como arma.
  • Assim que você concordar com o esforço relativo de cada valor de ponto da história, é rápido atribuir pontos sem muito debate. 
  • Os pontos de história recompensam membros da equipe por resolver problemas com base na dificuldade, e não no tempo gasto. Assim, os membros da equipe se concentram em apresentar resultados, não no tempo gasto. 

Pontos de história e Planning Poker

As equipes que estão começando a utilizar pontos de história usam um exercício chamado "Planning Poker". Na Atlassian, essa é uma prática comum em toda a empresa. A equipe escolhe um item do backlog, faz uma discussão breve sobre ele e cada membro formula uma estimativa mental. Então, todos levantam o cartão com o número que reflete sua estimativa. Se todos estiverem de acordo, ótimo! Se não, dedique algum tempo (mas não muito, apenas alguns minutos) para entender a lógica por trás de estimativas diferentes. Lembre-se: a estimativa deve ser uma atividade de alto nível. Se a equipe estiver muito perdida, respire e aumente o nível da discussão.

Pronto para tentar? 

Estime de um modo inteligente, não difícil

Nenhuma tarefa individual deve consumir mais de 16 horas de trabalho. (Se estiver usando pontos de história, você poderá decidir que, digamos, 20 pontos é o limite máximo.) É difícil demais estimar itens de trabalho individuais maiores que isso com um alto grau de confiança. E essa confiança tem uma importância especial para itens no topo do backlog. Quando a estimativa supera o limite de 16 horas (ou 20 pontos) de sua equipe, é um sinal para fazer uma divisão em partes menores e elaborar uma nova estimativa.

Para itens mais a fundo no backlog, faça uma estimativa aproximada. Quando a equipe começar a trabalhar nesses itens, os requisitos poderão mudar e seu aplicativo com certeza terá mudado. Portanto, as estimativas anteriores não serão tão precisas. Não perca tempo estimando o trabalho que provavelmente mudará. Basta fornecer ao proprietário do produto um valor aproximado que ele possa usar para priorizar o roteiro do produto de modo adequado.

Aprender com as últimas estimativas

As retrospectivas são um momento para a equipe incorporar insights de iterações anteriores, incluindo a precisão de suas estimativas. Muitas ferramentas ágeis (como o Jira Software) monitoram os pontos de história, o que deixa mais fácil refletir e recalibrar as estimativas. Tente, por exemplo, analisar as cinco últimas histórias de usuários que a equipe apresentou com ponto de história de valor 8. Discuta se esses itens de trabalho tiveram um nível semelhante de esforço. Se não tiveram, discuta o motivo. Use essas informações para debater estimativas no futuro.

Como tudo no método ágil, a estimativa exige prática. Você vai ficar melhor com o tempo. 

a seguir
Metrics