-
Somente a I e a III estão corretas.
I É viável a utilização do TDD (Test Driven Development) na fase de sprint, de modo que se escreva o teste automático antes da codificação.
Correta. OTDD implica escrever o CÓDIGO DE TESTE antes do código de produção, um teste de cada vez, tendo certeza de que o teste falha antes de escrever o código que irá fazê-lo passar.
III Integrantes da equipe scrum podem realizar a programação do código em pares, o que proporciona, entre outras vantagens, o nivelamento de conhecimento da equipe.
Correta. O scrum contém uma certa ligação com o XP - eXtreme Programming, que utiliza o conceito de programação em pares
-
Interessante essa questão. Ajuda a desmistificar alguns conceitos que acabam ficando presos "na caixa".
Particularmente, vejo o Scrum como uma forma (ou poderia chamar de metodologia) de apoio ao gerenciamento de projetos, pois ele possui os papéis, as reuniões time-boxed etc., contribuindo para um certo "rigor" ao se gerenciar os projetos de desenvolvimento de software (e, diga-se de passagem, não está restrito a desenvolvimento de software :) (por que estaria?) ). Nesse contexto, qualquer outra "ideia" (preferencialmente de metodologia ágil) para melhoria do desempenho e da qualidade das entregas caberia.
-
Alternativa:
IV O conceito de requisito “pronto” continuaria válido, contudo, inviabilizaria o refactoring, pois é proibitivo inserir o mesmo item (requisito) em várias sprints.
A pegadinha é a seguinte: No scrum, um requisito se for grande pode ser inserido em várias sprints, mas não se refere que eu recorde a que o mesm o requisito volte ou apareça em várias sprints. O refactoring não é uma prática do Scrum, nem há algo semelhante.
-
IV O conceito de requisito “pronto” continuaria válido, contudo, inviabilizaria o refactoring, pois é proibitivo inserir o mesmo item (requisito) em várias sprints.
==============
O refactoring é um dos pilares do XP, onde se evita tomar grandes decisões de projeto (design) no início, postergando essas decisões até o momento onde elas se tornem necessárias. Só é possível postergar tais decisões graças a possibilidade de refatoração do código já escrito. Matar a refatoração é matar o XP por completo.