-
Acredito que o erro da alternativa (C) é afirmar que o Kanban é utilizado para "planejamento de quais histórias serão implementadas em cada Sprint". Entendo que desta forma o Kanban seria uma técnica utilizada na Sprint Planning, que não é o caso.
Kanban é um método para observar mudanças, visualizando o progresso, e limitando a quantidade de trabalho sendo feito ao mesmo tempo (Work In Progress). O planejamento de quais histórias serão feitas deve ocorrer antes de formar o Kanban.
PS: Quase marquei (D), pois nunca vi o Poker sendo usado para priorizar histórias, mas tão somente estimar esforço necessário. Alguém pode comentar se isso é comum? Ou alguma fonte...
PS2: Conferi no site da banca, e por enquanto é só Gabarito Preliminar. Creio em uma anulação.
-
Tenho o seguinte em meus resumos, só não lembro a fonte, deve ser de outra questão:
Pontos de histórias ou histórias dos usuários é uma unidade de medida que analisa o esforço necessário para realizar uma funcionalidade (não o tempo necessário). Uma técnica para estimar Story points é o planning poker, utilizado tanto para estimar esforço quanto para estimar tamanho, ajudando a definir o Sprint backlog.
No caso o priorizar, seria a parte de estimar os pontos de história e ajudar a definir o Sprint backlog.
-
Entendo Matheus. A dúvida realmente é quanto à linha entre "priorizar" e "estimar". Ao meu ver são duas coisas diferentes: uma tarefa pode custar 21 pontos e ser mais prioritária que uma tarefa de 1 ponto, e vice-versa.
A única coisa que posso imaginar é que o custo (estimado) pode auxiliar na priorização. Se vc tem duas tarefas de mesma urgência (=prioridade), pode optar por começar pela que tenha custo mais baixo, visando entregar algum resultado mais rapidamente.
Ainda assim, dizer que o poker é usado para priorizar as tarefas, acho forte.. Tanto pensando em literatura quanto pensando em uso prático. Principalmente no Scrum, onde é bem 'delimitado' que quem prioriza é o PO.
-
O erro da assertiva C é mencionar o Product Backlog quando deveria ser o Sprint Backlog.
-
O backlog do produto é onde fica tudo que vai ser desenvolvimento e o backlog da sprint é onde é fatiado.
Ao mensurar as colunas adicionais para fatiar os requisitos do sprint é um erro gigante, as colunas adicionais são em outras palavras, fases ou estados que os requisitos passam durante seu ciclo de desenvolvimento: To-do, Doing, Test, On-hold e Done, é um quadro padrão simplista do Scrum.
-
A Alternativa C trocou sprint backlog por product backlog, vejamos a diferença de ambos:
o Sprint Backlog é um subconjunto do Backlog do Produto;
o Product Backlog se refere ao produto completo, pronto. Já o Sprint Backlog diz respeito ao período que foi determinado;
o Backlog do Produto pode ser revisado semanalmente, enquanto o Backlog Sprint precisa ser revisado diariamente;
o Sprint Backlog usa horas para estimar tarefas em vez de pontos de história;
o proprietário do produto mantém o mesmo Product Backlog para todo o projeto, enquanto a equipe de desenvolvimento cria um novo Sprint Backlog para cada novo Sprint.