eXtreme Programming

eXtreme Programming — geralmente apenas XP — é o membro mais exigente da família ágil. O East Agile Tracker é construído primeiro para o XP; todo o resto decorre disso.

Esta página cobre o que é o XP, por que ele funciona e como praticá-lo com o tracker como sua superfície de planejamento.

O que é o XP

O XP foi criado por Kent Beck no fim da década de 1990. O primeiro livro — Extreme Programming Explained: Embrace Change — foi publicado em 1999. Começou, como muitas coisas, com uma equipe frustrada tentando entregar um sistema de folha de pagamento na Chrysler.

A aposta do XP é que a maneira certa de lidar com a incerteza no software é fazer as coisas que funcionam e fazê-las com mais frequência. Testar? Testar o tempo todo. Integrar? Integrar de hora em hora. Conversar? Conversar constantemente. Planejar? Planejar a cada iteração e replanejar à medida que você aprende.

“XP é uma metodologia leve para equipes de pequeno a médio porte que desenvolvem software diante de requisitos vagos ou que mudam rapidamente.” — Kent Beck

Os cinco valores

O XP nomeia cinco valores dos quais todo o resto depende:

1. Comunicação — A equipe conversa. Diariamente. Sobre o trabalho, o design, os obstáculos. Face a face quando possível. Os silos são o inimigo.
2. Simplicidade — Faça a coisa mais simples que possivelmente funcione. Você pode adicionar complexidade depois se realmente precisar. Provavelmente não precisará.
3. Feedback — Do código (testes), da equipe (programação em par, revisões), do usuário (releases frequentes). Obtenha-o rápido.
4. Coragem — Diga a verdade sobre o progresso, as estimativas e o design. Jogue fora o código que não funciona. Refatore o que está te atrapalhando.
5. Respeito — Todos na equipe — e agora, todo agente na equipe — contribuem com valor. Tratem uns aos outros de acordo.

As práticas

O XP é famoso por suas doze práticas originais, organizadas em quatro áreas:

Planejamento

• Jogo do Planejamento — A equipe e o cliente planejam juntos: o que vem a seguir, em que ordem, qual o tamanho de cada peça.
• Releases Pequenos — Entregue com frequência. Dias, não meses. Obtenha feedback sobre algo concreto.
• Histórias de Usuário — Requisitos são conversas, capturadas como histórias curtas do ponto de vista do usuário. “Como usuário, eu quero X, para que Y.”

Design

• Design Simples — O design mais simples que passa nos testes e expressa todo conceito necessário. Nada além.
• Refatoração — Melhore o design de código que já está funcionando. Constantemente.
• Metáfora do Sistema — Uma história compartilhada de como o sistema funciona, usada para tornar as decisões de design consistentes.

Codificação

• Programação em Par — Dois desenvolvedores, um teclado. Um conduz, um navega. Troque com frequência.
• Propriedade Coletiva do Código — Qualquer um pode melhorar qualquer código. Sem feudos.
• Integração Contínua — Integre e teste o código muitas vezes ao dia. Capture quebras imediatamente.
• Padrões de Codificação — Estilo acordado para que o código se leia como se uma única pessoa o tivesse escrito.

Testes

• Desenvolvimento Orientado a Testes (TDD) — Escreva primeiro o teste que falha, depois o código que o faz passar.
• Testes de Aceitação — O cliente define, em código ou forma executável, o que “pronto” significa para cada história.

Por que o XP funciona

O XP é desconfortável. A programação em par força você a pensar em voz alta. O TDD força você a saber como é o sucesso antes de escrever o código. A integração contínua mata seus branches favoritos de vida longa. Releases pequenos significam que você não pode se esconder atrás de um roteiro de seis meses.

Funciona porque todas essas coisas encurtam os ciclos de feedback. Quanto mais rápido você descobre que estava errado, mais barata é a correção. O XP é, fundamentalmente, sobre tornar o ciclo de feedback o mais apertado possível.

Também é sobre coragem e respeito. Você só consegue fazer XP em uma equipe que confia o suficiente uns nos outros para estar errada em voz alta.

O modelo disciplinado de história

O East Agile Tracker codifica uma teoria específica de planejamento. Trate esta seção como o manual de operação do porquê o modelo de dados se parece com o que se parece — e como o guia de campo do que fazer (e não fazer) na prática.

Por que os quatro tipos de história importam

Tudo é uma história, mas há quatro tipos, e a distinção é o ponto central:

• Features carregam pontos e são a única coisa que “conta” para a velocidade. Isso força você a fatiar o trabalho em valor observável pelo usuário.
• Bugs não têm pontos (zero). Defeitos não rendem crédito, o que torna o custo do retrabalho visível em vez de recompensado.
• Chores também não têm pontos — trabalho necessário sem valor direto para o usuário (infra, refatorações, configuração). Mantê-los em zero pressiona a equipe a agrupá-los em features sempre que possível, para que o enquadramento de valor permaneça honesto.
• Releases são marcadores de zero pontos usados para ancorar marcos e permitir que a ferramenta projete uma data.

