Questionário e Gabarito - Aula 3: Planejamento no GitLab (2026-2)

Este documento contém as questões que devem ser enviadas aos alunos via GitLab Issues para o Sprint 3 (Aula 3). O prazo final geral (Milestone) é 09/09/2026. A Questão 1 tem prazo individual inicial.

Questão 1: A Bússola do Projeto (Project Charter)

Due Date: 2026-09-02

Texto da Issue

No mundo real, começar a programar sem um norte é garantia de retrabalho. Imagine que você foi alocado em um projeto onde não há Project Charter. Quais os maiores riscos que sua equipe corre ao longo das semanas de desenvolvimento por não ter formalizado os objetivos, escopo inicial e critérios de sucesso no início do projeto? Dê exemplos do que pode dar errado na comunicação com o “cliente” (ou professor).

(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): Aponta claramente que a falta de um Charter gera desalinhamento de expectativas, escopo mutante (scope creep) e dificuldade em provar que o projeto foi concluído com sucesso. Dá bons exemplos de falha de comunicação.
Bom (7): Entende a importância do documento, mas traz exemplos rasos ou muito teóricos.
Insuficiente (0): Acha que o Charter é apenas burocracia e que começar a programar direto é mais produtivo.

Questão 2: O Dilema dos Repositórios

Due Date: 2026-09-09

Texto da Issue

Para o nosso Projeto Integrador (Portfólio), optamos por um Monorepo (Repositório Único) no GitLab, ao invés de separar documentação, front-end e backend em repositórios diferentes (Polyrepo). Qual a principal vantagem dessa abordagem (Monorepo) para a nossa organização e como isso se relaciona com a rastreabilidade do que estamos entregando?

Gabarito / Rubrica de Correção

Excelente (10): Explica que o Monorepo centraliza o conhecimento, facilitando a rastreabilidade transversal (um único commit/MR resolve lógica, interface e testes). Menciona que é melhor para equipes enxutas por simplificar o CI/CD e a gestão.
Bom (7): Cita que fica “tudo no mesmo lugar” e é mais fácil de achar, mas não aborda a rastreabilidade de commits e gestão de CI/CD.
Insuficiente (0): Argumenta incorretamente que o Monorepo impede equipes de trabalharem juntas ou confunde com outros conceitos.

Questão 3: A Armadilha da Issue Épica e o WIP

Due Date: 2026-09-09

Texto da Issue

No seu Board Kanban do GitLab, você encontra uma Issue intitulada: “Fazer todo o backend do Portfólio”. Por que essa Issue é considerada um “Épico” e deve ser fatiada? Além disso, explique por que é um erro ter 10 issues na coluna “Doing” (Em Progresso) ao mesmo tempo para uma equipe de 3 pessoas, mencionando o conceito de limites de WIP.

Gabarito / Rubrica de Correção

Excelente (10): Explica que uma Issue tão grande é impossível de estimar, não tem critérios de aceitação claros e trava o fluxo. Também explica o WIP (Work In Progress), argumentando que muitas tarefas em progresso geram troca de contexto e impedem a finalização efetiva de valor.
Bom (7): Entende que a tarefa é muito grande e que muitas tarefas ao mesmo tempo geram confusão, mas não cita formalmente o WIP ou os impactos da troca de contexto.
Insuficiente (0): Acha que tarefas grandes são normais e que quanto mais coisas a equipe faz ao mesmo tempo, mais rápida ela é.

Questão 4: Escopo vs. Tempo (Issues e Milestones)

Due Date: 2026-09-09

Texto da Issue

Para o planejamento no GitLab, usamos dois artefatos principais: Issues e Milestones. Explique, de forma prática, qual a diferença entre eles no gerenciamento do projeto. Qual deles gerencia o Escopo e qual gerencia o Tempo?

Gabarito / Rubrica de Correção

Excelente (10): Define claramente que Issues fracionam e gerenciam o Escopo (o que será feito, as tarefas) e Milestones fracionam e gerenciam o Tempo (os Sprints, as metas de prazo).
Bom (7): Entende que Milestones têm prazo e Issues são tarefas, mas não faz a associação direta de Escopo e Tempo.
Insuficiente (0): Confunde os conceitos, dizendo que Milestones são tarefas gigantes e Issues são metas de tempo.

Questão 5: A Mágica do CI/CD

Due Date: 2026-09-09

Texto da Issue

Lembra da famosa frase “Na minha máquina funcionava!”? Explique como a configuração de um Pipeline de CI/CD (Integração e Entrega Contínuas) no GitLab ajuda a acabar com essa desculpa, garantindo que o código defeituoso não chegue ao servidor de produção.

Gabarito / Rubrica de Correção

Excelente (10): Explica que o CI (Integração Contínua) roda testes automatizados em um ambiente limpo (robô/runner) a cada commit. Se falhar, o código não é integrado (merge bloqueado), garantindo a qualidade antes do CD (Entrega/Deploy automático).
Bom (7): Explica que o CI/CD automatiza a publicação, mas não detalha como ele atua como uma barreira de qualidade contra código que “só funciona na máquina do dev”.
Insuficiente (0): Não entende o conceito, achando que CI/CD é apenas uma ferramenta de chat ou controle manual de versão.