Curso 214614 Aula 03 Metodologias Ágeis

Aula 03
MP-MG (Analista do Ministério Público -

Área Análise e Programação) Engenharia
de Software - 2022 (Pré-Edital)
Autor:
Diego Carvalho, Equipe
Informática e TI, Fernando
Pedrosa Lopes
09 de Setembro de 2022
81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

Diego Carvalho, Equipe Informática e TI, Fernando Pedrosa Lopes
Aula 03
Índice
1) Metodologias Ágeis
..............................................................................................................................................................................................3
2) Metodologias Ágeis - Agilidade x Velocidade

..............................................................................................................................................................................................
11
3) Metodologias Ágeis - Princípios Ágeis

..............................................................................................................................................................................................
13
4) Metodologias Ágeis - Método Ágil x Método Lean

..............................................................................................................................................................................................
17
5) Resumo - Metodologias Ágeis

..............................................................................................................................................................................................
19
6) Questões Comentadas - Metodologias Ágeis - Multibancas

..............................................................................................................................................................................................
23
7) Lista de Questões - Metodologias Ágeis - Multibancas

..............................................................................................................................................................................................
92
2
MP-MG (Analista do Ministério Público - Área Análise e Programação) Engenharia de Software - 2022 (Pré-Edital)
www.estrategiaconcursos.com.br 111

Aula 03
APRESENTAÇÃO
O assunto da aula de hoje é: Metodologias Ágeis! Vamos ver agora um novo paradigma de
desenvolvimento de software bem interessante, muda bastante coisa em relação às metodologias
tradicionais – é bem mais moderno. Esse é um assunto que sempre corre o risco de cair ao menos
uma questãozinha na prova porque é o paradigma de desenvolvimento mais utilizado atualmente.
Então, venham na fé que vocês vão gostar :)
PROFESSOR DIEGO CARVALHO - www.instagram.com/professordiegocarvalho
Galera, todos os tópicos da aula possuem Faixas de Incidência, que indicam se o assunto cai
muito ou pouco em prova. Diego, se cai pouco para que colocar em aula? Cair pouco não significa
que não cairá justamente na sua prova! A ideia aqui é: se você está com pouco tempo e precisa ver
somente aquilo que cai mais, você pode filtrar pelas incidências média, alta e altíssima; se você tem
tempo sobrando e quer ver tudo, vejam também as incidências baixas e baixíssimas. Fechado?
INCIDÊNCIA EM PROVA: baixíssima

INCIDÊNCIA EM PROVA: baixa
INCIDÊNCIA EM PROVA: média
INCIDÊNCIA EM PROVA: ALTA
INCIDÊNCIA EM PROVA: Altíssima
Além disso, essas faixas não são por banca – é baseado tanto na quantidade de vezes que caiu em
prova independentemente da banca e também em minhas avaliações sobre cada assunto...
3

Aula 03
4

Aula 03
==f219==
5

Aula 03
METODOLOGIAS ÁGEIS
Conceitos Básicos
Em meados de 2001, 17 especialistas proeminentes da área de desenvolvimento de software se

reuniram em um resort em Utah (foto acima) para conversar, esquiar, discutir e encontrar um
terreno comum para suas ideias sobre métodos de desenvolvimento de software. Essa galera
pegou uma mesa, se sentaram, tomaram umas cervejas e começaram a desabafar sobre seus
projetos de desenvolvimento de software que estavam falhando por diversos motivos.
Os 17 Engenheiros de Software
Foi quando um deles levantou a mão e disse que usou o Modelo em Cascata e o projeto estourou
o orçamento; o outro disse que isso também já aconteceu com ele, mas recentemente um projeto
falhou porque estourou o prazo; aí outro se compadeceu e disse que os projetos dele viviam
falhando porque ele não conseguia construir todo o escopo que foi pedido pelos usuários do
sistema. E assim foi...
Eles foram compartilhando suas experiências ruins com o uso das metodologias tradicionais,
mas depois cada um desses caras foi dizendo: “para remediar isso, agora eu uso iterações”; aí o outro
disse que não usa mais tanta documentação como antigamente; aí o outro levantou a mão e falou
que não faz mais tanto planejamento; e assim por diante. Então, no decorrer da reunião, foi sendo
criado um consenso entre os participantes.
6

Aula 03
Foi aí que alguns acharam que era o momento de formalizar e elevar aquela reunião em um patamar
maior. Eles decidiram escrever um documento que serviria de grito de guerra contra os
processos tradicionais de desenvolvimento de software que vigoravam naquela época. Para
isso, eles pensaram: “Nós precisamos de um nome que expresse bem o significado dessa reunião e das
nossas ideias comuns”.
Na discussão, eles decidiram que a palavra “leve” não expressava tão bem o que eles queriam dizer
e decidiram trocar pela palavra “ágil”, que captava melhor a abordagem que eles estavam
propondo. Em um segundo momento, eles começaram a escrever um documento bem pequeno,
bem objetivo, bem claro e que conteria as crenças, valores e princípios daqueles dezessete
engenheiros de software.
Foi então que surgiu o documento chamado Manifesto Ágil Para Desenvolvimento De Software,
que definia bem o que era ágil, o que não era ágil e o que essas pessoas defendiam. Além disso, eles
passaram a se autodenominar como Aliança Ágil, que era um grupo de pensadores independentes
sobre desenvolvimento de software e muitas vezes concorrentes entre si, mas que concordaram
em um documento chamado Manifesto Ágil.
Isso se tornou uma organização sem fins lucrativos que procura promover conhecimento e
discussões sobre os vários métodos ágeis que existem hoje em dia. A partir daí, galera... esses caras
– que eram os líderes do movimento ágil – começaram a escrever artigos, fazer palestras e
disseminar esse novo paradigma. Como vocês sabem, esse negócio explodiu e hoje a imensa
maioria dos projetos de software são feitos utilizando metodologias ágeis.
Bem, para aqueles que não conhecem, nós trazemos a seguir a imagem original do próprio
Manifesto Ágil com seus fundamentos. Vejamos...
Notem que a coluna da esquerda representa os anseios das metodologias ágeis, enquanto a coluna
da direita representa o que as metodologias tradicionais costumavam executar. Agora prestem
7

Aula 03
atenção: o manifesto ágil afirma que, mesmo havendo valor nos itens à direita, valorizam-se
mais os itens à esquerda. Uma pegadinha comum de prova é dizer que os métodos ágeis não
possuem documentação. Isso está correto?
Não, isso evidentemente está errado! O manifesto ágil preconiza que se valorize mais software em
funcionamento do que documentação abrangente, logo isso não significa que não tenha
documentação. E isso serve para os outros três fundamentos, isto é, os itens da direita tem o
seu valor, por outro lado se valoriza mais os itens da esquerda. Tudo certo até aqui? Agora vamos
detalhar um pouco mais...
Por que valorizar mais indivíduos e suas interações do que processos e ferramentas?
Porque, em última instância, quem gera produtos e serviços são os indivíduos, que possuem
características únicas como talento e habilidade. Pessoal, programar é uma atividade humana e,
como tal, depende de questões humanas para que obtenha sucesso. Jim Highsmith, um dos
signatários do manifesto ágil, afirma que as habilidades, as personalidades e as peculiaridades de
cada indivíduo são críticas para o sucesso dos projetos.
Ele diz também que pessoas muitas vezes são desorganizadas e difíceis de entender, por outro lado
elas também são inovadoras, criativas, apaixonadas, entre outros. E quanto às ferramentas e aos
processos, professor? Galera, ambos são importantíssimos para guiar e apoiar o
desenvolvimento, mas é a capacidade e o conhecimento dos indivíduos que ajudam a tomar
decisões críticas no projeto.
Dessa forma, basta eu ensinar um conjunto de processos para a minha equipe, assim como um conjunto
de ferramentas para garantir que a equipe criará bons softwares? Claro que não! Uma equipe possui
características intrínsecas à personalidade, habilidades e capacidades de cada um dos seus
integrantes e isso deve ser considerado e valorizado na construção de um software. Entendido,
pessoal? Seguindo...
Por que valorizar mais software em funcionamento do que documentação abrangente?
Porque o que gera valor para o cliente é o resultado que você entrega e, não, a documentação
em si. Respondam-me uma pergunta: quando você compra um carro, você olha o motor, o design, o
painel, o interior ou você sai correndo loucamente para ler o manual do carro e outras documentações?
Imagino que vocês tenham respondido a primeira opção! Dito isso, concluímos que o software em
funcionamento é o único indicador do que, de fato, a equipe construiu.
Claro, não se exclui a necessidade de documentação, que é bastante útil para o desenvolvimento,
mas é recomendável produzir somente a documentação necessária e suficiente para a realização
do trabalho em si. Nada de burocratizar demais e construir trezentas páginas de documentação
com quatrocentos diagramas diferentes para representar o software. Tudo certo? Eu vou repetir,
porque esse assunto cai bastante em prova!
8

Aula 03
No ágil, documentação é descartável? Não, ela é útil para ajudar a comunicação e a colaboração dos
integrantes da equipe, além de melhorar a transferência de conhecimento, preservar informações
históricas, satisfazer necessidades contratuais ou legais, entre outros. A documentação é
importante, sim; mas valoriza-se mais o software em funcionamento, que é o que de fato
agrega valor ao cliente. Belê?
Por que valorizar mais colaboração com o cliente do que negociação de contratos?
Porque é importante o envolvimento contínuo do cliente! Aliás, desenvolvedores e clientes

devem estar sempre lado a lado, visto que ambos possuem interesses em comum. Qual? Um
software que agregue valor! No Modelo em Cascata, vocês devem se lembrar que o cliente até
colaborava com a equipe no início do projeto (em geral, na fase de levantamento de requisitos),
mas – depois disso – o cliente saía de cena e só aparecia novamente para ver o software já pronto.
E pior: muitas vezes, o cliente saía insatisfeito, porque o resultado não era o que ele esperava.
Dessa forma, o manifesto ágil afirma que você tem que valorizar mais a sua relação com o cliente
do que ficar discutindo itens de contrato: “Isso não estava previsto no contrato”; “Isso não estava
combinado previamente”; “Vou cobrar a mais porque você mudou tal coisa”; entre outros. Professor,
então contratos não são importantes? Claro que são!
Contratos regulam essa relação entre cliente e fornecedor, mas não se deve ser excessivamente
rigoroso, porque isso pode acabar com a relação com seu cliente. Por falar em contrato, existem
várias maneiras de fazer contratos de desenvolvimento ágil. Uma maneira comum é fixar o tempo
e deixar o escopo variar. É o famoso: “Tempo Fixo e Escopo Variável”! Você fala para o seu cliente:
“É o seguinte: eu faço tudo que você pedir desde que seja possível fazer no prazo tal”.
Por que valorizar mais a resposta a mudanças do que seguir um planejamento específico?
Porque, em geral, é necessário obter respostas rápidas a mudanças e seguir um

desenvolvimento contínuo do software. Todo projeto deve balancear o planejamento com a
mudança, dependendo do nível de incerteza do projeto. Manter-se preso a um planejamento
ultrapassado pode ser nocivo ao andamento do projeto. Galera, nós estamos no século 21! Uma
empresa líder de mercado pode acabar de uma hora para outra – nós vemos isso o tempo todo.
Cadê o Orkut? Cadê o MSN? Cadê a Nokia? Cadê a Kodak? Cadê a BlockBuster? Todas essas empresas
foram gigantes pouco tempo atrás e simplesmente morreram! Logo, a única certeza que você tem
em um projeto é a instabilidade! Logo, a equipe deve estar preparada para mudanças no escopo,
tempo, custo, tecnologia, arquitetura, no paradigma de programação, regulamentações, leis,
regras de conformidade, entre outros.
Não tem como fazer um planejando e achar que ele vai ficar fixo ali ao longo do tempo – isso é
pensamento do século passado (se muito!). Acreditem: mudanças vão ocorrer! Planejar é bom
9

Aula 03
demais. É tão bom que é recomendável refazer o planejamento a todo momento, de forma
contínua e, não, fazer um planejamento estático e simplesmente segui-lo com todo rigor
ignorando mudanças externas que venham a ocorrer. Fechou?
10

Aula 03
Agilidade x Velocidade
Pessoal, agora vamos falar rapidamente sobre uma diferença

importante! Vocês sabem qual a diferença entre agilidade e
velocidade? Antes de explicá-la no contexto de desenvolvimento de
software, eu vou explicar como uma metáfora em outros dois
contextos para facilitar o entendimento. Vamos pensar no atleta
Usain Bolt! O Usain Bolt é um cara veloz ou um cara ágil? Bem, em
comparação com seres humanos normais, ele é mais ágil e mais
veloz que todo mundo! No entanto, vamos pensar só no grupo dos
grandes atletas que disputam mundiais e olimpíadas de atletismo.
Nesse contexto, ele é absurdamente veloz, mas menos ágil que a
==f219==
maioria dos seus concorrentes. Como é, professor?
Vejam as duas imagens a seguir: observem que – à esquerda – temos cerca de vinte metros de
corrida e o Bolt é o atleta de azul no meio. Notem também que ele está mais ou menos em quarto
lugar na corrida. Por que? Porque agilidade é a capacidade de reagir ou responder
adequadamente a mudanças e o Bolt sempre teve problemas de largada, uma vez que ele é
mais alto e pesado que os outros.
Logo, ele acaba reagindo de forma mais lenta que seus adversários quando o tiro de início da
corrida é disparado. Vejam: todos estão parados e, ao disparar o tiro, nós temos uma mudança.
Essa mudança faz com que o os atletas reajam e saiam da inércia. O Bolt demora mais que seus
concorrentes a sair da inércia, uma vez que ele não responde tão bem quanto os outros a mudança.
Nesse sentido, ele é ágil, mas não destoa dos outros pela sua agilidade.
Se nós tivéssemos corridas de 50 metros em vez de 100 metros, talvez ele não fosse tricampeão
olímpico. Por outro lado, vejam o final da corrida quando ele não tem mais que reagir a mudanças,
ele só tem que correr até o fim dos 100 metros. Ele termina muito distante do segundo lugar! Por
11

Aula 03
que? Porque ele é um cara extremamente veloz, logo ele destoa de todos os outros com muita
facilidade. Entenderam que agilidade não é velocidade? É a capacidade de reagir a mudanças!
A velocidade trata de quão rápido é possível entregar um software para o cliente. E, para isso,
nós temos outras metodologias de desenvolvimento (Ex: Rapid Application Development (RAD) é
capaz de desenvolver softwares em poucos meses). Utilizando outra metáfora, isso ocorre também
quando você tem uma disputa entre um carro muito potente e pesado, e um carro menos potente
e mais leve.
É provável que o carro mais leve, mesmo sendo menos potente, tenha uma arrancada melhor
que o carro mais potente, logo ele é mais ágil. Ele é mais rápido? Não, o carro mais potente é mais
rápido, mas ele é mais potente! Claro, pessoal, que esses são exemplos genéricos – apenas para
entender a ideia. Diego, e como esse conceito de agilidade pode ser utilizado no contexto de um
desenvolvimento de software?
No contexto de projetos de software, podemos imaginar: eu estou gerenciando meu projeto de um

novo sistema e, de repente, descubro que vou ter que mudar a arquitetura do software – não tem
problema; se eu descubro que, por conta de cortes de gastos, eu terei que reduzir o tamanho a
minha equipe – não tem problema; se eu tiver que trocar a tecnologia utilizada porque ela se tornou
defasada – mais uma vez, não tem problema.
Pressman afirma que a agilidade pode ser aplicada a qualquer processo de software. No
entanto, para obtê-la, é essencial que o processo de software seja projetado para que a equipe
possa adaptar e racionalizar suas tarefas; para que a equipe possa conduzir o planejamento
compreendendo a fluidez de uma abordagem do desenvolvimento ágil; e para que a equipe possa
eliminar tudo, exceto os artefatos essenciais do processo.
Além disso, deve enfatizar a estratégia de entrega incremental, entregando para o cliente o
software operacional o mais rapidamente possível para o tipo de produto e ambiente operacional.
Essa são as diretivas para que um processo de software qualquer possa ser, também, ágil.
Métodos ágeis são ágeis porque partem do princípio de que tem que responder adequadamente a
mudanças que venham a ocorrer durante o ciclo de vida do projeto.
Eles são mais dinâmicos, adaptativos, interativos e colaborativos – eles se adaptam às

necessidades de um projeto e às suas mudanças no decorrer do desenvolvimento; os métodos
tradicionais são mais preditivos/prescritivos, processuais, formais, documentais e contratuais – eles
valorizam mais o planejamento de todos os aspectos do processo de desenvolvimento de software
como um todo.
12

Aula 03
Princípios Ágeis
A seguir, nós vamos conhecer quais são os princípios do Manifesto Ágil. Eles vêm expressamente
no manifesto e vocês podem encontrá-lo no site oficial:
www.agilemanifesto.org
NÓS SEGUIMOS ESSES PRINCÍPIOS...

Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada e software com valor
agregado.
Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram
vantagem das mudanças visando vantagem competitiva para o cliente.
Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor
escala de tempo.
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles
para fazer o trabalho.
13

Aula 03
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através
de conversa face a face.
Software funcionando é a medida primária de progresso.
Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários

devem ser capazes de manter um ritmo constante indefinidamente.
Contínua atenção à excelência técnica e bom design aumenta a agilidade.
Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial.
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu
comportamento de acordo.
==f219==
Professor, metodologias ágeis são recomendadas para projetos de qualquer tamanho e

complexidade? Segundo Sommerville: “Todos os métodos têm limites, e os métodos ágeis são
somente adequados para alguns tipos de desenvolvimento de sistema. Na minha opinião, eles são mais
adequados para o desenvolvimento de sistemas de pequenas e médias empresas e produtos para
computadores pessoais”.
Diego, você concorda com essa afirmação? Não, eu discordo! Acredito que ela já foi válida tempos
atrás, mas hoje não é mais! Projetos Ágeis já são suficientemente maduros para serem
aplicados a projetos complexos e de grande porte. Pessoal, essa é só a minha opinião! Não é
possível saber ainda a posição das bancas caso isso seja questionado em provas de concurso. Legal?
Vamos ver agora exemplos de metodologias ágeis de desenvolvimento:
Principais METODOLOGIAS ÁGEIS

SCRUM CRYSTAL XP
TDD ATDD BDD
FDD DDD MDD
DSDM ASD KANBAN
LEAN AUP AGILE MODELING
OSSD SCRUMBAN BADM
Agora vamos ver algumas diferenças básicas entre metodologias de desenvolvimento software
tradicionais e metodologias ágeis:
CRITÉRIO MODELOS TRADICIONAIS MODELOS ÁGEIS

Comumente realizado em detalhe para todo Planejamento de alto nível no início do projeto e
o projeto em sua fase inicial. os detalhes são realizados durante o projeto. Não
é necessário possuir um planejamento detalhado
PLANEJAMENTO
de todo o projeto. A restrição se dá apenas em
possuir os detalhes do trabalho para a próxima
iteração.
14

Aula 03
Prioriza os riscos gerais do projeto, mas foca

Pode exigir um grande esforço e equipe para
principalmente nos riscos das próximas iterações,
atuar com os riscos de todo o projeto.
atuando assim em um escopo bem reduzido. A
RISCOS
própria equipe atua com os riscos e pode obter
apoio externo.
Possui profissionais com papéis bem Equipe multidisciplinar, multifuncional e auto-

definidos, quantificada e mobilizada organizada. Ela decide como fazer e atua de
conforme o planejamento do projeto. A forma colaborativa.
EQUIPE
equipe executa o projeto guiado pelo
Gerente de Projetos conforme o plano
estabelecido.
Fixo e é conforme a definição de duração das
iterações que comumente varia entre 1 e 4
TEMPO DE É realizado conforme o plano estabelecido e semanas.
pode durar semanas, meses ou até mesmo
ENTREGA anos.
Mudanças são bem-vindas. Evita-se mudar o

Gerenciamento formal de mudanças, pois escopo da iteração em andamento, mas o escopo
ACEITAÇÃO DE exige alteração do planejamento já realizado das futuras iterações podem ser replanejado
MUDANÇAS e geralmente precisa passar por aprovações conforme a necessidade do cliente.
formais de um ou mais níveis hierárquicos.
Tende a ter uma grande previsibilidade futura

Depende do intervalo de monitoramento e
devido à constante análise e feedback através das
controle do projeto. Quanto mais curto,
oportunidades de inspeção e adaptação providas
PREVISIBILIDADE maior a chance de prever as ocorrências
pelo método.
futuras. Quanto maior o intervalo, menor a
chance de prever as ocorrências futuras.
Gera resultados a curto, médio e longo prazo, pois

Tende a demorar a dar resultados a curto
RESULTADOS AO prazo, pois as entregas são geralmente atua com entregas antecipadas e de valor
agregado e contínuo ao cliente.
LONGO DO realizadas ao final do projeto. Melhores
TEMPO resultados são apresentados em projetos de
maior duração.
Geralmente informal e utiliza radiadores de

APRESENTAÇÃO Geralmente de uma apresentação formal
informação no ambiente de trabalho durante
previamente agendada com os stakeholders
DE todo o projeto, de modo que as informações do
em intervalos de tempo. As informações
INFORMAÇÕES podem ser detalhadas ou não conforme a
projeto fiquem visíveis e transparentes a toda
DO PROJETO equipe e envolvidos.
necessidade do público envolvido.
Conforme o tamanho da iteração e o

Conforme estabelecido no planejamento do
planejamento das releases para as entregas
PRAZO DE projeto. No caso de mudanças aprovadas, significativas.
varia conforme os impactos das solicitações
ENTREGA e podem ser traumáticas aos envolvidos
quanto às suas expectativas.
15

Aula 03
Abrangente no início e detalhada somente o

necessário durante o projeto conforme os
Detalhada desde o início do projeto.
objetivos das iterações e releases.
DOCUMENTAÇÃO
Durante todo o projeto, o cliente faz parte da

equipe.
ATUAÇÃO DO Nas fases iniciais e nas principais validações
do produto.
CLIENTE
Em prazos curtos, sempre ao final das iterações.
DISCUSSÕES E Geralmente em prazos longos através da

realização de reuniões após uma grande
MELHORIAS etapa ou grande entrega do projeto.
Equipe do Projeto.
Gerente de Projetos.
COMANDANTE
Conforme a confiança na equipe e ambiente

colaborativo.
Claros e definidos.
PAPÉIS
Empírico e guiado ao produto e às pessoas.

Orientado à geração de valor e conforme
Guiado conforme o planejamento do projeto
priorização dos riscos.
PROCESSO e nos processos estabelecidos no plano.
Melhor resultado em projetos cujo escopo é

dinâmico e construído durante a execução do
Melhor resultado em projetos com escopo
projeto.
RESULTADO muito bem definido e orientado a
planejamento.
16

Aula 03
Método Ágil x Método Lean

Galera, muitas pessoas me perguntam se Método Ágil é idêntico ao Método Lean! Apesar de serem
conceitos semelhantes, são diferentes! O Método Lean é uma filosofia de gestão inspirada em
práticas e resultados do Sistema Toyota e se caracteriza por uma estrutura de processos em que há
uma tentativa de minimizar o desperdício. O Lean serve de base para o Ágil. Ele apresenta sete
princípios...
Os princípios são: (1) Eliminar desperdício: O que seria um desperdício, professor? Trabalho
parcialmente feito (que você vai acabar tendo que terminar em algum momento); processos extras
(como documentação pesada); funcionalidades extras (entregue valor com qualidade e ponto);
alternação de tarefas ou multitarefas (trocar de tarefa toda hora acumula desperdícios). Acabou?
==f219==
Não, tem mais...
Evitar esperas (ex: cliente não tem tempo de homologar); esforços de comunicação (equipes
geograficamente distribuídas podem gerar problemas de gestão); defeitos (entregar um software
cheio de bugs). Enfim... tudo isso é considerado desperdício. (2) Amplificar conhecimento: trata-
se de priorizar a comunicação e o feedback contínuos entre equipes e usuários durante o
desenvolvimento.
(3) Fortalecer o time: criar um ambiente onde a equipe trabalhe de forma autoorganizada e
autodirigida, evitando microgerenciamento; (4) Entregas rápidas: maximizar o ROI (Return Of
Investiment) do projeto, entregando software de valor de forma rápida e contínua; (5) Construir
qualidade: garantir qualidade no desenvolvimento do software utilizando técnicas como TDD,
Refatoração, etc.
(6) Otimizar o todo: entender que o software concluído é muito mais que a soma das partes
entregues e verificar como ele está alinhado com os objetivos da empresa. (7) Adiar decisões:
deixar as decisões e comprometimentos para o último momento possível, permitindo coletar
informações e ter experiências para fortalecer a tomada de decisão. Enfim, galera... isso é o Método
Lean!
Deve-se eliminar tudo aquilo que não é percebido pelo cliente, por não
agregar valor para ele. Ex: passos extras, burocracia, documentação que
PRINCÍPIO #1 ELIMINAR DESPERDÍCIO não será lida, processo pesado, etc. Também existem aqueles
desperdícios que são trabalhos parcialmente prontos - tudo que teve um
começo, mas não teve fim e, portanto, não será utilizado.
Deve-se garantir que o conhecimento sobre o software seja criado durante
AMPLIFICAR/CRIAR o desenvolvimento, em vez de ter uma lista de requisitos e/ou um layout
PRINCÍPIO #2 recomendando como deve ser o resultado da aplicação antes do início de
CONHECIMENTO seu desenvolvimento.
17

