Questão de Engenharia de Software — Processos de Software - Desenvolvimento Ágil — FGV 2025
Engenharia de Software›Processos de Software - Desenvolvimento Ágil
Código
fg105420
Banca
FGV
Órgão
AL-AM
Ano
2025
Nível
Superior
Cargo
Analista Legislativo - Programador
Durante o evento de Sprint Planning do projeto de e-Legislação, o Time de Desenvolvimento estima o esforço dos itens do Product Backlog. O Product Owner (PO) questiona uma estimativa alta, alegando que o requisito é simples. O Time insiste na estimativa devido à alta incerteza técnica de integração com um sistema legado.Assinale qual das seguintes ações deve resolver a incerteza técnica na Sprint Planing, de acordo com as práticas ágeis.
AO PO deve simplesmente aceitar a estimativa, pois o Time é auto-organizado.
BO Scrum Master deve redefinir a Meta da Sprint para um objetivo mais fácil.
CO Time deve transformar a incerteza em uma Spike a ser incluída no Sprint Backlog.
DA incerteza deve ser resolvida pelo gerente de projetos após a Sprint.
EO Time deve reduzir a estimativa para forçar o desenvolvimento.
Revelar gabarito e comentário▾
GabaritoC — O Time deve transformar a incerteza em uma Spike a ser incluída no Sprint 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”.
Sprint Planning: Incerteza Técnica e Spikes
Gabarito: letra C. No Scrum, quando o Time de Desenvolvimento identifica alta incerteza técnica em uma história, a prática ágil é transformar essa incerteza em uma Spike — uma atividade de curta duração focada em pesquisa, experimentação ou prototipação para obter conhecimento — e adicioná-la ao Sprint Backlog. Isso permite que a equipe reduza riscos e estime com mais precisão antes de comprometer o trabalho.
Ação
Descrição
Correta?
Justificativa
PO aceitar a estimativa
O Product Owner simplesmente aceita a estimativa do Time
❌
A auto-organização não elimina a necessidade de tratar riscos técnicos; a incerteza precisa ser investigada
Scrum Master redefinir Meta
O Scrum Master altera a Meta da Sprint para algo mais fácil
❌
O Scrum Master facilita, não redefine metas; fugir do problema não resolve a incerteza
Time criar uma Spike
Transformar a incerteza em atividade de pesquisa no Sprint Backlog
✅
Prática ágil padrão para explorar riscos técnicos e obter conhecimento antes de estimar
Incerteza resolvida após Sprint
Postergar a resolução para depois da Sprint
❌
Compromete o planejamento; o papel de gerente de projetos não existe no Scrum
Time reduzir estimativa
Forçar redução artificial da estimativa
❌
Viola transparência e confiança; pode causar falhas e retrabalho
1Identificar incerteza técnica
2Criar Spike no Sprint Backlog
3Executar pesquisa/experimento
4Obter conhecimento
5Estimar com precisão
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Embora o Time seja auto-organizado, o PO não deve simplesmente aceitar a estimativa sem ação. A incerteza precisa ser tratada, e o PO pode negociar, mas a solução não é ignorar a preocupação. A auto-organização não elimina a necessidade de lidar com riscos técnicos.
Alternativa B — ❌ Incorreta
O Scrum Master não redefine a Meta da Sprint; ele facilita o processo. Mudar a meta para algo mais fácil não resolve a incerteza técnica — apenas foge do problema. A meta deve ser realista, e a incerteza deve ser investigada.
Alternativa C — ✅ Correta ⟵ GABARITO
Conforme práticas ágeis, especialmente do Extreme Programming (XP) mas também adotada no Scrum, a criação de uma Spike é a abordagem padrão para lidar com incertezas técnicas. A Spike é uma atividade com tempo limitado para explorar a integração com o sistema legado e gerar conhecimento que permita uma estimativa mais precisa. Ela é incluída no Sprint Backlog como um item de pesquisa.
Alternativa D — ❌ Incorreta
A incerteza não deve ser postergada para após a Sprint. A Sprint Planning é o momento de planejar o trabalho; deixar a incerteza para depois compromete o planejamento e a entrega de valor. O gerente de projetos não existe no Scrum; o papel é do Time e do PO.
Alternativa E — ❌ Incorreta
Reduzir a estimativa artificialmente para forçar o desenvolvimento vai contra os princípios ágeis de transparência e confiança. A equipe deve estimar com base na realidade; forçar a redução pode levar a falhas e retrabalho.
NÃO CAIA NESSA!
A banca testa o conhecimento sobre como lidar com incertezas em reuniões de planejamento. Muitos candidatos podem marcar a alternativa A, pensando que o time auto-organizado tem a palavra final, mas a prática ágil exige ação concreta: criar uma Spike para investigar a incerteza. O erro é confundir auto-organização com ausência de gestão de riscos.