Data de Publicação

27/10/2026

Data de Modificação

26/10/2026

Questionário e Gabarito - Aula 8: Fundamentos Ágeis e Scrum (2026-2)

Este documento contém as questões que devem ser enviadas aos alunos via GitLab Issues para a Lista L08 (Aula 8: Fundamentos Ágeis e Scrum). O prazo final geral sugerido (Milestone) é 08/11/2026 (Domingo).

Questão 1: Filosofia Ágil vs. “Scrum Zumbi” (Os 4 Valores do Manifesto de 2001)

Due Date: 2026-11-08

Texto da Issue

Em 2001, dezessete engenheiros de software reuniram-se no resort de Snowbird e elaboraram o Manifesto para o Desenvolvimento Ágil de Software, reagindo ao excesso de documentação e burocracia dos métodos tradicionais (Cascata/RUP). No mercado contemporâneo, no entanto, muitas organizações praticam o chamado “Scrum Zumbi”: seguem ritos e cerimônias de forma mecânica, mas continuam operando com mentalidade rígida e burocrática.

  1. Detalhe os 4 valores fundamentais do Manifesto Ágil, demonstrando por que o manifesto estabelece que, embora haja valor nos itens da direita (processos, documentação, contratos, plano), a equipe valoriza muito mais os itens da esquerda (indivíduos, software funcionando, colaboração, resposta a mudanças). Explique a diferença crucial entre Filosofia Ágil (Mindset), Metodologias e Frameworks (como Scrum/Kanban).
  2. A vivência prática no seu Assistente I.A.: No projeto da sua equipe, relate uma situação real em que priorizar a colaboração direta e o incremento funcional funcional (“Software em funcionamento”) evitou retrabalho e se mostrou muito superior a ficar semanas planejando especificações que ficariam obsoletas ao conectar o código com a API da LLM.

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

Gabarito / Rubrica de Correção

  • Excelente (10): Articula com maturidade os 4 valores do Manifesto sem simplificações ingênuas; diferencia com clareza Filosofia, Metodologia e Framework; conecta a teoria a um exemplo técnico e real do Assistente IA (ex: descoberta empírica de latência/tokens ou ajuste no prompt antes de engessar o código).
  • Bom (7): Cita os 4 valores, mas de forma rasa ou meramente decorada, ou traz um exemplo hipotético genérico de grupo.
  • Insuficiente (0): Afirma que ágil proíbe documentação e planejamento, ou confunde manifesto com regras do Scrum.

Questão 2: Os 3 Papéis do Scrum e o Mito do “Gerente Disfarçado” (PO, SM e Developers)

Due Date: 2026-11-08

Texto da Issue

O Scrum aboliu intencionalmente a figura do antigo “Gerente de Projeto” centralizador de comando e controle, redistribuindo suas antigas funções em três papéis fundamentais: o Product Owner (PO), o Scrum Master (SM) e a Equipe de Desenvolvedores (Developers).

  1. Diferencie rigorosamente as responsabilidades de negócio do Product Owner (maximização do valor do produto e ordenação do Product Backlog) das responsabilidades de processo e facilitação do Scrum Master (liderança servidora, guardião dos ritos e removedor de impedimentos). Por que é uma grave distorção transformar o PO em um “chefe tradicional que cobra tarefas” ou o SM em um “secretário que agenda reuniões”?
  2. A governança no GitLab do seu time: No seu grupo de 3 a 4 integrantes do Assistente I.A., como vocês organizaram a distribuição desses papéis? Como a equipe atua de forma auto-organizada e multifuncional para resolver um bloqueio técnico (ex: falha de integração de API ou pipeline quebrado) sem esperar ordens verticais?

(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): Demonstra distinção límpida entre autoridade de conteúdo (PO) e autoridade de processo (SM); desconstrói o modelo de comando-e-controle em favor da liderança servidora e da auto-organização; detalha a dinâmica interna real de resolução de problemas no repositório da equipe.
  • Bom (7): Cita os papéis, mas ainda enxerga o PO ou SM como um líder tradicional que manda na equipe, ou descreve a auto-organização de forma ingênua (“a gente se ajuda”).
  • Insuficiente (0): Confunde as responsabilidades dos papéis ou alega que Scrum é sinônimo de “ninguém manda em nada e não há papéis”.

Questão 3: Os 3 Pilares Empíricos e as 4 Cerimônias: Por que a Daily NÃO é Relatório de Status

Due Date: 2026-11-08

Texto da Issue