Aula 03
O software que está sendo produzido é uma espécie de espelho da equipe

FORTALECER O TIME / que o está desenvolvendo. Para que as pessoas se sintam motivadas e
PRINCÍPIO #3 engajadas na atuação em equipe, eles precisam de respeito e confiança.
RESPEITAR AS PESSOAS Deve-se criar um ambiente onde a equipe trabalhe de forma auto-
organizada e auto-dirigida, evitando micro-gerenciamento.
Outra dica importante é que, sem entregas rápidas, você não consegue
receber um retorno, ou seja, você não consegue saber o que errou para
PRINCÍPIO #4 ENTREGAS RÁPIDAS tentar corrigir. Por isso, procurar a velocidade na entrega é uma maneira
de garantir que o cliente tenha em mãos aquilo que ele precisava para hoje
e não o que precisou.
Segundo os criadores da teoria, a qualidade é inegociável e deve ser
CONSTRUIR / INTEGRAR entregue em duas dimensões: a integridade percebida e conceitual. A
PRINCÍPIO #5 integridade percebida quer dizer que foi entregue ao cliente um produto
QUALIDADE usual, funcional, confiável. A integridade conceitual quer dizer que o
sistema tem pontos centrais altamente coesos e fáceis.
Deve-se entender que o software concluído é muito mais que a soma das
partes entregues e verificar como ele está alinhado com os objetivos da
PRINCÍPIO #6 OTIMIZAR O TODO empresa. O ideal não é olhar apenas para o desenvolvimento, mas para
como aquele requisito está sendo atendido, como ele está sendo
detalhado e repassado para entrar em desenvolvimento, etc.
Deve-se diminuir as incertezas, retardando decisões até que elas sejam
ADIAR formuladas em cima de acontecimentos mais conhecidos, previsíveis e
PRINCÍPIO #7 firmes. Decisões tomadas tardiamente devem ser mais corretas, uma vez
DECISÕES/COMPROMISSOS que as melhores são baseadas em fatos ocorridos e não em suposições ou
especulações.
Ele serviu de base para o método ágil e tem várias características em comum, mas são
diferentes. A tabela abaixo organiza um comparativo para vocês terem noção das diferenças.
CARACTERÍSTICA LEAN ÁGIL

Obcecado com... Desperdício Clientes e Mercados
Gerencia... Processos Incertezas
Entrega de... Valor Produto em Funcionamento
Aplica... Heurísticas Princípios
Foca no processo de... Padronização e Conformidade Autogerenciamento p/ maximizar autonomia
18

Aula 03
RESUMO
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo. Através deste trabalho, passamos a valorizar:
INDIVÍDUOS E INTERAÇÕES MAIS QUE PROCESSOS E FERRAMENTAS

SOFTWARE EM FUNCIONAMENTO MAIS QUE DOCUMENTAÇÃO ABRANGENTE
COLABORAÇÃO COM O CLIENTE MAIS QUE NEGOCIAÇÃO DE CONTRATOS
RESPONDER A MUDANÇAS MAIS QUE SEGUIR UM PLANO

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Devemos entender que o desenvolvimento de software é uma atividade

INDIVÍDUOS E ITERAÇÕES MAIS QUE humana e que a qualidade da interação entre as pessoas pode resolver
PROCESSOS E FERRAMENTAS problemas crônicos de comunicação. Processos e Ferramentas são
importantes, mas devem ser simples e uteis.
O maior indicador de que sua equipe realmente construiu algo é software
SOFTWARE EM FUNCIONAMENTO MAIS funcionando. Clientes querem é resultado e isso pode ser com software
QUE DOCUMENTAÇÃO ABRANGENTE funcionando. Documentação também é importante, mas que seja somente o
necessário e que agregue valor.
Devemos atuar em conjunto com o cliente e não “contra” ele ou ele “contra” a
COLABORAÇÃO COM O CLIENTE MAIS gente. O que deve acontecer é colaboração, tomada de decisões em conjunto
QUE NEGOCIAÇÃO DE CONTRATOS e trabalho em equipe, fazendo que todos sejam um só em busca de um
objetivo.
Desenvolver software e produtos é um ambiente de alta incerteza e por isso
RESPONDER A MUDANÇAS MAIS QUE não podemos nos debruçar em planos enormes e cheio de premissas. O que
SEGUIR UM PLANO deve ser feito é aprender com as informações e feedbacks e adaptar o plano a
todo momento.
Principais METODOLOGIAS ÁGEIS

SCRUM CRYSTAL XP
TDD ATDD BDD
FDD DDD MDD
DSDM ASD KANBAN
LEAN AUP AGILE MODELING
OSSD SCRUMBAN BADM
19

Aula 03

Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada e software com valor
agregado.
vantagem das mudanças visando vantagem competitiva para o cliente.
Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor
escala de tempo.
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles
para fazer o trabalho.
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através
de conversa face a face.
Software funcionando é a medida primária de progresso.
Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários

devem ser capazes de manter um ritmo constante indefinidamente.
Contínua atenção à excelência técnica e bom design aumenta a agilidade.
Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial.
20

Aula 03
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu
comportamento de acordo.
CRITÉRIO MODELOS TRADICIONAIS MODELOS ÁGEIS

Comumente realizado em detalhe para todo Planejamento de alto nível no início do projeto e
o projeto em sua fase inicial. os detalhes são realizados durante o projeto. Não
é necessário possuir um planejamento detalhado
PLANEJAMENTO de todo o projeto. A restrição se dá apenas em
possuir os detalhes do trabalho para a próxima
iteração.
Pode exigir um grande esforço e equipe para Prioriza os riscos gerais do projeto, mas foca
atuar com os riscos de todo o projeto. principalmente nos riscos das próximas iterações,
RISCOS ==f219==
atuando assim em um escopo bem reduzido. A

própria equipe atua com os riscos e pode obter
apoio externo.
Possui profissionais com papéis bem
Equipe multidisciplinar, multifuncional e auto-
definidos, quantificada e mobilizada
organizada. Ela decide como fazer e atua de
conforme o planejamento do projeto. A
EQUIPE equipe executa o projeto guiado pelo
forma colaborativa.
Gerente de Projetos conforme o plano
estabelecido.
É realizado conforme o plano estabelecido e Fixo e é conforme a definição de duração das
TEMPO DE
pode durar semanas, meses ou até mesmo iterações que comumente varia entre 1 e 4
ENTREGA anos. semanas.
Gerenciamento formal de mudanças, pois Mudanças são bem-vindas. Evita-se mudar o
ACEITAÇÃO DE exige alteração do planejamento já realizado escopo da iteração em andamento, mas o escopo
MUDANÇAS e geralmente precisa passar por aprovações das futuras iterações podem ser replanejado
formais de um ou mais níveis hierárquicos. conforme a necessidade do cliente.
Depende do intervalo de monitoramento e Tende a ter uma grande previsibilidade futura
controle do projeto. Quanto mais curto, devido à constante análise e feedback através das
PREVISIBILIDADE maior a chance de prever as ocorrências oportunidades de inspeção e adaptação providas
futuras. Quanto maior o intervalo, menor a pelo método.
chance de prever as ocorrências futuras.
Tende a demorar a dar resultados a curto Gera resultados a curto, médio e longo prazo, pois
RESULTADOS AO prazo, pois as entregas são geralmente atua com entregas antecipadas e de valor
LONGO DO realizadas ao final do projeto. Melhores agregado e contínuo ao cliente.
TEMPO resultados são apresentados em projetos de
maior duração.
APRESENTAÇÃO Geralmente de uma apresentação formal Geralmente informal e utiliza radiadores de
previamente agendada com os stakeholders informação no ambiente de trabalho durante
DE
em intervalos de tempo. As informações todo o projeto, de modo que as informações do
INFORMAÇÕES podem ser detalhadas ou não conforme a projeto fiquem visíveis e transparentes a toda
DO PROJETO necessidade do público envolvido. equipe e envolvidos.
Conforme o tamanho da iteração e o
Conforme estabelecido no planejamento do
PRAZO DE planejamento das releases para as entregas
projeto. No caso de mudanças aprovadas,
ENTREGA varia conforme os impactos das solicitações
significativas.
21

Aula 03
e podem ser traumáticas aos envolvidos

quanto às suas expectativas.
Detalhada desde o início do projeto. Abrangente no início e detalhada somente o
DOCUMENTAÇÃO necessário durante o projeto conforme os
objetivos das iterações e releases.
ATUAÇÃO DO Nas fases iniciais e nas principais validações Durante todo o projeto, o cliente faz parte da
do produto. equipe.
CLIENTE
DISCUSSÕES E Geralmente em prazos longos através da Em prazos curtos, sempre ao final das iterações.
realização de reuniões após uma grande
MELHORIAS etapa ou grande entrega do projeto.
Gerente de Projetos. Equipe do Projeto.
COMANDANTE
Claros e definidos. Conforme a confiança na equipe e ambiente

PAPÉIS colaborativo.
Guiado conforme o planejamento do projeto Empírico e guiado ao produto e às pessoas.

PROCESSO e nos processos estabelecidos no plano. Orientado à geração de valor e conforme
priorização dos riscos.
Melhor resultado em projetos com escopo Melhor resultado em projetos cujo escopo é
RESULTADO muito bem definido e orientado a dinâmico e construído durante a execução do
planejamento. projeto.
CARACTERÍSTICA LEAN ÁGIL

Obcecado com... Desperdício Clientes e Mercados
Gerencia... Processos Incertezas
Entrega de... Valor Produto em Funcionamento
Aplica... Heurísticas Princípios
Foca no processo de... Padronização e Conformidade Autogerenciamento p/ maximizar autonomia
PARA MAIS DICAS: www.instagram.com/professordiegocarvalho
22

Aula 03
QUESTÕES COMENTADAS – CESPE
1. (CESPE / Petrobrás - 2022) O conceito de sprint tem sua origem no RUP a partir da execução
das fases, cada uma delas com seu marco; cada ciclo no RUP tinha uma sprint considerada,
assim como um projeto curto.
Comentários:
O conceito de sprint tem origem no SCRUM, e não no RUP.
Gabarito: Errado
2. (CESPE / Petrobrás - 2022) No Scrum, todo o trabalho necessário para atingir a meta do
produto está embutido nas sprints, inclusive as daily scrums e as sprint retrospective.
Comentários:
Uma Sprint trata-se de uma unidade de trabalho que satisfaz um requisito de negócio. Em outras
palavras, é um ciclo completo de desenvolvimento de um incremento potencialmente entregável
de um produto. Como cada Sprint contém uma meta do que deve ser desenvolvido, o conjunto das
sprints trata-se da meta do produto. Ademais, as daily scrums e as sprint restropectives também
fazem parte das sprints. A primeira é uma reunião de 15 minutos e a segunda uma reunião mais
longa, de 3 horas.
Gabarito: Correto
3. (CESPE / Petrobrás - 2022) O Scrum usa um conjunto de “padrões de processo de software”,

que são adequados para projetos com prazos apertados e requisitos que mudam
frequentemente.
Comentários:
De acordo com Pressman, o Scrum enfatiza o uso de um conjunto de padrões de processos de

software que provaram ser eficazes para projetos com prazos de entrega apertados, requisitos
mutáveis e urgência do negócio. Lembrem-se que o Scrum é um framework para gerenciar
projetos, ele é capaz de gerenciar qualquer projeto que vise aumentar a agilidade e qualidade da
sua execução.
Gabarito: Correto
4. (CESPE / FUNPRESP-EXE - 2022) Na fase de desenvolvimento do Scrum, os requisitos são

escritos no product backlog.
23

Aula 03
Comentários:
Na verdade, o product backlog é definido na fase de pré-planejamento.
Gabarito: Errado
5. (CESPE / FUNPRESP-EXE - 2022) No desenvolvimento de software ágil com base em

prototipação, é essencial que todos os requisitos do sistema tenham sido definidos
previamente.
Comentários:
Opa... os requisitos de um sistema podem mudar a qualquer momento, eles estão em constante
evolução. De acordo com o Guia Scrum, requisitos nunca param de mudar, então o Backlog do
Produto é um artefato vivo.
Gabarito: Errado
6. (CESPE / FUNPRESP-EXE - 2022) As fases do processo tradicional de engenharia de software,

como análise, projeto, implementação e testes, podem estar representadas dentro de uma
sprint do Scrum.
Comentários:
Perfeito! Todas as fases podem ser representadas dentro de uma Sprint.
Gabarito: Correto
7. (CESPE / SEFAZ-SE – 2022) De acordo com a metodologia Scrum, a reunião em que são
apresentados os pontos positivos e negativos da sprint é a:
a) sprint planning.
b) retrospective.
c) daily.
d) backlog refinement.
e) sprint review.
Comentários:
A reunião em que são apresentados os pontos positivos e negativos da sprint, isto é, do processo
(e, não, do produto) é a sprint retrospective.
Gabarito: Letra B
24

Aula 03
8. (CESPE / TJ-RJ - 2021) Na metodologia Scrum, o rito que tem como finalidade refletir sobre o
andamento das atividades na sprint é conhecido como:
a) review.
b) daily.
c) backlog.
d) retrospectiv.
e) planning.
Comentários:
Isso ocorre na etapa de Retrospectiva da Sprint (que tem duração aproximada de 3 horas), em que
o Scrum Team inspeciona a si mesmo e cria um plano de melhoria para a próxima Sprint. Em suma,
é feita uma inspeção sobre como tudo ocorreu na última sprint em relação às pessoas, relações,
processos e às ferramentas.
Gabarito: Letra D
9. (CESPE / TJ-RJ - 2021) A metodologia Scrum estabelece vários papéis a serem desempenhados
pelo time; o responsável por controlar o progresso do desenvolvimento do projeto e ser o
guardião dos ritos é o:
a) product owner.
b) scrum master.
c) patrocinador do projeto.
d) stakeholder.
e) gerente do time de desenvolvimento.
Comentários:
O Scrum Master é o responsável por garantir que a metodologia Scrum seja entendida e aplicada.
Além disso, ele é responsável pela eficácia do Scrum Team. Por fim, o gráfico de Burndown é uma
maneira de medir o progresso de uma Sprint no Scrum.
Gabarito: Letra B
10. (CESPE / TELEBRÁS - 2021) Ao se usar a metodologia Scrum, recomenda-se que, ao final do
sprint, ocorra uma reunião (sprint review) em que a equipe Scrum e todas as partes interessadas
se encontrem, preferencialmente de modo informal, com os objetivos de validar as entregas da
equipe Scrum e verificar se os critérios estabelecidos no planejamento foram executados.
Comentários:
25

Aula 03
Corretíssimo! A Revisão da Sprint (sprint review) ocorre ao final de uma sprint, ela é utilizada para
demonstrar as novas funcionalidades desenvolvidas durante a sprint e seu principal motivo é o de
inspecionar o que os desenvolvedores produziram e colher opiniões, de modo que o foco é
aprimorar o produto. Além disso, essa reunião deve ocorrer – preferencialmente - de maneira
informal.
Gabarito: Correto
11. (CESPE / TELEBRÁS - 2021) Em Scrum, na Sprint planning, o product owner seleciona os itens
do product backlog para incluir na Sprint e determina detalhadamente aos developers a forma
de trabalho a ser aplicada para viabilizar a criação de um incremento de valor.
Comentários:
O Sprint Planning é o planejamento dos trabalhos a serem realizados na Sprint. Esse planejamento
é realizado por toda a Equipe Scrum. O Product Owner não seleciona os itens que serão inclusos na
Sprint, ele apenas dá um valor de negócio para cada item e apresenta aos desenvolvedores, que
decidirão a quantidade de itens do backlog que serão realizados na Sprint.
Gabarito: Errado
12. (CESPE / TELEBRÁS - 2021) Para o método Scrum, o Product Backlog consiste em uma lista de
necessidades do cliente, ou seja, uma lista com as funcionalidades desejadas para um produto
Comentários:
O Product Backlog é uma lista ordenada (por valor, risco, prioridade, entre outros) de requisitos ou
funcionalidades que o produto deve conter criada pela Equipe Scrum e gerenciada pelo Product
Owner.
Gabarito: Correto
13. (CESPE / TELEBRÁS - 2021) Eliminar desperdício, amplificar o aprendizado e decidir o mais
tarde possível são alguns dos princípios do método Lean.
Comentários:
O método o Lean Thinking é uma espécie de estrutura mental (mindset) que permite reduzir o
desperdício e se concentrar no essencial. Ele é composto por sete princípios, entre eles está: a
amplificação do aprendizado que se trata de priorizar a comunicação e o feedback contínuos entre
equipes e usuários durante o desenvolvimento; além disso, também temos o princípio que trata-se
de adiar decisões, desse modo, deixa-se as decisões e comprometimentos para o último momento
possível, permitindo coletar informações e ter experiências para fortalecer a tomada de decisão.
26

Aula 03
Gabarito: Correto
14. (CESPE / TCE-RJ – 2021) O SCRUM é composto por quatro atividades: planeamento, projeto,
codificação e testes, as quais normalmente são repetidas iteração a iteração.
Comentários:
Scrum é composto por Planejamento da Sprint, Execução da Sprint, Reunião Diária, Revisão da
Sprint e Retrospectiva da Sprint. As fases apresentadas na questão são de outra metodologia ágil
também conhecida como XP (Extreme Programming).
Gabarito: Errado
15. (CESPE / CODEVASF – 2021) Na metodologia Scrum, é feita na sprint planning a seleção dos
itens do backlog que serão desenvolvidos durante a sprint; depois de fechado o seu escopo,
a sprint não poderá mais ser alterada.
Comentários:
O Planejamento da Sprint é a cerimônia que permite selecionar itens do Backlog do Produto que
serão desenvolvidos durante a execução da sprint. O problema da questão está em afirmar que,
depois de fechado o seu escopo, a sprint não poderá mais ser alterada. Na verdade, é possível
realizar alterações que não coloquem em risco a meta da sprint. Logo, discordo do gabarito da
questão veementemente.
Gabarito: Correto
16. (CESPE / SERPRO – 2021) Daily Scrum é o único momento do dia em que os developers se
reúnem para discutir detalhadamente a adaptação ou o replanejamento do trabalho da sprint.
Comentários:
Essa é uma cerimônia diária de discussão, mas desenvolvedores podem se reunir sempre que
desejarem e, não, o único.
Gabarito: Errado
17. (CESPE / APEX-BRASIL – 2021) Em Scrum, um item do Product Backlog incluído em uma Sprint
e que não atenda à Definição de Pronto:
a) será retornado ao Product Backlog para consideração futura.

b) será encaminhado com prioridade ao Sprint Backlog.
27

Aula 03
c) será liberado com ressalvas, desde que haja acordo no Scrum Team.
d) será apresentado na Sprint Review para uma segunda avaliação do Scrum Team
Comentários:
Se um item do Product Backlog não atender à Definição de Pronto, ele não poderá ser liberado ou
mesmo apresentado na Sprint Review. Em vez disso, ele retorna ao Product Backlog para
consideração futura.
Gabarito: Letra A
18. (CESPE / APEX-BRASIL – 2021) No Scrum, cada artefato tem um compromisso, para assegurar
que a informação fornecida aumente a transparência e o foco, possibilitando a mensuração do
progresso. No caso do Increment, esse compromisso é o:
a) Product Goal.
b) Sprint Goal.
c) Definition of Done.
d) Burn Down.
Comentários:
(a) Errado, esse é o compromisso do Product Backlog; (b) Errado, esse é o compromisso da Sprint
Backlog; (c) Correto, a Definition of Done é o compromisso do Increment; (d) Errado, esse não é o
compromisso de nada.
Gabarito: Letra C
19. (CESPE / Ministério da Economia – 2020) Os métodos ágeis de desenvolvimento

de software têm duas unidades principais de entrega: lançamentos e iterações.
Comentários:
De fato, lançamentos (releases) e iterações são componentes de métodos ágeis, no entanto não
vejo como se pode afirmar que são as unidades principais. Ora, são principais em que sentido? Enfim,
questão correta, mas com ressalvas...
Gabarito: Correto
20. (CESPE / Ministério da Economia – 2020) O responsável direto pelo backlog da sprint é o time
de desenvolvimento, que decide sobre as adições e(ou) remoções e os ajustes de tarefas durante
a execução da sprint; no entanto, se algum item for retirado, o dono do produto deve ser avisado
o mais breve possível.
28

Aula 03
Comentários:
De fato, o Sprint Backlog é um plano feito por e para os desenvolvedores. É uma imagem altamente
visível, em tempo real do trabalho que os desenvolvedores planejam realizar durante a Sprint para
atingir a meta da sprint. E realmente o Product Owner deve ser avisado o mais breve possível caso
algum item seja retirado – lembrando aqui do princípio da transparência.
Gabarito: Correto
21. (CESPE / Ministério da Economia – 2020) O Scrum Master é diretamente responsável por
manter e priorizar o backlog do produto, além de colaborar com o time de desenvolvimento.
Comentários:
Na verdade, essa é uma responsabilidade do Product Owner e, não, do Scrum Master. O Product
Owner é responsável pelo gerenciamento eficaz do Product Backlog, que inclui: (1) desenvolver e
comunicar explicitamente a meta do produto; (2) criar e comunicar claramente os itens do Product
Backlog; (3) ordenar os itens do Product Backlog; (4) e, garantir que o Product Backlog seja
transparente, visível e compreensível.
Gabarito: Errado
22. (CESPE / Ministério da Economia – 2020) Um dos artefatos do Scrum, o backlog do produto é
gerenciado, exclusivamente, pelo dono do produto e representa o conteúdo, a disponibilidade
e a ordenação do trabalho a ser realizado, sendo a única porta de entrada para todos os registros
de requisitos de mudança a serem realizados no produto.
Comentários:
O Backlog do Produto é uma lista ordenada de tudo que é conhecido como necessário no produto
– trata-se da única fonte de requisitos para quaisquer alterações a serem feitas no produto. O
Product Owner é responsável pelo Product Backlog, incluindo seu conteúdo, disponibilidade,
ordenação e requisitos de mudança.
Gabarito: Correto
23. (CESPE / Ministério da Economia – 2020) Sprint é o ciclo de desenvolvimento de poucas

semanas sobre o qual se estrutura o Scrum e durante o qual cabe ao scrum master manter
o sprint backlog atualizado, indicando as tarefas já concluídas e aquelas ainda por concluir.
Comentários:
29

Aula 03
Sprint é o ciclo de desenvolvimento de poucas semanas sobre o qual se estrutura o Scrum e durante
o qual cabe ao scrum master desenvolvedores manter o sprint backlog atualizado, indicando as
tarefas já concluídas e aquelas ainda por concluir.
Gabarito: Errado
24. (CESPE / Ministério da Economia – 2020) Uma forma de acompanhar a produtividade é fazer
uso de um gráfico de Burndown, no qual é possível visualizar a expectativa de produtividade
ideal do projeto e comparar com a produtividade real.
Comentários:
Perfeito! O Gráfico de Burndown torna visível a evolução diária do trabalho da equipe de

desenvolvimento, na medida em que mostra a comparação de produtividade entre o trabalho
estimado inicialmente com a quantidade restante estimada de trabalho. Dessa forma, é possível
visualizar a expectativa de produtividade ideal do projeto e comparar com a produtividade real.
Gabarito: Correto
25. (CESPE / Ministério da Economia – 2020) Backlog da sprint é diferente do backlog do produto,
já que o primeiro é um conjunto de itens selecionados a partir do segundo, sendo parte do
planejamento da equipe para entregar um incremento do produto.
Comentários:
Perfeito! O Backlog da Sprint é selecionado a partir do Backlog do Produto. Ele é composto pela
Meta da Sprint (por que), o conjunto de itens do Product Backlog selecionados para a Sprint (o que),
bem como um plano de ação para entregar o Incremento (como).
Gabarito: Correto
26. (CESPE / Ministério da Economia – 2020) As histórias são consideradas pequenos requisitos de
um projeto na perspectiva do usuário final.
Comentários:
Histórias de usuário são basicamente especificações no formato de uma ou mais frases na

