Métodos Ágeis para SEFAZ-CE na FCC: Scrum, Kanban, XP e Gestão de Backlog (sem enrolação)

Por
Publicado em • Atualizado em
3 min. de leitura

Quando a banca é FCC, “métodos ágeis” costuma aparecer em múltipla escolha com alternativas muito parecidas. O segredo não é decorar frases motivacionais, e sim dominar diferenças objetivas: quem faz o quê (papéis), o que acontece quando (eventos), o que é produzido (artefatos) e qual prática pertence a qual abordagem (Scrum x Kanban x XP). Se você acerta esse “mapa”, a questão vira praticamente um exercício de eliminação.

Neste artigo, vou direto ao que mais aparece em prova: Scrum, Kanban, XP e gestão de backlog com priorização. (E sim: a FCC adora trocar o papel do Product Owner com o do Scrum Master, ou vender Kanban como se fosse Scrum sem sprint.)

Terças e quintas de TI. Conteúdo prático e artigos especializados para acelerar seu conhecimento. Acesse agora!

Scrum: o pacote completo que a FCC mais cobra

Scrum é um framework para desenvolvimento incremental em Sprints, baseado em inspeção e adaptação. Na prova, o que mais cai é o trio: Papéis (accountabilities), Eventos e Artefatos.

Papéis

  • Product Owner (PO): maximiza valor e é o responsável por ordenar/priorizar o Product Backlog
  • Scrum Master: garante que o Scrum seja entendido e bem aplicado; remove impedimentos e facilita a vida do time. 
  • Developers: constroem o incremento; são responsáveis por entregar software pronto conforme a Definição de Pronto. 

Pegadinha clássica: o PO não é “chefe do time”, e o Scrum Master não é “gerente do projeto”. Na FCC, essas trocas aparecem como alternativas “quase certas”.

Eventos

  • Sprint Planning: define objetivo da sprint e como o trabalho será feito. 
  • Daily Scrum: sincroniza o time e ajusta o plano diário. 
  • Sprint Review: inspeciona o incremento com stakeholders e coleta feedback. 
  • Sprint Retrospective: melhora processo, práticas e colaboração. 

Pegadinha clássica: Review é sobre produto/incremento; Retrospective é sobre processo/time.

Artefatos

  • Product Backlog: lista ordenada do que pode gerar valor no produto. 
  • Sprint Backlog: itens selecionados para a sprint + plano de execução. 
  • Incremento: soma do trabalho “pronto” até o momento. 

Backlog no ágil: épico, feature e história (a hierarquia que derruba)

Em agilidade, a organização do trabalho costuma aparecer assim:

  • Épico: demanda grande, ampla e ainda “gorda”. 
  • Feature: capacidade/funcionalidade com valor percebido, menor que épico. 
  • História de usuário: item pequeno e negociável, geralmente no formato
    “Como [perfil], quero [objetivo] para [benefício]”. 

A FCC gosta de cobrar a ideia de que histórias devem ser testáveis, claras e pequenas o suficiente para caber na sprint (ou em uma janela razoável de entrega).


Priorização: MoSCoW e Kano (o que cada uma faz)

Priorização aparece em alternativas que trocam nomes e conceitos. Guarde o essencial:

  • MoSCoW: classifica itens em Must / Should / Could / Won’t (por agora)
  • Kano: classifica requisitos por impacto na satisfação:
    básicos, desempenho e encantadores

Dica de prova: MoSCoW é uma régua de obrigatoriedade e negociação; Kano é uma lente de satisfação do usuário.


Kanban: fluxo contínuo, WIP e melhoria do sistema

Kanban foca em gestão do fluxo. Ele não depende de sprints; pode até ter cadências, mas não é a essência. O que a FCC mais explora:

  • Visualizar trabalho (quadro/colunas/estado). 
  • Limitar WIP (Work in Progress) para reduzir multitarefa e gargalos. 
  • Melhoria contínua (otimizar o fluxo, reduzir espera, aumentar previsibilidade). 
  • Medidas típicas: lead time (tempo total) e cycle time (tempo em execução). 

Pegadinha clássica: Kanban não exige PO, eventos do Scrum nem timebox obrigatório.


XP: práticas de engenharia que a FCC coloca nas alternativas

XP (Extreme Programming) costuma ser cobrado pelas práticas. As mais frequentes:

  • Programação em pares 
  • Integração contínua 
  • Refatoração 
  • Padrão de codificação 
  • Propriedade coletiva do código (evita “dono fixo” de módulo) 

Quando a questão falar em propriedade coletiva, desconfie de alternativas que tentam manter “responsável fixo por componente”. Isso contraria o espírito do XP.


O que mais cai como “pegadinha” em métodos ágeis na FCC

  • Dizer que “ágil não tem planejamento” → errado (há planejamento contínuo). 
  • Trocar Review com Retrospective → errado (produto vs processo). 
  • Transformar Kanban em Scrum sem sprint → errado (fluxo vs timebox). 
  • Colocar PO como “chefe do time” → errado (ele maximiza valor e ordena backlog). 
  • Colocar Scrum Master como “gerente do projeto” → errado (ele facilita e remove impedimentos). 

Questões FCC (múltipla escolha)

1) Em uma equipe Scrum, o membro responsável por maximizar o valor do produto, ordenando e priorizando itens do Product Backlog, é o:

A) Scrum Master
B) Stakeholder
C) Gerente de Projetos
D) Product Owner
E) Desenvolvedor

Gabarito: D


2) No Scrum, o evento voltado à inspeção do incremento com stakeholders e coleta de feedback sobre o produto é:

A) Daily Scrum
B) Sprint Planning
C) Sprint Review
D) Sprint Retrospective
E) Refinamento do Backlog

Gabarito: C


3) Em Kanban, a prática mais diretamente associada a reduzir gargalos e evitar excesso de trabalho simultâneo é:

A) Planejamento da Sprint
B) Limitação de WIP
C) Reunião diária com timebox fixo
D) Definição de incremento a cada Sprint
E) Criação de épicos e histórias como artefatos obrigatórios

Gabarito: B


4) A técnica de priorização MoSCoW classifica itens do backlog em:

A) Básico, desempenho e encantamento
B) Curto prazo, médio prazo e longo prazo
C) Must, Should, Could e Won’t (por agora)
D) Funcionais, não funcionais e regras de negócio
E) Alto risco, médio risco e baixo risco

Gabarito: C


5) No Extreme Programming (XP), práticas que favorecem a propriedade coletiva do código incluem:

A) Atribuição de módulos a responsáveis fixos para garantir consistência
B) Programação em pares, integração contínua e padrão de codificação acordado
C) Limitação de WIP e gestão do fluxo contínuo por colunas
D) Revisão do incremento ao final de cada sprint como mecanismo central de validação
E) Centralização de decisões de arquitetura em um time separado de arquitetos

Gabarito: B

Por
Publicado em • Atualizado em
3 min. de leitura