O Jogo de Planejamento

O jogo de planejamento do XP é construído sobre um princípio simples: O negócio decide o que construir. Os desenvolvedores decidem como construir.

Essa separação é crítica:

• O negócio entende valor, prioridade e timing. Eles sabem quais funcionalidades importam para os clientes e quando são necessárias.
• Os desenvolvedores entendem esforço, complexidade e restrições técnicas. Eles sabem o que é difícil e o que é fácil.

Nenhum dos dois pode fazer o trabalho do outro. O negócio não pode estimar esforço técnico. Os desenvolvedores não podem decidir prioridade de negócio. O jogo de planejamento os reúne com papéis claros.

O negócio escolhe:

• Quais funcionalidades construir
• Em que ordem construí-las
• Quando lançar

Os desenvolvedores fornecem:

• Estimativas para cada funcionalidade
• Opções técnicas e trade-offs
• Avaliações de risco

O planejamento de release responde: O que estará na próxima release e quando será lançada?

O XP diz que você pode fixar duas destas três variáveis:

• Escopo: Quais funcionalidades estão incluídas
• Cronograma: Quando a release será lançada
• Recursos: Quem está trabalhando nela

Você não pode fixar as três. Algo tem que ser flexível.

Release com data fixa: "Lançamos em 1º de março. Quanto conseguimos fazer?" O escopo é negociável.

Release com escopo fixo: "Precisamos dessas funcionalidades. Quando podemos lançá-las?" A data é negociável.

O processo do jogo de planejamento:

1. O negócio lista as funcionalidades desejadas em ordem de prioridade
2. Os desenvolvedores estimam cada funcionalidade
3. Com base na velocidade, calculam quantas funcionalidades cabem até a data (ou quanto tempo para completar o escopo)
4. O negócio ajusta as prioridades se necessário
5. Comprometem-se com um plano, mas esperam replanejar

Replaneje regularmente. À medida que você aprende mais, atualize o plano de release. O XP não assume que o plano inicial é sagrado.

O planejamento de iteração é mais detalhado. Acontece no início de cada iteração (geralmente semanal ou quinzenal).

O processo:

1. O negócio apresenta as histórias de maior prioridade para a iteração
2. Os desenvolvedores dividem as histórias em tarefas (blocos de 2-4 horas)
3. Os desenvolvedores se inscrevem para tarefas com base em interesse e habilidade
4. A equipe se compromete com o que completará nesta iteração

Regras principais:

• Apenas o negócio define prioridade
• Apenas os desenvolvedores estimam e se comprometem
• Não se comprometa demais (deixe folga para o inesperado)
• Inclua trabalho técnico (infraestrutura, refatoração) no plano

Durante a iteração:

• Acompanhe o progresso visivelmente (quadro kanban, burndown)
• Se fora do caminho, levante imediatamente
• Não adicione escopo no meio da iteração (proteja o foco)
• Se adiantado, puxe a próxima história

O planejamento de iteração é mais leve que o planejamento de release. As histórias já estão estimadas. O foco é dividir em tarefas e se comprometer com quantidades realistas.

Os planos mudam. O XP espera isso e incorpora adaptação.

Quando ajustar:

• As estimativas estavam erradas (a história era maior que o esperado)
• As prioridades mudaram (o cliente descobriu novos requisitos)
• A capacidade da equipe mudou (doença, rotatividade)
• Dependências externas falharam (API não estava pronta)

Como ajustar:

1. Exponha o problema imediatamente (transparência)
2. Quantifique o impacto (estamos 2 histórias atrasados)
3. Proponha opções (reduzir escopo, estender ou reduzir qualidade—mas nunca qualidade)
4. O negócio decide (eles são donos da prioridade)

O que nunca muda: Qualidade. O XP não troca qualidade por escopo ou cronograma. Se você está atrasado, entrega menos—não de forma mais desleixada.

O jogo de planejamento assume ajuste contínuo. O plano inicial é um ponto de partida, não um compromisso com um resultado exato. Como Kent Beck diz: "O propósito do planejamento é planejar, não o plano."

O jogo de planejamento requer um cliente—alguém que representa as prioridades de negócio.

Isso pode ser:

• O usuário final real (ideal mas raro)
• Um product owner (terminologia Scrum)
• Um gerente de produto
• Um analista de negócios

O cliente deve:

• Estar disponível para responder perguntas (idealmente diariamente)
• Tomar decisões de prioridade rapidamente
• Aceitar trade-offs quando as coisas mudam
• Fornecer critérios de aceitação para histórias

O "cliente no local" do XP originalmente significava alguém fisicamente presente com a equipe. Em equipes distribuídas modernas, "no local" pode significar "no Slack" ou "no standup diário". A chave é disponibilidade, não localização física.

Sem um cliente, o planejamento falha. Os desenvolvedores adivinham a prioridade. O escopo aumenta porque ninguém decide o que está fora. A equipe constrói a coisa errada.