linguagem de negócio ou cotidiana do usuário do sistema que captura o que um usuário faz ou
necessita fazer como parte de sua função de trabalho. Logo, podem ser consideradas como
pequenos requisitos ou solicitações de um projeto sob a perspectiva do usuário final.
Gabarito: Correto
30

Aula 03
27. (CESPE / Ministério da Economia – 2020) Pequenas partes do trabalho com a perspectiva do
patrocinador são artefatos denominados Epics.
Comentários:
Algumas vezes, as histórias de usuário são muito grandes para serem desenvolvidas em uma única
sprint. Essas histórias de usuário são chamadas de Épicos e podem ser divididas em duas ou mais
histórias de tamanho menor. Não há nenhuma relação com pequenas partes de trabalho com a
perspectiva do patrocinados – são grandes histórias de usuário sob a perspectiva do usuário.
Gabarito: Errado
28. (CESPE / Ministério da Economia – 2020) O scrum master possui autoridade para cancelar
uma sprint antes de o time-boxed da sprint terminar.
Comentários:
Na verdade, apenas o Product Owner tem autoridade para cancelar a sprint.
Gabarito: Errado
29. (CESPE / SLU-DF – 2019) Entre os processos da gestão de projetos com Scrum, as inspeções
constituem os processos mais complexos e formais e, por isso, ocorrem somente ao fim de um
ciclo de várias sprints, após a liberação de uma funcionalidade plena e o seu reconhecimento
pelo demandante.
Comentários:
De acordo com o Scrum, os usuários devem, frequentemente, inspecionar os artefatos Scrum e o

progresso em direção ao objetivo da Sprint para detectar variações indesejadas. Esta inspeção não
deve ser tão frequente que atrapalhe o objetivo dos trabalhos. As inspeções são mais benéficas
quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar.
Gabarito: Errado
30. (CESPE / TCE-RO – 2019) No Scrum,
a) os times de desenvolvimento ou times Scrum são auto-organizáveis e responsáveis por

gerenciar o backlog do produto.
b) cabe ao product owner dizer ao time de desenvolvimento como transformar o backlog do

produto em incrementos operacionais para o cliente.
31

Aula 03
c) que consiste de um framework para desenvolver e manter produtos complexos, utiliza-se

uma abordagem iterativa e incremental para aperfeiçoar o controle de riscos.
d) as sprints consistem exclusivamente de reuniões diárias e do trabalho de desenvolvimento,

com duração superior a um mês.
e) após o planejamento da sprint, o backlog do produto torna-se completo, o que impede a

ocorrência de alterações posteriores.
Comentários:
(a) Errado. Times de Desenvolvimento e Time Scrum são diferentes – o primeiro está contido no
segundo. Eles são, de fato, auto-organizáveis, mas o responsável por gerenciar o backlog do
produto é Product Owner; (b) Errado, essa é uma responsabilidade do próprio Time de
Desenvolvimento; (c) Correto; (d) Errado, ela é composta de uma reunião de planejamento da
sprint, reuniões diárias, trabalho de desenvolvimento em si, uma revisão da Sprint e a retrospectiva
da Sprint – além disso, a duração é inferior a um mês; (e) Errado, um Backlog do Produto nunca está
completo e o restante da questão também não faz sentido algum.
Gabarito: Letra C
31. (CESPE / MPC-PA – 2019) A gestão ágil é uma das tendências nos projetos de desenvolvimento
de software. O backlog é um dos artefatos que auxiliam na organização do projeto, em especial
na definição das características tanto do produto (Product Backlog) quanto das Sprints (Sprint
Backlog). Com relação a esses conceitos, assinale a opção correta:
a) O backlog da Sprint não pode ser alterado após sua elaboração.

b) O backlog do produto deve ser atualizado diariamente, para refletir novos requisitos a serem
incorporados ao produto.
c) O backlog do produto é um dos produtos do backlog da Sprint .
d) O backlog da Sprint não deve ser embasado em Sprints anteriores, pois o tempo estimado
para cada Sprint depende do Product Backlog.
e) O backlog da Sprint deve prever a duração de, no máximo, um mês para cada Sprint.
Comentários:
(a) Errado, o Time de Desenvolvimento modifica o Backlog da Sprint ao longo de toda a Sprint; (b)
Errado, ele deve ser atualizado quando houver alguma necessidade de negócio; (c) Errado, ele é o
insumo do backlog da sprint; (d) Errado, o dono do produto compara o total do trabalho restante
na Reunião de Revisão da Sprint comparando o valor da Revisão da Sprint anterior, para avaliar o
progresso; (e) Correto.
Gabarito: Letra E
32

Aula 03
32. (CESPE / FUB – 2018) No método Scrum, ao final de cada período de duas a quatro semanas de
um Sprint backlog, pode-se planejar uma entrega periódica ao cliente.
Comentários:
Sprint Backlog não é um período – é um conjunto de itens selecionados para serem implementados
durante a sprint, mais o plano para transformá-los em um incremento. A redação correta da
questão seria: No método Scrum, ao final de cada período de duas a quatro semanas de um Sprint
backlog, pode-se planejar realizar uma entrega periódica ao cliente.
Gabarito: Errado
33. (CESPE / BNB – 2018) No Scrum, o Product Owner é a pessoa que define os itens que compõem
o product backlog.
Comentários:
Perfeito! O Product Owner é responsável por definir os itens que compõem o Product Backlog.
Gabarito: Correto
34. (CESPE / ANTT – 2013) Entre os vários papéis do SCRUM, o product owner é a única pessoa
responsável por gerenciar o backlog do produto, possuindo, ainda, a responsabilidade de
maximizar o valor do produto e do trabalho da equipe de desenvolvimento.
Comentários:
De acordo com Guia Scrum [Versão 2013]: “O Product Owner, ou dono do produto, é o responsável
por maximizar o valor do produto e do trabalho do Time de Desenvolvimento. Como isso é feito pode
variar amplamente através das organizações, Times Scrum e indivíduos”.
Gabarito: Correto
35. (CESPE / SERPRO – 2013) Scrum é um processo de desenvolvimento que tem como ponto de
partida um conjunto de requisitos bem definidos.
Comentários:
Conjunto de requisitos bem definidos? Não, ele tem como ponto de partida geralmente um conjunto
de requisitos pouco definidos. Ao longo das cerimônias, melhora-se a definição dos requisitos. Se
os requisitos fossem bem definidos, o Product Backlog seria quase imutável e não é isso que nós
verificamos empiricamente.
33

Aula 03
Gabarito: Errado
36. (CESPE / TCE-RO - 2013) Na metodologia Scrum, a equipe trabalha nos processos e não há
cargos na equipe. Como um dos papéis necessários, o Scrum Master deve garantir que o
processo seja entendido e atuar como facilitador para ajudar a equipe.
Comentários:
Perfeito! Lembrem-se de que não há cargos, mas papéis ou responsabilidades!
Gabarito: Correto
37. (CESPE / BASA – 2012) Em um projeto gerido com a metodologia Scrum, um produto estará,
ao final de cada sprint, completamente testado, estando 100% completos todos os requisitos
do product backlog.
Comentários:
Nenhum produto jamais estará completamente testado! Não há como testar todas as
possibilidades de defeitos em um produto qualquer – é impossível! Além disso, o Product Backlog
também nunca estará completo – lembrem-se que ele é um organismo vivo.
Gabarito: Errado
38. (CESPE / BASA – 2012) O escopo, a importância e a estimativa de um Sprint do Scrum são
definidos pelo Product Owner.
Comentários:
Product Owner não trata de estimativas. Entendam: escopo e importância são definidos pelo
Product Owner, no entanto quem define as estimativas é a Equipe de Desenvolvimento [Versão
2017].
Gabarito: Errado
39. (CESPE / BASA – 2012) A metodologia Scrum, ágil para gerência de projetos, baseia-se em
ciclos de 30 dias, denominados sprints, em que se trabalha para alcançar objetivos bem
definidos.
Comentários:
Scrum é uma metodologia ágil para gerência de projetos? Sim. Baseia-se em ciclos de 30 dias
denominados sprints? Sim, o ideal seria a questão ter falado menor que um mês, mas podemos
34

Aula 03
relevar! Nas sprints, trabalha-se para alcançar objetivos bem definidos? Sim, a meta da Sprint deve
ser alcançada.
Gabarito: Correto
40. (CESPE / ECT – 2011) Para que se obtenha sucesso na utilização do Scrum, o cliente deve se
tornar parte da equipe de desenvolvimento do software, participando diretamente do processo.
Comentários:
O cliente não se torna parte da equipe de desenvolvimento. Há – sim – uma forte integração, no
entanto dizer que faz parte da equipe de desenvolvimento é um completo absurdo. No entanto,
infelizmente a banca não entendeu dessa maneira :(
Gabarito: Correto
41. (CESPE / MEC – 2011) O framework scrum engloba conceitos como times scrum, eventos com
duração fixa (time-boxes), artefatos e regras. São exemplos de eventos que têm duração fixa: a
reunião de planejamento da versão para entrega, a sprint, a reunião diária, a revisão da sprint e
a retrospectiva da sprint.
Comentários:
Questão correta, porém peca em afirmar que se trata de um evento com duração fixa. Por que,
professor? Porque o conceito de time-box é aquilo que tem uma duração máxima fixa (Ex: Sprint <=
30 dias). Logo, eu entendo que caberia recurso nessa questão.
Gabarito: Correto
42. (CESPE / MEC 2011) Produto da metodologia Scrum, o documento product backlog contém os
requisitos definidos a partir da visão do cliente e é utilizado novamente no final do sprint para
revisão ou modificações dos requisitos inicialmente definidos.
Comentários:
Perfeito! A Sprint Backlog é derivada do Product Backlog, que é derivado do Documento de Visão.
No final da Sprint, durante a cerimônia de Revisão da Sprint, é verificado se o que foi feito está de
acordo com o que foi previamente definido.
Gabarito: Correto
43. (CESPE / ABIN – 2010) No SCRUM, um backlog consiste em uma lista de itens priorizados a
serem desenvolvidos para um software. Essa lista é mantida no product owner, o qual pode
35

Aula 03
alterá-la a qualquer momento, desde que os itens alterados não estejam na sprint backlog. Isso
significa que product backlog e sprint backlog são estruturas similares.
Comentários:
Não é necessariamente para um software. Ele pode alterá-la a qualquer momento, desde que a
alteração não coloque em risco a meta da sprint. Por fim, são estruturas similares em qual sentido?
Ambos são listas, mas um é derivado do outro: Product Backlog é uma lista de funcionalidades (alto
nível) e a Sprint Backlog é um conjunto de tarefas que devem ser feitas para entregar um
incremento potencialmente entregável (baixo nível).
Gabarito: Errado
36

Aula 03
QUESTÕES COMENTADAS – FCC
44.(FCC / TRF - 3ª REGIÃO – 2019) SCRUM atende aos princípios do Manifesto Ágil porque:
a) pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o

projeto.
b) não aceita mudanças nos requisitos durante o desenvolvimento e por isso as entregas são
mais ágeis.
c) as entregas ocorrem sempre no prazo, nunca adiantadas ou atrasadas.
d) mais importante que a motivação dos desenvolvedores é a disciplina gerencial imposta que
organiza e agiliza o desenvolvimento.
e) não admite a comunicação direta entre os desenvolvedores, pessoalmente. Isso só pode ser
feito por intermédio de um gerente ou coordenador.
Comentários:
(a) Correto, indivíduos e interações valorizam mais processos e ferramentas; (b) Errado, ele aceita
mudanças nos requisitos; (c) Errado, entregas podem ser adiadas ou atrasadas; (d) Errado,
indivíduos são mais valorizados do que processos; (e) Errado, a comunicação direta ocorre
frequentemente.
Gabarito: Letra A
45. (FCC / TRF - 3ª REGIÃO – 2019) A Reunião Diária do Scrum é:
a) executada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto,

se necessário.
b) um time-boxed de 15 minutos, durante o qual um “Pronto”, versão incremental
potencialmente utilizável do produto, é criado.
c) uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias
a serem aplicadas na próxima Sprint.
d) um time-boxed de 15 minutos, para que o Time de Desenvolvimento possa sincronizar as
atividades e criar um plano para as próximas 24 horas.
e) um time-boxed de 60 minutos, durante o qual os produtos de uma Sprint são definidos.
Comentários:
(a) Errado, essa seria a Revisão da Sprint; (b) Errado, ela realmente dura 15 minutos, mas não busca
criar uma versão potencialmente utilizável do produto; (c) Errado, essa seria a Retrospectiva da
Sprint; (d) Correto; (e) Errado, ela dura 15 minutos e não busca definir os produtos de uma sprint.
Gabarito: Letra D
37

Aula 03
46.(FCC / TRF - 3ª REGIÃO – 2019) No roteiro SCRUM, de gerenciamento Ágil, a atividade que
discute funcionalidades de modo a atualizar o que já foi feito, o que será feito e dificuldades é:
a) Sprint Review que pretende validar a entrega do momento quando termina uma Sprint.
Realiza-se a reunião que fará a demonstração do produto ou funcionalidade sendo entregue.
b) Sprint Backlog, onde o conjunto planejado, selecionado junto ao Backlog do Produto, é

definido para compor uma Sprint. Somente as entregas que compõem a Sprint serão detalhas
em atividades menores e as restantes serão “congeladas”, não sendo detalhadas ainda.
c) Sprint Goal resultado da negociação entre o time de desenvolvimento e o Product Owner -

PO reconhecido como necessidade(s) fundamental(ais) do cliente nesse momento.
d) Daily Scrum, reunião que ocorre diariamente, durante 15 minutos, com todos participantes
em pé, onde se atualiza a situação presente da Sprint sendo trabalhada.
e) Product Backlog onde se produz uma lista contendo todas as funcionalidades desejadas para
um produto em sua situação atual.
Comentários:
O que foi feito? O que será feito? Quais são as dificuldades? Essas são as três perguntas realizadas na
Daily Scrum [Versão 2017].
Gabarito: Letra D
47. (FCC / SANASA Campinas – 2019) Um Analista de TI tem como tarefas ordenar os itens do
Backlog do Produto visando o alcance das metas e missões do projeto, buscando garantir que o
Backlog do Produto esteja claro de forma a mostrar no que o Time Scrum vai trabalhar a seguir
e ainda visando garantir que o Time de Desenvolvimento entenda os itens do Backlog do
Produto no nível necessário. Considerando que o projeto é baseado no Scrum, o Analista está
no papel de:
a) Scrum Master.
b) Gerente do Produto.
c) Sprint Manager.
d) Product Owner.
e) Development Team Leader.
Comentários:
Quem ordena os itens do Product Backlog é o Product Owner.
38

Aula 03
Gabarito: Letra D
48.(FCC / TRF - 4ª REGIÃO – 2019) Uma Analista de TI está atuando como Product Owner em um
projeto Scrum. Ela está trabalhando na formulação de um acordo para definir quais são os
passos mínimos para a conclusão de um item potencialmente entregável, que serve como um
contrato entre o Scrum Team e o Product Owner, de forma que os integrantes tenham um
entendimento compartilhado do que significa o trabalho estar completo, assegurando a
transparência e os padrões de qualidade estabelecidos entre eles. O acordo, denominado:
a) Scrum rules, integra os eventos, papéis e artefatos, administrando as relações e interações

entre eles, e é criado na 1ª sessão do Sprint Review Meeting.
b) incremento, pode evoluir normalmente ao longo do projeto, porém é recomendável que a

primeira versão seja criada durante a primeira sessão de Sprint Planning, após a realização da
primeira Sprint do projeto.
c) DoD, é a soma de todos os itens do Product Backlog completados durante a Sprint e o valor
dos incrementos de todas as Sprints anteriores.
d) Scrum rules, é um conjunto de itens do Product Backlog selecionados para a Sprint que forma
o plano para entregar o incremento do produto e atingir o objetivo da Sprint.
e) DoD, também orienta o Scrum Team no conhecimento de quantos itens do Product

Backlog podem ser selecionados durante a Sprint Planning Meeting.
Comentários:
(a) Errado, as regras integram os eventos, papéis e artefatos, administrando as relações e

interações entre eles. No entanto, ele não é criado na Sprint Review Planning – isso nem faz sentido;
(b) Errado, incremento é a versão potencialmente utilizável do produto – ele é criado no final da
Sprint; (c) Errado, o incremento é a soma de todos os itens do Backlog do Produto completados
durante a Sprint e o valor dos incrementos de todas as Sprints anteriores; (d) Errado, essa seria a
Sprint Backlog; (e) Correto. Ela orienta o Time de Desenvolvimento no conhecimento de quantos
itens do Backlog do Produto podem ser selecionados durante o Planejamento da Sprint. O
propósito de cada Sprint é entregar incrementos de funcionalidades potencialmente liberáveis que
aderem à definição atual de “Pronto” do Time Scrum.
Gabarito: Letra E
49.(FCC / TJ-MA – 2019) Um Analista Judiciário, no papel de Scrum Master, esclarece que:
39

Aula 03
a) o gerenciamento do Product Backlog não fica unicamente na responsabilidade do Product

Owner, mas deve ser compartilhado com o Product Backlog Committee.
b) o Product Owner é uma pessoa ou um comitê. Quando o Product Owner é representado por
um comitê, aqueles que quiserem uma alteração nas prioridades dos itens do Product
Backlog devem endereçá-la ao Committee’s Coordinator.
c) somente integrantes do Development Team criam incrementos e um incremento “Pronto” é

requerido na Revisão da Sprint.
d) o Scrum recomenda que haja apenas quatro subtimes no Development Team relativos aos
domínios de conhecimento: teste, arquitetura, operação e análise de negócios.
e) o Scrum Team consiste de profissionais que realizam o trabalho de entregar um incremento

potencialmente liberável do produto “Pronto” no início de cada Sprint.
Comentários:
(a) Errado, ele é o único responsável pelo gerenciamento do Backlog do Produto; (b) Errado. O
Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um
comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens
de Backlog devem endereçar ao Product Owner; (c) Correto; (d) Errado. Scrum não reconhece sub-
times no Time de Desenvolvimento, independente dos domínios de conhecimento que precisam
ser abordados, tais como teste, arquitetura, operação ou análise de negócios; (e) Errado. O Time de
Desenvolvimento consiste de profissionais que realizam o trabalho de entregar um incremento
potencialmente liberável do produto “Pronto” ao final de cada Sprint.
Gabarito: Letra C
50. (FCC / SEGEP-MA – 2018) O Scrum prescreve quatro eventos formais, contidos dentro dos
limites da Sprint, para inspeção e adaptação. Dois desses eventos são:
a) revisão do backlog e orientação do Scrum Master.

b) preleção do Product Owner e revisão dos requisitos.
c) reunião de revisão da Sprint e descrição de requisitos no backlog.
d) revisão das especificações e reunião de planejamento da Sprint.
e) reunião diária e retrospectiva da Sprint.
Comentários:
A questão insere vários eventos que não existem – os únicos eventos formais listados são: reunião
diária e retrospectiva da sprint.
40

Aula 03
Gabarito: Letra E
51. (FCC / TRT-MG – 2015) Com relação ao Scrum, considere:
I. O Product Owner, ou dono do produto, é responsável por garantir que o Scrum seja entendido
e aplicado. Faz isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum.
É um servo-líder para o Time Scrum.
II. O Scrum Master é o responsável por maximizar o valor do produto e do trabalho do Time de
Desenvolvimento. Como isso é feito pode variar amplamente nas organizações, Times Scrum e
indivíduos.
III. O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um

“Pronto", versão incremental potencialmente utilizável do produto, é criado.
Está correto o que consta APENAS em:
a) I e II.
b) III
c) II e III.
d) II.
e) I e III.
Comentários:
(I) Errado, esse seria o Scrum Master; (II) Errado, essa é uma responsabilidade do Product Owner;
(III) Correto.
Gabarito: Letra B
52. (FCC / TRT-SC – 2013) SCRUM é um framework baseado no modelo ágil. No SCRUM,
a) o scrum team é a equipe de desenvolvimento, necessariamente dividida em papéis como

analista, designer e programador. Em geral o scrum team tem de 10 a 20 pessoas.
b) as funcionalidades a serem implementadas em cada projeto (requisitos ou histórias de

usuários) são mantidas em uma lista chamada de scrum board.
c) o scrum master é um gerente no sentido dos modelos prescritivos. É um líder, um facilitador

e um solucionador de conflitos. É ele quem decide quais requisitos são mais importantes.
d) um dos conceitos mais importantes é o sprint , que consiste em um ciclo de desenvolvimento

que, em geral, tem duração de 4 a 7 dias.
41

Aula 03
e) o product owner tem, entre outras atribuições, a de indicar quais são os requisitos mais
importantes a serem tratados em cada sprint. É responsável por conhecer e avaliar as
necessidades dos clientes.
Comentários:
(a) Errado, esse é o Development Team – que não é dividido em papéis (é multifuncional) e tem
entre 3 e 9 pessoas [Versão 2017]; (b) Errado, são mantidas em uma lista chamada Product Backlog;
(c) Errado, quem decide os requisitos mais importantes é o Product Owner; (d) Errado, a duração é
menos de um mês; (e) Correto.
Gabarito: Letra E
53. (FCC / TRE-CE – 2012) No SCRUM, sprint é:
a) um representante dos stakeholders e do negócio.

b) uma lista de requisitos que tipicamente vêm do cliente.
c) uma lista de itens priorizados a serem desenvolvidos para um software.
d) uma iteração que segue um ciclo (PDCA) e entrega incremento de software pronto.
e) um conjunto de requisitos, priorizado pelo Product Owner.
Comentários:
(a) Errado, isso é o Product Owner; (b) Errado, isso é o Product Backlog; (c) Errado, isso é o Product
Backlog; (d) Correto; (e) Errado, isso é o Product Backlog.
Gabarito: Letra D
54. (FCC / TRT-SP – 2012) Analise o texto:
O Scrum enfatiza o uso de um conjunto de padrões de processos de software que provaram ser
eficazes para projetos com prazo de entrega apertados, requisitos mutáveis e críticos de
negócio. Cada um desses padrões de processos define um conjunto de ações de
desenvolvimento. Uma dessas ações consiste em manter uma lista com prioridades dos
requisitos ou funcionalidades do projeto que fornecem valor comercial ao cliente. Os itens
podem ser adicionados a esse registro em qualquer momento. O gerente de produto avalia o
registro e atualiza as prioridades conforme requisitado. A lista citada no texto é conhecida
como:
a) urgências scrum.
b) registro ágil de requisitos.
c) alterações scrum.
42

Aula 03
d) registro pendente de trabalhos (Backlog).

e) registro iterativo de desenvolvimento (sprint).
Comentários:
De acordo com Roger Pressman: “O Registro Pendente de Trabalhos (Backlog) consiste em uma lista
com prioridades dos requisitos ou funcionalidades do projeto que fornecem valo comercial ao cliente.
Os itens podem ser adicionados a esse registro em qualquer momento (é assim que as alterações são
introduzidas). O gerente do produto avalia o registro e atualiza as prioridades conforme requisitado”.
Gabarito: Letra D
55. (FCC / TRF-2 – 2012) Segundo Roger S. Pressman, em seu livro Engenharia de Software, 7a
edição, os princípios do Scrum são consistentes com o manifesto ágil e são usados para orientar
as atividades de desenvolvimento dentro de um processo que incorpora as atividades
estruturais de requisitos, análise, projeto, evolução e entrega. Em cada atividade metodológica,
ocorrem tarefas a realizar dentro de um padrão de processo chamado:
a) process backlog.
b) scrum master.
c) product owner.
d) backlog.
e) sprint.
Comentários:
Em cada atividade metodológica, ocorrem tarefas a realizar dentro de um padrão de processo

chamado: Sprint. Ciclos completos de desenvolvimento em que, ao final, temos incrementos
potencialmente entreváveis do produto.
Gabarito: Letra E
56. (FCC / INFRAERO – 2011) Um dos principais conceitos do Scrum para atacar a complexidade do
desenvolvimento e gerenciamento de software é a implantação de um controle
descentralizado, capaz de lidar mais eficientemente com contextos pouco previsíveis. Para
tanto, o gerenciamento é distribuído por meio de três agentes independentes que são:
a) Product Owner, Scrum Team e Scrum Master.

