Data de Publicação

13/11/2026

Data de Modificação

12/11/2026

Questionário e Gabarito - Aula 10: Modelos Ágeis Alternativos (2026-2)

Este documento contém as questões que devem ser enviadas aos alunos via GitLab Issues para a Lista L10 (Aula 10: Modelos Ágeis Alternativos — Kanban, Lean e XP). O prazo final geral sugerido (Milestone) é 19/11/2026 (Quinta-feira).

Questão 1: O Princípio do Fluxo Contínuo, Limites de WIP e a Lei de Little no Kanban

Due Date: 2026-11-19

Texto da Issue

O modelo Kanban tem como premissa a gestão visual e a otimização do fluxo de trabalho, substituindo a rigidez temporal das iterações pelo fluxo contínuo puxado pela capacidade do time. Um dos seus conceitos centrais é o estabelecimento de Limites de Trabalho em Progresso (WIP - Work In Progress), fundamentado pela Lei de Little (\(Lead\,Time = WIP / Vaz\tilde{a}o\)).

  1. Explique como a redução do limite de WIP afeta diretamente o tempo de ciclo (Cycle Time) e a troca de contexto (Context Switching) dos desenvolvedores. O que é a prática ágil de swarming e por que o lema operacional do Kanban é “pare de começar e comece a terminar”?
  2. O fluxo no Issue Board do seu time: Inspecione o quadro Kanban da sua equipe no GitLab (gps-projetos-integradores). Quantas issues estão atualmente acumuladas nas colunas intermediárias (Doing ou Review)? Se uma dessas colunas estivesse congestionada, qual política de limite de WIP e de ação coletiva a sua equipe deveria adotar para destravar a entrega da Sprint 3?

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo! Respostas puramente conceituais sem os dados reais do repositório da sua equipe não atingirão a nota máxima.)

Gabarito / Rubrica de Correção

  • Excelente (10): Domina a relação matemática e prática entre WIP, Lead Time e multitarefa; fundamenta a técnica de swarming; analisa com dados reais o board da equipe no GitLab.
  • Bom (7): Conhece o quadro Kanban, mas não sabe justificar o limite de WIP com base na eficiência de fluxo ou traz resposta desconectada do repositório.
  • Insuficiente (0): Confunde Kanban com mero quadro de post-its sem limite de capacidade.

Questão 2: Os 7 Desperdícios do Lean (Muda) na Engenharia de Software

Due Date: 2026-11-19

Texto da Issue

Adaptado para a computação por Mary e Tom Poppendieck, o Lean Software Development ensina a equipe a eliminar sistematicamente tudo o que consome esforço sem gerar valor perceptível para o usuário final (Muda ou desperdício).

  1. Dentre os 7 desperdícios clássicos do Lean em software, analise o impacto negativo de três deles: (a) Trabalho Parcialmente Feito (código parado em branch isolada sem merge), (b) Recursos Extras (Gold Plating) (funcionalidades complexas desenvolvidas sem demanda real do usuário), e (c) Espera (Waiting) (tempo ocioso na fila de aprovação de código).
  2. O corte de desperdício no seu Professor Agente: Identifique 1 exemplo concreto de desperdício que a sua equipe cometeu (ou que precisou podar a tempo) durante a construção do assistente no semestre (ex: tentar criar suporte a dezenas de bibliotecas desnecessárias, gastar dias em telas secundárias enquanto o motor de prompt não funcionava, ou deixar branches estagnadas). Como o time identificou e eliminou esse desperdício para manter o MVP viável?

(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): Articula com precisão conceitual os desperdícios do Lean; diferencia trabalho incompleto de valor entregue; relata uma decisão real de gestão do escopo da sua equipe.
  • Bom (7): Conhece os desperdícios em teoria, mas traz um exemplo vago ou fictício que não reflete a rotina real do projeto integrador.
  • Insuficiente (0): Não compreende a filosofia Lean ou defende práticas de Gold Plating como algo positivo.

Questão 3: Extreme Programming (XP): Práticas de Engenharia, TDD e Pair Programming

Due Date: 2026-11-19

Texto da Issue

