Questionário e Gabarito - Aula 1: Apresentação e Iniciação (2026-2)
Este documento contém as questões que devem ser enviadas aos alunos via GitLab Issues para o Sprint 1 (Aula 1). O prazo final geral (Milestone) é 19/08/2026. A Questão 1 tem prazo individual para 16/08/2026.
Questão 1: Projetos vs. Operações na Prática
Due Date: 2026-08-16
Texto da Issue
Bem-vindo à sua primeira Issue! Para começar, vamos conectar a teoria com a sua experiência: No seu estágio ou em projetos passados da faculdade, quais atividades eram claramente “projetos” (início, meio e fim) e quais eram puramente “operações” (manutenção e rotina contínua)? Dê exemplos e explique como você separa esses dois mundos.
(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): Dá exemplos claros da própria vivência. Entende perfeitamente que projetos criam algo novo e temporário, enquanto operações são contínuas e mantêm o negócio rodando.
- Bom (7): Entende a diferença teórica, mas os exemplos práticos são confusos ou ausentes.
- Insuficiente (0): Confunde os conceitos e não consegue diferenciar rotina de um projeto pontual.
Questão 2: O Triângulo de Ferro e a Pressão da Diretoria
Due Date: 2026-08-19
Texto da Issue
Imagine a seguinte situação no seu trabalho: A diretoria exige que você antecipe o lançamento de um novo software em 1 mês, mas afirma que não haverá aumento de orçamento para contratar mais desenvolvedores. O que você diz a eles? Explique como você negociaria o Escopo utilizando o conceito do Triângulo de Ferro.
Gabarito / Rubrica de Correção
- Excelente (10): Explica que diminuir o tempo sem aumentar custo exige obrigatoriamente a redução do escopo (cortar features). Argumenta de forma madura usando o Triângulo de Ferro.
- Bom (7): Entende que precisa cortar escopo, mas não cita ou aplica o modelo do Triângulo de Ferro corretamente.
- Insuficiente (0): Diz que a equipe vai trabalhar mais horas (hora extra sem custo) ou propõe diminuir a qualidade do código para entregar tudo.
Questão 3: O Preço Oculto da Baixa Qualidade
Due Date: 2026-08-19
Texto da Issue
Muitos times imaturos pensam: “Vamos fazer de qualquer jeito agora só pra entregar no prazo, depois a gente arruma”. Pense rápido e responda: Por que sacrificar a qualidade do código como “variável de ajuste” para cumprir um prazo é uma bomba-relógio para a sua equipe no mês seguinte?
Gabarito / Rubrica de Correção
- Excelente (10): Menciona o conceito de “dívida técnica”. Explica que código ruim gera manutenções insustentáveis, quedas em produção e travará o desenvolvimento de novas features no futuro.
- Bom (7): Responde superficialmente que vai dar mais trabalho para consertar bugs depois.
- Insuficiente (0): Concorda com a afirmação de que entregar rápido é melhor que entregar com qualidade.
Questão 4: Esconder Bugs vs. Transparência
Due Date: 2026-08-19
Texto da Issue
Na Engenharia de Software, a forma como lidamos com os erros dita o sucesso do projeto. Qual a principal diferença, na prática e nas consequências de longo prazo, entre esconder um bug debaixo do tapete para cumprir um prazo imediato e reportá-lo precocemente (transparência) em uma reunião de alinhamento da equipe?
Gabarito / Rubrica de Correção
- Excelente (10): Relata que bug escondido em produção pode causar catástrofes, vazamento de dados ou falência. E que reportar antes é apenas um risco mapeado que a gestão pode contornar. Demonstra maturidade profissional.
- Bom (7): Responde de forma rasa que mentir é errado e a equipe deve ser honesta.
- Insuficiente (0): Justifica que bugs irrelevantes podem ser escondidos.
Questão 5: Por que código bom não basta?
Due Date: 2026-08-19
Texto da Issue
Se projetos de software fossem solucionados apenas “escrevendo código bom e otimizado”, não precisaríamos de Gestão Ágil ou metodologias como o PMBOK. Liste e explique duas razões puramente humanas (ex: ego, falhas de comunicação, expectativas irreais) que tornam a adoção de processos formais de gestão indispensável na nossa área.
Gabarito / Rubrica de Correção
- Excelente (10): Cita duas razões humanas válidas (ex: quebra de comunicação entre dev e cliente, escopo mal compreendido, falta de alinhamento, ego do desenvolvedor solitário) e explica como a gestão resolve isso.
- Bom (7): Cita as razões, mas não explica como os processos (Scrum, Dailies, PMBOK) ajudam a mitigá-las.
- Insuficiente (0): Responde focando em limitações técnicas das máquinas ou não compreende o fator comportamental na engenharia.