b) Product Owner, Product Backlog e Planning Meeting.
c) Product Owner, Sprint e Planning Meeting.
d) Sprint, Scrum Master e Planning Meeting.
e) Sprint, Scrum Team e Product Backlog.
43

Aula 03
Comentários:
O Guia Scrum [Versão 2017] afirma que o Scrum Team é dividido em Product Owner, Scrum Master
e Development Team. No entanto, a banca considerou como resposta correta: Product Owner,
Scrum Team e Scrum Master. Viagem completa da banca...
Gabarito: Letra A
57. (FCC / INFRAERO – 2011) Em relação às regras do Scrum, é INCORRETO afirmar:
a) O Sprint deve ser realizado num período máximo de 40 dias e ter uma equipe de trabalho não
superior a 10 pessoas.
b) Se o Sprint tomar um rumo não desejado, é possível dissolvê-lo e começar um novo Sprint,
baseando num novo Sprint Backlog.
c) As reuniões durante um Sprint devem ser diárias, sempre à mesma hora e no mesmo local e
não devem durar mais que 30 minutos.
d) Toda conversação restringe as respostas dos participantes às três perguntas do Scrum

Master: O que desenvolveu desde a última reunião? Que dificuldades encontrou durante o seu
trabalho? O que planeja desenvolver até a próxima reunião?
e) Com base nas respostas às três perguntas, o Scrum Master deve imediatamente tomar
decisões, quando necessárias, para remover todas as situações que impeçam a agilidade do
trabalho.
Comentários:
(a) Errado. O período máximo é de 30 dias e a equipe de trabalho varia de 3 a 9 pessoas [Versão
2017]; (b) Correto. É possível dissolver uma sprint e começar outra baseando-se em um novo sprint
backlog – quem pode fazer isso é o Product Owner; (c) Correto. Essa questão foi muito polêmica e
eu acho uma sacanagem! A Daily Scrum deve ter no máximo 15 minutos? Sim, mas a questão apenas
afirma que ela não deve durar mais que 30 minutos. Se ela dura no máximo 15 minutos, ela não dura
mais que 30 minutos. Sendo bastante rigoroso no julgamento, o item não está errado, mas isso
prejudica quem estudou e sabe que a reunião tem no máximo 15 minutos; (d) Correto, essas são –
de fato – as perguntas a serem feitas [Versão 2017]; (e) Correto, é exatamente isso que o Scrum
Master deve fazer.
Gabarito: Letra A
58. (FCC / TCE-SE – 2011) Aceita a imprevisibilidade do desenvolvimento de software e a contorna

através da adaptação constante. Destaca-se das demais metodologias ágeis por dar mais
44

Aula 03
enfoque à área de gerenciamento. Seu nome tem origem em um esporte quando jogadores de
cada time colaboram entre si numa tentativa de avançar juntos pelo campo adversário. Tais
características estão presentes no processo:
a) UP.
b) Crystal.
c) XP.
d) DSDM.
e) Scrum.
Comentários:
A questão deu duas dicas: primeiro, ela fala em gerenciamento; segundo, ela fala que o nome é
inspirado em um esporte. Logo, trata-se do Scrum!
Gabarito: Letra E
59. (FCC / TRT-RS – 2011) Para utilizar o processo de estimativa por Story Points em Scrum,
inicialmente:
a) o Product Owner deve atribuir valores de negócio para cada um dos itens do Product Backlog.
b) o Product Backlog deve considerar todos os fatores de Sprint contidos no Backlog Owner.
c) os Stakeholders devem atribuir os riscos do Product Owner para cada Sprint Planning.
d) os Stakeholders devem atribuir valores de negócio do Product Owner para cada Sprint.
e) o Product Planning deve avaliar cada Sprint contida no Backlog transacional e decidir pela
prioridade de atividades.
Comentários:
Essa questão é até engraçada! Os quatro últimos itens não fazem absolutamente nenhum sentido
– o examinador aparentemente saiu trocando palavras de forma aleatória. Não existem os
conceitos de Product Planning, Backlog Transacional, etc. Além disso, os Story Points são uma
unidade de estimativa em relação ao Product Backlog e, não, ao Sprint Backlog.
Gabarito: Letra A
60.(FCC / TRT-RJ – 2011) No SCRUM, o processo de desenvolvimento inicia com uma reunião de
planejamento na qual o Product Owner e a equipe decidem, em conjunto, o que deverá ser
45

Aula 03
implementado do Product Backlog. Assim, a equipe planeja seu trabalho, definindo o Sprint
Backlog, na:
a) primeira parte da Sprint Planning Meeting.

b) segunda parte da Sprint Planning Meeting.
c) terceira parte da Sprint Planning Meeting.
d) Sprint.
e) Sprint Burndown.
Comentários:
Na primeira parte, os desenvolvedores trabalham para prever as funcionalidades que serão

desenvolvidas durante a Sprint. O Product Owner debate a meta a Sprint deve realizar e os itens de
Backlog do Produto que, se completados na Sprint, atingirão a meta. Na segunda parte, tendo
definido o objetivo da Sprint e selecionado os itens de Backlog do Produto da Sprint, os
desenvolvedores decidem como irão construir essas funcionalidades durante a Sprint e transformá-
las em um incremento de produto “Pronto”. Ainda nessa parte: os itens do Backlog do Produto
selecionados para a Sprint junto com o plano de entrega destes itens é chamado de Backlog da
Sprint.
Gabarito: Letra B
61. (FCC / TRE-ES – 2010) Os princípios Scrum são usados para guiar as atividades de
desenvolvimento dentro de um processo que incorpora as seguintes atividades de arcabouço:
requisitos, análise, projeto, evolução e entrega. Em cada atividade de arcabouço, as tarefas de
trabalho ocorrem dentro de um padrão de processo chamado:
a) pendência.
b) iterator.
c) demo.
d) história de usuário.
e) sprint.
Comentários:
O Scrum realiza ciclos completos de desenvolvimento em que, ao final, temos incrementos

potencialmente entregáveis do produto – o nome desses ciclos de desenvolvimento em que tarefas
de trabalho ocorrem é chamado: Sprint!
Gabarito: Letra E
62. (FCC / TRF 4ª – 2010) Na fase de desenvolvimento do Scrum, o software é desenvolvido em

processos iterativos denominados:
46

Aula 03
a) Building Products.
b) Product Backlog.
c) Sprint.
d) Product Owner.
e) Product Backlog Cycle.
Comentários:
O Scrum realiza ciclos completos de desenvolvimento em que, ao final, temos incrementos

potencialmente entregáveis do produto – o nome desses ciclos de desenvolvimento em que o
software é desenvolvido em processos iterativos é chamado: Sprint.
Gabarito: Letra C
63. (FCC / TRE-RS – 2010) Em reunião, toda conversação é restringida às respostas dos elementos
às perguntas colocadas pelo Scrum Master, sendo uma delas: "O que planeja desenvolver até a
próxima reunião?". As Scrum meetings ocorrem:
a) sempre que necessário.

b) ocasionalmente.
c) uma vez por semana.
d) duas vezes por semana.
e) diariamente.
Comentários:
Essa é uma das três perguntas feitas pelo Scrum Master [Versão 2017] e a Scrum Meeting citada é
a Daily Scrum Meeting – também chamada de Reunião Diária.
Gabarito: Letra E
64. (FCC / TRE-RS – 2010) No contexto das regras do SCRUM, é correto afirmar:
a) Durante a realização do Sprint, o Backlog pode ser modificado por qualquer um dos
elementos da equipe, desde que acordado nas reuniões semanais.
b) O Sprint deve ser realizado num período não superior a 30 dias e ter um objetivo bem claro,
baseado no Backlog.
c) Modificação no Backlog é prerrogativa do Scrum Master, quando achar necessário, em

qualquer momento no decorrer do Sprint.
47

Aula 03
d) Não é possível dissolver um Sprint. Se houver algum risco de ele tomar um rumo não
desejável, novas funcionalidades devem ser implementadas para garantir o prazo do projeto.
e) O foco na produtividade se estende às Scrum meetings e a conversação é pautada em

discussões por toda a equipe.
Comentários:
(a) Errado. Backlog? Qual Backlog? Da Sprint? Do Produto? A questão não especificou! De todo
modo, o Product Backlog só pode ser modificado pelo Product Owner e o Sprint Backlog só pode
ser modificado pelo Development Team [Versão 2017]; (b) Correto; (c) Errado. Scrum Master é
apenas um facilitador – quem pode modificar o Product Backlog é o Product Owner; (d) Errado. É
possível, sim, dissolver uma sprint; (e) Errado. Na verdade, as discussões ocorrem mais entre os
desenvolvedores.
Gabarito: Letra B
65. (FCC / TRE-RS – 2010) No SCRUM, o produto final, a data final e o custo do projeto são
determinados:
a) respectivamente, no planejamento, ao longo do projeto, no início do projeto.

b) ao longo do projeto.
c) no planejamento.
d) respectivamente, nas fases intermediárias, no planejamento, no final do projeto.
e) em função das iterações.
Comentários:
No Scrum, o tempo e o custo geralmente são fixos e o escopo é variável, isto é, eu não parto do
escopo fixo para descobrir um tempo variável – eu parto do tempo fixo para descobrir um escopo
variável. Ser fixo não significa que é determinado antes. Eu posso dizer que minha data final é daqui
três meses e a equipe de projeto vai fazer quantas funcionalidades conseguir dentro desse período.
Ao longo do projeto, eu posso dizer que tenho mais três meses para entregar e a equipe dirá que dá
para fazer mais algumas funcionalidades. Então, eu sempre parto do tempo para decidir o escopo
e não do escopo para definir o tempo. Por que? Porque senão o projeto poderia durar eternamente
dado que os requisitos são como organismos vivos e nunca têm fim. O Product Owner
frequentemente pode mudar de ideia, pedir mudanças, adicionar requisitos e o escopo final do
projeto nunca será alcançado, logo nunca chegará ao fim do projeto. Então, o produto final, a data
final e o custo do projeto são determinados.
Gabarito: Letra B
48

Aula 03
66. (FCC / DPE-SP – 2010) Na engenharia de software, um processo iterativo denominado

sprint, que segue o ciclo PDCA para entregar, num período de 30 dias aproximadamente, um
incremento do software pronto, caracteriza a metodologia ágil:
a) SCRUM.
b) DSDM.
c) Crystal.
d) FDD.
e) XP.
Comentários:
Palavras-chave: processo iterativo, sprint, 30 dias, incremento pronto... essas palavras tratam de
uma metodologia ágil chamada Scrum. ==f219==
Gabarito: Letra A
67. (FCC / AFR-SP – 2009) O conceito de sprint aplica-se ao modelo ágil do processo de engenharia
de software denominado:
a) Crystal.
b) XP.
c) DAS.
d) DSDM.
e) Scrum.
Comentários:
O conceito de sprint é um inerentemente do processo de engenharia de software chamado Scrum!
Gabarito: Letra E
49

Aula 03
QUESTÕES COMENTADAS – FGV
68. (FGV / TJDFT – 2022) Uma equipe de analista de sistemas está desenvolvendo o software
ProgramaTJ aplicando a metodologia Lean. A equipe decidiu implementar apenas as
funcionalidades formalmente requisitadas pelo cliente, evitando adicionar qualquer
funcionalidade extra à ProgramaTJ por conta própria.
Essa decisão da equipe remete, de forma direta, ao princípio da metodologia Lean para o
desenvolvimento de software de:
a) otimização do todo;
b) adiar comprometimento;
c) eliminação de desperdícios;
d) respeitar as pessoas;
e) criação de conhecimento.
Comentários:
Trata-se do princípio de eliminar desperdícios! Esse princípio afirma que se deve eliminar tudo que
não é percebido pelo cliente. Funcionalidades extras não são requisitadas pelo cliente, logo devem
ser eliminadas.
Gabarito: Letra C
69. (FGV / TJDFT – 2022) Uma equipe de desenvolvimento de sistemas de software (EDSS) está
trabalhando no desenvolvimento de uma nova aplicação Web utilizando práticas ágeis
alinhadas com o Scrum. Algumas funcionalidades da aplicação Web já foram disponibilizadas
aos clientes, porém um dos Product Owners solicitou mudanças em algumas delas. Sabendo-se
que a EDSS está no meio do andamento de uma Sprint de 4 semanas cujo Sprint Goal não tem
relação direta com as funcionalidades entregues, para atender à solicitação do Product Owner,
a EDSS deve:
a) alterar o prazo planejado para desenvolvimento da Sprint de modo a adicionar a alteração

solicitada;
b) realizar uma Sprint Retrospective para decidir quando adicionar a alteração solicitada;
c) executar uma Sprint Review para determinar as adaptações para adicionar a alteração
solicitada;
50

Aula 03
d) manter o prazo planejado para desenvolvimento da Sprint, removendo um dos itens do Sprint
Backlog para adicionar a alteração solicitada;
e) manter o prazo planejado para desenvolvimento da Sprint, adicionando a alteração solicitada

no Product Backlog.
Comentários:
O guia nos diz que, durante a sprint, não são feitas alterações que possam pôr em perigo o Sprint
Goal e o enunciado afirma que o Sprint Goal não tem relação direta com as funcionalidades
entregues, logo não há que se alterar prazo, remover itens, realizar retrospectivas ou revisões –
basta manter o prazo e adicionar a alteração solicitada.
Alguns alunos argumentaram que o responsável por adicionar itens no Product Backlog é o Product
Owner. No entanto, o guia nos diz que o Product Owner pode fazê-lo ou poderá delegar essa
atividade a outros, mantendo-se responsável pelo Product Backlog. Ainda não saiu o gabarito
definitivo, mas eu acho um recurso difícil.
Gabarito: Letra E
70. (FGV / FUNSAÚDE - 2021) Analise a frase a seguir.
Funciona criando ciclos, conhecidos como sprints, que são os intervalos de tempo para o
desenvolvimento de cada etapa.
Assinale a metodologia ágil de desenvolvimento à qual a frase acima diz respeito.
a) Crystal.
b) Kanban.
c) Lean.
d) Scrum.
e) XP.
Comentários:
Ciclos (Sprints) que funcionam como intervalos de tempo para o desenvolvimento de cada etapa é
uma característica típica do Scrum.
Gabarito: Letra D
71. (FGV / COMPESA – 2018) O SCRUM é um framework para gerenciamento de projetos

complexos, sendo um dos métodos ágeis mais populares do mundo. Uma das dinâmicas
51

Aula 03
definidas no SCRUM é a retrospectiva. Assinale a opção que melhor descreve o objetivo da

retrospectiva definida no SCRUM.
a) Planejar medidas que possam trazer, no próximo Sprint, melhorias relacionadas à

colaboração entre as pessoas, processos ou ferramentas.
b) Inspecionar o resultado do trabalho realizado em um Sprint e ajustar o Backlog do produto,

se necessário.
c) Rever as prioridades dos itens que compõem o Backlog do produto.
d) Planejar como o time construirá as funcionalidades definidas para um Sprint com base nos
resultados obtidos nos Sprints anteriores.
e) Disseminar conhecimento sobre o que foi feito no dia anterior para poder priorizar o trabalho
a ser realizado no dia que se inicia.
Comentários:
A Retrospectiva da Sprint (Proporcional a 3 horas) é uma chance para o Scrum Team inspecionar a
si próprio e criar um plano de melhorias para a próxima sprint. Ela inspeciona como foi a última
sprint em relação às pessoas, às relações, aos processos e às ferramentas. Pode identificar e ordenar
os itens que se tornaram potenciais de melhorias e cria um plano para implementar melhorias no
trabalho.
Dessa forma, temos que: (a) Correto; (b) Errado, isso é a Revisão da Sprint; (c) Errado, isso é
Planejamento da Sprint; (d) Errado, isso é Planejamento da Spring; (e) Errado, isso é Reunião Diária.
Gabarito: Letra A
72. (FGV / AL-RO – 2018) Para o desenvolvimento do Sistema de Informações ao Cidadão (SIC), foi
decidida a utilização de uma metodologia ágil. Segundo o Manifesto Ágil, esta decisão indica
que foi dado maior valor:
a) aos processos e ferramentas.

b) à resposta a modificações.
c) à documentação abrangente.
d) à negociação do contrato.
e) ao cumprimento do plano.
Comentários:
52

Aula 03
Segundo o Manifesto Ágil, esta decisão indica que foi dado maior valor à resposta a modificações.
Vamos relembrar: (1) os indivíduos e suas interações acima de procedimentos e ferramentas; (2) o
funcionamento do software acima de documentação abrangente; (3) a colaboração com o cliente
acima da negociação e contrato; (4) a capacidade de resposta a mudanças acima de um plano pré-
estabelecido.
Gabarito: Letra B
73. (FGV / Banestes – 2018) Com relação aos valores relacionados ao desenvolvimento ágil de
software, NÃO se pode incluir:
a) colaboração do cliente mais que negociação de contratos;

b) indivíduos e iterações mais que processos e ferramentas;
c) rapidez na construção mais que excelência técnica;
d) responder a mudanças mais que seguir um plano;
e) software funcional mais que documentação abrangente.
Comentários:
Todos os itens estão de acordo com o Manifesto Ágil, exceto rapidez na construção mais que
excelência técnica! Isso não faz parte dos valores do desenvolvimento ágil – excelência técnica deve
ser mais importante que a rapidez na construção.
Gabarito: Letra C
74. (FGV / Banestes – 2018) Um dos valores relacionados ao ambiente ágil de desenvolvimento é:
a) documentação abrangente mais que software funcional;

b) negociação de contratos mais que colaboração do cliente;
c) processos e ferramentas mais que indivíduos e iterações;
d) rapidez na construção mais que excelência técnica;
e) responder a mudanças mais que seguir um plano.
Comentários:
O Manifesto Ágil afirma que estavam sendo descobertas maneiras melhores de desenvolver
software. Através do manifesto ágil, passa-se a valorizar: (1) Indivíduos e interações mais que
processos e ferramentas; (2) Software em funcionamento mais que documentação abrangente; (3)
Colaboração com o cliente mais que negociação de contratos; (4) Responder a mudanças mais que
seguir um plano.
Gabarito: Letra E
53

Aula 03
75. (FGV / TJ-SC – 2015) O SCRUM, processo para o desenvolvimento de software ágil, estrutura-
se sobre:
a) plan, documentaton, test;

b) roles, artifacts, activities;
c) requisites, code, products;
d) client team, development team, deliverables;
e) interface, data, code.
Comentários:
O Scrum trata de Papeis (Roles), Artifacts (Artefatos) e Eventos (Activities). A tradução desse último
termo ficou péssima infelizmente.
Gabarito: Letra B
76. (FGV / PGE-RO – 2015) Durante 5 anos gerenciando o desenvolvimento de sistemas de

informação, Claudia teve que lidar com diversas insatisfações de seus usuários pois os sistemas
não atendiam as suas necessidades. Claudia decidiu, então, implantar métodos ágeis de
desenvolvimento e definiu os seguintes princípios:
I. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
II. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de
desenvolvimento é através da documentação.
III. Simplicidade é essencial.
Dentre os princípios definidos por Claudia, o que infringe os princípios do manifesto para
Desenvolvimento Ágil de Software é o que se afirma em:
a) somente I;
b) somente II;
c) somente III;
d) somente I e III;
e) I, II e III.
Comentários:

vantagem das mudanças visando vantagem competitiva para o cliente. As Metodologias Tradicionais são
preditivas – já vimos que esse cenário é ilusório.
54

Aula 03
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é
através de conversa face a face. As Metodologias Tradicionais utilizam documentos, diagramas, relatórios,
telefonemas para promover a comunicação no projeto.
Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial. As Metodologias
Tradicionais, algumas vezes, recorriam a implementações desnecessariamente complexas, a planejamentos
exageradamente detalhados, entre outros.
(I) Correto. Mudanças são sempre bem-vindas; (II) Errado, o método mais eficiente é frente-a-
frente; (III) Correto. Como a questão pede os princípios que infringem o manifesto ágil, trata-se da
segunda opção.
Gabarito: Letra B
77. (FGV / TJ-RO – 2015) O manifesto ágil tem por princípio que:
a) mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento;
b) a contínua atenção à excelência técnica reduz a agilidade;
c) a redução do backlog é a medida primária de progresso;
d) as melhores arquiteturas, requisitos e designs emergem de equipes que possuem um bom

líder;
e) pessoas de negócio e desenvolvedores devem trabalhar em ambientes separados para reduzir

as interferências no processo de desenvolvimento.
Comentários:

vantagem das mudanças visando vantagem competitiva para o cliente. As Metodologias Tradicionais são
preditivas – já vimos que esse cenário é ilusório.
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. As
Metodologias Tradicionais não valorizavam essa colaboração intensa entre clientes e desenvolvedores,
como faz o Ágil.
Software funcionando é a medida primária de progresso. As Metodologias Tradicionais propunham a

entrega de artefatos (Ex: Documentação) que, em geral, não agregavam valor algum aos clientes, como
também uma forma de medir o progresso do projeto.
Contínua atenção à excelência técnica e bom design aumenta a agilidade. As Metodologias Tradicionais
acreditavam que, para se obter máxima velocidade e flexibilidade no desenvolvimento de software, poder-
se-ia sacrificar a qualidade deste software.
55

Aula 03
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. As Metodologias

Tradicionais geralmente precisam de um gerente de projetos responsável por organizar o trabalho da equipe
como um todo, sendo também responsável pela tomada de decisões.
O único princípio correto é que mudanças nos requisitos são bem-vindas, mesmo tardiamente no
desenvolvimento.
Gabarito: Letra A
78. (FGV / Câmara Municipal de Caruaru - PE – 2015) O desenvolvimento ágil de software é guiado
por metodologias que compartilham um conjunto comum de valores e de princípios, conforme
definido pelo Manifesto Ágil. Assinale a opção que indica um princípio do desenvolvimento ágil.
a) As mudanças nos requisitos devem ocorrer dentro do quadro de tempo estabelecido para a
iteração.
b) O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de
desenvolvimento é por meio de conversa face a face.
c) Os intervalos regulares devem ser evitados para tornar a equipe mais eficaz e maximizar a
quantidade de trabalho realizado.
d) As pessoas de negócio e desenvolvedores devem interagir somente no início de cada iteração.
e) A entrega contínua e adiantada de software, mesmo que o conjunto de funcionalidades
desenvolvidas não agregue valor, deve ser feita para satisfazer o cliente.
Comentários:
(a) Errado, idealmente devem ser feitas antes do início da iteração ou podem ser feitas durante o
período da iteração desde que não afetem os objetivos dela; (b) Correto; (c) Errado, os intervalos
regulares devem ser incentivados e, não, evitados; (d) Errado, devem interagir durante todo
período do projeto; (e) Errado, as entregas devem sempre agregar algum valor.
Gabarito: Letra B
79. (FGV / DPE-RO – 2015) O Manifesto Ágil é uma declaração que reúne os princípios e práticas
que fundamentam o desenvolvimento ágil de software. É um dos princípios desse manifesto:
a) defeitos no software são a medida primária de progresso;

b) pessoas de negócio e desenvolvedores devem trabalhar isoladamente e se reunir somente ao
final de cada iteração para validação do software;
c) atenção contínua à excelência técnica deve ser evitada para não afetar a agilidade uma vez
que simplicidade é essencial;
d) os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo
constante indefinidamente evitando interrupções e intervalos regulares;
e) as melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
56

Aula 03
Comentários:
(a) Errado, software funcional é a medida primária de progresso; (b) Errado, pessoas relacionadas à
negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do
projeto; (c) Errado, contínua atenção à excelência técnica e bom design, aumenta a agilidade; (d)
Errado, em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e
otimizam seu comportamento de acordo; (e) Correto, as melhores arquiteturas, requisitos e
designs emergem de equipes auto-organizáveis. As metodologias tradicionais geralmente
precisam de um gerente de projetos responsável por organizar o trabalho da equipe como um todo,
sendo também responsável pela tomada de decisões. Nas metodologias ágeis, as equipes são auto-
organizadas.
Gabarito: Letra E
80.(FGV / DPE-RO – 2015) Uma metodologia de desenvolvimento de software é um conjunto

