Data de Publicação

12/09/2026

Data de Modificação

30/08/2026

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: Escopo e Cronograma). O prazo final geral (Milestone) é 07/09/2026.

Questão 1: Escopo do Produto vs. Escopo do Projeto (Conexão com o seu Grupo)

Due Date: 2026-09-07

Texto da Issue

Um erro frequente de desenvolvedores iniciantes é acreditar que o escopo de um projeto se resume à lista de funcionalidades do software (ex: “fazer login”, “gerar relatório”, “conectar à API da IA”).

  1. Explique a diferença fundamental entre Escopo do Produto e Escopo do Projeto segundo as boas práticas de Engenharia de Software.
  2. O seu caso real no grupo: Olhe para o trabalho do seu time no Projeto Integrador. Cite 1 exemplo de Escopo do Produto que seu grupo planeja entregar e 2 exemplos de Escopo do Projeto (atividades técnicas ou de gestão necessárias, como reuniões de alinhamento, configuração de ambiente/Docker, testes manuais ou escrita de documentação) que consumiram tempo da equipe mas que o usuário final não vê diretamente como uma “tela/função”.

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo! Respostas puramente conceituais sem os exemplos práticos do seu grupo não atingirão a nota máxima.)

Gabarito / Rubrica de Correção

  • Excelente (10): Diferencia com clareza: Escopo do Produto são os recursos e funções do software final; Escopo do Projeto é todo o trabalho e esforço gerencial/técnico para construí-lo (Regra dos 100% da EAP). Cita com precisão 1 exemplo autêntico de produto e 2 exemplos reais de projeto vivenciados no seu time.
  • Bom (7): Define bem a teoria, mas os exemplos do grupo são genéricos, superficiais ou omite um dos exemplos solicitados.
  • Insuficiente (0): Confunde os conceitos, traz respostas genéricas de IA sem conexão com o projeto prático ou não apresenta exemplos.

Questão 2: Os Dois Vilões do Escopo (Scope Creep vs. Gold Plating na Vida Real)

Due Date: 2026-09-07

Texto da Issue

No ciclo de vida de um software, o cronograma é constantemente ameaçado por distorções de escopo que vêm de fora (cliente) ou de dentro (equipe):

  1. Diferencie Scope Creep (Corrupção de Escopo) de Gold Plating (Folheamento a Ouro), explicando por que ambos são prejudiciais aos prazos e custos do projeto.
  2. A sua experiência real: Conte uma situação real (no seu trabalho, estágio, projeto pessoal ou acadêmico) em que você viveu um desses dois casos:
    • Uma situação em que sofreu com Scope Creep (“o cliente/chefe/professor pediu só mais um detalhezinho informal”); OU
    • Uma situação em que você (ou um colega) cometeu Gold Plating (“vou gastar horas colocando essa biblioteca/efeito/refatoração que ninguém pediu”).
      O que aconteceu com o tempo gasto e com o prazo final acordado?

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo! Respostas puramente conceituais sem relato de experiência receberão desconto na rubrica.)

Gabarito / Rubrica de Correção

  • Excelente (10): Conceitua perfeitamente Scope Creep (pressão externa não controlada) e Gold Plating (iniciativa interna não solicitada), destacando os impactos negativos em custo, prazo e riscos. Relata uma situação real autêntica e detalhada (trabalho, estágio ou estudos), explicando o impacto que o desvio causou no cronograma.
  • Bom (7): Conceitua corretamente ambos, mas traz um exemplo raso, genérico ou pouco contextualizado.
  • Insuficiente (0): Troca os conceitos, defende o Gold Plating como algo sempre positivo ou não apresenta nenhum exemplo real.

Questão 3: O Cone da Incerteza (O dia em que o “rapidinho” demorou 3 dias)

Due Date: 2026-09-07

Texto da Issue

Steve McConnell demonstra que, no início de um projeto, as estimativas oscilam entre \(0{,}25\times\) e \(4\times\) em relação ao tempo real devido ao Cone da Incerteza.

  1. Por que cravar horas exatas no início do desenvolvimento é uma ilusão e como as abordagens do PERT (probabilística com 3 pontos) e dos Story Points (estimativa relativa ágil) tentam lidar com essa incerteza?
  2. O seu caso real de estimativa: Descreva uma tarefa recente sua (no projeto da disciplina, estágio ou trabalho) que você achou que seria “rapidinho” (ex: 30 minutos a 1 hora), mas acabou levando dias para ser concluída. Quais incógnitas técnicas (ex: erro de versão, biblioteca descontinuada, falha de documentação, erro de ambiente, CORS, autenticação) estavam escondidas no seu Cone da Incerteza que você não havia previsto?

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo! Respostas puramente teóricas sem o relato da sua experiência técnica não receberão nota máxima.)

