Comunicação

XP enfatiza a comunicação face a face em detrimento de outros tipos de comunicação, tais como documentos. XP valoriza os documentos, mas valoriza muito mais a comunicação pessoal. Para facilitar a comunicação, as equipes XP:

• Usam um vocabulário ou metáfora comum do sistema.
• Trabalham bem perto uns dos outros em um espaço aberto.
• Integram o código continuamente.
• Trabalham em estreita colaboração com os profissionais do negócio, de preferência no mesmo ambiente físico.
• Programam em pares.
• Possuem o código coletivamente.
• Planejam e informam o status para o cliente, frequentemente.

Simplicidade

XP pressupõe que é melhor fazer a coisa simples hoje e pagar um pouco mais amanhã se uma melhoria for realmente necessária do que fazer uma coisa complicada hoje, que nunca será usada. Esta é uma filosofia fundamental que permeia tudo em um projeto XP. Se algo não for necessário agora, nós não o faremos hoje.

Por exemplo:

• Não escreveremos nenhum documento, até que exista uma necessidade imediata e significativa.
• Não adotaremos nenhuma ferramenta a menos que haja um benefício tangível e verificável.
• Evitaremos escrever a infraestrutura até que seja necessária ao código existente.

Para manter a simplicidade do software e da estrutura da equipe, as equipes XP:

• Perguntam-se: Qual é a coisa mais simples que pode funcionar?
• Simplificam e melhoram o design continuamente através da refatoração.

Há algum tempo atrás, Kent Beck ofereceu as seguintes regras para um design simples. Em ordem prioritária, o código deve:

1. Passar em todos os testes.
2. Não conter código duplicado.
3. Expressar todas as ideias que o autor deseja expressar.
4. Minimizar as classes e os métodos.

Feedback

O feedback funciona em diferentes escalas na XP.

No nível mais alto, o cliente pode ver o progresso da equipe através da entrega de software executável a cada duas semanas. Esse feedback contínuo permite que o cliente dirija o projeto ao sucesso. Obtemos feedback concreto sobre o estado do sistema, na forma de pedaços de funcionalidade executáveis que passam repetidamente pelos testes automatizados de aceitação. Estes testes impedem que o desenvolvimento do sistema recue. Nenhuma nova liberação do sistema pode falhar nos testes de aceitação usados.

No nível de programação, os programadores escrevem testes de unidade para toda a lógica do sistema a fim de obter feedback imediato e concreto que lhes informe se o código que acabaram de escrever está fazendo o que eles desejam.

Equipes XP:

• Desenvolvem em pequenas liberações.
• Desenvolvem em menores iterações.
• Agrupam os requisitos e as funcionalidades em histórias que se encaixam em uma iteração.
• Decompõem as histórias em tarefas ainda menores.
• Escrevem pequenos testes de unidade para assegurar que o código gerado nas tarefas funciona adequadamente.
• Escrevem testes de aceitação para assegurar que as histórias funcionem corretamente.
• Acompanham o progresso e comunicam-no ao cliente com frequência.

Coragem

Talvez um melhor nome para este valor seja confiança. Para funcionar, os membros de uma equipe XP têm que ter a coragem de confiar uns nos outros, nos seus clientes, nas suas práticas e em si próprios.

Os membros da equipe XP sabem que podem:

• Parar quando estão cansados.
• Deixar que todas as decisões de negócio sejam feitas pelo cliente.
• Solicitar aos clientes a redução do escopo de uma liberação.
• Solicitar ajuda aos seus pares ou clientes.
• Projetar e implementar apenas o que seja necessário para hoje e deixar para amanhã o que será necessário amanhã.
• Fazer as alterações que melhorem a funcionalidade ou estrutura do código.
• Concertar o design e atualizar o código existente quando o design se demonstrar inadequado.
• Jogar código fora.
• Alterar o código que não escreveram.
• Alterar o processo quando não estiver funcionando.