-
Questão errada! XP não é uma metodologia "engessada" e que irá definir um prazo de 180 dias para grandes releases. Pelo contrário, a metodologia prega a liberação de versões ao cliente de forma rápida, contínua e integrada.
Extreme Programming é dinâmica e flexível, porém é necessário muita disciplina para usá-la em um projeto. Para demonstrar isso, abaixo temos um conjunto sugerido de "boas práticas" em projetos usando XP:
- O cliente sempre disponível
- Uso de metáforas no projeto
- Planejando o jogo
- Pequenas versões
- Testes de aceitação
- Desenvolvimento orientado a testes
- Integração contínua
- Simplicidade do projeto
- Refatoração - melhoria constante do código
- Programação em dupla
- Rodízio de pessoas
- Propriedade coletiva do código
- Padronização do código
- Ritmo sustentável (40 horas semanais)
Fonte: http://www.devmedia.com.br/extreme-programming-conceitos-e-praticas/1498
Creio que outro erro existente na questão é o trecho "em que todos os
requisitos são expressos como cenários": podem existir cenários, mas o que prevalece são estórias de usuário.
-
Colega Silas, apenas uma correção:
"Em Extreme Programming, os requisitos são expressos como cenários (chamados de histórias do usuário), que são implementados diretamente como uma série de tarefas. Os programadores trabalham em pares e desenvolvem testes para cada tarefa antes de escreverem o código. Quando o novo código é integrado ao sistema, todos os testes devem ser executados com sucesso. Há um curto intervalo entre os releases do sistema."
Ou seja, cenários são chamados também de histórias do usuário.
Fonte: Sommerville, 9 ed, pág. 44
-
Também acredito que cenários e histórias de usuários são termos que tem o mesmo significado para o XP. O erro da questão está mais claro quando se fala em ciclos de 180 dias.
-
Se ele pára em "todos os requisitos são expressos como cenários" eu ficaria em dúvida! :p