Enquanto o Scrum estabelece um arcabouço de papéis e eventos de gestão, o Extreme Programming (XP), criado por Kent Beck, foca na excelência técnica e na redução radical do custo da mudança através de práticas rigorosas de engenharia.

  1. Explique como a prática de TDD (Test-Driven Development) (o ciclo Red-Green-Refactor) e a Refatoração Contínua trabalham em conjunto com a Integração Contínua (CI) para criar uma rede de segurança que permite alterar e modernizar o código sem medo de regressões.
  2. Pair Programming e Code Review no repositório do time: No desenvolvimento do seu bot/assistente, descreva uma situação em que dois ou mais integrantes trabalharam juntos (seja programando em pares compartilhando tela ou fazendo Code Review minucioso em um Merge Request). Como essa prática de colaboração do XP ajudou a nivelar o conhecimento da equipe e eliminou o risco do “Desenvolvedor Herói” (Bus Factor = 1)?

(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 a dinâmica técnica do XP (TDD, refatoração e feedback imediato); ilustra com clareza como o trabalho em duplas ou revisão no GitLab aumentou o Bus Factor e a qualidade no projeto.
  • Bom (7): Entende o conceito de teste e pareamento, mas trata como mera divisão de tarefas ou não apresenta evidência de colaboração no GitLab.
  • Insuficiente (0): Afirma que TDD e Pair Programming são desperdício de tempo ou desconhece os papéis de Driver e Navigator.

Questão 4: ScrumBan: O Pragmatismo da Cadência com o Fluxo Contínuo

Due Date: 2026-11-19

Texto da Issue

Na engenharia de software contemporânea, times de alto desempenho raramente são puristas de uma única metodologia; eles combinam o melhor de cada abordagem. O ScrumBan representa a fusão pragmática entre a cadência e papéis do Scrum com a flexibilidade visual e o fluxo puxado do Kanban.

  1. Quais elementos estruturais o ScrumBan herda do Scrum (ex: cadência de planejamento, retrospectivas de melhoria, papéis bem definidos) e quais elementos adota do Kanban (ex: visualização transparente, políticas explícitas, puxada de tarefas sob demanda)? Por que essa abordagem é ideal para equipes que precisam cumprir marcos de entrega sem a rigidez de um Sprint Backlog congelado?
  2. O ScrumBan na prática da sua disciplina: Explique como a disciplina de GPS implementou um modelo genuíno de ScrumBan: de um lado, os Milestones quinzenais fixos no GitLab para as entregas de TP; de outro, o trabalho diário da equipe gerenciado via issues puxadas no board. Como a sua equipe organizou o fluxo de trabalho para não deixar todas as issues estourarem na véspera da Milestone?

(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): Sintetiza com clareza arquitetural a união Scrum + Kanban; fundamenta as vantagens operacionais do ScrumBan e analisa criticamente o ritmo de trabalho do time em relação aos Milestones da disciplina.
  • Bom (7): Descreve Scrum e Kanban isoladamente, mas tem dificuldade de explicar como operam juntos no ScrumBan.
  • Insuficiente (0): Considera Scrum e Kanban mutuamente exclusivos ou incompatíveis.

Questão 5: Métricas de Fluxo: Lead Time, Cycle Time e o Gargalo de Code Review

Due Date: 2026-11-19

Texto da Issue

Em gestão ágil de fluxo, entender o tempo que o software leva para percorrer o sistema é indispensável para evitar gargalos crônicos. Duas métricas temporais dominam essa análise: Lead Time e Cycle Time.

  1. Defina com rigor a diferença entre Lead Time (tempo decorrido desde a identificação da necessidade/criação da issue até sua entrega final ao usuário) e Cycle Time (tempo em que a tarefa esteve ativamente sendo trabalhada pela engenharia). Por que a etapa de espera por Code Review em Merge Requests é estatisticamente o maior vilão do Lead Time na indústria?
  2. O tempo de ciclo no GitLab da equipe: Analise o histórico dos Merge Requests da sua equipe no GitLab do projeto integrador:
    • Em média, quanto tempo um MR demorava entre ser aberto pelo autor e ser aprovado/mergeado pelo revisor?
    • Qual foi o acordo de equipe (SLA interno) adotado para garantir que um colega não ficasse bloqueado esperando revisão enquanto a Milestone se aproximava?

(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): Estabelece a distinção precisa entre Lead Time e Cycle Time com base nas filas de espera; analisa as métricas reais de tempo de MRs do repositório da equipe e detalha os acordos de revisão de código.
  • Bom (7): Confunde Lead Time com Cycle Time ou cita prazos de MR sem explicar a dinâmica de espera e bloqueio.
  • Insuficiente (0): Desconhece métricas de fluxo ou alega que tempo de revisão de código é irrelevante para o prazo final.
De volta ao topo