Questionário e Gabarito - Aula 4: Escopo e Cronograma (2026-2)
Este documento contém as questões que devem ser enviadas aos alunos via GitLab Issues para o Sprint 4 (Aula 4). O prazo final geral (Milestone) é 16/09/2026.
Questão 1: O Perigo Oculto (Funcionais vs. Não Funcionais)
Due Date: 2026-09-16
Texto da Issue
Muitas vezes, a equipe comemora porque todas as “telas estão prontas” e o sistema “funciona”, mas no dia do lançamento o servidor cai ou a página demora 10 segundos para carregar. Explique a diferença entre Requisitos Funcionais e Não Funcionais e discuta por que negligenciar os Não Funcionais pode levar ao fracasso do projeto, mesmo quando todas as funcionalidades foram implementadas.
(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo!)
Gabarito / Rubrica de Correção
- Excelente (10): Define claramente Funcionais (o que o sistema faz, ex: login) e Não Funcionais (como o sistema se comporta, ex: segurança, performance). Aponta que a ausência de não funcionais resulta em produtos não escaláveis, lentos e não confiáveis, arruinando a experiência do usuário.
- Bom (7): Entende a diferença básica, mas não aprofunda no impacto de negligenciar requisitos não funcionais.
- Insuficiente (0): Confunde os conceitos ou acha que requisitos não funcionais são puramente cosméticos (“deixar bonito”).
Questão 2: A Regra dos 100% e o Gold Plating
Due Date: 2026-09-16
Texto da Issue
Na Estrutura Analítica do Projeto (EAP), temos a “Regra dos 100%”: se não está na EAP, não faz parte do escopo. Muitos desenvolvedores adoram fazer o chamado “Gold Plating” (adicionar features extras que não foram pedidas para agradar o cliente). Por que isso é perigoso para o cronograma e para a qualidade final do projeto?
Gabarito / Rubrica de Correção
- Excelente (10): Explica que adicionar extras não solicitados consome tempo não planejado do cronograma, adiciona complexidade desnecessária e pode introduzir bugs. Afirma que o foco deve ser entregar os 100% acordados.
- Bom (7): Entende que atrasa o projeto, mas não menciona a Regra dos 100% e o impacto direto no risco do projeto.
- Insuficiente (0): Acha que “Gold Plating” é sempre algo bom e que o desenvolvedor sempre deve tentar entregar mais do que foi pedido a qualquer custo.
Questão 3: O Mito do Chute Rápido (Bottom-up vs Analogia)
Due Date: 2026-09-16
Texto da Issue
Ao planejar a próxima Sprint, você pode estimar tarefas “de cabeça” comparando com outros projetos (Estimativa por Analogia) ou quebrar as tarefas em pedaços menores e estimar um a um (Estimativa Bottom-up). Embora a estimativa Bottom-up seja muito mais demorada de fazer, por que ela é fundamental para projetos de software complexos, em vez de apenas estimar por analogia?
Gabarito / Rubrica de Correção
- Excelente (10): Explica que Bottom-up é mais preciso pois exige pensar na solução técnica (quebrando em pacotes de trabalho reais), o que minimiza o risco de surpresas. Analogia é rápida, mas falha em software onde o contexto dita a complexidade de cada linha de código.
- Bom (7): Cita que é mais preciso, mas não explica que quebrar a tarefa ajuda a mitigar o risco técnico e as incógnitas de desenvolvimento.
- Insuficiente (0): Responde que Bottom-up é pior porque perde muito tempo e desenvolvedor não deve estimar.
Questão 4: Rastreabilidade no GitLab
Due Date: 2026-09-16
Texto da Issue
No seu projeto Portfólio, como o uso conjunto de Milestones (como as Sprints), Due Dates (datas de entrega) e Labels permite ao Scrum Master saber visualmente e rapidamente se a Sprint vai atrasar? Dê um exemplo de como a falta dessas configurações torna o Kanban um quadro inútil.
Gabarito / Rubrica de Correção
- Excelente (10): Aponta que o Milestone fecha o escopo temporal e as Due dates monitoram o andamento interno de cada issue. Se as configurações faltam, o board vira apenas um depósito de posts genéricos, onde ninguém sabe o que tem prazo para esta semana ou para daqui a um mês.
- Bom (7): Fala que organiza o projeto, mas não conecta com a identificação rápida de atrasos.
- Insuficiente (0): Não entende a função do Milestone e confunde os termos.
Questão 5: A “Mudançazinha” Rápida
Due Date: 2026-09-16
Texto da Issue
O cliente (ou professor) liga na sexta-feira pedindo: “Queria só mudar a cor da barra de menus e colocar um ícone novo. É coisa rápida, 5 minutinhos”. Por que você deve submeter esse pedido a uma análise de impacto em vez de simplesmente aceitar e “codar rapidinho”? Como isso protege sua EAP?
Gabarito / Rubrica de Correção
- Excelente (10): Explica que toda mudança altera escopo. O que parece “5 minutos” para o cliente pode quebrar layout responsivo, necessitar de novos testes e desalinhar o cronograma (Scope Creep). Passar por análise protege a equipe de desgastes e o projeto de instabilidade.
- Bom (7): Entende que pode quebrar o código, mas não relaciona com os processos de mudança de escopo.
- Insuficiente (0): Afirma que deve aceitar a mudança logo e fazer para não chatear o cliente.