Princípios XP

Valores dizem o que é importante. Práticas dizem o que fazer. Mas como você os conecta? É aí que entram os princípios.

Princípios são a ponte. Eles são mais concretos que valores, mas mais abstratos que práticas. Quando você está decidindo se deve adotar uma prática ou modificá-la para seu contexto, os princípios guiam o caminho.

XP tem muitos princípios, mas vamos focar nos mais importantes.

Software é feito por pessoas, para pessoas.

Este princípio nos lembra que desenvolvedores não são recursos intercambiáveis. Pessoas têm necessidades:

• Segurança (física e psicológica)
• Realização (fazer trabalho significativo)
• Pertencimento (ser parte de uma equipe)
• Crescimento (aprender e melhorar)
• Intimidade (relacionamentos próximos e de confiança)

As práticas XP devem atender essas necessidades. Programação em par atende necessidades de pertencimento e intimidade. Desenvolvimento orientado a testes atende necessidades de realização e segurança. Ritmo sustentável protege a saúde física e mental.

Quando uma prática parece errada, pergunte: "Isso está violando necessidades humanas?"

Dinheiro importa. Tempo tem valor. Opções têm valor.

XP leva economia a sério:

• Valor do tempo do dinheiro: Uma funcionalidade entregue hoje vale mais que a mesma funcionalidade em seis meses
• Opções: Manter escolhas em aberto tem valor (daí evitar compromissos excessivos)
• Custo do atraso: Esperar para entregar valor tem custos reais

Este princípio apoia entregas pequenas (entregar valor cedo), design incremental (não investir demais antecipadamente) e planejamento iterativo (responder ao que você aprende).

Também apoia ritmo sustentável: desenvolvedores exaustos cometem erros caros.

Cada prática deve beneficiar todos os envolvidos.

As melhores práticas XP são ganha-ganha-ganha:

• Testes ajudam o desenvolvedor (confiança), a equipe (documentação) e futuros desenvolvedores (rede de segurança)
• Programação em par ajuda ambos os parceiros (aprendizado, captura de erros) e o código (qualidade)
• Código simples ajuda o autor (mais rápido de escrever) e leitores (mais fácil de entender)

Evite práticas que ajudam um grupo às custas de outro. Documentação escrita apenas para conformidade, nunca lida por desenvolvedores, falha no benefício mútuo. Código escrito para ser inteligente em vez de claro também falha.

Se uma prática cria ressentimento, ela provavelmente viola o benefício mútuo.

Padrões que funcionam em uma escala frequentemente funcionam em outras.

XP aplica os mesmos padrões em diferentes escalas:

• Vermelho-verde-refatorar (testes): Faça falhar, faça passar, faça limpo
• Planejar-fazer-estudar-agir (iterações): Planeje o trabalho, faça o trabalho, estude os resultados, ajuste
• Coletar-agrupar-votar (retros): Colete dados, encontre padrões, decida ações

Quando você encontra algo que funciona, tente em diferentes escalas. O jogo de planejamento funciona para planejamento de release e planejamento de iteração. Princípios de revisão de código funcionam para revisão de design e revisão de arquitetura.

Comece onde você está e melhore continuamente.

XP não exige perfeição desde o primeiro dia. Exige movimento. Comece com o que você pode fazer hoje e melhore a partir daí.

• Não tem testes? Escreva um teste para o próximo bug que você corrigir.
• Não está fazendo programação em par? Tente por uma hora amanhã.
• Sem integração contínua? Faça commit com mais frequência.

O objetivo não é "estar fazendo XP". O objetivo é estar melhorando. XP é uma direção, não um destino.

Este princípio também apoia falhar com segurança. Experimentos que não funcionam são oportunidades de aprendizado, não falhas.

Entregue valor continuamente, não em grandes lotes.

Este princípio alinha XP com pensamento lean e Kanban. Grandes lotes escondem problemas. Pequenos lotes os revelam rapidamente.

• Histórias pequenas (dias, não semanas)
• Releases frequentes (semanalmente, não trimestralmente)
• Integração contínua (horas, não dias)
• Testes imediatos (segundos, não horas)

Fluxo reduz trabalho em progresso, o que reduz troca de contexto, o que melhora foco e qualidade. Também entrega valor aos clientes mais cedo e feedback mais rápido.

Qualidade não é negociável.

Isso parece óbvio, mas as implicações são profundas. XP diz que você pode negociar escopo ou cronograma, mas nunca qualidade.

Isso significa:

• Testes não são opcionais quando o tempo está apertado
• Refatoração não é um luxo
• Débito técnico não é aceitável
• "Entregue agora, corrija depois" não é um plano

Por quê? Porque qualidade é a base da velocidade. Qualidade ruim cria bugs que te atrasam. Qualidade ruim cria código difícil de mudar. Qualidade ruim cria sistemas caros de manter.

Qualidade é a maneira mais rápida de ir rápido.

Dê o menor passo que faça progresso.

Grandes mudanças são arriscadas. Pequenas mudanças são seguras. XP sempre prefere passos pequenos:

• Escreva um teste que falha antes de escrever qualquer código
• Refatore uma coisa de cada vez
• Integre após pequenas mudanças, não grandes
• Faça release de incrementos pequenos, não grandes releases

Passos de bebê não significam progresso lento. Mil passos pequenos podem cobrir mais terreno que dez grandes saltos—e com menos chance de cair.

Quando você estiver travado, pergunte: "Qual é a menor coisa que posso fazer agora que faça progresso?"