Questionário e Gabarito - Aula 5: Qualidade e Recursos (2026-2)
Este documento contém as questões que devem ser enviadas aos alunos via GitLab Issues para o Sprint 5 (Aula 5). O prazo final geral (Milestone) é 23/09/2026.
Questão 1: Prevenir vs. Achar Defeitos
Due Date: 2026-09-23
Texto da Issue
Existe uma diferença gritante entre Garantia de Qualidade e Controle de Qualidade. No contexto de Engenharia de Software, explique por que é financeiramente e tecnicamente muito mais barato investir em prevenir defeitos (ex: Code Review, programação em pares, análise estática) do que focar todos os esforços apenas em achar defeitos no final (ex: equipe de testadores manuais no dia da entrega).
(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): Relaciona que a correção de um bug em produção é centenas de vezes mais cara que um erro barrado no código-fonte (Code Review). Demonstra o entendimento de que prevenir (Garantia) barra a dívida técnica precocemente.
- Bom (7): Entende que consertar depois dá mais trabalho, mas não utiliza a distinção clara entre Garantia e Controle.
- Insuficiente (0): Confunde os dois ou afirma que a responsabilidade da qualidade é 100% de quem testa o software depois de pronto.
Questão 2: O Conflito do Critério de Aceitação
Due Date: 2026-09-23
Texto da Issue
Imagine uma Issue: “Implementar página de contato”. O dev finaliza o formulário e coloca a issue em “Done”. O Product Owner testa, vê que os dados não estão chegando no e-mail, devolve para “To Do” e gera uma briga. Como a falta de Critérios de Aceitação na Issue causou esse conflito e como isso deveria ser resolvido antes do dev escrever a primeira linha de código?
Gabarito / Rubrica de Correção
- Excelente (10): Explica que a ausência de um “Definition of Done” / critérios mensuráveis causa percepções subjetivas de escopo. Deveria ter sido escrito, por exemplo: “Critério de aceitação: enviar e-mail via API e exibir tela de sucesso”, alinhando expectativas antes do início.
- Bom (7): Foca em dizer que a equipe tem má comunicação, mas não cita especificamente a definição e validação de Critérios de Aceitação.
- Insuficiente (0): A culpa é do desenvolvedor que não adivinhou ou do PO que é chato.
Questão 3: O Nivelamento de Recursos e o Herói
Due Date: 2026-09-23
Texto da Issue
Na sua equipe, há um “Desenvolvedor Herói” (Full-Stack Senior). No planejamento do Sprint, ele assume todas as tarefas críticas do Backend e Frontend, enquanto os novatos ficam com correções visuais simples. Pensando em Nivelamento de Recursos, o que acontece com o projeto se o “Herói” ficar doente e como o nivelamento deveria ser aplicado para evitar esse gargalo (Silo de Conhecimento)?
Gabarito / Rubrica de Correção
- Excelente (10): Explica que o projeto fica 100% bloqueado (fator ônibus = 1). O nivelamento evita alocações desproporcionais e sobrecarga de 1 recurso. Menciona técnicas como pareamento (pair programming) para disseminar o conhecimento e balancear a carga.
- Bom (7): Identifica o problema do cara ficar doente, mas não menciona ferramentas/soluções de nivelamento (ex: redistribuição de tarefas e compartilhamento).
- Insuficiente (0): Acha que é uma ótima estratégia pois o sênior programa mais rápido e a equipe entrega mais.
Questão 4: O “Silêncio” Tóxico da Equipe
Due Date: 2026-09-23
Texto da Issue
Na gestão de conflitos, uma das estratégias mais perigosas no longo prazo é a “Evitação” (varrer os problemas da equipe para debaixo do tapete). Se você tem um membro da equipe que sempre comita código sem testar, mas ninguém quer “ser o chato” de confrontá-lo, como isso impacta a qualidade no longo prazo? Como o ritual da Retrospectiva do Sprint ajuda a mediar e curar essa ferida?
Gabarito / Rubrica de Correção
- Excelente (10): Relata que a evitação quebra a confiança e abaixa a barra de qualidade (gerando dívida técnica enorme). A retrospectiva resolve fornecendo um ambiente estruturado e de segurança psicológica para atacar “o processo/código” em vez de atacar “a pessoa”.
- Bom (7): Entende que gera código ruim, mas não consegue justificar o papel formal da retrospectiva na mediação do conflito.
- Insuficiente (0): Aconselha que o Scrum Master dê bronca no funcionário na frente de todos ou demita imediatamente.
Questão 5: A Armadilha das Más Métricas
Due Date: 2026-09-23
Texto da Issue
O gerente quer provar para a diretoria que a equipe está com uma Qualidade fantástica e propõe usar a métrica: “Número de Linhas de Código Escritas por Dia”. Baseado nos modelos de Gestão de Qualidade, explique por que essa é uma métrica péssima e disfuncional. Que outras duas métricas focadas no processo e no produto você sugeriria em vez dessa?
Gabarito / Rubrica de Correção
- Excelente (10): Explica que mais linhas não significam valor, frequentemente significam código duplicado/sujo (dívida). Como alternativa, sugere “Tempo de carregamento” (performance), “Cobertura de Testes automatizados” ou “Bugs reportados por sprint”.
- Bom (7): Diz que qualidade não é quantidade, mas cita métricas confusas ou que não refletem nem produto nem processo.
- Insuficiente (0): Concorda que medir linhas de código é uma ótima forma de saber quem está trabalhando duro.