estruturado de práticas que auxiliam o processo de produção de software. Em geral, a adoção
de uma metodologia é significativamente melhor do que uma abordagem casual de
desenvolvimento de software. Em relação a metodologias de desenvolvimento de software,
analise as afirmativas a seguir:
I - O Scrum é uma metodologia de desenvolvimento ágil que emprega uma abordagem iterativa
e incremental para aperfeiçoar a previsibilidade e o controle de riscos.
II - A programação em dupla num único computador é uma característica da metodologia RUP

(Rational Unified Process) como uma forma de evitar e diminuir a possibilidade de defeitos.
III - Metodologias ágeis tentam minimizar o risco por meio do desenvolvimento do software em
longos períodos, evitando que funcionalidades do software sejam entregues frequentemente.
Está correto o que se afirma em:
a) somente I;
b) somente II;
c) somente III;
d) somente I e II;
e) I, II e III.
Comentários:
(I) Correto, todas essas são características do Scrum; (II) Errado, essa é uma característica do XP
(Extreme Programming) e, não, do RUP; (III) Errado, o desenvolvimento ocorre em curtos períodos,
incentivando a entrega frequente de funcionalidades de software.
57

Aula 03
Gabarito: Letra A
81. (FGV / PROCEMPA – 2014) O Manifesto Ágil é uma declaração de princípios que fundamentam
o desenvolvimento ágil de software. A respeito desses princípios, assinale a afirmativa correta.
a) As melhores arquiteturas, requisitos e designs emergem de equipes lideradas pelo

profissional mais sênior.
b) Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e
ajusta seu comportamento de acordo.
c) Pessoas de negócio e desenvolvedores devem trabalhar separadamente por todo o projeto.
d) Entregar software quando há poucas semanas de desenvolvimento deve ser evitado para não
afetar a satisfação do cliente.
e) Mudanças nos requisitos são bem-vindas, desde que não impactem o desenvolvimento.
Comentários:
(a) Errado, emergem de equipes auto-organizáveis; (b) Correto; (c) Errado, devem trabalhar em
conjunto; (d) Errado, deve ser incentivado a entrega frequente desde o início; (e) Errado, mudanças
são bem-vindas mesmo que impactem o desenvolvimento.
Gabarito: Letra B
82. (FGV / TJ-GO – 2014) O Manifesto Ágil lista valores seguidos por desenvolvedores com a
finalidade de melhorar a maneira pela qual o software é desenvolvido. A alternativa que se
encontra no manifesto é:
a) seguir um plano mais que responder a mudanças;

b) indivíduos e interações mais que processos e ferramentas;
c) documentação abrangente mais que software em funcionamento;
d) negociação de contratos mais que colaboração com o cliente;
e) negociação de contratos mais que indivíduos e interações.
Comentários:
(a) Errado, está invertido; (b) Correto; (c) Errado, está invertido; (d) Errado, está invertido; (e)
Errado, indivíduos e interações mais que processos e ferramentas.
Gabarito: Letra B
83. (FGV / DPE-RJ – 2014) Uma das características da metodologia ágil Scrum é:
a) focar nas práticas de engenharia.
58

Aula 03
b) focar na documentação formal do software.

c) ser um método iterativo e incremental.
d) exigir o planejamento do projeto, de acordo com as práticas do PMBOK.
e) não exigir interação com o cliente.
Comentários:
(a) Errado, ele se foca no empirismo e experiências práticas; (b) Errado, ele se foca no software em
funcionamento; (c) Correto; (d) Errado, ele se foca mais em responder rapidamente a mudanças do
que seguir um planejamento; (e) Errado, a colaboração com cliente é mais importante até que
negociações e contratos.
Gabarito: Letra C
84.(FGV / TJ-AM – 2013) Com relação aos princípios do modelo ágil de processo Scrum, analise as
afirmativas a seguir.
I. O processo precisa ser adaptável tanto a modificações técnicas quanto de negócios "para
garantir que o melhor produto possível seja produzido".
II. O trabalho de desenvolvimento e o pessoal que o realiza é dividido "em partições claras, de
baixo acoplamento ou em pacotes".
III. O processo produz frequentes incrementos de software "que podem ser inspecionados,
ajustados, testados, documentados e expandidos".
Assinale:
a) se somente a afirmativa I estiver correta.

b) se somente a afirmativa II estiver correta.
c) se somente a afirmativa III estiver correta
d) se somente as afirmativas I e II estiverem corretas.
e) se todas as afirmativas estiverem corretas.
Comentários:
(I) Correto, é exatamente por essa razão que ele é considerado um modelo ágil; (II) Correto, mas
com uma enorme ressalva: a fonte dessa questão foi o livro do Roger Pressman e ele realmente
afirma exatamente o que está escrito no item. No entanto, a fonte oficial deveria ser sempre o Guia
Oficial, justamente para evitar problemas! O que o Pressman afirma não faz nenhum sentido: pode-
se até afirmar que o trabalho é dividido em partições contidas nas sprints, mas o pessoal/equipe não
se divide – o próprio guia afirma que times de desenvolvimento não contém sub-times dedicados a
domínios específicos de conhecimento, logo a questão está flagrantemente errada. No entanto,
59

Aula 03
como a banca retirou a questão literalmente do Pressman, foi considerada como correta; (III)
Correto, o incremento é parte fundamental do modelo ágil.
Gabarito: Letra E
85. (FGV / MPE-MS – 2013) Em Scrum, pode-se utilizar diversas técnicas para estimar o que será
feito durante o projeto ou na próxima “Sprint”. A respeito da estimativa chamada de “Story
Points”, analise as afirmativas a seguir.
I. A estimativa de uma “User Story” com “Story Points” pode ser feita através da dinâmica
chamada de “Planning Poker”.
II. As estimativas usando “Story Points” são feitas por especialistas em estimativas e, em
seguida, validadas por todo o time.
III. A escala (1, 2, 3, 5, 8, 13, 20, 40, 100), usada para definir os “Story Points”, é inspirada na
sequência de Fibonnacci.
Assinale:
a) se somente a afirmativa III estiver correta

b) se somente as afirmativas I e III estiverem corretas
c) se somente as afirmativas II, III estiverem corretas
d) se somente as afirmativas I e II estiverem corretas
e) se todas as afirmativas estiverem corretas
Comentários:
(I) Correto. Uma das melhores formas de estimar Story Points é por meio de uma técnica chamada
Planning Poker, que não está no guia oficial, mas que é frequentemente utilizada tanto para estimar
esforço como para estimar tamanho; (II) Errado. A questão dá a entender que as estimativas são
feitas por especialistas externos, quando são feitas pelos próprios desenvolvedores e são validadas
por todo o time de desenvolvimento – a questão não especificou qual time. (III) Correto. Em geral,
os valores seguem uma escala baseada na Sequência de Fibonacci.
Gabarito: Letra B
86. (FGV / Senado Federa l – 2012) Com relação ao método ágil de desenvolvimento conhecido
como Scrum, analise as afirmativas a seguir.
I. Cada iteração do processo de desenvolvimento é denominada Sprint.

II. O Backlog do Produto é uma lista de itens priorizados, composta por requisitos e
funcionalidades que devem ser construídos para concretizar a visão.
60

Aula 03
III. No início de cada Sprint, a equipe se reúne para escolher os itens a serem desenvolvidos até
o final dessa iteração, o que dá origem ao Backlog do Sprint.

c) se somente a afirmativa III estiver correta.
Comentários:
(I) Correto, uma sprint é basicamente uma iteração; (II) Correto, o backlog do produto contém
requisitos de funcionalidades priorizadas para concretizar a visão; (III) Correto, trata-se do
planejamento da sprint.
Gabarito: Letra E
87. (FGV / MEC – 2009) Scrum é uma metodologia ágil para gestão e planejamento de projetos
de software. No Scrum, os projetos são divididos em ciclos chamados:
a) Product Backlog.
b) Sprint Backlog.
c) Scrum Master.
d) Daily Scrum.
e) Sprints.
Comentários:
No Scrum, os projetos são divididos em ciclos chamados sprints.
Gabarito: Letra E
61

Aula 03
QUESTÕES COMENTADAS – DIVERSAS BANCAS
A questão 86 baseia-se na Figura 11, que exibe a imagem de um gráfico elaborado no framework
Scrum, sobre o qual, considere os seguintes aspectos: (1) o eixo horizontal mostra, da esquerda para
a direita, os dias de uma Sprint; (2) o eixo vertical exibe, de cima para baixo, em porcentagem, a
quantidade de trabalho que ainda precisa ser feita; e (3) a linha tracejada exibe o esforço estimado,
enquanto a linha contínua mostra o esforço atual.
88. (FUNDATEC / ISS-Porto Alegre – 2022) No framework "Scrum", a equipe pode monitorar
seu progresso ao final de cada Sprint por meio do gráfico mostrado na Figura 17, o qual é
chamado de:
a) Sprint Planning Meeting.

b) Release Burndown Chart.
c) Release Planning Meeting.
d) Sprint Retrospective Chart.
e) Sprint Review Meeting Chart.
Comentários:
O artefato que permite que a equipe monitore seu progresso ao final de cada sprint é o Gráfico de
Burndown ou Release Burndown Chart. Todas as outras opções apresentam eventos!
Gabarito: Letra B
89. (FUNDATEC / ISS-Porto Alegre – 2022) No framework "Scrum", elabora-se uma lista
ordenada de tudo que é conhecido ser necessário no produto. Sobre essa lista, considere, ainda,
as seguintes características: (1) ela é a única origem dos requisitos para qualquer mudança a ser
feita no produto; (2) essa lista é dinâmica, mudando constantemente para identificar o que o
produto necessita para ser mais apropriado, competitivo e útil; (3) ela evolui tanto quanto o
62

Aula 03
produto e o ambiente no qual ele será utilizado; (4) nessa lista, constam todas as características,
funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no
produto nas futuras versões. Nesse caso, pode-se afirmar que tal lista é chamada de:
a) Incremento.
b) Sprint Backlog.
c) Backlog Planning.
d) Product Backlog.
e) Definição de Pronto.
Comentários:
Única origem de requisitos para qualquer mudança a ser feita no produto? Pronto! Já dava para matar
a questão: Product Backlog!
Gabarito: Letra D
90.(CESGRANRIO / Banco da Amazônia – 2021) “O Scrum é um arcabouço que ajuda pessoas,

times e organizações a gerar valor por meio de soluções adaptativas para problemas
complexos.”
SCHWABER, K. ; SUTHERLAND, J. O Guia do Scrum, O Guia Definitivo para o Scrum: As Regras do Jogo. Nov. 2020. p 3. Adaptado.
Para cumprir seu objetivo, o Scrum se baseia em quatro eventos formais, contidos dentro de um
evento de maior duração: a Sprint. Tais eventos formais implementam os três pilares empíricos
do Scrum, que são:
a) compromisso, abertura e adaptação

b) respeito, coragem e foco
c) respeito, inspeção e adaptação
d) transparência, compromisso e respeito
e) transparência, inspeção e adaptação
Comentários:
Os três pilares são o TIA (Transparência, Inspeção e Adaptação).
Gabarito: Letra E
91. (COMPERVE / TJ-RN – 2020) O Scrum é um framework dentro do qual as pessoas podem tratar
e resolver problemas de forma ágil. O coração do Scrum são suas sprints. Segundo
o Scrum Guide, em um projeto que adota Scrum, a autoridade de cancelar uma sprint cabe ao:
a) Time scrum.
b) Scrum Master.
63

Aula 03
c) Product Owner.
d) Team manager.
Comentários:
Apenas o Product Owner tem autoridade para cancelar a sprint.
Gabarito: Letra C
92. (INSTITUTO AOCP / Prefeitura de Novo Hamburgo - RS – 2020) Assinale a alternativa que
apresenta uma metodologia para desenvolvimento de software:
a) BIM
b) BALANCED SCORECARD
c) COBIT
d) SCRUM
e) ISACA
Comentários:
(a) Errado, desconheço essa sigla; (b) Errado, trata-se de uma metodologia para medição e gestão
de desempenho; (c) Errado, trata-se de um framework de boas práticas para governança de
tecnologia da informação; (d) Correto; (e) Errado, trata-se de uma associação internacional que
suporta e patrocina o desenvolvimento de metodologias e certificações para o desempenho das
atividades de auditoria e controle em sistemas de informação.
Gabarito: Letra D
93. (UFCG / UFCG – 2019) A respeito do framework de trabalho Scrum, marque a alternativa
correta:
a) O eixo X do gráfico de burn-down representa a entrega planejada, em horas de trabalho ou

em pontos de histórias.
b) Essa framework não prevê acompanhamento diário, logo, a equipe se reúne somente no final
de uma sprint.
c) O Product Backlog é uma lista de funcionalidades esperadas para um produto.
d) Foco, comprometimento e respeito não fazem parte dos valores de Scrum.
e) Uma equipe Scrum é composta exclusivamente por um Product Owner e desenvolvedores,
sem ninguém responsável pelo treinamento desses desenvolvedores.
Comentários:
64

Aula 03
(a) Errado. O gráfico possui um eixo X que representa o tempo, que pode ser medido em dias,
semanas, sprints, entre outros. Enquanto o eixo Y demonstra a entrega planejada, que pode ser em
horas de trabalho ou em pontos de histórias; (b) Errado, uma das cerimônias é justamente a reunião
diária; (c) Correto; (d) Errado, os valores são justamente foco, comprometimento e respeito – além
de abertura e coragem; (e) Errado, há também o Scrum Master.
Gabarito: Letra C
94.(VUNESP / Prefeitura de Campinas – SP – 2019) No método ágil Scrum, há um artefato

denominado backlog, aplicado a diversas etapas do método. Em particular, o backlog do
produto corresponde a:
a) um conjunto de todos os produtos de software já desenvolvidos com o uso do Scrum.

b) uma lista das funcionalidades a serem implementadas no produto.
c) uma relação dos analistas envolvidos no desenvolvimento do produto.
d) um conjunto de normas seguidas pela empresa proprietária do produto.
e) uma relação dos futuros usuários do produto.
Comentários:
O Backlog do Produto é uma lista das funcionalidades a serem implementadas no produto –

nenhum dos outros itens faz qualquer sentido.
Gabarito: Letra B
95. (INSTITUTO AOCP / IBGE – 2019) O time de desenvolvimento de software do IBGE está
utilizando o método ágil Scrum para desenvolvimento de software. Sabendo disso, analise as
assertivas a respeito do framework do Scrum e assinale a alternativa que aponta a(s) correta(s).
I. Os papéis definidos pelo Scrum são: times de desenvolvimento, gerente de projetos e product
owner (PO).
II. A sprint retrospective proporciona ao time do Scrum uma oportunidade de avaliar o que foi
bem e o que pode ser melhorado na sprint que acabou de ser finalizada.
III. Apesar da importância do product backlog, ele não é o verdadeiro artefato do Scrum.
Assim, o seu verdadeiro artefato é o requisito do usuário.
a) Apenas I.
b) Apenas II.
c) Apenas III.
d) Apenas I e II.
e) Apenas II e III.
65

Aula 03
Comentários:
(I) Errado, é Product Owner, Scrum Master e Time de Desenvolvimento [Versão 2017] ou
Desenvolvedores [Versão 2020]; (II) Correto; (III) Errado, é claro que é um verdadeiro artefato.
Gabarito: Letra B
96. (INSTITUTO AOCP / EMPREL – 2019) Assinale a alternativa que apresenta uma das
características do Scrum referente ao Scrum Team (Time Scrum):
a) O time valida com o cliente as características (features) ou requisitos do produto.

b) Um líder determina como é a distribuição das tarefas e a programação aos pares.
c) O líder do time Scrum deve priorizar as funcionalidades que serão desenvolvidas.
d) É auto-organizável e não ultrapassa sete pessoas em sua composição.
e) Reuniões diárias são realizadas para possibilitar a interatividade das tarefas.
Comentários:
(a) Errado, o Product Owner valida com o cliente as características; (b) Errado, os desenvolvedores
são auto-organizados [Versão 2017] ou auto-gerenciados [Versão 2020]; (c) Errado, não existe um
líder e quem prioriza as funcionalidades é o Product Owner; (d) Errado, é realmente auto-
organizado [Versão 2017] ou auto-gerenciados [Versão 2020], mas a sua composição é de 5 a 11
pessoas [Versão 2017] ou normalmente 10 pessoas ou menos [Versão 2020]. Logo, não vejo essa
limitação de sete pessoas; (e) Errado, são realizadas para possibilitar a interatividade dos
desenvolvedores.
Gabarito: Letra D
97. (CESGRANRIO / UNIRIO – 2019) Uma equipe de desenvolvimento adota o método SCRUM
para gerenciar seu projeto. Para iniciar a reunião de planejamento da Sprint, deve(m)-se definir
e atualizar:
a) o Backlog do Produto
b) o plano de revisão da Sprint
c) o plano de retrospectiva da Sprint
d) a função de cada membro da equipe de desenvolvimento
e) as tarefas necessárias para cada história do usuário
Comentários:
Para iniciar a Reunião de Planejamento da Sprint, deve-se atualizar o backlog do produto.
Gabarito: Letra A
66

Aula 03
98. (CS-UFG / Prefeitura de Goianira - GO – 2019) De acordo com o Guia do Scrum,

uma sprint tem um período de duração de um mês aproximadamente, em que uma entrega,
versão incremental potencialmente utilizável, do produto é criada. Quais são, respectivamente
no tempo, os quatro eventos que constituem a sprint?
a) Reunião de escolha do backlog, reunião diária, reunião de refinamento e acompanhamento.

b) Reunião de planejamento, reunião diária, revisão e acompanhamento.
c) Reunião de escolha do backlog, reunião diária, reunião de refinamento e retrospectiva.
d) Reunião de planejamento, reunião diária, revisão e retrospectiva.
Comentários:
A ordem correta é: (1) Reunião de Planejamento da Sprint; (2) Reunião Diária; (3) Revisão da Sprint;
(4) Retrospectiva da Sprint.
Gabarito: Letra D
99. (IF-MT / IF-MT– 2019) Sutherland (2016), co-criador do Scrum, sugere que, para a
implementação de um projeto Ágil Scrum, algumas definições são a chave para sua condução e
sucesso.
I - Existe e evolui ao longo de toda a vida do produto, é o mapa do produto, é a visão única e
definitiva de "tudo que a equipe poderia um dia vir a realizar, em ordem de prioridade".
II - Tem a visão do que a equipe fará, produzirá ou realizará. Leva em consideração os riscos e
recompensas.
III - Treinará e ajudará outros integrantes da equipe a eliminarem qualquer coisa que esteja
diminuindo seu ritmo.
IV - Tem uma duração determinada que deve ser de menos do que um mês. Possui meta para
cada ciclo, e os ciclos são planejados para que nada seja alterado até sua conclusão.
Essas sentenças referem-se, respectivamente:
a) Scrum Master, Sprint, Product Owner e Backlog.

b) Sprint, Product Owner, Scrum Master e Backlog.
c) Backlog, Scrum Master, Product Owner e Sprint.
d) Sprint, Scrum Master, Product Owner e Backlog.
e) Backlog, Product Owner, Scrum Master e Sprint.
Comentários:
(I) Backlog do Produto: existe e evolui ao longo de toda a vida do produto, é o mapa do produto, é
a visão única e definitiva de "tudo que a equipe poderia um dia vir a realizar, em ordem de
67

Aula 03
prioridade"; (II) Product Owner: tem a visão do que a equipe fará, produzirá ou realizará. Leva em
consideração os riscos e recompensas; (III) Scrum Master: treinará e ajudará outros integrantes da
equipe a eliminarem qualquer coisa que esteja diminuindo seu ritmo; (IV) Sprint: tem uma duração
determinada que deve ser de menos do que um mês. Possui meta para cada ciclo, e os ciclos são
planejados para que nada seja alterado até sua conclusão.
Gabarito: Letra E
100. (IF-PE / IF-PE – 2019) A reunião de balanço sobre o que foi realizado durante uma sprint e
onde o time deve mostrar ao product owner os resultados obtidos é chamada de:
a) planejamento da sprint.
b) retrospectiva da sprint.
c) reunião diária.
d) revisão da sprint.
e) reunião de estimativas.
Comentários:
O enunciado trata da Revisão da Sprint – ela avalia o produto em si.
Gabarito: Letra D
101. (IF-PE / IF-PE – 2019) São características inerentes ao SCRUM:
I. implementação do conceito interativo e incremental no desenvolvimento de software e/ou

produtos.
II. a programação em pares.
III. valorização dos indivíduos envolvidos na construção do software.
Está(ão) CORRETO(S), apenas, o(s) item(ns):
a) I.
b) I e III.
c) I e II.
d) II e III.
e) I,II e III.
Comentários:
(I) Correto, apesar do deslize de chamar de interativo em vez de iterativo; (II) Errado, essa é uma
característica de uma metodologia ágil de desenvolvimento de software chamada Extreme
Progamming; (III) Correto, valorizam-se mais os indivíduos do que processos e ferramentas.
68

Aula 03
Gabarito: Letra B
102. (COMPERVE / UFRN – 2019) O Scrum é um framework no qual as pessoas podem abordar
problemas adaptativos complexos ao mesmo tempo em que entregam, de maneira produtiva e
criativa, produtos de mais alto valor possível. Nesse framework, existem três papéis
importantes, que são:
a) product owner, development team e scrum master.

b) product manager, scrum team e scrum master.
c) product leader, development team e scrum master.
d) product scrum, development team e development master.
Comentários:
Os três papeis importantes são: Product Owner, Scrum Master e Development Team [Versão 2017]
ou Developers [Versão 2020].
Gabarito: Letra A
103. (COSEAC / UFF – 2019) Em relação aos métodos ágeis, o responsável por garantir que a
equipe está aderindo aos valores do Scrum é representado por:
a) product owner.
b) time.
c) scrum master.
d) gerente de projetos.
e) stakeholders.
Comentários:
O responsável por garantir que a equipe está aderindo aos valores do Scrum é o Scrum Master.
Gabarito: Letra C
104. (IF-PA / IF-PA – 2019) A gestão de projetos é um dos grandes desafios no desenvolvimento
de produtos de software, pois uma gestão padronizada, aliada às boas práticas de
desenvolvimento minimizam os fracassos nos projetos de softwares. O Scrum é um dos
frameworks mais utilizados na gestão de projetos de software e sobre ele é correto afirmar.
a) Por definição, o seu ciclo é composto pela seguinte sequência: “Sprint”, “Sprint View” e “Daily
Scrum”.
69

Aula 03
b) Por definição, “Sprint Review” é uma reunião informal que ocorre ao final de cada “Sprint”
para avaliar o que foi feito, e se necessário, adaptar o “Backlog do Produto”.
c) O “Sprint Retrospective” é um plano feito pelo “Product Owner”, que demonstra como se
espera que o produto evolua ao longo do tempo.
d) O “Daily Review” é um evento de curta duração realizado todos os dias durante um “Sprint”,
neste evento, a equipe de desenvolvimento planeja o trabalho das próximas 24 horas.
e) É de responsabilidade exclusiva do “Scrum Master” a gerência dos itens do “Product Backlog”,

bem como as suas prioridades e objetivos do projeto.
Comentários:
(a) Errado, a sequência é Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective; (b)
Correto, o guia afirma que se trata de uma reunião informal, não uma reunião de status, e a
apresentação do incremento destina-se a motivar e obter feedback e promover a colaboração; (c)
Errado, não é um plano, não é um feito pelo Product Owner e não demonstra como se espera que
o produto evolua ao longo do tempo – tudo errado no item; (d) Errado, não existe evento chamado
Daily Review; (e) Errado, é de responsabilidade do Product Owner.
Gabarito: Letra B
105. (FUNDATEC / Prefeitura de Gramado – RS – 2019) De acordo com o guia Scrum, analise as
assertivas a seguir:
I. Scrum é um framework para planejamento, programação e manutenção de produtos simples.

II. Três são os pilares para toda a implementação de um controle de processo empírico:
transparência, inspeção e adaptação.
III. O Scrum Team consiste de um Product Owner, o Development Team, e de um Scrum
Master.
IV. A Product Backlog é uma lista ordenada de tudo o que é conhecido como necessário ao
produto.
Quase estão corretas?
a) Apenas I e II.
b) Apenas II e III.
c) Apenas III e IV.
d) Apenas II, III e IV
e) I, II, III e IV.
Comentários:
70

Aula 03
(I) Errado, Scrum é um framework leve, simples de entender e extremamente difícil de dominar,
para desenvolver e manter produtos complexos e adaptativos, enquanto entrega produtiva e
criativamente produtos com o mais alto valor possível; (II) Correto; (III) Correto, sendo que na última
versão temos Desenvolvedores em vez de Time de Desenvolvimento; (IV) Correto.
Gabarito: Letra D
106. (CESGRANRIO / TRANSPETRO – 2018) Quando ocorre, no SCRUM, a reunião de

