Questão de Engenharia de Software — Outras Metodologias Ágeis e Questões Mescladas — FCC 2025

SAFe, Scrum e Kanban: identificando o framework correto

Gabarito: letra C. A alternativa correta descreve o PI Planning do SAFe (Scaled Agile Framework), evento de planejamento colaborativo em ciclos programados que sincroniza múltiplas equipes e alinha a entrega de valor em grande escala. As demais alternativas misturam conceitos de Kanban, Scrum e SAFe de forma incorreta, atribuindo práticas e papéis a frameworks errados.

O enunciado apresenta um cenário em que os analistas optaram por aplicar práticas ágeis envolvendo SAFe, Scrum e Kanban. A questão testa o conhecimento sobre as características distintivas de cada framework. O SAFe é um framework de ágil escalado, projetado para coordenar múltiplas equipes em grandes organizações. Seu principal evento de sincronização é o PI Planning (Program Increment Planning), uma reunião presencial de dois dias que ocorre no início de cada Program Increment (PI), geralmente com duração de 8 a 12 semanas. Durante o PI Planning, todas as equipes se reúnem para planejar o trabalho do próximo incremento, alinhando objetivos, identificando dependências e criando um plano integrado. Esse evento é fundamental para garantir que as equipes trabalhem de forma coordenada e entreguem valor de forma contínua.

O Scrum, por sua vez, é um framework ágil para gerenciar o desenvolvimento de produtos complexos, baseado em iterações chamadas Sprints. Ele define papéis (Product Owner, Scrum Master, Time de Desenvolvimento), eventos (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) e artefatos (Product Backlog, Sprint Backlog, Increment). O Kanban é um método de gestão de fluxo de trabalho, focado na visualização do trabalho, limitação do WIP (Work In Progress) e melhoria contínua. Ele não prescreve iterações nem papéis fixos, sendo mais adequado para ambientes com demandas contínuas e alta variabilidade.

A pegadinha da questão está em atribuir conceitos de um framework a outro. Por exemplo, a alternativa A atribui ao Kanban a prática de "priorização semanal de tarefas, estruturada por papéis e eventos formais", o que é uma característica do Scrum, não do Kanban. A alternativa B atribui ao Scrum o conceito de Program Increment (PI), que é do SAFe. A alternativa D atribui ao Scrum o uso do Kanban Board como artefato para controle individual do fluxo de trabalho, o que não é uma prática do Scrum. A alternativa E atribui ao SAFe a responsabilidade do Scrum Master por definir tecnicamente os incrementos e tomar decisões de arquitetura, o que não corresponde ao papel do Scrum Master em nenhum framework.

A alternativa C está correta porque descreve com precisão o PI Planning do SAFe: "o sincronismo entre múltiplas equipes é realizado por meio de eventos como o PI Planning, que permite o planejamento colaborativo em ciclos programados, alinhando a entrega de valor em grande escala". Essa é a definição exata do evento no contexto do SAFe.

Alternativa A — ❌ Incorreta

A alternativa afirma que no Kanban a principal prática para lidar com demandas não planejadas é a "priorização semanal de tarefas, estruturada por papéis e eventos formais, semelhantes ao Sprint Planning do Scrum". Isso está errado porque o Kanban não possui papéis fixos nem eventos formais como o Sprint Planning. O Kanban é um método de gestão de fluxo contínuo, baseado na visualização do trabalho, limitação do WIP e melhoria contínua. A priorização de tarefas no Kanban é feita de forma contínua, conforme a capacidade da equipe, e não em reuniões semanais estruturadas. A descrição apresentada mistura conceitos do Scrum (papéis, eventos, Sprint Planning) com o Kanban, o que é incorreto.

Alternativa B — ❌ Incorreta

A alternativa afirma que no Scrum o conceito de Program Increment (PI) é aplicado para organizar o Product Backlog em entregas fixas trimestrais. Isso está errado porque o Program Increment (PI) é um conceito do SAFe, não do Scrum. No Scrum, o Product Backlog é organizado em Sprints, que são iterações de 1 a 4 semanas, e não em entregas trimestrais. O PI é um período de 8 a 12 semanas no SAFe, durante o qual múltiplas equipes trabalham para entregar um incremento de valor. A alternativa confunde os conceitos de Scrum e SAFe.

Alternativa C — ✅ Correta ⟵ GABARITO

A alternativa afirma que no SAFe o sincronismo entre múltiplas equipes é realizado por meio de eventos como o PI Planning, que permite o planejamento colaborativo em ciclos programados, alinhando a entrega de valor em grande escala. Isso está correto. O PI Planning é um evento central do SAFe, que ocorre no início de cada Program Increment (PI), geralmente com duração de dois dias. Durante o evento, todas as equipes se reúnem para planejar o trabalho do próximo incremento, alinhando objetivos, identificando dependências e criando um plano integrado. Esse evento é fundamental para garantir a coordenação entre múltiplas equipes e o alinhamento com a visão do produto e os objetivos da organização.

Alternativa D — ❌ Incorreta

A alternativa afirma que no Scrum o Kanban Board é um artefato utilizado para garantir controle detalhado do fluxo de trabalho individual dos membros da equipe, podendo substituir o uso do Product Backlog. Isso está errado por dois motivos. Primeiro, o Kanban Board não é um artefato do Scrum; é uma ferramenta do Kanban. Segundo, o Kanban Board não substitui o Product Backlog, que é o artefato do Scrum que contém a lista priorizada de requisitos do produto. O Kanban Board é usado para visualizar o fluxo de trabalho, mas não para substituir o backlog. A alternativa mistura conceitos de Scrum e Kanban de forma incorreta.

Alternativa E — ❌ Incorreta

A alternativa afirma que no SAFe o Scrum Master é responsável por definir tecnicamente os incrementos de produto e tomar decisões de arquitetura, devido à sua visão de governança ágil centralizada. Isso está errado porque o papel do Scrum Master, tanto no Scrum quanto no SAFe, é facilitar o processo, remover impedimentos e garantir que o framework seja seguido. O Scrum Master não define tecnicamente os incrementos nem toma decisões de arquitetura; essas responsabilidades são do Time de Desenvolvimento e do Product Owner, respectivamente. A alternativa atribui ao Scrum Master um papel que não é dele, confundindo suas responsabilidades.

Gabarito: letra C