Gabarito Positivo e Negativo - Prova Teórica 2

Gestão de Projetos de Software - 18/12/2025

Valor total: 25 pontos

Questões: 1 a 5 (conteúdos 7 a 12)

Questão 1 (5 pontos)

Defina o conceito e indique quando faz sentido combinar controles preditivos com práticas ágeis. Dê um exemplo do projeto da equipe onde um artefato preditivo ajudaria e um exemplo onde uma prática ágil foi mais adequada.

✅ RESPOSTA POSITIVA (4–5 pontos)

  • Explica gestão híbrida como combinação intencional de práticas preditivas (planejamento mais estável, marcos) com práticas ágeis (sprints, inspeção e adaptação).
  • Cita exemplos de controles preditivos: cronograma/milestones, baseline de escopo, roadmap do semestre, datas de checkpoints.
  • Cita exemplos de práticas ágeis: Sprints, Daily, Review, Retrospectiva, Kanban/WIP, definição de pronto (DoD).
  • Dá um exemplo concreto do Portfólio onde um artefato preditivo ajudou/ajudaria (ex.: milestones de checkpoints, prazo fixo da disciplina).
  • Dá um exemplo concreto onde uma prática ágil foi mais adequada (ex.: usar Kanban para organizar issues, ajustar backlog a cada sprint).

❌ RESPOSTA NEGATIVA (0–2 pontos)

  • Trata gestão híbrida apenas como “misturar coisas” sem explicar o porquê.
  • Não diferencia exemplos preditivos de exemplos ágeis ou confunde os dois.
  • Não traz exemplos do projeto, ou usa exemplos genéricos demais.
  • Foca só em um lado (só preditivo ou só ágil) sem discutir combinação.

Questão 2 (6 pontos)

a) Em termos conceituais, explique os benefícios diretos de CI/CD para a gestão de projetos/gestão ágil.
b) No contexto do Portfólio, cite três checagens automatizadas adequadas, explicando ganho e posição no pipeline.

✅ RESPOSTA POSITIVA (5–6 pontos)

  • Parte teórica (CI/CD): explica CI como integrar código com frequência, detectar erros cedo, reduzir conflitos; explica CD como facilitar deploys frequentes, reduzir risco de grandes entregas, melhorar feedback de usuários.
  • Relaciona explicitamente com gestão ágil: mais previsibilidade, visibilidade (pipelines), apoio a sprints curtos, menos “surpresas” perto de marcos.
  • Parte prática (checagens): apresenta pelo menos três checagens coerentes com o projeto (ex.: build do Hugo sem erro, verificação de links, lint de Markdown/HTML, verificação básica de acessibilidade).
  • Para cada checagem, explica o benefício (ex.: evitar site quebrado, evitar links 404 na apresentação, manter código organizado) e indica onde entra no pipeline (antes do build, durante o build, antes do deploy).

❌ RESPOSTA NEGATIVA (0–3 pontos)

  • Parte conceitual muito vaga (“CI/CD é automatizar coisas”) sem conectar com feedback, risco, previsibilidade ou qualidade.
  • Não diferencia CI de CD ou troca os conceitos.
  • Na parte prática, cita poucas checagens, irrelevantes para o projeto ou sem explicar ganho.
  • Não indica onde as checagens entrariam no pipeline, ou responde só “testar o código” sem detalhar.

Questão 3 (4 pontos)

Em palavras simples, explique o significado de lead time, cycle time, WIP e throughput. Diga que atitude tomaria se perceber tarefas paradas há tempo demais.

✅ RESPOSTA POSITIVA (3–4 pontos)

  • Define lead time como tempo desde que a tarefa entra na fila até ser entregue.
  • Define cycle time como tempo desde que a tarefa entra em “em andamento” até concluir.
  • Define WIP como quantidade de tarefas em andamento simultaneamente.
  • Define throughput como quantidade de tarefas/entregas concluídas em um período.
  • Propõe atitudes concretas quando tarefas ficam paradas: reduzir WIP, dividir tarefas grandes, remover bloqueios, revisar prioridades, conversar na daily.

❌ RESPOSTA NEGATIVA (0–1 ponto)

  • Confunde totalmente os termos ou usa explicações circulares (“lead time é o tempo de lead”).
  • Não menciona relação com fluxo de trabalho (quadros, colunas, filas).
  • Não sugere nenhuma ação prática frente a tarefas travadas.
  • Respostas muito curtas ou só copiando palavras sem explicar.

Questão 4 (4 pontos)

Diferencie risco de impedimento. Liste dois riscos do projeto, classifique (probabilidade/impacto), escolha a estratégia de resposta e cite um gatilho/indicador para cada.

✅ RESPOSTA POSITIVA (3–4 pontos)

  • Diferencia bem risco (evento futuro incerto) de impedimento (problema já presente que bloqueia o trabalho).
  • Apresenta 2 riscos reais do projeto (ex.: membro chave sair, atraso em conteúdo, falha no deploy, falta de tempo).
  • Classifica cada risco com probabilidade e impacto (baixo/médio/alto) de forma coerente.
  • Escolhe estratégia de resposta adequada (evitar, mitigar, transferir, aceitar) e dá uma ação concreta.
  • Define um gatilho/indicador para cada risco (ex.: X dias sem commit, pipeline falhando mais de N vezes, ausência em reuniões).

❌ RESPOSTA NEGATIVA (0–1 ponto)

  • Confunde risco e impedimento (trata tudo como se já estivesse acontecendo).
  • Riscos muito genéricos (“o projeto pode dar errado”) ou sem relação com o contexto.
  • Não classifica probabilidade/impacto ou faz classificações incoerentes.
  • Não indica estratégia de resposta nem gatilhos claros.

Questão 5 (6 pontos)

Relacione as ferramentas do GitLab (Milestones, Releases, Issues) com os conceitos de metodologia ágil, usando exemplos do projeto.

✅ RESPOSTA POSITIVA (3–4 pontos)

  • Milestones: liga com Sprints ou marcos maiores (ex.: Checkpoints, versão 1.0 do site), usando datas e escopo claro.
  • Releases: conecta com increments entregáveis (ex.: primeira versão pública do site, release de conteúdo completo) e ideia de entrega contínua.
  • Issues: associa a User Stories/tarefas de backlog, com descrição, critérios de aceitação, labels e vínculo com milestones.
  • Usa exemplos reais ou plausíveis do projeto (nomenclatura de milestones, exemplos de issues criadas, como fariam uma release no GitLab).
  • Mostra entendimento de que as ferramentas dão suporte às práticas ágeis (planejamento, transparência, inspeção/adaptação).

❌ RESPOSTA NEGATIVA (0–1 ponto)

  • Descreve Milestones/Releases/Issues apenas como “funcionalidades da ferramenta” sem conectar com conceitos ágeis.
  • Não usa exemplos do projeto ou usa descrições muito vagas.
  • Confunde o papel das ferramentas (ex.: tratar Release como Issue, ou Milestone como rótulo qualquer).
  • Não mostra relação com Sprints, backlog, incrementos ou roadmap.