Questão de Engenharia de Software — Processos de Software - Desenvolvimento Ágil — FGV 2026
Engenharia de Software›Processos de Software - Desenvolvimento Ágil
Código
fg133787
Banca
FGV
Órgão
TJ-RJ
Ano
2026
Nível
Superior
Cargo
Analista Judiciário - Tecnologia da Informação - Analista de Inteligência Artificial
O departamento de TI de uma escola está desenvolvendo um Sistema de Gestão Escolar usando a metodologia ágil. Depois de definido 90% do escopo do projeto, o diretor da escola solicitou uma mudança significativa no escopo com a alegação de que a nova funcionalidade tinha se tornado prioridade.A equipe ágil deve lidar com essa demanda:
Aaceitando a mudança apenas após o término do projeto;
Brecusando a mudança, pois ela compromete o planejamento inicial;
Cavaliando a solicitação junto ao Product Owner e adaptando o backlog;
Dcobrando uma taxa adicional e incluindo a funcionalidade sem discussão;
Esuspendendo o projeto até que todas as mudanças sejam definidas.
Revelar gabarito e comentário▾
GabaritoC — avaliando a solicitação junto ao Product Owner e adaptando o backlog;
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”.
Metodologia Ágil — Lidando com Mudanças de Escopo
Gabarito: letra C. A equipe ágil deve avaliar a solicitação junto ao Product Owner e adaptar o backlog, conforme o princípio do Manifesto Ágil que valoriza "responder a mudanças mais que seguir um plano". Essa é a essência do desenvolvimento ágil: acolher mudanças, até tardias, para maximizar o valor entregue ao cliente.
A questão explora um dos valores centrais do Manifesto Ágil: abertura a mudanças, mesmo após significativo progresso. Em projetos ágeis, mudanças no escopo são tratadas como oportunidades, e não como ameaças. O Product Owner é o responsável por priorizar e ajustar o Product Backlog, garantindo que as funcionalidades mais valiosas sejam desenvolvidas primeiro.
1Solicitação de mudança
2Avaliação com Product Owner
3Priorização no backlog
4Adaptação do planejamento
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Aceitar a mudança apenas após o término do projeto é típico de metodologias tradicionais (cascata), que congelam o escopo. No ágil, as mudanças são incorporadas continuamente.
Alternativa B — ❌ Incorreta
Recusar a mudança por comprometer o planejamento inicial contraria o espírito ágil, que valoriza a adaptabilidade. O planejamento é flexível e revisado constantemente.
Alternativa C — ✅ Correta ⟵ GABARITO
A equipe avalia a mudança junto ao Product Owner, que decide se e como priorizá-la no backlog. Essa é a prática recomendada pelo Scrum e pelos métodos ágeis em geral.
Alternativa D — ❌ Incorreta
Cobrar taxa adicional e incluir a funcionalidade sem discussão fere a transparência e a colaboração. O valor ágil "indivíduos e interações mais que processos" e "colaboração do cliente mais que negociação de contratos" é desrespeitado.
Alternativa E — ❌ Incorreta
Suspender o projeto até definir todas as mudanças é contraproducente. O ágil preza por entregas incrementais e contínuas; mudanças são absorvidas ao longo do desenvolvimento.
NÃO CAIA NESSA!
O candidato pode ser tentado a escolher a opção B (recusar a mudança) por associar mudança tardia a prejuízo. No ágil, no entanto, mudanças são bem-vindas e gerenciadas via backlog priorizado. Lembre-se: o Manifesto Ágil diz "responder a mudanças mais que seguir um plano".