A partir dos princípios citados, foram definidas doze práticas básicas que são adotadas pelo XP.
Em relação às doze práticas, Bona (2002) e Kuhn e Pamplona (2004) apresentam as seguintes descrições:
1. Jogo de Planejamento (Planning Game): Rapidamente determina o escopo das próximas versões combinando as prioridades do negócio e estimativas técnicas. Como prática, estrutura o plano e atualiza-o. O planejamento é feito muitas vezes ao longo do projeto, o cliente descreve com suas palavras, através de cartões de histórias, o que deseja que o sistema faça e com isso a equipe consegue estimar o custo e o tempo de cada história.
2. Pequenas versões (Small releases): Releases são pequenos intervalos de tempo, onde um conjunto de funcionalidade bem definidas e que gerem valor ao cliente são entregues. O time XP coloca rapidamente um sistema simples em produção, e o atualiza freqüentemente em ciclos bastante curtos.
13. Metáforas: Guiam todo o desenvolvimento e a comunicação com o cliente utilizando um “sistema de nomes” e uma descrição do sistema. São comparações e analogias com o assunto em questão que proporcionarão as pessoas uma compreensão rápida deste assunto e que possivelmente não a esquecerão mais.
4. Projeto simples (Simple design): O sistema precisa ser projetado o mais simples possível satisfazendo os requisitos atuais. O design do sistema deve ser de forma simples para que atenda as necessidades do cliente.
5. Teste: Os times XP focalizam a validação do software durante todo o processo. Os programadores escrevem primeiro os testes e só então, continuam o desenvolvimento que deve atender os requisitos destes testes, são os testes de unidade. Os clientes escrevem testes para validar se os requisitos estão sendo atendidos, esses testes são chamados de testes de aceitação.
6. Refactoring: Os times procuram aperfeiçoar o projeto do sistema durante todo o desenvolvimento, mantendo a clareza do software: sem ambigüidade, com alta comunicação, simples, porém completo. Todo desenvolvedor tem a possibilidade de melhorar qualquer código do sistema, desde que esta alteração não mude o comportamento do código em questão.
7. Programação em pares (Pair Programming): Todo código produzido é feito em duplas, ou seja, dois programadores trabalhando juntos na mesma máquina. Com esta prática enquanto o digitador codifica o problema o outro revisa o código digitado percebendo com facilidade pequenos erros de programação.
8. Propriedade coletiva (Colletive ownership): Todo código pertence a todo o time. Então, qualquer um pode alterar qualquer código em qualquer tempo. Isso permite que o código seja revisado por diversas pessoas, onde qualquer uma pode alterá-lo tornando-o mais legível.
9. Integração contínua (Continnuous integration): Integra e constrói o sistema de software várias vezes por dia. A todo o momento, uma tarefa é completada. Sendo possível um feedback da alteração efetuada em um menor espaço de tempo.
10. Semana de 40-horas (40-hour week): Como regra, não se deve trabalhar mais que 40 (quarenta) horas na semana. Possibilitando à equipe uma contínua concentração minimizando falhas de implementação. Programadores exaustos cometem mais erros.
11. Cliente dedicado (On-site customer): A equipe XP tem o cliente disponível o tempo todo, o qual descreve os requisitos, atribui as prioridades e reponde as dúvidas encontradas pelos desenvolvedores do sistema.
12. Código padrão (Coding standards): Todos os programadores escrevem o código da mesma forma, de acordo com regras que asseguram clareza e comunicação através do código. Com isso agiliza e facilita o desenvolvedor a fazer as modificações e adaptações durante o projeto.
A metodologia XP não utiliza diagramas para implementar. A equipe se une para desenvolver práticas simples, obtendo feedback suficiente para ajustar as práticas a sua situação particular.
Mais resumos sobre As Doze Práticas do XP