-
O metódo ágil SCRUM utiliza o Gráfico de Burndown - Burndown chart que é um diagrama usado pela equipe de Scrum para mostrar quanto trabalho falta no SPRINT. Ou seja, Os gráficos típicos de burndown mostram as horas acumuladas a serem concluídas e, em seguida, medem as horas reais, consumidas em relação às horas planejadas, para representar o consumo das horas planejadas.
Fonte: Scrum em Ação - Por Andrew Pham,Phuong-Van Pham.
Letra B
-
Fugi da (B) porque falar que o increment (que aliás, eu sempre vi como product increment) é projetado para transparência e inspeção me pareceu estranho.
Agora que errei, pensando bem, acho que o incremento no produto te dá sim meios de testar, inspecionar o produto, afinal, assim que saiu o incremento, vc pode botar a mão na massa pra ver se ficou como vc queria.
Creio que o erro da (D) é afirmar que o pair programming garante a refatoração contínua. Apesar de a refatoração contínua estar presente no XP (é um princípio, né?), não vejo relação com a programação em pares, muito menos uma relação tão estreita quanto afirmado.
-
Alternativa correta: B.
O erro da d) é falar que a programação em pares garante a refatoração contínua, quando na verdada essa prática visa a qualidade do código.
-
b-
O Scrum é orientado a iterações -Sprints. As entradas de sprints sao uma vez por mês. Os requisitos e funcionalidades ficam no Product Backlog. Ao iniciar Sprint, é realizada uma reunião de planejamento- o Product Owner dita funcionalidades a serem implementadas e à equipe as atividades. As funcionalidades do Sprint vao do Product Backlog para o Sprint Backlog.
-
Não sei. O problema pra mim é que a questão diz que o burndown é um artefato. Pelo guia scrum ele é citado apenas como uma prática de estimativa e não como um artefato.
-
Burndown é uma técnica ou ferramenta. Não é um artefato.
-
O Gráfico de Release Burndown não é parte do framework Scrum, mas pode
ser útil quando se usa um Plano de Release, geralmente estabelecido em uma
reunião de Release Planning.
Fonte: Rafael Sabbagh - Livro Gestão Agil para projetos de sucesso.
Acho que a resposta certa seria letra D
Mesmo que algumas atividades não sejam realizadas em pares
o tempo inteiro, utilize sempre a revisão em dupla. O modo
mais eficiente é o de rever o código dessa forma antes de
enviá-lo para o branch padrão. Isso resulta um código
totalmente revisado que será integrado no seu servidor.
Reexaminar depois pode perder a prioridade e gerar
retrabalho. Aproveite também para usar a revisão não apenas
no código, mas também em tudo o que é útil para o
desenvolvimento.
Fonte: Extreming Pro.. praticas do dia a dia
-
a) E. Não existe esse método ágil.
b) C
c) E. Não existe esse método ágil.
d) E. Embora o XP realmente use a programação em pares, ela visa a qualidade de código.
e) E. Não existe esse método ágil.
-
O DSDM exsiste.
-
Existe todos os métodos ágeis citados.
A) o erro é que foram inclusos 6 novos princípios, que difere o XP do IXP.
C) Existe sim o AUP, porém a definição dessa alternativa foi parar na alternativa E.
D) Definição errada da refatoração fez a questão ficar errada.
E) Existe também, a definição está trocada com a letra C.
Todas as metodologias que o amigo Roger Sampaio falou que não existe estão expressas no livro de Pressman 8 edição no capítulo 5.
Abraço.
-
refactoração contínua? daí nunca faz entrega? :)
eu tava entre B e D, por isso D caiu fora
-
Parece que o examinador fez umas opções confusas de propósito
-
Segundo o The Scrum Guide, o framework Scrum possui apenas 3 artefatos oficiais: Product Backlog, Sprint Backlog e o Incremento