Elaborar o Product Backlog para um Jogo Digital Educativo. Dizer qual é o Jogo Digital Educativo proposto.
(2 pontos)
(2 pontos)
Passo 1
Aqui eu deixo bem claro o que o exercício pede: você quer que eu elabore um Product Backlog para um Jogo Digital Educativo e que eu diga qual é o Jogo Digital Educativo proposto. As informações relevantes que o enunciado dá são apenas essas — criar o backlog e nomear o jogo. Não há restrições extra sobre plataforma, público-alvo ou conteúdo (vou assumir que o público é estudantes de exatas em nível básico/ensino médio / início de graduação, já que você estuda exatas). A resolução começa agora.
Passo 2
O que é um Product Backlog (explicação didática, passo a passo):
- O Product Backlog é uma lista priorizada de tudo que o produto precisa ter: funcionalidades, correções, requisitos técnicos, melhorias, conteúdo educativo, etc.
- Cada item do backlog costuma ser escrito como uma user story (história de usuário): “Como <tipo de usuário>, eu quero <ação> para <benefício>”. Isso ajuda a focar no valor.
- Cada item deve ter critérios de aceitação (o que precisa acontecer para considerar o item pronto), prioridade e uma estimativa (por exemplo, story points) para planejamento.
- O backlog é vivo: itens podem ser quebrados, re-priorizados e estimados ao longo do tempo.
Passo 3
Como escrever uma user story (aula rápida e prática):
- Estrutura simples: “Como <usuário>, eu quero <ação> para <benefício>.”
- Exemplo concreto: “Como estudante, eu quero um tutorial interativo para aprender a regra de três, para conseguir resolver exercícios sozinho.”
- Critérios de aceitação (usar formato Given / When / Then ajuda):
- Given (dado que) — contexto inicial;
- When (quando) — ação;
- Then (então) — resultado esperado.
- Estimativa: usar uma escala simples tipo Fibonacci (
) para indicar esforço/complexidade.
Passo 4
Como priorizar itens do backlog (métodos simples e rápidos que você pode usar na prova):
- MoSCoW: Must have, Should have, Could have, Won’t have. É direto e fácil de justificar em prova.
- Valor × Esforço: priorize itens com alto valor e baixo esforço (fácil de mostrar com uma tabela 2×2).
- Para uma resposta de prova, diga claramente qual método de priorização usou (aqui usarei MoSCoW para clareza).
Passo 5
Como dividir épicos em histórias menores (dica prática para tempo de prova):
- Se um item for grande demais, quebre em entregáveis que possam ser feitos em uma iteração (sprint).
- Indicadores de que precisa quebrar: estimativa >
story points, ou muitos critérios de aceitação distintos. - Demonstre um exemplo rápido: “Sistema de níveis” (épico) → “Mecânica de XP”, “Tela de progresso”, “Recompensas por completar lição” (histórias menores).
Passo 6
Definir o MVP (Produto Mínimo Viável) — como escolher o que entregar primeiro:
- MVP = menor conjunto de funcionalidades que entrega valor educativo significativo.
- Regras práticas: incluir núcleo do jogo (mecânica que ensina/pratica o conteúdo), conteúdo inicial (algumas lições/níveis), tutorial, sistema de avaliação simples (correção e feedback).
- Em prova, identifique os itens marcados como “Must have” no backlog como o MVP.
Passo 7
Apresentação do Jogo Digital Educativo proposto (nome e ideia curta — isso responde a parte pedida pelo enunciado):
- Nome proposto: MathQuest — Aventura dos Conceitos.
- Ideia curta: jogo de aventura por fases em que o jogador resolve desafios matemáticos (álgebra, lógica e raciocínio) para avançar no mapa. Cada fase foca num conceito, com feedback imediato, dicas adaptativas e mini-jogos para fixação.
Passo 8
Estrutura lógica do Product Backlog que vou entregar (como organizei os itens):
- Cada item terá: ID curto, título, user story, critérios de aceitação (Given/When/Then), prioridade (MoSCoW), estimativa (story points:
), dependências curtas. - Vou priorizar e marcar o que entra no MVP (Must have).
Passo 9
Observações práticas para a prova — como justificar cada item rapidamente:
- Diga o valor educativo (por exemplo: “ensina regra de três”, “fixa conceitos de função”).
- Diga a prioridade com base em MVP/engajamento/viabilidade.
- Use estimativas pequenas para itens de interface e maiores para sistemas (bastante defensável em prova).
Passo 10
Product Backlog — explicação de leitura rápida (como usar em uma apresentação de 2 minutos na prova):
- Mostre os itens Must have primeiro (MVP).
- Aponte um ou dois Should have que aumentam retenção.
- Liste Could have e Won’t have para mostrar visão futura.
- Termine com dependências e nota sobre testes/qualidade.
Passo 11
Abaixo está o Product Backlog finalizado e pronto para entregar. Itens estão organizados por prioridade MoSCoW e cada item tem user story, critérios de aceitação e estimativa. Use isto como resposta final na sua prova — é direto, justificável e mostra entendimento do processo.
Resposta
Jogo proposto: MathQuest — Aventura dos Conceitos
Product Backlog (itens principais, prioridade MoSCoW, estimativa em story points):
-
PB-01 — Tutorial interativo inicial (Must have) — User story: Como novo jogador, eu quero um tutorial passo a passo para entender controles e mecânica de resolução, para começar a jogar sem dúvida.
Critérios: Given jogador novo; When entra no jogo pela primeira vez; Then tutorial guia controles e resolve 1 problema exemplo com feedback.
Estimativa:SP. Dependência: nenhum. -
PB-02 — Núcleo de mecânica de resolução (Must have) — User story: Como jogador, eu quero a mecânica de responder questões (entrada de resposta, checagem e feedback), para praticar conceitos.
Critérios: Given pergunta exibida; When jogador submete resposta; Then sistema valida e mostra correção e explicação.
Estimativa:SP. Dependência: PB-01. -
PB-03 — Banco de questões por conceito (Must have) — User story: Como professor/jogador, eu quero um banco de questões categorizado (álgebra, lógica, funções), para gerar níveis coerentes.
Critérios: Given seleção de conceito; When criar nível; Then são selecionadasquestões válidas daquele conceito.
Estimativa:SP. Dependência: PB-02. -
PB-04 — Sistema de níveis e progressão (Must have) — User story: Como jogador, eu quero avançar por níveis com mapa, para sentir progresso e motivação.
Critérios: Given completou mini-desafios; When cumpre objetivos; Then desbloqueia próximo nível e registro de progresso.
Estimativa:SP. Dependência: PB-02, PB-03. -
PB-05 — Feedback e explicações educativas (Must have) — User story: Como estudante, eu quero receber explicações após erro, para aprender o porquê da resposta correta.
Critérios: Given resposta errada; When jogador vê feedback; Then aparece explicação passo a passo e uma dica para repetir.
Estimativa:SP. Dependência: PB-02, PB-03. -
PB-06 — Sistema de dicas adaptativas (Should have) — User story: Como jogador com dificuldade, eu quero dicas que se adaptam ao meu erro, para melhorar sem frustração.
Critérios: Given sequência de erros; When pedir dica; Then sistema oferece dica de nível 1/2/3.
Estimativa:SP. Dependência: PB-05. -
PB-07 — Pontuação, medalhas e gamificação (Should have) — User story: Como jogador, eu quero receber pontos e medalhas, para me motivar a repetir e melhorar.
Critérios: Given completar nível; When condições de score atendidas; Then conceder medalha e atualizar ranking local.
Estimativa:SP. Dependência: PB-04. -
PB-08 — Tela de perfil e histórico de desempenho (Should have) — User story: Como estudante, eu quero ver meu histórico de acertos/erros por conceito, para identificar pontos fracos.
Critérios: Given jogador com sessões; When abre perfil; Then mostra gráficos simples de acerto por tema.
Estimativa:SP. Dependência: PB-02, PB-03. -
PB-09 — Modo desafio cronometrado (Could have) — User story: Como jogador competitivo, eu quero desafios com tempo limitado, para treinar rapidez.
Critérios: Given modo ativado; When começar desafio; Then aplicar limite de tempo e pontuar por rapidez e acerto.
Estimativa:SP. Dependência: PB-02, PB-07. -
PB-10 — Ferramenta de criação de lições pelo professor (Should have) — User story: Como professor, eu quero criar/editar conjuntos de questões e sequências, para usar o jogo em aula.
Critérios: Given conta professor; When criar lição; Then salvar lição e permitir exportar link para estudantes.
Estimativa:SP. Dependência: PB-03, PB-08. -
PB-11 — Acessibilidade (contraste, leitores de tela, teclas) (Must have) — User story: Como jogador com necessidades especiais, eu quero opções de acessibilidade, para poder jogar e aprender.
Critérios: Given ativação de modo acessível; When navegar; Then UI atende contraste, navegação por teclado e rótulos para leitores de tela.
Estimativa:SP. Dependência: PB-01, PB-02. -
PB-12 — Localização básica (pt/en) (Could have) — User story: Como usuário de outra língua, eu quero interface em inglês, para entender conteúdos.
Critérios: Given idioma selecionado; When iniciar; Then todos os textos da UI e explicações aparecem no idioma escolhido.
Estimativa:SP. Dependência: PB-01, PB-05. -
PB-13 — Analytics para educadores (Should have) — User story: Como coordenador, eu quero relatórios agregados de desempenho, para avaliar eficácia pedagógica.
Critérios: Given dados coletados; When gerar relatório; Then mostrar métricas por turma/tema e exportar CSV.
Estimativa:SP. Dependência: PB-08, PB-10. -
PB-14 — Painel administrativo e deploy (Must have para entrega mínima) — User story: Como equipe, eu quero painel para gerir conteúdo e publicar atualizações, para manter o jogo em produção.
Critérios: Given conta admin; When subir conteúdo; Then conteúdo fica disponível para jogadores e há log de alterações.
Estimativa:SP. Dependência: PB-03, PB-10. -
PB-15 — Testes automatizados e QA (Must have) — User story: Como equipe de desenvolvimento, eu quero testes automáticos básicos, para garantir estabilidade nas entregas.
Critérios: Given pipeline CI; When rodar build; Then executar testes de unidade e integração com cobertura mínima.
Estimativa:SP. Dependência: todos os módulos principais.
MVP recomendado (itens Must have): PB-01, PB-02, PB-03, PB-04, PB-05, PB-11, PB-14, PB-15.
(Fim)