Questão de Engenharia de Software — Processos de Software - Desenvolvimento Ágil — FGV 2026
Engenharia de Software›Processos de Software - Desenvolvimento Ágil
Código
fg133768
Banca
FGV
Órgão
TJ-RJ
Ano
2026
Nível
Superior
Cargo
Analista Judiciário - Tecnologia da Informação - Analista de Infraestrutura de TIC
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”.
Gestão de Mudanças em Metodologias Ágeis
Gabarito: letra C. No desenvolvimento ágil, mudanças são bem-vindas mesmo tardiamente (Manifesto Ágil: "responder a mudanças mais que seguir um plano") e a equipe deve avaliar a solicitação junto ao Product Owner, que é o responsável por priorizar e adaptar o Product Backlog de forma contínua. A alternativa C reflete exatamente essa prática.
A banca testa se o candidato compreende os valores ágeis e o papel do Product Owner na gestão de mudanças.
1Solicitação de mudança
2Product Owner avalia impacto
3Adaptação do Product Backlog
4Equipe executa na Sprint
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Aceitar a mudança apenas após o término do projeto contraria o princípio de entregar valor continuamente e de acolher mudanças mesmo em fases avançadas. A agilidade permite replanejar a cada iteração.
Alternativa B — ❌ Incorreta
Recusar a mudança por comprometer o planejamento inicial é uma postura de metodologia preditiva (cascata), não ágil. O planejamento ágil é flexível e prioriza a satisfação do cliente através da adaptação.
Alternativa C — ✅ Correta ⟵ GABARITO
A equipe ágil, com o Product Owner, avalia o impacto da mudança, reprioriza o backlog e decide se e quando incorporá-la. Isso está alinhado ao valor "colaboração do cliente" e ao princípio de "mudanças de escopo são bem-vindas".
Alternativa D — ❌ Incorreta
Cobrar taxa adicional e incluir sem discussão não é uma prática ágil. A transparência, a negociação e a adaptação baseada em valor são essenciais; a simples inclusão sem avaliação fere a auto-organização da equipe e o papel do Product Owner.
Alternativa E — ❌ Incorreta
Suspender o projeto até que todas as mudanças sejam definidas é o oposto da agilidade, que trabalha com iterações curtas e entrega incremental. A equipe deve continuar entregando valor enquanto lida com as mudanças.
NÃO CAIA NESSA!
A banca pode confundir com a alternativa D (cobrança adicional) por parecer "prática de mercado", mas a agilidade valoriza a transparência e a priorização baseada em valor, não em taxas. A alternativa B (recusar) também é um distrator comum para quem ainda associa desenvolvimento a planos rígidos.
PEGA ESSA DICA!
Lembre-se sempre dos quatro valores do Manifesto Ágil, especialmente "Responder a mudanças mais que seguir um plano". O Product Owner é o guardião do backlog e o ponto focal para mudanças de escopo.