O Scrum sustenta-se sobre a teoria do controle empírico de processos, sustentado por três pilares inseparáveis: Transparência, Inspeção e Adaptação. Para materializar esse controle empírico, o framework prescreve quatro cerimônias oficiais com time-box (além do Sprint em si): Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective.

  1. Relacione como os 3 pilares empíricos ganham vida em cada uma das cerimônias. Em seguida, desmonte tecnicamente o erro comum de transformar a Daily Scrum em um “relatório de status” para o professor ou líder: qual é a real finalidade da Daily e por que seu foco é inspecionar o progresso rumo ao Sprint Goal e identificar bloqueios entre os desenvolvedores?
  2. A Retrospectiva da sua equipe no Checkpoint: Após a entrega do Módulo 1 / Checkpoint inicial do Assistente I.A., como o grupo conduziu sua avaliação de melhoria contínua? Cite 1 melhoria concreta de processo (ex: regras mais rígidas no Merge Request, limites de tempo por issue, maior frequência de alinhamentos ou revisão cruzada) que a equipe decidiu adotar para os ciclos seguintes.

(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 com precisão conceitual Transparência, Inspeção e Adaptação às 4 cerimônias; desconstrói com maturidade a Daily como prestação de contas burocrática; detalha uma melhoria real e verificável no fluxo de engenharia adotada pelo time após a entrega inicial.
  • Bom (7): Conhece as cerimônias, mas descreve a Daily como mera prestação de contas (“dizer o que fez ontem e o que fará hoje”), ou relata melhorias genéricas de grupo sem conexão com o processo.
  • Insuficiente (0): Erra os pilares empíricos ou não compreende a finalidade da retrospectiva.

Questão 4: User Stories, Critérios INVEST e a Decomposição em Fatias Verticais

Due Date: 2026-11-08

Texto da Issue

No desenvolvimento ágil, requisitos não são listas de especificações funcionais congeladas, mas sim expressos na forma de User Stories (Histórias de Usuário), complementadas por Critérios de Aceitação rigorosos. Uma boa história de usuário deve satisfazer as diretrizes do acrônimo INVEST criado por Bill Wake.

  1. Detalhe os 6 critérios do acrônimo INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Explique por que fatiar itens de backlog em fatias verticais (que entregam uma ponta a ponta funcional de valor para o usuário) é infinitamente superior a fatiar em “camadas horizontais” (uma issue só para criar tabelas de banco, outra só para desenhar botões de tela).
  2. A User Story do seu Assistente I.A.: Escreva 1 User Story completa do projeto do seu grupo no formato canônico (“Como [persona], eu quero [funcionalidade] para que [benefício de valor]”), acompanhada de 3 critérios de aceitação específicos e verificáveis (cenários de teste ou comportamento esperado do bot). Justifique como ela cumpre os critérios INVEST.

(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): Explica com profundidade cada letra do modelo INVEST; defende a fatiamento vertical contra a armadilha das camadas técnicas horizontais; formula uma User Story impecável para o Assistente IA com 3 critérios de aceitação testáveis e bem definidos.
  • Bom (7): Cita os critérios INVEST, mas a User Story proposta é genérica ou se parece com uma tarefa puramente técnica sem valor de negócio para o usuário final.
  • Insuficiente (0): Desconhece o modelo INVEST ou formula histórias sem formato de persona/valor.

Questão 5: A Ilusão da “Velocidade Mágica” e o Débito Técnico no Desenvolvimento Ágil

Due Date: 2026-11-08

Texto da Issue

Um dos maiores equívocos de gestores inexperientes é acreditar que “adotar métodos ágeis significa entregar software na metade do tempo, custando menos e pulando testes”. Pior ainda é transformar a Velocidade da Equipe (Velocity) em uma métrica de produtividade para cobrar os desenvolvedores a “pontuarem mais”.

  1. O que é de fato a métrica de Velocidade (Velocity) no Scrum, como ela deve ser usada para estabilização de planejamento de capacidade e por que utilizá-la como meta de cobrança individual ativa a Lei de Goodhart (“quando uma métrica se torna uma meta, ela deixa de ser uma boa métrica”), induzindo inflação de estimativas e explosão de dívida técnica?
  2. A postura ágil no seu time diante da pressão de prazo: Se o seu grupo do Assistente I.A. perceber, a dois dias da entrega final, que não haverá tempo para concluir todas as funcionalidades prometidas na Sprint, qual é a atitude ágil correta a ser tomada junto ao Product Backlog e ao escopo, em vez de recorrer a “gambiarras”, código sem testes e commits desesperados de madrugada?

(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): Desmistifica a velocidade como produtividade; aplica a Lei de Goodhart demonstrando como métricas manipuladas destroem a qualidade; fundamenta a resposta ágil diante de aperto de prazo (redução negociada de escopo preservando o Definition of Done e a excelência técnica).
  • Bom (7): Entende o conceito de velocidade, mas hesita em defender a negociação de escopo, sugerindo “fazer hora extra” ou “correr para entregar tudo”.
  • Insuficiente (0): Afirma que ágil serve para trabalhar sob pressão contínua ou defende sacrificar qualidade para bater metas de velocidade.
De volta ao topo