Questão de Engenharia de Software — Processos de Software - Desenvolvimento Ágil — FCC 2026
Engenharia de Software›Processos de Software - Desenvolvimento Ágil
Código
gp044436
Banca
FCC
Órgão
MPE-AL
Ano
2026
Cargo
Analista do Ministério Público - Especialidade: Desenvolvimento de Sistemas
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 o 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 no Extreme Programming na sustentação técnica para aprimorar a qualidade dos artefatos e contratos.
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”.
Transição para desenvolvimento ágil escalonado
Gabarito: letra D. A alternativa correta combina Scrum para o desenvolvimento, SAFe 6.0 para o alinhamento organizacional em larga escala e Kanban para o fluxo de suporte e manutenção, com o Release Train Engineer (RTE) garantindo a governança dos ciclos de entrega — essa é a abordagem que integra equipes de novos produtos e suporte de forma coerente com as práticas ágeis escaladas.
A questão testa a capacidade de combinar frameworks ágeis (Scrum, SAFe, Kanban) e papéis (RTE, Product Owner, Scrum Master) de acordo com suas finalidades, evitando misturas incorretas. A seguir, analisa-se cada alternativa.
Abordagem ágil escalonada: Scrum (Desenvolvimento iterativo, Product Owner (backlog), Sprint Planning (metas)); SAFe 6.0 (Alinhamento organizacional, Release Train Engineer (RTE), Governança dos ciclos de entrega); Kanban (Fluxo de suporte e manutenção, Gestão do fluxo de trabalho)
Alternativa A — ❌ Incorreta
Afirma que o Scrum Master gerencia o backlog de manutenção e que o Kanban define metas da Sprint. No Scrum, o Product Owner é quem gerencia o backlog (Product Backlog). O Kanban é um método para gerenciar o fluxo de trabalho, não para definir metas de Sprint — isso é feito no Sprint Planning do Scrum. Além disso, utilizar Scrum apenas para novos sistemas e Kanban para suporte pode ser válido, mas a delegação de papéis está errada.
Alternativa B — ❌ Incorreta
Propõe XP para todas as etapas e atribui ao System Architect do SAFe a priorização do backlog de suporte e o planejamento em cascata. XP (Extreme Programming) é focado em práticas técnicas, não em escala organizacional. No SAFe, o papel de Product Owner (ou Product Manager em nível de programa) é responsável pela priorização do backlog. O planejamento em cascata é oposto aos princípios ágeis. A mistura de papéis e abordagens é inconsistente.
Alternativa C — ❌ Incorreta
Sugere modelo Cascata para concepção/análise e Scrum para implementação, com Product Owner gerenciando suporte. A combinação de Cascata (preditivo) com Scrum (adaptativo) no mesmo ciclo de vida gera conflitos de planejamento. Além disso, o Product Owner não é o responsável direto pelo suporte pós-entrega; esse papel é geralmente de uma equipe de suporte ou de operações. A transição híbrida não é a abordagem escalonada sugerida pelo enunciado.
Alternativa D — ✅ Correta ⟵ GABARITO
Implementa Scrum para o desenvolvimento iterativo, SAFe 6.0 para coordenar múltiplas equipes em larga escala (incluindo a sincronia de entrega) e Kanban para o fluxo contínuo de suporte e manutenção. O Release Train Engineer (RTE) é um papel do SAFe que atua como facilitador e coach do ART (Agile Release Train), garantindo a governança e a execução dos ciclos de entrega (Program Increments). Essa combinação respeita os papéis e processos de cada framework: Scrum para o time, SAFe para o alinhamento organizacional e Kanban para o trabalho não iterativo de suporte.
Alternativa E — ❌ Incorreta
Utiliza o RUP (Rational Unified Process) como framework de governança e integra práticas de XP na sustentação técnica. O RUP é um processo iterativo, mas não é classificado como ágil (é mais pesado e prescritivo). Misturar RUP com XP em um contexto de suporte não resolve a necessidade de escalabilidade e sincronia entre equipes de produto e suporte. A governança proposta não está alinhada com os princípios ágeis modernos.