Estimativa em XP

Humanos são ruins em estimar tempo absoluto. "Isso vai levar 3 dias" está quase sempre errado. Subestimamos a complexidade e superestimamos nossa produtividade.

Mas humanos são bons em comparação relativa. "Esta história é cerca de duas vezes maior que aquela" é algo que podemos fazer de forma confiável.

XP usa estimativa relativa. Em vez de estimar horas, estimamos tamanho. Uma história pode ser um "2" ou um "5" ou um "13". Esses números não significam horas ou dias—eles significam tamanho relativo comparado a outras histórias.

Por que o relativo funciona:

• Estamos comparando coisas que entendemos (história com história, não história com tempo)
• É mais rápido (você não precisa de detalhamentos de tarefas)
• É mais honesto (sem falsa precisão)
• Se autocorrige através do rastreamento de velocidade

Story points são a unidade mais comum para estimativa relativa.

Pontos representam esforço, complexidade e incerteza combinados—não tempo. Uma história de 5 pontos é aproximadamente o dobro do esforço de uma história de 2 pontos (mais ou menos), mas não necessariamente o dobro de horas.

Escalas de pontos comuns:

• Fibonacci: 1, 2, 3, 5, 8, 13, 21, ? (lacunas forçam você a escolher)
• Potências de 2: 1, 2, 4, 8, 16 (duplicação simples)
• Tamanhos de camiseta: XS, S, M, L, XL (não numérico, bom para planejamento de alto nível)

Dicas para pontuar histórias:

• Compare com histórias de referência ("Isso é maior ou menor que a História X?")
• Não pense demais (pontos são imprecisos por design)
• Inclua incerteza na estimativa (desconhecido = maior)
• Reavalie se você aprender algo que mude seu entendimento

Planning poker é uma técnica para alcançar consenso da equipe sobre estimativas.

Como funciona:

1. O product owner lê uma história
2. Membros da equipe fazem perguntas de esclarecimento
3. Todos selecionam privadamente uma carta de estimativa
4. Todas as cartas são reveladas simultaneamente
5. Os estimadores mais alto e mais baixo explicam seu raciocínio
6. A equipe discute e revota se necessário
7. O consenso emerge (ou a média é tomada)

Por que revelação simultânea? Para evitar ancoragem. Se o desenvolvedor sênior diz "5" primeiro, todos os outros se ajustam em direção a 5. Revelar simultaneamente captura opiniões independentes.

Por que discutir valores extremos? A pessoa que disse "13" pode saber algo que outros não sabem ("isso requer migração de banco de dados"). A pessoa que disse "2" pode ter uma abordagem mais simples. Ambas as visões melhoram a estimativa.

Planning poker é tanto sobre construir entendimento compartilhado quanto obter um número. A discussão revela suposições, riscos e decisões de design.

Velocidade é quantos pontos a equipe completa por iteração. É a chave para transformar estimativas relativas em previsões.

Se a equipe completou 30 pontos na última iteração, provavelmente completará cerca de 30 pontos na próxima iteração. Isso é chamado de tempo de ontem—o melhor preditor do tempo de amanhã é o tempo de hoje.

Usando velocidade:

• Se você tem 100 pontos de trabalho e uma velocidade de 20, espere cerca de 5 iterações
• Se o cliente quer entregar em 3 iterações, você pode fazer cerca de 60 pontos de trabalho
• A velocidade flutua; use uma média móvel (últimas 3-5 iterações)

O que afeta a velocidade:

• Composição da equipe (férias, novos membros)
• Ambiente técnico (novo framework, mudanças de infraestrutura)
• Tipo de trabalho (nova funcionalidade vs correção de bugs)
• Foco da equipe (interrupções matam a velocidade)

Não manipule a velocidade. Não é uma métrica de produtividade—é uma ferramenta de planejamento. Inflar pontos ou cortar caminhos para "aumentar a velocidade" derrota o propósito.

Estimativas são palpites. Elas estarão erradas. XP reconhece isso e incorpora adaptabilidade.

Falhas comuns de estimativa:

• Desconhecidos desconhecidos: Complexidade imprevista emerge
• Dependências: Equipes ou sistemas externos causam atrasos
• Aumento de escopo: A história cresce conforme você a constrói
• Débito técnico: O código existente é mais difícil de mudar do que o esperado

O que fazer quando fora do caminho:

1. Revele imediatamente (transparência)
2. Reavalie com base no novo entendimento
3. Discuta com o product owner
4. Negocie escopo se necessário (incremento menor, adie funcionalidades)

Não esconda. Não trabalhe horas extras para atingir uma estimativa ruim. O objetivo da estimativa é planejar—se o plano está errado, mude-o.

Com o tempo, as estimativas melhoram. Conforme a equipe ganha experiência com a base de código e uns com os outros, a incerteza diminui. Mas elas nunca serão perfeitas—é por isso que XP enfatiza adaptação sobre previsão.