Questão de Engenharia de Software — Processos de Software — FGV 2025
Engenharia de Software›Processos de Software
Código
fg104553
Banca
FGV
Órgão
AL-AM
Ano
2025
Nível
Superior
Cargo
Analista Legislativo - Analista de Sistema
A equipe de desenvolvimento do sistema de gestão de documentos adotou o Kanban para gerenciar seu fluxo de trabalho. Em seu quadro visual, a coluna Em Desenvolvimento possui um limite de WIP (Work in Progress) de 3 tarefas. O objetivo dessa limitação é aumentar a taxa de entrega e reduzir o tempo de ciclo.O principal efeito direto da limitação de WIP, como 3 tarefas em desenvolvimento, no fluxo de trabalho de uma equipe Kanban será
Adiminuir a necessidade de reuniões diárias (Daily Scrum), aumentando o tempo de programação.
Baumentar o número total de tarefas iniciadas simultaneamente, promovendo a produtividade individual.
Cforçar a equipe a concentrar-se na finalização do trabalho, expondo gargalos e reduzindo o Context Switching.
Daumentar o inventário de trabalho em cada etapa, garantindo que os desenvolvedores nunca fiquem ociosos.
Etornar o Product Owner responsável por gerenciar a fila de itens prontos para serem puxados.
Revelar gabarito e comentário▾
GabaritoC — forçar a equipe a concentrar-se na finalização do trabalho, expondo gargalos e reduzindo o Context Switching.
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”.
Kanban: Efeitos da Limitação de WIP
Gabarito: letra C. A limitação de Work In Progress (WIP) é um princípio fundamental do Kanban. Ao fixar um limite de tarefas simultâneas (ex.: 3 em desenvolvimento), a equipe é forçada a concentrar esforços na conclusão das atividades em andamento antes de iniciar novas. Isso expõe gargalos no fluxo e reduz as trocas de contexto (context switching), aumentando a eficiência e reduzindo o tempo de ciclo.
Alternativa
Efeito Direto da Limitação de WIP (3 tarefas)
Relação com o Kanban
Correção
A
Diminuir necessidade de reuniões diárias (Daily Scrum)
Não há relação direta; Kanban não elimina reuniões
❌ Incorreta
B
Aumentar tarefas iniciadas simultaneamente
Limite de WIP reduz tarefas em andamento
❌ Incorreta
C
Forçar foco na finalização, expor gargalos e reduzir Context Switching
Princípio fundamental do Kanban
✅ Correta
D
Aumentar inventário de trabalho em cada etapa
Limite de WIP reduz inventário (WIP)
❌ Incorreta
E
Tornar Product Owner responsável pela fila de itens prontos
Product Owner é papel do Scrum, não obrigatório no Kanban
❌ Incorreta
1Limite de tarefas simultâneas
2Foco na finalização
3Exposição de gargalos
4Redução de context switching
5Menor tempo de ciclo
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Afirma que a limitação de WIP diminui a necessidade de reuniões diárias (Daily Scrum), aumentando o tempo de programação. O Kanban não elimina reuniões; embora não prescreva Daily Scrums (que são do Scrum), a limitação de WIP não tem relação direta com a quantidade de reuniões. O objetivo é otimizar o fluxo, não aumentar tempo de programação.
Alternativa B — ❌ Incorreta
Diz que o limite de WIP aumenta o número total de tarefas iniciadas simultaneamente. Na verdade, a limitação de WIP reduz o número de tarefas em andamento, justamente para evitar sobrecarga e melhorar o foco. Promover produtividade individual não é o efeito direto; o efeito é no fluxo da equipe.
Alternativa C — ✅ Correta ⟵ GABARITO
A limitação de WIP obriga a equipe a finalizar o trabalho em andamento antes de puxar novas tarefas. Isso expõe gargalos (etapas onde o trabalho acumula) e reduz o context switching, pois os membros se dedicam a menos tarefas por vez. Consequentemente, o tempo de ciclo diminui e a taxa de entrega aumenta.
Alternativa D — ❌ Incorreta
Afirma que o limite de WIP aumenta o inventário de trabalho em cada etapa. Na verdade, ele reduz o inventário (WIP) para evitar acúmulo e desperdícios. A ideia de garantir que desenvolvedores nunca fiquem ociosos é contrária ao Kanban, que busca um fluxo puxado e balanceado.
Alternativa E — ❌ Incorreta
Atribui ao Product Owner a responsabilidade de gerenciar a fila de itens prontos para serem puxados. No Kanban, a fila (backlog) é gerenciada pelo time ou pelo cliente, mas o Product Owner é um papel do Scrum. No Kanban, não há um papel obrigatório de Product Owner; a gestão da fila pode ser colaborativa. Além disso, a limitação de WIP não torna o PO responsável por isso.