Releases grandes (Afirmação errada e alternativa errada)
Versões Pequenas: Release é algo que é implantado no cliente, ou seja, está pronto para ser utilizado. As Releases normalmente são pequenas e frequentes (a cada 2-3 meses) sendo que funcionalidades prioritárias são desenvolvidas mais cedo para serem entregues mais rapidamente ao cliente, pois prioriza-se o que ele mais precisa no momento. Uma Release também pode ser guiada por funcionalidade ou prazo, nesse caso deveremos analisar o que é mais importante, liberar até um certo dia, ou liberar com determinadas funcionalidades. Releases são construídas ao longo de iterações. Uma iteração sempre alcança algum objetivo perceptível ao cliente, ou seja, não adianta usarmos uma iteração para projetarmos ou melhorarmos a arquitetura do nosso software se ele não vai agregar absolutamente nenhum valor ao cliente. Nada é feito que não seja imediatamente útil e necessário para não afetar os prazos de desenvolvimento.
integração das funcionalidades, mesmo com erros. (Afirmação errada e alternativa errada)
Além do que foi dito sobre os testes,
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.
fonte: https://www.devmedia.com.br/praticas-em-xp-extreme-programming/29330
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. (Resposta certa)
Time-box de 40 horas: "Timeboxing" é um termo de gerenciamento de tempo (geralmente utilizado em Scrum) que se refere ao limite do tempo fixado para cada atividade e processo. O XP preconiza que não se pode trabalhar horas extras por mais de uma semana (mais de 40h/semana), pois trabalho extra é sintoma de que algo está errado. Devemos manter um ritmo sustentável. (Afirmação correta, mas alternativa errada)
Testes apenas depois da codificação (Afirmação errada e alternativa errada)
Em XP, os testes são escritos antes da funcionalidade, o que também é conhecido como TDD (Test-Driven Design) onde intercala-se a função de testar um pouco e codificar um pouco. Além disso, o TDD impõe o programador à saber o que deve ser verdadeiro no programa e o que não deve ser para que ele funcione corretamente, portanto, pensa-se primeiramente no problema e depois na solução. Dessa forma, os testes são automatizados, diferente de anteriormente onde o desenvolvedor fazia a implementação e entregava para alguém testar. Com os testes automatizados podemos executá-los a qualquer momento, e dessa forma, novas funcionalidade ou alterações podem ser imediatamente testadas para ver se essas mexidas não acarretaram outros problemas.
fonte: https://www.devmedia.com.br/praticas-em-xp-extreme-programming/29330