Retrospectiva da Sprint?
a) No fim da Sprint, antes da Reunião de Revisão

b) Entre a Reunião de Revisão da Sprint e a de Planejamento da próxima Sprint
c) No início da Sprint, após a Reunião de Planejamento
d) No final de cada dia da Sprint
e) No início de cada dia da Sprint
Comentários:
A Retrospectiva da Sprint é a última reunião do Scrum, ocorrendo logo após a Revisão da Sprint. A
Revisão da Sprint busca avaliar o produto e a Retrospectiva da Sprint busca avaliar o Processo.
Gabarito: Letra B
107. (CESGRANRIO / TRANSPETRO – 2018) No uso de alguns métodos ágeis, como o SCRUM,
é comum que o esforço de desenvolvimento seja avaliado por meio de Pontos de História (Story
Points). Essa metodologia usa cartas, semelhantes a cartas de baralho, onde cada uma
apresenta um valor de uma escala de valores numéricos, que, normalmente, segue a seguinte
sequência:
a) 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10.
b) 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100.
c) 0, 1, 2, 4, 8, 16, 32, 64, 128.
d) 1, 2, 3, 6, 12, 24, 48, 96.
e) 1, 5, 10, 50, 100, 500, 1000.
Comentários:
No início do Planning Poker, cada membro do time recebe um conjunto de cartas. Cada carta exibe
um dos valores válidos para a estimativa (0, 1, 2, 3, 5, 8, 13, 20, 40, e 100, por exemplo). Em geral,
os valores seguem uma escala baseada na Sequência de Fibonacci. Nota: outra sequência pode ser
escolhida, porém Fibonacci é a mais utilizada.
71

Aula 03
Gabarito: Letra B
108. (FAURGS / TJ-RS - 2018) Considere as seguintes afirmações sobre SCRUM.
I - Um sprint do SCRUM é uma unidade de planejamento na qual o trabalho a ser feito é avaliado,
os recursos para o desenvolvimento são selecionados e o software é implementado.
II - O ponto de partida para o planejamento é o backlog do produto, que é a lista do trabalho que
será feito no projeto. Durante a fase de avaliação do sprint, esta lista é revista e as prioridades e
os riscos são identificados. O cliente está totalmente envolvido nesse processo e, no início de
cada sprint, pode introduzir novos requisitos ou tarefas.
III - No SCRUM, há o papel do product owner, que é um facilitador que organiza reuniões diárias,
controlando o backlog de trabalho, registrando decisões, medindo o progresso, comparando-o
ao backlog e se comunica com os clientes e a gerência externa à equipe.
Quais estão corretas?
a) Apenas I.
b) Apenas I e II.
c) Apenas I e III.
d) Apenas II e III.
e) I, II e III.
Comentários:
(I) Correto, é durante a sprint que o software (ou outro produto) é implementado e avaliado com os
recursos necessários; (II) Correto, perfeita definição; (III) Errado, o facilitador é o Scrum Master e,
não, Product Owner.
Gabarito: Letra B
109. (Instituto Excelência / Prefeitura de São Carlos - SP – 2018) Considerando o Scrum, e os

papeis de partes interessadas, equipe e usuários. Avaliando as descrições abaixo defina os
papeis nas alternativas a seguir.
I) Atua como uma ponte entre a área de negócios, participa do planejamento das tarefas e do
objetivo define critérios de aceitação, este se compromete a não trazer mudanças dentro de
uma Sprint.
II) Assegura para que a equipe siga os valores e práticas, protege a equipe de alterações da Sprint
atua como facilitador removendo qualquer obstáculo ou algo levantado pela equipe
72

Aula 03
III) Lista contendo todas as funcionalidades desejada dos produtos com o tempo cresce ou muda
de acordo que se aprende sobre o usuário e seu produto:
a) I. Scrum Master II. Product Owner III. Product Backlog

b) I. Product Owner. II. Scrum Master. III. Product Backlog.
c) I. Sprint Master. II. Product Backlog. III. Scrum Master.
d) I. Product Backlog. II. Scrum Owner. III. Product Master.
e) Nenhuma das alternativas.
Comentários:
(I) Product Owner; (II) Scrum Master; (III) Product Backlog.
Gabarito: Letra B
110. (INSTITUTO AOCP / PRODEB – 2018) O SCRUM é um método ágil que caracteriza-se por
ter bem definido quais são os papéis que precisam estar envolvidos no desenvolvimento do
projeto. Sendo estes:
a) Scrum Master, Gerente do Projeto, Analista de Negócio e Product Owner.

b) Equipe do Projeto, Gerente do Projeto e Analista de Requisitos.
c) Gerente do Projeto, Product Owner e Gerente de Recursos Humanos.
d) Scrum Master, Product Owner e Equipe do Projeto.
e) Product Owner, Gerente de Projetos, PMO e Analista de Negócios.
Comentários:
Os papeis são: Scrum Master, Product Owner e Development Team [Versão 2017] ou Developers
[Versão 2020]. A questão viajou e trocou Equipe de Desenvolvimento por Equipe do Projeto.
Gabarito: Letra D
111. (INSTITUTO AOCP / PRODEB – 2018) Consiste de profissionais que realizam o trabalho de
entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada
Sprint:
a) Time de Desenvolvimento.
b) Product Owner.
c) Scrum Master.
d) Stakeholder.
e) Sprintholder.
Comentários:
73

Aula 03
Os profissionais que realizam o trabalho de entregar uma versão usável que potencialmente
incrementa o produto “Pronto” ao final de cada sprint é o Time de Desenvolvimento [Versão 2017]
ou Desenvolvedores [Versão 2020].
Gabarito: Letra A
112. (INSTITUTO AOCP / PRODEB – 2018) O Product Owner exerce um papel fundamental para
a execução de um produto de sucesso dentro de um determinado método ágil. Ele é responsável
por realizar a comunicação entre o cliente e a equipe que está desenvolvendo o projeto. Em qual
método o Product Owner é considerado um dos três papéis que constituem a equipe?
a) Cascata.
b) Lean.
c) Scrum.
d) Espiral.
e) Prototipação.
Comentários:
Product Owner é um papel do Scrum!
Gabarito: Letra C
113. (INSTITUTO AOCP / ADAF - AM – 2018) Scrum é uma metodologia ágil para gestão e
planejamento de projetos de software. No Scrum, os projetos são divididos em ciclos e tendem
a ser mais rápidos que a metodologia tradicional. No Scrum, existem três papéis. São eles:
a) Sprint; Stakeholders; Secretária.

b) Artefatos; Linguagem de Programação; Reuniões.
c) Product Owner; Scrummaster; Equipe.
d) Programador; Analista; Tester.
e) Gerente de sistemas; Sprint; Planejamento.
Comentários:
Os papeis são: Scrum Master, Product Owner e Development Team [Versão 2017] ou Developers
[Versão 2020]. A questão viajou e trocou Equipe de Desenvolvimento por Equipe do Projeto.
Gabarito: Letra C
114. (INSTITUTO AOCP / UFOB – 2018) Scrum é um método de desenvolvimento ágil. Esse
método envolve as etapas de requisitos, análise, projeto, evolução e entrega do software.
74

Aula 03
Comentários:
Não existem essas etapas, não há nada sobre isso no Guia Scrum. No entanto, a banca considerou
a questão como correta.
Gabarito: Correto
115. (AOCP / UNIR – 2018) O Backlog da Sprint é a recomendação do trabalho que o Time
identifica como necessário para alcançar a meta da Sprint. Os itens do Backlog da Sprint devem
ser íntegros.
Comentários:
Backlog da Sprint é uma lista do trabalho a ser desenvolvida pela Equipe de Desenvolvimento
[Versão 2017] ou Desenvolvedores [Versão 2020]. Trata-se de uma previsão sobre qual
funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa
funcionalidade em um incremento “Pronto”. Logo, não se trata de uma recomendação. Por fim,
não entendi o que o examinador quis dizer com itens íntegros.
Gabarito: Errado
116. (AOCP / UNIR – 2018) O Product Owner é um comitê responsável pelo gerenciamento do
Backlog do Produto e por garantir o valor do trabalho realizado pelo Time Scrum.
Comentários:
O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de
um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos
itens de Backlog devem endereçar ao Product Owner.
Gabarito: Errado
117. (AOCP / UNIR – 2018) O ScrumMaster é responsável por garantir que o Time Scrum esteja
aderindo aos valores do Scrum, às práticas e às regras. Também ajuda o Time Scrum e a
organização a adotarem o Scrum e treina e leva o Time Scrum a ser mais produtivo e a
desenvolver produtos de maior qualidade.
Comentários:
O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. Ele faz isso para
garantir que o Time Scrum adere à teoria, práticas e regras do Scrum. Ele é um servo-líder para o
Time Scrum e ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com
75

Aula 03
o Time Scrum são úteis e quais não são. Ele também ajuda todos a mudarem estas interações para
maximizar o valor criado pelo Time Scrum.
Gabarito: Correto
118. (AOCP / UNIR – 2018) O framework Scrum consiste em um conjunto formado por Times
Scrum e seus papéis associados, Eventos com Duração Fixa (Time-Boxes), Artefatos e Regras.
Comentários:
Eu novamente enfatizaria que são eventos com duração máxima fixa, mas a questão está correta.
Gabarito: Correto
119. (INSTITUTO AOCP / UFOB – 2018) No Scrum, são utilizados encontros diários, os
chamados Daily Scrum, para disseminar o conhecimento desenvolvido no dia anterior.
Comentários:
Perfeito! A Reunião Diária do Scrum é um evento time-boxed de 15 minutos para o Time de

Desenvolvimento. A Reunião Diária é realizada em todos os dias da Sprint. Nela o Time de
Desenvolvimento planeja o trabalho para as próximas 24 horas. Isso otimiza a colaboração e a
performance do time através da inspeção do trabalho desde a última Reunião Diária, e da previsão
do próximo trabalho da Sprint.
Gabarito: Correto
120. (INSTITUTO AOCP/ PRODEB – 2018) Sobre a retrospectiva de Sprint usando Scrum,
assinale a alternativa correta:
a) Ocorre depois da Revisão da Sprint.

b) Equivale à Revisão da Sprint.
c) É uma oportunidade para o Time Scrum inspecionar outros times.
d) Tem como objetivo resolver os itens que não foram concluídos durante a sprint.
e) É onde se planeja a próxima Sprint.
Comentários:
(a) Correto; (b) Errado, revisão avalia o produto e retrospectiva avalia o processo; (c) Errado, é uma
oportunidade para inspecionar o processo do próprio time; (d) Errado, não faz sentido algum; (e)
Errado, isso ocorre no planejamento da sprint.
Gabarito: Letra A
76

Aula 03
121. (FUNDATEC / SPGG – RS – 2018) O framework Scrum prescreve os seguintes eventos

formais para inspeção e adaptação:
a) Sprint e Daily Scrum.

b) Sprint Backlog e Daily Scrum.
c) Sprint Review e Sprint Backlog.
d) Product Backlog e Sprint Backlog.
e) Sprint Retrospective e Daily Scrum.
Comentários:
(a) Errado, Sprint não é um evento formal; (b) Errado, Sprint Backlog é um artefato; (c) Errado,
Sprint Backlog é um artefato; (d) Errado, ambos são artefatos; (e) Correto, ambos são eventos
formais para inspeção e adaptação.
Gabarito: Letra E
122. (FUNDATEC / SPGG – RS – 2018) Considere as seguintes assertivas sobre o framework

Scrum:
I. Emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o

controle de riscos.
II. Fundamenta-se em teorias empíricas de controle de processo, como, por exemplo, na
transparência.
III. São valores fundamentais do Scrum: comprometimento, coragem, foco, transparência e
respeito.
a) Apenas I.
b) Apenas III.
c) Apenas I e II.
d) Apenas II e III.
e) I, II e III.
Comentários:
(I) Correto, ele realmente utiliza uma abordagem iterativa e incremental, o que ajuda a gerenciar os
riscos do projeto; (II) Correto, é baseado no empirismo e um de seus pilares é a transparência; (III)
Correto, todos esses realmente são valores fundamentais.
Gabarito: Letra E
77

Aula 03
123. (FUNDATEC / SPGG - RS – 2018) Sobre o cancelamento de uma Sprint,

no framework Scrum, afirma-se que:
a) Somente o Scrum Master tem a autoridade para cancelar uma Sprint.

b) Somente o Product Owner tem a autoridade para cancelar uma Sprint.
c) Uma Sprint não pode ser cancelada antes de terminar o seu time-boxed.
d) Uma Sprint somente pode ser cancelada pelo cliente caso o seu time-boxed ainda não tenha
iniciado.
e) Uma Sprint somente pode ser cancelada pelo Time de Desenvolvimento caso o seu time-
boxed ainda não tenha iniciado.
Comentários:
(a) Errado, somente o Product Owner; (b) Correto; (c) Errado, pode ser cancelada, sim; (d) Errado,
ela pode ser cancelada ainda que ele já tenha iniciado; (e) Errado, ela não pode ser cancelada pelo
Time de Desenvolvimento [Versão 2017] ou Desenvolvedores [Versão 2020].
Gabarito: Letra B
124. (FAPEC / UFMS – 2018) Assinale a alternativa correta considerando as responsabilidades e

os papéis na metodologia SCRUM.
a) O responsável por gerenciar o Product Backlog (garantindo que esteja visível para todos),
gerar e disseminar os requisitos do projeto, assim como o plano para as entregas sucessivas,
priorizando os resultados que trarão maior valor agregado ao projeto, é o Product Owner.
b) O responsável por implementar o método Scrum, assim como por ensiná-lo a todos os
envolvidos nos projetos e assegurar que todos sigam as suas regras e práticas é
denominado Time Scrum.
c) O grupo de desenvolvedores que é coletivamente responsável pelo sucesso de cada iteração

e do projeto como um todo é conhecido como Scrum Masters.
d) O grupo de gerentes com responsabilidade de avaliar os custos do projeto é

denominado Scrum Cost.
e) O grupo de usuários finais do produto desenvolvido durante o projeto é denominado Scrum

Users.
Comentários:
78

Aula 03
(a) Correto; (b) Errado, é o Scrum Master; (c) Errado, é conhecido como Equipe de Desenvolvimento
[Versão 2017] ou Desenvolvedores [Versão 2020]; (d) Errado, esse papel não existe no Guia Scrum;
(e) Errado, esse papel não existe no Guia Scrum.
Gabarito: Letra A
125. (FAPEC / UFMS – 2018) Considere as afirmações a seguir sobre as fases da metodologia
SCRUM.
I - Product Backlog é uma lista ordenada por prioridade, produzida antes do início do
desenvolvimento, de itens que representam o que será produzido ao longo do projeto.
II - Cada ciclo de Sprint inicia com uma reunião de Sprint Planning.
III - Em cada ciclo de Sprint a reunião de Sprint Retrospective é realizada antes da reunião
de Daily Scrum.
Está(ão) correta(s):
a) Apenas I.
b) Apenas II.
c) Apenas I e II.
d) Apenas II e III.
e) I, II e III.
Comentários:
(I) Correto; (II) Correto; (III) Errado, é realizada ao final da sprint – é a última cerimônia da sprint.
Gabarito: Letra C
126. (INSTITUTO AOCP/ PRODEB – 2018) Considerando a metodologia Scrum, assinale a

alternativa que discorre corretamente sobre o que significa quando o item do Backlog do
Produto ou um incremento é descrito como “Pronto”:
a) A interpretação varia significativamente de um extremo ao outro para cada Time Scrum.

b) Cada integrante do time tem sua própria interpretação.
c) Significa Pronto para ser testado.
d) Significa Pronto para liberação em produção.
e) Significa que está pronto para ser implementado, ou seja, especificado.
Comentários:
De acordo com o guia: “Quando um item do Backlog do Produto ou um incremento é descrito como
“Pronto”, todos devem entender o que o “Pronto” significa. Embora, isso possa variar por Time Scrum,
79

Aula 03
os integrantes devem ter um entendimento compartilhado do que significa o trabalho estar completo,
assegurando a transparência. Esta é a “Definição de Pronto” para o Time Scrum e é usado para
assegurar quando o trabalho está completado no incremento do produto”.
(a) Correto, cada Time Scrum pode interpretar o que será o “pronto”; (b) Errado, a interpretação
dentro do time deve ser a mesma; (c) Errado, significa que o trabalho do incremento está completo;
(d) Errado, significa que o trabalho do incremento está completo; (e) Errado, significa que o trabalho
do incremento está completo.
Gabarito: Letra A
127. (INSTITUTO AOCP/ PRODEB – 2018) Sobre as características gerais do Scrum, assinale a
alternativa correta:
a) Não prioriza feedback.

b) Seus princípios são consistentes com o manifesto ágil.
c) Foi proposto após os anos 2000.
d) Incorpora desenvolvimento mas não requisitos.
e) Não se adapta bem a requisitos mutáveis.
Comentários:
(a) Errado, tanto prioriza que a cerimônia de retrospectiva tem esse objetivo; (b) Correto; (c) Errado,
foi proposto no início dos anos 1990; (d) Errado, incorpora ambos; (e) Errado, pelo contrário, ele se
adapta super bem a requisitos mutáveis.
Gabarito: Letra B
128. (INSTITUTO AOCP/ PRODEB – 2018) Sobre o método ágil denominado SCRUM, faça uma
análise das assertivas e assinale a alternativa que apresente somente práticas do método
SCRUM.
I. Sprint Planning Meeting (Reunião de Planejamento da Sprint).

II. Spikes Solution (Spikes de Planejamento).
III. Sprint Backlog (Backlog da Sprint).
IV. Client on Site (Clientes no Local).
a) Apenas I e II.
b) Apenas III.
c) Apenas II e IV.
d) Apenas II e III.
e) Apenas I e III.
80

Aula 03
Comentários:
A questão chama de prática o que seria idealmente chamado de evento. Logo, Sprint Planning
Meeting e Sprint Backlog são os eventos formais. Já o Client On Site e Spike Solution são realmente
práticas, mas do Extreme Programming e, não, do Scrum.
Gabarito: Letra E
129. (CESGRANRIO / Transpetro – 2018) A metodologia de desenvolvimento SCRUM é

caracterizada por ser ágil e rápida nas entregas. Um dos elementos-chave do processo SCRUM
é o Sprint, que é uma fase que acontece:
a) no fim do projeto, onde todos se esforçam para compensar os atrasos e cumprir o prazo.
b) no início do projeto, onde se procura entregar logo um grande volume de itens do projeto
para não arriscar atrasos.
c) sempre que necessário para compensar um atraso.
d) recorrentemente, ocorrendo de forma cíclica, várias vezes, até que se atinja o escopo do
projeto.
e) eventualmente, se necessário, caso ocorram eventos adversos não previstos que atrasem o
projeto.
Comentários:
Sprints ocorre recorrentemente, ocorrendo de forma cíclica, várias vezes, até que se atinja o escopo
do projeto – nenhum dos outros itens faz qualquer sentido.
Gabarito: Letra D
130. (INSTITUTO AOCP / PRODEB – 2018) Sobre a definição de Scrum, assinale a alternativa
correta.
a) Scrum é um processo para construir produtos.

b) Scrum é um framework dentro do qual você pode empregar vários processos ou técnicas.
c) Scrum é uma técnica para construir produtos de software.
d) Scrum não permite resolver problemas complexos.
e) Scrum é considerado extremamente fácil de dominar.
Comentários:
(a) Errado, não é um processo ou uma técnica para construir produtos – em vez disso, é um
framework dentro do qual você pode empregar vários processos ou técnicas; (b) Correto; (c) Errado,
ele não é uma técnica; (d) Errado, ele é um framework dentro do qual pessoas podem tratar e
resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam
81

Aula 03
produtos com o mais alto valor possível; (e) Errado, ele é leve, simples de entender e extremamente
difícil de dominar.
Gabarito: Letra B
131. (INSTITUTO AOCP / PRODEB – 2018) Em relação ao Backlog do Produto utilizando Scrum,
assinale a alternativa INCORRETA.
a) É uma lista ordenada de tudo que deve ser necessário no produto.

b) É uma origem única dos requisitos para qualquer mudança a ser feita no produto.
Requisitos nunca param de mudar, então o Backlog do Produto é um artefato vivo.
c) Mudanças de condições de mercado ou tecnologia podem causar mudanças no Backlog do
Produto.
d) Um Backlog do Produto deve estar completo antes do início da primeira Sprint.
Comentários:
Todos os itens estão corretos, exceto o último! Um Backlog do Produto nunca está completo. Os
primeiros desenvolvimentos estabelecem os requisitos inicialmente conhecidos e melhor
entendidos. O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele será
utilizado evoluem. O Backlog do Produto é dinâmico; mudando constantemente para identificar o
que o produto necessita para ser mais apropriado, competitivo e útil. Se um produto existe, seu
Backlog do Produto também existe.
Gabarito: Letra E
132. (INSTITUTO AOCP / PRODEB – 2018) Considerando a realização de Reuniões diárias

utilizando Scrum, assinale a alternativa correta.
a) Serve para sincronizar as atividades e criar um plano para as próximas 12 horas.

b) Deve ser mantido no mesmo horário e local todo dia a fim de reduzir a complexidade.
c) Deve ter um time-box de, no máximo, 2h.
d) Não há regra clara sobre quem deve participar dessas reuniões.
e) Discussões detalhadas após a reunião diária são desencorajadas.
Comentários:
(a) Errado, o plano é para as próximas 24 horas; (b) Correto; (c) Errado, é de no máximo 15 minutos;
(d) Errado, somente desenvolvedores podem participar; (e) Errado, elas são incentivadas.
Gabarito: Letra B
82

Aula 03
133. (FUNDATEC / CIGA-SC – 2018) Para responder à questão, considere a Figura 7, obtida a
partir do site <>, mostra, esquematicamente, uma visão geral do framework ou metodologia
ágil chamada Scrum. Nessa Figura, inseriu-se, em alguns locais, um retângulo, de modo a
ocultar inscrições existentes em tais locais.
Analise as seguintes assertivas sobre a metodologia ou framework ágil Scrum mostrada na

Figura 7:
I. A seta nº 1 aponta para uma etapa do framework chamada Product Backlog, que é uma lista
das funcionalidades desejadas para um produto. No Scrum, o conteúdo dessa lista é definido e
mantido pelo Scrum Master.
II. A seta nº 2 aponta para uma atividade chamada de Daily Scrum, que consiste em reuniões
diárias envolvendo, sempre que possível, toda a equipe de projeto, como, por exemplo, Product
Owner, Scrum Master, Scrum Team e Representante do Cliente, para avaliarem, em conjunto,
o andamento do projeto, assim como na identificação e resolução imediata dos problemas, de
modo que eles não evoluam e comprometam o andamento dos trabalhos.
III. No Scrum, a equipe monitora seu progresso em relação a um plano estabelecido, por meio
da atualização de um Release Burndown Chart, ao final de cada Sprint.
a) Apenas I.
b) Apenas II.
c) Apenas III.
d) Apenas I e III.
e) I, II e III.
Comentários:
(I) Errado. Ela realmente aponta para o Product Backlog, mas ele não é uma etapa – é um artefato.
Além disso, ele é mantido pelo Product Owner e, não, pelo Scrum Master; (II) Errado. Ela envolve
apenas os desenvolvedores e, não, toda a equipe do projeto; (III) Correto.
83

