-
O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner.
O Product Backlog não precisa estar completo no início de um projeto.
Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento.
Com o tempo, o Product Backlog cresce e muda à medida que se aprende
mais sobre o produto e seus usuários.
Fonte: http://www.desenvolvimentoagil.com.br/scrum/product_backlog
Observem que as funcionalidades são em alto nível, sem ter muitos aspectos técnicos envolvidos. Além disso, elas devem estar alinhadas ao produto, ou seja, ao negócio.
O aspecto técnico é trabalhado no Sprint Backlog, conforme visto:
O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades.
Fonte: http://www.desenvolvimentoagil.com.br/scrum/sprint_backlog
A estória inicial (Product Backlog) pode ser decomposta em várias outras de aspectos mais técnicos (Sprint Backlog).
Espero ter ajudado. Bons estudos!
-
@Silas Júnior: então você acha que a questão está errada? Pelo comentário as histórias do Sprint Backlog, que é do que a questão trata, são mais técnicas que a do Product Backlog.
-
@flashfs '
Pra mim a questão está errada, pois no backlog da Sprint (solicitado no enunciado), temos as tarefas técnicas para atender o que foi solicitado. A correta, no meu ver, seria a letra A.
-
Letra D é a correta
Estórias de usuário nada mais é do que uma metáfora em que clientes, programadores e gerentes podem contar sobre como o sistema funciona para refinamento de requisitos, buscando entender o negócio. Neste momento não é relevante abordar aspectos técnicos do sistema tipo "ah vamos utilizar aqui a linguagem JAVA para implementar essa classe, usar o DAO e o SGBD Oracle" me diz uma coisa, o cliente quer saber disso? Isso é importante na hora de entender as funcionalidades? Não, não é, queremos apenas saber como o sistema funciona para poder mapear as funcionalidades que farão parte de um product backlog. Uma vez entendido como funciona, são definida funcionalidades de modo prioritário em uma lista de backlog, aí sim você vai partir para a solução em uma Sprint Backlog onde você, após ter selecionando as funcionalidades na reunião de planejamento, vai definir as atividades ou lista de tarefas que a equipe de desenvolvimento irá realizar para, de fato, desenvolver o produto, aí sim você vai ter definido aspectos técnicos e soluçaõ proposta ja com tecnlogia envolvida. Dessa forma eliminamos A e C. As demais alternativas em "desenhar um workflow" e "focar em componentes existente" não é importante na etapa de estórias do usuário.
-
Silas seu comentário é legal mas vai confundir as pessoas.
A questão está claramente errada. Quem define o Sprint backlog é o time de desenvolvimento. Eles decidem baseado na complexidade que cabe na Sprint e o que irá entregar mais valor para o cliente. Essa complexidade pode ser medida usando Planning Poker.
Portanto, para definir a complexidade de uma estória, o time de desenvolvimento deve usar argumentos técnicos e arquiteturais, em muitos casos até mesmo detalhando o desenvolvimento ou propondo soluções
A resposta dessa questão era pra ser letra A ou C
o examinador fumou um nessa prova ou queria passar o filho dele
-
NÃO PODERIA CONCORDAR MAIS COM O MR. ROBOT!!!!!
-
Primeiro foi a questão sobre a reunião do Scrum definir o local das reuniões diárias e agora foi essa. Numa boa, vou pular as questões da cespe pq só atrapalham o estudo.
-
Pra mim a definição de User Stories que li se encaixa muito bem com a D. Também fala sobre diferenças entre user story e casos de uso.
"User Stories fracionam os requisitos para que seja possível (e mais fácil) estimar o esforço para realizar aquele objetivo. Resumindo, User Stories são descrições simples que descrevem uma funcionalidade e é recomendável que sejam escritas segundo o ponto de vista do usuário.
User Stories devem ser curtas, simples e claras. Devemos conseguir escrevê-las em um simples e pequeno cartão (conhecidos como User Index Cards). Se não há espaço para escrevê-la em um cartão é porquê devemos refiná-la mais, e as dividir em outras User Stories."
http://blog.myscrumhalf.com/2011/10/user-stories-o-que-sao-como-usar/
-
Seria a C, histórias ficam no backlog de produto. backlog de sprint tem itens técnicos.