O XP é uma metodologia de desenvolvimento de software que se destina a melhorar a qualidade do software e a capacidade de resposta às mudanças nos requisitos do cliente. Como um tipo de desenvolvimento de software ágil, ele defende "releases" frequentes em ciclos curtos de desenvolvimento, com o objetivo de melhorar a produtividade e introduzir pontos de verificação nos quais novos requisitos do cliente podem ser adotados.

Outros elementos de programação extrema incluem: programação em pares ou code review, teste unitário de todo o código, evitar programação de recursos até que sejam realmente necessários, estrutura de gerenciamento horizontal, simplicidade de código e clareza, esperando mudanças nos requisitos do cliente com o passar do tempo e à medida que o problema é melhor compreendido, e comunicação frequente com o cliente e entre os programadores. A metodologia leva o nome da ideia de que os elementos benéficos das práticas tradicionais de engenharia de software são levados a níveis "extremos". Por exemplo, as revisões de código são consideradas uma prática benéfica; levado ao extremo, o código pode ser revisto continuamente, isto é, a prática da programação em par.

Programação em pares: Trata-se de duas pessoas trabalhando com UMA máquina onde um codifica, e o outro critica ou dá sugestões. Os pares trocam de lugar periodicamente. Essa prática é excelente e favorece comunicação e aprendizado. Com essa troca constante de ideias temos como resultado um Projeto de maior qualidade e como estudos comprovam temos maior produtividade e maior qualidade (com padrão de codificação e entendimento do código e partes do código que não eram entendidos). Essa prática também facilita aprendizado dos novos integrantes.

Evidente que essa prática requer ambiente de trabalho apropriado como, por exemplo, um ambiente que provê mobilidade, e pessoas que devem concordar com o barulho que será causado.

Projeto Simples: Projetos flexíveis são considerados uma defesa contra mudanças imprevistas no software, porém, projetos flexíveis também têm custos, tempo para desenvolvimento e manutenção, além de um código mais complexo e que muitas vezes nunca será utilizado.

O XP preconiza que a mudança é barata, pois ele utiliza ciclos curtos, projetos simples, refatorações, por isso mantém-se o projeto o mais simples possível, modificando-o quando for necessário suportar mais funcionalidade. Portanto, o XP diz que o melhor e mais simples projeto é aquele que passa em todos os testes, não contém duplicação de funcionalidade, salienta as decisões de projeto importantes e tem o menor número possível de classes e métodos.

Refatoração: A refatoração significa melhorar o código sem alterar sua funcionalidade. Antes de uma mudança sempre refatoramos o código para facilitar a realização de mudanças. Ou seja, se após a refatoração o código continua funcionando como anteriormente, incluímos as novas mudanças. A refatoração contínua possibilita manter um bom projeto, apesar das mudanças frequentes. O Projeto é uma atividade diária, de responsabilidade de todos.

A refatoração provê um aumento contínuo de qualidade do código.

Propriedade Coletiva: Todos podem modificar o código a qualquer momento. Códigos não pertencem a apenas uma pessoa. A melhor forma de evitarmos problemas como trocas de pessoas da equipe e com isso a perda de conhecimento é a propriedade coletiva, onde todos mexem em todas as partes do programa e conhecem de tudo um pouco.

Integração Contínua: Todo código deve ser integrado diariamente e todos testes devem passar antes e depois da integração. Se algum problema é encontra do ele deve ser corrigido imediatamente.

Cliente presente: Clientes devem estar presentes para escrevem testes de aceitação, definirem prioridades e histórias para as futuras iterações.

Semana de 40 horas: O XP preconiza que não se pode trabalhar horas extras por mais de uma semana, pois trabalho extra é sintoma de que algo está errado. Devemos manter um ritmo sustentável.

Padrões de Codificação: Todos mexem em todos os códigos, todos refatoram e todos trabalham em pares. Assim é interessante mantermos um padrão para termos algo solidificado. Por isso a melhor forma é a equipe definir um padrão de codificação sempre no inicio dos projetos.

Metáfora: é uma linguagem comum que todos devem possuir. Por exemplo, ao invés de descrevermos como uma certa arquitetura funciona apenas comunicamos o seu nome e todos entendem o que um programador quis dizer.

Reunião diária: é uma prática vinda do SCRUM em que todos fazem uma rápida reunião de pé para discutir o que foi feito no dia anterior, o que será feito no dia atual e se existe algum impedimento.