Aula 03
Gabarito: Letra C
134. (FUNRIO / Câmara de São João de Meriti - RJ – 2018) SCRUM é um framework dentro do
qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva
e criativamente entregam produtos com o mais alto valor possível. O SCRUM chama seus
eventos de timeboxes, uma vez que são eventos de duração fechada, sendo o componente
principal conhecido por Sprint, havendo alguns tipos, dos quais quatro são detalhados a seguir:
( I ) Time-boxe de 8h, de acordo com o tamanho da Sprint. Nesta reunião é onde o Product
Owner é ouvido em relação às prioridades e os objetivos. É nela também onde o time irá
deliberar sobre o que conseguem fazer em relação às necessidades, formalizando o Sprint
Backlog.
( II ) Time-box de 4h, onde o incremento do produto que está pronto para uso, é apresentado
ao Product Owner para apreciação. Também é nesta reunião, que deve ser facilitada pelo Scrum
Master, que o Product Owner apresentará os números, gráficos e tudo o mais que for
importante à equipe saber sobre o produto. Novas prioridades e movimentos do mercado, tudo
focado em manter os objetivos coerentes ao longo das sprints. Esse é o evento que melhor
representa o pilar de inspeção do Scrum.
( III ) Time-box de 3h onde o time de desenvolvedores e o Scrum Master, que atua apenas como
facilitador, falam sobre os resultados obtidos na Sprint que passou e as lições tiradas, para a
partir daí melhorar o processo, fortemente arraigado ao pilar de adaptação.
( IV ) Time-boxe de 15 min, sempre no mesmo local e horário para gerar consistência e evitar
perda de tempo, facilitada pelo Scrum Master. Nesta reunião, que deve ser muito dinâmica e
que popularmente é feita em pé, para evitar prolongamentos e distrações, cada membro do
time deve responder apenas três perguntas: o que eu fiz ontem, o que eu vou fazer hoje e se tem
algo me impedindo.
Os tipos (I), (II), (III) e (IV) são denominados respectivamente:
a) Sprint Retrospective, Daily Scrum, Sprint Planning e Sprint Review.

b) Sprint Planning, Sprint Rewiew, Daily Scrum e Sprint Retrospective.
c) Sprint Planning, Sprint Review, Sprint Retrospective e Daily Scrum.
d) Sprint Planning, Sprint Retrospective, Sprint Review e Daily Scrum.
e) Daily Scrum, Sprint Planning, Sprint Retrospective e Sprint Review.
Comentários:
(Sprint Planning) Time-boxe de 8h, de acordo com o tamanho da Sprint. Nesta reunião é onde
o Product Owner é ouvido em relação às prioridades e os objetivos. É nela também onde o time irá
deliberar sobre o que conseguem fazer em relação às necessidades, formalizando o Sprint Backlog.
84

Aula 03
(Sprint Review) Time-box de 4h, onde o incremento do produto que está pronto para uso, é
apresentado ao Product Owner para apreciação. Também é nesta reunião, que deve ser facilitada
pelo Scrum Master, que o Product Owner apresentará os números, gráficos e tudo o mais que for
importante à equipe saber sobre o produto. Novas prioridades e movimentos do mercado, tudo
focado em manter os objetivos coerentes ao longo das sprints. Esse é o evento que melhor
representa o pilar de inspeção do Scrum.
(Sprint Retrospective) Time-box de 3h onde o time de desenvolvedores e o Scrum Master, que atua
apenas como facilitador, falam sobre os resultados obtidos na Sprint que passou e as lições tiradas,
para a partir daí melhorar o processo, fortemente arraigado ao pilar de adaptação.
(Daily Scrum) Time-boxe de 15 min, sempre no mesmo local e horário para gerar consistência e
evitar perda de tempo, facilitada pelo Scrum Master. Nesta reunião, que deve ser muito dinâmica e
que popularmente é feita em pé, para evitar prolongamentos e distrações, cada membro do time
deve responder apenas três perguntas: o que eu fiz ontem, o que eu vou fazer hoje e se tem algo
me impedindo.
Gabarito: Letra C
135. (FAURGS / UFCSPA - RS – 2018) ____________ é uma metodologia ágil que fornece
um framework de gerenciamento de projetos. É centralizada em torno de um conjunto
de sprints, que são períodos determinados de tempo, quando um incremento de sistema é
desenvolvido. O planejamento é baseado na priorização de um backlog de trabalho e na seleção
das tarefas mais importantes para um sprint.
a) MDE – Engenharia Dirigida a Modelos

b) XP
c) SCRUM
d) MDA – Arquitetura Dirigida a Modelos
e) Programação em Pares
Comentários:
Scrum é uma metodologia ágil que fornece um framework de gerenciamento de projetos. É

centralizada em torno de um conjunto de sprints, que são períodos determinados de tempo,
quando um incremento de sistema é desenvolvido. O planejamento é baseado na priorização de
um backlog de trabalho e na seleção das tarefas mais importantes para um sprint.
Gabarito: Letra C
85

Aula 03
136. (IADES / APEX-BRASIL – 2018) Na metodologia Scrum, existem times que tipicamente
consistem de um dono do produto, um mestre Scrum e um time de desenvolvimento. Acerca
das respectivas responsabilidades, é correto afirmar que o:
a) mestre Scrum é o responsável por maximizar o valor do produto que resulta do trabalho do
time de desenvolvimento.
b) mestre Scrum é responsável por gerenciar o backlog do produto.
c) time de desenvolvimento tem autonomia para organizar e gerenciar seu próprio trabalho.
d) dono do produto é responsável por promover e suportar o Scrum, ajudando a todos

entenderem a teoria.
e) time de desenvolvimento garante que o dono do produto saiba como organizar o backlog do
produto para maximar o valor.
Comentários:
(a) Errado, esse seria o Product Owner; (b) Errado, esse seria o Product Owner; (c) Correto; (d)
Errado, esse seria o Scrum Master; (e) Errado, esse seria o Scrum Master.
Gabarito: Letra C
137. (PR4 / UFRJ – 2018) Assinale a alternativa que apresenta apenas papéis recomendados no
Framework Scrum.
a) Time Scrum, Scrum Master, Product Owner.

b) Time Scrum, Scrum Tester, Product Owner.
c) Time Scrum, Scrum Manager, Product Owner.
d) Scrum Manager, Scrum Tester, Product Owner.
e) Scrum Manager, Scrum Tester, Scrum Master.
Comentários:
Para mim, não há resposta! Os papeis são: Scrum Master, Product Owner e Time de
Desenvolvimento [Versão 2017] ou Desenvolvedores [Versão 2020]. Não existe o papel de Time
Scrum – esse é apenas o conjunto dos outros papeis.
Gabarito: Letra A
138. (UFG / SANEAGO – 2017) Na metodologia SCRUM, quais são os itens registrados dentro de
uma “Retrospectiva”?
86

Aula 03
a) Pontos positivos, negativos e melhorias para a próxima iteração.

b) Itens entregues e itens a serem desenvolvidos.
c) Itens não entregues a serem desenvolvidos na próxima iteração.
d) Estimativas para o desenvolvimento de funcionalidades escolhidas pelo cliente
Comentários:
A Restrospectiva da Sprint busca inspecionar como a última sprint realizada em relação às pessoas,
aos relacionamentos, aos processos e às ferramentas; identificar e ordenar os principais itens que
foram bem e as potenciais melhorias; e criar um plano para implementar melhorias no modo que o
Time Scrum faz seu trabalho. Em suma, registram-se os pontos positivos, negativos e melhorias
para a próxima iteração.
Gabarito: Letra A
139. (UFG / SANEAGO – 2017) O pré-planejamento (também conhecido como pré-game) é uma
das cerimônias conhecidas da metodologia SCRUM. Por definição, é objetivo deste pré-
planejamento:
a) integração do software entregue na última interação com a versão que será desenvolvida.
b) distribuição dos pacotes de trabalho entre os membros da equipe.
c) detalhamento, priorização e estimativa de desenvolvimento dos pacotes de trabalho.
d) levantamento de pontos positivos, negativos e melhorias no processo.
Comentários:
O pré-planejamento define o sistema sendo desenvolvido. Cria-se o Product Backlog, que contém
todos os requisitos atuais e informações sobre o planejamento do projeto. Cria-se também uma
arquitetura de alto nível. No entanto, essa questão foi anulada porque o pré-planejamento não é
uma das quatro cerimônias tradicionais do Scrum!
Gabarito: Anulada
140. (UFG / SANEAGO – 2017) Dentro do método SCRUM, quais são as informações utilizadas
para criar o gráfico burndown?
a) Tempo total da sprint e esforço estimado para as tarefas não realizadas.

b) Tempo gasto na resolução das tarefas do projeto e estimativas para as tarefas não realizadas.
c) Tempo gasto na sprint anterior e esforço de tarefas já realizadas.
d) Tempo total na resolução de impedimentos e estimativas para finalização do projeto.
Comentários:
87

Aula 03
O Gráfico de Burndown torna visível a evolução diária do trabalho da equipe de desenvolvimento,

na medida em que mostra a comparação entre o trabalho estimado inicialmente com a quantidade
restante estimada de trabalho (estimado x realizado). Via de regra, as unidades utilizadas são de
esforço (em horas) planejado pelo tempo decorrido. Em suma: ele mostra o tempo/esforço
realizado versus o tempo/esforço estimado. A primeira opção é a que mais se aproxima disso, mas
as questões dessa banca são bastante confusas.
Gabarito: Letra A
141. (UFG / SANEAGO – 2017) Faz parte do conjunto de eventos do SCRUM um encontro
conhecido em inglês por Daily SCRUM. O Daily Scrum:
a) tem a duração fixa de 15 minutos.

b) é o instrumento empregado para relatar o progresso do projeto.
c) ocorre uma vez por semana.
d) é um encontro do qual o Scrum Master não participa.
Comentários:
(a) Errado, a Daily Scrum tem uma duração de até 15 minutos; (b) Errado, essa reunião não tem esse
objetivo; (c) Errado, essa reunião é diária; (d) Errado, ele participa, sim.
No entanto, a questão foi anulada porque todos os itens são errados com a seguinte justificativa:
“Depreende-se que a time-box de 15 minutos não é fixa, mas sim um intervalo de até 15 minutos”.
Gabarito: Anulada
142. (UFG / SANEAGO – 2017) Em uma equipe que trabalha orientada pelo Scrum,
a) a descoberta de um "erro" ou "defeito" recebe máxima prioridade e justifica a extensão da

Sprint por até 15 dias.
b) a identificação de novos requisitos pode ser feita durante reunião (Daily Scrum), na qual estão
presentes clientes do futuro produto.
c) o Scrum Master é responsável por orientar a equipe de desenvolvimento e definir como

transformar itens do backlog no incremento proposto para a sprint em questão.
d) a responsabilidade pela produção do incremento cabe a toda a equipe de desenvolvimento,

a despeito de um determinado membro da equipe possuir habilidades específicas.
Comentários:
88

Aula 03
(a) Errado, não se estende prazo de sprint; (b) Errado, Product Owner é o único responsável por
identificar novos requisitos; (c) Errado, Scrum Master é um facilitador e especialista no Scrum – ele
não tem essa prerrogativa; (d) Correto, a responsabilidade é da equipe de desenvolvimento e, não,
de um desenvolvedor em particular [Versão 2017].
Gabarito: Letra D
143. (ESAF / ESAF – 2015) O SCRUM é uma metodologia ágil para gestão e planejamento de
projetos de software. Nele, as funcionalidades a serem implementadas em um projeto são
mantidas em uma lista que é conhecida como ____________. No início de cada Sprint, faz-se
um ____________ na qual o ____________ prioriza os itens do ____________ e a equipe
seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As
tarefas alocadas em um Sprint são transferidas do ____________ para o ____________ .
a) Product Backlog, Sprint Backlog, Product Owner, Product Backlog, Sprint Planning Meeting
e Product Backlog.
b) Sprint Planning Meeting, Product Backlog, Product Owner, Product Backlog, Product
Backlog e Sprint Backlog.
c) Product Backlog, Sprint Planning Meeting, Product Owner, Product Backlog, Sprint Backlog
e Product Backlog.
d) Product Backlog, Sprint Planning Meeting, Product Backlog, Sprint Backlog, Product
Backlog, e Product Owner.
e) Product Backlog, Sprint Planning Meeting, Product Owner, Product Backlog, Product
Backlog e Sprint Backlog.
Comentários:
O Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. Nele, as
funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida
como Product Backlog No início de cada Sprint, faz-se um Sprint Planning Meeting na qual o Product
Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de
implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do
Product Backlog para o Sprint Backlog.
Gabarito: Letra E
144. (CESGRANRIO / CEFET-RJ – 2014) No Scrum, segundo o guia 2013, o responsável pelo
trabalho de expressar claramente os itens do Backlog do Produto é o:
89

Aula 03
a) Product Master
b) Product Owner
c) Scrum Master
d) Scrum Owner
e) Time de Desenvolvimento
Comentários:
O Product Owner é o responsável por definir os itens que compõem o Product Backlog e também
por priorizá-los nas Sprint Planning Meetings (Reuniões de Planejamento da Sprint).
Gabarito: Letra B
145. (CESGRANRIO / EPE – 2014) No planejamento de projetos de software, e principalmente

em metodologias ágeis de desenvolvimento, muitos autores defendem a técnica conhecida
como “timebox”, que:
a) estima o menor e o maior tempo de desenvolvimento para cada funcionalidade a ser

desenvolvida, definindo uma “caixa” de tempo em vez de um prazo fixo.
b) parte do tempo disponível em uma fábrica de software para especificar versões consecutivas
de um produto, conhecidas como “caixas”
c) divide um produto de software em versões de complexidade crescente, conhecidas como

“caixas”, especificando o tempo de desenvolvimento de cada caixa do mais rápido para o mais
longo.
d) define um tempo para cada função a ser desenvolvida e as aloca em “caixas” de igual tempo
de desenvolvimento que são escolhidas pelos desenvolvedores.
e) define o tempo a ser utilizado em um ciclo de desenvolvimento e depois define a

funcionalidade que pode ser desenvolvida naquela “caixa” de tempo.
Comentários:
Todas as atividades do Scrum são time-boxed, isto é, ocorrem sob um segmento de tempo de
“duração fixa” para um evento ou atividade específica. Essa unidade de tempo é chamada de Time
Box. O objetivo é definir e limitar a quantidade máxima de tempo dedicado para executar um
conjunto de atividades. Dessa forma, em vez de começar a trabalhar em algo até sua finalização de
forma indefinida, é acordado de antemão o tempo limite para cada tarefa de projeto (tempo fixo e
escopo variável).
90

Aula 03
Gabarito: Letra E
146. (UNIRIO / UNIRIO – 2014) De acordo com o autor Schwaber, o Scrum é um framework para
desenvolvimento e manutenção de produtos complexos baseado em três pilares, que são:
a) simplicidade, reflexão, organização.

b) transparência, inspeção e adaptação.
c) Scrum master, product owner, time de desenvolvimento.
d) backlog (do produto e do sprint), gráfico de burndown, incremento do produto.
e) controle, documentação, previsibilidade.
Comentários:
Os três pilares são: Transparência, Inspeção e Adaptação.
Gabarito: Letra B
91

Aula 03
LISTA DE QUESTÕES – CESPE

1. (CESPE / Petrobrás - 2022) Entre as principais características dos métodos ágeis, destacam-se
a maximização da documentação formal e o envolvimento dos clientes.
2. (CESPE / TCE-ES – 2012) Em virtude de as metodologias ágeis gerarem excessiva

documentação, a gestão do conhecimento depende diretamente dos programadores
envolvidos no projeto.
3. (CESPE / EBC – 2011) O que os métodos ágeis buscam é como evitar as mudanças desde o início
do projeto e não a melhor maneira de tratar essas mudanças.
4. (CESPE / BASA – 2010) Desenvolvimento ágil de software (Agile Software Development) ou

método ágil é aplicado, principalmente, a grandes corporações, uma vez que permite produzir
grandes sistemas de forma ágil.
5. (CESPE / TCU – 2010) A agilidade não pode ser aplicada a todo e qualquer processo de software.
6. (CESPE / UNIPAMPA – 2009) XP, Scrum e Cristal são exemplos de modelos ágeis de
desenvolvimento de sistemas.
7. (CESPE / EBC – 2011) Considerando o conceito de metodologia ágil em apreço, é correto

afirmar que as seguintes metodologias são ágeis: XP (Extreme Programming), Scrum, Crystal,
FDD (Feature Driven Development), DSDM (Dynamic Systems Development Method) e Open
Source Software Development.
8. (CESPE / CNJ – 2013 O desenvolvimento ágil de sistemas consiste em uma linguagem de

modelagem que permite aos desenvolvedores visualizarem os produtos de seu trabalho em
gráficos padronizados.
9. (CESPE / EBC – 2011) É conveniente que o contrato, entre cliente e fornecedor, para o
desenvolvimento de um sistema computacional, contenha a lista de requisitos para o software.
Contudo, os métodos ágeis de desenvolvimento preconizam que o referido contrato estabeleça
o preço, a ser pago pelo cliente, com base no tempo necessário para o desenvolvimento do
sistema e não com base no conjunto de requisitos.
10. (CESPE / MPOG – 2015) Metodologias de desenvolvimento ágil enfocam atividades de projeto
e implementação, desconsiderando as atividades de elicitação de requisitos e a produção de
documentação.
11. (CESPE / TRE-PI – 2008) No que se refere a métodos ágeis de desenvolvimento de sistemas,
assinale a opção correta.
92

Aula 03
a) A aplicação de método ágil para desenvolvimento de grandes sistemas pode enfrentar

dificuldades que o tornem inviável.
b) O documento de requisitos, apesar de abordar um conjunto pequeno de funcionalidades,

deve especificar toda a necessidade do usuário.
c) O sistema é construído em pequenos blocos, que irão compor uma versão a ser entregue aos
usuários.
d) A documentação de projeto deve ser feita pelo próprio desenvolvedor, seguindo padrões
simplificados.
e) Para atingir os objetivos de agilidade exigidos, os desenvolvedores devem seguir processos

simplificados para a construção do software.
12. (CESPE / TCE-PR – 2016) Os métodos ágeis para o desenvolvimento de software representam
uma evolução da engenharia de software tradicional, uma vez que são aplicáveis a todos os tipos
de projetos, produtos, pessoas e situações.
13. (CESPE / TCE-PR – 2016) Um dos princípios de agilidade da Agile Alliance dispõe que a entrega
completa de um software garante a satisfação do cliente.
14. (CESPE / Ministério da Economia – 2020) Os modelos ágeis de desenvolvimento

de software dão grande ênfase às definições de atividades e aos processos e pouca ênfase à
pragmática e ao fator humano.
15. (CESPE / MEC – 2015) Acatar as mudanças de requisitos, ainda que o desenvolvimento já esteja
avançado, é um dos princípios do Manifesto Ágil.
16. (CESPE / TRT17 – 2013) Em um desenvolvimento ágil que segue o manifesto ágil, não se deve
aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis não se
adequam a mudanças não planejadas.
17. (CESPE / EBSERH – 2018) Nas metodologias de desenvolvimento ágeis, mudanças em

requisitos são bem recebidas, mesmo em fases mais avançadas do desenvolvimento.
93

Aula 03
LISTA DE QUESTÕES – FCC

18. (FCC / SEFAZ-AP – 2022) Dentre os doze Princípios do Manifesto Ágil, incluem-se:
a) funcionalidade, satisfação do cliente e trabalho em conjunto.

b) respeito ao cliente, economia de recursos e paralelismo.
c) resiliência, motivação e trabalho em pares.
d) simplicidade, motivação e paralelismo.
e) especificidade, longevidade do software e prazos curtos.
Comentários:
Trata-se de funcionalidade (software funcionando), satisfação do cliente (satisfaça o consumidor)

e trabalho em conjunto.
Gabarito: Letra A
94

Aula 03
LISTA DE QUESTÕES – FGV
19. (FGV / IMBEL – 2021) Com referência aos valores do The Agile Manifesto, analise as afirmativas
a seguir.
I. Processos e ferramentas mais que indivíduos e interação entre eles.

II. Software em funcionamento mais que documentação abrangente.
III. Colaboração do cliente mais que negociação de contratos.
IV. Seguir um plano mais que responder a mudanças.
Está correto o que se afirma em:
a) I e II, somente
b) II e III, somente.
c) III e IV, somente.
d) I e IV, somente.
e) II e IV, somente.
20. (FGV / MPE-MS – 2013) Considerando a caracterização de agilidade e processo de

desenvolvimento ágil, segundo Pressman, analise as afirmativas a seguir.
I. Um processo ágil de software deve ser incrementalmente adaptável.

II. Um processo ágil de software permite que as pessoas e a equipe se moldem a ele com
facilidade.
III. Os conceitos ágeis são efetivos, pois diminuem a imprevisibilidade sistêmica ao enfatizar
entregas em prazos curtos.

c) se somente a afirmativa III estiver correta.
21. (FGV / PGE-RO – 2015) Durante 5 anos gerenciando o desenvolvimento de sistemas de

informação, Claudia teve que lidar com diversas insatisfações de seus usuários pois os sistemas
não atendiam as suas necessidades. Claudia decidiu, então, implantar métodos ágeis de
desenvolvimento e definiu os seguintes princípios:
I. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
95

Aula 03
II. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de
desenvolvimento é através da documentação.
III. Simplicidade é essencial.
Dentre os princípios definidos por Claudia, o que infringe os princípios do manifesto para
Desenvolvimento Ágil de Software é o que se afirma em:
a) somente I;
b) somente II;
c) somente III;
d) somente I e III;
e) I, II e III.
22. (FGV / TJ-RO – 2015) O manifesto ágil tem por princípio que:
a) mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento;
b) a contínua atenção à excelência técnica reduz a agilidade;
c) a redução do backlog é a medida primária de progresso;
d) as melhores arquiteturas, requisitos e designs emergem de equipes que possuem um bom

líder;
e) pessoas de negócio e desenvolvedores devem trabalhar em ambientes separados para reduzir

as interferências no processo de desenvolvimento.
23. (FGV / TJ-GO – 2014) Escreva O Manifesto Ágil lista valores seguidos por desenvolvedores com
a finalidade de melhorar a maneira pela qual o software é desenvolvido. A alternativa que se
encontra no manifesto é:
a) seguir um plano mais que responder a mudanças;

b) indivíduos e interações mais que processos e ferramentas;
c) documentação abrangente mais que software em funcionamento;
d) negociação de contratos mais que colaboração com o cliente;
e) negociação de contratos mais que indivíduos e interações.
24. (FGV / Câmara Municipal de Caruaru-PE – 2015) O desenvolvimento ágil de software é guiado
por metodologias que compartilham um conjunto comum de valores e de princípios, conforme
definido pelo Manifesto Ágil. Assinale a opção que indica um princípio do desenvolvimento ágil.
a) As mudanças nos requisitos devem ocorrer dentro do quadro de tempo estabelecido para a
iteração.
96

Aula 03
b) O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de
desenvolvimento é por meio de conversa face a face.
c) Os intervalos regulares devem ser evitados para tornar a equipe mais eficaz e maximizar a
quantidade de trabalho realizado.
d) As pessoas de negócio e desenvolvedores devem interagir somente no início de cada iteração.
e) A entrega contínua e adiantada de software, mesmo que o conjunto de funcionalidades

desenvolvidas não agregue valor, deve ser feita para satisfazer o cliente.
25. (FGV / PROCEMPA – 2014) O Manifesto Ágil é uma declaração de princípios que fundamentam
o desenvolvimento ágil de software. A respeito desses princípios, assinale a afirmativa correta:
a) As melhores arquiteturas, requisitos e designs emergem de equipes lideradas pelo

profissional mais sênior.
b) Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e
ajusta seu comportamento de acordo.
c) Pessoas de negócio e desenvolvedores devem trabalhar separadamente por todo o projeto.
d) Entregar software quando há poucas semanas de desenvolvimento deve ser evitado para não
afetar a satisfação do cliente.
e) Mudanças nos requisitos são bem-vindas, desde que não impactem o desenvolvimento.
26. (FGV / DPE-RO – 2015) O Manifesto Ágil é uma declaração que reúne os princípios e práticas
que fundamentam o desenvolvimento ágil de software. É um dos princípios desse manifesto:
a) defeitos no software são a medida primária de progresso;
b) pessoas de negócio e desenvolvedores devem trabalhar isoladamente e se reunir somente ao

final de cada iteração para validação do software;
c) atenção contínua à excelência técnica deve ser evitada para não afetar a agilidade uma vez
que simplicidade é essencial;
d) os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo

constante indefinidamente evitando interrupções e intervalos regulares;
e) as melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
97

Aula 03
27. (FGV / BANESTES – 2018) Um dos valores relacionados ao ambiente ágil de desenvolvimento
é:
a) documentação abrangente mais que software funcional;

b) negociação de contratos mais que colaboração do cliente;
c) processos e ferramentas mais que indivíduos e iterações;
d) rapidez na construção mais que excelência técnica;
e) responder a mudanças mais que seguir um plano.
28. (FGV / BANESTES – 2018) Com relação aos valores relacionados ao desenvolvimento ágil de
software, NÃO se pode incluir:
a) colaboração do cliente mais que negociação de contratos;

