Questão de Engenharia de Software — Geral — FCC 2026
Engenharia de Software›Geral
Código
fc142525
Banca
FCC
Órgão
MPE AL
Ano
2026
Cargo
Ana ( )
Os analistas de um órgão público buscam transicionar seu modelo de desenvolvimento para uma estrutura ágil escalonada, visando integrar as equipes de novos produtos com as de suporte e manutenção. A nova abordagem deve cobrir desde a concepção estratégica até a sustentação em produção, mantendo a clareza sobre os papéis de liderança e a sincronia de entrega em larga escala mediante a aplicação correta de processos e metodologias no ciclo de vida completo. A abordagem correta, nesse caso, é a
Aaplicação do Scrum Guide 2020 para o desenvolvimento de novos sistemas, delegando a gestão do backlog de manutenção ao Scrum Master e utilizando o Kanban para definir as metas da Sprint e o planejamento do incremento.
Bestruturação do fluxo via XP (Extreme Programming) para todas as etapas, adotando o papel de System Architect do SAFe como responsável direto pela priorização do backlog de suporte e pela execução do planejamento em cascata.
Cadoção do modelo Cascata para as fases de concepção e análise, migrando para o Scrum durante a implementação, com foco no papel do Product Owner para gerenciar o suporte e os Service Request após a entrega final.
Dimplementação do Scrum para o desenvolvimento, utilizando o SAFe 6.0 para o alinhamento organizacional e o Kanban para o fluxo de suporte e manutenção, visando garantir a governança do Release Train Engineer nos ciclos de entrega.
Eutilização do RUP como framework de governança para as etapas de projeto e construção, integrando práticas de XP (Extreme Programming) na sustentação técnica para otimizar as janelas de manutenção corretiva e preventiva.
Revelar gabarito e comentário▾
GabaritoD — implementação do Scrum para o desenvolvimento, utilizando o SAFe 6.0 para o alinhamento organizacional e o Kanban para o fluxo de suporte e manutenção, visando garantir a governança do Release Train Engineer nos ciclos de entrega.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Escalando ágil: Scrum, SAFe e Kanban no ciclo de vida completo
Gabarito: letra D. A alternativa correta combina o Scrum para o desenvolvimento de novos sistemas, o SAFe 6.0 para o alinhamento organizacional em larga escala e o Kanban para o fluxo de suporte e manutenção, garantindo a governança do Release Train Engineer (RTE) nos ciclos de entrega. Essa é a abordagem que integra equipes de novos produtos com as de suporte, cobrindo da concepção estratégica à sustentação em produção, conforme os princípios do Scaled Agile Framework.
O enunciado descreve um cenário típico de escalonamento ágil: uma organização que precisa coordenar múltiplas equipes, integrar desenvolvimento e operação, e manter clareza sobre papéis de liderança e sincronia de entrega. O SAFe (Scaled Agile Framework) é o framework mais consolidado para esse fim, pois estrutura o trabalho em níveis (Team, Program, Large Solution e Portfolio) e define papéis específicos para cada um. No nível de Programa, o Release Train Engineer (RTE) atua como o "Scrum Master do ART" (Agile Release Train), coordenando o PI Planning e facilitando a execução do fluxo de valor em escala.
A combinação proposta na alternativa D é coerente porque cada método é aplicado onde tem maior aderência: o Scrum gerencia o desenvolvimento iterativo de novos produtos; o SAFe fornece a governança e o alinhamento estratégico entre os times; e o Kanban é ideal para o fluxo contínuo de suporte e manutenção, que não se encaixa em sprints fixos. Essa divisão de responsabilidades é uma prática comum em organizações que buscam agilidade em larga escala, e é exatamente o que o enunciado pede: "integrar as equipes de novos produtos com as de suporte e manutenção".
As demais alternativas falham ao misturar papéis e responsabilidades de forma incorreta, atribuindo funções a personagens errados ou usando métodos inadequados para determinadas etapas. A banca explora justamente a confusão entre os papéis do Scrum (Product Owner, Scrum Master) e do SAFe (RTE, System Architect), além de misturar metodologias tradicionais (Cascata, RUP) com ágeis de forma incoerente.
NÃO CAIA NESSA!
A banca adora inverter os papéis entre Scrum e SAFe. O Scrum Master não gerencia backlog de manutenção (isso é papel do Product Owner, e mesmo assim apenas o backlog do produto); o System Architect do SAFe não prioriza backlog de suporte (isso é papel do Product Manager ou do Product Owner); e o Product Owner não gerencia Service Request (isso é fluxo de suporte, tipicamente Kanban). Fique atento: cada papel tem uma responsabilidade específica, e a troca é o erro mais comum nessas questões.
O erro está em atribuir ao Scrum Master a gestão do backlog de manutenção. No Scrum, o Scrum Master é um líder servidor que facilita o processo, remove impedimentos e promove práticas ágeis — ele não gerencia backlog. Quem gerencia e prioriza o backlog é o Product Owner. Além disso, o Kanban não é usado para "definir as metas da Sprint" — as metas da Sprint são definidas no Sprint Planning, um evento do Scrum. O Kanban é um método de fluxo contínuo, não um mecanismo de planejamento de sprint.
Alternativa B — ❌ Incorreta
A alternativa mistura XP com SAFe de forma equivocada. O System Architect do SAFe é responsável pela arquitetura técnica e orientação de decisões de escalabilidade, não pela priorização do backlog de suporte. Além disso, o XP (Extreme Programming) é uma metodologia focada em práticas técnicas de desenvolvimento (programação em pares, TDD, refatoração), não em "todas as etapas" do ciclo de vida, e o "planejamento em cascata" é uma contradição com os princípios ágeis do XP.
Alternativa C — ❌ Incorreta
A alternativa propõe um modelo híbrido Cascata + Scrum, mas atribui ao Product Owner a gestão de suporte e Service Request. O Product Owner é responsável por maximizar o valor do produto, priorizando o Product Backlog — ele não gerencia suporte técnico. Além disso, a adoção do modelo Cascata para "concepção e análise" contradiz a proposta de uma estrutura ágil escalonada, que busca justamente evitar a rigidez do modelo sequencial.
Alternativa D — ✅ Correta ⟵ GABARITO
A alternativa combina corretamente as três abordagens: Scrum para o desenvolvimento iterativo de novos produtos, SAFe 6.0 para o alinhamento organizacional e a governança em larga escala, e Kanban para o fluxo contínuo de suporte e manutenção. O Release Train Engineer (RTE) é o papel do SAFe que coordena o Agile Release Train (ART), facilitando o PI Planning e garantindo a sincronia de entrega — exatamente o que o enunciado pede: "clareza sobre os papéis de liderança e a sincronia de entrega em larga escala".
Alternativa E — ❌ Incorreta
A alternativa usa o RUP (Rational Unified Process) como framework de governança, mas o RUP é um processo tradicional, não ágil, e não é adequado para uma estrutura ágil escalonada. Além disso, integrar práticas de XP na "sustentação técnica" para otimizar "janelas de manutenção" é um uso inadequado do XP, que é focado em práticas de desenvolvimento, não em manutenção corretiva e preventiva.