Questão de Engenharia de Software — Geral — FCC 2024
Engenharia de Software›Geral
Código
fc147291
Banca
FCC
Órgão
TRT 20
Ano
2024
Cargo
TJ TRT20
equipe de um Tribunal está debatendo a adequação de metodologias ágeis, considerando a natureza dos diversos projetos institucionais. Um Técnico de Ti afirmou que a metodologia
A Scrum é melhor em projetos que requerem a auto-organização da equipe e iterações regulares, permitindo que os desenvolvedores façam ajustes nas prioridades e no escopo do projeto a cada Sprint. Além disso, o Scrum se concentra na implementação de um ciclo de desenvolvimento linear e sequencial, mais próximo da realidade.
BXP deve ser escolhida na maior parte dos projetos, pois permite um planejamento detalhado a longo prazo, com entregas frequentes em sprints de 3-4 semanas ou um mês. Além disso, como a colaboração com o cliente é fundamental, essa metodologia incentiva reuniões de revisão mensais com as partes interessadas.
CXP é mais indicada quando há alta necessidade de refatoração continua e testes automatizados, o que permite melhor controle da qualidade do código durante o desenvolvimento.
DXP deve ser escolhida quando o time deseja trabalhar sem sprints fixos e priorizar documentações mais detalhadas e extensas. Além disso, projetos com baixa variabilidade de requisitos se beneficiam com as práticas XP.
E Scrum deve ser preferida em projetos em que há necessidade de ciclos curtos com entregas de incremento de software a cada semana, garantindo uma integração continua do produto.
Revelar gabarito e comentário▾
GabaritoC — XP é mais indicada quando há alta necessidade de refatoração continua e testes automatizados, o que permite melhor controle da qualidade do código durante o desenvolvimento.
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”.
Metodologias Ágeis: Scrum e XP
Gabarito: letra C. A alternativa correta descreve com precisão a Extreme Programming (XP): uma metodologia ágil que valoriza a refatoração contínua e os testes automatizados como práticas centrais para garantir a qualidade do código. As demais alternativas distorcem características fundamentais do Scrum e do XP, atribuindo-lhes práticas de metodologias tradicionais ou invertendo seus princípios.
A Extreme Programming (XP) é uma metodologia ágil criada por Kent Beck em 1996, focada em práticas de engenharia de software levadas ao extremo. Enquanto o Scrum é um framework de gerenciamento de projetos, o XP concentra-se nas técnicas de desenvolvimento. Seu objetivo é melhorar a qualidade do software por meio de testes frequentes, colaboração contínua e feedback rápido, adaptando-se rapidamente a mudanças de requisitos, inclusive nas fases finais do projeto.
Os cinco valores do XP são: Comunicação, Simplicidade, Feedback, Coragem e Respeito. Esses valores se traduzem em 12 práticas fundamentais, entre as quais se destacam a Programação em Pares, o Desenvolvimento Orientado a Testes (TDD), a Refatoração, a Integração Contínua e os Pequenos Releases. A refatoração contínua é a prática de melhorar constantemente o código sem alterar seu comportamento externo, enquanto os testes automatizados garantem que as mudanças não introduzam erros. Essas práticas são essenciais para o controle de qualidade no XP.
O Scrum, por sua vez, é um framework ágil para gerenciamento de projetos complexos, baseado em iterações de duração fixa chamadas Sprints. Ele se estrutura em papéis (Product Owner, Scrum Master e Desenvolvedores), eventos (Sprint, Daily, Review, Retrospectiva) e artefatos (Product Backlog, Sprint Backlog, Incremento). O Scrum é iterativo e incremental, mas não prescreve práticas técnicas específicas como TDD ou refatoração — essas são características do XP. O foco do Scrum está na gestão do processo, não nas técnicas de engenharia.
A pegadinha desta questão está em atribuir ao Scrum características do XP e vice-versa, ou em descrever metodologias ágeis com práticas de modelos tradicionais (como ciclo linear e sequencial, documentação extensa e planejamento detalhado de longo prazo). A banca explora a confusão entre os dois frameworks ágeis mais cobrados em concursos. Para acertar, é preciso ter clareza sobre o foco de cada um: Scrum = gestão; XP = técnica.
Guarde a fronteira decisiva: Scrum gerencia o processo com Sprints; XP define práticas técnicas de qualidade (testes, refatoração, programação em pares). É exatamente nessa distinção que as alternativas se dividem.
Critério
Scrum
XP (Extreme Programming)
Foco principal
Gerenciamento do processo
Práticas técnicas de engenharia
Estrutura de iterações
Sprints de duração fixa (geralmente 1–4 semanas)
Iterações curtas, sem rigidez de Sprints fixos
Práticas centrais
Papéis, eventos e artefatos (Product Backlog, Sprint Backlog, Incremento)
Refatoração contínua, testes automatizados (TDD), programação em pares, integração contínua
Documentação
Ênfase no produto funcional, documentação enxuta
Código-fonte como principal documentação
Adequação
Projetos complexos com equipes auto-organizadas
Ambientes com alta variabilidade de requisitos e necessidade de qualidade técnica
Metodologias ágeis: Scrum (gestão) (Sprints de duração fixa, Papéis, eventos e artefatos, Equipe auto-organizada); XP (técnica) (Refatoração contínua, Testes automatizados (TDD), Programação em pares, Integração contínua); Modelo cascata (tradicional) (Ciclo linear e sequencial, Documentação extensa)
Alternativa A — ❌ Incorreta
A alternativa começa corretamente ao afirmar que o Scrum é adequado para equipes auto-organizadas com iterações regulares, mas erra ao dizer que o Scrum se concentra em um ciclo de desenvolvimento linear e sequencial. O Scrum é iterativo e incremental, não linear. O ciclo linear e sequencial é característica do modelo em cascata (waterfall), uma metodologia tradicional. A banca mistura conceitos de metodologias ágeis com o modelo cascata para confundir o candidato.
Alternativa B — ❌ Incorreta
A alternativa atribui ao XP características que não lhe pertencem. O XP não é indicado para a "maior parte dos projetos" nem se baseia em "planejamento detalhado a longo prazo" — pelo contrário, o XP valoriza a adaptação a mudanças e o feedback rápido. Além disso, o XP não trabalha com Sprints fixos de 3-4 semanas; essa é uma característica do Scrum. O XP utiliza pequenos releases e iterações curtas, sem a rigidez de Sprints definidos. A menção a "reuniões de revisão mensais" também não corresponde a uma prática específica do XP.
Alternativa C — ✅ Correta ⟵ GABARITO
A alternativa descreve com precisão a Extreme Programming (XP). A refatoração contínua e os testes automatizados são, de fato, práticas centrais do XP, que visam melhorar a qualidade do código durante o desenvolvimento. A refatoração permite melhorar a estrutura interna do código sem alterar seu comportamento, enquanto os testes automatizados (como o TDD) garantem que as mudanças não quebrem funcionalidades existentes. Essas práticas são fundamentais para o controle de qualidade no XP, que prioriza a simplicidade e o feedback constante.
Alternativa D — ❌ Incorreta
A alternativa inverte completamente as características do XP. O XP não trabalha "sem sprints fixos" — na verdade, ele utiliza iterações curtas e pequenos releases. Além disso, o XP prioriza o código-fonte como documentação, em vez de "documentações mais detalhadas e extensas". A afirmação de que "projetos com baixa variabilidade de requisitos se beneficiam com as práticas XP" também é incorreta, pois o XP é especialmente adequado para ambientes de alta variabilidade de requisitos, onde a adaptação rápida é essencial.
Alternativa E — ❌ Incorreta
A alternativa atribui ao Scrum características que não são exclusivas ou definidoras. Embora o Scrum utilize ciclos curtos (Sprints) e entregue incrementos de software, a afirmação de que ele garante "integração contínua do produto" é imprecisa. A integração contínua é uma prática do XP, não do Scrum. O Scrum foca na gestão do processo e na entrega de incrementos ao final de cada Sprint, mas não prescreve a prática técnica de integração contínua. Além disso, a duração dos Sprints é definida pela equipe (geralmente 1 a 4 semanas), mas a "entrega a cada semana" não é uma regra do Scrum.