Vamos analisar cada uma das alternativas.
I. Todo o código desenvolvido pelo time é incorporado em um repositório comum várias vezes ao dia. Isso garante que qualquer problema de integração ao longo do projeto possa ser notado e corrigido rapidamente.
Está falando de continuous integration, a prática de integrar continuamente o código em um repositório central e rodar uma build automatizada que compila tudo e executa todos os testes para detectar eventuais problema de integração.
II. Qualquer programador do time pode alterar qualquer seção do código, se necessário. Por mais que esta prática pareça perigosa, ela aumenta a velocidade do desenvolvimento e problemas em potencial podem ser detectados pelos testes de unidade.
Está falando de collective code ownership. No XP (e nas metodologias ágeis em geral) não existe aquela figura do programador que é “dono” de certa parte do código. O conhecimento é sempre compartilhado entre todos os desenvolvedores do time de forma que qualquer um possa mexer em qualquer parte do código. Isso é salutar porque não ficamos com o risco de descontinuidade no projeto em caso de ausência de alguém da equipe, dentre outras vantagens.
III. Traz a ideia de que qualquer pessoa do time seja capaz de verificar o código sendo desenvolvido em alto nível e ter uma compreensão clara de qual funcionalidade do sistema está sendo trabalhada.
Está falando de system metaphor, onde cada parte do sistema recebe um nome amigável, facilmente entendida por todos (inclusive o cliente). Dessa forma, fugindo de termos técnicos e focando nas metáforas, a comunicação é facilitada e permite o que foi descrito, que qualquer pessoa do time seja capaz de verificar o código em alto nível.
IV. Permite aplicar melhorias ao código sem mudar sua funcionalidade, visando sua simplificação. Se o cliente deseja alterar alguma coisa no produto final, o time pode fazer os ajustes rapidamente, e esta prática contribui para alcançar este objetivo.
Está falando de refactoring, que é a técnica de mudar um trecho de código (um método, uma classe, um módulo, um bloco) sem alterar a sua funcionalidade. O desenvolvedor reescreve o código tornando-o mais claro sem alterar o objetivo final do mesmo.
Resumindo, as afirmativas I, II, III e IV falam de continuous integration, collective code ownership, system metaphor e refactoring, respectivamente. Isso dá gabarito letra E.
Resposta: E