b) indivíduos e iterações mais que processos e ferramentas;
c) rapidez na construção mais que excelência técnica;
d) responder a mudanças mais que seguir um plano;
e) software funcional mais que documentação abrangente.
29. (FGV / AL-RO – 2018) Para o desenvolvimento do Sistema de Informações ao Cidadão (SIC), foi
decidida a utilização de uma metodologia ágil. Segundo o Manifesto Ágil, esta decisão indica
que foi dado maior valor:
a) aos processos e ferramentas.

b) à resposta a modificações.
c) à documentação abrangente.
d) à negociação do contrato.
e) ao cumprimento do plano.
98

Aula 03
LISTA DE QUESTÕES – DIVERSAS BANCAS

30. (FADESP / UEPA – 2020) Um dos princípios do Manifesto Ágil é o de que os indivíduos e
interações são mais importantes que processos e ferramentas. Um outro princípio é o de que:
a) o usuário é a principal fonte de informação de requisitos de software.

b) os contratos são mais importantes que a colaboração com os clientes.
c) o software funcionando é mais importante do que a documentação completa e detalhada.
d) seguir o plano inicial é mais importante que a adaptação a mudanças.
31. (IESES / SCGás – 2019) A filosofia por trás dos métodos ágeis é refletida no manifesto ágil, que
foi acordado por muitos dos principais desenvolvedores desses métodos. Assinale a alternativa
==f219==
correta que contêm os itens deste manifesto.
a) “Estamos descobrindo melhores maneiras de desenvolver softwares, fazendo-o e ajudando

outros a fazê-lo. Através desse trabalho, valorizamos mais: Indivíduos e interações do que
processos e ferramentas; Software em funcionamento do que documentação abrangente;
Colaboração do cliente do que negociação de contrato; Respostas a mudanças do que seguir um
plano. Ou seja, embora itens à direita sejam importantes, valorizamos mais os que estão à
esquerda”.
b) “Estamos descobrindo melhores maneiras de desenvolver softwares, fazendo-o e ajudando

outros a fazê-lo. Através desse trabalho, valorizamos mais: A concorrência e o desenvolvimento
da competitividade entre as empresas; Software em funcionamento do que documentação
abrangente; Colaboração do cliente do que negociação de contrato; Respostas a mudanças do
que seguir um plano. Ou seja, embora itens à direita sejam importantes, valorizamos mais os
que estão à esquerda”.
c) “Estamos descobrindo melhores maneiras de desenvolver softwares, fazendo-o e ajudando

outros a fazê-lo. Através desse trabalho, valorizamos mais: Indivíduos e interações do que
processos e ferramentas; Software em funcionamento do que documentação abrangente;
Colaboração da equipe de desenvolvedores do que negociação de contrato e clientes; Respostas
a mudanças do que seguir um plano. Ou seja, embora itens à direita sejam importantes,
valorizamos mais os que estão à esquerda”.
d) “Estamos descobrindo melhores maneiras de vender softwares, fazendo-o e ajudando outros

a fazê-lo. Através desse trabalho, valorizamos mais: Indivíduos e interações do que processos e
ferramentas; Software para mobiles e, em funcionamento do que documentação abrangente;
Colaboração do cliente do que negociação de contrato; Respostas a mudanças do que seguir um
plano. Ou seja, embora itens à direita sejam importantes, valorizamos mais os que estão à
esquerda”.
99
www.estrategiaconcursos.com.br 8 11119
Aula 03
32. (IESES / SCGás – 2019) Identifique a opção correta para conceituar desenvolvimentos ágeis ou,
que caracterizam métodos ágeis:
a) São métodos de desenvolvimento estáticos em que os incrementos são dinâmicos e,

normalmente, as novas versões do sistema são criadas e disponibilizadas aos clientes a cada
duas ou três semanas. Elas não envolvem os clientes no processo de desenvolvimento para obter
feedback rápido sobre a evolução dos requisitos. Assim, minimiza-se a documentação, pois se
utiliza mais a comunicação informal do que reuniões formais com documentos escritos.
b) São métodos de desenvolvimento incremental em que os incrementos são pequenos e,

duas ou três semanas. Neles envolvemos clientes no processo de desenvolvimento para obter
c) São métodos de desenvolvimento estáticos em que os incrementos são pequenos e,

duas ou três semanas. Elas envolvem os clientes no processo de desenvolvimento para obter
d) São métodos de desenvolvimento incremental em que os incrementos são intermediários e,

normalmente, as novas versões do sistema são descritas e disponibilizadas aos clientes a cada
duas ou três semanas. Elas envolvem os desenvolvedores do processo de concepção para obter
33. (IESES / SCGás – 2019) Os processos de software podem ser categorizados como dirigidos a
planos ou processos ágeis. Considerando esta afirmação, assinale a afirmativa correta:
a) Nos processos ágeis todas as atividades são planejadas antecipadamente, e a avaliação do

processo considera a comparação com um planejamento inicial. Já nos processos dirigido a
planos, o planejamento é gradativo. Esta característica facilita a alteração do processo de forma
a refletir as necessidades de mudança dos clientes.
b) Nos processos dirigidos a planos todas as atividades são planejadas antecipadamente, e a

avaliação do processo considera a comparação com um planejamento inicial. Já nos processos
ágeis, o planejamento é gradativo. Esta característica facilita a alteração do processo de forma
c) Nos processos ágeis todas as atividades são planejadas posteriormente, e a avaliação do

processo considera a comparação com um planejamento inicial. Já nos processos dirigido a
planos, o planejamento é gradativo. Esta característica facilita a alteração do processo de forma
100
www.estrategiaconcursos.com.br 9 11119
Aula 03
d) Nos processos dirigidos a planos todas as rotinas são empíricas e, a avaliação do processo
considera a comparação com um planejamento final a ser definido. Já nos processos ágeis, o
planejamento é gradativo. Esta característica facilita a alteração do processo de forma a refletir
as necessidades de mudança dos clientes.
34. (INSTITUTO AOCP / EMPREL – 2019) Em se tratando de desenvolvimento de software, o

termo qualidade é bastante subjetivo. Entretanto, no desenvolvimento ágil, é claro o conceito
de qualidade. Sabendo disso, assinale a alternativa que apresenta corretamente o conceito de
qualidade no desenvolvimento ágil.
a) Envolve a documentação do processo e o estabelecimento de práticas para entregar ao

cliente um produto de qualidade.
b) Cumpre os critérios sistêmicos estabelecidos em acordo com o cliente para que os requisitos
também sejam cumpridos.
c) Tem como objetivo gerar manuais e código claro por meio de uma equipe especializada no
processo.
d) Cumpre os requisitos para o cliente com uma documentação completa do produto

desenvolvido.
e) Significa que a qualidade do código e as práticas são utilizadas para garantir um código de
alta qualidade.
35. (IF-PE / IF-PE – 2019) O Manifesto Ágil é um documento que encoraja a utilização de métodos
melhores no desenvolvimento de software. Nele foram escritos doze princípios que norteiam o
desenvolvimento ágil de sistemas. Um dos princípios mais relevantes é:
a) “A prioridade é satisfazer a equipe de desenvolvimento por meio de uma entrega única de

software de valor.”
b) “A prioridade é satisfazer ao cliente por meio de uma entrega única de software de valor.”
c) “A prioridade é satisfazer ao gerente do projeto por meio de entregas contínuas e frequentes

de software de valor.”
d) “A prioridade é satisfazer ao gerente de projetos por meio de uma entrega única de software
de valor.”
e) “A prioridade é satisfazer ao cliente por meio de entregas contínuas e frequentes de software

de valor.”
101
19
Aula 03
36. (AJURI / Desenvolve - RR – 2018) Desenvolvimento ágil de software (em inglês: Agile software
development) ou Método ágil é uma expressão que define um conjunto de metodologias
utilizadas no desenvolvimento de software. As metodologias que fazem parte do conceito de
desenvolvimento ágil, tal como qualquer metodologia de software, providenciam uma estrutura
conceitual para reger projetos de engenharia de software. Métodos ágeis enfatizam
comunicações em tempo real, preferencialmente cara a cara, a documentos escritos. A maioria
dos componentes de um grupo ágil deve estar agrupada em uma sala. Isso inclui todas as
pessoas necessárias para terminar o software: no mínimo, os programadores e seus
clientes(clientes são as pessoas que definem o produto, eles podem ser os gerentes, analistas
de negócio, ou realmente os clientes). Considerando o contexto dos Valores da Metodologia
Ágil, é correto afirmar que indivíduos e iterações:
a) mais do que processos e ferramentas; software funcional mais do que documentação

abrangente; colaboração do cliente menor do que negociação de contratos; responder a
mudanças menor do que seguir um plano.
b) mais do que processos e ferramentas; software funcional mais do que documentação

abrangente; colaboração do cliente mais do que negociação de contratos; responder a
mudanças mais do que seguir um plano.
c) mais do que processos e ferramentas; software funcional menos do que documentação

abrangente; colaboração do cliente menor do que negociação de contratos; responder a
mudanças na mesma medida que seguir um plano.
d) mais do que processos e ferramentas; software funcional mais do que documentação

abrangente; colaboração do cliente na mesma medida que negociação de contratos; responder
a mudanças na mesma medida que seguir um plano.
e) na mesma medida que processos e ferramentas; software funcional menos do que

documentação abrangente; colaboração do cliente menor do que negociação de contratos;
responder a mudanças menor do que seguir um plano.
37. (INSTITUTO AOCP / PRODEB – 2018) Assinale a alternativa que apresenta corretamente um
dos princípios defendidos pelo Manifesto Ágil.
a) As melhores arquiteturas, requisitos e designs emergem de times com cronogramas bem

definidos.
b) O método mais eficiente e eficaz de transmitir informações para um time de desenvolvimento

é através de uma update meeting.
c) Deve-se construir projetos ao redor de estruturas hierárquicas verticais. Dando a eles o

ambiente e suporte necessário.
102
19
Aula 03
d) Pessoas relacionadas a negócios devem trabalhar sem interferência constante ao time de

desenvolvimento.
e) Em intervalos regulares, o time reflete como ficar mais efetivo, então se ajustam e otimizam
seu comportamento de acordo.
38. (INSTITUTO AOCP / PRODEB – 2018) Assinale a alternativa que apresenta uma característica
presente em Equipes ágeis:
a) Equipe grande.
b) Equipe modestamente motivada.
c) Equipe que se auto-organiza.
d) Individualismo e talento.
e) Alto formalismo.
39. (INSTITUTO AOCP / PRODEB – 2018) Assinale a alternativa correta em relação ao manifesto
ágil para desenvolvimento de software.
a) Uma documentação detalhada é o método mais eficiente e eficaz de transmitir informações

para e por dentro de um time de desenvolvimento.
b) Processos ágeis se adéquam a mudanças para que o cliente possa tirar vantagens
competitivas.
c) Não se deve aceitar mudanças de requisitos no fim do desenvolvimento.
d) Pessoas relacionadas a negócios e desenvolvedores devem manter contato em reuniões

específicas.
e) Deve-se aceitar mudança de requisitos porém o time deve parar o desenvolvimento e voltar
à etapa de validação de requisitos.
40. (INSTITUTO AOCP / PRODEB – 2018) Com a realização do Manifesto Ágil em 2001 por um
conjunto de especialistas em processos de desenvolvimento de software, ficaram definidos
alguns parâmetros principais que passaram a ser um denominador comum de Metodologias
Ágeis. São características atribuídas aos métodos ágeis, EXCETO:
a) processos e ferramentas ao contrário de pessoas e interações.

b) software executável, ao contrário de documentação extensa e confusa.
c) colaboração do cliente, ao contrário de constantes negociações de contratos.
d) indivíduos e interações mais que processos e ferramentas.
e) respostas rápidas para as mudanças, ao contrário de seguir planos previamente definidos.
103
19
Aula 03
41. (FCM / IFN-MG – 2018) O Manifesto Ágil para o Desenvolvimento de Software, proposto por
Beck, K. et al. (2001), propõe 12 princípios. NÃO correspondem a um desses princípios criados
por esses autores:
a) as melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas.
b) a simplicidade é a arte de maximizar a quantidade de trabalho que não precisa ser feito.
c) o projeto para ser ágil precisa ter um controle bem definido sobre as pessoas e as tarefas que
elas executam.
d) a prioridade é satisfazer o cliente através de entrega antecipada e contínua de um software

que tenha valor para o mesmo.
e) a entrega do software deve ser feita com uma frequência predeterminada de tempo,
preferencialmente em uma escala de tempo mais curta.
42. (CS-UFG / UFG – 2019) O desenvolvimento de software baseado em abordagem ágil estimula:
a) a produção de planos detalhados.

b) a realização de atividades de desenvolvimento em cada iteração.
c) a valorização da equipe de operação em detrimento daquela de desenvolvimento.
d) a aplicação de métodos formais de desenvolvimento de software.
43. (INSTITUTO AOCP / ITEP – RN – 2018) Qual das alternativas a seguir apresenta somente
métodos ágeis de desenvolvimento de software?
a) XP e Scrum.
b) Cascata e XP.
c) Incremental e XP.
d) Evolucionário e Scrum.
e) Incremental e Evolucionário.
44.(UECE-CEV / Prefeitura de Sobral - CE – 2018) Escreva V ou F conforme seja verdadeiro ou

falso o que se afirma nos itens abaixo com respeito ao processo de desenvolvimento ágil de
software.
( ) Efetuar testes constantemente permite detectar defeitos mais cedo e da forma menos
custosa possível.
( ) O uso de uma ferramenta robusta de modelagem e uma completa documentação são

imprescindíveis para o desenvolvimento ágil.
104
19
Aula 03
( ) É importante produzir em poucas semanas uma versão inicial do software a fim de obter
rapidamente uma primeira conquista e um feedback adiantado.
( ) Novas versões do software devem ser lançadas em intervalos cada vez mais frequentes, seja
semanalmente, diariamente ou mesmo de hora em hora.
a) V, F, F, V.
b) F, V, F V.
c) V, F, V, F.
d) F, V, V, F.
45. (CETRO / ANVISA – 2013) Com relação aos conceitos do processo ágil, um dos conceitos-chave
do Manifesto Ágil é :
I. produzir documentação em vez de software executável.

II. a colaboração do cliente em vez da negociação de contratos.
III. obter respostas rápidas a mudanças em vez de seguir planos.
É correto o que está contido em:
a) I, apenas.
b) II, apenas.
c) III, apenas.
d) II e III, apenas.
e) I, II e III.
46.(UNIRIO / UNIRIO – 2014) Dentre os princípios do manifesto ágil para desenvolvimento de

software, NÃO se inclui (em):
a) a satisfação do cliente deve ser priorizada através da entrega contínua.

b) conversas face a face são preferíveis para e entre uma equipe de desenvolvimento.
c) simplicidade é essencial.
d) mudança nos requisitos devem ser evitadas.
e) entregas de software funcionando devem ser realizadas frequentemente.
47. (FCM / IF-RS – 2016) As metodologias ágeis tornaram-se populares em 2001 quando um grupo
de especialistas em processos de desenvolvimento de software decidiu se reunir nos Estados
Unidos. O objetivo foi discutir maneiras de melhorar o desempenho de seus projetos. Embora
tivessem preferências e métodos distintos entre si, concordaram que um pequeno conjunto de
princípios sempre parecia ter sido respeitado quando os projetos davam certo. Foi então criada
a Aliança Ágil e o estabelecimento do Manifesto Ágil, contendo os conceitos e os princípios
comuns compartilhados por todos esses métodos.
NÃO é considerado um princípio por trás do Manifesto Ágil:
105
19
Aula 03
a) Responder a mudanças mais que seguir um plano.

b) Colaboração com o cliente mais que negociação de contratos.
c) Processos e ferramentas mais que indivíduos e interação entre eles.
d) Software em funcionamento mais que documentação abrangente.
e) Indivíduos e interação entre eles mais que processos e ferramentas.
48.(FUNCAB / MJ-SP – 2015) O manifesto ágil considera que a medida primária de progresso é:
a) tempo utilizado.
b) quantidadede testes.
c) quantidadede documentação.
d) custo realizado.
e) software funcionando.
49.(UECE-CEV / FUNCEME – 2018) O Manifesto para o desenvolvimento ágil de software resume

os itens mais valorizados pelos praticantes desta abordagem. Considerando os itens listados a
seguir, assinale a opção que NÃO representa um valor ágil segundo o Manifesto.
a) indivíduos e interações mais que processos e ferramentas

b) seguir um plano mais que responder a mudanças
c) software em funcionamento mais que documentação abrangente
d) colaboração com o cliente mais que negociação de contratos
50. (ESAF / MF – 2013) O desenvolvimento ágil de software fundamenta-se no Manifesto Ágil.

Segundo ele deve-se valorizar:
a) mudança de respostas em vez do seguimento de um plano.

b) indivíduos e interações em vez de processos e ferramentas.
c) documentação extensiva operacional em vez de software funcional.
d) indivíduos e intenções junto a processos e ferramentas.
e) seguimento de um plano em vez de resposta a mudança.
51. (IF-PE / IF-PE – 2016) Sobre o documento conhecido como “manifesto ágil”, é CORRETO dizer
que:
a) prega uma extensa lista de documentos, processos, atores, métodos e diagramas visando
fornecer alta agilidade.
b) lista e cataloga a maioria dos métodos vigentes à época de sua criação, classificando cada um
como “ágil” ou “burocrático”.
c) foi criado como base para descrever as principais ideias e práticas que eram comuns a muitos
dos métodos considerados ágeis e que já existiam na época.
106
19
Aula 03
d) foi criado com base na ideia de que se tudo for muito bem controlado e documentado, os
processos serão naturalmente ágeis.
e) a partir dele, foram definidos o XP, o scrum, o crystal, o CMM e o RUP, cada um com suas
características particulares.
52. (CS-UFG / UFG – 2018) Ao se empregar métodos ágeis em desenvolvimento de software, as

atividades:
a) são planejadas com antecedência, e seu progresso é medido em relação ao plano

estabelecido.
b) são realizadas com base na abordagem iterativa/incremental de desenvolvimento.
c) são planejadas com base no modelo cascata, com fases separadas e distintas de especificação
e desenvolvimento.
d) são realizadas em fases sequenciais, sendo que cada fase precisa estar completa antes que se
passe para a próxima.
53. (CESGRANRIO / Banco da Amazônia – 2018) O Manifesto Ágil se tornou um marco da

Engenharia de Software, chamando a atenção de que vários processos propostos de forma
independente tinham valores em comum. Além disso, foram definidos 12 princípios. Entre eles,
figura o seguinte princípio:
a) cada pessoa em um projeto deve ter sua função predeterminada para acelerar o
desenvolvimento em conjunto.
b) a contínua atenção à simplicidade do trabalho feito aumenta a agilidade.
c) software funcionando é a medida primária de progresso.
d) os indivíduos, clientes e desenvolvedores, são mais importantes que processos e ferramentas.
e) o software funcional emerge de times auto-organizáveis.
54. (IADES / ARCON-PA – 2018) Embora esses métodos ágeis sejam todos baseados na noção de
desenvolvimento e entrega incremental, eles propõem diferentes processos para alcançar tal
objetivo. No entanto, compartilham um conjunto de princípios, com base no manifesto ágil, e
por isso têm muito em comum.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Person Education, 2011.
Os cinco princípios citados no texto são:
a) envolvimento do cliente; entregas agendadas; pessoas e processos são igualmente

importantes; aceitar mudanças; e manter a simplicidade.
107
19
Aula 03
b) envolvimento do cliente; entrega incremental; pessoas, não processos; aceitar as mudanças;

e manter a simplicidade.
c) envolvimento do cliente apenas no início; entrega incremental; prazos rígidos; evitar

mudanças; e manter a equipe.
d) programadores em primeiro lugar; ausência de prazos; cliente como última prioridade;

aceitar as mudanças; e investir em controle de versão.
e) programadores em primeiro lugar; entrega por protótipos; processos, não pessoas; aceitar as
mudanças; e manter o cronograma.
55. (FAURGS / TJ-RS – 2018) Considere as seguintes afirmações sobre princípios dos métodos
ágeis.
I - Os clientes devem estar totalmente envolvidos no processo de desenvolvimento. Seu papel é

fornecer e priorizar novos requisitos do sistema e avaliar suas iterações.
II - Embora as habilidades da equipe devam ser reconhecidas e exploradas, seus membros não
devem desenvolver maneiras próprias de trabalhar, podendo o processo ser prescritivo.
III- Deve-se ter em mente que os requisitos do sistema irão mudar, por isso, o sistema deve ser
projetado de maneira a acomodar essas mudanças.
a) Apenas I.
b) Apenas I e II.
c) Apenas I e III.
d) Apenas II e III.
e) I, II e III.
108
19
Aula 03
GABARITO
1. ERRADO 20. LETRA A 39. LETRA B
2. ERRADO 21. LETRA B 40. LETRA A
3. ERRADO 22. LETRA A 41. LETRA C
4. ERRADO 23. LETRA B 42. LETRA B
5. ERRADO 24. LETRA B 43. LETRA A
6. CORRETO 25. LETRA B 44. LETRA C
7. CORRETO 26. LETRA E 45. LETRA D
8. ERRADO 27. LETRA E 46. LETRA D
9. CORRETO 28. LETRA C 47. LETRA C
10. ERRADO 29. LETRA B 48. LETRA E
11. LETRA A 30. LETRA C 49. LETRA B
12. ERRADO 31. LETRA A 50. LETRA B
13. ERRADO 32. LETRA B 51. LETRA C
14. ERRADO 33. LETRA B 52. LETRA B
15. CORRETO 34. LETRA E 53. LETRA C
16. ERRADO 35. LETRA E 54. LETRA B
17. CORRETO 36. LETRA B 55. LETRA C
18. LETRA A 37. LETRA E
19. LETRA B 38. LETRA C
109
19
Aula 03
110

Curso 214614 Aula 03 Metodologias Ágeis

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Curso 214614 Aula 03 Metodologias Ágeis

Enviado por

Direitos autorais:

Formatos disponíveis

Aula 03

MP-MG (Analista do Ministério Público -

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

2) Metodologias Ágeis - Agilidade x Velocidade

3) Metodologias Ágeis - Princípios Ágeis

4) Metodologias Ágeis - Método Ágil x Método Lean

5) Resumo - Metodologias Ágeis

6) Questões Comentadas - Metodologias Ágeis - Multibancas

7) Lista de Questões - Metodologias Ágeis - Multibancas

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

PROFESSOR DIEGO CARVALHO - www.instagram.com/professordiegocarvalho

INCIDÊNCIA EM PROVA: baixíssima

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

Em meados de 2001, 17 especialistas proeminentes da área de desenvolvimento de software se

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

Por que valorizar mais software em funcionamento do que documentação abrangente?

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

Porque é importante o envolvimento contínuo do cliente! Aliás, desenvolvedores e clientes

Porque, em geral, é necessário obter respostas rápidas a mudanças e seguir um

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

Pessoal, agora vamos falar rapidamente sobre uma diferença

maioria dos seus concorrentes. Como é, professor?

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

No contexto de projetos de software, podemos imaginar: eu estou gerenciando meu projeto de um

Eles são mais dinâmicos, adaptativos, interativos e colaborativos – eles se adaptam às

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

NÓS SEGUIMOS ESSES PRINCÍPIOS...

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários

Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial.

As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.

Professor, metodologias ágeis são recomendadas para projetos de qualquer tamanho e

Principais METODOLOGIAS ÁGEIS

CRITÉRIO MODELOS TRADICIONAIS MODELOS ÁGEIS

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

Prioriza os riscos gerais do projeto, mas foca

Possui profissionais com papéis bem Equipe multidisciplinar, multifuncional e auto-

Mudanças são bem-vindas. Evita-se mudar o

Tende a ter uma grande previsibilidade futura

Gera resultados a curto, médio e longo prazo, pois

Geralmente informal e utiliza radiadores de

Conforme o tamanho da iteração e o

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

Abrangente no início e detalhada somente o

Durante todo o projeto, o cliente faz parte da

Em prazos curtos, sempre ao final das iterações.

DISCUSSÕES E Geralmente em prazos longos através da

Conforme a confiança na equipe e ambiente

Empírico e guiado ao produto e às pessoas.

Melhor resultado em projetos cujo escopo é

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

Método Ágil x Método Lean

Não, tem mais...

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

O software que está sendo produzido é uma espécie de espelho da equipe

CARACTERÍSTICA LEAN ÁGIL

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

INDIVÍDUOS E INTERAÇÕES MAIS QUE PROCESSOS E FERRAMENTAS

RESPONDER A MUDANÇAS MAIS QUE SEGUIR UM PLANO