1. Teste XP
1.1. Desenvolvimento Test-First
1.1.1. O desenvolvimento test-first é uma das mais importantes inovações no XP. Em vez de escrever algum código e, em seguida, escrever testes para esse código, você escreve os testes antes de escrever o código. Isso significa que você pode executar o teste enquanto o código está sendo escrito e pode encontrar problemas durante o desenvolvimento.
1.2. Desenvolvimento de teste incremental a partir de cenários
1.2.1. No desenvolvimento test-first, os implementadores de tarefas precisam entender completamente a especificação para que possam escrever testes para o sistema. Isso significa que as ambiguidades e omissões da lista de especificações devem ser esclarecidas antes do início da implementação. Além disso, também evita o problema de ‘test-lag’. Isso pode acontecer quando o desenvolvedor do sistema trabalha em um ritmo mais rápido que o testador. A implementação fica mais e mais à frente dos testes e desenvolve-se uma tendência a ignorar os testes,a fim de que o cronograma de desenvolvimento possa ser mantido.
1.3. Envolvimento dos usuários no desenvolvimento de teste e validações
1.3.1. Uma grande dificuldade no processo de teste em XP é contar com o apoio do cliente no desenvolvimento de testes de aceitação. Clientes têm muito pouco tempo disponível e podem não conseguir trabalhar com a equipe de desenvolvimento em tempo integral. O cliente pode sentir que fornecer os requisitos seja uma contribuição suficiente e, dessa forma, pode estar relutante em se envolver no processo de testes.
1.4. Uso de frameworks de testes automatizados
1.4.1. Automação de testes é essencial para o desenvolvimento test-first. Os testes são escritos como componentes executáveis antes que a tarefa seja implementada. Esses componentes de teste devem ser autônomos, devem simular a submissão de entrada a ser testada e devem verificar se o resultado atende à especificação de saída. Um framework de testes automatizados é um sistema que torna mais fácil escrever os testes executáveis e submeter um conjunto de testes para execução. Junit (MASSOL e HUSTED, 2003) é um exemplo amplamente usado de framework de testes automatizado.
2. Extreme Programmig
2.1. Desenvolvimento Incremental
2.1.1. O desenvolvimento incremental é sustentado por pequenos e frequentes releases do sistemas. Os requisitos são baseados e cenários ou em simples estorias de clientes, usados como base para decidir a funcionalidade que deve ser incluída em um incremento no sistema.
2.2. Envolvimento do Cliente
2.2.1. O envolvimento do cliente é sustentado por meio do engajamento contínuo do cliente com a equipe de desenvolvimento. O representante do cliente participa do desenvolvimento e é responsável por definir os teste de aceitação para o cliente.
2.3. Pessoas - Não Processo
2.3.1. São sustentadas por meio de programas em pares, propriedade coletiva do código do sistema e em processo de desenvolvimento sustentável que não envolvem horas de trabalho excessivamente longas.
2.4. Mudanças
2.4.1. As mudanças são aceitas por meio de releases contínuos para os clientes, do desenvolvimento do test-first da refatoração para evitar a degeneração do código e integração continua de nova funcionalidade.
2.5. Manutenção
2.5.1. A manutenção da simplicidade é feita por meio da fatoração constante que melhora a qualidade do código, bem como por meio de projetos simples que não antecipam desnecessariamente futuras mudanças no sistema.
3. Programação em Pares
3.1. Suporte a Ideia
3.1.1. Dá suporte à ideia de propriedade e responsabilidade coletiva para o sistema, o que reflete a ideia de programação sem ego, de Weinberg (1971), segundo a qual o software é de propriedade da equipe como um todo e os indivíduos não são responsabilizados por problemas com o código. Em vez disso, a equipe tem responsabilidade coletiva para resolver esses problemas.
3.2. Processo de Revisão
3.2.1. Atua como um processo de revisão informal, porque cada linha de código é observada por, pelo menos, duas pessoas. Inspeções e revisões do código (abordadas no Capítulo 24) são muito bem-sucedidas em descobrir uma elevada porcentagem de erros de softwares. No entanto, são demoradas para organizar e costumam apresentar atrasos no processo de desenvolvimento. Embora a programação em pares seja um processo menos formal que provavelmente não encontra tantos erros como as inspeções de código, é um processo de inspeção muito mais barato do que inspeções formais de programa.
3.3. Suporte a Refatoração
3.3.1. Dá suporte à refatoração, que é um processo de melhoria de software. A dificuldade de implementar isso em um ambiente de desenvolvimento normal é que o esforço despendido na refatoração é para um benefício a longo prazo. Um indivíduo que pratica a refatoração pode ser considerado menos eficiente do que aquele que simplesmente atua no desenvolvimento de código.