O efeito comportamental é o que importa: quando bugs e chores não pontuam, uma equipe naturalmente passa a expressar o trabalho como funcionalidade orientada ao usuário e fica agudamente consciente do custo dos defeitos. Isso é uma disciplina de planejamento codificada no modelo de dados.

O backlog único e ordenado

Três zonas, uma regra.

• O Icebox é o pool de ideias não priorizadas.
• O Backlog é uma lista estritamente ordenada, de prioridade única — sem empates, sem “P1/P1/P1”.
• A zona Current mantém a(s) iteração(ões) ativa(s).

O product owner é dono da ordem de cima a baixo, e a invariante é que o topo do backlog é sempre o mais importante e o mais bem especificado, com a clareza diminuindo legitimamente à medida que você desce. Uma história perto do topo com critérios de aceitação vagos é um bug de planejamento. O Icebox tem permissão para ser um cemitério; o Backlog não.

Planejamento automático conduzido pela velocidade

Esta é a parte que a maioria das equipes reimplementa mal em outros lugares. O planejamento ao estilo do tracker calcula uma velocidade média móvel a partir dos pontos aceitos recentemente e automaticamente puxa essa quantidade de pontos de histórias para a próxima iteração — você não “se compromete” manualmente com uma sprint, os dados empíricos fazem isso por você. Duas consequências que vale a pena preservar:

• Você estima apenas features, usando pontos relativos (Fibonacci 1/2/3/5/8 ou nossa escala mais enxuta 0/1/2/3), não horas. A estimativa é uma conversa de dimensionamento, não uma promessa.
• Você não manipula a velocidade. Inflar pontos para “parecer rápido”, ou pontuar chores, quebra a projeção que torna todo o sistema honesto. A velocidade é um instrumento de medição, e você não adultera seu próprio instrumento.

A recompensa é que a projeção da data de release torna-se um cálculo em vez de uma negociação, e a conversa com as partes interessadas muda de “você consegue se comprometer com X até sexta-feira” para “na velocidade atual, este release chega por volta da data Y — eis o trade-off entre escopo e data”.

O ciclo de vida da história e o ciclo de aceitação

A máquina de estados é Start → Finish → Deliver → Accept / Reject. O estado crítico é Deliver: um engenheiro marca uma história como entregue, mas ela não está pronta até que o product owner a aceite explicitamente em relação aos seus critérios de aceitação — ou a rejeite, devolvendo-a. Isso embute um ciclo de feedback do cliente em cada história, em vez de adiar a aceitação para uma demonstração no fim da sprint.

Os critérios de aceitação pertencem à história antes de ela ser iniciada, idealmente no formato Given/When/Then, para que mapeiem diretamente em testes de aceitação. O INVEST é a verificação de sanidade sobre se uma história está bem formada:

• Independent (Independente) — pode ser liberada sem outras histórias.
• Negotiable (Negociável) — captura a intenção, não uma especificação congelada.
• Valuable (Valiosa) — para um usuário ou parte interessada.
• Estimable (Estimável) — a equipe consegue dimensioná-la.
• Small (Pequena) — cabe confortavelmente em uma iteração.
• Testable (Testável) — tem critérios de aceitação que podem ser exercitados.

Cadência

As cerimônias de planejamento são leves e regulares:

• Uma Reunião de Planejamento de Iteração semanal para pontuar novas histórias e fixar os critérios de aceitação no topo do backlog.
• Uma reunião diária curta focada em fluxo e bloqueios.
• Uma retrospectiva por iteração para ajustar o processo.

As iterações geralmente são de uma ou duas semanas — curtas o suficiente para que uma estimativa ruim seja barata de descobrir.

As práticas de engenharia que fazem o planejamento funcionar

O planejamento ao estilo do tracker é a metade visível do XP; ele desmorona sem a metade de engenharia.

• Test-first / TDD e uma verdadeira suíte de testes de aceitação são o que permitem que “delivered” signifique algo.
• Integração contínua e releases pequenos e frequentes mantêm o tempo de ciclo curto, para que a velocidade seja estável em vez de irregular.
• Programação em par (ou revisão forte) mantém o trabalho em progresso baixo — termine antes de começar — que é a maior alavanca individual sobre o tempo de ciclo.
• Um product owner disponível é o que impede o ciclo de aceitar/rejeitar de travar.

Antipadrões a observar

As falhas recorrentes:

