As Práticas XP: Uma Visão Geral

XP não é um menu onde você escolhe seus favoritos. As práticas são projetadas para se reforçarem mutuamente. Remova uma, e as outras se tornam mais difíceis ou menos eficazes.

Por exemplo:

• Refatoração é segura porque você tem testes abrangentes
• Design simples é possível porque você pode refatorar quando os requisitos mudam
• Propriedade coletiva funciona porque você tem padrões de código
• Integração contínua é viável porque você tem pequenos lançamentos e testes

Essa natureza interligada é o motivo pelo qual "fazer TDD mas não refatorar" ou "programação em par sem testes" frequentemente falha. Você está removendo uma parede de sustentação.

Dito isso, você precisa começar de algum lugar. Discutiremos a adoção incremental no Módulo 5.

Estas são as práticas centrais que a maioria das equipes XP adota:

Práticas de Planejamento:

• Histórias de Usuário: Requisitos como iniciadores de conversa
• Jogo de Planejamento: O negócio escolhe o quê, os desenvolvedores escolhem como
• Pequenos Lançamentos: Entregar valor com frequência
• Planejamento de Iteração: Dividir histórias em tarefas para cada iteração

Práticas de Desenvolvimento:

• Desenvolvimento Orientado a Testes (TDD): Escreva o teste primeiro
• Programação em Par: Dois desenvolvedores, um teclado
• Refatoração: Melhorar o código sem alterar o comportamento
• Design Simples: A coisa mais simples que funciona
• Integração Contínua: Integrar e testar várias vezes ao dia

Práticas de Equipe:

• Equipe Completa: Todos os necessários para entregar, em uma sala
• Propriedade Coletiva de Código: Qualquer um pode alterar qualquer código
• Padrões de Código: Convenções de código acordadas
• Ritmo Sustentável: Sem horas extras como regra

Cobriremos cada uma delas em profundidade nos módulos seguintes.

Essas práticas são poderosas, mas exigem mais maturidade ou condições específicas:

• Envolvimento Real do Cliente: O cliente real, não apenas um representante
• Análise de Causa Raiz: Corrigir o sistema, não apenas o sintoma
• Código Compartilhado: Todo código é visível para todos os desenvolvedores
• Código e Testes: Código e testes são os únicos artefatos permanentes
• Base de Código Única: Um branch, não muitos
• Implantação Diária: Implantar em produção todos os dias
• Contrato de Escopo Negociado: Contratos que abraçam a mudança
• Pagamento por Uso: Feedback direto de clientes reais

Estas não são "XP avançado". São práticas que funcionam bem no contexto certo, mas podem ser inadequadas ou impossíveis em outros.

Uma maneira de entender as práticas XP é através de seus ciclos de feedback:

Segundos: Testes unitários Minutos: Programação em par Horas: Integração contínua Dia: Reunião de standup Semana: Planejamento de iteração, demonstração ao cliente Mês/Trimestre: Lançamento, retrospectiva

Em cada escala, XP cria oportunidades para aprender e ajustar. Isso é intencional. Quanto mais rápido você aprende, mais rápido pode corrigir o curso.

Se você não está obtendo feedback em cada uma dessas escalas, algo está faltando.

Isso pode parecer avassalador. Não tente adotar tudo de uma vez.

A maioria das equipes começa com:

1. TDD ou pelo menos escrever testes
2. Integração Contínua
3. Iterações (ou sprints se usar Scrum)
4. Retrospectivas

Estes formam a base. Uma vez que estejam funcionando, adicione:

• Programação em par (comece apenas com problemas difíceis)
• Refatoração (comece com o código mais confuso)
• Pequenos lançamentos (comece lançando com mais frequência)

Cobriremos estratégias de adoção no Módulo 5. Por enquanto, apenas entenda o panorama.