Metodologias Ágeis: Scrum e Estimativas de Software
Gabarito: letra B. A alternativa correta combina o Scrum como framework de gerenciamento — com suas cerimônias, artefatos (Product Backlog, Sprint Backlog, Increment) e entregas incrementais — com o uso de Análise de Pontos de Função (APF) como técnica de estimativa de esforço, que apoia o planejamento das iterações. As demais alternativas distorcem conceitos de metodologias ágeis e tradicionais, misturando características incompatíveis.
O cenário descrito no enunciado é o clássico de um projeto que exige adaptabilidade (requisitos em constante evolução), interações frequentes com usuários e entregas incrementais. Essas são as características centrais das metodologias ágeis, que priorizam a resposta rápida a mudanças em vez de um planejamento rígido e antecipado. O Scrum é o framework ágil mais difundido para gerenciar esse tipo de desenvolvimento, organizando o trabalho em ciclos chamados Sprints, com papéis bem definidos (Product Owner, Scrum Master e Time de Desenvolvimento), eventos (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) e artefatos (Product Backlog, Sprint Backlog e Increment).
A Análise de Pontos de Função, por sua vez, é uma técnica de medição do tamanho funcional do software, baseada na visão do usuário. Ela conta as funcionalidades que o sistema oferece, classificando-as em cinco tipos: Entradas Externas (EE), Saídas Externas (SE), Consultas Externas (CE), Arquivos Lógicos Internos (ALI) e Arquivos de Interface Externa (AIE). Essa medição é independente da tecnologia e da linguagem de programação, o que a torna útil para estimar esforço, custo e prazo antes do desenvolvimento. No contexto do Scrum, a APF pode ser aplicada para dimensionar os itens do Product Backlog e embasar as estimativas de esforço, auxiliando o planejamento das Sprints.
A banca explora a confusão entre métodos de gestão (Scrum) e técnicas de estimativa (APF), além de distorcer as características de outras metodologias como XP, Waterfall e RUP. A pegadinha central é apresentar alternativas que misturam conceitos de forma incoerente, como usar APF com Contagem de Pontos de Caso de Uso (que são técnicas distintas) ou descrever o Waterfall com características ágeis. A alternativa correta é a única que apresenta uma combinação coerente e tecnicamente válida.
Guarde a distinção fundamental: Scrum é um framework de gerenciamento (como organizar o trabalho), enquanto APF é uma técnica de medição (como dimensionar o software). A alternativa B é a única que integra essas duas abordagens de forma correta, atendendo à necessidade de adaptabilidade, previsibilidade e estimativa descrita no enunciado.
Critério | Scrum (framework de gerenciamento) | Análise de Pontos de Função (técnica de estimativa) |
|---|
Natureza | Framework ágil para organizar o trabalho | Técnica de medição do tamanho funcional do software |
Artefatos/Elementos | Product Backlog, Sprint Backlog, Increment | Entradas Externas, Saídas Externas, Consultas, ALI, AIE |
Função principal | Gerenciar o desenvolvimento com entregas incrementais e adaptabilidade | Estimar esforço, custo e prazo com base na visão do usuário |
Aplicação no contexto | Atende à necessidade de requisitos em evolução e interações frequentes | Apoia o planejamento das iterações (Sprints) com estimativas objetivas |
Alternativa A — ❌ Incorreta
Esta alternativa mistura duas técnicas de estimativa distintas: a Análise de Pontos de Função e a Contagem de Pontos de Caso de Uso. A APF avalia a complexidade funcional considerando entradas externas, saídas externas, consultas, arquivos lógicos internos e arquivos de interface externa — mas a Contagem de Pontos de Caso de Uso é uma técnica separada, baseada em casos de uso, não em pontos de função. Além disso, a alternativa não menciona o Scrum, que é o framework mais adequado para o cenário de requisitos em constante evolução e entregas incrementais descrito no enunciado. O erro está em apresentar uma técnica de estimativa isolada, sem o framework de gerenciamento que atenderia à necessidade de adaptabilidade e interações frequentes.
Alternativa B — ✅ Correta ⟵ GABARITO
Esta alternativa descreve corretamente o uso do Scrum como framework de gerenciamento, com suas cerimônias (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) e artefatos (Product Backlog, Sprint Backlog e Increment), assegurando a entrega incremental. Além disso, integra a Análise de Pontos de Função como técnica para embasar estimativas de esforço e apoiar o planejamento das iterações. Essa combinação atende exatamente ao cenário descrito: requisitos em constante evolução (gerenciados pelo Product Backlog), interações frequentes com usuários (cerimônias e revisões) e entregas incrementais (Sprints), com capacidade de estimar esforço (APF). É a única alternativa que apresenta uma integração coerente e tecnicamente válida entre gestão ágil e estimativa de software.
Alternativa C — ❌ Incorreta
Esta alternativa descreve o modelo Waterfall (cascata) com características que são exatamente o oposto do que ele representa. O Waterfall é um modelo sequencial e linear, onde cada fase só começa após o término da anterior, com validação completa dos requisitos na primeira fase. Ele não utiliza ciclos curtos, reuniões diárias ou entregas parciais — essas são características de metodologias ágeis. A alternativa inverte completamente a natureza do modelo, apresentando-o como se fosse ágil, o que é um erro conceitual grave.
Alternativa D — ❌ Incorreta
Esta alternativa descreve o Extreme Programming (XP) com características que o contradizem. O XP é uma metodologia ágil que prioriza o código-fonte como principal documentação, com foco em comunicação, simplicidade, feedback, coragem e respeito. Ele não exige documentação formal extensa nem modelagem UML detalhada antes dos ciclos — pelo contrário, valoriza a simplicidade e a resposta rápida a mudanças. A alternativa atribui ao XP características de metodologias tradicionais, como documentação formal e modelagem antecipada, o que é incorreto.
Alternativa E — ❌ Incorreta
Esta alternativa descreve o Rational Unified Process (RUP) de forma totalmente distorcida. O RUP é um processo iterativo e incremental, mas que valoriza a documentação e a modelagem (especialmente com UML), sendo um processo disciplinado e bem definido. Ele não realiza entregas contínuas sem documentação formal nem prioriza a simplicidade do backlog — essas são características de metodologias ágeis como Scrum e XP. A alternativa inverte completamente a natureza do RUP, apresentando-o como se fosse uma metodologia ágil simplificada, o que é um erro conceitual.
Gabarito: letra B