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 que contém descrições breves de todos os recursos desejados e correções para o produto. Os proprietários de produto agrupam os requisitos da empresa, mas nem sempre entendem o que há por trás da implementação. Uma estimativa boa dá ao proprietário do produto uma visão nova em relação ao nível de esforço para cada item de trabalho que, então, embasa uma 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 do usuário. Por exemplo, se o gerenciamento de produto quer fazer algo que pareça simples, como a compatibilidade com um navegador da Web novo, as equipes de desenvolvimento e assistência de qualidade precisam fazer o ponderamento, pois a experiência demonstra que problemas podem surgir 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 assistência 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 um formato de tempo: dias, semanas, meses. Muitas equipes ágeis, contudo, fizeram a transição para pontos de história. Pontos de história classificam o esforço relativo de trabalho em um formato Fibonacci: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Pode parecer nada intuitivo, mas essa abstração é realmente útil porque faz com que a equipe tome decisões mais difíceis em relação a uma dificuldade do trabalho. Aqui estão alguns motivos para usar pontos de história:

  • Datas não levam em conta o trabalho não relacionado ao projeto que aparece inevitavelmente em nossos dias: e-mails, reuniões e entrevistas nas quais um membro da equipe pode estar envolvido.
  • Datas têm um vínculo emocional com eles. A estimativa relativa elimina o vínculo emocional.
  • Cada equipe estimará o trabalho em uma escala levemente diferente, o que significa que a velocidade (medida em pontos) será, naturalmente, diferente. Isso, por sua vez, torna impossível fazer política usando a velocidade como uma estratégia.
  • Depois de concordar sobre o esforço relativo do valor de cada ponto da história, você pode atribuir pontos com rapidez e sem muita discussão.
  • Os pontos da história recompensam os membros da equipe por resolver problemas com base na dificuldade, não no tempo gasto. Isso mantém os membros da equipe focados em entregar valor, não em gastar tempo.

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 "pôquer de planejamento". Na Atlassian, o pôquer de planejamento é uma prática comum em toda a empresa. A equipe pegará um item da lista de pendências, discutirá brevemente sobre ele e cada membro formulará mentalmente uma estimativa. Então todos levantam o cartão com o número que reflete sua estimativa. Se todos estiverem de acordo, ótimo! Se não, levará algum tempo (mas não muito tempo– 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 distante, respire e aumente o nível da discussão.

Pronto para testar?

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

Nenhuma tarefa individual deve ter mais de 16 horas de trabalho. (Se estiver usando pontos de história, você poderá decidir que, digamos, 20 pontos é o limite superior.) É simplesmente muito difícil estimar itens de trabalho individuais maiores do que os com um alto grau de confiança. E essa confiança é especialmente importante para itens no topo da lista de pendências. Quando algo é estimado acima do limite de 16 horas (ou 20 pontos) de sua equipe, isso é um sinal para fazer uma divisão em partes menores e elaborar uma nova estimativa.

Para itens mais complicados na lista de pendências, dê uma estimativa aproximada. Quando que a equipe realmente começar a trabalhar nesses itens, os requisitos poderão mudar, e seu aplicativo certamente terá mudado. Então as estimativas anteriores não serão tão precisas. Não desperdice tempo estimando trabalho que provavelmente será alterado. Forneça ao proprietário do produto um número aproximado para que seja possível priorizar o roteiro do produto adequadamente.

Aprender com as últimas estimativas

As retrospectivas são o momento em que a equipe integra dados de iterações anteriores, como a precisão das estimativas. Muitas ferramentas ágeis (como o Jira Software) acompanham os pontos da história, o que facilita muito a reflexão e a recalibração das estimativas. Tente, por exemplo, analisar as últimas cinco histórias de usuários que a equipe apresentou com valor 8 do ponto da história. Discuta quais desses itens de trabalho tiveram um nível semelhante de trabalho. Se não tiveram, discuta o motivo. Use essa informação nas próximas discussões de estimativa.

Como tudo no método ágil, a estimativa é questão de prática. Você vai melhorar com o tempo.

a seguir
Metrics