Os Cinco Valores do XP

XP não é apenas uma coleção de práticas—é um sistema de valores. As práticas só fazem sentido no contexto dos valores. Sem os valores, você tem XP cargo-cult: equipes seguindo os movimentos sem o espírito.

Os cinco valores do XP são: Comunicação, Simplicidade, Feedback, Coragem e Respeito.

Estes não são pôsteres aspiracionais. São ferramentas de tomada de decisão. Quando você não tem certeza do que fazer, pergunte qual escolha melhor incorpora esses valores.

Comunicação é o primeiro valor porque desenvolvimento de software é fundamentalmente um problema de comunicação. Não estamos apenas escrevendo código—estamos traduzindo necessidades humanas em instruções de máquina.

Mal-entendidos são a causa raiz da maioria dos bugs. O cliente diz "rápido", o desenvolvedor implementa cache, mas o cliente queria dizer "menos cliques". Abordagens tradicionais tentam resolver isso com documentação. XP resolve com comunicação contínua.

No XP, comunicação significa:

• Programação em par (comunicação técnica constante)
• Cliente no local (comunicação constante de requisitos)
• Standups diários (comunicação constante da equipe)
• Código simples (código que comunica sua intenção)

O oposto da comunicação: presumir que você sabe o que é necessário, trabalhar isolado, escrever código inteligente e jogar especificações por cima do muro.

Simplicidade significa fazer a coisa mais simples que poderia funcionar. Não a mais elegante, não a mais extensível, não a mais geral—a mais simples.

Isso é capturado no mantra do XP YAGNI: You Aren't Gonna Need It (Você Não Vai Precisar Disso). Não construa frameworks. Não adicione pontos de extensão. Não generalize. Construa exatamente o que é necessário hoje.

Por quê? Porque:

• Código simples tem menos bugs
• Código simples é mais fácil de mudar
• Código simples é mais fácil de entender
• Metade do que você acha que vai precisar, você não vai

Isso não significa desleixado ou improvisado. Código simples é frequentemente mais difícil de escrever do que código complexo. Requer pensar profundamente sobre o que é realmente essencial.

O oposto da simplicidade: construir para requisitos futuros hipotéticos, adicionar flexibilidade "por precaução", criar abstrações antes de precisar delas.

Feedback é como você aprende se está fazendo a coisa certa. XP cria loops de feedback em todas as escalas:

• Segundos: Testes unitários dizem se seu código funciona
• Minutos: Parceiro de par detecta erros enquanto você digita
• Horas: Integração diária revela problemas de integração
• Dias: Iterações semanais mostram progresso aos clientes
• Semanas: Ciclos de release confirmam que você está construindo a coisa certa

Quanto mais rápido o feedback, mais barato o conserto. Um bug detectado em segundos não custa nada. Um bug detectado em produção custa tempo, dinheiro e reputação.

As práticas do XP são projetadas para criar feedback rápido e honesto. Testes não mentem. Software funcionando não mente. Métricas de produção não mentem.

O oposto do feedback: trabalhar isolado por semanas, esperar até o final para testar, evitar contato com o cliente, ignorar métricas de produção.

Coragem significa fazer o que precisa ser feito, mesmo quando é desconfortável. No XP, coragem aparece como:

• Refatorar impiedosamente: Mudar código funcionando para torná-lo mais simples
• Jogar código fora: Deletar código que não está cumprindo seu papel
• Pedir ajuda: Admitir que você não sabe algo
• Falar abertamente: Dizer ao cliente quando as estimativas estão erradas
• Tentar coisas novas: Experimentar mesmo quando você pode falhar

Coragem não é imprudência. É apoiada pelos outros valores. Você pode refatorar com coragem porque tem testes (feedback). Você pode falar abertamente porque tem relacionamentos com o cliente (comunicação).

O oposto da coragem: deixar janelas quebradas, inflar estimativas para estar "seguro", esconder más notícias, fazer o que sempre foi feito.

Respeito foi adicionado na segunda edição do livro de Kent Beck, reconhecendo o que sempre foi implícito: XP só funciona quando os membros da equipe se respeitam.

Respeito significa:

• Confiar na competência dos colegas (não microgerenciar)
• Valorizar a contribuição de todos (desenvolvedores, testadores, clientes)
• Dar feedback honesto com gentileza (não esmagar espíritos)
• Cuidar do seu próprio trabalho (não criar fardos para outros)

Na programação em par, respeito significa ouvir as ideias do seu parceiro. No planejamento, respeito significa dar estimativas honestas. Na revisão de código, respeito significa criticar código, não pessoas.

O oposto do respeito: descartar ideias sem consideração, atribuir culpa, tratar alguns papéis como menos importantes, se importar mais em estar certo do que em ser eficaz.