Gabarito / Rubrica de Correção

  • Excelente (10): Explica com propriedade o Cone da Incerteza e contrasta o PERT (\(Te = \frac{O + 4M + P}{6}\), focado em cenários de risco em horas) com os Story Points (focado em complexidade/risco relativo calibrado pela velocidade da equipe). Descreve um caso real detalhado de tarefa subestimada, apontando as variáveis e armadilhas técnicas ocultas que inflaram o tempo.
  • Bom (7): Explica a teoria, mas descreve uma situação vaga ou não aprofunda nas variáveis técnicas que causaram a incerteza.
  • Insuficiente (0): Não compreende o Cone da Incerteza, confunde PERT e Story Points ou não apresenta relato prático.

Questão 4: Esforço vs. Duração e a Sua Rotina Real

Due Date: 2026-09-07

Texto da Issue

Uma tarefa crítica do projeto exige 40 horas de esforço humano bruto. Se um desenvolvedor estagiário só consegue dedicar 10 horas por semana, a duração no calendário será de 4 semanas.

  1. Explique a diferença entre Esforço e Duração. O que significa dizer que uma tarefa no Caminho Crítico (CPM) tem folga zero e o que ocorre se ela atrasar 1 semana?
  2. A sua realidade: Considerando sua rotina semanal (faculdade, trabalho/estágio, locomoção e vida pessoal), quantas horas de esforço líquido você realisticamente consegue dedicar por semana a este Projeto Integrador? Se você pegar uma tarefa crítica de 8 horas de esforço faltando apenas 1 dia para o encerramento da Sprint, por que a relação entre esforço e duração tornará a entrega quase impossível sem sacrificar a qualidade ou o sono?

(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): Distingue formalmente Esforço (tempo de trabalho direto) de Duração (tempo decorrido no calendário com base na alocação). Explica que folga zero no Caminho Crítico transfere integralmente qualquer atraso para a data final do projeto. Faz uma análise realista da sua própria capacidade semanal de esforço e demonstra matematicamente por que 8h de esforço não cabem em 1 dia de calendário na sua rotina sem falha ou sobrecarga.
  • Bom (7): Acerta a teoria de esforço vs. duração e caminho crítico, mas faz uma reflexão superficial sobre a própria rotina.
  • Insuficiente (0): Confunde esforço com duração ou não compreende o impacto de tarefas no caminho crítico.

Questão 5: A EAP e Dependências no GitLab do seu Time

Due Date: 2026-09-07

Texto da Issue

No gerenciamento moderno no GitLab, transformamos a EAP em Issues (Pacotes de Trabalho) e Checklists/Tasks (Atividades), usando comandos como /estimate ou campos de Weight para quantificar o esforço.

  1. Como o relacionamento de dependência (“bloqueia / é bloqueada por”) no GitLab reflete na prática o conceito de Caminho Crítico?
  2. Aplicação no seu Repositório: Abra o GitLab do seu grupo e cite uma dependência real entre tarefas: uma Issue sua que depende do término da issue de um colega (ou vice-versa). Se o seu colega atrasar a entrega da tarefa dele no Caminho Crítico, qual é o impacto direto no seu trabalho e qual deve ser a postura pró-ativa do time para evitar o atraso do Milestone?

(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): Conecta a teoria da EAP/CPM às funcionalidades do GitLab (Issues, Checklists, /estimate/Weight e dependências bloqueantes). Identifica uma relação real de dependência/bloqueio no repositório do seu grupo e descreve ações ágeis concretas de contingência (comunicação imediata, pareamento, replanejamento de escopo ou readequação do Milestone) caso a dependência atrase.
  • Bom (7): Explica as funções do GitLab, mas dá um exemplo hipotético ou não detalha a postura prática da equipe perante bloqueios.
  • Insuficiente (0): Não entende a relação de dependências no GitLab ou sugere atitudes passivas (ex: “apenas esperar e culpar o colega”).
De volta ao topo