-
Resposta: letra B.
O Scrum propõe a existência de uma tríplice restrição formada por escopo, importância e estimativa, onde escopo e importância são definidos pelo product owner. Estimativa é definida pela equipe durante uma reunião de planejamento do sprint, estas três variáveis são refinadas continuamente por diálogo cara-a-cara entre equipe e product owner.
-
As expressões "em função das iterações" e "ao longo do projeto" parecem ter significados equivalentes no contexto apresentado. Vocês não acham?
-
Fiquei com a mesma dúvida do rapaz acima! :/
-
Concordo com o Daniel Luiz
-
Fiz essa questão e também achei que as letras B e E estão certas. O custo é por funcionalidade adicionada. Cada iteração representa(m) nova(s) funcionalidade(s).
-
Compartilho do entendimento dos colegas acima, os termos iterações e ao longo do projeto me parecem, no contexto, termos que tratam da mesma coisa.
Afinal as iterações ocorrem ao longo do projeto, e o projeto é contruido em função das iterações. O produto final é contruido em função das iterações, bem como a data final e o custo do projeto.
Questão muito estranha...
-
FCC aprontando mais uma das suas... já nem me esquento mais. Imagine o tanto de recursos contra essa questão, e não foi anulada. Esse país é terra de ninguém.
-
Na verdade iteração é o conceito para o ciclo do XP, assim como Sprint é o conceito da iteração no Scrum. Por isso que a questão continuou válida e o gabarito é a letra B.
-
SCRUM não tem iterações, mas Sprints, portanto é fácil de entender porque a E não está correta. Tem algumas perguntas da FCC que são estranhas mesmo, mas neste caso é uma resposta errada, ou seja, eles põe o que quiserem e o candidato tem que saber que aquilo não é relacionado o assunto da pergunta e ponto, se o conceito estivesse na pergunta aí sim dava para questionar anulação, mas na resposta, se fosse assim não iam existir perguntas válidas, pelo menos eu vejo dessa forma.
-
Retirado so Scrum Guide 2011.
Um dos itens da Revisão da Sprint:
"O Product Owner discute o Backlog do Produto tal como está. Ele (ou ela) projeta as prováveis datas de conclusão baseado no progresso até a data;"
Como todos sabem, o Product Backlog é dinâmico. O custo é baseado no tempo e no escopo. Logo estão relacionados.
Se o Scrum Guide diz que a cada revisão é avaliado como o Product Backlog está, sabendo que o PO pode mudá-lo constantemente, e que é avaliado prováveis datas de conclusão (ou seja, a cada Revisão pode alterar)...infere-se que:
- custo
- data final
- produto final (soma dos requisitos do Product Backlog implementados "Pronto",
são decididos ao longo do projeto (Reviews)
-
Pessoal,
Me desculpem mas eu entendo que a resposta certa para este pergunta deveria ser a C, porque o produto final , data final e o custo do projeto deve ser definido no planejamento do projeto, senão, como alguém poderia fechar um projeto utilizando SCRUM sendo que o custo seria mapeado ao longo do projeto?
Não faz sentido :(
a questão é que se houver mudanças ao longo do projeto, estas serão tratadas como aumento de escopo e impactarão no prazo e no custo, porém caso o projeto mantiver o backlog original, tanto o scrum master quanto a equipe, terão que trabalhar para alcançar o prazo definido com o custo definido.
-
Cara Michele H., é claro que o SCRUM possui iterações, afinal de contas ele é um método ITERATIVO E INCREMENTAL, como todas as demais metodologias ágeis e até mesmo algumas não-ágeis como RUP e RAD.
-
Essa questão deveria ter sido anulada, pois há duas alternativas corretas a letra (B) e (E). Vejamos abaixo.
Como outros métodos ágeis, Scrum é uma metodologia que prima pelo desenvolvimento iterativo e incremental de software. Em termos práticos, isto significa que ciclos contendo um conjunto de específico de atividades são repetidos continuamente ao longo de um projeto; por incremental, deve-se ter em mente a ideia de sucessivas entregas de funcionalidade, acrescentando aquilo que se espera do software em intervalos constantes de tempo.
-
No Scrum, o tempo e o custo geralmente são fixos e o escopo é variável, ou seja, eu não parto do escopo para descobrir o tempo - eu parto do tempo para descobrir o escopo. Ser fixo não significa que é determinado antes. Eu posso dizer que minha data final é daqui três meses e a equipe de projeto vai fazer quantas funcionalidades conseguir nesse tempo. Ao longo do projeto, eu posso dizer que tenho mais três meses para entregar e a equipe dirá que dá para fazer mais algumas funcionalidades. Então, eu sempre parto do tempo para decidir o escopo e não do escopo para definir o tempo. Por que? Porque senão o projeto dura eternamente. O PO muda de ideia, pede mudanças, adiciona requisitos e o escopo do projeto nunca é alcançado e nunca chega ao fim do projeto. Então, isso é definido ao longo do projeto.
Gabarito: Letra B
-
Como que a data final é definida ao longo do projeto? kkkkk