Princípios do Agile Project Management e o Scrum
Gabarito: letra C. A alternativa C reflete corretamente os princípios ágeis ao propor a organização do trabalho em partes menores e priorizadas, com revisões frequentes dos resultados para ajustar as entregas — exatamente o que o Scrum preconiza com seus ciclos curtos (Sprints) e eventos de inspeção e adaptação. As demais alternativas distorcem conceitos fundamentais, como a duração das iterações, a rigidez do ciclo de vida, a interação com o usuário e o papel do Scrum como framework.
O Agile Project Management, e especificamente o Scrum, é um framework para gerenciar e desenvolver produtos complexos, baseado na colaboração, adaptação e entrega incremental. Diferente dos modelos tradicionais (como o cascata), que seguem um plano rígido e sequencial, o Scrum adota uma abordagem iterativa e incremental, fundamentada no empirismo — ou seja, o conhecimento vem da experiência e da tomada de decisões baseadas no que é conhecido. Isso se traduz em ciclos de trabalho curtos e frequentes, chamados Sprints, nos quais a equipe entrega um incremento do produto e, ao final de cada ciclo, revisa o que foi feito para ajustar o que vem a seguir.
Os três pilares do Scrum — Transparência, Inspeção e Adaptação — são a base desse processo. A transparência garante que todos tenham visibilidade sobre o progresso e os problemas; a inspeção exige que os artefatos e o progresso sejam revisados com frequência para detectar variações; e a adaptação determina que, se algo se desviar do esperado, o processo ou o produto sejam ajustados o mais rápido possível. É exatamente essa dinâmica de "revisar e ajustar" que a alternativa C descreve: organizar o trabalho em partes menores e priorizadas, revisando resultados em intervalos frequentes para ajustar as entregas conforme a necessidade operacional.
Na prática, imagine o projeto do sistema integrado de informações para metrô e ônibus. Em vez de planejar todas as funcionalidades de uma vez e entregar tudo no final, a equipe Scrum divide o trabalho em Sprints de, por exemplo, duas a quatro semanas. Em cada Sprint, seleciona-se um conjunto de funcionalidades priorizadas (do Product Backlog), desenvolve-se, testa-se e entrega-se um incremento utilizável. Ao final do Sprint, na Revisão da Sprint, os stakeholders (incluindo usuários do transporte) inspecionam o incremento e dão feedback, que será usado para adaptar o Product Backlog e planejar o próximo Sprint. Esse ciclo contínuo de inspeção e adaptação é o coração do Agile.
A pegadinha que a banca explora nesta questão é a tentação de associar o Agile a práticas rígidas ou a um modelo único de gestão. O Scrum, por exemplo, não é um processo prescritivo — ele não descreve exatamente o que fazer em cada situação, mas fornece um conjunto de valores, princípios e práticas que podem ser adaptados. Além disso, o Scrum não é um método completo de gestão de projetos no sentido tradicional; ele foca no gerenciamento do desenvolvimento iterativo, e não em todas as áreas de conhecimento do PMBOK (como custos, riscos, aquisições etc.). A alternativa E, que sugere "ampliar" o Scrum para um modelo completo de gestão, contraria essa natureza.
Outro ponto crucial é a interação com o usuário. No Agile, a colaboração com o cliente é contínua e frequente, mas não significa "aumentar as interações até que todas as funcionalidades estejam concluídas" — pelo contrário, a interação é constante e visa justamente reduzir retrabalho, mas não eliminar revisões e adaptações, que são inerentes ao processo. A alternativa D erra ao sugerir que as interações devem ser intensificadas apenas até a conclusão, buscando reduzir revisões — isso vai contra o princípio de adaptação contínua.
Por fim, a duração das iterações no Scrum não é fixa em 40 dias. O Guia do Scrum recomenda Sprints de até um mês, mas a duração é definida pela equipe e pode variar (geralmente de 1 a 4 semanas). A alternativa A, ao fixar 40 dias como "principal critério", está errada. E a alternativa B, que defende seguir um modelo único de ciclo de vida escolhido no início, contraria o princípio ágil de responder a mudanças — o Manifesto Ágil valoriza "responder a mudanças mais que seguir um plano".
Guarde a fronteira entre o que é ágil (iterativo, incremental, adaptativo, colaborativo) e o que é tradicional (sequencial, rígido, planejado de antemão): é exatamente nela que as alternativas se dividem.
Alternativa A — ❌ Incorreta
A alternativa afirma que a divisão em ciclos curtos de 40 dias é o principal critério para implantar o projeto de forma ágil. O erro está em fixar uma duração específica e tratá-la como critério central. No Scrum, as Sprints têm duração time-boxed (geralmente de 1 a 4 semanas, com recomendação de no máximo um mês), mas a duração é definida pela equipe com base no contexto do projeto, não um número fixo de 40 dias. Além disso, o principal critério do Agile não é a duração do ciclo, mas a entrega incremental de valor e a adaptação contínua. A alternativa confunde o meio (ciclos curtos) com o fim (entregar valor e se adaptar).
Alternativa B — ❌ Incorreta
A alternativa defende seguir um modelo único de ciclo de vida escolhido no início do projeto, tratando qualquer mudança de abordagem como um fator que ajuda na manutenção do cronograma. Isso contraria frontalmente o Manifesto Ágil, que valoriza "responder a mudanças mais que seguir um plano". O Agile é, por definição, adaptativo: a equipe deve estar aberta a mudanças de requisitos, de abordagem e de processo ao longo do projeto. Tratar mudanças como algo que "ajuda na manutenção do cronograma" é um contrassenso — no Agile, mudanças são bem-vindas e podem alterar o cronograma, mas o foco é entregar valor, não manter um cronograma rígido. A alternativa descreve uma postura tradicional, não ágil.
Alternativa C — ✅ Correta ⟵ GABARITO
A alternativa C está correta porque descreve com precisão os princípios do Agile Project Management: organizar o trabalho em partes menores e priorizadas (incremental), revisando resultados em intervalos frequentes (iterativo) para ajustar as entregas conforme a necessidade operacional (adaptativo). Isso corresponde exatamente ao ciclo de Sprints do Scrum, com seus eventos de planejamento, revisão e retrospectiva, e aos pilares de Transparência, Inspeção e Adaptação. A alternativa captura a essência do empirismo: aprender com a experiência e ajustar o curso rapidamente.
Alternativa D — ❌ Incorreta
A alternativa sugere aumentar as interações com os usuários até que todas as funcionalidades estejam concluídas, buscando reduzir revisões e adaptações durante o desenvolvimento. Isso é o oposto do Agile. No Scrum, a interação com o usuário (ou Product Owner) é contínua e frequente, não apenas até a conclusão. Além disso, revisões e adaptações são inerentes ao processo ágil — a cada Sprint, o incremento é revisado e o backlog é adaptado. Reduzir revisões e adaptações seria abandonar o pilar da Inspeção e da Adaptação. A alternativa descreve uma abordagem mais próxima do modelo tradicional, onde o usuário é consultado no início e no final, e não ao longo do desenvolvimento.
Alternativa E — ❌ Incorreta
A alternativa propõe adaptar o Scrum para transformá-lo em um modelo completo de gestão de projetos, ampliando suas funções para além do propósito original. O Scrum é um framework focado no gerenciamento do desenvolvimento iterativo e incremental de produtos, e não um método completo de gestão de projetos que cubra todas as áreas do PMBOK (escopo, tempo, custo, qualidade, riscos, aquisições, etc.). O Guia do Scrum é claro: o Scrum é um framework para "gerenciar e desenvolver produtos complexos", e não um processo prescritivo para todas as áreas de gestão. Ampliá-lo para além do propósito original seria desvirtuá-lo. A alternativa confunde o escopo do Scrum com o de uma metodologia de gestão de projetos abrangente.
Gabarito: letra C