• Tratar o Backlog como um estacionamento em vez de uma verdadeira ordem de prioridade.
• Estimar bugs e chores para fazer a velocidade parecer melhor.
• Carregar histórias enormes que não conseguem terminar em uma iteração. Divida até que cada uma seja entregável de forma independente.
• Deixar histórias se acumularem em Delivered porque ninguém está aceitando.

Qualquer um desses converte silenciosamente um sistema empírico de volta em planejamento ilusório. O tracker não pode impedir você de fazê-los; só pode torná-los visíveis. Observe sua coluna Delivered no fim de cada iteração — se ela está crescendo, esse é o seu sinal.

XP com o East Agile Tracker

O tracker é a superfície de planejamento que as equipes de XP queriam desde os tempos do Pivotal Tracker. Cada conceito se mapeia diretamente:

Histórias de Usuário → Histórias

As histórias de usuário do XP são as histórias do East Agile Tracker. Escreva-as no tipo Feature. Use a descrição para a conversa; use comentários para a discussão contínua. Os critérios de aceitação pertencem à descrição.

Jogo do Planejamento → O quadro

O Jogo do Planejamento no XP é uma conversa entre o negócio e a equipe sobre prioridade e tamanho. No East Agile Tracker:

1. A pessoa de produto escreve histórias no Backlog e as ordena por prioridade.
2. A equipe estima features em pontos (escala Fibonacci ou East Agile).
3. O sistema planeja automaticamente as iterações a partir da velocidade.
4. A equipe inicia histórias a partir do topo da coluna Current.

É isso. O “jogo” vive na conversa; o tracker apenas mantém o placar.

Releases Pequenos → Releases (o tipo de história)

O XP diz para liberar com frequência. Release é um dos quatro tipos de história no East Agile Tracker. Crie um release para cada marco de entrega; arraste-o para a iteração em que ele é lançado. Releases pulam Started/Finished/Delivered e vão direto para Accepted quando você lança.

Integração Contínua → Máquina de estados da história

A máquina de estados não é a CI em si — isso é o seu sistema de build — mas o caminho Finished → Delivered → Accepted espelha o ciclo de aceitação do cliente que o XP descreve. Termine o trabalho, entregue-o ao cliente, aceite quando estiver confirmado como funcionando.

Velocidade → “Clima de ontem”

O XP chama de clima de ontem: o quanto você fez na última iteração é a melhor previsão do quanto você fará nesta. O East Agile Tracker calcula a velocidade automaticamente — média de iterações recentes, estratégia configurável — e a usa para planejar automaticamente a capacidade da próxima iteração.

Testes de Aceitação → Revisões

As revisões de história no tracker se mapeiam à aceitação. Atribua um revisor (o cliente, o product owner ou até um agente atuando como um). Eles aprovam ou rejeitam. Rejeitar devolve a história para Started.

Programação em Par → Copropriedade

As equipes de XP fazem par no código. No tracker, isso aparece como múltiplos donos em uma história. Atribua ambos os pares à história; ambos os nomes aparecem no card.

XP com agentes — a nova prática

O XP foi escrito antes que os agentes de IA pudessem contribuir significativamente para o software. Acreditamos que esta seja a atualização mais importante do XP em vinte e cinco anos.

Em nossa prática — e aquilo para o qual o tracker é construído — um agente é um membro nomeado da equipe de XP. Ele tem seu próprio papel, seu próprio parceiro de par (humano ou agente) e sua própria trilha de auditoria. Ele pode fazer qualquer coisa que um membro humano da equipe pode fazer na superfície de planejamento: estimar, possuir histórias, comentar, transicionar, aceitar revisões.

Os valores do XP ainda valem. Comunicação: os agentes se comunicam lendo o fluxo de eventos e postando comentários. Simplicidade: os agentes ficam restritos aos papéis que você concede a eles. Feedback: cada ação do agente está na trilha de auditoria, imediatamente revisável. Coragem: seja honesto sobre o que seus agentes acertaram e o que não acertaram. Respeito: os colegas de equipe agentes contribuem com valor — reconheça isso.

Não colocamos os agentes dentro do tracker fazendo a codificação. Damos a superfície de planejamento a humanos e agentes trabalhando juntos. Você traz o agente de codificação — Claude Code, Codex, o seu próprio — e o conecta ao tracker via API. O agente pega histórias, faz o trabalho, comenta, transiciona. Você revisa a trilha e aceita.

Isto é Planejamento Ágil Inclusivo. É XP, com a equipe que ele realmente tem.

Leitura adicional

• Extreme Programming Explained — O livro fundacional de Kent Beck, 1999.
• O Manifesto Ágil — Onde a família começou.
• Desenvolvimento Ágil — O quadro mais amplo.
• Instruções de Operação — Guia prático do tracker.
• Guia da API — Conectando seu agente de codificação.