Aula 34 - TI - Engenharia de Software - Metodologias Ágeis

Aula 29 (Profs Diego
Carvalho e Fernando
Pedrosa)
Concursos da Área Fiscal - Curso Básico
de Tecnologia da Informação - 2022
Autor:
Diego Carvalho, Equipe
Informática e TI, Fernando
Pedrosa Lopes , Raphael Henrique
Lacerda, Renato da Costa, Thiago
Rodrigues Cavalcanti
04 de Janeiro de 2022
43089971860 - Filipe Gonçalves Costa

Diego Carvalho, Equipe Informática e TI, Fernando Pedrosa Lopes , Raphael Henrique Lacerda, Renato da Costa, Thiago Rodrigu
Aula 29 (Profs Diego Carvalho e Fernando Pedrosa)
Í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

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

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

..............................................................................................................................................................................................
49
8) Metodologias Ágeis - Scrum

..............................................................................................................................................................................................
65
9) Metodologias Ágeis - Scrum - Pilares Fundamentais

..............................................................................................................................................................................................
72
10) Metodologias Ágeis - Scrum - Principais Valores

..............................................................................................................................................................................................
75
11) Metodologias Ágeis - Scrum - Papeis

..............................................................................................................................................................................................
77
12) Metodologias Ágeis - Scrum - Artefatos

..............................................................................................................................................................................................
87
13) Metodologias Ágeis - Scrum - Eventos

..............................................................................................................................................................................................
98
14) Metodologias Ágeis - Scrum - Novidades do Scrum

..............................................................................................................................................................................................
115
15) Resumo - Metodologias Ágeis - Scrum

..............................................................................................................................................................................................
119
16) Questões Comentadas - Metodologias Ágeis - Scrum - Multibancas

..............................................................................................................................................................................................
123
17) Lista de Questões - Metodologias Ágeis - Scrum - Multibancas

..............................................................................................................................................................................................
188
18) Metodologias Ágeis - XP

..............................................................................................................................................................................................
225
19) Metodologias Ágeis - XP - Principais Práticas

..............................................................................................................................................................................................
230
20) Metodologias Ágeis - XP - Processo do XP

..............................................................................................................................................................................................
232
21) Metodologias Ágeis - XP - Valores Fundamentais

..............................................................................................................................................................................................
237
22) Metodologias Ágeis - XP - Princípios Básicos

..............................................................................................................................................................................................
238
23) Resumo - Metodologias Ágeis - XP

..............................................................................................................................................................................................
240
24) Questões Comentadas - Metodologias Ágeis - XP - Multibancas

..............................................................................................................................................................................................
243
25) Lista de Questões - Metodologias Ágeis - XP - Multibancas

..............................................................................................................................................................................................
296
Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 2

www.estrategiaconcursos.com.br 324
43089971860 -1644786
Filipe Gonçalves Costa
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...

43089971860 -1644786

43089971860 -1644786
==1918f2==

43089971860 -1644786
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.

43089971860 -1644786
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

43089971860 -1644786
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!

43089971860 -1644786
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

43089971860 -1644786
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?

43089971860 -1644786
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
==1918f2==
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

43089971860 -1644786
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.

43089971860 -1644786
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.

43089971860 -1644786
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.
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.

43089971860 -1644786
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 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 forma colaborativa.
equipe executa o projeto guiado pelo
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
==1918f2==
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
DE previamente agendada com os stakeholders informação no ambiente de trabalho durante
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 estabelecido no planejamento do Conforme o tamanho da iteração e o
projeto. No caso de mudanças aprovadas, planejamento das releases para as entregas
PRAZO DE
varia conforme os impactos das solicitações significativas.
ENTREGA 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.
Nas fases iniciais e nas principais validações Durante todo o projeto, o cliente faz parte da
ATUAÇÃO DO
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

43089971860 -1644786
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.

43089971860 -1644786
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?
==1918f2==
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!
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

43089971860 -1644786
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
OSSD SCRUMBAN BADM

43089971860 -1644786

agregado.
Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor
escala de tempo.
Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários

devem ser capazes de manter um ritmo constante indefinidamente.

43089971860 -1644786
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 ==1918f2==
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.

43089971860 -1644786
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

43089971860 -1644786
QUESTÕES COMENTADAS – DIVERSAS BANCAS

1. (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.
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, idealmente ele deve se adaptar de forma incremental; (II) Errado, a agilidade não tem
relação com a facilidade da equipe de se moldar; (III) Errado, mas questão polêmica! Eu acredito
que os conceitos ágeis diminuem a imprevisibilidade. Já alguns argumentam que conceitos ágeis
não diminuem a imprevisibilidade, na verdade eles aceitam que a imprevisibilidade é inevitável e,
dessa forma, provêm métodos de se adaptar às mudanças rapidamente.
Gabarito: Letra A
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.
Comentários:
No ágil, documentação é descartável? Não, ela é útil para ajudar a comunicação e colaboração na
equipe, 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. Logo, não é correto dizer que metodologias ágeis geram
excessiva documentação.
Gabarito: Errado

43089971860 -1644786
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.
Comentários:
Metodologias Ágeis são extremamente afeitas a mudanças de requisitos, adaptando-se a novos

contextos e respondendo a cada modificação. Logo, mudanças nos requisitos são bem-vindas,
mesmo tardiamente no desenvolvimento.
Gabarito: Errado
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.
Comentários:
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”. A questão afirma que ela é aplicada principalmente a grandes corporações. De fato, isso
está errado! Ela ainda é aplicada principalmente a aplicações pequenas e médias, mas permite –
sim – produzir grandes sistemas de forma ágil.
Gabarito: Errado
5. (CESPE / TCU – 2010) A agilidade não pode ser aplicada a todo e qualquer processo de software.
Comentários:
A agilidade pode – sim – ser aplicada a qualquer processo de software. Entretanto, para obtê-la, é
essencial que seja projetado para que a equipe possa adaptar e alinhar (racionalizar) tarefas; possa
conduzir o planejamento compreendendo a fluidez de uma abordagem do desenvolvimento ágil; e
possa eliminar tudo, exceto os artefatos essenciais, conservando-os enxutos.
Gabarito: Errado
6. (CESPE / UNIPAMPA – 2009) XP, Scrum e Cristal são exemplos de modelos ágeis de
desenvolvimento de sistemas.
Comentários:
METODOLOGIAS ÁGEIS

43089971860 -1644786
SCRUM CRYSTAL XP
TDD ATDD BDD
FDD DDD MDD
DSDM ASD KANBAN
OSSD SCRUMBAN BADM
Todos são exemplos de metodologias ágeis (apesar do nome errado: Crystal e, não, Cristal).
Gabarito: Correto
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.
Comentários:
METODOLOGIAS ÁGEIS
SCRUM CRYSTAL XP
TDD ATDD BDD
FDD DDD MDD
DSDM ASD KANBAN
OSSD SCRUMBAN BADM
De fato, todas essas são exemplos de metodologias ágeis.
Gabarito: Correto
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.
Comentários:
Não, desenvolvimento ágil de sistemas não é uma linguagem de modelagem. Sabe qual é um
exemplo de linguagem de modelagem? UML (Unified Modeling Language)!
Gabarito: Errado

43089971860 -1644786
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.
Comentários:
Segundo Martin Fowler, pode-se fixar um orçamento para o software antes de desenvolvê-lo. A
abordagem ágil comum é fixar tempo e preço, deixando o escopo variar (os requisitos são variáveis)
de forma controlada. É o famoso: “Tempo fixo, escopo variável”.
Gabarito: Correto
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.
Comentários:
É absurdo pensar que se desconsidera atividades de elicitação de requisitos – não há o que se

discutir nesse ponto. Além disso, o Manifesto Ágil afirma que, mesmo havendo valor na
documentação extensa de software, valoriza-se mais o software em funcionamento. Em outras
palavras, é errado afirmar que se desconsidera a produção de documentação, tendo em vista que
há uma codificação não formal.
Gabarito: Errado
11. (CESPE / TRE-PI – 2008) No que se refere a métodos ágeis de desenvolvimento de sistemas,
assinale a opção correta.
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.

43089971860 -1644786
e) Para atingir os objetivos de agilidade exigidos, os desenvolvedores devem seguir processos

simplificados para a construção do software.
Comentários:
a) Correto. Aqui temos a teoria e a prática: no início, tanto a teoria quanto a prática não
recomendavam que as metodologias ágeis fossem aplicadas a sistemas grandes. No entanto,
atualmente, isso já não é mais uma limitação. Hoje em dia, as metodologias ágeis adquiriram
maturidade suficiente para desenvolver sistemas grandes e complexos. Porém, isso ainda está na
teoria, por isso as questões ainda cobram.
b) Errado. Em metodologias ágeis, há uma documentação abrangente no início e detalhada

somente o necessário durante o projeto conforme os objetivos das iterações e releases. No entanto,
não existe um "Documento de Requisitos" - isso é coisa de metodologias tradicionais. Além disso,
nenhum documento nunca conseguirá especificar todas as necessidades dos usuários.
c) Correto. Não vislumbro qualquer erro nesse item. Ora, metodologias ágeis são iterativas e
incrementais, dividindo o sistema em pequenas partes e sempre entregando versões que agreguem
valor aos usuários. Se você errou esse item, fique tranquilo - o vacilo foi da banca!
d) Errado. Documentação de Projeto? Isso é coisa de metodologias tradicionais. E, pensa comigo, o

Product Backlog (do Scrum) é feito pelo desenvolvedor? Não, as histórias de usuário são escritas
pelo Product Owner.
e) Errado. Não existe esse negócio de "objetivos de agilidade exigidos". Isso soa como se existissem
métricas de agilidade que tivessem que ser atingidas.
Gabarito: Letra A
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.
Comentários:
É um erro comum achar que metodologias ágeis servem para todas as ocasiões. Não confundam:
agilidade pode ser aplicada a todo processo de software; mas métodos ágeis não funcionam bem
em qualquer situação.
Gabarito: Errado
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.

43089971860 -1644786
Comentários:
De acordo com o 1º Princípio Ágil: Nossa maior prioridade é satisfazer o cliente através da entrega
contínua e adiantada de software com valor agregado. Percebam que não existe entrega completa,
mas contínua.
Gabarito: Errado
14. (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:

(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.

43089971860 -1644786
Gabarito: Letra B
15. (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:

O único princípio correto é que mudanças nos requisitos são bem-vindas, mesmo tardiamente no
desenvolvimento.
Gabarito: Letra A
16. (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.
Comentários:

43089971860 -1644786
(a) Errado, isso realmente ocorre, mas não é um dos princípios do manifesto ágil; (b) Errado,
colaboração com o cliente é mais valorizado que negociação de contratos; (c) Correto; (d) Errado,
responder a mudanças é mais valorizado que seguir um plano.
Gabarito: Letra C
17. (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
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

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;
esquerda”.
Comentários:

43089971860 -1644786
(1) Indivíduos e interações acima de processos e ferramentas; (2) Software em funcionamento

acima de documentação abrangente; (3) Colaboração com o cliente acima de negociação de
contratos; (4) Responder a mudanças acima de seguir fielmente um plano.
Gabarito: Letra A
18. (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
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.
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
Comentários:
(a) Errado, não são estáticos – são incrementais; (b) Correto; (c) Errado, não são estáticos – são
incrementais; (d) Errado, incrementos são pequenos e, não, intermediários; as novas versões são
criadas e, não, descritas; os clientes participam do processo de desenvolvimento e, não, os
desenvolvedores participam no processo de concepção.
Gabarito: Letra B

43089971860 -1644786
19. (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

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.
Comentários:
(a) Errado, isso ocorre em modelos dirigidos a planos, como o modelo em cascata; (b) Correto; (c)
Errado, a questão inverteu os conceitos; (d) Errado, o empirismo é uma característica dos processos
ágeis.
Gabarito: Letra B
20. (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.

43089971860 -1644786
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.
Comentários:
(a) Errado, software em funcionamento é mais valorizado do que documentação abrangente – e um

indicativo melhor de qualidade; (b) Errado, colaboração com o cliente é mais valorizado que
negociação e contratos; (c) Errado, metodologias ágeis prezam mais pelo software funcionando do
que documentação abrangente; (d) Errado, metodologias ágeis prezam mais pelo software
funcionando do que documentação abrangente; (e) Correto, a qualidade de um software é medida
baseado na qualidade do código-fonte e das práticas de programação utilizadas.
Gabarito: Letra E
21. (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.”
Comentários:

agregado.

43089971860 -1644786
Gabarito: Letra E
22. (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

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.
Comentários:
A questão vacila ao dizer no enunciado “indivíduos e iterações” – o correto seria interações.

Ignorando esse deslize, indivíduos e interações são mais valorizados do que processos e
ferramentas; software funcional é mais valorizado do que documentação abrangente; colaboração
do cliente é mais valorizado do que negociação de contratos; responder a mudanças é mais
valorizado do que seguir um plano.

43089971860 -1644786
Gabarito: Letra B
23. (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.
==1918f2==
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.
Comentários:

Gabarito: Letra E
24. (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.

43089971860 -1644786
Comentários:
(a) Errado, equipes pequenas; (b) Errado, equipe altamente motivada; (c) Correto; (d) Errado,
colaboração e talento; (e) Errado, alto empirismo.
Gabarito: Letra C
25. (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.
Comentários:
(a) Errado, 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; (b) Correto; (c) Errado, mudanças nos requisitos
são bem-vindas, mesmo tardiamente no desenvolvimento; (d) Errado, pessoas de negócio e
desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto; (e) Errado, não é
necessário parar o desenvolvimento.
Gabarito: Letra B
26. (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.

43089971860 -1644786
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.
Comentários:

Gabarito: Letra A
27. (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.
Comentários:
(a) Correto, as melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis;

(b) Correto, simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial;
(c) Errado, esse não é um dos doze princípios ágeis; (d) Errado, nossa maior prioridade é satisfazer
o cliente através da entrega contínua e adiantada de software com valor agregado; (e) Errado,
entregar frequentemente software funcionando, de poucas semanas a poucos meses, com
preferência à menor escala de tempo.
Gabarito: Letra C
28. (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.

43089971860 -1644786
Comentários:
Que isso? É exatamente o oposto! O foco é maior no pragmatismo, empirismo e fatores humanos
do que nas definições de atividades ou processos.
Gabarito: Errado
29. (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.
Comentários:
(a) Errado, valoriza-se mais responder a mudanças do que seguir um plano detalhado; (b) Correto;
(c) Errado, isso não existe; (d) Errado, métodos formais são – como o próprio nome diz – formais. A
abordagem ágil prega o empirismo e a resposta à mudanças.
Gabarito: Letra B
30. (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.
Comentários:
(a) Correto; (b) Errado, Cascata é tradicional; (c) Errado, Incremental é tradicional; (d) Errado,
Evolucionário é tradicional; (e) Errado, ambos são tradicionais.
Gabarito: Letra A
31. (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.

43089971860 -1644786
( ) 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.
( ) É 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.
Comentários:
(V) Efetuar testes constantemente permite detectar defeitos mais cedo e da forma menos custosa
possível; (F) Valorizam-se mais indivíduos e interações do que processos e ferramentas; (V) A ideia
é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado; (F)
A ideia é entregar frequentemente software funcionando, de poucas semanas a poucos meses, com
preferência à menor escala de tempo.
Gabarito: Letra C
32. (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.
Comentários:


43089971860 -1644786
Gabarito: Letra B
33. (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.
Comentários:
(I) Errado, software em funcionamento é mais valorizado do que documentação abrangente; (II)
Correto; (III) Correto.
Gabarito: Letra D
34. (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.
Comentários:
(a) Correto, nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada
de software com valor agregado; (b) Correto, 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; (c)
Correto, simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial;
(d) Errado, mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento; (e)
Correto, entregar frequentemente software funcionando, de poucas semanas a poucos meses,
com preferência à menor escala de tempo.

43089971860 -1644786
Gabarito: Letra D
35. (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:
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.
Comentários:

Gabarito: Letra C
36. (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.
Comentários:
De acordo com o 7º princípio ágil: software funcionando é a medida primária de progresso.
Gabarito: Letra E
37. (CESPE / MEC – 2015) Acatar as mudanças de requisitos, ainda que o desenvolvimento já esteja
avançado, é um dos princípios do Manifesto Ágil.

43089971860 -1644786
Comentários:
De acordo com o 2º princípio ágil: 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.
Gabarito: Correto
38. (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.
Comentários:
Gabarito: Errado
39. (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, mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento; (b)
Correto; (c) Errado, em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e
então refina e ajusta seu comportamento de acordo; (d) Errado, pessoas de negócio e

43089971860 -1644786
desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto; (e) Errado, nossa
maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com
valor agregado.
Gabarito: Letra B
40. (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
Comentários:

Gabarito: Letra B
41. (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.
Comentários:

Gabarito: Letra B
42. (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:

43089971860 -1644786
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, as melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis;

(b) Correto; (c) Errado, pessoas de negócio e desenvolvedores devem trabalhar diariamente em
conjunto por todo o projeto; (d) Errado, entregar frequentemente software funcionando, de poucas
semanas a poucos meses, com preferência à menor escala de tempo; (e) Errado, mudanças nos
requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
Gabarito: Letra B
43. (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.
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.
Comentários:

43089971860 -1644786
(a) Errado, prega software em funcionamento mais do que documentações abrangentes ; (b)
Errado, esse item não faz qualquer sentido; (c) Correto; (d) Errado, prega software em
funcionamento mais do que documentações abrangentes; (e) Errado, todos esses métodos já
existiam antes do manifesto ágil.
Gabarito: Letra C
44.(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.
Comentários:
(a) Errado, software funcionando é a medida primária de progresso; (b) Errado, pessoas de negócio
e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto; (c) Errado,
contínua atenção à excelência técnica e bom design aumenta a agilidade; (d) Errado,
patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante
indefinidamente; (e) Correto.
Gabarito: Letra E
45. (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.

43089971860 -1644786
d) são realizadas em fases sequenciais, sendo que cada fase precisa estar completa antes que se
passe para a próxima.
Comentários:
(a) Errado, software funcionando é a medida primária de progresso – valoriza-se mais a resposta a
mudanças do que seguir um plano; (b) Correto; (c) Errado, modelo em cascata utiliza uma
abordagem tradicional e, não, ágil; (d) Errado, são realizadas de forma iterativa e incremental.
Gabarito: Letra B
46.(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.
Comentários:
Nenhum desses faz parte dos doze princípios, exceto: software funcionando é a medida primária
de progresso.
Gabarito: Letra C
47. (CESPE / EBSERH – 2018) Nas metodologias de desenvolvimento ágeis, mudanças em

requisitos são bem recebidas, mesmo em fases mais avançadas do desenvolvimento.
Comentários:
Gabarito: Correto

43089971860 -1644786
48.(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:

Gabarito: Letra E
49.(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:

contratos; (4) Responder a mudanças acima de seguir fielmente um plano. Notem que rapidez na
construção mais que excelência técnica não é um dos valores do manifesto ágil.
Gabarito: Letra C
50. (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:

43089971860 -1644786
a) envolvimento do cliente; entregas agendadas; pessoas e processos são igualmente

importantes; aceitar mudanças; e manter a simplicidade.
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.
Comentários:
(a) Errado. Envolvimento do cliente; entregas agendadas; pessoas e processos são igualmente
importantes; aceitar mudanças; e manter a simplicidade;
(b) Correto. Envolvimento do cliente; entrega incremental; pessoas, não processos; aceitar as
mudanças; e manter a simplicidade.
(c) Errado. Envolvimento do cliente apenas no início; entrega incremental; prazos rígidos; evitar
(d) Errado. Programadores em primeiro lugar; ausência de prazos; cliente como última prioridade;
(e) Errado. Programadores em primeiro lugar; entrega por protótipos; processos, não pessoas;
aceitar as mudanças; e manter o cronograma.
Gabarito: Letra B
51. (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.

43089971860 -1644786
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.
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, pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por
todo o projeto. ; (II) Errado, as melhores arquiteturas, requisitos e designs emergem de equipes
auto-organizáveis da maneira que se sentirem mais adequados; (III) Correto, mudanças nos
requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
Gabarito: Letra C
52. (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:

Gabarito: Letra B

43089971860 -1644786
LISTA DE QUESTÕES – DIVERSAS BANCAS

1. (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.

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.

43089971860 -1644786
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.
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.


43089971860 -1644786
a) somente I;
b) somente II;
c) somente III;
d) somente I e III;
e) I, II e III.

líder;

16. (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.
17. (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
correta que contêm os itens deste manifesto.
a) “Estamos descobrindo melhores maneiras de desenvolver softwares, fazendo-o e ajudando


43089971860 -1644786
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

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;
esquerda”.
18. (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,

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

43089971860 -1644786
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
19. (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

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

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.
20. (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.

43089971860 -1644786
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.
21. (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.”
22. (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

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.

43089971860 -1644786
c) mais do que processos e ferramentas; software funcional menos do que documentação

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.
23. (INSTITUTO AOCP / PRODEB – 2018) Assinale a alternativa que apresenta corretamente um
dos princípios defendidos pelo Manifesto Ágil. ==1918f2==
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.
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.
24. (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.
25. (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.

43089971860 -1644786
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.
26. (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.
27. (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.
28. (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.

43089971860 -1644786
29. (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.
30. (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.
31. (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.
( ) É 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.
32. (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


43089971860 -1644786

33. (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.
e) I, II e III.
34. (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.
35. (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:
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.
36. (FUNCAB / MJ-SP – 2015) O manifesto ágil considera que a medida primária de progresso é:

43089971860 -1644786
a) tempo utilizado.
b) quantidadede testes.
c) quantidadede documentação.
d) custo realizado.
e) software funcionando.
37. (CESPE / MEC – 2015) Acatar as mudanças de requisitos, ainda que o desenvolvimento já esteja
avançado, é um dos princípios do Manifesto Ágil.
38. (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.
39. (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.
iteração.

40. (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
41. (ESAF / MF – 2013) O desenvolvimento ágil de software fundamenta-se no Manifesto Ágil.

Segundo ele deve-se valorizar:

43089971860 -1644786
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.
42. (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:

43. (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.
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.
44.(FGV / DPE-RO – 2015) O Manifesto Ágil é uma declaração que reúne os princípios e práticas

43089971860 -1644786


45. (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.
46.(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.
47. (CESPE / EBSERH – 2018) Nas metodologias de desenvolvimento ágeis, mudanças em

requisitos são bem recebidas, mesmo em fases mais avançadas do desenvolvimento.
48.(FGV / BANESTES – 2018) Um dos valores relacionados ao ambiente ágil de desenvolvimento

é:

43089971860 -1644786

49.(FGV / BANESTES – 2018) Com relação aos valores relacionados ao desenvolvimento ágil de

50. (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.
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

d) programadores em primeiro lugar; ausência de prazos; cliente como última prioridade;

e) programadores em primeiro lugar; entrega por protótipos; processos, não pessoas; aceitar as
mudanças; e manter o cronograma.
51. (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.

43089971860 -1644786
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.


43089971860 -1644786
GABARITO – DIVERSAS BANCAS

1. LETRA A 19. LETRA B 37. CORRETO
2. ERRADO 20. LETRA E 38. ERRADO
3. ERRADO 21. LETRA E 39. LETRA B
4. ERRADO 22. LETRA B 40. LETRA B
5. ERRADO 23. LETRA E 41. LETRA B
6. CORRETO 24. LETRA C 42. LETRA B
7. CORRETO 25. LETRA B 43. LETRA C
8. ERRADO 26. LETRA A 44.LETRA E
10. ERRADO 28. ERRADO 46.LETRA C
11. LETRA A 29. LETRA B 47. CORRETO
12. ERRADO 30. LETRA A 48.LETRA E
13. ERRADO 31. LETRA C 49.LETRA C
14. LETRA B 32. LETRA B 50. LETRA B
15. LETRA A 33. LETRA D 51. LETRA C
16. LETRA C 34. LETRA D 52. LETRA B
17. LETRA A 35. LETRA C
18. LETRA B 36. LETRA E

43089971860 -1644786
APRESENTAÇÃO
O assunto da aula de hoje é: Scrum! Trata-se do principal framework ágil de gerenciamento de
projetos de quaisquer áreas para construção de produtos complexos. Cai demaaaaaaais em prova,
mas ele tem uma vantagem bem interessante: é baseado em um guia bem pequeno. A imensa
maioria das questões são retiradas desse pequeno guia, então aqui nós vamos apenas orientá-los
sobre os detalhes que o guia não mostra.


43089971860 -1644786

43089971860 -1644786
SCRUM
Conceitos Básicos
Galera, alguém de vocês sabe de onde vem esse nome? Então, eu vou contar para vocês! Esse nome
vem do Rugby e é utilizado como uma metáfora para refletir o alto grau de cooperação
necessária para obter sucesso no alcance de algum objetivo. Imagino que poucos de vocês
entendam as regras desse esporte, portanto vou explicar de forma bastante rápida e objetiva o
porquê dessa metáfora ser utilizada.
No Rugby, um time pontua sempre que a bola cruza a linha de gol e toca o chão – sendo carregada
ou por meio de passes. Caso o jogador seja derrubado, ele deve soltar a bola, e a jogada se reiniciará!
Além disso, deve haver intensa troca de passes entre os jogadores, de modo a deixá-los menos
vulneráveis a serem derrubados por outros jogadores. Calma que tudo isso que estou dizendo fará
sentido...
Bem... cada jogada se inicia quando um scrum é realizado, isto é, forma-se uma parede de força
entre os jogadores, como pode ser visto nas imagens acima. Observem que os jogadores se reúnem
de forma bastante próxima e coesa, unindo suas forças e habilidades para trabalhar em conjunto

43089971860 -1644786
e harmonicamente a fim de conseguir recuperar a bola. Percebam, portanto, que o time inteiro
deve trabalhar para que a equipe possa pontuar.
Diferentemente do Futebol Americano, não há um quarterback ou uma estrela no time – todos têm
suas funções e responsabilidades, e são igualmente importantes! Acredito que agora ficou mais
fácil entender de onde vem esse nome. Antes de iniciarmos a teoria, eu gostaria de enfatizar a
importância de ler o guia oficial: ele tem apenas 13 páginas em sua última versão, mas eu inseri na
aula tanto o Guia Scrum Versão 2017 quanto à Versão 2020.
Logo, eu recomendo que vocês o leiam por inteiro, porque ele é a fonte de praticamente tudo que
veremos aqui! Tem versão em português, é gratuito, é enxuto, então não tem desculpas :)
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. Na minha época de concurso, eu decorava
essa definição – sim, eu recomendo decorar algumas definições! Fiquem calmos porque nós vamos
esmiuçar cada parte desse conceito.
[Guia Scrum - Versão 2017]
Scrum é um framework para desenvolver, entregar e manter produtos complexos. Este guia contém a definição do Scrum.
Esta definição consiste em papéis, eventos, artefatos e as regras do Scrum que unem os demais e os mantém integrados.
Ken Schwaber e Jeff Sutherland desenvolveram o Scrum; o Guia do Scrum é escrito e fornecido por eles. Juntos, eles
apoiam o Guia do Scrum.
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. Scrum é: leve, simples de entender e difícil
de dominar.
Scrum é um framework estrutural que está sendo usado para gerenciar o trabalho em produtos complexos desde o início
de 1990. Scrum não é um processo, técnica ou um método definitivo. Em vez disso, é um framework dentro do qual você
pode empregar vários processos ou técnicas. O Scrum deixa claro a eficácia relativa de suas práticas de gerenciamento de
produto e técnicas de trabalho, de modo que você possa continuamente melhorar o produto, o time e o ambiente de
trabalho.

43089971860 -1644786
O framework Scrum consiste de times Scrum associados a papéis, eventos, artefatos e regras. Cada componente dentro
do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum. As regras do Scrum integram
os papéis, eventos e artefatos, administrando as relações e interações entre eles. As regras do Scrum são descritas ao
longo deste documento. Estratégias específicas para o uso do framework Scrum variam e são descritas em outros
documentos.
Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções adaptativas para
problemas complexos.
Em suma, Scrum requer um Scrum Master para promover um ambiente onde:
1. Um Product Owner ordena o trabalho para um problema complexo em um Product Backlog.

2. O Scrum Team transforma uma seleção do trabalho em um incremento de valor durante uma Sprint.
3. O Scrum Team e seus stakeholders inspecionam os resultados e se ajustam para a próxima Sprint.
==1918f2==
4. Repita
Em primeiro lugar, percebam que ele é um framework – isso significa dizer que ele agrega
processos, métodos e técnicas. Fundamentalmente, ele possui pressupostos, conceitos, valores e
práticas, mas quem utilizá-lo pode incluir outras novidades. Ele não te dirá tudo o que fazer, logo
você tem a liberdade para fazer o que melhor funcionar dentro das suas necessidades específicas.
Observem que o Scrum é aplicado no gerenciamento do “trabalho” de desenvolvimento dos

produtos, e não exatamente para gerenciar o produto em si. Ele é eficaz nas suas práticas de
gerenciamento de produto e técnicas de trabalho e se foca na melhoria contínua do produto, do
time e do ambiente de trabalho. Ele não é um método definitivo, ou seja, ele pode ser utilizado
em conjunto, ou complementado, por outras práticas, ferramentas e abordagens.
Em segundo lugar, ele é um documento bastante enxuto conforme acabamos de ver! Vocês verão
que, oficialmente e obrigatoriamente, ele é composto por três papeis, quatro eventos, três
artefatos e por um fluxo (chamado Sprint) – veremos em detalhes adiante. Ele pode comportar
outros artefatos, como Gráfico de Burndown, Documento de Visão, etc. No entanto, esses outros
não são obrigatórios – são como “plug-ins” que podem ser adicionados.
O Scrum foi inicialmente desenvolvido para gerenciar e desenvolver produtos. Iniciando no começo dos anos 90, o Scrum
tem sido usado extensivamente, mundialmente, para: 1. Pesquisar e Identificar mercados viáveis, tecnologias e
funcionalidades de produtos; 2. Desenvolver produtos e melhorias; 3. Liberar produtos e melhorias frequentes, chegando
a várias vezes por dia; 4. Desenvolver e sustentar a Nuvem (online, segura, sob demanda) e outros ambientes operacionais
para uso de produtos; e, 5. Sustentar e renovar produtos.
Scrum tem sido usado para desenvolver software, hardware, software embarcado, redes de funções interativas, veículos
autônomos, escolas, governo, marketing, gerenciar a operação da organização e quase tudo que usamos em nosso dia-
dia nas nossas vidas, como indivíduos e sociedades. Como tecnologia, mercado, complexidades ambientais e suas
interações têm aumentado rapidamente, a utilidade do Scrum em lidar com a complexidade é provada diariamente.

43089971860 -1644786
Scrum demonstra efetividade especialmente na transferência de conhecimento iterativo e incremental. Scrum é agora
amplamente usado para produtos, serviços e no gerenciamento da própria empresa. A essência do Scrum é um pequeno
time de pessoas. O time individual é altamente flexível e adaptativo. Essas forças continuam operando em únicos, muitos,
vários, e em redes de times que desenvolvem, liberam, operam e sustentam o trabalho e trabalham produtos de milhares
de pessoas.
Eles colaboram e interoperam através de arquiteturas sofisticadas de desenvolvimento e ambientes de liberação como
objetivo. Quando as palavras “desenvolver” e “desenvolvimento” são usadas no Guia Scrum, elas se referem a trabalho
complexo, tais como os tipos identificados acima.
Scrum é simples. Experimente como está e determine se sua filosofia, teoria e estrutura ajudam a atingir objetivos e criar
valor. O framework Scrum é propositalmente incompleto, apenas definindo as partes necessárias para implementar a
teoria Scrum. O Scrum é construído sobre a inteligência coletiva das pessoas que o utilizam. Em vez de fornecer às pessoas
instruções detalhadas, as regras do Guia do Scrum orientam seus relacionamentos e interações.
Vários processos, técnicas e métodos podem ser empregados com o framework. Scrum se acopla as práticas existentes ou
as torna desnecessárias. Scrum torna visível a eficácia relativa da gestão atual, meio ambiente e técnicas de trabalho,
para que melhorias possam ser feitas.
O Scrum é um framework para gerenciar projetos, produtos e processos, focado na adaptação em

vez de planejamento, que não utiliza muita documentação e que adota processos mais
simplificados, facilitando a adaptação às mudanças de requisitos e permitindo entregas rápidas e
menores. Ele é usado em ambientes complexos, onde os requisitos e as prioridades mudam
constantemente.

43089971860 -1644786
Diego, o que seria exatamente um ambiente complexo? Existe uma coisa chamada Modelo Cynefin
que explica bem os tipos de ambientes, dividindo-os em simples, complicados, complexos e
caóticos. O que vocês precisam saber é que um ambiente complexo é aquele que não é muito bem
definido, não é muito acoplado, há muitas mudanças, apresenta muitas formas de realizar um
trabalho.
Vamos ver um exemplo: McDonalds é um ambiente complexo? Não, é um ambiente simples! Ele é
muito bem definido, extremamente acoplado, não tem liberdade e não existem muitas opções
de como realizar um trabalho. Em qualquer lugar do mundo, o cardápio será praticamente o
mesmo; o cara que faz o sanduba realiza os mesmos passos; não há mudanças; não há várias formas
de realizar um trabalho.
O Scrum é um framework em que podem ser empregados vários processos e técnicas. Pode ser
definido como um conjunto de papéis, eventos, artefatos e regras associadas a uma equipe. Ele é
fundamentado em teorias empíricas de controle de processo e emprega uma abordagem
iterativa e incremental (maximizando as oportunidades de feedback) para aperfeiçoar a previsão e
controle de riscos.

43089971860 -1644786
Pilares Fundamentais
O Scrum se baseia no empirismo e no lean thinking. O empirismo afirma que o conhecimento

vem da experiência e da tomada de decisões com base naquilo que é verdadeiro e conhecido.
Para tal, ele emprega uma abordagem iterativa e incremental para aperfeiçoar e otimizar a
previsibilidade e controle de riscos. Já o Lean Thinking é uma espécie de estrutura mental (mindset)
que permite reduzir o desperdício e se concentrar no essencial.
O Scrum combina quatro eventos formais para inspeção e adaptação, contidos dentro de uma
sprint (que eventualmente é considerada por questões de prova como um tipo de evento). Esses
eventos funcionam porque implementam três pilares fundamentais para controle do processo
empírico: Transparência, Inspeção e Adaptação (é o famoso TIA). Vejamos adiante em mais
detalhes...
TRANSPARÊNCIA INSPEÇÃO ADAPTAÇÃO

1º PILAR
2º PILAR
3º PILAR
Transparência
Esse pilar trata de aspectos significativos (e padronizados) devem estar visíveis aos responsáveis
pelos resultados. Deve haver transparência dentro e fora da equipe, permitindo a qualquer pessoa
compreender o que realmente está ocorrendo, ocasionando melhor comunicação e confiança. Um
dos autores, Ken Schwaber, diz: “Scrum é igual sogra: chega na sua casa e esfrega todos os seus
problemas na sua cara“.
Se uma iteração falhar, todos devem ficar sabendo; se os feedbacks forem ruins, todos devem ficar
sabendo; se o projeto atrasou, todos devem ficar sabendo. O objetivo é encarar as dificuldades de
forma honesta e chegar a um consenso sobre como estes podem ser ultrapassados. Os erros são
inevitáveis e a equipe deve ser incentivada a encarar esta premissa como uma base para aprender
com os erros que são cometidos.
Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. A transparência requer que
estes aspectos tenham uma definição padrão comum para que os observadores compartilharem um mesmo
entendimento comum do que está sendo visto. Por exemplo: uma linguagem comum referindo-se ao processo deve ser
compartilhada por todos os participantes; e aqueles que realizam o trabalho e aqueles que inspecionam o incremento
resultado do trabalho devem compartilhar uma definição comum de “Pronto”.

43089971860 -1644786
O processo emergente e o trabalho devem ser visíveis tanto para quem executa o trabalho quanto para quem recebe o
trabalho. Com o Scrum, decisões importantes são baseadas no estado percebido de seus três artefatos formais. Artefatos
com baixa transparência podem levar a decisões que diminuem o valor e aumentam o risco. A transparência permite a
inspeção. A inspeção sem transparência é enganosa e gera desperdício.
Inspeção
Também chamada de verificação, os usuários devem frequentemente inspecionar os artefatos

produzidos e o progresso para detectar variações indesejáveis (claro, não pode ser extremamente
frequente ao ponto de atrapalhar a execução das tarefas). Uma vez que todos os problemas sejam
transparentes, esse é o momento de inspecionar o processo e o produto em busca de resolver o
problema. ==1918f2==
Galera, a ideia aqui é identificar rapidamente qualquer desvio em relação à meta que deve ser
atingida. Nós veremos mais à frente que, tanto na Reunião de Revisão quanto na Reunião de
Retrospectiva, os produtos e os processos serão devidamente inspecionados. Essas inspeções em
geral são mais benéficas quando realizadas de forma diligente e cuidadosa por inspetores
especializados no trabalho a se verificar.
Os usuários Scrum 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.
Os artefatos do Scrum e o progresso em direção às metas acordadas devem ser inspecionados com frequência e diligência
para detectar variações ou problemas potencialmente indesejáveis. Para ajudar na inspeção, o Scrum fornece cadência
na forma de seus cinco eventos. A inspeção habilita a adaptação. A inspeção sem adaptação é considerada inútil. Os
eventos Scrum são projetados para provocar mudanças.
Adaptação
Se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos
limites aceitáveis, e que o produto resultado será inaceitável, o processo ou o artefato sendo
produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possível para minimizar
mais desvios. Como mudanças sempre ocorrem, é recomendável se adaptar a mudanças em vez de
evitar mudanças.

43089971860 -1644786
Se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos limites aceitáveis, e que o
resultado do produto será inaceitável, o processo ou o material sendo produzido deve ser ajustado. O ajuste deve ser
realizado o mais breve possível para minimizar mais desvios. O Scrum prescreve quatro Eventos formais para inspeção e
adaptação, como descrito na seção Eventos do Scrum deste documento: Planejamento da Sprint; Reunião diária; Revisão
da Sprint; e Retrospectiva da Sprint.
Se algum aspecto de um processo se desviar fora dos limites aceitáveis ou se o produto resultante for inaceitável, o
processo que está sendo aplicado ou os materiais que estão sendo produzidos devem ser ajustados. O ajuste deve ser feito
o mais rápido possível para minimizar novos desvios. A adaptação se torna mais difícil quando as pessoas envolvidas não
são empoderadas ou auto-gerenciadas. Espera-se que um Scrum Team se adapte no momento em que aprende algo novo
por meio da inspeção.
Vamos resumir os três pilares que sustentam o nosso framework! Tudo no Scrum deve ser
transparente e facilmente acessível. Partindo dessa premissa, podemos inspecionar e identificar
problemas e oportunidades de melhoria do produto e/ou processo – em geral, por meio de eventos
(também chamados de reuniões ou cerimônias). Feito isso, deve-se buscar ajustar e adaptar
produto e/ou processo para minimizar desvios.
Pessoal, lembrem-se que o Scrum é um framework para gerenciar projetos! Em algum momento eu
falei aqui sobre desenvolvimento de software? Não, ele é capaz de gerenciar qualquer projeto que
vise aumentar a agilidade e qualidade da sua execução. Embora tenha sido concebido
inicialmente como uma metodologia de desenvolvimento de software, ele contém elementos que
podem ajudar a formar uma equipe de alto desempenho para qualquer projeto.
O Scrum apenas fornece um framework estruturado para executar alguns princípios. As equipes
de desenvolvimento de software seguem essa metodologia porque seu trabalho é altamente
complexo, interdependente e acelerado. No entanto, se ele funciona para essas equipes,
certamente pode funcionar para outros casos. Se você é um líder de uma equipe que gerencia
projetos complexos, é interessante pensar na aplicação do Scrum!
Dito isso, notem que todos os conceitos que veremos daqui para frente podem ser aplicados a
qualquer projeto, apesar de ter sido concebido para desenvolvimento de software. O primeiro e
talvez principal conceito seja a Sprint! O que é 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.
PILARES DESCRIÇÃO
Todo trabalho deve ser claramente definido e conhecido por todas as partes
TRANSPARÊNCIA
envolvidas no projeto.
Todo trabalho deve ser inspecionado com a frequência necessária para garantir a
INSPEÇÃO
qualidade do produto.
O projeto deve ser capaz de se adaptar o projeto às necessidades de negócio.
ADAPTAÇÃO

43089971860 -1644786
Principais Valores
==1918f2==
O Scrum possui basicamente cinco valores principais: coragem, foco, comprometimento,

respeito e abertura. O sucesso do uso desse framework de gerenciamento de projetos dependerá
intrinsecamente de como os membros se tornam mais familiarizados e proficientes em relação a
cada um desses valores. Vamos falar logo abaixo sobre cada um deles com um pouco mais de
detalhes. Vejamos:
Valores DESCRIÇÃO
Os integrantes de um projeto precisam ter coragem para fazer a coisa certa e
CORAGEM trabalharem juntos removendo impedimentos, buscando soluções.
Os integrantes de um projeto precisam focar no trabalho durante a sprint e nas metas
FOCO
designadas – time disperso perde produtividade e não alcança os objetivos.
Os integrantes se comprometem com o trabalho que se responsabilizou em fazer,
COMPROMETIMENTO envolvendo-se e não abandonando pela metade ou entregando sem qualidade.
Os integrantes se respeitam entre si a fim de manter a colaboração, a integração e o
RESPEITO bom ambiente de trabalho.
Os integrantes devem poder ser francos, expor ideias e propostas mesmo que elas não
ABERTURA
sejam proveitosas. Momentos de debates, discussões e sugestões são ideais.
Quando os valores de comprometimento, coragem, foco, abertura e respeito são incorporados e vividos pelo Time Scrum,
os pilares do Scrum de transparência, inspeção e adaptação tornam-se vivos e constroem a confiança para todos. Os
membros do Time Scrum aprendem e exploram estes valores à medida que trabalham com os eventos, papéis e artefatos

43089971860 -1644786
do Scrum. O Sucesso no uso do Scrum depende das pessoas se tornarem mais proficientes na vivência destes cinco
valores.
As pessoas se comprometem pessoalmente em alcançar os objetivos do Time Scrum. O Time Scrum precisa ter coragem
para fazer a coisa certa e trabalhar em problemas difíceis. Todos focam no trabalho da Sprint e nos objetivos do Time
Scrum. O Time Scrum e seus Stakeholders concordam em estarem abertos a todo o trabalho e aos desafios com a
execução dos trabalhos. Os membros do Time Scrum respeitam uns aos outros para serem pessoas capazes e
independentes.
O Scrum Team se compromete a atingir seus objetivos e suportar uns aos outros. Seu foco principal é o trabalho da Sprint
para fazer o melhor progresso possível em direção a essas metas. O Scrum Team e seus stakeholders são abertos quanto
ao trabalho e os desafios. Os membros do Scrum Team se respeitam quanto a serem pessoas capazes e independentes, e
são respeitados como tal pelas pessoas com quem trabalham. Os membros do Scrum Team têm a coragem de fazer a
coisa certa e trabalhar em problemas difíceis.
Esses valores orientam o Scrum Team em relação ao seu trabalho, ações e comportamento. As decisões que são tomadas,
os passos dados e a forma como o Scrum é usado devem reforçar esses valores, não diminuí-los ou miná-los. Os membros
do Scrum Team aprendem e exploram os valores à medida que trabalham com os eventos e artefatos do Scrum. Quando
esses valores são incorporados pelo Scrum Team e pelas pessoas com quem trabalham, os pilares empíricos do Scrum de
transparência, inspeção e adaptação ganham vida, construindo confiança.
(TRANSPETRO – 2018) Entre os processos de desenvolvimento de software ágeis mais

usados no Brasil está o SCRUM. Quais são os pilares do SCRUM que apoiam a
implementação de controle de processo empírico?
a) Comprometimento, coragem, foco e respeito

b) Comprometimento, transparência e adaptação
c) Coragem, inspeção e adaptação
d) Transparência, adaptação, foco e respeito
e) Transparência, inspeção e adaptação
_______________________
Comentários: a questão mistura valores (Foco, Abertura, Coragem, Comprometimento e Respeito) com pilares (Transparência,
Inspeção e Adaptação) (Letra E).

43089971860 -1644786
Papéis
O Scrum possui poucos papeis, mas muito bem definidos! As pessoas que desempenham esses
papeis são igualmente responsáveis e responsabilizadas pelos resultados do trabalho e, assim, se
comprometem com o projeto. Eles são membros de um mesmo time e trabalham juntos, de forma
colaborativa, para alcançarem seus resultados. Os papeis são diferentes dependendo da versão
de referência:
DEVELOPMENT TEAM DEVELOPERS

( EQUIPE DE DESENVOLVIMENTO ) ( DESENVOLVEDORES )
SCRUM TEAM (VERSÃO 2020)

( EQUIPE SCRUM )
( EQUIPE SCRUM )
PRODUCT OWNER PRODUCT OWNER

( DONO DO PRODUTO ) ( DONO DO PRODUTO )
SCRUM MASTER SCRUM MASTER

( MESTRE SCRUM ) ( MESTRE SCRUM )
O Time Scrum consiste em um Product Owner, o Time de Desenvolvimento e um Scrum Master. Times Scrum são auto-
organizáveis e multifuncionais. Times auto-organizáveis escolhem qual a melhor forma para completarem seu trabalho,
em vez de serem dirigidos por outros de fora do Time. Times multifuncionais possuem todas as competências necessárias
para completar o trabalho sem depender de outros que não fazem parte da equipe. O modelo de time no Scrum é projetado
para aperfeiçoar a flexibilidade, criatividade e produtividade.
O Time Scrum demonstra-se estar aumentando sua efetividade para todos os usos anteriormente citados, e qualquer
trabalho complexo. Times Scrum entregam produtos de forma iterativa e incremental, maximizando as oportunidades
para feedback. Entregas incrementais de produto “Pronto” garantem que uma versão potencialmente funcional do
produto do trabalho esteja sempre disponível. O tamanho ideal do Time de Desenvolvimento é pequeno o suficiente para
se manter ágil e grande o suficiente para completar um trabalho significativo dentro da Sprint.
Menos de três integrantes no Time de Desenvolvimento diminuem a interação e resultam em um menor ganho de
produtividade. Times de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando
um Time de Desenvolvimento incapaz de entregar um incremento potencialmente liberável. Havendo mais de nove
integrantes é exigida muita coordenação. Times de Desenvolvimento grandes geram muita complexidade para que um
processo empírico seja útil. Os papéis de Product Owner e de Scrum Master não são incluídos nesta contagem, a menos
que eles também executem o trabalho do Backlog da Sprint.
A unidade fundamental do Scrum é um pequeno time de pessoas, um Scrum Team. O Scrum Team consiste em um Scrum
Master, um Product Owner e Developers. Dentro de um Scrum Team, não há sub-times ou hierarquias. É uma unidade
coesa de profissionais focados em um objetivo de cada vez, a Meta do Produto. Os Scrum Teams são multifuncionais, o

43089971860 -1644786
que significa que os membros possuem todas as habilidades necessárias para criar valor a cada Sprint. Eles também são
autogerenciáveis, o que significa que decidem internamente quem faz o quê, quando e como.
O Scrum Team é pequeno o suficiente para permanecer ágil e grande o suficiente para concluir um trabalho significativo
dentro de uma Sprint, normalmente 10 ou menos pessoas. Em geral, descobrimos que times menores se comunicam
melhor e são mais produtivos. Se os Scrum Teams se tornarem muito grandes, eles devem considerar a reorganização em
vários Scrum Teams coesos, cada um focado no mesmo produto. Portanto, eles devem compartilhar a mesma meta do
produto, Product Backlog e Product Owner.
O Scrum Team é responsável por todas as atividades relacionadas ao produto, desde a colaboração com stakeholder,
verificação, manutenção, operação, experimentação, pesquisa e desenvolvimento, e qualquer outra coisa que possa ser
necessária. Eles são estruturados e empoderados pela organização para gerenciar seu próprio trabalho. Trabalhar em
Sprints em um ritmo sustentável melhora o foco e a consistência do Scrum Team. Todo o Scrum Team é responsável por
criar um Incremento valioso e útil a cada Sprint. Scrum define três responsabilidades específicas dentro do Scrum Team:
os Developers, o Product Owner e o Scrum Master.
==1918f2==
Na versão 2017, é importante não confundir Development Team com Scrum Team! A Equipe Scrum
que é um time auto-organizável e multifuncional! Ser auto-organizável significa que ela é capaz
de escolher qual a melhor forma para realizar seu próprio trabalho em vez de serem dirigidos por
outros de fora do Time. Ser multifuncional significa que ela possui todas as competências e não
depende de outros de fora da equipe.
Em outras palavras, os times de desenvolvimento não contêm subtimes dedicados a domínios

específicos de conhecimento (Ex: testadores, analistas de negócio, entre outros). A Equipe Scrum
é o responsável por entregar produtos de forma iterativa e incremental, maximizando as
oportunidades de realimentação (feedback). Uma dúvida comum é: professor, pode existir uma
sobreposição nesses papeis, isto é, uma mesma pessoa desempenhando dois papeis diferentes?
Não! Scrum Master e o Product Owner podem fazer parte do Development Team [Versão 2017],
mas um Scrum Master jamais pode ser simultaneamente Product Owner! Essa última afirmação
não está explícita no Guia Scrum, mas é possível inferir que pode haver um conflito de interesses.
Quanto à primeira afirmação: “The Product Owner and Scrum Master roles are not included in this
count unless they are also executing the work of the Sprint Backlog”.
(TJ-PE – 2017) O Scrum está sendo implantado dentro da sua empresa, portanto existe
a necessidade de se criar o Time Scrum que é formado pelo:
a) Product Backlog, o Time de Planejamento e o Scrum Master

b) Product Owner, o Time de Desenvolvimento e o Scrum Sprint
c) Product Backlog, o Time de Planejamento e o Scrum Sprint
d) Product Owner, o Time de Desenvolvimento e o Scrum Master
e) Product Backlog, o Time de Desenvolvimento e o Scrum Sprint
_______________________
Comentários: o Time Scrum é formado pelo Product Owner, Time de Desenvolvimento (Desenvolvedores) e Scrum Master
(Letra D).

43089971860 -1644786
Product Owner (PO)
O Product Owner é uma pessoa e, não, um comitê. Ele pode representar o desejo de um comitê
no Product Backlog, mas aqueles que quiserem uma alteração nas prioridades dos itens de
backlog devem convencer o Product Owner. Para que ele tenha sucesso, toda a organização deve
respeitar as suas decisões e elas devem ser visíveis no conteúdo e na priorização do Backlog do
Produto. Vejamos a seguir suas responsabilidades e características:
Ele é responsável pela macro-gestão e pela gestão do produto.
Ele é o responsável por maximizar o valor do produto e do trabalho dos desenvolvedores, sendo o único
que pode gerenciar o Product Backlog.
Ele pode até delegar as atividades de gerenciamento para os desenvolvedores, mas ainda será
considerado o responsável pelos trabalhos.
PRODUCT OWNER (PO)
RESPONSABILIDADES
Ele é responsável por priorizar/ordenar os itens do Product Backlog e seleciona aqueles que serão
implementados.
Ele é responsável por garantir o ROI (Returno On Investment ou Retorno sobre Investimento).
Ele é responsável por expressar claramente os itens do Product Backlog.
Ele é responsável por garantir que o Backlog do Produto seja visível, transparente, claro para todos, e
mostrar o que a Equipe Scrum vai trabalhar a seguir.
Ele é responsável por garantir que os desenvolvedores entendam os itens do Product Backlog no nível
necessário.
O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto resultado do trabalho do Time
de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos. O
Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. O gerenciamento do Backlog do Produto
inclui:
• Expressar claramente os itens do Backlog do Produto;

• Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;
• Otimizar o valor do trabalho que o Time de Desenvolvimento realiza;
• Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai
trabalhar a seguir; e,
• Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.
O Product Owner pode fazer o trabalho acima, ou delegar para o Time de Desenvolvimento fazê-lo. No entanto, o Product
Owner continua sendo o responsável pelos trabalhos. 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. Para que o Product Owner tenha sucesso, toda a organização
deve respeitar as decisões dele(a). As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do
Produto. Ninguém pode forçar o Time de Desenvolvimento a trabalhar em um diferente conjunto de requerimentos.

43089971860 -1644786
O Product Owner é responsável por maximizar o valor do produto resultante do trabalho do Scrum Team. A forma como
isso é feito pode variar amplamente entre organizações, Scrum Teams e indivíduos. O Product Owner também é
responsável pelo gerenciamento eficaz do Product Backlog , que inclui:
• Desenvolver e comunicar explicitamente a meta do produto;

• Criar e comunicar claramente os itens do Product Backlog;
• Ordenar os itens do Product Backlog; e,
• Garantir que o Product Backlog seja transparente, visível e compreensível.
O Product Owner pode fazer o trabalho acima ou pode delegar a responsabilidade a outros. Independentemente disso, o
Product Owner ainda é o responsável. Para que os Product Owners tenham sucesso, toda a organização deve respeitar
suas decisões. Essas decisões são visíveis no conteúdo e na ordem do Product Backlog e por meio do incremento
inspecionável na revisão da sprint. O Product Owner é uma pessoa, não um comitê. O Product Owner pode representar
as necessidades de muitos stakeholders no Product Backlog. Aqueles que desejam alterar o Product Backlog podem fazê-
lo tentando convencer o Product Owner.
(DETRAN-MT – 2015) No Scrum, há três papéis importantes: Product Owner, Team e

Scrum Master. É responsabilidade do Product Owner:
a) Determinar como serão a gestão e a organização dos times.

b) Desenvolver funcionalidades do projeto.
c) Assegurar que a funcionalidade mais valiosa será produzida primeiro.
d) Ensinar Scrum a todos os envolvidos no projeto.
_______________________
Comentários: (a) Errado, essa não é uma responsabilidade do Product Owner; (b) Errado, essa é uma responsabilidade dos
desenvolvedores; (c) Correto, ele é responsável por priorizar as funcionalidades no Product Backlog; (d) Errado, essa é uma
responsabilidade do Scrum Master (Letra C).
(UFRJ – 2018) No framework Scrum, o papel que tem como uma das responsabilidades,
maximizar o valor do produto e do trabalho do Time de Desenvolvimento, além de ser a
pessoa responsável por gerenciar o Backlog do Produto é denominado:
a) Product Owner.
b) Scrum Master.
c) Scrum Team.
d) Stakeholder.
e) Development Team.
_______________________
Comentários: o papel responsável por maximizar o valor do produto e do trabalho do time de desenvolvimento
(desenvolvedores), além de ser a pessoa responsável por gerenciar o Backlog do Produto é o Product Owner (Letra A).

43089971860 -1644786
evelopers (DV)
Os Desenvolvedores consistem em profissionais que realizam o trabalho de entregar uma

versão usável que potencialmente incrementa o produto “pronto” ao final de cada sprint.
Somente Desenvolvedores criam incrementos. Ninguém tem permissão para falar com os eles
sobre diferentes configurações de prioridade e os eles não têm permissão para agir sobre o que
outras pessoas disserem.
Os Desenvolvedores só respondem ao Product Owner. Além disso, só ele pode cancelar uma
sprint. Ele deve ser pequeno o suficiente de forma a se manter ágil e produtivo, e grande o
suficiente de forma que a coordenação dos membros não cause problemas. A versão anterior do
guia recomendava que a equipe tivesse entre 3 e 9 integrantes (excluídos o Product Owner e Scrum
Master – exceto se eles também executarem o trabalho da sprint).
No Guia Scrum 2020, houve uma alteração de nomes. O termo ‘Time de Desenvolvimento’ passava
a impressão de que existia um sub-time no Time Scrum. Esse termo foi substituído por uma nova
responsabilidade: Desenvolvedores. Isso reforça a ideia de existir apenas um único time: o Time
Scrum – que é formado pelo Scrum Master, o Product Owner e os Desenvolvedores, sendo que seus
objetivos devem ser os mesmos.
A ideia por trás dessa mudança não é apenas semântica: ao remover o conceito de sub-time dentro
da equipe e deixar claro que todas essas pessoas pertencem ao mesmo time, o Time Scrum, isso
cria um compromisso mais forte entre todos para a entrega da Meta da Sprint. O Time Scrum é,
portanto, apenas uma equipe com três responsabilidades diferentes e objetivos idênticos. Fechado?
A versão anterior dizia que o Time de Desenvolvimento deveria idealmente ser composto por 3 a 9
integrantes. Com o objetivo de se tornar ainda menos prescritivo, agora não há tamanho mínimo
ou máximo para os desenvolvedores. No entanto, o Scrum Guide comenta que o Scrum Team
normalmente tem 10 ou menos integrantes – incluindo na conta o Scrum Master e o Product
Owner. Não mudou muita coisa da versão anterior, mas deixou mais aberto...
Responsável pela micro-gestão e pela criação do produto.

CARACTERÍSTICAS: desenvolvedores
Eles são auto-organizados. Ninguém (nem mesmo o SM) diz aos desenvolvedores como transformar o
RESPONSABILIDADES E
Product Backlog em incrementos de funcionalidades potencialmente utilizáveis.

Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto
equipe, para criar o incremento do Produto.
O Scrum não reconhece títulos específicos para os desenvolvedores, independentemente do trabalho que
está sendo realizado pela pessoa;
Individualmente, os desenvolvedores podem ter habilidades especializadas, mas a responsabilidade
pertence aos desenvolvedores como um todo.
Os desenvolvedores não contêm sub-times dedicados a domínios específicos de conhecimento, tais como
teste ou análise de negócios.

43089971860 -1644786
Os desenvolvedores são estruturados e autorizados pela organização para organizar e gerenciar seu
próprio trabalho.
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. Um incremento “Pronto” é requerido na Revisão da Sprint. Somente
integrantes do Time de Desenvolvimento criam incrementos. Os Times de Desenvolvimento são estruturados e
autorizados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência
e a eficácia do Time de Desenvolvimento como um todo.
Developers são as pessoas do Scrum Team que estão comprometidas em criar qualquer aspecto de um Incremento
utilizável a cada Sprint. As habilidades específicas necessárias pelos Developers geralmente são amplas e variam de
acordo com o domínio de trabalho. No entanto, os Developers são sempre responsáveis por: criar um plano para a Sprint,
o Sprint Backlog; introduzir gradualmente qualidade aderindo a uma Definição de Pronto; adaptar seu plano a cada dia
em direção à meta da Sprint; e responsabilizar-se mutuamente como profissionais.
(Banco da Amazônia – 2018) No SCRUM, o Backlog da Sprint é “um conjunto de itens

do Backlog do Produto selecionados para Sprint, juntamente com o plano para entregar
o incremento do produto e atingir o objetivo da Sprint”
(Schwaber e Sutherland, 2017).
Durante a Sprint, quem pode alterar o Backlog da Sprint?
a) Product Owner, apenas

b) Scrum Master, apenas
c) Time de Desenvolvimento, apenas
d) Time de Desenvolvimento e o Product Owner, apenas
e) Time de Desenvolvimento e o Scrum Master, apenas
_______________________
Comentários: durante a sprint, apenas o Time de Desenvolvimento (Desenvolvedores) pode alterar o Sprint Backlog (Letra C).
(TRE-MT – 2015) Em um projeto ágil em que se utiliza Scrum, a criação e a estimação de

tarefas cabe ao:
a) gerente de projeto.
b) product owner.
c) time de desenvolvimento.
d) Scrum master.
e) time de desenvolvimento, ao Scrum master e ao product owner, em conjunto.
_______________________
Comentários: a criação e a estimação de tarefas cabem ao Time de Desenvolvimento ou Desenvolvedores (Letra C).

43089971860 -1644786
Scrum Master (SM)
O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado! Ele faz isso
para garantir que a Equipe Scrum adira à teoria, práticas e regras do Scrum. O Scrum Master é um
servo-líder para a Equipe Scrum. Ele ajuda aqueles que estão fora da a Equipe Scrum a entender
quais as suas interações com a Equipe Scrum são úteis e quais não são. Ademais, ele ajuda todos a
mudarem estas interações para maximizar o valor criado pela Equipe Scrum.
Responsável pela gestão de pessoas e gestão do processo.
Ele deve garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que a
Equipe Scrum adere à teoria, práticas e regras do Scrum.
O Scrum Master ajuda aqueles que estão fora da Equipe Scrum a entender quais as suas interações com
a Equipe Scrum são úteis e quais não são.
O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pela Equipe
Scrum.
Ele é responsável por orientar o Product Owner na criação e ordenação do Product Backlog.
Ele é responsável por garantir que as regras do Scrum estejam sendo cumpridas e seus valores estejam
scrum master (sm)
RESPONSABILIDADES
sendo seguidos.
Ele é responsável por ajudar a remover impedimentos que o time enfrente, fazendo isso sem o uso de
qualquer autoridade.
Ele utiliza técnicas de facilitação e coaching para que os membros do time consigam visualizar os
problemas e encontrem a melhor solução.
Durante eventos, ele é responsável por fazer com que a reunião flua adequadamente, utilizando técnicas
de facilitação, embora não seja o responsável pela condução.
Ele ajuda a treinar os desenvolvedores em autogerenciamento e interdisciplinaridade.
Ele treina os desenvolvedores em ambientes organizacionais nos quais o Scrum não é totalmente
adotado e compreendido.
Ele ensina a Equipe Scrum a criar itens do Product Backlog de forma clara e concisa.
Ele comunica claramente a visão, objetivo e itens do Product Backlog para os desenvolvedores.
O Scrum Master é responsável por promover e suportar o Scrum como definido no Guia Scrum. O Scrum Master faz isso
ajudando todos a entenderem a teoria, as práticas, as regras e os valores do Scrum. O Scrum Master é um servo-líder para
o Time Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o
Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor
criado pelo Time Scrum.
O Scrum Master trabalhando para o Product Owner
O Scrum Master serve o Product Owner de várias maneiras, incluindo:

43089971860 -1644786
• Garantindo que objetivos, escopo e domínio do produto sejam entendidos o melhor possível por todos do Time Scrum.
• Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;
• Ajudando o Time Scrum a entender as necessidades para ter itens de Backlog do Produto claros e concisos.
• Compreendendo o planejamento do Produto em um ambiente empírico;
• Garantindo que o Product Owner saiba como organizar o Backlog do Produto para maximizar valor;
• Compreender e praticar a agilidade; e,
• Facilitar os eventos Scrum conforme exigidos ou necessários.
O Scrum Master trabalhando para o Time de Desenvolvimento
O Scrum Master serve o Time de Desenvolvimento de várias maneiras, incluindo:
• Treinando o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade;

• Ajudando o Time de Desenvolvimento na criação de produtos de alto valor;
• Removendo impedimentos para o progresso do Time de Desenvolvimento;
• Facilitando os eventos Scrum conforme exigidos ou necessários; e,
• Treinando o Time de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e
compreendido.
O Scrum Master trabalhando para a Organização
O Scrum Master serve a Organização de várias maneiras, incluindo:
• Liderando e treinando a organização na adoção do Scrum;

• Planejando implementações Scrum dentro da organização;
• Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto
empírico;
• Causando mudanças que aumentam a produtividade do Time Scrum; e,
• Trabalhando com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum na organização.
O Scrum Master é responsável por estabelecer o Scrum conforme definido no Guia do Scrum. Eles fazem isso ajudando
todos a entender a teoria e a prática do Scrum, tanto no Scrum Team quanto na organização. O Scrum Master é
responsável pela eficácia do Scrum Team. Eles fazem isso permitindo que o Scrum Team melhore suas práticas, dentro
do framework Scrum Scrum Masters são verdadeiros líderes que servem ao Scrum Team e à organização como um todo.
O Scrum Master serve ao Scrum Team de várias maneiras, incluindo:
• Treinar os membros do time em autogerenciamento e cross-funcionalidade;

• Ajudar o Scrum Team a se concentrar na criação de incrementos de alto valor que atendem à Definição de Pronto;
• Provocando a remoção de impedimentos ao progresso do Scrum Team; e,
• Garantir que todos os eventos Scrum ocorram e sejam positivos, produtivos e mantidos dentro do Timebox.
O Scrum Master serve o Product Owner de várias maneiras, incluindo:
• Ajudar a encontrar técnicas para a definição eficaz de meta do Produto e gerenciamento do Product Backlog;
• Ajudar o Scrum Team a entender a necessidade de itens do Product Backlog claros e concisos;
• Ajudar a estabelecer o planejamento empírico do produto para um ambiente complexo; e,
• Facilitar a colaboração dos stakeholder, conforme solicitado ou necessário.

43089971860 -1644786
O Scrum Master serve a organização de várias maneiras, incluindo:
• Liderar, treinar e orientar a organização na adoção do Scrum;

• Planejar e aconselhar implementações de Scrum dentro da organização;
• Ajudar os funcionários e os stakeholders a compreender e aplicar uma abordagem empírica para trabalhos complexos;
e,
• Remover barreiras entre stakeholders e Scrum Teams.
Galera, eu só consigo explicar por metáfora, então vamos tentar entender esses papeis! Imaginem
que João deseja construir uma casa. Para tal, ele contrata uma renomada empresa de engenharia.
A empresa irá fornecer todo seu know-how por meio de uma Equipe de Construção de Casas, que
será composta por uma Equipe de Pedreiros, um Mestre de Obras e... por você! Sim, você fará
parte da Equipe de Construção de Casas como principal parte interessada.
Vamos dar um nome para você? Você ocupará o cargo de Dono da Casa. Portanto, a Equipe de
Construção de Casas será composta por uma Equipe de Pedreiros, pelo Mestre de Obras e pelo
Dono da Casa. E como será a organização e a função de cada um desses papeis? Bem, a Equipe de
Pedreiros é composta por 3 a 9 pedreiros multidisciplinares, isto é, todos dominam todas as
atividades de um pedreiro.
Galera, esses caras são os responsáveis por colocar a mão na massa, levantar parede, fazer o
concreto, alinhar o piso, entre outras atividades. Já o Mestre de Obras é o grande facilitador! Como
assim, professor? Ele é o cara que vai retirar os impedimentos que aparecem no decorrer do
nosso projeto. Um pedreiro faltou? Ficou doente? Se machucou? Ele irá buscar uma maneira de
reduzir os impactos dessa ausência.
Os pedreiros estão desmotivados, distraídos, descuidados? Ele irá arrumar uma maneira de solucionar
isso. Um pedreiro saiu na porrada com outro? Ele vai tentar intermediar o conflito. Além disso, ele
que vai trazer a demanda do Dono da Casa, entender o que ele quer e passar de maneira
simples, clara e objetiva para a Equipe de Pedreiros. Ele é o cara que mais deve conhecer os
fundamentos da construção de uma casa!
Imaginem ele como um grande estudioso da construção de casas com bastante experiência
adquirida em anos de empreendimentos. Ele saca tudo sobre como se faz para se construir uma
casa, qual é o papel de cada um, qual é a melhor ordem, quais são as melhores técnicas e é um
grande professor, capaz de ensinar a todos os outros integrantes quais são os melhores princípios
para a construção de casas. Em outras palavras, ele é um grande mestre!
Por fim, ele também é capaz de treinar a equipe de construção para que ela seja auto-gerenciável e
interdisciplinar. Legal, mas está faltando um papel nessa história. E qual é? É o seu papel! Qual a sua
função? Você é o Dono da Casa! Logo, você que gerencia o que será feito e o que não será feito,
sendo também o responsável pelo que será entregue. A Equipe de Pedreiros responde a você!
Até o Mestre de Obras responde somente a você! Viu a sua importância?

43089971860 -1644786
Você é o cara que tem que tentar fazer essa casa ficar da melhor forma possível – com máximo valor
agregado. Você é o cara que vai priorizar o que deve ser feito primeiro; você é o cara que coloca
ou tira tarefas da lista tarefas a serem realizadas; você é o único cara que pode cancelar
determinada tarefa; você é o cara que fiz expressamente o que deve ser feito; enfim... você ocupa
um papel importantíssimo para o sucesso do projeto de construir uma casa.
Galera, toda metáfora possui suas limitações, mas acho que vocês conseguiram captar a mensagem
aqui! A Equipe de Construção de Casas é o Scrum Team; a Equipe de Pedreiros é o Development
Team; o Mestre de Obras é o Scrum Master; e o Dono da Casa é o Product Owner. Além disso, cada
um desses tem atividades bem definidas e o controle sobre essas atividades é descentralizado.
Entendido? Seeeeeegue o jogo...
(TRE-RS – 2015) No desenvolvimento ágil de sistemas utilizando o Scrum, um integrante

da equipe é encarregado de comunicar a visão, os objetivos e os itens do product backlog
para o time de desenvolvimento, além de encontrar técnicas para o gerenciamento
efetivo do product backlog. Esse integrante é o:
a) Product Owner, sob orientação do Scrum Master.

b) próprio time de desenvolvimento, que realiza essas definições de forma auto-
organizada.
c) Scrum Master.
d) Team Leader.
e) Product Owner, diretamente.
_______________________
Comentários: o integrante encarregado de comunicar a visão, os objetivos e os itens do Product Backlog para o time de
desenvolvimento, além de encontrar técnicas para o gerenciamento efetivo do Product Backlog é o Scrum Master (Letra C).
(EPTC – 2012) No Scrum, existem papéis bem definidos. Assinalar a alternativa a qual o
trecho abaixo se refere:
Tem como função primária remover impedimentos para que a equipe consiga entregar o
objetivo do Sprint. Além dessa função, a pessoa nesse papel tem a função de assegurar que
as práticas do Scrum sejam utilizadas corretamente.
a) Scrum Product Owner.

b) Scrum Master.
c) Scrum Manager.
d) Scrum Project Manager.
_______________________
Comentários: esse é o papel do Scrum Master (Letra B).

43089971860 -1644786
Artefatos
Segundo o Guia do Scrum, o framework possui apenas três artefatos oficiais: Product Backlog,
Sprint Backlog e Product Increment. Um artefato é o produto de um trabalho...
Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para
inspeção e adaptação. Os artefatos definidos para o Scrum são especificamente projetados para maximizar a
transparência das informações chave de modo que todos tenham o mesmo entendimento dos artefatos
Os artefatos do Scrum representam trabalho ou valor. Eles são projetados para maximizar a transparência das principais
informações. Assim, todos os que os inspecionam têm a mesma base para adaptação. Cada artefato contém um
compromisso para garantir que ele forneça informações que aumentem a transparência e o foco contra o qual o progresso
pode ser medido:
• Para o Product Backlog, é a Meta do produto.

• Para o Sprint Backlog, é a Meta da Sprint.
• Para o incremento, é a Definição de Pronto.
Esses compromissos existem para reforçar o empirismo e os valores Scrum para o Scrum
Team, e seus stakeholders.
Product Backlog
Trata-se de uma lista ordenada (por valor, risco, prioridade, entre outros) de requisitos
PRODUCT BACKLOG ou funcionalidades que o produto deve conter criada pela Equipe Scrum e gerenciada
pelo Product Owner.
Antes de tudo, o que é um backlog? Galera, um backlog é basicamente uma lista, um resumo
histórico, de acumulação de trabalho num determinado período de tempo, pode ser uma pilha de
pedidos que devem ser produzidos. Já o Product Backlog é uma lista ordenada (por valor, risco,
prioridade, entre outros) de requisitos ou funcionalidades que o produto deve conter1 criada
pela Equipe Scrum.
O Product Backlog é a origem única dos requisitos para qualquer mudança a ser feita no produto.
Costuma-se dizer que ele é um artefato dinâmico que nunca estará completo e existirá
enquanto o produto também existir. Por que? Porque sempre haverá novos requisitos, novas
1
Apesar de o Scrum Team (PO, SM, DV) ser o responsável pela criação do Product Backlog, o responsável pelo artefato e o único que pode priorizar
suas funcionalidades é o Product Owner.

43089971860 -1644786
necessidades e mudanças a serem incorporadas. Logo, trata-se de um artefato vivo – sempre em

movimento.
O Product Backlog evolui tanto quanto o produto e o ambiente no qual ele será utilizado
evoluem. Ele muda constantemente para identificar o que o produto necessita para ser mais
apropriado, competitivo e útil para as partes interessadas. Lembrando que somente o Product
Owner pode inserir, remover ou reordenar esses itens, incluindo seu conteúdo, disponibilidade e
ordenação.
Rafael Prikladnicki afirma que o formato mais utilizado para os itens são Histórias de Usuário (User
Stories) ordenadas de acordo com o critério escolhido pelo Product Owner. O que são histórias de
usuário? É basicamente uma especificação 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.
Enfim... em geral, itens mais importantes ficam no topo do Product Backlog e são
implementados primeiro. Na maioria das vezes, esses são os itens sobre os quais há maior
conhecimento, logo são mais detalhados e refinados. Itens que precisem de maior refinamento
geralmente têm uma importância menor e ficam mais abaixo. Não existe, no entanto, uma forma
única para materializar esse artefato e descrever seus itens.
Além das Histórias de Usuário, podem ser utilizadas descrições textuais de funcionalidades,
cenários de casos de uso, etc. Galera, o Product Backlog pode apresentar itens funcionais, não-
funcionais, arquiteturais ou de infraestrutura – além de itens que representem riscos a serem
removidos. É claro que, durante o andamento do projeto, algumas funcionalidades podem acabar
perdendo a importância – não importando sob que circunstâncias isso ocorreu.
Isso é totalmente normal na maioria dos projetos, uma

vez que é impossível saber, desde o início, os detalhes
de tudo o que queremos no produto. Assim, algumas
funcionalidades podem acabar até mesmo
desaparecendo. Da mesma forma, novas
funcionalidades também podem ser adicionadas de
acordo com a necessidade. Ao lado, temos um exemplo
de Product Backlog. É nele onde eu vou armazenar todas
as necessidades que eu desejo no meu projeto, entre
outras coisas. No exemplo acima, deseja-se poder tanto
tuitar quanto remover um tuite – são duas histórias de
usuário diferentes que eu desejo que sejam
implementadas na minha aplicação. Legal, mas quando
eu sei quando um desses itens pode realmente ser
considerado pronto (também chamado ready)?

43089971860 -1644786
Para que um item possa ser incluído em uma sprint, ele deve ser pequeno o suficiente para que caiba
em uma única sprint e deve deixar tudo claro e transparente quanto à expectativa do Product Owner
(geralmente através de um critério de aceite). Mas até que ponto estes requisitos precisam ser
detalhados? Eles devem ser detalhados até atender ao conceito de Definition of Ready (DoR). O
que é isso, Diego?
Isso significa que o requisito tem informações suficientes para começar a ser desenvolvido
imediatamente. Esta definição é bastante específica de cada organização – não há um padrão. Vou
dar um exemplo para melhor entendimento... eu já trabalhei em um projeto em que as histórias de
usuário eram entregues aos desenvolvedores de forma muito pobres, pouco refinadas e
demasiadamente confusas.
O Product Owner estava rejeitando a conclusão das sprints, declarando que não havia sido feito
o que ele havia pedido. Os desenvolvedores reclamavam que a especificação era péssima e que
==1918f2==
nem o próprio Product Owner sabia o que queria. A partir daí, modificamos nosso processo! A
equipe combinou critérios explícitos e visíveis do que uma história de usuário deveria conter para
ser aceita para entrar em uma sprint. Como diz o ditado, combinado não sai caro!
Dessa forma, uma vez que todos haviam concordado, as brigas reduziram bastante. Por que?
Porque eles nos disseram exatamente (por meio de um checklist) o que a história de usuário
deveria conter para que elas pudessem ser aceitas para entrar no Product Backlog e serem de
fato implementadas pelos desenvolvedores. A partir daí, essa definição de “pronto” nos ajudou a
mitigar falhas de comunicação.
O Backlog do Produto é uma lista ordenada de tudo que é conhecido ser necessário no produto. É a única origem dos
requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto,
incluindo seu conteúdo, disponibilidade e ordenação. 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. O Backlog do Produto lista
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. Os itens do Backlog do Produto possuem os atributos de descrição, ordem, estimativa e
valor. Os itens do Backlog geralmente incluem descrições de testes que comprovarão sua completude quando “Prontos”.
Enquanto um produto é usado e ganha valor, e o mercado fornece feedback, o Backlog do Produto torna-se uma lista
maior e mais completa. Requisitos nunca param de mudar, então o Backlog do Produto é um artefato vivo. Mudanças nos
requisitos de negócio, condições de mercado ou tecnologia podem causar mudanças no Backlog do Produto. Múltiplos
Times Scrum frequentemente trabalham juntos no mesmo produto. Um Backlog do Produto é usado para descrever o
trabalho previsto para o produto. Um atributo do Backlog do Produto que agrupe itens pode ser então aplicado.
O refinamento do Backlog do Produto é a ação de adicionar detalhes, estimativas e ordem aos itens no Backlog do
Produto. Este é um processo contínuo no qual o Product Owner e o Time de Desenvolvimento colaboram nos detalhes dos
itens do Backlog do Produto. Durante o refinamento do Backlog do Produto, os itens são inspecionados e revisados. O

43089971860 -1644786
Time de Scrum decide como e quando o refinamento está “Pronto”. Este refinamento usualmente não consome mais de
10% da capacidade do Time de Desenvolvimento.
Contudo, os itens do Backlog do Produto podem ser atualizados a qualquer momento pelo Product Owner ou a critério do
Product Owner. Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais
detalhados que os itens de ordem mais baixa. Estimativas mais precisas são feitas baseadas em maior clareza e maior
detalhamento; Quanto menor a ordem na lista, menos detalhes. Os itens do Backlog do Produto que irão ocupar o Time
de Desenvolvimento na próxima Sprint são mais refinados, de modo que todos os itens possam ser “Prontos” dentro do
time-boxed da Sprint.
Os itens do Backlog do Produto que podem ser “Prontos” pelo Time de Desenvolvimento dentro de uma Sprint são
considerados “Preparados” para seleção no Planejamento da Sprint. Itens do Backlog do Produto geralmente adquirem
este grau de transparência através das atividades de refinamento descritas acima. O Time de Desenvolvimento é
responsável por todas as estimativas. O Product Owner deve influenciar o Time de Desenvolvimento, ajudando no
entendimento e nas decisões conflituosas de troca, mas as pessoas que irão realizar o trabalho fazem a estimativa final.
Monitorando o Progresso a Caminho dos Objetivos
Em qualquer ponto do tempo, o total do trabalho restante para alcançar o objetivo pode ser somado. O Product Owner
acompanha o total do trabalho restante pelo menos a cada Revisão da Sprint. O Product Owner compara este valor com
o trabalho restante nas Revisões das Sprints anteriores, para avaliar o progresso na direção de completar o trabalho
previsto pelo tempo desejado para alcançar o objetivo.
Esta informação deve ser transparente para todas as partes interessadas. Várias práticas para prever tendências foram
usadas para prever o progresso, tais como burndowns, burn-ups, ou fluxos cumulativos. Estas têm se provado úteis.
Contudo, não substituem a importância do empirismo. Em ambientes complexos, o que acontecerá é desconhecido.
Somente o que já acorreu pode ser usado para uma tomada de decisão a respeito do que virá.
O Product Backlog é uma lista ordenada e emergente do que é necessário para melhorar o produto. É a única fonte de
trabalho realizado pelo Scrum Team. Os itens do Product Backlog que podem ser realizados pelo Scrum Team em uma
Sprint são considerados preparados para seleção no evento Sprint Planning. Eles geralmente adquirem esse grau de
transparência após as atividades de refinamento. O Product Backlog refinement é o ato de quebrar e incluir definição
adicional aos itens do Product Backlog para ter itens menores e mais precisos.
Esta é uma atividade contínua para adicionar detalhes, como descrição, ordem e tamanho. Os atributos geralmente
variam de acordo com o domínio de trabalho. Os Developers que farão o trabalho são responsáveis pelo
dimensionamento. O Product Owner pode influenciar os Developers, ajudando-os a entender e selecionar trade-offs
(trocas de itens).
Compromisso: Meta do Produto
A Meta do Produto descreve um estado futuro do produto que pode servir como um alvo para o Scrum Team planejar. A
Meta do produto está no Product Backlog. O restante do Product Backlog emerge para definir “o que” cumprirá a Meta
do Produto. Um produto é um veículo para entregar valor. Tem um limite claro, stakeholders conhecidos, usuários ou
clientes bem definidos. Um produto pode ser um serviço, um produto físico ou algo mais abstrato. A Meta do Produto é o
objetivo de longo prazo para o Scrum Team. Eles devem cumprir (ou abandonar) um objetivo antes de assumir o próximo.

43089971860 -1644786
(TRT7 – 2017) Assinale a opção que apresenta o termo no qual constam as solicitações
de melhorias e novas funcionalidades do software no método Scrum:
a) Sprint Backlog
b) Daily Scrum
c) Sprint Planning
d) Product Backlog
_______________________
Comentários: as solicitações de melhorias e novas funcionalidades ficam no Product Backlog (Letra D).
(CREA-AC – 2016) Uma equipe de desenvolvimento está utilizando o SCRUM como

modelo de desenvolvimento ágil. Nesse caso, o componente desse modelo que
representa a visão geral do produto, definindo o que deve ser feito, assim como suas
prioridades e a ordem em que deve ser realizado, é o:
a) evaluation screen.
b) given pillar.
c) product backlog.
d) sprint backlog.
e) users visions.
_______________________
Comentários: o componente que define o que deve ser feito, assim como ordem e prioridade é o Product Backlog (Letra C).
(TRT3 – 2015) Um técnico de TI está trabalhando em um projeto de desenvolvimento de

software que utiliza o modelo Scrum, em que as funcionalidades a serem
implementadas, na forma de histórias de usuários, são mantidas em uma lista
denominada:
a) product backlog.
b) sprint.
c) chaos list.
d) sprint burndown.
e) metaphor list.
_______________________
Comentários: as funcionalidades a serem implementadas, na forma de histórias de usuários, são mantidas em uma lista
ordenada chamada de Product Backlog (Letra A).

43089971860 -1644786
Sprint Backlog
Trata-se de conjunto de itens selecionados do Product Backlog, mais a meta da sprint

SPRINT BACKLOG e mais um plano de ação para entregar um incremento potencialmente usável – é
criado e gerenciado pelos desenvolvedores.
O Sprint Backlog é o conjunto de itens selecionados para serem implementados durante a sprint
mais o plano para transformá-los em um incremento. Assim, ao final de cada Reunião de
Planejamento, um novo Sprint Backlog é criado. Normalmente, o plano é composto por tarefas
técnicas necessárias para transformar o item em um incremento do produto. Vamos diferenciar
Product Backlog e Sprint Backlog? Essa é uma pegadinha comum em prova!
O primeiro é uma lista ordenada dos requisitos ou funcionalidades que o software deverá possuir.
O segundo é uma lista de tarefas a serem executadas durante uma sprint para atingir a sua
meta. Trata-se do desmembramento de cada item selecionado do Product Backlog em pequenas
tarefas. O Sprint Backlog torna visível todo o trabalho que os desenvolvedores identificam como
necessário para atingir a meta da sprint.
Aliás, os desenvolvedores (e somente eles) podem adicionar novas tarefas caso descubram, no
decorrer da sprint, que mais trabalho será necessário. Da mesma forma, também podem remover
tarefas caso estas se mostrem desnecessárias. Conforme o trabalho é realizado ou completado, a
estimativa do trabalho restante é atualizada. Em qualquer ponto do tempo na sprint, o total do
trabalho remanescente dos itens pode ser somado.
O Sprint Backlog é altamente visível, uma imagem em tempo

real do trabalho que os desenvolvedores planejam completar
durante a sprint, e pertence exclusivamente os desenvolvedores.
Eles monitoram o total do trabalho restante pelo menos a cada
Reunião Diária. Os desenvolvedores acompanham estes
resumos diários e projeta a probabilidade de alcançar o
objetivo da sprint. Com o rastreamento do trabalho restante em
toda a sprint, os desenvolvedores são capazes de gerenciar o seu
progresso.
Na Versão 2017, foi incluído um texto que reforça muito a importância da melhoria contínua ao
longo dos trabalhos do Time Scrum. Passa a ser declaradamente fundamental a inserção de pelo
menos um item priorizado referente a melhoria do processo identificado na última reunião de
retrospectiva. Essa alteração reforça explicitamente que o time deve trabalhar também na melhoria
contínua do próprio time, trabalho e processos. Esse trecho foi retirado na Versão 2020.
Vejam a seguir um exemplo de Backlog da Sprint. No exemplo, a meta da Sprint 2 é que usuários
possam estar no twitter. À esquerda, temos as funcionalidades do Backlog do Produto; e à direita,
temos as tarefas ou atividades técnicas e de negócio do Backlog da Sprint que devem ser

43089971860 -1644786
executadas para entregar as funcionalidades e efetivamente cumprir a meta da sprint definida na

reunião de planejamento.
O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano
para entregar o incremento do produto e atingir o objetivo da Sprint. O Backlog da Sprint é a previsão do Time de
Desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar
essa funcionalidade em um incremento “Pronto”. O Backlog da Sprint torna visível todo o trabalho que o Time de
Desenvolvimento identifica como necessário para atingir o objetivo da Sprint.
Para garantir melhoria contínua, é incluído no mínimo um item de prioridade alta sobre melhoria do processo identificado
na última Reunião de Retrospectiva. O Backlog da Sprint é um plano com detalhes suficientes que as mudanças no
progresso sejam entendidas durante a Reunião Diária. O Time de Desenvolvimento modifica o Backlog da Sprint ao longo
de toda a Sprint, e o Backlog da Sprint vai surgindo durante a Sprint. Este surgimento ocorre quando o Time de
Desenvolvimento trabalha segundo o plano e aprende mais sobre o trabalho necessário para atingir o objetivo da Sprint.
Sempre que um novo trabalho é necessário, o Time de Desenvolvimento adiciona este ao Backlog da Sprint. Conforme o
trabalho é realizado ou completado, a estimativa do trabalho restante é atualizada. Quando elementos do plano são
considerados desnecessários, eles são removidos. Somente o Time de Desenvolvimento pode alterar o Backlog da Sprint
durante a Sprint. O Backlog da Sprint é altamente visível, uma imagem em tempo real do trabalho que o Time de
Desenvolvimento planeja completar durante a Sprint, e que pertence exclusivamente ao Time de Desenvolvimento.
Monitorando o Progresso da Sprint
Em qualquer ponto do tempo na Sprint, o total do trabalho remanescente dos itens do Backlog da Sprint pode ser somado.
O Time de Desenvolvimento monitora o total do trabalho restante pelo menos a cada Reunião Diária para projetar a
probabilidade de alcançar o objetivo da Sprint. Ao acompanhar o trabalho restante ao longo de toda a Sprint, o Time de
Desenvolvimento pode gerenciar o seu progresso.

43089971860 -1644786
O Sprint Backlog é 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). O Sprint Backlog é um plano feito por e
para os Developers. É uma imagem altamente visível, em tempo real do trabalho que os Developers planejam realizar
durante a Sprint para atingir a Meta da Sprint. Consequentemente, o Sprint Backlog é atualizado ao longo da Sprint
conforme mais é aprendido. Deve ter detalhes suficientes para que eles possam inspecionar seu progresso na Daily Scrum.
Compromisso: Meta da Sprint
A Meta da Sprint é o único objetivo da Sprint. Embora a Meta da Sprint seja um compromisso dos Developers, esta fornece
flexibilidade em termos do trabalho exato necessário para alcançá-la. A Meta da Sprint também cria coerência e foco,
encorajando o Scrum Team a trabalhar junto ao invés de iniciativas separadas. A Meta da Sprint é criada durante o evento
Sprint Planning e então adicionada ao Sprint Backlog. Conforme os Developers trabalham durante a Sprint, eles mantêm
a Meta da Sprint em mente. Se o trabalho acabar sendo diferente do que eles esperavam, eles colaboram com o Product
Owner para negociar o escopo do Sprint Backlog dentro da Sprint sem afetar a Meta da Sprint.
(TRT-RS – 2015) No Scrum, a lista de funcionalidades a serem implementadas em cada

projeto que apresenta uma visão dos requisitos de forma mais voltada à maneira como
a equipe vai desenvolvê-los, e não em uma visão de alto nível voltada às necessidades
diretas do cliente, é conhecida como:
a) product backlog.
b) scrum backlog.
c) sprint backlog.
d) daily backlog.
e) daily sprint.
_______________________
Comentários: a questão fala que não se trata de uma lista de alto nível, logo se trata de uma lista mais detalhada. Dito isso,
estamos falando da Sprint Backlog. Lembrando que o Product Backlog apresenta uma lista de alto nível (pouco detalhada) e a
Sprint Backlog apresenta uma lista de baixo nível (muito detalhada) (Letra C).
(UFRJ – 2018) De acordo com o framework Scrum, o artefato descrito como uma lista
de tarefas que o Scrum Team se compromete a fazer em um Sprint é denominado:
a) Product Backlog.
b) Sprint Backlog.
c) Burndown chart.
d) User stories.
e) Tasks.
_______________________
Comentários: a lista de tarefas que a equipe se compromete a fazer em uma sprint é a Sprint Backlog. A minha única ressalva é
que o compromisso de fazer essa lista de tarefas é da Equipe de Desenvolvimento [Versão 2017] ou Desenvolvedores [Versão
2020] – não se trata de um compromisso do Scrum Team (Letra B).

43089971860 -1644786
Product Increment
Trata-se da é da soma de todos os itens do Backlog do Produto completados durante

Product increment a Sprint e o valor dos incrementos de todas as sprints anteriores – sendo validado como
“pronto”.
Ao final de cada sprint, os desenvolvedores entregam um incremento do produto – resultado

do que foi produzido ao final do trabalho realizado na sprint. Esse é um dos principais conceitos
do framework e vai ao encontro da sua natureza empírica, já que permite ao Product Owner
perceber o valor do investimento realizado e também vislumbrar outras possibilidades de novos
incrementos.
Para os desenvolvedores, é importante entender que o incremento deve ser algo potencialmente
entregável ou liberável. Por que potencialmente? Porque o cliente pode optar por disponibilizar de
imediato o incremento ou não. A equipe, portanto, deve produzir código que tenha qualidade –
e, então, chegamos à Definition of Done (DoD). O que seria isso, professor? Calma, eu vou
explicar...
Pronto significa pronto mesmo! Quando uma equipe ágil diz que uma funcionalidade está pronta,
significa que não tem aquele “veja bem…” ou “só falta uma coisinha, mas já está pronto…”. O DoD é
um acordo formal que define claramente quais são os passos mínimos para a conclusão de um
item ou funcionalidade potencialmente entregável. Trata-se de uma lista de verificação de
atividades necessárias para que um incremento seja considerado como completo.
Ele serve, mais ou menos, como um contrato entre os desenvolvedores e o Product Owner,
garantindo que todo produto gerado pelo projeto estará dentro dos padrões de qualidade
estabelecidos anteriormente. Vocês devem se lembrar que a Definition of Ready (DoR) é um
checklist de critérios acordados para que os desenvolvedores possam aceitar um requisito.
Entenderam direitinho?
Aqui acontece o contrário: trata-se de um checklist de critérios acordados para que o Product
Owner possa aceitar uma funcionalidade. Ambos tratam de critérios de aceite, mas o primeiro
trata dos critérios de aceite das histórias de usuário pelos desenvolvedores e o segundo trata dos

43089971860 -1644786
critérios de aceite das funcionalidades pelo Product Owner. Em suma: toda a Equipe Scrum deve
entender o que significa “pronto” para ambos os casos.
Uma funcionalidade só é considerada “pronta” se tiver passado por todas as etapas definidas
pelos desenvolvedores (Ex: codificado, passado por todos os testes unitários, passado pelos
testes de aceitação, entre outros). Uma funcionalidade que não esteja “pronta” ao final da sprint
deve retornar ao Product Backlog para que seja incluída em uma próxima sprint. Esse critério é
bastante específico, cada um escolhe o seu!
Por outro lado, é uma boa prática revisar essas definições de “pronto” a cada sprint porque elas
podem mudar ao longo do tempo. O amadurecimento organizacional e a habilidade da equipe
de resolver impedimentos podem fazer com que alguns itens sejam acrescentados com o passar
do tempo. Sempre lembrando que o Definition of Ready é opcional, já o Definition of Done é
obrigatório. Compreenderam?
Por fim, é interessante mencionar outros artefatos que não estão explícitos no guia como o Gráfico
Burndown, que torna visível a evolução diária do trabalho dos desenvolvedores, na medida em que
mostra a comparação de produtividade entre o trabalho estimado inicialmente com a quantidade
restante estimada de trabalho. Via de regra, as unidades utilizadas são de esforço (em horas)
planejado pelo tempo decorrido.

43089971860 -1644786
Esse gráfico ajuda os gestores a acompanharem o andamento da equipe em projetos, considerando

tempo, esforço e prazo de entrega.
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. Ao final da Sprint um novo incremento deve estar “Pronto”, o que significa que deve estar
na condição de ser utilizado e atender a definição de “Pronto” do Time Scrum. Um incremento é uma parte principal
inspecionável de trabalho pronto que suporta empirismo no final da sprint. O incremento é um passo na direção de uma
visão ou de um objetivo. O incremento deve estar na condição de ser utilizado independente do Product Owner decidir por
liberá-lo ou não.
Um incremento é um trampolim concreto em direção a Meta do produto. Cada incremento é adicionado a todos os
incrementos anteriores e completamente verificado, garantindo que todos os incrementos funcionem juntos. A fim de
fornecer valor, o incremento deve ser utilizável. Vários incrementos podem ser criados em uma Sprint. A soma dos
incrementos é apresentada na Sprint Review, apoiando assim o empirismo. No entanto, um incremento pode ser entregue
aos stakeholders antes do final da Sprint. A Sprint Review nunca deve ser considerada um marco para liberar valor. O
trabalho não pode ser considerado parte de um incremento a menos que atenda a Definição de Pronto.
Compromisso: Definição de Pronto
A Definição de Pronto é uma descrição formal do estado do Incremento quando ela atende às medidas de qualidade
exigidas para o produto. No momento em que um item do Product Backlog atende a Definição de Pronto, um incremento
nasce. A Definição de Pronto cria transparência ao fornecer a todos um entendimento compartilhado de qual trabalho foi
concluído como parte do Incremento. 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.
Se a Definição de Pronto para um incremento faz parte dos padrões da organização, todos os Scrum Teams devem segui-
la como mínimo. Se não for um padrão organizacional, o Scrum Team deve criar uma Definição de Pronto apropriada para
o produto. Os Developers devem estar em conformidade com a Definição de Pronto. Se houver vários
Scrum Teams trabalhando juntos em um produto, eles devem definir e cumprir mutuamente a mesma Definição de
Pronto.

43089971860 -1644786
Eventos
Vamos falar agora sobre os eventos – também chamados em questões de provas de reuniões ou
cerimônias! Vamos começar pelo contêiner que cobre todos os outros eventos: Sprint.
Pensem comigo: estou em um projeto cujo objetivo é criar uma página de e-commerce para uma
empresa de varejo. Eu tenho que realizar diversas tarefas para construir essa página, como por
exemplo criar uma funcionalidade que permita o pagamento via cartão de crédito e débito. Essa
funcionalidade pode ser (em conjunto com outras) a unidade de trabalho que satisfaz um
requisito de negócio, logo pode ser realizada em uma sprint.
O Scrum prega que, ao fim de cada sprint, deve-se entregar um incremento potencialmente
funcional do produto ao cliente. O que seria potencialmente funcional? É aquilo que tem potencial
de entrar ser utilizado pelo cliente em seu ambiente. As sprints têm duração de até um mês,
permitindo feedbacks constantes quanto ao que está sendo desenvolvido. Ela é como um contêiner
para todos os outros eventos e cerimônias que veremos à frente.
Eu sei que está um pouco abstrato, então vamos pensar em uma metáfora! Imagina que você
contrate um marceneiro para construir os armários do apê novo que você comprou logo após passar
em um concurso público. Há duas maneiras de fazer isso: se fôssemos utilizar um método
tradicional, ele perguntaria como você quer os armários, passaria alguns meses construindo e
algum dia montaria todos os armários na sua casa de uma só vez – sem interações com você.
No método ágil, nós vamos dividir esse projeto de construção dos armários em vários ciclos de
tempo fixo. Por exemplo: nós vamos combinar com o marceneiro que a cada quinze dias eu quero
que ele entregue um incremento dos armários já potencialmente funcional, ou seja, que você já
possa utilizar na sua casa. Nos primeiros quinze dias, ele deve entregar os armários do banheiro
prontinhos para você utilizar.

43089971860 -1644786
Nos próximos quinze dias, ele deve entregar os armários da área de serviço também prontos para
utilizar. Nos outros quinze, não será possível entregar todos os armários do quarto, mas ele
deve entregar pelo menos o guarda-roupa já pronto para você utilizar. Vocês conseguem notar
que a cada intervalo regular de quinze dias, você vai recebendo incrementos potencialmente
funcionais? Com o software é a mesma coisa...
Qual é a grande vantagem dessa segunda opção em relação à primeira? Bem, primeiro você não
morre de ansiedade de receber os móveis somente ao final; a segunda vantagem é que você pode
mudar de ideia no meio do caminho e pedir para ele mudar o projeto. Enfim, o que importa disso
tudo que eu disse? Importa que esses ciclos regulares de tempo fixo de desenvolvimento de um
incremento potencialmente funcional são conhecidos também como Sprint!
Bem, nós já sabemos que uma sprint dura um mês ou menos e se inicia imediatamente após a
conclusão da sprint anterior. Durante a sprint, é proibido realizar mudanças que coloquem em
risco os objetivos da própria sprint. Na nossa metáfora, se eu planejei que nessa sprint eu vou
construir os armários do banheiro utilizando madeira do tipo cedro, eu não posso no meio do
caminho alterar para madeira do tipo mogno porque isso coloca em risco os objetivos da sprint.
Colocaria em risco, Diego? Sim, porque essa mudança poderia inviabilizar a entrega do produto na
data acordada e a sprint poderia falhar! Além disso, é proibido mudar a composição da equipe ou
diminuir as metas de qualidade. Apesar disso, o escopo pode ser sempre clarificado, esclarecido e
renegociado entre o Product Owner e os desenvolvedores durante a própria execução da sprint em
andamento.
Aliás, nada impede que uma sprint seja cancelada antes de seu time-box terminar e isso somente
pode ser feito pelo Product Owner (sob influência de stakeholders, desenvolvedores, etc).
Professor, por que alguém faria esse cancelamento? A Sprint poderá ser cancelada se o objetivo da
Sprint se tornar obsoleto. Isto pode ocorrer se a organização mudar sua direção ou se as
condições de mercado tecnologias mudarem.
Geralmente, a Sprint deve ser cancelada se ela não faz mais sentido às dadas circunstâncias. No
entanto, devido a curta duração da Sprint, raramente cancelamentos fazem sentido. Se uma parte
do trabalho estiver potencialmente utilizável, tipicamente o Product Owner o aceita. Todos os itens
de Backlog do Produto incompletos são reestimados e colocados de volta no Backlog do Produto.
O trabalho feito se deprecia rapidamente e deve ser frequentemente reestimado.
O cancelamento de Sprints consome recursos, já que todos tem que se reagrupar em outra
reunião de planejamento da sprint para iniciar outra sprint. Cancelamentos de sprints são
frequentemente traumáticos para a Equipe Scrum, e são muito incomuns. Por falar em
planejamento da sprint, vamos falar agora sobre os eventos. Por que eu fiz essa pausa para falar um
pouco mais sobre as sprints?

43089971860 -1644786
Porque os quatro eventos que serão detalhados a seguir compõem uma sprint – além, é claro, do
próprio trabalho de desenvolvimento. Eventos Scrum são eventos time-boxed – o que significa
que eles possuem uma duração máxima predefinida. Eles são utilizados para criar uma rotina e
minimizar a necessidade de reuniões não definidas pelo Scrum. Esses eventos são: (1) Reunião de
Planejamento da Sprint; (2) Reunião Diária; (3) Revisão da Sprint; (4) Retrospectiva da Sprint.
Eventos prescritos são usados no Scrum para criar uma regularidade e minimizar a necessidade de reuniões não definidas
no Scrum. Todos os eventos são eventos time-boxed, de tal modo que todo evento tem uma duração máxima. Uma vez
que a Sprint começa, sua duração é fixada e não pode ser reduzida ou aumentada. Os eventos restantes podem terminar
sempre que o propósito do evento é alcançado, garantindo que uma quantidade adequada de tempo seja gasta não
permitindo desperdícios no processo.
Além da Sprint, que é um container para outros eventos, cada evento no Scrum é uma oportunidade de inspecionar e
adaptar alguma coisa. Estes eventos são especificamente projetados para permitir uma transparência e inspeção
criteriosa. Falhas na inclusão de qualquer um destes eventos resultará na redução da transparência e na perda de
oportunidades para inspecionar e adaptar.
O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um “Pronto”, incremento de produto
potencialmente liberável é criado. Sprints tem durações consistentes ao longo de todo o esforço de desenvolvimento. Uma
nova Sprint inicia imediatamente após a conclusão da Sprint anterior. As Sprints contêm e consistem de um planejamento
da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e uma retrospectiva da Sprint. Durante
a Sprint:
• Não são feitas mudanças que possam por em perigo o objetivo da Sprint;
• As metas de qualidade não diminuem; e,
• O escopo pode ser clarificado e renegociado entre o Product Owner e o Time de Desenvolvimento quanto mais for
aprendido.
Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês. Como os projetos, as Sprints são
utilizadas para realizar algo. Cada Sprint tem uma meta do que é para ser construído, um plano previsto e flexível que irá
guiar a construção, o trabalho e o produto resultante do incremento. Sprints são limitadas a um mês corrido. Quando o
horizonte da Sprint é muito longo, a definição do que será construído pode mudar, a complexidade pode aumentar e o
risco pode crescer. Sprints permitem previsibilidade que garante a inspeção e adaptação do progresso em direção à meta
pelo menos a cada mês corrido. Sprints também limitam o risco ao custo de um mês corrido.
Uma Sprint pode ser cancelada antes do time-boxed da Sprint terminar. Somente o Product Owner tem a autoridade para
cancelar a Sprint, embora ele (ou ela) possa fazer isso sob influência das partes interessadas, do Time de Desenvolvimento
ou do Scrum Master. A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto. Isto pode ocorrer se a
organização mudar sua direção ou se as condições do mercado ou das tecnologias mudarem. Geralmente a Sprint deve
ser cancelada se ela não faz mais sentido às dadas circunstâncias.
No entanto, devido a curta duração da Sprint, raramente cancelamentos fazem sentido. Quando a Sprint é cancelada,
qualquer item de Backlog do Produto completado e “Pronto” é revisado. Se uma parte do trabalho estiver potencialmente
liberável, tipicamente o Product Owner o aceita. Todos os itens de Backlog do Produto incompletos são reestimados e
colocados de volta no Backlog do Produto. O trabalho feito se deprecia rapidamente e deve ser frequentemente
reestimado.

43089971860 -1644786
O cancelamento de Sprints consome recursos, já que todos se reagrupam em outro planejamento da Sprint para iniciar
outra Sprint. Cancelamentos de Sprints são frequentemente traumáticos para o Time Scrum, e são muito incomuns.
A Sprint é um contêiner para todos os outros eventos. Cada evento no Scrum é uma oportunidade formal para inspecionar
e adaptar os artefatos do Scrum. Esses eventos são projetados especificamente para permitir a transparência necessária.
A falha em operar quaisquer eventos conforme prescrito resulta em oportunidades perdidas de inspeção e adaptação. Os
eventos são usados no Scrum para criar regularidade e minimizar a necessidade de reuniões não definidas no Scrum. O
ideal é que todos os eventos sejam realizados no mesmo horário e local para reduzir a complexidade.
Sprints são o coração do Scrum, onde ideias são transformadas em valor. São eventos de duração fixa de um mês ou
menos para criar consistência. Uma nova Sprint começa imediatamente após a conclusão da Sprint anterior. Todo o
trabalho necessário para atingir a meta do Produto, incluindo Sprint Planning, Daily Scrums, Sprint Review e Sprint
Retrospective, acontece dentro de Sprints. Durante a Sprint:
• Nenhuma mudança é feita que coloque em risco a meta da Sprint;

• A qualidade não diminui;
• O Product Backlog é refinado conforme necessário; e,
• O escopo pode ser esclarecido e renegociado com o Product Owner conforme mais é aprendido.
Sprints permitem previsibilidade, garantindo a inspeção e adaptação do progresso em direção a uma meta do Produto ao
menos uma vez por mês. Quando o horizonte de uma Sprint é muito longo, a meta da Sprint pode se tornar inválida, a
complexidade pode aumentar e o risco pode aumentar. Sprints mais curtas podem ser empregados para gerar mais ciclos
de aprendizagem e limitar os riscos de custo e esforço a um período de tempo menor. Cada Sprint pode ser considerado
um projeto curto.
Existem várias práticas para prever o progresso, como burn-downs, burn-ups ou cumulative flows. Embora
comprovadamente úteis, eles não substituem a importância do empirismo. Em ambientes complexos, o que acontecerá é
desconhecido. Somente o que já aconteceu pode ser usado para a tomada de decisão voltada para o futuro. Uma Sprint
pode ser cancelada se a Meta da Sprint se tornar obsoleta. Apenas o Product Owner tem autoridade para cancelar a
Sprint.
(UNIR – 2018) Os Eventos com Duração Fixa chamados Time-Boxes no Scrum são
compostos por: a reunião de planejamento da versão para entrega, a Sprint, a reunião
de planejamento da Sprint, a revisão da Sprint, a retrospectiva da Sprint e a reunião
diária.
_______________________
Comentários: a questão está correta, mas eu enfatizaria que time-boxes são tempos de duração máxima fixa (Correto).

43089971860 -1644786
Sprint Planning
O trabalho a ser realizado na Sprint é planejado na Reunião de Planejamento da Sprint. Este

planejamento é criado com o trabalho colaborativo de toda a Equipe Scrum. Ela possui um time-
box com no máximo oito horas para uma sprint de um mês de duração – para sprints menores, a
duração é menor. O Scrum Master garante que o evento ocorra e que os participantes entendam
seu propósito. Ela consiste em duas partes e devem responder adequadamente as perguntas:
1. O que será entregue como resultado do incremento da próxima Sprint?
2. Como o trabalho necessário para entregar o incremento será realizado?
Na primeira parte, os desenvolvedores tentam prever as funcionalidades que serão

desenvolvidas durante a sprint. O Product Owner apresenta as histórias de usuário mais
priorizados do Product Backlog aos desenvolvedores. Como ele faz isso? Em geral, ele dá um valor
de negócio para cada item do backlog, organizando-os em forma decrescente de valor de negócio.
Como assim, professor?
Imaginem que exista um item que o Product Owner deseja muito que seja implementado – ele pode
dizer que esse item tem o valor de negócio de 1000. Agora imagine que exista outro item no Product
Backlog que o Product Owner não liga tanto – ele dá um valor de negócio de 10. Dessa forma, o
Product Owner consegue ordenar os itens de acordo com o valor de negócio. Feito isso, é hora
de estimar o esforço de desenvolvimento de cada item do backlog.
Quando nós utilizamos histórias de usuário, é comum utilizarmos uma outra unidade de medida
para medir esforço, em vez do tempo – utilizado frequentemente em metodologias tradicionais.
No caso de Histórias de Usuário (User Stories), nós utilizamos Pontos de História (Story Points).
Trata-se de uma unidade de medida relativa que leva em consideração o esforço1 necessário
para realizar uma determinada funcionalidade.
Se uma funcionalidade requerer o dobro de esforço para ser implementada, ela receberá
aproximadamente o dobro de Story Points. Para fazer essa estimativa, os desenvolvedores
realizam uma comparação com outras histórias já estimadas. Caso não haja ainda nada estimado
no Product Backlog, a equipe localiza a história de usuário com o menor esforço para
desenvolvimento e o utiliza como base de comparação.
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
1
Há uma polêmica danada: alguns afirmam que ela estima complexidade e, não, esforço; outros dizem que é uma combinação de complexidade,
esforço, risco, etc.

43089971860 -1644786
estimar esforço como para estimar tamanho. Essa técnica combina a opinião de experts, analogia
e desagregação em uma abordagem divertida na estimação de Histórias de Usuário, e elimina a
influência que um desenvolvedor possa exercer sobre outros.
Feita a estimativa de cada história de usuário, os desenvolvedores decidirão a quantidade de itens

do backlog a serem realizados na sprint. Galera, vamos detalhar isso um pouco mais! Story Points
é uma unidade de medida relativa que leva em consideração o esforço necessário para realizar
uma determinada funcionalidade. Se uma funcionalidade requerer o dobro de esforço para ser
implementada, ela receberá aproximadamente o dobro de Story Points.
Para estimar a quantidade de Story Points de uma User Story, os desenvolvedores os comparam
com outros já estimados. Caso não haja ainda nada estimado no Product Backlog, os
desenvolvedores localizam o User Story com o menor esforço para o desenvolvimento, e o utiliza
como base para comparações futuras. Uma das melhores formas de se estimar Story Points é
utilizando o Planning Poker.
Isso porque ele combina a opinião de experts, analogia e desagregação em uma abordagem
divertida na estimativa de itens ou User Stories e elimina a influência que um membro dos
desenvolvedores possa exercer sobre os outros. Vamos entender um pouco melhor como ele
funciona? 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 (Ex: 0, 1, 2, 3, 5, 8, 13, 20, 40, e 100).
Em geral, os valores seguem uma escala baseada na Sequência de Fibonacci. Observem: outra
sequência pode ser escolhida, porém Fibonacci é a mais utilizada. Para cada User Story a ser
estimativa, o Product Owner lê a descrição e esclarece quaisquer dúvidas que os membros do time
tenham. Entretanto, é importante lembrar que em determinado ponto, qualquer discussão
adicional não busca uma precisão maior.
Após todas as questões serem respondidas, cada membro seleciona uma carta representando sua
estimativa, mas sem mostrar aos outros. As cartas não são mostradas até o momento em que
todos, simultaneamente, exibem seus valores, de forma que todos vejam os valores selecionados
simultaneamente. Neste ponto, é normal que as estimativas sejam significativamente diferentes.
E na realidade é um bom sinal.
Quando as estimativas diferem, os membros expõem os motivos que os levaram a escolher

aqueles valores.Depois das explanações e discussões, todos recolhem suas cartas e estimam
novamente da mesma forma. O Planning Poker funciona porque utiliza a opinião de diversos
experts na estimativa. Como estes experts compõem um time multidisciplinar, eles são os mais
indicados para estimar as histórias do que qualquer outra pessoa.
Além disso, os diálogos e justificativas permitem uma maior acuracidade das estimativas,
especialmente nos itens com maior incerteza. E isto é de extrema importância em um projeto que
tenha um certo nível de complexidade. Finalmente, estudos mostram que a média de estimativas
individuais levam a melhores resultados, uma vez que promovem discussões em grupo.

43089971860 -1644786
Estas discussões em grupo são a base do Planning Poker e elas conduzem a um consenso entre os
indivíduos participantes. Mais uma vez: Fibonacci é a escala mais utilizada na estimativa de User
Story por Planning Poker. Isso se deve ao fato de a Sequência de Fibonacci ser uma função
quadrática, em vez de uma função linear. Detalhe: algumas vezes as histórias de usuário são muito
grandes para serem desenvolvidas em uma sprint – são chamadas de Épicos.
Elas precisarão ser quebradas em partes menores. Mais que isso, em alguns projetos é necessário
um nível ainda maior que um épico – chamado de Saga – para features geralmente mais complexas.
Foram selecionados os itens? Ok! Agora a Equipe Scrum definirá uma meta para a sprint que será o
guia para os desenvolvedores sobre o que estará sendo desenvolvido durante a Sprint.
Na segunda parte, os desenvolvedores decidem como irá transformar os itens selecionados em

um incremento durante a Sprint e desenvolve o Sprint Backlog. Por falar nisso... qual a diferença
entre Product e Sprint Backlog mesmo? O primeiro é uma lista de todos os
requisitos/funcionalidades de usuário levantados até o momento e mantidas pelo Product Owner,
que pode alterá-las a qualquer momento.
O segundo é um subconjunto do primeiro transformado em uma lista de tarefas técnicas e

mantidas pelos desenvolvedores, que pode alterá-las a qualquer momento. Bem, ao final do
planejamento da Sprint, os desenvolvedores devem ser capazes de explicar ao Product Owner e ao
Scrum Master como pretende trabalhar como equipe auto-organizada para completar o objetivo da
Sprint e criar o incremento previsto.
Com o Sprint Backlog criado, define-se a meta da sprint! O que seria isso, Diego? Galera, a meta
nada mais é que um objetivo definido para ser satisfeito ao final da sprint. O Product Owner pode
estar presente durante a segunda parte da reunião para clarificar itens do Backlog do Produto.
Vocês se lembram que essa é uma das principais responsabilidades desse papel, certo? Pois é... vamos
para o nosso próximo evento...
O trabalho a ser realizado na Sprint é planejado durante o planejamento da Sprint. Este plano é criado com o trabalho
colaborativo de todo o Time Scrum. O Planejamento da Sprint é um um time-boxed com no máximo oito horas para uma
Sprint de um mês de duração. Para Sprints menores, este evento é usualmente menor. O Scrum Master garante que o
evento ocorra e que os participantes entendam seu propósito. O Scrum Master ensina o Time Scrum a manter-se dentro
dos limites do time-box. O planejamento da Sprint responde as seguintes questões:
• O que pode ser entregue como resultado do incremento da próxima Sprint?

• Como o trabalho necessário para entregar o incremento será realizado?
Tópico Um: O que pode ser Pronto nesta Sprint?
O Time de Desenvolvimento trabalha para prever as funcionalidades que serão desenvolvidas durante a Sprint. O Product
Owner debate o objetivo que a Sprint deve realizar e os itens de Backlog do Produto que, se completados na Sprint,
atingirão o objetivo da Sprint. Todo o Time Scrum colabora com o entendimento do trabalho da Sprint. A entrada desta

43089971860 -1644786
reunião é o Backlog do Produto, o mais recente incremento do produto, a capacidade projetada do Time de
Desenvolvimento durante a Sprint e o desempenho passado do Time de Desenvolvimento.
O número de itens selecionados do Backlog do Produto para a Sprint é o único trabalho do Time de Desenvolvimento.
Somente o Time de Desenvolvimento pode avaliar o que pode ser completado ao longo da próxima Sprint. Durante o
Planejamento da Sprint, o Time Scrum também determina a meta da Sprint. A meta da Sprint é o objetivo que será
satisfeito dentro da Sprint através da implementação do Backlog do Produto, e que fornece a orientação para o Time de
Desenvolvimento sobre o porquê dele estar construindo o incremento.
Tópico Dois: Como o trabalho escolhido será Pronto?
Tendo definido o objetivo da Sprint e selecionado os itens de Backlog do Produto da Sprint, o Time de Desenvolvimento
decide como irá construir essas funcionalidades durante a Sprint e transformá-las em um incremento de produto “Pronto”.
Os itens de Backlog do Produto selecionados para a Sprint, junto com o plano de entrega destes itens é chamado de
Backlog da Sprint. O Time de Desenvolvimento frequentemente inicia o desenho do sistema e do trabalho
necessário para converter o Backlog do Produto em um incremento funcional do produto.
O trabalho pode ser de vários tamanhos ou esforços. Contudo, o trabalho suficiente é planejado durante o planejamento
da Sprint pelo Time de Desenvolvimento para prever o que este acredita que poderá fazer durante a próxima Sprint. O
trabalho planejado pelo Time de Desenvolvimento para os primeiros dias da Sprint é decomposto até o final desta reunião,
frequentemente em unidades de um dia de duração ou menos. O Time de Desenvolvimento se auto-organiza para realizar
todo o trabalho do Backlog da Sprint, tanto durante o planejamento da Sprint quanto no que for necessário durante a
Sprint.
O Product Owner pode ajudar a clarificar os itens de Backlog do Produto selecionados e nas decisões conflituosas de troca.
Se o Time de Desenvolvimento determina que tem excesso ou falta de trabalho, os itens do Backlog da Sprint podem ser
renegociados com o Product Owner. O Time de Desenvolvimento também pode convidar outras pessoas para participar
desta reunião para fornecer opinião técnica ou de domínios específicos. No final do planejamento da Sprint, o Time de
Desenvolvimento deve ser capaz de explicar ao Product Owner e ao Scrum Master como pretende trabalhar como equipe
auto-organizada para completar o objetivo da Sprint e criar o incremento previsto.
Meta da Sprint
A meta da Sprint é um objetivo definido para a Sprint que pode ser satisfeito através da implementação do Backlog do
Produto. Este fornece uma direção para o Time de Desenvolvimento sobre o porquê de estar construindo o incremento.
Este é criado durante a reunião de planejamento da Sprint. O objetivo da Sprint dá ao Time de Desenvolvimento alguma
flexibilidade a respeito da funcionalidade que será completada dentro da Sprint. Os itens do Backlog do Produto
selecionados entregam uma função coerente, que pode ser o objetivo da Sprint.
O objetivo da Sprint pode ser qualquer outro coerente que faça o Time de Desenvolvimento trabalhar em conjunto em vez
de em iniciativas separadas. Conforme o Time de Desenvolvimento trabalha, eles mantêm o objetivo da Sprint em mente.
A fim de satisfazer o objetivo da Sprint, implementando funcionalidade e tecnologia. Caso o trabalho acabe por ser
diferente do esperado pelo Time de Desenvolvimento, então eles colaboram com o Product Owner para negociar o escopo
do Backlog da Sprint dentro da Sprint.
A Sprint Planning inicia a Sprint ao definir o trabalho a ser realizado na Sprint. Este plano resultante é criado pelo trabalho
colaborativo de todo o Scrum Team. O Product Owner garante que os participantes estejam preparados para discutir os
itens mais importantes do Product Backlog e como eles são mapeados para a Meta do Produto. O Scrum
Team também pode convidar outras pessoas para participar da Sprint Planning para fornecer conselhos.

43089971860 -1644786
A Sprint Planning aborda os seguintes tópicos:
Tópico um: Por que esta Sprint é valiosa?
O Product Owner propõe como o produto pode aumentar seu valor e utilidade na Sprint atual. Todo o Scrum Team então
colabora para definir uma Meta da Sprint que comunica porque a Sprint é valiosa para os stakeholders. A meta da Sprint
deve ser finalizada antes do final da Sprint Planning.
Tópico dois: O que pode ser feito nesta Sprint?
Por meio de discussão com o Product Owner, os Developers selecionam itens do Product Backlog para incluir na Sprint
atual. O Scrum Team pode refinar esses itens durante este processo, o que aumenta a compreensão e a confiança.
Selecionar o quanto pode ser concluído em uma Sprint pode ser um desafio. No entanto, quanto mais os Developers sabem
sobre seu desempenho anterior, sua capacidade futura e sua Definição de Pronto, mais confiantes eles estarão em suas
previsões quanto a Sprint.
Tópico três: Como o trabalho escolhido será realizado?
Para cada item do Product Backlog selecionado, os Developers planejam o trabalho necessário para criar um Incremento
que atenda à Definição de Pronto. Isso geralmente é feito decompondo itens do Product Backlog em itens de trabalho
menores de um dia ou menos. A forma como isso é feito fica a critério exclusivo dos Developers . Ninguém mais diz a eles
como transformar itens do Product Backlog em incrementos de valor. A Meta da Sprint, os itens do Product Backlog
selecionados para a Sprint, mais o plano para entregá-los são chamados juntos de Sprint Backlog.
A Sprint Planning tem um Timebox definido com duração máxima de de oito horas para uma Sprint de um mês. Para
Sprints mais curtas, o evento geralmente é mais curto.
(TRE-BA – 2017) A reunião de planejamento da sprint do Scrum é o evento em que:
a) é definida a equipe scrum e são cancelados os itens da sprint anterior que não tenham
sido entregues e os que tenham sido entregues, mas tenham sido rejeitados pelo
usuário.
b) são escritas as histórias dos usuários por meio do planning poker.
c) é definida a meta da sprint e são selecionados os itens do product backlog que

comporão a sprint.
d) é decidido pelo PO (product owner) se haverá o cancelamento ou não da sprint em

curso.
e) participam exclusivamente o PO (product owner) e o SM (scrum master), que, por

meio do planning poker, priorizaram os itens do backlog.
_______________________
Comentários: (a) Errado, a equipe é definida antes e não se cancela nada; (b) Errado, planning poker é uma técnica de estimativa
de esforço; (c) Correto; (d) Errado, se ainda está no planejamento, a sprint não está em curso; (e) Errado, os desenvolvedores
também participam da reunião de planejamento (Letra C).

43089971860 -1644786
Daily Scrum
A Reunião Diária (15 minutos) é um evento que busca criar um plano para as próximas 24 horas
e inspecionar o trabalho desde a última Reunião Diária. É realizada em todos os dias da sprint e
é o evento em que os desenvolvedores planejam 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.
A Reunião Diária é mantida no mesmo horário e local todo dia para reduzir a complexidade e não
deve ocorrer necessariamente em pé. A Reunião Diária aumenta a probabilidade dos
desenvolvedores atingirem o objetivo da Sprint. Todos os dias, os desenvolvedores devem
entender como o mesmo pretende trabalhar em conjunto, como um time auto-organizado, para
completar o objetivo da Sprint e criar o incremento previsto até o final da Sprint.
A estrutura da reunião é definida pelos desenvolvedores e pode ser conduzida de diferentes

formas desde que estas se foquem no progresso em direção à meta da sprint. Alguns Times de
Desenvolvimento utilizarão perguntas, outros se basearão em discussões – no meu caso pessoal,
nós utilizávamos ambos: perguntas e discussões. Bem, aqui segue um exemplo do que pode ser
utilizado:
1. O que eu fiz ontem que ajudou o os desenvolvedores a atenderem a meta da Sprint?
2. O que eu farei hoje para ajudar os desenvolvedores atenderem a meta da Sprint?
3. Eu vejo algum obstáculo que impeça a mim ou aos desenvolvedores no atendimento da meta da Sprint?
As Reuniões Diárias melhoram a comunicação entre os integrantes, eliminam a necessidade de

outras reuniões, identificam e removem impedimentos, destacam e promovem rápidas tomadas
de decisão, e melhoram o nível de conhecimento da Equipe. Apesar de poder contar com a presença
de outras partes interessadas, essa é uma reunião feito pelos desenvolvedores para os próprios
desenvolvedores.
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. A Reunião Diária é mantida no mesmo horário e local todo dia para reduzir a
complexidade.

43089971860 -1644786
O Time de Desenvolvimento usa a Reunião Diária para inspecionar o progresso em direção ao objetivo da Sprint e para
inspecionar se o progresso tende na direção de completar o trabalho do Backlog da Sprint. A Reunião Diária aumenta a
probabilidade do Time de Desenvolvimento atingir o objetivo da Sprint. Todos os dias, o Time de Desenvolvimento deve
entender como o mesmo pretende trabalhar em conjunto, como um time auto-organizado, para completar o objetivo da
Sprint e criar o incremento previsto até o final da Sprint.
A estrutura da reunião é definida pelo Time de Desenvolvimento e pode ser conduzida de diferentes formas desde que
estas foquem no progresso em direção à Meta da Sprint. Alguns Times de Desenvolvimento utilizarão perguntas, outros
se basearão em discussões. Aqui segue um exemplo do que pode ser utilizado:
• O que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir a meta da Sprint?
• O que eu farei hoje para ajudar o Time de Desenvolvimento atingir a meta da Sprint?
• Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atingimento da meta da Sprint?
O Time de Desenvolvimento ou membros da equipe frequentemente se encontram imediatamente após a Reunião Diária
para discussões detalhadas, ou para adaptar, ou replanejar, o restante do trabalho da Sprint.O Scrum Master assegura
que o Time de Desenvolvimento tenha a reunião, mas o Time de Desenvolvimento é responsável por conduzir a Reunião
Diária. O Scrum Master ensina o Time de Desenvolvimento a manter a Reunião Diária dentro do time-box de 15 minutos.
A Reunião Diária é uma reunião interna do Time de Desenvolvimento. Se outros estiverem presentes, o Scrum Master
deve garantir que eles não perturbem a reunião. Reuniões Diárias melhoram as comunicações, eliminam outras reuniões,
identificam e removem impedimentos para o desenvolvimento, destacam e promovem rápidas tomadas de
decisão, e melhoram o nível de conhecimento do Time de Desenvolvimento. Esta é uma reunião chave para inspeção e
adaptação.
O propósito da Daily Scrum é inspecionar o progresso em direção a Meta da Sprint e adaptar o Sprint Backlog conforme
necessário, ajustando o próximo trabalho planejado. A Daily Scrum é um evento de 15 minutos para os Developers do
Scrum Team. Para reduzir a complexidade, é realizado no mesmo horário e local, todos os dias úteis da Sprint. Se o
Product Owner ou o Scrum Master estão trabalhando ativamente nos itens do Sprint Backlog, eles participam como
Developers.
Os Developers podem selecionar qualquer estrutura e técnicas que quiserem, desde que seu Daily Scrum se concentre no
progresso em direção a Meta da Sprint e produza um plano de ação para o próximo dia de trabalho. Isso cria foco e melhora
o autogerenciamento. As Daily Scrums melhoram as comunicações, identificam os impedimentos, promovem a rápida
tomada de decisões e consequentemente, eliminam a necessidade de outras reuniões. A Daily Scrum não é o único
momento em que os Developers podem ajustar seu plano. Eles costumam se reunir ao longo do dia para discussões mais
detalhadas sobre a adaptação ou replanejamento do resto do trabalho da Sprint.
(EBSERH – 2017) As reuniões diárias estabelecidas pelos autores do SCRUM (Jef

Sutherland e Ken Schwaber) faz com que o Scrum Master oriente o Time de
Desenvolvimento a manter a Reunião Diária dentro do time-box constante de:
a) 15 minutos b) 1 hora c) 30 minutos d) 2 horas e) 45 minutos

_______________________
Comentários: o time-box da reunião diária é de 15 minutos (Letra A).

43089971860 -1644786
Sprint Review
No final da sprint, ocorre a Revisão da Sprint (Proporcional a 4 horas). Embora seja utilizada para
demonstrar as novas funcionalidades desenvolvidas durante a sprint, seu principal motivo é o de
inspecionar o que os desenvolvedores produziram e colher opiniões e impressões dos presentes
para, caso seja necessário, adaptar o plano para a sprint seguinte. O foco aqui é aprimorar o
produto!
Vocês se lembram do filme O Gladiador? Pois é! A Revisão da Sprint é o momento em que o Product
Owner valida () ou não () a sprint, de acordo com a meta que tenha sido acordada com os
desenvolvedores durante a reunião de planejamento da sprint. Discute-se os problemas e as
soluções e, após a demonstração do incremento, respondem-se quaisquer dúvidas dos
presentes.
A Revisão da Sprint é realizada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se
necessário. Durante a Revisão da Sprint o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint.
Com base nisso e em qualquer mudança no Backlog do Produto durante a Sprint, os participantes colaboram nas próximas
coisas que podem ser feitas para otimizar valor. Esta é 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.
Esta é uma reunião de no máximo 4 horas de duração para uma Sprint de um mês. Para Sprints menores, este evento é
usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam o seu propósito. O
Scrum Master ensina todos os envolvidos a manter a reunião dentro do Time-box. A Revisão da Sprint inclui os seguintes
elementos:
• Os participantes incluem o Time Scrum e os Stakeholders chaves convidados pelo Product Owner;
• O Product Owner esclarece quais itens do Backlog do Produto foram “Prontos” e quais não foram “Prontos”;
• O Time de Desenvolvimento discute o que foi bem durante a Sprint, quais problemas ocorreram dentro da Sprint, e como
estes problemas foram resolvidos;
• O Time de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as questões sobre o incremento;

43089971860 -1644786
• O Product Owner discute o Backlog do Produto tal como está. Ele (ou ela) projeta os prováveis alvos e datas de entrega
baseado no progresso até a data (se necessário);
• O grupo todo colabora sobre o que fazer a seguir, e é assim que a Revisão da Sprint fornece valiosas entradas para o
Planejamento da Sprint subsequente;
• Revisão de como o mercado ou o uso potencial do produto pode ter mudado e o que é a coisa mais importante a se fazer
a seguir; e,
• Revisão da linha do tempo, orçamento, potenciais capacidades, e mercado para a próxima versão esperada de
funcionalidade ou de capacidade do produto.
O resultado da Revisão da Sprint é um Backlog do Produto revisado que define os prováveis Itens de Backlog do Produto
para a próxima Sprint. O Backlog do Produto pode também ser ajustado completamente para atender novas
oportunidades.
O propósito da Sprint Review é inspecionar o resultado da Sprint e determinar as adaptações futuras. O Scrum Team
apresenta os resultados de seu trabalho para os principais stakeholders e o progresso em direção a Meta do Produto é
discutido. Durante o evento, o Scrum Team e os stakeholders revisam o que foi realizado na Sprint e o que mudou em seu
ambiente. Com base nessas informações, os participantes colaboram sobre o que fazer a seguir. O Product Backlog
também pode ser ajustado para atender a novas oportunidades.
A Sprint Review é uma sessão de trabalho e o Scrum Team deve evitar limitá-la a uma apresentação. A Sprint Review é o
penúltimo evento da Sprint e tem um Timebox com prazo máximo de quatro horas para uma Sprint de um mês. Para
Sprints mais curtas, o evento geralmente é mais curto.
(TRE-SP – 2017) Considere, por hipótese, que uma equipe de Analistas do TRE-SP
participou de uma reunião de um projeto baseado no Scrum e, ao final, o Backlog do
Produto foi revisto e completamente ajustado para atender às novas necessidades de
verificação de contribuições para campanhas de candidatos, advindas de pessoas físicas
sob suspeita de corrupção. Os Analistas participaram da reunião:
a) de Revisão da Sprint.
b) de Retrospectiva da Sprint.
c) diária.
d) de Verificação da Sprint.
e) de Planejamento da Sprint.
_______________________
Comentários: a questão trata da revisão da sprint, que é executada no final para inspecionar o incremento e adaptar o Backlog
do Produto, se necessário (Letra A).

43089971860 -1644786
Sprint Retrospective
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.
O Scrum Master garante que o evento seja positivo e produtivo. O Scrum Master ensina todos
a manter o evento dentro do time-box. O Scrum Master participa da reunião como um membro
auxiliar do time devido a sua responsabilidade pelo processo Scrum. O Scrum Master encoraja o
Time Scrum a melhorar, dentro do processo do framework do Scrum, seu processo de
desenvolvimento e suas práticas para torná-lo mais efetivo e agradável para a próxima Sprint.
Durante cada Retrospectiva da Sprint, o Time Scrum planeja formas de aumentar a qualidade do
produto melhorando o processo de trabalho ou adaptando a definição de “Pronto”, se apropriado
e sem entrar em conflito com os padrões do produto ou organização. Ao final da Retrospectiva da
Sprint, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima
Sprint.
A implementação destas melhorias na próxima Sprint é a forma de adaptação à inspeção que o

Time Scrum faz a si próprio. Apesar de que melhorias podem ser implementadas a qualquer
momento, a Retrospectiva da Sprint fornece uma oportunidade formal focada em inspeção e
adaptação. Fechou? Antes disso, vamos falar de um evento não-oficial, mas que geralmente é
realizado: Reunião de Visão! O que é isso, professor?
Trata-se do momento que visa estabelecer um ponto no processo em que o Product Owner deve
expor os detalhes do produto a ser construído. A saída dessa reunião deve ser uma visão sobre o
produto, isto é, representa como os clientes, usuários finais, gerentes, stakeholders,
executivos, entre outros, visualizam o resultado final do produto que será criado. Para tal, pode-
se utilizar diversas técnicas como: Product Vision Box, Product RoadMap ou Elevator Pitch Sentence.
Vamos ver um pouco dessa última técnica! Geoffrey Moore, no seu livro Crossing the Chasm,
apresenta um modelo interessante para a Visão do Produto, o chamado “Teste do Elevador”. A
ideia é que seja possível explicar o que é o produto durante a subida de um elevador, ou seja,
em um tempo bastante curto. Adaptado por Jim Highsmith, esse modelo tem o formato
apresentado na imagem da página seguinte.
Um exemplo de visão sobre um produto de turismo poderia ser: “Para turistas usuários de
smartphone que desejam aproveitar melhor seus locais de destino, o MyTrip é um aplicativo móvel de
viagens que sugere roteiros diários flexíveis de acordo com seu perfil de viajante. Ao contrário de guias
de viagens com roteiros predefinidos e burocráticos, nosso produto elabora trajetos personalizados e
adaptáveis”.

43089971860 -1644786
==1918f2==
Lembremos que a visão do produto, de forma geral, deve permanecer estável durante todo o
projeto. Ela é criada, gerenciada e compartilhada pelo Product Owner, que garante que o Product
Backlog esteja sempre alinhado a ela. No entanto, as partes interessadas relevantes podem estar
diretamente envolvidas no refinamento dessa visão. Há outra cerimônia não-oficial (apesar de
muito comum) chamada Release Planning Meeting. O que seria isso?
Nós vimos que ao final da sprint, a equipe entrega um incremento do produto potencialmente
funcional, isto é, tem o potencial de entrar em produção. Ora, muitas vezes é desejável esperar
algumas sprints até juntas todas as funcionalidades e entregar uma release (conjunto de
funcionalidades). Essa cerimônia serve para planejar como será essa release. Isso é muito
importante, porque vocês devem saber a criticidade de colocar algo em produção.
É comum ter várias restrições, preocupações e dependências, como datas importantes, itens
contratuais, logística, entre outros. Dessa forma, a equipe precisa planejar suas entregar várias
sprints à frente. Por fim, é salutar enfatizar que o ciclo de vida do nosso framework é baseado em
três fases principais:
1. Pré-Planejamento (Pre-game Phase)
Define o sistema sendo desenvolvido. Cria-se o Product Backlog, que contém os requisitos atuais e
informações sobre o planejamento do projeto. Cria-se também uma arquitetura de alto nível.
2. Desenvolvimento (Game Phase)

43089971860 -1644786
O sistema é desenvolvido em sprints, por meio de uma abordagem iterativa. A cada sprint, novas
funcionalidades são adicionadas de modo tradicional, i.e., análise, projeto, implementação, etc.
3. Pós-Planejamento (Post-game Phase)
Após o desenvolvimento, são feitas reuniões para analisar o progresso do projeto e demonstrar o
software para os clientes. Aqui ocorrem as etapas de integração, testes finais e documentação.
A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias
a serem aplicadas na próxima Sprint. A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes do
planejamento da próxima Sprint. Esta é uma reunião de no máximo três horas para uma Sprint de um mês. Para Sprint
menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam
seu propósito.
O Scrum Master garante que o evento seja positivo e produtivo. O Scrum Master ensina todos a manter o evento dentro
do time-box. O Scrum Master participa da reunião como um membro auxiliar do time devido a sua responsabilidade pelo
processo Scrum. O propósito da Retrospectiva da Sprint é:
• Inspecionar como a última Sprint foi 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;
O Scrum Master encoraja o Time Scrum a melhorar, dentro do processo do framework do Scrum, seu processo de
desenvolvimento e suas práticas para torná-lo mais efetivo e agradável para a próxima Sprint. Durante cada
Retrospectiva da Sprint, o Time Scrum planeja formas de aumentar a qualidade do produto melhorando o processo de
trabalho ou adaptando a definição de “Pronto”, se apropriado e sem entrar em conflito com os padrões do produto ou
organização.
Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima
Sprint. A implementação destas melhorias na próxima Sprint é a forma de adaptação à inspeção que o Time Scrum faz a
si próprio. Apesar de que melhorias podem ser implementadas a qualquer momento, a Retrospectiva da Sprint fornece
uma oportunidade formal focada em inspeção e adaptação.
O propósito da Sprint Retrospective é planejar maneiras de aumentar a qualidade e a eficácia. O Scrum Team inspeciona
como foi a última Sprint em relação a indivíduos, interações, processos, ferramentas e sua Definição de Pronto. Os
elementos inspecionados geralmente variam com o domínio de trabalho. As suposições que os desviaram são
identificadas e suas origens exploradas. O Scrum Team discute o que deu certo durante a Sprint, quais problemas
encontraram e como esses problemas foram (ou não) resolvidos.
O Scrum Team identifica as mudanças mais úteis para melhorar sua eficácia. As melhorias mais impactantes são
endereçadas o mais rápido possível. Essas podem até ser adicionadas ao Sprint Backlog para a próxima Sprint. A Sprint
Retrospective conclui a Sprint. É limitada pelo Timebox de no máximo três horas para uma Sprint de um mês. Para Sprints
mais curtas, o evento geralmente é mais curto.

43089971860 -1644786
(SINESP – 2015) No Scrum, o evento que ocorre no final da sprint que serve para a equipe
examinar a sprint passada e planejar melhorias é conhecido como:
a) retrospectiva da sprint.
b) avaliação da sprint.
c) lições aprendidas da sprint.
d) melhoria da sprint.
e) fechamento da sprint.
_______________________
Comentários: o evento que ocorre no final da sprint que serve para a equipe examinar a sprint passada e planejar melhorias é a
retrospectiva da sprint (Letra A).
Vamos fazer um resumão de tudo agora! Notem na imagem que tudo começa no canto superior
esquerdo. O Product Owner define o Product Backlog, isto é, uma lista com tudo que ele deseja
que tenha em seu projeto. Então, os integrantes da Equipe Scrum fazem a Reunião de
Planejamento e constroem a Sprint Backlog. O trabalho da sprint segue com reuniões diárias
realizadas pelos desenvolvedores e atualizando os artefatos.
Ao final do sprint, há uma Revisão da Sprint – responsável por analisar se o incremento do produto
entregue realmente satisfaz às expectativas dos clientes. Em seguida, realiza-se a última cerimônia,
também conhecida como Retrospectiva da Sprint! Esse evento é responsável por analisar se o
processo foi efetivamente utilizado e se há alguma sugestão de melhoria. Por fim, essas melhorias
servem de entrada para a próxima reunião de planejamento. Fechou?

43089971860 -1644786
Novidades do Scrum
IMPORTANTE
O Scrum passou por melhorias desde sua versão inicial – acrescentando, modificando ou retirando
conceitos. No entanto, infelizmente as bancas de concurso raramente explicitam no edital qual
versão será cobrada em prova. Dessa forma, professores e alunos ficam vendidos. De toda forma,
essa aula foi feita baseada no Scrum 2013 com atualizações do Scrum 2017 e Scrum 2020, mas
seguem abaixo resumidamente as melhorias da última versão.
Scrum 2020
SIMPLIFICAÇÃO GERAL DO GUIA
O Scrum 2020 coloca ênfase na eliminação de informações redundantes e complexas – assim como
a remoção de qualquer referência remanescente em relação a tecnologia da informação (Ex: testes,
sistemas, design, requerimento, etc), uma vez que ele pode ser utilizado para projetos de quaisquer
áreas. O Guia Scrum agora possui menos do que 13 páginas e apresenta uma linguagem mais
simplificada e compreensível para outros públicos.
Definição de scrum
Enquanto o Scrum 2017 se referia apenas a pessoas para resolução de problemas complexos, a nova
versão trata também de times e organizações. Vejamos:
Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções
adaptativas para problemas complexos.
Fim das três perguntas
Removeram as famosas três perguntas da Reunião Diária, que eram um exemplo de perguntas que
poderiam ser utilizadas pelo time, mas que para muitos virou regra para dar o status do projeto. O
motivo da retirada foi que as perguntas nunca foram obrigatórias e muito menos uma forte
sugestão para que guiassem todas as reuniões diárias – era simplesmente um exemplo que os
autores utilizaram e que passou a ser visto e aplicado como regra.
Por essa razão, eles resolveram remover as perguntas por completo para que não fossem mais
interpretadas incorretamente e gerassem uma disfunção nos Times Scrum.

43089971860 -1644786
Artefatos e compromissos
Surgiram novas definições para artefatos, incluindo o conceito de compromissos conforme

podemos ver a seguir:
Os artefatos do Scrum representam trabalho ou valor. Eles são projetados para maximizar a transparência das
principais informações. Assim, todos os que os inspecionam têm a mesma base para adaptação. Cada artefato
contém um compromisso para garantir que ele forneça informações que aumentem a transparência e o foco
contra o qual o progresso pode ser medido:
– Para o Product Backlog, é a meta do produto;

– Para o Sprint Backlog, é a meta da sprint;
– Para o incremento, é a Definição de Pronto.
==1918f2==
Esses compromissos existem para reforçar o empirismo e os valores Scrum para o Scrum Team, e seus
stakeholders.
A Meta da Sprint e a Definição de Pronto já existiam na versão do Guia Scrum 2017, mas era confuso
e não se sabia ao certo se eram artefatos ou não. Nesta versão, os autores fizeram questão de
reforçar que Meta da Sprint, Definição de Pronto e Meta do Produto são compromissos que o Time
Scrum deve ter em relação aos seus trabalhos e as suas entregas a fim de trazer transparência em
direção ao progresso de cada de artefato e do produto como um todo.
Compromisso: Meta do Produto – descreve um estado futuro do produto que pode servir como um alvo para o
Scrum Team planejar. A Meta do produto está no Product Backlog. O restante do Product Backlog emerge para
definir “o que” cumprirá a Meta do Produto.
Um produto é um veículo para entregar valor. Tem um limite claro, stakeholders conhecidos, usuários ou clientes
bem definidos. Um produto pode ser um serviço, um produto físico ou algo mais abstrato. A Meta do Produto é o
objetivo de longo prazo para o Scrum Team. Eles devem cumprir (ou abandonar) um objetivo antes de assumir o
próximo.
Compromisso: Meta da Sprint – é o único objetivo da Sprint. Embora a Meta da Sprint seja um compromisso dos
desenvolvedores, esta fornece flexibilidade em termos do trabalho exato necessário para alcançá-la.
A Meta da Sprint também cria coerência e foco, encorajando o Scrum Team a trabalhar junto ao invés de
iniciativas separadas. A Meta da Sprint é criada durante o evento Sprint Planning e então adicionada ao Sprint
Backlog. Conforme os desenvolvedores trabalham durante a Sprint, eles mantêm a Meta da Sprint em mente. Se
o trabalho acabar sendo diferente do que eles esperavam, eles colaboram com o Product Owner para negociar o
escopo do Sprint Backlog dentro da Sprint sem afetar a Meta da Sprint.
Compromisso: Definição de Pronto – é uma descrição formal do estado do Incremento quando ela atende às
medidas de qualidade exigidas para o produto. No momento em que um item do Product Backlog atende a
Definição de Pronto, um incremento nasce.
A Definição de Pronto cria transparência ao fornecer a todos um entendimento compartilhado de qual trabalho
foi concluído como parte do Incremento. 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

43089971860 -1644786
para consideração futura. Se a Definição de Pronto para um incremento faz parte dos padrões da organização,
todos os Scrum Teams devem segui-la como mínimo.
Se não for um padrão organizacional, o Scrum Team deve criar uma Definição de Pronto apropriada para o
produto. Os desenvolvedores devem estar em conformidade com a Definição de Pronto. Se houver vários Scrum
Teams trabalhando juntos em um produto, eles devem definir e cumprir mutuamente a mesma Definição de
Pronto.
Remoção do termo ‘time de desenvolvimento’
A presença de um Time de Desenvolvimento passava a impressão de existir um sub-time no Time

Scrum. Foi substituído pela responsabilidade Desenvolvedor. Isso reforça a ideia de termos apenas
um único time: o Time Scrum, formado pelo Scrum Master, o Product Owner e os Desenvolvedores
– seus objetivos devem ser o mesmo.
A mudança não é apenas semântica: ao remover o conceito de sub-time dentro da equipe e deixar
claro que todas essas pessoas pertencem ao mesmo time, o Time Scrum, isso cria um compromisso
mais forte entre todos para a entrega da Meta da Sprint. O Time Scrum é apenas uma equipe com
três responsabilidades diferentes.
A unidade fundamental do Scrum é um pequeno time de pessoas, um Scrum Team. O Scrum Team consiste em
um Scrum Master, um Product owner e Developers. Dentro de um Scrum Team, não há sub-times ou hierarquias.
É uma unidade coesa de profissionais focados em um objetivo de cada vez, a Meta do Produto.
Tamanho da equipe
Na versão do Guia Scrum 2017, estava descrito que o Time de Desenvolvimento deveria idealmente
ser composto por 3 a 9 integrantes. Com o objetivo de se tornar ainda menos prescritivo, agora não
há tamanho mínimo ou máximo. No entanto, o Scrum Guide comenta que o Scrum Team
normalmente tem 10 ou menos integrantes – incluindo na conta o Scrum Master e o Product
Owner.
O Scrum Team é pequeno o suficiente para permanecer ágil e grande o suficiente para concluir um trabalho
significativo dentro de uma Sprint, normalmente 10 ou menos pessoas. Em geral, descobrimos que times menores
se comunicam melhor e são mais produtivos. Se os Scrum Teams se tornarem muito grandes, eles devem
considerar a reorganização em vários Scrum Teams coesos, cada um focado no mesmo produto. Portanto, eles
devem compartilhar o mesma meta do produto, Product Backlog e Product Owner.
“Por que” do Planejamento da sprint
A Sprint Planning trazia os tópicos “O que” e “Como” e, na versão 2020, um novo tópico foi o
adicionado: “Por que”. Logo, deve ser respondido “Por que esta Sprint é valiosa?” e “Por que esta
deve ser realizada?”. Muitas vezes, sabemos o que fazer, como fazer, mas não sabemos por que
fazer – o que acaba gerando produtos inúteis e promovendo o desperdício (o que não é preconizado
pelo lean thinking) por toda a organização.

43089971860 -1644786
Auto-organizável  auto-gerenciável
Houve uma mudança de termos: saiu o “auto-0rganizável” e entrou o “auto-gerenciável”. Neste

ponto, os autores do guia oficial quiseram passar uma forte mensagem em relação a autonomia e
responsabilidades do Scrum Team no sentido de que ele não é só responsável por escolher quem e
como farão o trabalho da sprint, mas devem ser auto-gerenciados de modo a escolher quem, como
e no que trabalhar.
O Scrum Team deve ter as responsabilidades compartilhadas de selecionar, entender e priorizar no

que vão trabalhar, quem irá trabalhar e como irão trabalhar para cumprir os compromissos.
Product owner compartilhado
Um incremento de texto importante foi o que o Product Owner pode ser compartilhado com
múltiplos times. Se os Scrum Teams se tornarem muito grandes, eles devem considerar a
reorganização em vários times menores e coesos, cada um focado no mesmo produto e devem
compartilhar a mesma Meta do Produto, Product Backlog e Product Owner. No entanto, apenas
um PO deve ser considerado, além do mesmo Backlog do Produto e Meta do Produto.

43089971860 -1644786
RESUMO
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. Scrum é: leve, simples de entender e difícil
de dominar.
Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções adaptativas para
problemas complexos.
1º PILAR
2º PILAR
3º PILAR
TRANSPARÊNCIA INSPEÇÃO ADAPTAÇÃO
PILARES DESCRIÇÃO
Todo trabalho deve ser claramente definido e conhecido por todas as partes
TRANSPARÊNCIA
envolvidas no projeto.
Todo trabalho deve ser inspecionado com a frequência necessária para garantir a
INSPEÇÃO
qualidade do produto.
O projeto deve ser capaz de se adaptar o projeto às necessidades de negócio.
ADAPTAÇÃO

43089971860 -1644786
Valores DESCRIÇÃO
Os integrantes de um projeto precisam ter coragem para fazer a coisa certa e
CORAGEM trabalharem juntos removendo impedimentos, buscando soluções.
Os integrantes de um projeto precisam focar no trabalho durante a sprint e nas metas
FOCO designadas – time disperso perde produtividade e não alcança os objetivos.
Os integrantes se comprometem com o trabalho que se responsabilizou em fazer,
COMPROMETIMENTO
envolvendo-se e não abandonando pela metade ou entregando sem qualidade.
Os integrantes se respeitam entre si a fim de manter a colaboração, a integração e o
RESPEITO bom ambiente de trabalho.
Os integrantes devem poder ser francos, expor ideias e propostas mesmo que elas não
ABERTURA
sejam proveitosas. Momentos de debates, discussões e sugestões são ideais.
DEVELOPMENT TEAM DEVELOPERS

==1918f2==
( EQUIPE DE DESENVOLVIMENTO ) ( DESENVOLVEDORES )


( EQUIPE SCRUM )
( EQUIPE SCRUM )
PRODUCT OWNER PRODUCT OWNER
( DONO DO PRODUTO ) ( DONO DO PRODUTO )
SCRUM MASTER SCRUM MASTER

( MESTRE SCRUM ) ( MESTRE SCRUM )
Responsável pela gestão de pessoas e gestão do processo.
Ele deve garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que a
Equipe Scrum adere à teoria, práticas e regras do Scrum.
O Scrum Master ajuda aqueles que estão fora da Equipe Scrum a entender quais as suas interações com
a Equipe Scrum são úteis e quais não são.
O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pela Equipe
Scrum.
Ele é responsável por orientar o Product Owner na criação e ordenação do Product Backlog.
scrum master (sm)
RESPONSABILIDADES
Ele é responsável por garantir que as regras do Scrum estejam sendo cumpridas e seus valores estejam
sendo seguidos.
Ele é responsável por ajudar a remover impedimentos que o time enfrente, fazendo isso sem o uso de
qualquer autoridade.
Ele utiliza técnicas de facilitação e coaching para que os membros do time consigam visualizar os
problemas e encontrem a melhor solução.
Durante eventos, ele é responsável por fazer com que a reunião flua adequadamente, utilizando técnicas
de facilitação, embora não seja o responsável pela condução.
Ele ajuda a treinar os desenvolvedores em autogerenciamento e interdisciplinaridade.
Ele treina os desenvolvedores em ambientes organizacionais nos quais o Scrum não é totalmente
adotado e compreendido.
Ele ensina a Equipe Scrum a criar itens do Product Backlog de forma clara e concisa.

43089971860 -1644786
Ele comunica claramente a visão, objetivo e itens do Product Backlog para os desenvolvedores.
Responsável pela micro-gestão e pela criação do produto.
Eles são auto-organizados. Ninguém (nem mesmo o SM) diz aos desenvolvedores como transformar o
Product Backlog em incrementos de funcionalidades potencialmente utilizáveis.
RESPONSABILIDADES
Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto

desenvolvedores
equipe, para criar o incremento do Produto.

O Scrum não reconhece títulos específicos para os desenvolvedores, independentemente do trabalho
que está sendo realizado pela pessoa;
Individualmente, os desenvolvedores podem ter habilidades especializadas, mas a responsabilidade
pertence aos desenvolvedores como um todo.
Os desenvolvedores não contêm sub-times dedicados a domínios específicos de conhecimento, tais
como teste ou análise de negócios.
Os desenvolvedores são estruturados e autorizados pela organização para organizar e gerenciar seu
próprio trabalho.
Ele é responsável pela macro-gestão e pela gestão do produto.
Ele é o responsável por maximizar o valor do produto e do trabalho dos desenvolvedores, sendo o único
que pode gerenciar o Product Backlog.
Ele pode até delegar as atividades de gerenciamento para os desenvolvedores, mas ainda será
PRODUCT OWNER (PO)
considerado o responsável pelos trabalhos.

RESPONSABILIDADES
Ele é responsável por priorizar/ordenar os itens do Product Backlog e seleciona aqueles que serão
implementados.
Ele é responsável por garantir o ROI (Return On Investment ou Retorno sobre Investimento).
Ele é responsável por expressar claramente os itens do Product Backlog.
Ele é responsável por garantir que o Backlog do Produto seja visível, transparente, claro para todos, e
mostrar o que a Equipe Scrum vai trabalhar a seguir.
Ele é responsável por garantir que os desenvolvedores entendam os itens do Product Backlog no nível
necessário.
Trata-se de uma lista ordenada (por valor, risco, prioridade, entre outros) de requisitos
PRODUCT BACKLOG ou funcionalidades que o produto deve conter criada pela Equipe Scrum e gerenciada
pelo Product Owner.
Trata-se de conjunto de itens selecionados do Product Backlog, mais a meta da sprint
SPRINT BACKLOG e mais um plano de ação para entregar um incremento potencialmente usável – é
criado e gerenciado pelos desenvolvedores.
Trata-se da é da soma de todos os itens do Backlog do Produto completados durante
SPRINT REVIEW a Sprint e o valor dos incrementos de todas as sprints anteriores – sendo validado como
“pronto”.

43089971860 -1644786
Conjunto de critérios que indicam que já existem informações suficientes para um

DEFINIÇÃO DE ready
requisito começar a ser desenvolvido.
Conjunto de critérios que indicam que uma determinada história de usuário atende a
DEFINIÇÃO DE done
todos os requisitos de aceitação para se tornar um incremento.
Reunião dividida em duas partes que possui duração de até 8 horas. Na primeira parte,
a equipe seleciona, alinha e detalha os itens que vão ser desenvolvidos na próxima
SPRINT PLANNING
sprint. Na segunda parte, cada item é estimado e decomposto nas tarefas necessárias
para produzir as entregas.
Reunião diária para alinhar a comunicação do projeto, inspecionar o progresso para a
DAILY SCRUM meta, identificar impedimentos e adaptar o backlog da sprint, se necessário. Não pode
ter mais que 15 minutos de duração, ocorrendo sempre no mesmo local e horário.
Reunião de até 4h de duração realizada ao final de cada sprint para apresentar ao
Product Owner as funcionalidades implementadas para que ele possa validá-las e
Sprint review eventualmente adaptar futuras modificações. Trata-se de um evento informal para
apresentação do incremento e colaboração sobre os próprios passos.
Reunião de até 3h de duração realizada após a Sprint Review. No entanto, em vez de
validar o produto, a equipe busca revisar e validar o processo executado para gerar as
SPRINT RETROSPECTIVE funcionalidades. A ideia é planejar maneiras de aumentar a qualidade e efetividade do
processo.

43089971860 -1644786
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.

43089971860 -1644786
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

43089971860 -1644786
A questão 13 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.
8. (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
9. (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
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:

43089971860 -1644786
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
10. (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 chamados Sprints? Trata-se do Scrum!
Gabarito: Letra D
11. (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:

43089971860 -1644786
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
12. (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
13. (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:
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
14. (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.

43089971860 -1644786
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
15. (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
16. (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.
Gabarito: Correto
17. (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

43089971860 -1644786
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
18. (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
19. (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
20. (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.

43089971860 -1644786
Gabarito: Errado
21. (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.
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
22. (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
23. (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...

43089971860 -1644786
Gabarito: Correto
24. (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.
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
25. (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
26. (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

43089971860 -1644786
27. (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:
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
28. (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
29. (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
30. (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:

43089971860 -1644786
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
31. (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
32. (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
33. (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.
c) Product Owner.
d) Team manager.
Comentários:
Apenas o Product Owner tem autoridade para cancelar a sprint.
Gabarito: Letra C

43089971860 -1644786
34. (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
35. (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:
(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

43089971860 -1644786
36. (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
37. (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.
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

43089971860 -1644786
38. (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
39. (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
40. (FCC / TRF - 3ª REGIÃO – 2019) A Reunião Diária do Scrum é:

43089971860 -1644786
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
41. (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].

43089971860 -1644786
Gabarito: Letra D
42. (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:
==1918f2==
Para iniciar a Reunião de Planejamento da Sprint, deve-se atualizar o backlog do produto.
Gabarito: Letra A
43. (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
44.(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.

43089971860 -1644786
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
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
45. (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
46.(IF-PE / IF-PE – 2019) São características inerentes ao SCRUM:

43089971860 -1644786
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.
Gabarito: Letra B
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.
Gabarito: Letra D
48.(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

43089971860 -1644786
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
49.(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
50. (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

43089971860 -1644786
51. (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”.
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
52. (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.

43089971860 -1644786
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:
(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
53. (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:

43089971860 -1644786
(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
54. (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.
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
55. (FCC / TJ-MA – 2019) Um Analista Judiciário, no papel de Scrum Master, esclarece que:

43089971860 -1644786
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
56. (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:

43089971860 -1644786
(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
57. (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
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
58. (CESGRANRIO / TRANSPETRO – 2018) Quando ocorre, no SCRUM, a reunião de Retrospectiva

da Sprint?

43089971860 -1644786
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
59. (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.
Gabarito: Letra B
60.(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

43089971860 -1644786
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.
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
61. (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
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.

43089971860 -1644786
Comentários:
(I) Product Owner; (II) Scrum Master; (III) Product Backlog.
Gabarito: Letra B
62. (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.
Gabarito: Letra E
63. (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
64.(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:

43089971860 -1644786
a) Time de Desenvolvimento.
b) Product Owner.
c) Scrum Master.
d) Stakeholder.
e) Sprintholder.
Comentários:
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
65. (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
66. (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:

43089971860 -1644786
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
67. (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.
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
68. (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
69. (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
70. (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

43089971860 -1644786
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
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
71. (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
72. (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
73. (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.

43089971860 -1644786
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
74. (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
75. (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
76. (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.

43089971860 -1644786
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. (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
78. (FAPEC / UFMS – 2018) Assinale a alternativa correta considerando as responsabilidades e os

papéis na metodologia SCRUM.

43089971860 -1644786
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:
(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
79. (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:

43089971860 -1644786
(I) Correto; (II) Correto; (III) Errado, é realizada ao final da sprint – é a última cerimônia da sprint.
Gabarito: Letra C
80.(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,
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
81. (INSTITUTO AOCP/ PRODEB – 2018) Sobre as características gerais do Scrum, assinale a
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:

43089971860 -1644786
(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
82. (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.
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
83. (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:

43089971860 -1644786
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
84.(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
produtos com o mais alto valor possível; (e) Errado, ele é leve, simples de entender e extremamente
difícil de dominar.
Gabarito: Letra B
85. (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

43089971860 -1644786
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
86. (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
87. (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

43089971860 -1644786
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.
Gabarito: Letra C
88. (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.

43089971860 -1644786
( 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.
(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
(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

43089971860 -1644786
89. (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
90. (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.

43089971860 -1644786
Gabarito: Letra C
91. (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
92. (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

Comentários:
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

43089971860 -1644786
acima da negociação e contrato; (4) a capacidade de resposta a mudanças acima de um plano pré-
estabelecido.
Gabarito: Letra B
94.(FGV / Banestes – 2018) Com relação aos valores relacionados ao desenvolvimento ágil de

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
95. (FGV / Banestes – 2018) Um dos valores relacionados ao ambiente ágil de desenvolvimento é:

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
96. (UFG / SANEAGO – 2017) Na metodologia SCRUM, quais são os itens registrados dentro de
uma “Retrospectiva”?
a) Pontos positivos, negativos e melhorias para a próxima iteração.

43089971860 -1644786
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
97. (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
98. (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:

43089971860 -1644786
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
99. (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
100. (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:

43089971860 -1644786
(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
101. (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
102. (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.

43089971860 -1644786
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
103. (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
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


43089971860 -1644786
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.
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

43089971860 -1644786

líder;

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.
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
106. (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.
iteração.

43089971860 -1644786
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
107. (FGV / DPE-RO – 2015) O Manifesto Ágil é uma declaração que reúne os princípios e práticas

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
108. (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

43089971860 -1644786
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.
Gabarito: Letra A
109. (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:
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).

43089971860 -1644786
Gabarito: Letra B
110. (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).
Gabarito: Letra E
111. (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:

43089971860 -1644786
Os três pilares são: Transparência, Inspeção e Adaptação.
Gabarito: Letra B
112. (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.

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
113. (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

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

43089971860 -1644786
114. (FGV / DPE-RJ – 2014) Uma das características da metodologia ágil Scrum é:
a) focar nas práticas de engenharia.

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
115. (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.
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

43089971860 -1644786
116. (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
117. (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.
Gabarito: Errado
118. (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
119. (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.

43089971860 -1644786
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
120. (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.
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
121. (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.

43089971860 -1644786
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
122. (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
123. (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
124. (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
relevar! Nas sprints, trabalha-se para alcançar objetivos bem definidos? Sim, a meta da Sprint deve
ser alcançada.

43089971860 -1644786
Gabarito: Correto
125. (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.
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.

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
126. (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.
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...

43089971860 -1644786
Gabarito: Letra A
127. (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
128. (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 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.

43089971860 -1644786
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
129. (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
130. (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 :(

43089971860 -1644786
Gabarito: Correto
131. (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
132. (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
133. (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
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

43089971860 -1644786
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
134. (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
135. (FCC / TRF 4ª – 2010) Na fase de desenvolvimento do Scrum, o software é desenvolvido em

processos iterativos denominados:
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

43089971860 -1644786
136. (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
137. (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.
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.

43089971860 -1644786
Gabarito: Letra B
138. (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
139. (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.

43089971860 -1644786
Gabarito: Letra A
140. (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
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
141. (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
142. (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:

43089971860 -1644786
No Scrum, os projetos são divididos em ciclos chamados sprints.
Gabarito: Letra E

43089971860 -1644786
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.
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.
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.
4. (CESPE / FUNPRESP-EXE - 2022) Na fase de desenvolvimento do Scrum, os requisitos são

escritos no product backlog.
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.
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.
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.
A questão 13 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.

43089971860 -1644786
8. (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
==1918f2==
de:
a) Sprint Planning Meeting.

b) Release Burndown Chart.
c) Release Planning Meeting.
d) Sprint Retrospective Chart.
e) Sprint Review Meeting Chart.
9. (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
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.
10. (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.

43089971860 -1644786
a) Crystal.
b) Kanban.
c) Lean.
d) Scrum.
e) XP.
11. (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.
12. (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.
13. (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.
14. (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.
15. (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
16. (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.
17. (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.

43089971860 -1644786
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
18. (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.
19. (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.
20. (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.
21. (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.
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
22. (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.
23. (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.
24. (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.

43089971860 -1644786
25. (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.
26. (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.
27. (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.
28. (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.
29. (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.
30. (CESPE / Ministério da Economia – 2020) As histórias são consideradas pequenos requisitos
de um projeto na perspectiva do usuário final.
31. (CESPE / Ministério da Economia – 2020) Pequenas partes do trabalho com a perspectiva do
patrocinador são artefatos denominados Epics.
32. (CESPE / Ministério da Economia – 2020) O scrum master possui autoridade para cancelar
uma sprint antes de o time-boxed da sprint terminar.
33. (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.
c) Product Owner.
d) Team manager.
34. (INSTITUTO AOCP / Prefeitura de Novo Hamburgo - RS – 2020) Assinale a alternativa que
apresenta uma metodologia para desenvolvimento de software:
a) BIM
b) BALANCED SCORECARD

43089971860 -1644786
c) COBIT
d) SCRUM
e) ISACA
35. (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.
36. (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.
37. (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.

43089971860 -1644786
38. (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.
39. (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.
40. (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.
41. (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.

43089971860 -1644786
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.
42. (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
43. (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.
44.(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:

43089971860 -1644786
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.
45. (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.
46. (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.
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.

43089971860 -1644786
48. (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.
49. (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.
50. (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.
51. (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”.
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.

43089971860 -1644786
52. (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.
53. (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.
54. (CESPE / TCE-RO – 2019) No Scrum,

43089971860 -1644786
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.
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.
55. (FCC / TJ-MA – 2019) Um Analista Judiciário, no papel de Scrum Master, esclarece que:
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.
56. (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.

43089971860 -1644786
e) O backlog da Sprint deve prever a duração de, no máximo, um mês para cada Sprint.
57. (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
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.
58. (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
59. (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.
60. (FAURGS / TJ-RS - 2018) Considere as seguintes afirmações sobre SCRUM.

43089971860 -1644786
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.
a) Apenas I.
b) Apenas I e II.
c) Apenas I e III.
d) Apenas II e III.
e) I, II e III.
61. (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
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.
62. (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.

43089971860 -1644786
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.
63. (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.
64. (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.
65. (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.
66. (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.

43089971860 -1644786
e) Gerente de sistemas; Sprint; Planejamento.
67. (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.
68. (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.
69. (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.
70. (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.
71. (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.
72. (INSTITUTO AOCP / UFOB – 2018) No Scrum, são utilizados encontros diários, os chamados
Daily Scrum, para disseminar o conhecimento desenvolvido no dia anterior.
73. (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.
74. (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.
75. (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.

43089971860 -1644786
76. (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.
77. (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.
78. (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.

43089971860 -1644786
e) O grupo de usuários finais do produto desenvolvido durante o projeto é denominado Scrum

Users.
79. (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.
80. (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.
81. (INSTITUTO AOCP/ PRODEB – 2018) Sobre as características gerais do Scrum, assinale a
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.
82. (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.

43089971860 -1644786
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.
83. (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.
84. (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.
85. (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.

43089971860 -1644786
86. (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.
87. (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.

43089971860 -1644786
d) Apenas I e III.
e) I, II e III.
88. (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
( 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.
89. (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.

43089971860 -1644786
a) MDE – Engenharia Dirigida a Modelos

b) XP
c) SCRUM
d) MDA – Arquitetura Dirigida a Modelos
e) Programação em Pares
90.(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.
91. (CESPE / BNB – 2018) No Scrum, o Product Owner é a pessoa que define os itens que compõem
o product backlog.
92. (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.


43089971860 -1644786
94. (FGV / Banestes – 2018) Com relação aos valores relacionados ao desenvolvimento ágil de

95. (FGV / Banestes – 2018) Um dos valores relacionados ao ambiente ágil de desenvolvimento é:

96. (UFG / SANEAGO – 2017) Na metodologia SCRUM, quais são os itens registrados dentro de
uma “Retrospectiva”?
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
97. (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.
98. (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.

43089971860 -1644786
99. (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.
100. (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.
101. (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.

43089971860 -1644786
102. (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.
103. (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
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


43089971860 -1644786
a) somente I;
b) somente II;
c) somente III;
d) somente I e III;
e) I, II e III.

líder;

106. (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.
iteração.
107. (FGV / DPE-RO – 2015) O Manifesto Ágil é uma declaração que reúne os princípios e práticas


43089971860 -1644786
108. (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.
109. (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:
a) Product Master
b) Product Owner
c) Scrum Master
d) Scrum Owner
e) Time de Desenvolvimento
110. (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.

43089971860 -1644786
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.
111. (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.
112. (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.

113. (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


43089971860 -1644786
114. (FGV / DPE-RJ – 2014) Uma das características da metodologia ágil Scrum é:
a) focar nas práticas de engenharia.

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.
115. (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.
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.
116. (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.
117. (CESPE / SERPRO – 2013) Scrum é um processo de desenvolvimento que tem como ponto
de partida um conjunto de requisitos bem definidos.
118. (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.
119. (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.

43089971860 -1644786
d) uma iteração que segue um ciclo (PDCA) e entrega incremento de software pronto.
e) um conjunto de requisitos, priorizado pelo Product Owner.
120. (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.
d) registro pendente de trabalhos (Backlog).
e) registro iterativo de desenvolvimento (sprint).
121. (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.
122. (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.
123. (CESPE / BASA – 2012) O escopo, a importância e a estimativa de um Sprint do Scrum são
definidos pelo Product Owner.
124. (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.

43089971860 -1644786
125. (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.
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.

126. (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.
127. (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.

43089971860 -1644786
128. (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 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.
129. (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.
130. (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.
131. (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.
132. (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.
133. (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
implementado do Product Backlog. Assim, a equipe planeja seu trabalho, definindo o Sprint
Backlog, na:

43089971860 -1644786
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.
134. (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.
135. (FCC / TRF 4ª – 2010) Na fase de desenvolvimento do Scrum, o software é desenvolvido em

processos iterativos denominados:
a) Building Products.
b) Product Backlog.
c) Sprint.
d) Product Owner.
e) Product Backlog Cycle.
136. (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.
137. (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.

43089971860 -1644786
c) Modificação no Backlog é prerrogativa do Scrum Master, quando achar necessário, em

qualquer momento no decorrer do Sprint.
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.
138. (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.
139. (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.
140. (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
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.
141. (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.

43089971860 -1644786
142. (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.

43089971860 -1644786

1. ERRADO 41. LETRA D 81. LETRA B
2. CORRETO 42. LETRA A 82. LETRA E
3. CORRETO 43. LETRA D 83. LETRA D
4. ERRADO 44.LETRA E 84.LETRA B
5. ERRADO 45. LETRA D 85. LETRA E
6. CORRETO 46.LETRA B 86. LETRA B
7. LETRA B 47. LETRA D 87. LETRA C
8. LETRA B 48.LETRA A 88. LETRA C
9. LETRA D 49.ERRADO 89. LETRA C
10. LETRA D 50. LETRA C 90.LETRA C
11. LETRA D 51. LETRA B 91. CORRETO
12. LETRA B 52. LETRA D 92. LETRA A
13. CORRETO 53. LETRA E 93. LETRA B
14. ERRADO 54. LETRA C 94.LETRA C
15. CORRETO 55. LETRA C 95. LETRA E
16. CORRETO 56. LETRA E 96. LETRA A
17. LETRA E 57. LETRA A 97. ANULADA
18. ERRADO 58. LETRA B 98. LETRA A
19. CORRETO 59. LETRA B 99. ANULADA
20. ERRADO 60.LETRA B 100. LETRA D
21. LETRA A 61. LETRA B 101. LETRA B
22. LETRA C 62. LETRA E 102. LETRA B
23. CORRETO 63. LETRA D 103. LETRA E
24. CORRETO 64.LETRA A 104. LETRA B
25. ERRADO 65. LETRA C 105. LETRA A
27. ERRADO 67. CORRETO 107. LETRA E
28. CORRETO 68. ERRADO 108. LETRA A
29. CORRETO 69. ERRADO 109. LETRA B
30. CORRETO 70. CORRETO 110. LETRA E
31. ERRADO 71. CORRETO 111. LETRA B
33. CORRETO 73. LETRA A 113. LETRA B
34. LETRA D 74. LETRA E 114. LETRA C
35. LETRA C 75. ERRADO 115. LETRA E
36. LETRA B 76. LETRA E 116. CORRETO
37. LETRA B 77. LETRA B 117. ERRADO
38. LETRA D 78. LETRA A 118. CORRETO
39. LETRA A 79. LETRA C 119. LETRA D
40. LETRA D 80.LETRA A 120. LETRA D

43089971860 -1644786
121. LETRA E 129. LETRA A 137. LETRA B

123. ERRADO 131. CORRETO 139. LETRA A
124. CORRETO 132. CORRETO 140. ERRADO
125. LETRA E 133. LETRA B 141. LETRA E
126. LETRA A 134. LETRA E 142. LETRA E
127. LETRA A 135. LETRA C
128. LETRA E 136. LETRA E

43089971860 -1644786
APRESENTAÇÃO
O assunto da aula de hoje é: Extreme Programming! Trata-se de uma famosa metodologia de
desenvolvimento ágil. É muuuuuuuuito tranquila de entender, teoria pequena e muitas questões
para treinar. Essa é aquela aula para dar uma relaxada porque não exige muito. Tentem fazer todas
as questões propostas e a chance de você errar uma questão de prova sobre esse tema será bem
pequena. Vamos lá...


43089971860 -1644786
==1918f2==

43089971860 -1644786
EXTREME PROGRAMMING (XP)

1 – Conceitos Básicos
Em 1996, Kent Beck desenvolveu um novo paradigma de

desenvolvimento de software que rompia com grande
parte das metodologias tradicionais e a batizou de
Extreme Programming. Por que extremo? Porque ele
recomenda que as boas práticas sejam levadas ao
extremo! Ahn? Como assim, professor?
 Testar é bom?
Então vamos testar toda hora!
 Iterar é bom?
Então vamos iterar toda hora!
 Integrar é bom?
Então vamos integrar toda hora!
O eXtreme Programming é uma metodologia ágil de desenvolvimento de software para

equipes pequenas, coesas e multidisciplinares cujos projetos possuem requisitos vagos e em
constante mudança. Ele parte do princípio de que o código-fonte é a melhor documentação, pois
qualquer outra se torna rapidamente desatualizada e perde sua confiabilidade. Aliás, a
codificação/programação é a atividade principal no XP!
No eXtreme Programming, todos os requisitos são expressos como cenários (também chamados
histórias do usuário1), que são implementados diretamente como uma série de tarefas. Os
programadores trabalham em pares e desenvolvem testes para cada tarefa antes da escrita do
código-fonte em si. Sempre que há integração de uma nova funcionalidade, há novos testes e o
usuário realiza uma priorização dos requisitos para o desenvolvimento.
A equipe de desenvolvimento (ou programadores) avalia cada um dos cenários e os divide em

tarefas. Cada tarefa representa uma característica discreta/isolada do sistema e um teste
unitário pode então ser projetado para essa tarefa. Os testes de aceitação (ou testes de cliente)
são especificados pelo cliente e mantêm o foco nas características e funcionalidades visíveis do
sistema como um todo.
No XP, o desenvolvimento incremental é apoiado por pequenos e frequentes releases do

sistema e por uma abordagem de descrição de requisitos baseada nos cenários do cliente. Além
disso, o envolvimento do cliente em tempo integral facilita bastante o desenvolvimento e melhora
1
Por vezes, também chamado de estórias de usuário.

43089971860 -1644786
a qualidade do produto. Agora vejam só... eu falei muito rapidamente sobre histórias de usuário,
mas é importante se aprofundar um pouco porque ela é muito importante.
Histórias de Usuário (User Stories) são artefatos de desenvolvimento utilizados em sistemas

geridos segundo metodologias ágeis. Nós podemos dizer que as histórias de usuário são uma
descrição resumida de alguma funcionalidade fornecida pelo sistema do ponto de vista de um
usuário desse sistema. Ela representa uma pequena parte da funcionalidade do sistema a ser
construído – não se trata de uma especificação completa de uma funcionalidade. Vejamos...
Uma história de usuário é apenas um símbolo das conversas passadas e futuras entre o cliente e os
programadores. Lembrando que a presença do cliente no local minimiza a necessidade de
documentar extensamente cada história. Por que? Porque os programadores podem
simplesmente dar alguns passos e fazer suas perguntas ao cliente. Galera, é muito mais proveitoso
tirar uma eventual dúvida rapidamente do que marcar uma reunião formal para dias depois...
Os detalhes das histórias de usuário são capturados nos testes automatizados de aceitação que
são posteriormente usados para validar a implementação da história. Eventualmente poderá
não ser necessário escrever descrições para todas as histórias, visto que o nome de algumas
histórias já irá fornecer informações suficientes. E o que indica uma boa história de usuário? O cliente
deverá se preocupar com ela.
A história deverá ter valor de negócio na visão do cliente, para que possa ser priorizada. Às vezes
uma história precisa ser decomposta em partes menores para caber em uma iteração. Se por si
só a história não fornecer valor de negócio, deverá fornecer no mínimo progresso em direção a uma
funcionalidade de valor ao negócio. As histórias de usuário atravessam verticalmente a arquitetura
do produto – normalmente elas não estão focadas em um subsistema específico.
Histórias de usuário podem ser razoavelmente estimadas pelos desenvolvedores e as histórias

que não puderem ser estimadas idealmente deverão ser reescritas. Além disso, casos de teste
devem ser escritos para verificar se os programadores as implementaram corretamente. O que são
casos de teste, Diego? É um conjunto de condições usadas para teste de software – ele especifica os
valores de entrada e os resultados esperados do processamento de uma funcionalidade.

43089971860 -1644786
Por fim, elas devem ser concluídas em até uma iteração. Uma história de usuário que não caiba
em uma iteração deverá ser decomposta em duas ou mais histórias menores de modo que
caibam em uma iteração. Galera, as histórias criam um ambiente de propriedade do cliente em
relação aos recursos e prioridades em um contexto incremental e iterativo de desenvolvimento. A
seguir, podemos ver mais alguns exemplos de histórias de usuário:

43089971860 -1644786
Principais Práticas
O XP possui um conjunto de práticas que são frequentemente utilizadas. Galera... isso cai, mas cai
com muita força em prova! Talvez seja a parte mais importante da aula :)
PRÁTICAs DESCRIÇÃO
Planejamento Os requisitos são registrados em cartões de histórias e as histórias a serem incluídas em um
release são determinadas pelo tempo disponível e sua prioridade relativa. Os desenvolvedores
Incremental dividem essas histórias em tarefas.
Pequenos O conjunto mínimo útil de funcionalidade que agrega valor ao negócio é desenvolvido
primeiro. Releases do sistema são frequentes e adicionam funcionalidade incrementalmente
Releases ao primeiro release.
Projeto É realizado um projeto suficientemente simples de modo que atenda aos requisitos atuais e
nada mais. Deve-se lembrar que um código simples não é código fácil (KIS – Keep It Simple).
Simples
Desenvolvimento Um framework automatizado de teste unitário é usado para escrever os testes para uma nova
parte da funcionalidade antes que esta seja implementada. Portanto, primeiro se escreve o
Test-First teste, depois faz-se a implementação.
Espera-se que todos os desenvolvedores recriem o código continuamente tão logo os
Refactoring aprimoramentos do código forem encontrados. Isso torna o código simples de entender e fácil
de manter.
Programação Os desenvolvedores trabalham em pares, um verificando o trabalho do outro e fornecendo
apoio para realizar sempre um bom trabalho. Eles utilizam o mesmo mouse, teclado e monitor.
em Pares
Propriedade Os pares de desenvolvedores trabalham em todas as áreas do sistema, de tal maneira que não
se formem ilhas de conhecimento, com todos os desenvolvedores de posse de todo o código.
Coletiva Qualquer um pode mudar qualquer coisa.
Integração Tão logo o trabalho em uma tarefa seja concluído, este é integrado ao sistema como um todo.
Depois de qualquer integração, todos os testes unitários do sistema devem ser realizados.
Contínua
Ritmo Grandes quantidades de horas extras não são consideradas aceitáveis, pois, no médio prazo,
há uma redução na qualidade do código e na produtividade. Trabalhar por longos períodos se
Sustentável torna contraproducente – recomenda-se 40 horas semanais.
A equipe se comunica sobre o desenvolvimento de software por meio de metáforas, caso
Metáforas consiga encontrar uma que realmente faça sentido dentro do contexto e possa facilitar a
comunicação.
Cliente Um representante do usuário final do sistema deve estar disponível em tempo integral para
apoiar a equipe. No XP, o cliente é um membro da equipe de desenvolvimento e é responsável
On-site por trazer os requisitos do sistema.
Reuniões Reuniões são realizadas em pé para não se perder o foco nos assuntos, produzindo reuniões
mais rápidas, somente abordando as tarefas realizadas e tarefas a realizar pela equipe no
em Pé futuro.
Time A equipe de desenvolvimento é formada por pessoas engajadas e multidisciplinares, i.e., elas
possuem habilidades para diversas áreas do projeto.
Coeso

43089971860 -1644786
Jogo do O planejamento de um release e das iterações são feitos com base nas histórias e conta com a
colaboração de toda equipe de desenvolvimento, inclusive o cliente, divididos em papeis:
Planejamento negócio e técnico. Os clientes priorizam e os desenvolvedores avaliam e estimam.
É claro que – no contexto do dia a dia – nem todas as práticas são utilizadas por organizações
que adotam o XP. Em regra, cada organização escolhe aquelas que consideram mais úteis,
eficientes e viáveis. Ex: para acomodar os diferentes níveis de habilidade, alguns programadores
não fazem refatoração em partes do sistema que não desenvolveram; nem sempre é possível
programar em pares; etc. É claro que a teoria trata do mundo ideal...
==1918f2==

43089971860 -1644786
Processo do XP
E como seria o processo do Extreme Programming? Galera, no contexto de programação, a

abordagem orientada a objetos é o paradigma de desenvolvimento preferido do XP e envolve um
conjunto de regras e práticas em torno de quatro atividades metodológicas principais: (1)
Planejamento, (2) Projeto, (3) Codificação e (4) Teste. Observem na imagem abaixo como tudo
isso funciona:
1 - Planejamento
A atividade de planejamento se inicia com a atividade de ouvir – uma atividade de levantamento de
requisitos que capacita os membros técnicos da equipe a entender o ambiente de negócios e a fim
de ter uma percepção ampla sobre os resultados solicitados, fatores principais e funcionalidade.
“Ouvir” conduz à criação de um conjunto de histórias de usuários que descreve o resultado, as
características e a funcionalidade requisitados para o software a ser construído.
Cada história é escrita pelo cliente e é colocada em uma ficha. Ele atribui um valor (prioridade) à
história baseando-se no valor de negócio global do recurso/função. Os membros da equipe XP
avaliam cada história e atribuem um custo a ela medido em semanas de desenvolvimento. Se a
história requerer, por estimativa, mais que três semanas de desenvolvimento, é solicitado ao cliente
para dividir a história em histórias menores e a atribuição de valor e custo ocorre novamente.
É importante notar que podem ser escritas novas histórias a qualquer momento. Clientes e
desenvolvedores trabalham juntos para decidir como agrupar histórias para a versão seguinte
(o próximo incremento de software) a ser desenvolvida pela equipe XP. Conseguindo chegar a
um compromisso básico (concordância sobre quais histórias serão incluídas, data de entrega, etc)
para uma versão, a equipe XP ordena as histórias a ser desenvolvidas em uma das três formas:

43089971860 -1644786
(1) todas serão implementadas imediatamente (em um prazo de poucas semanas); (2) as histórias
de maior valor serão deslocadas para cima no cronograma e implementadas primeiro; ou (3) as
histórias de maior risco serão deslocadas para cima no cronograma e implementadas primeiro.
Depois de a primeira versão do projeto (também denominada incremento de software) ter sido
entregue, a equipe XP calcula a velocidade do projeto.
De forma simples, a velocidade do projeto é o número de histórias de clientes implementadas

durante a primeira versão. Assim, a velocidade do projeto pode ser utilizada para (1) ajudar a
estimar as datas de entrega e o cronograma para versões subsequentes e (2) determinar se foi
assumido um compromisso exagerado para todas as histórias ao longo de todo o projeto de
desenvolvimento.
Se ocorrer um exagero, o conteúdo das versões é modificado ou as datas finais de entrega são
alteradas. Conforme o trabalho de desenvolvimento prossegue, o cliente pode acrescentar
histórias, mudar o valor de uma existente, dividir algumas ou eliminá-las. Em seguida, a equipe XP
reconsidera todas as versões remanescentes e modifica seus planos de acordo. Vamos ver agora
como funciona o Projeto...
2 - Projeto
O projeto XP segue rigorosamente o princípio KIS (Keep It Simple, ou seja, preserve a
simplicidade). É preferível sempre um projeto simples do que uma representação mais complexa.
Como acréscimo, o projeto oferece um guia de implementação para uma história à medida que é
escrita — nada mais, nada menos. O projeto de funcionalidade extra (pelo fato de o desenvolvedor
supor que ela será necessária no futuro) é desencorajado.
O Extreme Programming encoraja o uso de cartões CRC (Classe – Responsabilidade -

Colaborador) como um mecanismo eficaz para pensar sobre o software em um contexto
orientado a objetos. Os cartões CRC identificam e organizam as classes orientadas a objetos7
relevantes para o incremento de software corrente. Os cartões CRC são o único artefato de projeto
produzidos como parte do processo XP.
Se um difícil problema de projeto for encontrado como parte do projeto de uma história, o XP
recomenda a criação imediata de um protótipo operacional dessa parte do projeto. Denominada
solução pontual, o protótipo do projeto é implementado e avaliado. O objetivo é reduzir o risco
para quando a verdadeira implementação iniciar e validar as estimativas originais para a
história contendo o problema de projeto.
Anteriormente, nós dissemos que o XP encoraja a refatoração – uma técnica de construção que
também é um método para otimização de projetos. Refatoração é o processo de alteração de um
sistema de software de tal forma que não se altere o comportamento externo do código, mas se

43089971860 -1644786
aprimore a estrutura interna. É uma forma disciplinada de organizar código (e modificar/simplificar

o projeto interno) que minimiza as chances de introdução de bugs.
Ao se refatorar, se está aperfeiçoando o projeto de codificação depois de este ter sido feito. Como
o XP não usa praticamente nenhuma notação e produz poucos, se algum, artefatos, além dos
cartões CRC e soluções pontuais, o projeto é visto como algo transitório que pode e deve ser
continuamente modificado conforme a construção prossegue. O objetivo é controlar modificações
sugerindo pequenas mudanças de projeto capazes de melhorá-lo radicalmente.
Deve ser observado, no entanto, que o esforço necessário para a refatoração pode aumentar
dramaticamente à medida que o tamanho de uma aplicação cresça. Um aspecto central no XP é
o de que a elaboração do projeto ocorre tanto antes como depois de se ter iniciado a codificação.
Na realidade, a própria atividade de desenvolvimento guiará a equipe XP quanto à aprimoração do
projeto. Vamos partir para a codificação...
3 - Codificação:
Depois de desenvolvidas as histórias e o trabalho preliminar de elaboração do projeto ter sido
feito, a equipe não passa para a codificação, mas – sim – desenvolve uma série de testes de
unidades que exercitarão cada uma das histórias a ser inclusas na versão corrente (incremento
de software). Uma vez criado o teste de unidades, o desenvolvedor poderá melhor focar-se no que
deve ser implementado para ser aprovado no teste. Nada estranho é adicionado (KIS)!
Estando o código completo, este pode ser testado em unidade imediatamente, e, dessa forma,
prover – instantaneamente – feedback para os desenvolvedores. Conforme vimos, um conceito-
chave na atividade de codificação é a programação em dupla. O Extreme Programming
recomenda que duas pessoas trabalhem juntas em uma mesma estação de trabalho para criar
código para uma história.
Isso fornece um mecanismo para resolução de problemas em tempo real (duas cabeças
normalmente funcionam melhor do que uma) e garantia da qualidade em tempo real (o código é
revisto à medida que é criado). Ele também mantém os desenvolvedores focados no problema em
questão. Na prática, cada pessoa assume um papel ligeiramente diferente. Por exemplo: uma
pessoa pensa nos detalhes de codificação, enquanto outra trata dos padrões de codificação.
Conforme a dupla de programadores completa o trabalho, o código que desenvolveram é integrado

ao trabalho de outros. Em alguns casos, isso é realizado diariamente por uma equipe de integração.
Em outros, a dupla de programadores é responsável pela integração. A estratégia de integração
contínua ajuda a evitar problemas de compatibilidade e de interfaceamento, além de criar um
ambiente “teste da fumaça” que ajuda a revelar erros precocemente.
4 - Testes:

43089971860 -1644786
Já foi observado que a criação de testes de unidade, antes de começar a codificação, é um

elemento-chave da abordagem XP. Os testes de unidade criados devem ser implementados
usando-se uma metodologia que os capacite a ser automatizados (assim, poderão ser executados
fácil e repetidamente). Isso encoraja uma estratégia de testes de regressão, toda vez em que o
código for modificado (o que é frequente, dada a filosofia de refatoração do XP).
Como os testes de unidades individuais são organizados em um “conjunto de testes universal”, os

testes de integração e validação do sistema podem ocorrer diariamente. Isso dá à equipe XP uma
indicação contínua do progresso e também permite lançar alertas logo no início, caso as coisas não
andem bem. Wells afirma: “Corrigir pequenos problemas em intervalos de poucas horas leva menos
tempo do que corrigir problemas enormes próximo ao prazo de entrega”.
E como é a visão de Sommerville sobre o Processo XP? Bem.. ele afirma que os clientes estão
intimamente envolvidos na especificação e priorização dos requisitos do sistema. Os requisitos não
==1918f2==
estão especificados como uma lista de funções requeridas do sistema. Pelo contrário, o cliente do
sistema é parte da equipe de desenvolvimento e discute cenários com outros membros da
equipe. Juntos, eles desenvolvem um cartão de história, englobando as necessidades do cliente:
A equipe de desenvolvimento, então, tenta implementar esse cenário em uma release futura do
software. Os cartões de história são as principais entradas para o processo de planejamento em XP
ou Jogo de Planejamento. Uma vez que tenham sido desenvolvidos, a equipe de desenvolvimento
os divide em tarefas e estima o esforço e os recursos necessários para a realização de cada tarefa.
Esse processo geralmente envolve discussões com o cliente para refinamento dos requisitos.
O cliente, então, prioriza as histórias para implementação, escolhendo aquelas que podem ser
usadas imediatamente para oferecer apoio aos negócios. A intenção é identificar funcionalidade
útil que possa ser implementada em cerca de duas semanas, quando o próximo release do
sistema é disponibilizado para o cliente. Claro que, como os requisitos mudam, as histórias não
implementadas mudam ou podem ser descartadas.

43089971860 -1644786
Se houver necessidade de mudanças em um sistema que já tenha sido entregue, novos cartões de
histórias são desenvolvidos e, mais uma vez, o cliente decide se essas mudanças devem ter
prioridade sobre a nova funcionalidade. Às vezes, durante o jogo de planejamento, emergem
questões que não podem ser facilmente respondidas, tornando necessário algum trabalho
adicional para explorar possíveis soluções.
A equipe pode fazer algum protótipo ou desenvolvimento-teste para entender o problema e a

solução. Em termos XP, isso é chamado de spike – um incremento em que nenhum tipo de
programação é realizado. Também pode haver spikes de projeto da arquitetura do sistema ou para
desenvolver a documentação do sistema. De acordo com Sommerville, eis o ciclo de um incremento
no Extreme Programming:
PROCESSO PARA DESENVOLVER UM INCREMENTO

43089971860 -1644786
Valores Fundamentais
VALORES
DESCRIÇÃO
FUNDAMENTAIS
Para se desenvolver um sistema de software, exige-se comunicar os requisitos de sistema para
os desenvolvedores. Em metodologias formais de desenvolvimento de software, esta tarefa é
COMUNICAÇÃO realizada por meio de documentação. O Extreme Programming favorece projetos simples,
metáforas comuns, a colaboração dos usuários, programadores e outros stakeholders, a
comunicação verbal frequente e o feedback.
XP incentiva que se comece com a solução mais simples. Funcionalidades adicionais podem
ser acrescentadas posteriormente. Alega-se que desenvolver funções que não são necessárias
SIMPLICIDADE hoje pode ser prejudicial, na medida em que futuramente essa função pode não ser mais útil.
Codificação e projeto de necessidades futuras incertas implicam o risco de gastar recursos em
algo não mais necessários, embora talvez atrasando aspectos cruciais.
O feedback ocorre quando os testes unitários ou testes de integração retornam o estado do

sistema após a implementação das mudanças. Ademais, como os clientes participam do
FEEDBACK desenvolvimento de testes, eles podem dar um feedback instantâneo. Dessa forma, o cliente
pode orientar o desenvolvimento em uma possível recodificação do sistema. Quando o cliente
traz um novo requisito, recebe um feedback de tempo e orçamento.
A coragem permite que os desenvolvedores se sintam confortáveis com ao refatorar o seu

código, quando necessário. Eventualmente, há de se ter coragem para jogar fora um código
CORAGEM ou para remover um código obsoleto, não importa quanto esforço e tempo se gastou para
produzi-lo. Além disso, coragem significa persistência, pois um programador pode se
encontrar preso em um problema complexo durante um dia inteiro sem conseguir resolver.
Aqui se inclui o respeito pelos outros, assim como o auto-respeito. Membros devem respeitar
seu próprio trabalho, sempre se esforçando para oferecer alta qualidade e buscando o melhor
RESPEITO projeto para a solução através de refatoração. Ninguém na equipe deve se sentir
desvalorizado ou ignorado. Isso garante um alto nível de motivação e incentiva a lealdade
dentro da equipe. Este valor é muito dependente dos outros valores.
COMUNICAÇÃO SIMPLICIDADE COMUNICAÇÃO FEEDBACK RESPEITO

Cor Sim Com Fe Re
CorSim ComFeRe
43089971860 -1644786
Princípios Básicos
Da mesma forma que existem valores fundamentais, há também princípios básicos. Galera, não
confundam esses dois conceitos! É muito fácil de confundi-los porque eles também são cinco. Os
princípios básicos devem ser seguidos por equipes que forem utilizar o XP em projetos. Os
princípios servirão para ajudar na escolha de alternativas de solução de problemas durante o curso
do projeto. Vejamos quais são:
Princípios básicos DESCRIÇÃO

Retorno tempestivo do cliente, isto é, o sistema é apresentado e – a cada mudança – há um
Feedback rápido novo retorno positivo ou negativo do cliente.
Abraçar Mudanças devem ser bem-vindas e ocorrerão de acordo com o melhor entendimento do
mudanças projeto.
Presumir Todo problema deve ser tratado para ser resolvido da forma mais simples possível.
simplicidade
Mudanças A solução deve ser aperfeiçoada a cada iteração de modo a satisfazer, ao fim, as expectativas
incrementais do usuário.
Trabalho de A qualidade jamais deve ser comprometida – essa é uma das razões para se ter a codificação
qualidade dos testes antes da codificação do sistema.
No XP, as novas versões de software podem ser compiladas várias vezes por dia e os
incrementos são entregues para os clientes aproximadamente a cada duas semanas. Quando
um programador compila o sistema para criar uma nova versão, ele deve executar todos os testes
automatizados existentes bem como os testes para a nova funcionalidade. A nova compilação do
software será aceita somente se todos os testes foram executados com sucesso.
Um preceito essencial da engenharia de software tradicional é projetar mudanças. Em outras

palavras, você deve antecipar mudanças futuras para o software e projetá-lo de tal maneira que
essas mudanças possam ser implementadas facilmente. O Extreme Programming, contudo,
descarta esse princípio alegando que projetar para a mudança é, geralmente, um esforço
completamente inútil.
As mudanças antecipadas muitas vezes não ocorrem e as solicitações de mudança realizadas são
completamente diferentes, causando diversos prejuízos ao sistema. Entenderam o problema? O
problema com a implementação de mudanças não antecipadas é que elas tendem a degradar a
estrutura do software, fazendo com que as mudanças se tornem cada vez mais difíceis de
implementar.
O Extreme Programming lida com este problema defendendo que o software deve passar por
refatoramento constantemente. Isso significa que a equipe de programação procura por
possíveis melhorias no software, implementando-as imediatamente. Portanto, o software deve

43089971860 -1644786
sempre ser fácil de compreender e alterar quando novas histórias de usuário são implementadas.
Essa agilidade é muito importante no desenvolvimento ágil de software. Bacana?
Por último, vamos falar um pouco mais sobre Testes de Software. Sommerville afirma que uma das
diferenças importantes entre o desenvolvimento incremental e o desenvolvimento dirigido a
planos está na forma como o sistema é testado. Com o desenvolvimento incremental, não há
especificação do sistema que possa ser usada por uma equipe de teste externa para
desenvolvimento de testes do sistema.
Como consequência, algumas abordagens para o desenvolvimento incremental têm um

processo de testes muito informal em comparação com os testes dirigidos a planos. Para evitar
alguns dos problemas de teste e validação do sistema, o XP enfatiza a importância dos testes de
software e inclui uma abordagem de testes que reduz as chances de erros desconhecidos na versão
atual do sistema. ==1918f2==
As principais características dos testes na metodologia XP são: (1) Desenvolvimento test-first; (2)
Desenvolvimento de teste incrementais a partir de cenários; (3) Envolvimento dos usuários no
desenvolvimento de testes e validação; (4) Uso de frameworks de testes automatizados. Bem,
pessoal! Finalizamos toda a teoria do XP. Vocês viram que não é difícil e as questões são bem
decorebas. Entendendo o fundamento, é possível respondê-las. Vamos lá...

43089971860 -1644786
RESUMO
EXTREME PROGRAMMING
O eXtreme Programming é uma metodologia ágil de desenvolvimento de software para equipes pequenas,
coesas e multidisciplinares cujos projetos possuem requisitos vagos e em constante mudança.
Exemplo de Histórias de usuário
PROCESSOS DO EXTREME PROGRAMMING

43089971860 -1644786
PRÁTICAs DESCRIÇÃO
Planejamento Os requisitos são registrados em cartões de histórias e as histórias a serem incluídas em um
release são determinadas pelo tempo disponível e sua prioridade relativa. Os desenvolvedores
Incremental dividem essas histórias em tarefas.
Pequenos O conjunto mínimo útil de funcionalidade que agrega valor ao negócio é desenvolvido
primeiro. Releases do sistema são frequentes e adicionam funcionalidade incrementalmente
Releases ao primeiro release.
Projeto É realizado um projeto suficientemente simples de modo que atenda aos requisitos atuais e
nada mais. Deve-se lembrar que um código simples não é código fácil (KIS – Keep It Simple).
Simples
Desenvolvimento Um framework automatizado de teste unitário é usado para escrever os testes para uma nova
parte da funcionalidade antes que esta seja implementada. Portanto, primeiro se escreve o
Test-First teste, depois faz-se a implementação.
Espera-se que todos os desenvolvedores recriem o código continuamente tão logo os
Refactoring aprimoramentos do código forem encontrados. Isso torna o código simples de entender e fácil
==1918f2==
de manter.
Programação Os desenvolvedores trabalham em pares, um verificando o trabalho do outro e fornecendo
em Pares
Propriedade Os pares de desenvolvedores trabalham em todas as áreas do sistema, de tal maneira que não
se formem ilhas de conhecimento, com todos os desenvolvedores de posse de todo o código.
Coletiva Qualquer um pode mudar qualquer coisa.
Integração Tão logo o trabalho em uma tarefa seja concluído, este é integrado ao sistema como um todo.
Depois de qualquer integração, todos os testes unitários do sistema devem ser realizados.
Contínua
Ritmo Grandes quantidades de horas extras não são consideradas aceitáveis, pois, no médio prazo,
há uma redução na qualidade do código e na produtividade. Trabalhar por longos períodos se
Sustentável torna contraproducente – recomenda-se 40 horas semanais.
A equipe se comunica sobre o desenvolvimento de software por meio de metáforas, caso
Metáforas consiga encontrar uma que realmente faça sentido dentro do contexto e possa facilitar a
comunicação.
Cliente Um representante do usuário final do sistema deve estar disponível em tempo integral para
apoiar a equipe. No XP, o cliente é um membro da equipe de desenvolvimento e é responsável
On-site por trazer os requisitos do sistema.
Reuniões Reuniões são realizadas em pé para não se perder o foco nos assuntos, produzindo reuniões
mais rápidas, somente abordando as tarefas realizadas e tarefas a realizar pela equipe no
em Pé futuro.
Time A equipe de desenvolvimento é formada por pessoas engajadas e multidisciplinares, i.e., elas
possuem habilidades para diversas áreas do projeto.
Coeso
Jogo do O planejamento de um release e das iterações são feitos com base nas histórias e conta com a
colaboração de toda equipe de desenvolvimento, inclusive o cliente, divididos em papeis:
Planejamento negócio e técnico. Os clientes priorizam e os desenvolvedores avaliam e estimam.
VALORES
DESCRIÇÃO
FUNDAMENTAIS
Para se desenvolver um sistema de software, exige-se comunicar os requisitos de sistema para
COMUNICAÇÃO os desenvolvedores. Em metodologias formais de desenvolvimento de software, esta tarefa é

43089971860 -1644786
realizada por meio de documentação. O Extreme Programming favorece projetos simples,

XP incentiva que se comece com a solução mais simples. Funcionalidades adicionais podem
ser acrescentadas posteriormente. Alega-se que desenvolver funções que não são necessárias
SIMPLICIDADE hoje pode ser prejudicial, na medida em que futuramente essa função pode não ser mais útil.
Codificação e projeto de necessidades futuras incertas implicam o risco de gastar recursos em
algo não mais necessários, embora talvez atrasando aspectos cruciais.
FEEDBACK desenvolvimento de testes, eles podem dar um feedback instantâneo. Dessa forma, o cliente
pode orientar o desenvolvimento em uma possível recodificação do sistema. Quando o cliente
traz um novo requisito, recebe um feedback de tempo e orçamento.
A coragem permite que os desenvolvedores se sintam confortáveis com ao refatorar o seu
código, quando necessário. Eventualmente, há de se ter coragem para jogar fora um código
CORAGEM ou para remover um código obsoleto, não importa quanto esforço e tempo se gastou para
produzi-lo. Além disso, coragem significa persistência, pois um programador pode se
Aqui se inclui o respeito pelos outros, assim como o auto-respeito. Membros devem respeitar
seu próprio trabalho, sempre se esforçando para oferecer alta qualidade e buscando o melhor
RESPEITO projeto para a solução através de refatoração. Ninguém na equipe deve se sentir
desvalorizado ou ignorado. Isso garante um alto nível de motivação e incentiva a lealdade
dentro da equipe. Este valor é muito dependente dos outros valores.
Princípios básicos DESCRIÇÃO

Retorno tempestivo do cliente, isto é, o sistema é apresentado e – a cada mudança – há um
Feedback rápido
novo retorno positivo ou negativo do cliente.
Abraçar Mudanças devem ser bem-vindas e ocorrerão de acordo com o melhor entendimento do
projeto.
mudanças
Presumir Todo problema deve ser tratado para ser resolvido da forma mais simples possível.
simplicidade
Mudanças A solução deve ser aperfeiçoada a cada iteração de modo a satisfazer, ao fim, as expectativas
incrementais do usuário.
Trabalho de A qualidade jamais deve ser comprometida – essa é uma das razões para se ter a codificação
qualidade dos testes antes da codificação do sistema.

43089971860 -1644786

1. (COMPERVE / TJ-RN – 2020) O método ágil Extreme Programming ou XP é um dos métodos
ágeis mais conhecidos. Sobre as características desse método, é correto afirmar:
a) o planning game é uma reunião que ocorre a cada iteração com o objetivo de discutir o que
foi feito na última iteração.
b) o código fonte que será executado no ambiente de produção é desenvolvido em pares, sendo
que o par se alterna nos papéis de condutor e navegador.
c) é importante tentar prever o que o cliente deseja e executar antes mesmo de comunicá -lo,
mostrando proatividade na resolução de possíveis problemas.
d) o código fonte de cada página pertence a um membro da equipe. Qualquer alteração a ser
realizada precisa ser informada ao respectivo membro.
Comentários:
(a) Errado. Na verdade, o planning game é uma reunião de planejamento para discutir o que será
feito; (b) Correto. Desenvolvedores trabalham em pares, um verificando o trabalho do outro; (c)
Errado. No XP, o envolvimento do cliente ocorre em tempo integral; (d) Errado. XP valoriza o
trabalho em equipe e, por isso, o código fonte pertence a equipe.
Gabarito: Letra B
2. (CESPE / Ministério da Economia – 2020) Grandes quantidades de horas extras são aceitáveis
em médio e longo prazo, para agilizar a entrega de requisitos.
Comentários:
Uma das práticas do XP é o ritmo sustentável! Grandes quantidades de horas extras não são
consideradas aceitáveis, pois – no médio prazo – há uma redução na qualidade do código e na
produtividade. Trabalhar por longos períodos se torna contraproducente – recomenda-se 40 horas
semanais.
Gabarito: Errado
3. (CESPE / Ministério da Economia – 2020) Como forma de agilizar as implantações de

novas releases nesse modelo, são acumulados grandes grupos de funcionalidades e
implantadas grandes releases.
Comentários:

43089971860 -1644786
Uma das práticas do XP são as pequenas releases! O conjunto mínimo útil de funcionalidade que
agrega valor ao negócio é desenvolvido primeiro. Releases do sistema são frequentes e adicionam
funcionalidade incrementalmente ao primeiro release.
Gabarito: Errado
4. (CESPE / Ministério da Economia – 2020) Os programadores trabalham em pares para que um

possa verificar e apoiar o trabalho do outro e, assim, realizem um bom trabalho.
Comentários:
Uma das práticas do XP é a programação em pares! Os desenvolvedores trabalham em pares, um

verificando o trabalho do outro e fornecendo apoio para realizar sempre um bom trabalho. Eles
utilizam o mesmo mouse, teclado e monitor.
Gabarito: Correto
5. (CESPE / Ministério da Economia – 2020) O refactoring de código não faz parte do modelo XP,
visto que a expectativa é a entrega ágil, e não deve ser considerada em tempo de projeto a
recriação de código para aprimoramento.
Comentários:
Uma das práticas do XP é a refatoração! Espera-se que todos os desenvolvedores recriem o código
continuamente tão logo os aprimoramentos do código forem encontrados. Isso torna o código
simples de entender e fácil de manter.
Gabarito: Errado
6. (CESPE / Ministério da Economia – 2020) O XP possui planejamento incremental com

requisitos registrados em histórias.
Comentários:
No eXtreme Programming, todos os requisitos são expressos como cenários (também chamados
histórias do usuário), que são implementados diretamente como uma série de tarefas.
Gabarito: Correto
7. (IBFC / TRE-PA – 2020) Para aplicar valores e princípios do XP (Extreme Programming), durante
os processos e práticas ágeis de desenvolvimento de software, se propõe uma série específica
de práticas. Assinale a alternativa que apresenta algumas dessas "boas práticas" utilizadas
tradicionalmente em projetos, usando XP.

43089971860 -1644786
a) Reformation - Pair Programming - PlayStation Game

b) Refactoring - Pair Programming - Planning Game
c) Reformation - Pair Production - Planning Game
d) Refactoring - Pair Production - PlayStation Game
Comentários:
- Não existe prática chamada reformation e, sim, refactoring;

- Não existe prática chamada pair production e, sim, pair programming;
- Não existe prática chamada Playstation game e, sim, planning game.
Logo, trata-se de: Refactoring, Pair Programming e Planning Game.
Gabarito: Letra B
8. (UFCG / UFCG – 2019) Marque a alternativa INCORRETA com relação a Extreme

Programming (XP).
a) Comunicação, coragem e respeito são valores dessa metodologia.

b) Em XP, uma das regras é codificar os testes de unidade primeiro.
c) Refatoramento é uma prática recomendada nesse processo.
d) O código a ser enviado para produção é criado por duas pessoas trabalhando juntas em um
único computador.
e) O autor, Don Wells, exige que o processo seja seguido à risca, de forma que todas suas regras
devem ser respeitadas e, nenhum projeto pode ser realizado sem adaptações e/ou remoção
dessas regras.
Comentários:
(a) Correto. Todos são valores do XP; (b) Correto. primeiro se escreve o teste, depois faz-se a
implementação; (c) Correto. A refatoração é uma prática recomendada no XP; (d) Correto. No XP,
o desenvolvimento ocorre em pares; (e) Errado. Pelo contrário, organizações não precisam seguir
tudo à risca – podem adaptar o processo.
Gabarito: Letra E
9. (IDECAN / UNIVASF – 2019) Extreme Programming (XP), em sua essência, possui um conjunto
de regras que devem ser seguidas em projetos ágeis que queiram utilizá-la em sua completude.
Sobre as regras do XP, assinale a alternativa correta.
a) Apenas as operações mais críticas devem possuir testes unitários.

b) Todo o código-fonte de produção deve ser implementado em programação em pares.

43089971860 -1644786
c) A integração de código deve ser feita nos computadores dos desenvolvedores.

d) É importante estabelecer o papel de um XP Master, que será responsável pela implementação
da metodologia.
e) A velocidade do projeto deve ser medida com o objetivo de informar ao cliente o tempo médio
de correção de falhas.
Comentários:
(a) Errado. No XP, são desenvolvidos testes para cada uma das tarefas; (b) Correto. No XP, uma das
características é a programação em pares; (c) Errado. A integração de código é feita em um sistema;
(d) Errado. Não há o papel de XP Master no XP; (e) Errado. No XP, o envolvimento do cliente é em
tempo integral.
Gabarito: Letra B
10. (CESGRANRIO / UNIRIO – 2019) Uma das principais práticas de XP (Extreme Programming) é
o Iteration Planning Game. Entre as atividades realizadas em uma sessão de Iteration Planning,
está a:
a) definição, pelos programadores, de quais story cards serão implementados em uma iteração.
b) estimação do esforço que será necessário para implementar cada story card.
c) estimação da data de entrega de um release baseado na estimativa de esforço de cada story
card.
d) estimação, feita por cada programador, do tempo que será necessário para realizar cada
tarefa sob sua responsabilidade.
e) designação, por parte do coach, dos programadores que irão realizar as tarefas contidas na
lista de tarefas.
Comentários:
(a) Errado. Na verdade, essa definição é feita pelos clientes; (b) Errado. Ocorre estimação do tempo
e, não, do esforço; (c) Errado, não existe a estimativa do esforço; (d) Correto. Cada programador
estima o tempo de suas tarefas; (e) Errado. Não existe a figura do coach no XP.
Gabarito: Letra D
11. (CESPE / TCE-RO – 2019) No que diz respeito a processos e práticas ágeis, o desenvolvimento
incremental
a) é, assim como o test-driven development, uma prática da XP (Extreme Programming) que

exige teste automatizado, domain-driven design, refactoring e integração contínua.

43089971860 -1644786
b) é, na XP (Extreme Programming), sustentado por meio de pequenos e frequentes releases do

sistema, e os clientes estão intimamente envolvidos na especificação e na priorização dos
requisitos do sistema.
c) enfoca, assim como o acceptance test-driven development, a qualidade do código

desenvolvido quanto a recursividade, declaração das variáveis e clean code, de modo a torná-lo
de fácil entendimento, modificação e testagem
d) pressupõe o uso do behavior driven development, que considera a linguagem de

programação a ser usada, da 4.ª geração em diante, com foco, principalmente, no
comportamento visual, interativo e cognitivo do sistema.
e) enfoca a integração contínua como uma prática de desenvolvimento de software,

incompatível com a XP (E xtreme Programming) e o Scrum, que permite aos desenvolvedores
agregarem alterações de código e realizarem testes.
Comentários:
(a) Errado. Esse item é bastante confuso, o desenvolvimento incremental não exige o domain-
driven design (DDD); (b) Correto. No XP, o envolvimento do cliente ocorre em tempo integral,
facilitando o desenvolvimento e a melhora do produto; (c) Errado. Na verdade, trata-se do TDD; (d)
Errado. Ele não pressupõe o uso do Behavior Driven Development; (e) Errado. A integração
contínua não é incompatível com o XP e com o Scrum.
Gabarito: Letra B
12. (FCC / SANASA Campinas – 2019) Em um projeto de software baseado na metodologia ágil XP,
um Analista de TI deve
a) consultar o cliente quando uma história exigir, por estimativa, menos do que 3 semanas de
desenvolvimento, para que o cliente a complemente com mais tarefas.
b) ouvir o cliente, durante o levantamento de requisitos, para que este crie as histórias de
usuários. Após essa importante etapa nenhuma história nova deve ser criada para não
comprometer o cronograma do projeto.
c) evitar que o projeto caia na armadilha de seguir o princípio KISS de forma a estimular que o
projeto de uma funcionalidade extra, que poderá ser necessária no futuro, faça parte do modelo
do software.
d) realizar os testes de unidade de forma manual, evitando que sejam usadas baterias de testes
automatizados, pois estes impedem a realização de testes de regressão.

43089971860 -1644786
e) estimular o uso de cartões CRC como um mecanismo eficaz para pensar o software em um
contexto orientado a objetos.
Comentários:
Para Pressman: “A XP estimula o uso de cartões CRC como um mecanismo eficaz para pensar o
software em um contexto orientado a objetos. Os cartões CRC (classe-responsabilidade-colaborador)
identificam e organizam as classes orientadas a objetos relevantes para o incremento de software
corrente”.
Gabarito: Letra E
13. (INSTITUTO AOCP / UFPB – 2019) Um dos principais métodos ágeis de desenvolvimento de
software foi concebido para impulsionar práticas reconhecidas como boas, por exemplo, o
desenvolvimento iterativo a nível extremo, em que novas versões de um determinado sistema
podem ser implementadas, integradas e, até mesmo, testadas em um único dia por
programadores diferentes. Essa é uma das características de qual método de desenvolvimento
ágil de software?
a) Scrum.
b) Adaptative Software Development.
c) Extreme Programming.
d) Pramatic Programming.
e) Test Driven Development.
Comentários:
O método de desenvolvimento ágil que permite o desenvolvimento iterativo a nível extremo, em

que novas versões de um determinado sistema podem ser implementadas, integradas e, até
mesmo, testadas em um único dia por programadores diferentes é o Extreme Programming.
Gabarito: Letra C
14. (FCM / Prefeitura de Caranaíba - MG – 2019) De acordo com Pressman e Maxim (2016), a
Programação Extrema (Extreme Programming – XP) é uma abordagem amplamente utilizada
do desenvolvimento ágil de software que consiste das atividades:
a) Planejamento (Planning) / Projeto (Designing) / Codificação (Coding) / Teste (Test).

b) Colaboração (Collaboration) / Projeto (Designing) / Codificação (Coding) / Teste (Test).
c) Colaboração (Collaboration) / Projeto (Designing) / Codificação (Coding) / Teste (Test) /
Adaptação (Adaptation).
d) Colaboração (Collaboration) / Projeto (Designing) / Codificação (Coding) / Teste (Test) /
Adaptação (Adaptation) / Melhoria (Improvement).

43089971860 -1644786
Comentários:
Trata-se do Planejamento (Planning), Projeto (Designing), Codificação (Coding) e Teste (Test).
Gabarito: Letra A
15. (VUNESP / Câmara de Piracicaba - SP – 2019) Um dos processos ágeis de desenvolvimento

de software é a programação extrema (extreme programming – XP), cuja fase ou atividade
inicial é composta pela descrição dos cenários (características e funcionalidades) requisitadas
para o software a ser desenvolvido. Essa atividade recebe a denominação de:
a) métodos práticos.
b) histórias de usuário.
c) estruturas de apoio.
d) classes de projeto.
e) artefatos de usuário
Comentários:
De acordo com Sommerville, a primeira atividade do ciclo de uma release é “selecionar histórias de
usuário para esta release” – não é exatamente o nome da atividade, mas é o que mais se aproxima!
Gabarito: Letra B
16. (CESPE / TJ-AM – 2019) No XP (Extreme Programming), o valor de uma história de usuário é
atribuído pelos membros da equipe e é medido em termos de semanas estimadas para o
desenvolvimento.

43089971860 -1644786
Comentários:
No Extreme Programming, cada história é escrita pelo cliente e é colocada em uma ficha! O cliente
atribui um valor (prioridade) à história baseando-se no valor de negócio global do recurso/função.
Os membros da equipe XP avaliam cada história e atribuem um custo a ela medido em semanas de
desenvolvimento. Logo, quem atribui um valor é o cliente e, não, os membros da equipe.
Gabarito: Errado
17. (INSTITUTO AOCP / ADAF - AM – 2018) Na metodologia ágil Extreme Programming (XP), a
propriedade do código é coletiva, dessa forma, todos compartilham o mesmo orgulho e as
mesmas críticas. Considerando o exposto, assinale a alternativa que apresenta uma das regras
da codificação em XP.
a) No Overtime.
b) Eliminar gargalos de hardware no início.
c) O usuário não deve participar do planejamento das interfaces.
d) No Outsourcing.
e) No Sprint.
Comentários:
O XP tem como uma de suas práticas o ritmo sustentável, dessa forma, grandes quantidades de
horas extras não são consideradas aceitáveis. Overtime está relacionado a horas extras, dessa
forma, é uma prática que não deve ser adotada. As demais alternativas não têm relação com o XP.
Gabarito: Letra A
18. (AOCP / SUSIPE-PA – 2018) Sobre as práticas do XP (Extreme Programming), assinale a

alternativa INCORRETA.
a) O cliente deve conduzir o desenvolvimento a partir do feedback que recebe do sistema.

b) O código deve ser padronizado, visando tornar o sistema mais homogêneo.
c) O XP trabalha com releases curtos, buscando a integração contínua de valor para o cliente.
d) O XP trabalha com código coletivo, no qual todos os membros da equipe têm acesso ao
código.
e) O XP utiliza-se de programação em par para permitir que o código seja revisado
permanentemente enquanto é desenvolvido.
Comentários:

43089971860 -1644786
A banca deu a alternativa (d) como incorreta, mas eu acredito que caberia recurso. O XP valoriza o
trabalho em equipe e, por isso, o código fonte pertence à equipe – as demais alternativas são
também práticas adotadas no XP.
Gabarito: Letra D
19. (COMPERVE / UFRN – 2018) Programação Extrema (XP - Extreme Programming) é uma das
principais metodologias ágeis já propostas. A respeito de XP, considere as afirmativas abaixo.
I XP promove a execução de testes automatizados de avaliação do desempenho a cada iteração

de desenvolvimento do sistema.
II Em XP, os requisitos do sistema são especificados através de casos de uso.
III A prática de integração contínua do XP envolve a geração frequente de versões (builds) do
sistema, assim como execução dos testes automatizados sobre as versões geradas.
IV A prática de refatoração do XP envolve a modificação interna do código de classes do sistema,
mas sem modificar seu comportamento externo (interfaces dos métodos).
Estão corretas as afirmativas
a) III e IV.
b) I e II.
c) I e III.
d) II e IV.
Comentários:
(I) Errado. Testes automatizados são realizados a cada entrega; (II) Errado. No XP, os requisitos de
sistema são especificados por meio de histórias de usuários; (III) Correto. O XP adota a prática de
integração contínua e de testes automatizados; (IV) Correto. O XP utiliza a refatoração como uma
de suas práticas.
Gabarito: Letra A
principais metodologias ágeis já propostas. Considere as seguintes afirmativas a respeito de
suas práticas.
I A técnica de refatoração promove mudanças no código que visam à adição de novas

funcionalidades.
II XP determina a produção de um executável do sistema desenvolvido a cada iteração.
III XP motiva a criação de projetos simples onde requisitos futuros não são inicialmente
contemplados.
IV Integração contínua consiste na geração de builds diários do sistema.

43089971860 -1644786
a) II e IV.
b) I e IV.
c) I e III.
d) II e III.
Comentários:
(I) Errado. A refatoração é a modificação interna do código sem alterar seu comportamento
externo; (II) Correto. Refere-se à prática do lançamento de pequenos releases; (III) Correto. De fato,
uma das práticas adotadas pelo XP é a dos projetos simples; (IV) Errado. Logo que o trabalho em
uma tarefa é concluído, ele é integrado ao sistema, mas não há essa relação com builds diários.
Gabarito: Letra D
21. (IF-RS / IF-RS – 2018) Sobre as práticas encontradas na metodologia ágil de desenvolvimento
de software, conhecida por Programação Extrema (XP Programming), de acordo com Dooley
(2017) no livro Software Development, Design and Coding, classifique cada uma das afirmativas
abaixo como verdadeira (V) ou falsa (F) e assinale a alternativa que apresenta a sequência
CORRETA, de cima para baixo:
( ) Participação intensa do representante do cliente no desenvolvimento do projeto.
( ) Testes são realizados continuamente. Quando todos os testes forem aprovados, o módulo foi
concluído.
( ) Programação em par: enquanto um escreve o código, o outro monitora falhas, realiza testes,
faz sugestões e planeja próximas ações.
( ) Lançamentos frequentes de novas versões.
a) F – V – V – F
b) V – F – F – V
c) V – V – F – V
d) V – V – V – V
e) F – F – V – V
Comentários:
No XP, temos o envolvimento em tempo integral do cliente, por isso o item I é verdadeiro. O
segundo item também é verdadeiro e está de acordo com a prática da Integração Contínua. O

43089971860 -1644786
terceiro item também é verdadeiro, de fato, no XP é adotada a prática da programação em pares.

Por fim, o último item também é verdadeiro e remete à prática de pequenos releases.
Gabarito: Letra D
22. (IADES / ARCON-PA – 2018) Um dos métodos de desenvolvimento de software mais

conhecido e utilizado é o extreme programming (XP). Esse consiste em um modelo:
a) que evita a refatoração de código.

b) que realiza testes de integração apenas ao final de todo o desenvolvimento.
c) que valoriza o trabalho de forma individualizada, evitando a programação em pares.
d) que busca atender às necessidades atuais, e nada mais.
e) no qual não se faz necessária a disponibilidade de um representante do cliente a todo o
tempo.
Comentários:
(a) Errado, o XP utiliza a refatoração; (b) Errado, utiliza durante todo o desenvolvimento; (c) Errado,
valoriza a propriedade coletiva e a programação em pares; (d) Correto, de fato, busca atender as
necessidades atuais; (e) Errado, o envolvimento do cliente ocorre em tempo integral.
Gabarito: Letra D
23. (CESPE / ABIN – 2018) Na extreme programming, como não há especificação de sistema que
possa ser usada por equipe de teste externa, a característica de test-first exige que os
implementadores de tarefa compreendam detalhadamente a especificação de comportamento
da funcionalidade em desenvolvimento, a fim de que possam escrever o teste para o sistema.
Comentários:
Pessoal, vimos que umas das principais práticas do XP é a do Desenvolvimento Test-First. Essa
prática faz uso de testes unitários para cada funcionalidade, além disso, os testes devem ser escritos
antes da implementação da funcionalidade e para isso os implementadores devem conhecer
detalhadamente as especificações da funcionalidade que está sendo desenvolvida.
Gabarito: Correto
24. (FCC / DPE-AM – 2018) Considere a definição de algumas práticas da eXtreme Programming −
XP.

43089971860 -1644786
I. Todo o código desenvolvido pelo time é incorporado em um repositório comum várias vezes
ao dia. Isso garante que qualquer problema de integração ao longo do projeto possa ser notado
e corrigido rapidamente.
II. Qualquer programador do time pode alterar qualquer seção do código, se necessário. Por
mais que esta prática pareça perigosa, ela aumenta a velocidade do desenvolvimento e
problemas em potencial podem ser detectados pelos testes de unidade.
III. Traz a ideia de que qualquer pessoa do time seja capaz de verificar o código sendo
desenvolvido em alto nível e ter uma compreensão clara de qual funcionalidade do sistema está
sendo trabalhada.
IV. Permite aplicar melhorias ao código sem mudar sua funcionalidade, visando sua
simplificação. Se o cliente deseja alterar alguma coisa no produto final, o time pode fazer os
ajustes rapidamente, e esta prática contribui para alcançar este objetivo.
As práticas de I a IV são, correta e respectivamente,
a) pair programming – test-driven development – system metaphor – continuous integration.

b) planning game – pair programming – system simplicity – continuous integration.
c) planning game – test-driven development – system simplicity – refactoring.
d) continuous integration – pair programming – feedback – planning game.
e) continuous integration – collective code ownership – system metaphor – refactoring.
Comentários:
(I) Trata-se da prática de Integração Contínua, que diz que tão logo o trabalho em tarefa seja
concluído, este é integrado ao sistema, são também realizados testes unitários; (II) Trata-se da
prática da Propriedade Coletiva do Código, ou seja, o código pertence a todos os integrantes da
equipe, além disso, essa prática aumenta a velocidade de desenvolvimento; (III) Trata-se da prática
das Metáforas, que visa facilitar a comunicação entre os membros da equipe, de forma que sejam
transmitidas ideias complexas de maneira simples; (IV) Por fim, melhorar o código sem afetar o
comportamento externo do sistema, trata-se da prática de refatoramento.
Gabarito: Letra E
25. (FAURGS / TJ-RS – 2018) Considere as seguintes afirmações sobre princípios ou práticas da XP
(Extreme Programming).
I - Um representante do usuário final do sistema (cliente) deve estar disponível todo o tempo à
equipe de XP. Em um processo de Extreme Programming, o cliente é um membro da equipe de
desenvolvimento e é responsável por levar ao grupo os requisitos de sistema para
implementação.

43089971860 -1644786
II - Todos os desenvolvedores devem refatorar o código continuamente, assim que encontrarem

oportunidades de melhorias de código.
III - Os desenvolvedores trabalham em todas as áreas do sistema, de modo que não se

desenvolvam ilhas de expertise. Todos os desenvolvedores têm responsabilidade em relação ao
código; qualquer um pode mudar qualquer coisa.
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) Perfeito! Trata-se do Client On-Site, ou seja, o cliente no local de trabalho, junto dos
desenvolvedores.
(II) Isso mesmo! A Refatoração também é uma prática recomendada pelo XP – sempre que o
desenvolvedor encontrar uma oportunidade de refatorar o código, recomenda-se fazê-lo.
(III) Corretíssimo! As equipes devem ser multidisciplinares – todo mundo modela, desenvolve, testa,
implanta, etc. Sem ilhas de expertise porque isso pode causar dependência de um determinado
membro da equipe.
Gabarito: Letra E
26. (FUNRIO / Câmara de São João de Meriti - RJ – 2018) A figura abaixo ilustra a metodologia
Extreme Programming (XP) que usa uma abordagem orientada a objetos, incluindo um
conjunto de regras e práticas que ocorrem ao longo do desenvolvimento do projeto.

43089971860 -1644786
As fases I, II, III e IV são denominadas respectivamente:
a) modelagem, construção, implantação e homologação.

b) planejamento, construção, codificação e homologação.
c) planejamento, projeto, implantação e teste.
d) planejamento, projeto, codificação e teste.
e) modelagem, projeto, codificação e homologação.
Comentários:
As fases são planejamento, projeto, codificação e teste.
Gabarito: Letra D

43089971860 -1644786
27. (INSTITUTO AOCP / PRODEB – 2018) O método de desenvolvimento ágil denominado de XP

(Extreme Programming) tem sua estrutura baseada em algumas prerrogativas, dentre as quais,
é correto citar como princípios do XP:
a) Princípio da Legalidade, Princípio da Agilidade e Princípio do Feedback.

b) Princípio da Coragem, Princípio da Agilidade e Princípio da Simplicidade.
c) Princípio da Comunicação, Princípio da Simplicidade, Princípio do Feedback e Princípio da
Coragem.
d) Princípio da Agilidade, Princípio da Qualidade, Princípio do Feedback e Princípio da Coragem.
e) Princípio da Simplicidade, Princípio do Desenvolvimento e Princípio de Governança.
Comentários:
VALORES
DESCRIÇÃO
FUNDAMENTAIS
Para se desenvolver um sistema de software, exige-se comunicar os requisitos de sistema para os
desenvolvedores. Em metodologias formais de desenvolvimento de software, esta tarefa é
COMUNICAÇÃO realizada por meio de documentação. O Extreme Programming favorece projetos simples,
XP incentiva que se comece com a solução mais simples. Funcionalidades adicionais podem ser
acrescentadas posteriormente. Alega-se que desenvolver funções que não são necessárias hoje
SIMPLICIDADE pode ser prejudicial, na medida em que futuramente essa função pode não ser mais útil.
Codificação e projeto de necessidades futuras incertas implicam o risco de gastar recursos em algo
não mais necessários, embora talvez atrasando aspectos cruciais.
FEEDBACK desenvolvimento de testes, eles podem dar um feedback instantâneo. Dessa forma, o cliente pode
orientar o desenvolvimento em uma possível recodificação do sistema. Quando o cliente traz um
novo requisito, recebe um feedback de tempo e orçamento.
A coragem permite que os desenvolvedores se sintam confortáveis com ao refatorar o seu código,
quando necessário. Eventualmente, há de se ter coragem para jogar fora um código ou para
CORAGEM remover um código obsoleto, não importa quanto esforço e tempo se gastou para produzi-lo. Além
disso, coragem significa persistência, pois um programador pode se encontrar preso em um
problema complexo durante um dia inteiro sem conseguir resolver.
Aqui se inclui o respeito pelos outros, assim como o auto-respeito. Membros devem respeitar seu
próprio trabalho, sempre se esforçando para oferecer alta qualidade e buscando o melhor projeto
RESPEITO para a solução através de refatoração. Ninguém na equipe deve se sentir desvalorizado ou
ignorado. Isso garante um alto nível de motivação e incentiva a lealdade dentro da equipe. Este
valor é muito dependente dos outros valores.
Na verdade, o ideal seria chamar de valores fundamentais e, não, princípios do XP. De toda forma,
trata-se do princípio da comunicação, princípio da simplicidade, princípio do feedback e princípio
da coragem.
Gabarito: Letra C

43089971860 -1644786
28. (INSTITUTO AOCP / PRODEB – 2018) O Pair Programming (Programação em Pares) é uma
característica de um determinado método de desenvolvimento de software em que dois
programadores trabalham juntos no desenvolvimento de um código. Qual foi o método que
criou essa prática?
a) Lean.
b) XP.
c) Scrum.
d) FDD.
e) Cascata.
Comentários:
O método ágil que criou essa prática foi o XP!
Gabarito: Letra B
29. (INSTITUTO AOCP / UFOB – 2018) Uma das práticas do Extreme Programming é o uso do
código coletivo, na qual todos os desenvolvedores têm acesso ao código.
Comentários:
De fato, essa é uma das práticas do XP! Os pares de desenvolvedores trabalham em todas as áreas
do sistema, de tal maneira que não se formem ilhas de conhecimento, com todos os
desenvolvedores de posse de todo o código. Qualquer um pode mudar qualquer coisa.
Gabarito: Correto
30. (IBADE / IPM - JP – 2018) Metodologias ágeis podem ser aplicadas para facilitar a adaptação do
processo de desenvolvimento de software a mudanças. Trata-se de uma abordagem de
desenvolvimento de software ágil amplamente conhecida e utilizada, denominada:
a) desenvolvimento direto.
b) modelagem extrema.
c) programação dinâmica.
d) modelagem direta.
e) programação extrema.
Comentários:
A única alternativa que apresenta uma abordagem de desenvolvimento de software ágil

amplamente conhecida e utilizada é a programação extrema (ou extreme programming).

43089971860 -1644786
Gabarito: Letra E
31. (INSTITUTO AOCP / PRODEB – 2018) Extreming Programming (XP) é um método de

desenvolvimento ágil amplamente utilizado pelas software houses. Com base neste método,
qual alternativa a seguir possui uma prática que NÃO faz parte do XP?
a) Small Releases (Pequenas Entregas).

b) Pair Programming (Programação em Pares).
c) Sprint Review (Reunião de revisão da Sprint).
d) Sustainable Pace (Ritmo Saudável).
e) Collective Owership (Posse Coletiva).
Comentários:
Todas as alternativas apresentam práticas do XP, exceto sprint review – que é uma cerimônia do
Scrum e, não, do XP.
Gabarito: Letra C
32. (CESPE / BNB – 2018) Em XP, a técnica de planning game é utilizada pelo cliente para identificar
as prioridades do que deve ser construído em um software, sem a participação dos
desenvolvedores.
Comentários:
Uma das práticas do XP é o jogo do planejamento. Nessa prática, o planejamento de uma release e
das iterações são feitos com base nas histórias e conta com a colaboração de toda equipe de
desenvolvimento, inclusive o cliente, divididos em papeis: negócio e técnico. Os clientes priorizam
e os desenvolvedores avaliam e estimam.
Gabarito: Errado
33. (CESPE / ABIN – 2018) O ritmo ágil de desenvolvimento de softwares é uma prática usada para
favorecer a entrega das releases quando grandes volumes de horas extras são tolerados.
Comentários:
Não se trata de ritmo ágil e, sim, ritmo sustentável! Grandes quantidades de horas extras não são
consideradas aceitáveis, pois, no médio prazo, há uma redução na qualidade do código e na
produtividade. Trabalhar por longos períodos se torna contraproducente – recomenda-se 40 horas
semanais).

43089971860 -1644786
Gabarito: Errado
34. (CESPE / ABIN – 2018) Para apoiar a equipe de desenvolvimento, é uma prática o uso do
cliente on-site em tempo integral.
Comentários:
De fato, cliente on-site é uma prática do XP. Um representante do usuário final do sistema deve
estar disponível em tempo integral para apoiar a equipe. No XP, o cliente é um membro da equipe
de desenvolvimento e é responsável por trazer os requisitos do sistema.
Gabarito: Correto
35. (CESPE / STM – 2018) Na XP (Extreme Programming), programadores trabalham em pares, e

requisitos são expressos como cenários, denominados histórias de usuários, os quais são
implementados como uma série de tarefas.
Comentários:
A programação em pares é uma das práticas do XP. Além disso, requisitos realmente são expressos
como cenários ou histórias de usuário, que são implementados como uma série de tarefas.
Gabarito: Correto
36. (FCC / TST – 2017) Uma dupla de programadores, utilizando o modelo Extreme Programming −
XP, realiza, na fase de:
a) desenvolvimento, a implementação das user stories que fazem parte da iteração corrente.
b) desenvolvimento, a entrega das user stories totais do sistema.
c) validação do sistema, a análise dos requisitos técnicos entregáveis.
d) validação do sistema, a integração total dos incrementos das user stories.
e) projeto da arquitetura do sistema, a implementação das user stories totais do sistema.
Comentários:
No XP, todos os requisitos são expressos como histórias do usuário, que são implementados
diretamente como uma série de tarefas. Além disso, essa implementação ocorre na fase de
desenvolvimento.
Gabarito: Letra A
37. (CESPE / TRT - 7ª Região (CE) – 2017) Acerca de metodologia XP, assinale a opção correta.

43089971860 -1644786
a) Para atingir a agilidade necessária, a equipe de desenvolvimento deve ser composta de

pessoas com experiência comprovada na linguagem utilizada.
b) A prática de planning game do XP permite que o escopo do projeto seja alterado a cada
semana.
c) Mesmo sendo considerada uma metodologia ágil, XP exige uma especificação completa e
formal dos requisitos.
d) Em XP, denomina-se explanação o processo por meio do qual uma pessoa tenta explicar um
assunto fazendo comparações com o mundo real.
Comentários:
(a) Errado, não há esse requisito; (b) Correto, vimos que no XP a prática do planning game é
realmente adotada; (c) Errado, um projeto XP tem especificações simples; d) Errado, trata-se das
metáforas.
Gabarito: Letra B
38. (IBFC / TJ-PE – 2017) Está sendo implementado o XP (eXtreme Programming) em uma equipe
de TI. Para tanto, está sendo colocada a seguinte série de práticas específicas da metodologia
XP em análise:
I. Programação Pareada (Pair Programming).

II. Fases pequenas (Small Releases).
III. Refatoração (Refactoring).
IV. Jogo de Planejamento (Planning Game).
Com base no seu conhecimento sobre a metodologia citada acima, suas práticas específicas
estão corretamente relacionadas nos itens:
a) I, II e III, apenas
b) I, II e IV, apenas
c) II, III e IV, apenas
d) I, III e IV, apenas
e) I, II, III e IV
Comentários:
O XP utiliza como prática a programação em pares, pequenos releases, refatoração e o jogo do

planejamento – todos os itens estão corretos.
Gabarito: Letra E

43089971860 -1644786
39. (FCC / DPE-RS – 2017) Considere que um Analista esteja participando de um projeto que utiliza
as melhores práticas da Extreme Programming − XP. No início de uma iteração a equipe de
desenvolvimento, da qual o Analista fazia parte, convidou o cliente a escrever as funcionalidades
que desejava no sistema em pequenos cartões chamados user stories. Depois disso, a equipe de
desenvolvimento estimou o tempo e o custo de cada funcionalidade para o cliente. O cliente foi
informado do tempo e custo, e foi solicitado a decidir a prioridade em que cada user
story deveria ser desenvolvida. Esta prática XP é conhecida como:
a) Releases e é utilizada para que o cliente possa utilizar o sistema, possibilitando à equipe de
desenvolvimento saber se há defeitos ou não no código.
b) Releases e visa reorganizar o código fonte para melhorar sua qualidade interna, facilitar seu
entendimento pelo cliente e diminuir o tempo gasto com manutenção.
c) Metáforas e permite que o cliente transmita ideias complexas de forma simples e clara,
usando um vocabulário comum.
d) Planning Game e permite que o Analista e outro desenvolvedor escolham uma user story e
codifiquem juntos aquela funcionalidade.
e) Planning Game e busca assegurar que a equipe esteja sempre trabalhando no que é mais
importante e gere mais valor para o cliente.
Comentários:
O cliente escreve as funcionalidades em um cartão chamado user stories: trata-se da prática do jogo
do planejamento (planning game). Ou seja, o planejamento dos releases e das iterações é feito com
base nas prioridades do cliente, o trabalho dos desenvolvedores é avaliar e estimar as entregas
dessas prioridades.
Gabarito: Letra E
40. (CESPE / TRE-BA – 2017) Considerando uma situação hipotética com o uso da XP (eXtreme
Programming) concomitante com Scrum em um projeto de desenvolvimento de software em
uma organização, julgue os seguintes itens.
I. É viável a utilização do TDD (Test Driven Development) na fase de sprint, de modo que se
escreva o teste automático antes da codificação.
II. O princípio da integração contínua da XP deve ser utilizado especificamente na retrospectiva

da sprint com vistas a integrar a equipe scrum.

43089971860 -1644786
III. Integrantes da equipe scrum podem realizar a programação do código em pares, o que
proporciona, entre outras vantagens, o nivelamento de conhecimento da equipe.
IV. O conceito de requisito “pronto” continuaria válido, contudo, inviabilizaria o refactoring, pois
é proibitivo inserir o mesmo item (requisito) em várias sprints.
Estão certos apenas os itens:
a) I e II.
b) I e III.
c) II e IV.
d) I, III e IV.
e) II, III e IV
Comentários:
(I) Correto. TDD é uma prática XP em que se escreve o teste antes de escrever o código do
componente e é viável utilizá-lo em uma Sprint; (II) Errado. A Integração Contínua é uma prática
XP, mas não se integra a equipe, integram-se componentes e não deve ser utilizado na
retrospectiva da sprint, mas na sprint em si; (III) Correto. A Programação em Pares é uma prática
XP e evidentemente proporciona o nivelamento de conhecimento da equipe; (IV) Errado.
Refatoração é uma prática XP, mas não é proibido inserir o mesmo requisito em várias sprints.
Gabarito: Letra B
41. (UFG / SANEAGO – 2017) Dentro do framework Extreme Programming (XP), uma metodologia
ágil, a ação de teste de código é responsabilidade da pessoa:
a) diretamente ligada à criação do artefato em questão.

b) responsável pela equipe de teste de software, que não pode ser a pessoa que o desenvolve.
c) utilizadora do código diariamente.
d) facilitadora da comunicação entre a equipe de desenvolvimento e o cliente.
Comentários:
(a) Errado. Regra clássica: quem desenvolve, não teste e quem testa, não desenvolve! Logo, a ação
de teste não é de responsabilidade ad pessoa diretamente ligada à criação do artefato; (b) Errado,
lembrem-se que no XP a equipe é multidisciplinar, logo não existe uma equipe dedicada de testes;
(c) Errado, não é o cliente que testa – ele apenas homologa posteriormente; (d) Errado, o teste é
realizado pelos desenvolvedores de outras funcionalidades.
Questão anulada sob a justificativa de que o tema não constava do Edital, porém a razão verdadeira
– na minha opinião – é que de que não há resposta correta.

43089971860 -1644786
Gabarito: Anulada
42. (CESPE / TRE-TO – 2017) Em projetos de desenvolvimento de software, a extreme

programming (XP) é um método ágil que usa a prática de:
a) projetos com planejamento completo sem incrementos.

b) grandes releases.
c) grande quantidade de horas extras.
d) trabalho em pares de desenvolvedores.
e) integrações após a entrega do software completo.
Comentários:
(a) Errado, planejamento incremental e, não, completo; (b) Errado, pequenas releases e, não,
grandes; (c) Errado, ritmo sustentável e, não, grande quantidade de horas extras; (d) Correto; (e)
Errado, integração contínua e, não, após a entrega do software completo.
Gabarito: Letra D
43. (IBFC / EBSERH – 2017) Dentro das práticas do XP (eXtreme Programming) existe uma
fundamental que é o Jogo de Planejamento (Planning Game). Para serem realizadas
adequadamente essas reuniões com os usuários, deve(m) ter sido feito(s) antecipadamente:
a) o Sustainable Pace
b) as Small Releases
c) os Customer Tests
d) as User Stories
e) um Simple Design
Comentários:
Antes de fazer reuniões com os usuários para o jogo do planejamento, deve-se fazer
antecipadamente as user stories (histórias de usuário). Caso contrário, não é possível priorizar!
Gabarito: Letra D
44.(FCC / CREMESP – 2016) Considere que nos projetos do CREMESP baseados em XP pratica-se
a propriedade coletiva de código, de forma que todos os desenvolvedores podem fazer
alterações e refatoração de qualquer parte do código a qualquer momento. Para isso, é
necessário que também haja:
a) padrões de codificação.

43089971860 -1644786
b) time-box de 40 horas.
c) testes apenas depois da codificação.
d) releases grandes.
e) integração das funcionalidades, mesmo com erros.
Comentários:
A codificação é a principal atividade no XP, além disso, os programadores trabalham em pares e a

propriedade do código é coletiva. Por isso, é necessário que haja uma padronização na elaboração
do código.
Gabarito: Letra A
45. (COPEVE-UFAL / UFAL – 2016) Assinale a alternativa que contém apenas características ou
práticas relacionadas ao método ágil para desenvolvimento de softwares Extreme
Programming (XP):
a) Planejamento incremental, cliente disponível em tempo integral e programação em pares.

b) Requisitos expressos como cenários, programação incremental e programação individual.
c) Cliente não participa do desenvolvimento, desenvolvimento em cascata e programação em
pares.
d) Equipe heterogênea especializada, requisitos expressos como histórias e desenvolvimento
em espiral.
e) Toda equipe altera qualquer parte do código, desenvolvimento em cascata e programação
individual.
Comentários:
(a) Correto. O XP utiliza uma abordagem incremental, o envolvimento do cliente ocorre em tempo
integral e também é adotada a prática da programação em pares; (b) Errado. A programação não é
individual; (c) Errado. O envolvimento do cliente ocorre em tempo integral; (d) Errado. Os requisitos
são expressos como histórias, mas as outras duas práticas não fazem sentido; (e) Errado. A
programação não é individual e não há relação com desenvolvimento em cascata.
Gabarito: Letra A
46.(IF-PE / IF-PE – 2016) Extreme Programming é uma metodologia ágil para equipes pequenas e
médias que desenvolvem software com requisitos vagos e em constante mudança. Sobre os
valores do XP, analise as definições abaixo e assinale a alternativa CORRETA.
a) Simplicidade - procura-se que a equipe concentre-se, primeiro, em fazer o necessário.

b) Comunicação - prioriza-se a troca de e-mail como melhor forma de comunicação,
independente do horário.

43089971860 -1644786
c) Coragem - a metodologia XP prega coragem para dizer “não” ao cliente e evitar mudanças do
projeto.
d) Feedback - é valorizado o feedback positivo do cliente. Desta forma, procura-se evitar a
entrega de software sem a realização de testes detalhados.
e) Respeito - prega o respeito à hierarquia, ouvindo e respeitando, apenas, o que é determinado
pelo líder de projeto.
Comentários:
(a) Correto. De fato, XP incentiva soluções mais simples, se preocupando primeiramente nas partes
essenciais; (b) Errado. O XP valoriza a comunicação verbal frequente; (c) Errado. Na verdade, a
coragem refere-se aos desenvolvedores se sentirem confortáveis ao realizarem mudanças no
código; (d) Errado. O cliente pode trazer um feedback, mas normalmente o feedback ocorre por
meio dos testes unitários ou de integração; (e) Errado. O respeito deve ser um valor amplo, e não
deve se limitar ao que é determinado pelo líder do projeto.
Gabarito: Letra A
47. (CESPE / FUNPRESP-JUD – 2016) Uma característica da metodologia XP é a existência de uma

equipe técnica voltada para a agilidade e velocidade do desenvolvimento do software, de forma
que todo o desenvolvimento seja feito sem a interferência ou ajuda do cliente até que
os releases sejam disponibilizados para que o desenvolvimento se torne o mais ágil possível.
Comentários:
No XP o envolvimento do cliente ocorre em tempo integral. O que isso significa? Significa que o
cliente pode interferir em qualquer etapa do desenvolvimento. Esse envolvimento em tempo
integral do cliente facilita o desenvolvimento e a melhora da qualidade do produto.
Gabarito: Errado
48.(FCC / Prefeitura de Teresina – PI – 2016) Os métodos ágeis de desenvolvimento

de software como eXtreme Programming – XP consideram um conjunto de valores
fundamentais derivados do manifesto ágil. Assim, estes métodos valorizam MENOS:
a) os indivíduos e a interação entre eles, do que os processos e ferramentas.

b) o software funcionando, do que uma documentação abrangente.
c) a colaboração com o cliente, do que negociação de contratos.
d) a resposta rápida a mudanças, do que seguir um plano previamente definido.
e) a rigorosidade dos processos, do que a adaptação às mudanças.
Comentários:

43089971860 -1644786
Primeiramente, vê se que a questão pede os fundamentos que o Manifesto Ágil valoriza menos. O
Manifesto Ágil valoriza mais a resposta às mudanças do que seguir um plano, por isso, ele valoriza
menos a rigorosidade dos processos do que a adaptação às mudanças. A rigorosidade dos
processos está mais ligada às metodologias tradicionais.
Gabarito: Letra E
49.(CESPE / TCE-PA – 2016) Em XP (Extreme Programming), as user stories não objetivam definir
o escopo global do sistema, mas avaliar a complexidade de cada uma de suas partes a fim serem
estimados prazos na perspectiva dos usuários ou clientes do sistema.
Comentários:
No XP, todos os requisitos são expressos como cenários (histórias dos usuários). Ou seja, as user
stories são uma descrição resumida de alguma funcionalidade, por isso não estão relacionadas ao
escopo global, mas sim a funcionalidades específicas. Além disso, as user stories permitem que se
avaliem a complexidade e que se defina as estimativas para as entregas aos clientes.
Gabarito: Correto
50. (UFCG / UFCG – 2016) Sobre XP (Extreme Programming), marque a assertiva INCORRETA.
a) É um processo criado por Kent Beck.

b) São exemplos de boas práticas do processo: desenvolvimento orientado a testes, pair
programming e documentação em todas as suas fases.
c) Esse processo almeja reduzir o custo de mudanças a partir de múltiplos ciclos de
desenvolvimento de curta duração.
d) Simplicidade ao projetar e programar é uma das chaves para o sucesso na visão do XP.
e) Nesse processo, deve-se refatorar o código sempre que possível.
Comentários:
(a) Correto, foi criado por Kent Beck em 1996; (b) Errado, apesar do XP ser orientado a testes e
adotar a prática da programação em pares, ele não tem como prática a documentação em todas as
fases; (c) Correto, o XP utiliza o desenvolvimento incremental; (d) Correto, o XP incentiva soluções
mais simples; (e) Correto, o refatoramento é uma prática adotada.
Gabarito: Letra B
51. (IF-SE / IF-SE – 2016) A Programação Extrema (Extreme Programming - XP) possui diversas
práticas. Analise as afirmativas abaixo.
I. As releases do sistema são frequentes e incrementais.

43089971860 -1644786
II. Os requisitos são representados através de casos de uso.

III. Os desenvolvedores não trabalham em pares.
IV. Depois de qualquer integração, todos os testes de unidade devem passar.
De acordo com as afirmativas, marque a alternativa CORRETA
a) As afirmativas I e II estão incorretas.

b) Apenas as afirmativas I e II estão corretas.
c) As afirmativas II e III estão incorretas
d) As afirmativas III e IV estão incorretas
Comentários:
(I) Correto. O XP adota a prática dos pequenos releases, que são frequentes e incrementais; (II)
Errado. Na verdade, são representados pelas histórias de usuários; (III) Errado. Eles trabalham em
pares; (IV) Correto. É o que diz a prática da integração contínua.
Gabarito: Letra C
52. (FGV / Prefeitura de Paulínia - SP – 2016) A empresa de desenvolvimento de

sistemas “Inovation” tem ampla experiência no mercado e, até o momento, utilizou diversos
modelos de ciclo de vida para o desenvolvimento de sistemas. A “Inovation” já recebeu diversas
reclamações dos seus clientes por causa da demora em apresentar alguma tela em
funcionamento, bem como da falta de envolvimento dos clientes no desenvolvimento. A
empresa, assim, decidiu passar a utilizar um novo modelo de ciclo de vida. Esta decisão visa
aproveitar a grande experiência de sua equipe e trazer o cliente para a equipe de
desenvolvimento, com iterações de desenvolvimento extremamente curtas. Qualquer membro
da equipe implementa parte do código, que pode ser evoluído por qualquer outro membro.
O novo modelo adotado pela “Inovation” é denominado:
a) Extremme Programming (XP).

b) Modelo V.
c) Evolutivo.
d) Incremental.
e) Espiral.
Comentários:
Iterações de desenvolvimento extremamente curtas (pequenas releases) e qualquer membro da

equipe implementa uma parte do código (propriedade coletiva) são práticas típicas do XP.
Gabarito: Letra A

43089971860 -1644786
53. (IF-PE / IF-PE – 2016) Com relação à metodologia ágil de desenvolvimento de software
conhecido como eXtreme Programming (XP), quais são os quatro processos ou atividades
metodológicas encontradas nela?
a) Análise, projeto, codificação e teste.

b) Planejamento, análise, projeto e codificação.
c) Planejamento, projeto, codificação e testes.
d) Planejamento, análise, codificação e testes.
e) Levantamento, análise, projeto e codificação.
Comentários:
As atividades são: planejamento, projeto, codificação e testes.
Gabarito: Letra C
54. (IBFC / EBSERH – 2016) Equipes XP (eXtreme Programming) planejam utilizando histórias
escritas em pequenos cartões. Essas histórias devem ter como objetivo:
a) a modelagem de dados
b) as métricas de software
c) os requisitos não-funcionais
d) os requisitos funcionais
e) tanto os requisitos funcionais como os requisitos não-funcionais
Comentários:
Os cartões devem conter os requisitos funcionais do software a ser desenvolvido.

43089971860 -1644786
Gabarito: Letra D
55. (IBFC / EBSERH – 2016) Para aplicar os valores e princípios durante o desenvolvimento de
software, a Programação Extrema (eXtreme Programming - XP) propõe uma série de práticas.
Selecione a única alternativa que NÃO seja uma dessas práticas:
a) Time Coeso (Whole Team).

b) Design Complexo (Complex Design).
c) Programação Pareada (Pair Programming).
d) Semana de 40 horas (Sustainable Pace).
e) Refatoração (Refactoring).
Comentários:
Todas as alternativas apresentam práticas do XP, exceto design complexo. O XP preconiza o

design/projeto simples em que o projeto é suficientemente simples de modo que atenda aos
requisitos atuais e nada mais.
Gabarito: Letra B
56. (CESPE / FUNPRESP-JUD – 2016) A programação em pares, em que os desenvolvedores atuam

avaliando entre si o trabalho do outro, é uma prática da metodologia XP.
Comentários:
Perfeito! Os desenvolvedores trabalham em pares, um verificando o trabalho do outro e fornecendo

Gabarito: Correto
57. (CESPE / FUNPRESP-JUD – 2016) As práticas da extreme programming, que tem por princípio
liberar grandes releases de software, visam agregar valor ao negócio.
Comentários:
As práticas do XP têm por princípio liberar pequenas releases e, não, grandes releases. O conjunto
mínimo útil de funcionalidade que agrega valor ao negócio é desenvolvido primeiro. Releases do
sistema são frequentes e adicionam funcionalidade incrementalmente ao primeiro release.
Gabarito: Errado
58. (CESPE / TRT-PR – 2016) Um projeto desenvolvido mediante XP (Extreme Programming) segue
princípios opostos aos de um projeto implementado com base em KIS (Keep It Simple).

43089971860 -1644786
Comentários:
Projeto Simples significa que é realizado um projeto suficientemente simples de modo que atenda
aos requisitos atuais e nada mais. Deve-se lembrar que um código simples não é código fácil (KIS –
Keep It Simple). Logo, seguem princípios análogos/semelhantes e, não, opostos aos de um projeto
implementado com base no Keep It Simple.
Gabarito: Errado
59. (IDECAN / INMETRO – 2015) Na extreme programming, todos os requisitos são expressos
como cenários (chamados histórias do usuário) que são implementados diretamente como uma
série de tarefas. Sabe-se que o extreme programming envolve um número de práticas que se
enquadram nos princípios dos métodos ágeis. Acerca de algumas dessas práticas, relacione
adequadamente as colunas a seguir.
1. Releases pequenos.
2. Refactoring.
3. Propriedade coletiva.
4. Integração contínua.
5. Ritmo sustentável.
( ) Os pares de desenvolvedores trabalham em todas as áreas do sistema, de tal maneira que não
se formem ilhas de conhecimento.
( ) O conjunto mínimo útil de funcionalidade que agrega valor ao negócio é desenvolvido
primeiro.
( ) Grandes quantidades de horas-extras não são consideradas aceitáveis, pois, no médio prazo,
há uma redução na quantidade de código e na produtividade.
( ) Espera-se que todos desenvolvedores recriem o código continuamente tão logo os
aprimoramentos do código forem encontrados.
( ) Tão logo o trabalho em uma tarefa seja concluído, este é integrado ao sistema como um todo
a) 5, 3, 1, 4, 2.
B) 2, 4, 3, 5, 1.
c) 4, 5, 2, 1, 3.
d) 3, 1, 5, 2, 4.
e) 5, 2, 4, 3, 1.
Comentários:
Desenvolvedores trabalham em todas as áreas do sistema? (3) Estamos falando da prática da

propriedade coletiva do código; Conjunto mínimo útil de funcionalidades? (1) Trata-se da prática dos
pequenos releases; Excesso de horas-extras e redução da produtividade? (5) Trata-se da prática de

43089971860 -1644786
ritmo sustentável; Desenvolvedores recriam o código continuamente? (2) Estamos falando da prática
do refatoramento; Integração assim que um trabalho é concluído? Trata-se da propriedade da
integração contínua (4).
Gabarito: Letra D
60.(CESPE / TRE-RS – 2015) Tendo em vista que, em um processo ágil de desenvolvimento

de software, foi adotado o XP (eXtreme Programming) e que os requisitos levantados foram
expressos na forma de histórias de usuário, assinale a opção que apresenta, corretamente,
recomendações técnicas para a elaboração de um cartão de histórias de usuário.
a) Como um professor, quero calcular as médias semestrais dos alunos de modo que eu possa
identificar quais serão aprovados.
b) O professor deseja o cálculo de notas semestrais com precisão de até duas casas decimais.
c) O sistema deve calcular as médias semestrais dos alunos com base nas notas atribuídas a eles
pelos professores.
d) Como analista de requisitos, eu preciso oferecer o cálculo das notas semestrais aos
professores em menos de um minuto.
e) Como um professor, eu preciso de releases semanais de funcionalidades, mesmo que elas
possam ser refatoradas posteriormente.
Comentários:
A questão pergunta por recomendações para elaboração de histórias de usuários. Uma boa história
de usuário é aquela em que o cliente se preocupa com ela. Além disso, ela deve ter valor de negócio
na visão do cliente. Em suma, as histórias de usuários são feitas pelos clientes. Por fim, as histórias
devem descrever o resultado, as características e a funcionalidade solicitados para o software a ser
construído.
(a) Correto. O professor é o cliente, ele criou a história e definiu corretamente o resultado, as
características e a funcionalidade; (b) Errado. O professor não definiu corretamente a
funcionalidade; (c) Errado. O sistema não é o cliente; (d) Errado, o cliente é que deve elaborar a
história; (e) Errado. Isso é papel do desenvolvedor.
Gabarito: Letra A
61. (FCC / TRE-PB – 2015) Extreme Programming − XP pode ser considerado um modelo de
desenvolvimento de software baseado em uma série de valores, princípios e regras, dentre eles,
a) criar obrigatoriamente uma matriz de rastreabilidade de requisitos.

b) manter o foco na documentação, detalhada e diversificada.
c) definir sprint de no máximo duas semanas.
d) escrever sempre o código, depois, o teste de unidade.

43089971860 -1644786
e) realizar semanalmente o jogo do planejamento (planning game).
Comentários:
(a) Errado. Não há essa obrigação; (b) Errado. O XP por ser uma metodologia ágil, valoriza mais um
software em funcionamento do que uma documentação detalhada e diversificada; (c) Errado. na
verdade, os incrementos é que são entregues em aproximadamente duas semanas; (d) Errado. O
XP adota o desenvolvimento test-first, ou seja, primeiro escreve-se o teste; (e) Correto. O planning
game pode ocorrer semanalmente.
Gabarito: Letra E
62. (UFPel-CES / UFPEL – 2015) Em projetos nos quais se aplicam o método ágil XP, a fase em que
o propósito é empresa e cliente concordarem em uma data na qual o menor e melhor conjunto
de histórias de usuários deverá ser implementado é a fase de:
a) planejamento.
b) exploração.
c) iterações e entregas.
d) produção.
e) manutenção.
Comentários:
De acordo com a figura, vemos que a fase que está relacionada diretamente com os valores das
histórias de usuários é a fase de planejamento. É na fase de planejamento que os desenvolvedores
definem com os clientes as user stories, que nada mais são do que requisitos. Além disso, para cada
requisito é definido uma complexidade e prazo de entrega.

43089971860 -1644786
Gabarito: Letra A
63. (CS-UFG / AL-GO – 2015) Extreme Programming (XP) é um exemplo de método ágil que foi
definido por Kent Beck. O XP inclui uma abordagem de teste que:
a) valoriza o desenvolvimento test-last.

b) depende da técnica de teste baseada em defeitos
c) desenvolve teste incremental baseado em cenários
d) utiliza processo de teste dirigido a planos.
Comentários:
(a) Errado. O XP trabalha com desenvolvimento test-first; (b) Errado. O teste é baseado em
cenários; (c) Correto. O XP tem como características testes incrementais a partir de cenários – é
importante lembrar que os cenários são também chamados de histórias de usuários (user stories);
(d) Errado. Os testes são dirigidos a cenários.
Gabarito: Letra C
64. (CESPE / TJDFT – 2015) Na metodologia XP (extreme programming), em que todos os

requisitos são expressos como cenários, deve-se aguardar, após a conclusão das tarefas, ciclos
de cento e oitenta dias para a publicação de grandes releases do software.
Comentários:
Não, não há absolutamente nenhuma condição para a publicação de grandes releases – muito
menos 180 dias! Já imaginaram isso? 180 dias!!!
Gabarito: Errado
65. (CESPE / TJDFT – 2015) As características da metodologia XP incluem o desenvolvimento

interativo, que dispõe de um processo de testes informais.
Comentários:
Vamos lá! Já começo dizendo que não gostei dessa questão. Por que? Porque várias vezes a banca
escreve interativo, em vez de iterativo, e dá como errado. Ora, é característica de qualquer tipo de
desenvolvimento a interatividade, logo isso não deveria ser alvo de questão alguma, mas só
algumas metodologias de desenvolvimento são iterativas e, isso sim, deveria ser alvo de questões.
O fato é que a questão não está errada ao dizer que o XP possui como característica o
desenvolvimento interativo. Mas, porém, todavia, entretanto, ele dispõe de um processo de testes

43089971860 -1644786
formais, como diz Sommerville - ele possui mecanismos para tal. Logo, para mim, a questão está
errada, mas a banca a deu como correta e infelizmente não foram acatados recursos.
Gabarito: Correto
66. (CETRO / AMAZUL – 2015) Assinale a alternativa que não apresenta um princípio/ valor da
metodologia de desenvolvimento de software XP (Extreme Programming):
a) Simplicidade.
b) Programação individual ou não em pares.
c) Comunicação.
d) Coragem.
e) Feedback.
Comentários:
Todas as alternativas apresentam valores do XP, exceto a programação individual. Primeiro, porque
isso é uma prática; segundo, porque é a programação em pares e, não, individual.
Gabarito: Letra B
67. (CESPE / TRE-RS – 2015) Em um desenvolvimento ágil de sistemas utilizando o XP, foram
adotadas as seguintes ações: foi dita a verdade ao cliente acerca do progresso do projeto e
acerca de suas estimativas, além de haverem sido realizadas adaptações quando mudanças
importantes aconteceram no projeto. Essas ações estão coerentes com o valor do XP
denominado:
a) sinceridade.
b) comunicação.
c) coragem.
d) feedback.
e) respeito.
Comentários:
A questão trata do valor da coragem! Ela permite que os desenvolvedores se sintam confortáveis
com ao refatorar o seu código, quando necessário. Eventualmente, há de se ter coragem para jogar
fora um código ou para remover um código obsoleto, não importa quanto esforço e tempo se
gastou para produzi-lo. Além disso, coragem significa persistência, pois um programador pode se
Gabarito: Letra C

43089971860 -1644786
68. (CESPE / TRE-RS – 2015) Assinale a opção que apresenta uma característica relacionada a
projetos que utilizam o método XP (eXtreme Programming), muito utilizado em projetos para
o desenvolvimento de softwares.
a) grandes releases
b) programação individual
c) cliente off-site
d) grandes volumes de horas extras
e) planejamento incremental
Comentários:
(a) Errado, a prática adequada são pequenas releases; (b) Errado, a prática adequada é a
programação em pares; (c) Errado, a prática adequada é cliente on-site; (d) Errado, a prática
adequada é o ritmo sustentável; (e) Correto, essa é uma prática bastante utilizada no contexto do
XP.
Gabarito: Letra E
69. (CESPE / STJ – 2015) Na Extreme Programming, a programação em pares cria ilhas de
especialistas na equipe por meio da análise simultânea de duas pessoas no desenvolvimento
do software.
Comentários:
Pelo contrário, a programação em pares permite que os programadores trabalhem em diversas

áreas do sistema, de tal maneira que não se formem ilhas de conhecimento, com todos os
desenvolvedores de posse de todo o código.
Gabarito: Errado
70. (IESES / TRE-MA – 2015) No desenvolvimento de software em XP, são empregadas algumas
práticas. Avalie as assertivas abaixo:
I. Programação em pares.
II. Time coeso.
III. Integração contínua.
IV. Desenvolvimento orientado a testes.
Quantas afirmativas são verdadeiras?
a) 2
b) 1

43089971860 -1644786
c) 4
d) 3
Comentários:
Todas as alternativas apresentam práticas do XP.
Gabarito: Letra C
71. (CESPE / FUB – 2015) Práticas de desenvolvimento de software aos pares de programadores,
em que um programador verifica o trabalho do outro, são uma característica do método de
desenvolvimento XP.
Comentários:
Perfeito! É uma das práticas mais cobradas em prova sobre o XP.
Gabarito: Correto
72. (CESPE / FUB – 2015) É considerada como ritmo sustentável a carga horária de trabalho extensa
para gerar rapidamente entregas de produtos de software, o que provoca grande quantidade de
horas extras.
Comentários:
Opaaa... grandes quantidades de horas extras não são consideradas aceitáveis, pois, no médio
prazo, há uma redução na qualidade do código e na produtividade. Trabalhar por longos períodos
se torna contraproducente – recomenda-se 40 horas semanais.
Gabarito: Errado
73. (FUNCAB / SEFAZ-BA – 2014) São características do Extreme Programming (XP), EXCETO:
a) apresentar desenvolvimento incremental.

b) admitir a existência de uma especificação detalhada.
c) utilizar programação com pares de desenvolvedores.
d) permitir a integração de usuário com o time de desenvolvimento.
e) suportar testes automáticos contínuos.
Comentários:

43089971860 -1644786
(a) Correto. O desenvolvimento é incremental; (b) Errado. Na verdade, o projeto deve ser simples,
e não detalhado; (c) Correto. O XP utiliza a programação em pares; (d) Correto. o envolvimento do
cliente ocorre em tempo integral; (e) Correto. Há testes automatizados e contínuos no XP.
Gabarito: Letra B
74. (INSTITUTO AOCP / MPE-BA – 2014) O processo ágil XP possui doze práticas que são os
princípios fundamentais do processo. A prática que encoraja a equipe inteira a trabalhar mais
unida em busca de qualidade no código fazendo melhorias e refatoramentos em qualquer parte
do código a qualquer tempo é conhecida como:
a) propriedade coletiva do código.

b) semana de quarenta horas.
c) programação em pares.
==1918f2==
d) padrões de codificação.
e) integração contínua.
Comentários:
Uma das principais práticas do XP é a propriedade coletiva do código, ela diz que os pares de
desenvolvedores podem trabalhar em todas as áreas do sistema, de forma que não se formem ilhas
de conhecimento.
Gabarito: Letra A
75. (FGV / Câmara Municipal do Recife-PE – 2014) Uma das práticas do método ágil XP (eXtreme
Programming) é:
a) documentação extensiva;
b) prototipação;
c) ciclos longos de desenvolvimento;
d) desenvolvimento orientado a testes (TDD);
e) utilização de todos os artefatos do RUP.
Comentários:
O TDD é uma prática XP em que se escreve o teste antes de escrever o código do componente.
Gabarito: Letra D
76. (FUNCAB / MDA – 2014) A “Extreme Programming - XP” representa um dos mais conhecidos
métodos ágeis. Uma das práticas utilizadas na XP é:

43089971860 -1644786
a) empregar um esquema em que os desenvolvedores trabalham individualmente.

b) integrar o sistema exclusivamente quando todos os módulos forem concluídos.
c) usar cenários para expressar requisitos implementados como uma série de tarefas.
d) impedir que o cliente interaja com a equipe de desenvolvimento na fase de especificação.
e) eliminar a necessidade da realização de testes durante a fase de desenvolvimento.
Comentários:
(a) Errado, os desenvolvedores trabalham em pares; (b) Errado, uma das práticas é a de pequenos
releases durante o desenvolvimento; (c) Correto, no XP os requisitos são expressos como cenários;
(d) Errado, o cliente tem envolvimento em tempo integral; (e) Errado, os testes são frequentes.
Gabarito: Letra C
77. (CESGRANRIO / Banco da Amazônia – 2014) Uma prática que NÃO é adotada por Extreme
Programming (XP) é
a) usar duas pessoas trabalhando juntas em um único computador para produzir todo o código
que será enviado para a produção.
b) criar os testes antes do código que será testado.
c) refatorar frequentemente, e ao longo de todo o projeto, o código produzido pelos

desenvolvedores.
d) integrar continuamente o código recém-produzido com o código existente no repositório.
e) variar a duração de cada iteração durante todo o projeto para acomodar eventuais mudanças
de prioridade dos requisitos, definidas pelo cliente.
Comentários:
Lembrem-se: tempo fixo e escopo variável e, não, o contrário! A última opção afirma que o tempo
muda de acordo com o escopo/mudanças e isso não é verdade.
Gabarito: Letra E
78. (CESPE / ANTT – 2013) São práticas ou princípios recomendados no modelo de

desenvolvimento de software XP (eXtreme Programming) proposto por Kent Beck:
programação em pares; semana de trabalho de 40 horas; refatoração sem piedade;
desenvolvimento orientado a testes TDD (Test Driven Development); e desenvolvimento de
metáforas arquiteturais.

43089971860 -1644786
Comentários:
Vamos verificar? Programação em Pares, ok. Semana de 40 horas, ok. Desenvolvimento orientado
a testes TDD, ok. Desenvolvimento de metáforas arquiteturais, ok. Refatoração sem piedade, como
é? Sem piedade? Galera, não faço ideia de onde a banca tirou esse nome! É simplesmente
refatoração. No entanto, é melhor não brigar com a banca...
Gabarito: Correto
79. (CESPE / STF – 2013) XP (Extreme Programming) é uma metodologia ágil voltada para equipes
pequenas e médias que desenvolvam software baseado em requisitos vagos e se caracteriza por
possibilitar modificações rápidas.
Comentários:
É uma metodologia ágil? Sim! Voltada para equipes pequenas e médias? Sim! Desenvolvem software
baseado em requisitos vagos? Sim! Possibilita modificações rápidas? Sim, lembrem-se que é um
método ágil!
Gabarito: Correto
80.(CESPE / TCE-RO – 2013) No método XP (eXtreming programming), os sistemas são concebidos

a partir de uma metáfora e descritos em estórias do usuário. Esse método busca facilitar a
comunicação com o cliente, entendendo a realidade deste e guiando o desenvolvimento com o
uso de estória simples.
Comentários:
Perfeito! Uma das vantagens das metáforas é que elas simplificam o entendimento...
Gabarito: Correto
81. (CESPE / MPU 2013) XP é um método de desenvolvimento de software em que os requisitos

são especificados em user stories; requisitos, arquitetura e design surgem durante o curso do
projeto; e o desenvolvimento ocorre de maneira incremental.
Comentários:
Perfeito! De fato, ela utiliza histórias de usuário. Além disso, requisitos, arquitetura e design surgem
durante o curso do projeto – elas não são completamente definidas previamente. Por fim, o
desenvolvimento é incremental porque se trata de um método iterativo e incremental.
Gabarito: Correto

43089971860 -1644786
82. (CESGRANRIO / BNDES – 2013) Sendo atualmente conhecida por just-in-time, a produção
enxuta contém princípios que compõem a base dos processos ágeis de desenvolvimento de
software, como o Extremme Programming (XP). Um dos princípios básicos do XP, a eliminação
de desperdícios, busca:
a) evitar o efeito negativo que uma definição de risco, na fase inicial do projeto, possa causar na
performance do software como um todo, tendo, como saída, informações não relevantes para
o processo.
b) produzir requisitos bem definidos e completos de forma a abranger todos os processos e

rotinas administrativas, funcionais e produtivas almejadas pelos stakeholders envolvidos no
projeto.
c) reduzir, o máximo possível, o volume de trabalho executado e os subprodutos envolvidos

nesse trabalho, concentrando os esforços apenas no que pode produzir um resultado objetivo e
palpável ao cliente final.
d) descrever os processos que garantam a inclusão, no projeto, de todo o serviço necessário, e

somente o serviço necessário, para que esse projeto seja finalizado com sucesso.
e) descrever os processos envolvidos no planejamento, no monitoramento e na garantia de que

o projeto será realizado dentro dos prazos definidos no escopo, mantendo a qualidade definida
e o enxugamento dos custos inicialmente programados.
Comentários:
A frase chave é “…concentrando os esforços apenas no que pode produzir um resultado objetivo e
palpável ao cliente final”. Tudo que não for entregar valor ao cliente é desperdício.
Gabarito: Letra C
83. (CESPE / MPE-PI – 2012) O XP (Extreme Programming) é um método ágil, que preconiza a
criação de um caso de teste unitário antes do início da codificação.
Comentários:
O XP é, de fato, um método ágil que preconiza o Test-First Design como uma de suas práticas, isto
é, primeiro cria-se o teste para depois codificar a funcionalidade referente a esse teste.
Gabarito: Correto

43089971860 -1644786
84.(CESPE / ANAC – 2012) Para o método ágil de desenvolvimento conhecido como extreme
programming, todos os requisitos funcionais são expressos como cenários (histórias do usuário)
que são implementados diretamente como uma série de tarefas.
Comentários:
Corretíssimo! Requisitos funcionais são representados como cenários ou histórias de usuário, que
são implementadas diretamente como uma série de tarefas.
Gabarito: Correto
85. (CESPE / ANAC – 2012) A técnica conhecida como refactoring é constantemente aplicada no
desenvolvimento baseado no método ágil extreme programming.
Comentários:
Perfeito! Também conhecida como refatoração, essa é uma das técnicas amplamente preconizadas
pelo XP!
Gabarito: Correto
86. (CESPE / ANAC – 2012) No modelo extreme programming, os testes de software só são
realizados na etapa final de desenvolvimento do software e, somente nessa etapa, os
programadores trabalham, obrigatoriamente, em pares, utilizando cada um o próprio
computador.
Comentários:
Primeiro, testes de software não ocorrem somente na etapa final de desenvolvimento, eles são
realizados a todo momento. Ademais, programadores trabalham em pares a todo instante: um
computador para dois programadores.
Gabarito: Errado
87. (CESPE / ANAC – 2012) Na metodologia ágil XP (extreme programming), as metáforas são
formas de transmitir ideias complexas de maneira simples, ou seja, utiliza-se uma linguagem
simples entre a equipe e o cliente, com o objetivo de que, entre as inúmeras variáveis de controle
em projetos, tais como tempo, custo, qualidade e escopo, obtenha-se maior foco no tempo, em
detrimento do planejamento do release.
Comentários:

43089971860 -1644786
A primeira parte da questão está perfeita, isto é, metáforas ajudam a transmitir ideias complexas
de maneira simples. No entanto, o objetivo dela não é obter maior foco no tempo. Ademais, o
planejamento da release é dependente do tempo, logo não há essa distinção de foco!
Gabarito: Errado
88. (FCC / TST – 2012) O XP (Extreme Programming) utiliza uma abordagem orientada a objetos
como seu paradigma de desenvolvimento predileto. Ele:
a) recomenda que duas pessoas trabalhem juntas para criar o código correspondente a uma
história.
b) recomenda que a equipe XP e os clientes trabalhem de forma separada para não mudar o
compromisso básico definido para a versão a ser entregue.
c) segue rigorosamente o princípio FDD - Feature Driven Development.
d) recomenda que depois que as histórias forem desenvolvidas e o trabalho preliminar do

projeto for feito, a equipe XP avance diretamente para o código.
e) inclui um conjunto de regras e práticas que ocorrem no contexto de 3 atividades de arcabouço:

projeto, implementação e entrega.
Comentários:
(a) Correto, trata-se da programação em pares; (b) Errado, recomenda-se o cliente on-site, isto é, o
cliente está sempre presente para auxiliar com seu conhecimento sobre a área de negócio; (c)
Errado, ela segue o TDD – Test-Driven Development; (d) Errado, Pressman afirma que se
recomenda desenvolver testes unitários que exercitarão as histórias; (e) Errado, Pressman afirma
que XP inclui um conjunto de regras e práticas que ocorrem no contexto de quatro atividades de
arcabouço: planejamento, projeto, codificação e teste.
Gabarito: Letra A
89. (FCC / MPE-AP – 2012) O Extreme Programming (XP) é, talvez, o mais conhecido e mais
utilizado dos métodos ágeis. Dentre suas práticas se encontram programação em pares,
integração contínua, refatoração e:
a) propriedade coletiva, que garante uma participação nos lucros aos membros da equipe de
desenvolvimento, técnica que incentiva e aumenta o desempenho de toda a equipe.
b) envolvimento do cliente apenas na fase final do sistema, fator que difere de outras
metodologias como SCRUM e TDD e confere agilidade ao processo de desenvolvimento.

43089971860 -1644786
c) processo de desenvolvimento contínuo, em que a equipe se mantém focada no sistema até

que uma funcionalidade específica seja entregue, comumente agregando horas extras ao turno
de trabalho.
d) utilização de técnicas de ofuscação do código fonte, trazendo segurança e garantindo que

apenas a equipe de desenvolvimento poderá ter acesso a este código
e) desenvolvimento incremental e sustentado por meio de pequenos e frequentes releases do

sistema. Os requisitos são baseados em cenários ou em simples histórias de clientes.
Comentários:
(a) Errado. Participação nos lucros? Quem dera! Essa prática significa que todos podem visualizar e
editar um código-fonte; (b) Errado, o envolvimento ocorre durante todo o processo; (c) Errado,
deve-se manter um ritmo sustentável, evitando horas-extras; (d) Errado. Pelo contrário, quanto
mais limpo o código, melhor; (e) Perfeito, não há nada a acrescentar.
Gabarito: Letra E
90.(FCC / MPE-PE – 2012) Dentre as práticas do método ágil Extreme Programming (XP), está a
prática de propriedade coletiva. É correto afirmar que, nessa prática,
a) os trabalhos são desenvolvidos em conjunto, para que um programador possa analisar o

trabalho do outro.
b) cada projeto é realizado para atender às necessidades globais dos usuários, focando na
coletividade da distribuição da informação.
c) os pares de desenvolvedores trabalham em todas as áreas do sistema, de modo que não se

desenvolvam ilhas de expertise.
d) grandes quantidades de horas extras não são consideradas aceitáveis, pois o resultado final,
muitas vezes, é a redução da qualidade do código e da produtividade a médio prazo, sendo que
o indivíduo pode afetar o desempenho de todo o time.
e) um representante do usuário final do sistema deve estar disponível todo o tempo à equipe de
desenvolvimento. Nesse modelo de desenvolvimento, o cliente é membro da equipe e participa
da responsabilidade do código desenvolvido.
Comentários:

43089971860 -1644786
(a) Trata-se do Pair Programming; (b) Não sei o que é, mas não há relação com Propriedade
Coletiva; (c) Trata-se da Propriedade Coletiva; (d) Trata-se do Ritmo Sustentável; (e) Trata-se do
Cliente On-Site.
Alguns afirmam que a terceira opção está mais para a prática de Pair Programming e, não, para
Propriedade Coletiva. Eu admito que é um pensamento razoável, mas nenhuma outra opção se
encaixa em Propriedade Coletiva. Dessa forma, deve-se ter essa noção nas questões da FCC, isto é,
marcar a mais correta ou a menos errada.
Gabarito: Letra C
91. (FCC / TJ-PE – 2012) Nos métodos ágeis XP e Scrum, as entregas de partes funcionais do projeto
são divididas em ciclos, geralmente compreendidos no período de 1 a 4 semanas. Estes ciclos
denominam-se, respectivamente,
a) iterações e sprint.
b) reunião de planejamento e backlog.
c) período de entrega e reunião de revisão.
d) backlog e planejamento da produção.
e) entrega e retrospectiva.
Comentários:
No XP, temos as iterações; no Scrum, temos a sprint!
Gabarito: Letra A
92. (CESPE / EBC – 2011) O XP segue um conjunto de valores, princípios e regras básicas que visam
alcançar eficiência e efetividade no processo de desenvolvimento de software. Os valores são
cinco: comunicação, simplicidade, feedback, coragem e respeito.
Comentários:
De fato, esses são os valores preconizados pelo XP: Comunicação, Simplicidade, Feedback,
Coragem e Respeito.
Gabarito: Correto
93. (CESPE / STM – 2011) O Extreme Programming (XP), que se inclui entre os métodos ágeis,
apresenta, entre outras, as seguintes características: pequenos releases, projeto simples,
refactoring, programação em pares e propriedade coletiva.
Comentários:

43089971860 -1644786
Perfeito! Todas essas são características/práticas do Extreme Programming.
Gabarito: Correto
94.(FCC / TRT-MT – 2011) NÃO se aplica à disciplina de desenvolvimento de software extreme

programming (XP):
a) Usa notações próprias para construir os diversos produtos de trabalho do projeto.
b) Encoraja a refabricação para modificar um sofware sem alterar o comportamento externo do

código.
c) Recomenda que dois programadores trabalhem juntos no mesmo computador para escrever
um código.
d) Baseada em valores de simplicidade, comunicação, feedback e coragem.
e) Adota como um elemento-chave a criação de testes unitários antes da codificação começar.
Comentários:
(a) Errado, não há nenhuma notação própria; (b) Correto, trata-se do Refactoring; (c) Correto, trata-
se da programação em pares; (d) Correto, há também respeito; (e) Correto, teste primeiro e
codifique depois.
Gabarito: Letra A
95. (FCC / TRE-RN – 2011) Considere as seguintes características:
I. Propriedade coletiva.
II. Integração contínua.
III. Metáfora.
Dentre as práticas componentes da Extreme Programming, aplica-se o que consta em:
a) I, apenas.
b) II, apenas.
c) I e II, apenas.
e) I, II e III.
Comentários:

43089971860 -1644786
Todas as opções estão corretas: Propriedade Coletiva, Integração Contínua e Metáfora.
Gabarito: Letra E
96. (FCC / TRT-23 – 2011) No desenvolvimento de software em Extreme Programming (XP) há

uma confiança muito grande na sinergia entre as práticas, já que os pontos fracos de cada uma
são superados pelos pontos fortes de outras. Dentre elas, aquela em que o código fonte não tem
dono e ninguém precisa solicitar permissão para poder modificá-lo, permitindo, assim, que a
equipe conheça todas as partes do sistema, é chamada de:
a) Whole Team (Time Coeso).

b) Sustainable Pace (Ritmo Sustentável).
c) Pair Programming (Programação em Pares).
d) Collective Ownership (Posse Coletiva).
e) Coding Standards (Padrões de Codificação).
Comentários:
O código fonte não tem dono e ninguém precisa solicitar permissão para poder modificá-lo,
permitindo, assim, que a equipe conheça todas as partes do sistema, é chamada de
Posse/Propriedade Coletiva (Collective Ownership).
Gabarito: Letra D
97. (FCC / TRE-RN – 2011) Assegurar que a equipe se concentre em fazer, primeiro, apenas aquilo
que é claramente necessário e evite fazer o que poderia vir a ser necessário, mas ainda não se
provou essencial. Este é um dos cinco valores fundamentais do XP (Extreme Programming),
denominado:
a) coragem.
b) respeito.
c) comunicação.
d) simplicidade.
e) feedback.
Comentários:
Fazer o necessário e essencial é exatamente o valor da simplicidade.
Gabarito: Letra D

43089971860 -1644786
98. (CESPE / TRE-BA – 2010) Em XP, a prática denominada programação em pares (pair
programming) é realizada por um desenvolvedor em dois computadores, com o objetivo de
aumentar a produtividade.
Comentários:
Na verdade, são dois desenvolvedores utilizando apenas um computador. Observem que o intuito
é aumentar a qualidade do software por meio da revisão constante pelo par.
Gabarito: Errado
99. (CESPE / ABIN – 2010) Na Extreme Programming, os requisitos são expressos como
cenários e implementados diretamente como uma série de tarefas. O representante do cliente
faz parte do desenvolvimento e é responsável pela definição de testes de aceitação do sistema.
Comentários:
Perfeito! Os requisitos são expressos como cenários (ou histórias de usuário) e implementados
como tarefas. Ademais, recomenda-se o Cliente On-Site, isto é, um representante do usuário final
do sistema deve estar disponível em tempo integral para apoiar a equipe. Além disso, Pressman, 7ª
Ed., pág. 77, afirma:
“XP acceptance tests, also called customer tests, are specified by the customer and focus on overall
system features and functionality that are visible and reviewable by the costumer. Acceptance tests
are derived from user stories that have been implemented as part of a software release”.
Gabarito: Correto
100. (CESPE / MPU – 2010) Extreme programming (XP) é embasado em requisitos conhecidos,
definidos de antemão, que não sofram muitas alterações, devendo ser usado por equipes de
pequeno porte, formadas por representantes de todos os stakeholders.
Comentários:
XP é um método ágil de desenvolvimento de software com requisitos vagos e em constante

mudança, devendo ser usado por equipes de pequeno a médio porte, formadas – se possível – por
representantes de todos os stakeholders.
Gabarito: Errado
101. (CESPE / TRE-BA – 2010) Os quatro valores fundamentais da metodologia XP são:

comunicação, simplicidade, feedback e coragem.

43089971860 -1644786
Comentários:
No início, havia apenas quatro valores – posteriormente, foi adicionado um novo valor: respeito! Na
época dessa questão, ainda havia apenas quatro valores.
Gabarito: Correto
102. (CESPE / TCU – 2010) O processo XP (extreme programming) envolve a realização das
atividades de planejamento, de projeto, de codificação e de teste.
Comentários:
Perfeito! Essas são as atividades do Processo XP...
Gabarito: Correto
103. (FCC / TRE-RS – 2010) No eXtreme Programming, XP:
a) o código é integrado e testado depois de alguns dias e, no máximo, até o final da semana.
b) a codificação é feita em grupos de programadores (no mínimo 3 integrantes),

preferencialmente num único computador.
c) as equipes de desenvolvimento estabelecem suas próprias regras, mas uma equipe pode
adotar as regras de outra equipe.
d) releases quando complexos não podem deixar de fora os requisitos de negócio de maior valor
para o cliente.

43089971860 -1644786
e) módulos não são propriedade de nenhum desenvolvedor; todo desenvolvedor da equipe tem
o direito de checar um módulo e modificá-lo.
Comentários:
(a) Errado, recomenda-se a integração sempre que possível; (b) Errado, é feita por um par de
programadores; (c) Errado, as equipes são auto-organizáveis de acordo com as suas habilidades,
logo não faz sentido se organizar de acordo com outra equipe; (d) Errado, releases devem ser
simples e, não, complexas; (e) Correto, o código é compartilhado.
Gabarito: Letra E
104. (FCC / MPE-RN – 2010) Refactoring, programação em pares e Stand-up Meeting são
características das práticas do:
a) PRINCE2.
b) Rational Unified Process.
c) Extreme programming.
d) PMBOK.
e) SCRUM.
Comentários:
Refactoring (Refatoração), Pair-Programming (Programação em Pares) e Standup Meeting

(Reuniões em Pé) são todas práticas do XP.
Gabarito: Letra C
105. (CESPE / SECONT-ES – 2009) Métodos ágeis de desenvolvimento de sistemas foram

propostos principalmente para apoiar o desenvolvimento de aplicações de negócios nas quais
os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento. Entre
esses métodos está o extreme programming, que envolve um número de práticas, como o
planejamento incremental, a definição de um ritmo de trabalho sustentável e a divisão das
equipes de trabalho por meio da especialização de seus membros.
Comentários:
A questão está quase toda correta, exceto pela última parte! O XP recomenda que não haja
especialização de membros, apresentando uma equipe coesa e multidisciplinar, isto é, todos
participam de todas as atividades.
Gabarito: Errado

43089971860 -1644786
106. (CESPE / IPEA – 2009) A extreme programming (XP) é um método de desenvolvimento ágil.
Nele, os requisitos são expressos como cenários implementados diretamente como uma série
de tarefas.
Comentários:
XP é um método ágil? Sim! Os requisitos são expressos como cenários implementados como uma série
de tarefas? Sim! Questão bastante comum em concursos!
Gabarito: Correto
107. (CESPE / TRE-MG – 2009) Extreme programming é um método centrado no usuário, na

produtividade do desenvolvimento e na documentação de apoio.
Comentários:
Centrado na documentação de apoio? Não! Lembrem-se que não há foco em documentação em

metodologias ágeis.
Gabarito: Errado
108. (CESPE / TRE-BA – 2009) A metodologia XP prevê valores e princípios básicos para serem
considerados durante o desenvolvimento de software. Feedback, coragem e respeito são
exemplos de valores; mudanças incrementais, abraçar mudanças e trabalho de qualidade são
exemplos de princípios básicos.
Comentários:
Perfeito! Valores Fundamentais: Feedback, Coragem, Respeito, Comunicação e Simplicidade;

Princípios Básicos: Feedback Rápido, Abraçar Mudanças, Presumir Simplicidade, Mudanças
Incrementais e Trabalho de Qualidade.
Gabarito: Correto
109. (CESPE / ANAC – 2009) Extreme Programming é um modelo de processo de

desenvolvimento de software para equipes com grande número de pessoas, que desenvolvem
software com base em requisitos vagos e que são modificados rapidamente.
Comentários:
Grande número de pessoas? Não, equipes de pequeno e médio porte!
Gabarito: Errado

43089971860 -1644786
110. (CESPE / ANTAQ – 2009) O extreme programming (XP) constitui método ágil de
desenvolvimento de software. Uma das práticas que se enquadram nos princípios dos métodos
ágeis é a programação em pares, que promove o compartilhamento da autoria do código do
sistema. Além dessa vantagem, a programação em pares atua como processo informal de
revisão porque cada linha de código é vista por pelo menos duas pessoas.
Comentários:
Perfeito! A Programação em Par promove a Propriedade Coletiva! Além disso, serve como uma
revisão informal.
Gabarito: Correto
111. (FCC / TJ-PI – 2009) XP (eXtreme Programming) é uma metodologia ágil para equipes
pequenas e médias que desenvolverão software com requisitos vagos e em constante mudança.
Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos
ajustes durante o desenvolvimento de software. Para aplicar os valores e princípios durante o
desenvolvimento de software, a XP propõe uma série de práticas, sendo uma delas: sempre que
produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do
sistema a fim de evitar o aumento da possibilidade de conflitos e da possibilidade de erros no
código fonte. Tal prática é denominada:
a) Time Coeso.
b) Refatoração.
c) Integração Contínua.
d) Desenvolvimento Orientado a Testes.
e) Ritmo Sustentável.
Comentários:
Essa é a prática da Integração Contínua! É comum a utilização de servidores de integração contínua

que automatizam esse processo para os desenvolvedores.
Gabarito: Letra C
112. (CESPE / PRODEST – 2008) Projetar detalhadamente todo o software antes de iniciar a sua
implementação é uma prática recomendada pelo XP. O software deve ser projetado para
atender tanto aos requisitos atuais quanto aos potenciais requisitos futuros. Para atingir esse
objetivo, são analisados os possíveis cenários de evolução futura e são empregados padrões de
projeto para facilitar a manutenção.
Comentários:

43089971860 -1644786
Projetar detalhadamente? Não! O Manifesto Ágil já dizia: responder a mudanças é mais valorizado
do que seguir um plano específico.
Gabarito: Errado
113. (CESPE / PRODEST – 2008) Constituem práticas recomendadas pelo XP a colocação rápida
de uma versão simples em produção, a liberação das novas versões em curtos intervalos de
tempo, a programação em duplas, a refatoração (refactor) dos códigos produzidos, a adoção de
padrões para a codificação; a integração e o teste contínuos de códigos; a limitação em 40 horas
da carga de trabalho semanal.
Comentários:
Perfeito! Todas essas são práticas recomendadas pelo XP!
Gabarito: Correto
114. (CESPE / PRODEST – 2008) O XP é um processo que visa a um desenvolvimento ágil e

portanto não recomenda os testes de unidade, pois eles consomem muitos recursos. Durante o
desenvolvimento, o primeiro teste recomendado é o smoke test que foca os detalhes de
funcionamento. O smoke test é realizado após as unidades serem integradas. Após o smoke
test, é realizado o teste de sistema.
Comentários:
Como é? XP recomenda veementemente a utilização de testes de unidade!
Gabarito: Errado
115. (FCC / TCE-AL – 2008) Originalmente, o único produto da atividade de Projeto que é
realizado como parte do processo XP (Extreme Programming):
a) é a definição do caso de uso de contexto.

b) são os cartões CRC.
c) são os diagramas de objetos.
d) são os diagramas de seqüência.
e) é a codificação, feita em pares.
Comentários:
Pressman afirma: “Como o projeto XP praticamente não usa nenhuma notação e produz poucos, ou
nenhum produto de trabalho que não sejam os cartões CRC e as soluções de ponta, o projeto é visto

43089971860 -1644786
como um artefato provisório que pode e deve ser continuamente modificado à medida que a construção
prossegue”. Dessa forma, trata-se dos Cartões CRC.
Gabarito: Letra B
116. (FCC / TRE-SE – 2007) Na XP (eXtreme Programming):
a) deve-se usar o modelo em cascata para o desenvolvimento do software.
b) os programadores desenvolvem o software criando primeiramente os testes.
c) deve ser evitada a comunicação pessoal entre clientes e desenvolvedores, sempre dando
preferência a outros meios de comunicação mais formais.
d) os programadores desenvolvem o software fazendo todos os testes possíveis no término do

desenvolvimento.
e) deve-se projetar todas as funções possíveis com a máxima previsão do que ocorrerá no futuro,
antes do desenvolvimento do software, a fim de evitar alterações desnecessárias.
Comentários:
(a) Errado, esse item não faz o menor sentido; (b) Correto, testa-se primeiro, codifica-se depois; (c)
Pelo contrário, deve-se estimular a comunicação pessoal entre clientes e desenvolvedores e evitar
outros meios mais formais; (d) Errado, testes são feitos a todo momento; (e) Errado. Pelo contrário,
XP lida bem com mudanças.
Gabarito: Letra B
117. (INSTITUTO AOCP / EBSERH – 207) O Extreme Programming (XP) surgiu em 1999, a partir
de uma publicação sobre o assunto, mas suas bases se conectam a princípios da década de 80 e
ao manifesto ágil. O XP é baseado em 4 atividades de arcabouços. Assinale a alternativa que
contém 3 desses arcabouços:
a) Levantamento de requisitos, análise de negócio, planejamento e documentação.

b) Levantamento de requisitos, planejamento, documentação e implantação.
c) Levantamento de requisitos, documentação, codificação e teste.
d) Planejamento, projeto, documentação e implantação.
e) Governança, planejamento, codificação e teste.
Comentários:

43089971860 -1644786
A resposta é: Governança, Planejamento, Codificação e Testes. Professor, você está cego? Onde tem
governança na imagem? A questão não deveria ser anulada? Não! A questão afirma que o XP é
baseado em quatro atividades de arcabouços e pede para assinalar a alternativa que contém três
desses arcabouços. Governança não faz parte, mas projeto, codificação e testes fazem!
Gabarito: Letra E

43089971860 -1644786

1. (COMPERVE / TJ-RN – 2020) O método ágil Extreme Programming ou XP é um dos métodos
ágeis mais conhecidos. Sobre as características desse método, é correto afirmar:
a) o planning game é uma reunião que ocorre a cada iteração com o objetivo de discutir o que
foi feito na última iteração.
b) o código fonte que será executado no ambiente de produção é desenvolvido em pares, sendo
que o par se alterna nos papéis de condutor e navegador.
c) é importante tentar prever o que o cliente deseja e executar antes mesmo de comunicá -lo,
mostrando proatividade na resolução de possíveis problemas.
d) o código fonte de cada página pertence a um membro da equipe. Qualquer alteração a ser
realizada precisa ser informada ao respectivo membro.
2. (CESPE / Ministério da Economia – 2020) Grandes quantidades de horas extras são aceitáveis
em médio e longo prazo, para agilizar a entrega de requisitos.
3. (CESPE / Ministério da Economia – 2020) Como forma de agilizar as implantações de

novas releases nesse modelo, são acumulados grandes grupos de funcionalidades e
implantadas grandes releases.
4. (CESPE / Ministério da Economia – 2020) Os programadores trabalham em pares para que um

possa verificar e apoiar o trabalho do outro e, assim, realizem um bom trabalho.
5. (CESPE / Ministério da Economia – 2020) O refactoring de código não faz parte do modelo XP,
visto que a expectativa é a entrega ágil, e não deve ser considerada em tempo de projeto a
recriação de código para aprimoramento.
6. (CESPE / Ministério da Economia – 2020) O XP possui planejamento incremental com

requisitos registrados em histórias.
7. (IBFC / TRE-PA – 2020) Para aplicar valores e princípios do XP (Extreme Programming), durante
os processos e práticas ágeis de desenvolvimento de software, se propõe uma série específica
de práticas. Assinale a alternativa que apresenta algumas dessas "boas práticas" utilizadas
tradicionalmente em projetos, usando XP.
a) Reformation - Pair Programming - PlayStation Game

b) Refactoring - Pair Programming - Planning Game
c) Reformation - Pair Production - Planning Game
d) Refactoring - Pair Production - PlayStation Game

43089971860 -1644786
8. (UFCG / UFCG – 2019) Marque a alternativa INCORRETA com relação a Extreme

Programming (XP).
a) Comunicação, coragem e respeito são valores dessa metodologia.

b) Em XP, uma das regras é codificar os testes de unidade primeiro.
c) Refatoramento é uma prática recomendada nesse processo.
d) O código a ser enviado para produção é criado por duas pessoas trabalhando juntas em um
único computador.
e) O autor, Don Wells, exige que o processo seja seguido à risca, de forma que todas suas regras
devem ser respeitadas e, nenhum projeto pode ser realizado sem adaptações e/ou remoção
dessas regras.
9. (IDECAN / UNIVASF – 2019) Extreme Programming (XP), em sua essência, possui um conjunto
de regras que devem ser seguidas em projetos ágeis que queiram utilizá-la em sua completude.
Sobre as regras do XP, assinale a alternativa correta.
a) Apenas as operações mais críticas devem possuir testes unitários.

b) Todo o código-fonte de produção deve ser implementado em programação em pares.
c) A integração de código deve ser feita nos computadores dos desenvolvedores.
d) É importante estabelecer o papel de um XP Master, que será responsável pela implementação
da metodologia.
e) A velocidade do projeto deve ser medida com o objetivo de informar ao cliente o tempo médio
de correção de falhas.
10. (CESGRANRIO / UNIRIO – 2019) Uma das principais práticas de XP (Extreme Programming) é
o Iteration Planning Game. Entre as atividades realizadas em uma sessão de Iteration Planning,
está a:
a) definição, pelos programadores, de quais story cards serão implementados em uma iteração.
b) estimação do esforço que será necessário para implementar cada story card.
c) estimação da data de entrega de um release baseado na estimativa de esforço de cada story
card.
d) estimação, feita por cada programador, do tempo que será necessário para realizar cada
tarefa sob sua responsabilidade.
e) designação, por parte do coach, dos programadores que irão realizar as tarefas contidas na
lista de tarefas.
11. (CESPE / TCE-RO – 2019) No que diz respeito a processos e práticas ágeis, o desenvolvimento
incremental
a) é, assim como o test-driven development, uma prática da XP (Extreme Programming) que

exige teste automatizado, domain-driven design, refactoring e integração contínua.

43089971860 -1644786
b) é, na XP (Extreme Programming), sustentado por meio de pequenos e frequentes releases do

sistema, e os clientes estão intimamente envolvidos na especificação e na priorização dos
requisitos do sistema.
c) enfoca, assim como o acceptance test-driven development, a qualidade do código

desenvolvido quanto a recursividade, declaração das variáveis e clean code, de modo a torná-lo
de fácil entendimento, modificação e testagem
d) pressupõe o uso do behavior driven development, que considera a linguagem de

programação a ser usada, da 4.ª geração em diante, com foco, principalmente, no
comportamento visual, interativo e cognitivo do sistema.
e) enfoca a integração contínua como uma prática de desenvolvimento de software,

incompatível com a XP (E xtreme Programming) e o Scrum, que permite aos desenvolvedores
agregarem alterações de código e realizarem testes.
12. (FCC / SANASA Campinas – 2019) Em um projeto de software baseado na metodologia ágil
XP, um Analista de TI deve
a) consultar o cliente quando uma história exigir, por estimativa, menos do que 3 semanas de
desenvolvimento, para que o cliente a complemente com mais tarefas.
b) ouvir o cliente, durante o levantamento de requisitos, para que este crie as histórias de
usuários. Após essa importante etapa nenhuma história nova deve ser criada para não
comprometer o cronograma do projeto.
c) evitar que o projeto caia na armadilha de seguir o princípio KISS de forma a estimular que o
projeto de uma funcionalidade extra, que poderá ser necessária no futuro, faça parte do modelo
do software.
d) realizar os testes de unidade de forma manual, evitando que sejam usadas baterias de testes
automatizados, pois estes impedem a realização de testes de regressão.
e) estimular o uso de cartões CRC como um mecanismo eficaz para pensar o software em um
contexto orientado a objetos.
13. (INSTITUTO AOCP / UFPB – 2019) Um dos principais métodos ágeis de desenvolvimento de
software foi concebido para impulsionar práticas reconhecidas como boas, por exemplo, o
desenvolvimento iterativo a nível extremo, em que novas versões de um determinado sistema
podem ser implementadas, integradas e, até mesmo, testadas em um único dia por
programadores diferentes. Essa é uma das características de qual método de desenvolvimento
ágil de software?
a) Scrum.

43089971860 -1644786
b) Adaptative Software Development.

c) Extreme Programming.
d) Pramatic Programming.
e) Test Driven Development.
14. (FCM / Prefeitura de Caranaíba - MG – 2019) De acordo com Pressman e Maxim (2016), a
Programação Extrema (Extreme Programming – XP) é uma abordagem amplamente utilizada
do desenvolvimento ágil de software que consiste das atividades:
a) Planejamento (Planning) / Projeto (Designing) / Codificação (Coding) / Teste (Test).

b) Colaboração (Collaboration) / Projeto (Designing) / Codificação (Coding) / Teste (Test).
c) Colaboração (Collaboration) / Projeto (Designing) / Codificação (Coding) / Teste (Test) /
Adaptação (Adaptation).
d) Colaboração (Collaboration) / Projeto (Designing) / Codificação (Coding) / Teste (Test) /
Adaptação (Adaptation) / Melhoria (Improvement).
15. (VUNESP / Câmara de Piracicaba - SP – 2019) Um dos processos ágeis de desenvolvimento

de software é a programação extrema (extreme programming – XP), cuja fase ou atividade
inicial é composta pela descrição dos cenários (características e funcionalidades) requisitadas
para o software a ser desenvolvido. Essa atividade recebe a denominação de:
a) métodos práticos.
b) histórias de usuário.
c) estruturas de apoio.
d) classes de projeto.
e) artefatos de usuário
16. (CESPE / TJ-AM – 2019) No XP (Extreme Programming), o valor de uma história de usuário é
atribuído pelos membros da equipe e é medido em termos de semanas estimadas para o
desenvolvimento.
17. (INSTITUTO AOCP / ADAF - AM – 2018) Na metodologia ágil Extreme Programming (XP), a
propriedade do código é coletiva, dessa forma, todos compartilham o mesmo orgulho e as
mesmas críticas. Considerando o exposto, assinale a alternativa que apresenta uma das regras
da codificação em XP.
a) No Overtime.
b) Eliminar gargalos de hardware no início.
c) O usuário não deve participar do planejamento das interfaces.
d) No Outsourcing.
e) No Sprint.
18. (AOCP / SUSIPE-PA – 2018) Sobre as práticas do XP (Extreme Programming), assinale a

alternativa INCORRETA.

43089971860 -1644786
a) O cliente deve conduzir o desenvolvimento a partir do feedback que recebe do sistema.

b) O código deve ser padronizado, visando tornar o sistema mais homogêneo.
c) O XP trabalha com releases curtos, buscando a integração contínua de valor para o cliente.
d) O XP trabalha com código coletivo, no qual todos os membros da equipe têm acesso ao
código.
e) O XP utiliza-se de programação em par para permitir que o código seja revisado
permanentemente enquanto é desenvolvido.
principais metodologias ágeis já propostas. A respeito de XP, considere as afirmativas abaixo.
I XP promove a execução de testes automatizados de avaliação do desempenho a cada iteração

de desenvolvimento do sistema.
II Em XP, os requisitos do sistema são especificados através de casos de uso.
III A prática de integração contínua do XP envolve a geração frequente de versões (builds) do
sistema, assim como execução dos testes automatizados sobre as versões geradas.
IV A prática de refatoração do XP envolve a modificação interna do código de classes do sistema,
mas sem modificar seu comportamento externo (interfaces dos métodos).
a) III e IV.
b) I e II.
c) I e III.
d) II e IV.
principais metodologias ágeis já propostas. Considere as seguintes afirmativas a respeito de
suas práticas.
I A técnica de refatoração promove mudanças no código que visam à adição de novas

funcionalidades.
II XP determina a produção de um executável do sistema desenvolvido a cada iteração.
III XP motiva a criação de projetos simples onde requisitos futuros não são inicialmente
contemplados.
IV Integração contínua consiste na geração de builds diários do sistema.
a) II e IV.
b) I e IV.
c) I e III.
d) II e III.

43089971860 -1644786
21. (IF-RS / IF-RS – 2018) Sobre as práticas encontradas na metodologia ágil de desenvolvimento
de software, conhecida por Programação Extrema (XP Programming), de acordo com Dooley
(2017) no livro Software Development, Design and Coding, classifique cada uma das afirmativas
abaixo como verdadeira (V) ou falsa (F) e assinale a alternativa que apresenta a sequência
CORRETA, de cima para baixo:
( ) Participação intensa do representante do cliente no desenvolvimento do projeto.
( ) Testes são realizados continuamente. Quando todos os testes forem aprovados, o módulo foi
concluído.
( ) Programação em par: enquanto um escreve o código, o outro monitora falhas, realiza testes,
faz sugestões e planeja próximas ações.
( ) Lançamentos frequentes de novas versões.
a) F – V – V – F
b) V – F – F – V
c) V – V – F – V
d) V – V – V – V
e) F – F – V – V
22. (IADES / ARCON-PA – 2018) Um dos métodos de desenvolvimento de software mais

conhecido e utilizado é o extreme programming (XP). Esse consiste em um modelo:
a) que evita a refatoração de código.

b) que realiza testes de integração apenas ao final de todo o desenvolvimento.
c) que valoriza o trabalho de forma individualizada, evitando a programação em pares.
d) que busca atender às necessidades atuais, e nada mais.
e) no qual não se faz necessária a disponibilidade de um representante do cliente a todo o
tempo.
23. (CESPE / ABIN – 2018) Na extreme programming, como não há especificação de sistema que
possa ser usada por equipe de teste externa, a característica de test-first exige que os
implementadores de tarefa compreendam detalhadamente a especificação de comportamento
da funcionalidade em desenvolvimento, a fim de que possam escrever o teste para o sistema.
24. (FCC / DPE-AM – 2018) Considere a definição de algumas práticas da eXtreme Programming −
XP.

43089971860 -1644786
I. Todo o código desenvolvido pelo time é incorporado em um repositório comum várias vezes
ao dia. Isso garante que qualquer problema de integração ao longo do projeto possa ser notado
e corrigido rapidamente.
II. Qualquer programador do time pode alterar qualquer seção do código, se necessário. Por
mais que esta prática pareça perigosa, ela aumenta a velocidade do desenvolvimento e
problemas em potencial podem ser detectados pelos testes de unidade.
III. Traz a ideia de que qualquer pessoa do time seja capaz de verificar o código sendo
desenvolvido em alto nível e ter uma compreensão clara de qual funcionalidade do sistema está
sendo trabalhada.
IV. Permite aplicar melhorias ao código sem mudar sua funcionalidade, visando sua
simplificação. Se o cliente deseja alterar alguma coisa no produto final, o time pode fazer os
ajustes rapidamente, e esta prática contribui para alcançar este objetivo.
As práticas de I a IV são, correta e respectivamente,
a) pair programming – test-driven development – system metaphor – continuous integration.

b) planning game – pair programming – system simplicity – continuous integration.
c) planning game – test-driven development – system simplicity – refactoring.
d) continuous integration – pair programming – feedback – planning game.
e) continuous integration – collective code ownership – system metaphor – refactoring.
25. (FAURGS / TJ-RS – 2018) Considere as seguintes afirmações sobre princípios ou práticas da XP
(Extreme Programming).
I - Um representante do usuário final do sistema (cliente) deve estar disponível todo o tempo à
equipe de XP. Em um processo de Extreme Programming, o cliente é um membro da equipe de
desenvolvimento e é responsável por levar ao grupo os requisitos de sistema para
implementação.
II - Todos os desenvolvedores devem refatorar o código continuamente, assim que encontrarem

oportunidades de melhorias de código.
III - Os desenvolvedores trabalham em todas as áreas do sistema, de modo que não se

desenvolvam ilhas de expertise. Todos os desenvolvedores têm responsabilidade em relação ao
código; qualquer um pode mudar qualquer coisa.
a) Apenas I.
b) Apenas I e II.
c) Apenas I e III.

43089971860 -1644786
d) Apenas II e III.
e) I, II e III.
26. (FUNRIO / Câmara de São João de Meriti - RJ – 2018) A figura abaixo ilustra a metodologia
Extreme Programming (XP) que usa uma abordagem orientada a objetos, incluindo um
conjunto de regras e práticas que ocorrem ao longo do desenvolvimento do projeto.
As fases I, II, III e IV são denominadas respectivamente:
a) modelagem, construção, implantação e homologação.

b) planejamento, construção, codificação e homologação.
c) planejamento, projeto, implantação e teste.
d) planejamento, projeto, codificação e teste.
e) modelagem, projeto, codificação e homologação.
27. (INSTITUTO AOCP / PRODEB – 2018) O método de desenvolvimento ágil denominado de XP

(Extreme Programming) tem sua estrutura baseada em algumas prerrogativas, dentre as quais,
é correto citar como princípios do XP:
a) Princípio da Legalidade, Princípio da Agilidade e Princípio do Feedback.

b) Princípio da Coragem, Princípio da Agilidade e Princípio da Simplicidade.
c) Princípio da Comunicação, Princípio da Simplicidade, Princípio do Feedback e Princípio da
Coragem.
d) Princípio da Agilidade, Princípio da Qualidade, Princípio do Feedback e Princípio da Coragem.
e) Princípio da Simplicidade, Princípio do Desenvolvimento e Princípio de Governança.
28. (INSTITUTO AOCP / PRODEB – 2018) O Pair Programming (Programação em Pares) é uma
característica de um determinado método de desenvolvimento de software em que dois
programadores trabalham juntos no desenvolvimento de um código. Qual foi o método que
criou essa prática?

43089971860 -1644786
a) Lean.
b) XP.
c) Scrum.
d) FDD.
e) Cascata.
29. (INSTITUTO AOCP / UFOB – 2018) Uma das práticas do Extreme Programming é o uso do
código coletivo, na qual todos os desenvolvedores têm acesso ao código.
30. (IBADE / IPM - JP – 2018) Metodologias ágeis podem ser aplicadas para facilitar a adaptação
do processo de desenvolvimento de software a mudanças. Trata-se de uma abordagem de
desenvolvimento de software ágil amplamente conhecida e utilizada, denominada:
a) desenvolvimento direto.
b) modelagem extrema.
c) programação dinâmica.
d) modelagem direta.
e) programação extrema.
31. (INSTITUTO AOCP / PRODEB – 2018) Extreming Programming (XP) é um método de

desenvolvimento ágil amplamente utilizado pelas software houses. Com base neste método,
qual alternativa a seguir possui uma prática que NÃO faz parte do XP?
a) Small Releases (Pequenas Entregas).

b) Pair Programming (Programação em Pares).
c) Sprint Review (Reunião de revisão da Sprint).
d) Sustainable Pace (Ritmo Saudável).
e) Collective Owership (Posse Coletiva).
32. (CESPE / BNB – 2018) Em XP, a técnica de planning game é utilizada pelo cliente para
identificar as prioridades do que deve ser construído em um software, sem a participação dos
desenvolvedores.
33. (CESPE / ABIN – 2018) O ritmo ágil de desenvolvimento de softwares é uma prática usada para
favorecer a entrega das releases quando grandes volumes de horas extras são tolerados.
34. (CESPE / ABIN – 2018) Para apoiar a equipe de desenvolvimento, é uma prática o uso do
cliente on-site em tempo integral.
35. (CESPE / STM – 2018) Na XP (Extreme Programming), programadores trabalham em pares, e

requisitos são expressos como cenários, denominados histórias de usuários, os quais são
implementados como uma série de tarefas.

43089971860 -1644786
36. (FCC / TST – 2017) Uma dupla de programadores, utilizando o modelo Extreme Programming −
XP, realiza, na fase de:
a) desenvolvimento, a implementação das user stories que fazem parte da iteração corrente.
b) desenvolvimento, a entrega das user stories totais do sistema.
c) validação do sistema, a análise dos requisitos técnicos entregáveis.
d) validação do sistema, a integração total dos incrementos das user stories.
e) projeto da arquitetura do sistema, a implementação das user stories totais do sistema.
37. (CESPE / TRT - 7ª Região (CE) – 2017) Acerca de metodologia XP, assinale a opção correta.
a) Para atingir a agilidade necessária, a equipe de desenvolvimento deve ser composta de

pessoas com experiência comprovada na linguagem utilizada.
b) A prática de planning game do XP permite que o escopo do projeto seja alterado a cada
semana.
c) Mesmo sendo considerada uma metodologia ágil, XP exige uma especificação completa e
formal dos requisitos.
d) Em XP, denomina-se explanação o processo por meio do qual uma pessoa tenta explicar um
assunto fazendo comparações com o mundo real.
38. (IBFC / TJ-PE – 2017) Está sendo implementado o XP (eXtreme Programming) em uma equipe
de TI. Para tanto, está sendo colocada a seguinte série de práticas específicas da metodologia
XP em análise:
I. Programação Pareada (Pair Programming).

II. Fases pequenas (Small Releases).
III. Refatoração (Refactoring).
IV. Jogo de Planejamento (Planning Game).
Com base no seu conhecimento sobre a metodologia citada acima, suas práticas específicas
estão corretamente relacionadas nos itens:
a) I, II e III, apenas
b) I, II e IV, apenas
c) II, III e IV, apenas
d) I, III e IV, apenas
e) I, II, III e IV
39. (FCC / DPE-RS – 2017) Considere que um Analista esteja participando de um projeto que utiliza
as melhores práticas da Extreme Programming − XP. No início de uma iteração a equipe de
desenvolvimento, da qual o Analista fazia parte, convidou o cliente a escrever as funcionalidades
que desejava no sistema em pequenos cartões chamados user stories. Depois disso, a equipe de
desenvolvimento estimou o tempo e o custo de cada funcionalidade para o cliente. O cliente foi

43089971860 -1644786
informado do tempo e custo, e foi solicitado a decidir a prioridade em que cada user
story deveria ser desenvolvida. Esta prática XP é conhecida como:
a) Releases e é utilizada para que o cliente possa utilizar o sistema, possibilitando à equipe de
desenvolvimento saber se há defeitos ou não no código.
b) Releases e visa reorganizar o código fonte para melhorar sua qualidade interna, facilitar seu
entendimento pelo cliente e diminuir o tempo gasto com manutenção.
c) Metáforas e permite que o cliente transmita ideias complexas de forma simples e clara,
usando um vocabulário comum.
d) Planning Game e permite que o Analista e outro desenvolvedor escolham uma user story e
codifiquem juntos aquela funcionalidade. ==1918f2==
e) Planning Game e busca assegurar que a equipe esteja sempre trabalhando no que é mais
importante e gere mais valor para o cliente.
40. (CESPE / TRE-BA – 2017) Considerando uma situação hipotética com o uso da XP (eXtreme
Programming) concomitante com Scrum em um projeto de desenvolvimento de software em
uma organização, julgue os seguintes itens.
I. É viável a utilização do TDD (Test Driven Development) na fase de sprint, de modo que se
escreva o teste automático antes da codificação.
II. O princípio da integração contínua da XP deve ser utilizado especificamente na retrospectiva

da sprint com vistas a integrar a equipe scrum.
III. Integrantes da equipe scrum podem realizar a programação do código em pares, o que
proporciona, entre outras vantagens, o nivelamento de conhecimento da equipe.
IV. O conceito de requisito “pronto” continuaria válido, contudo, inviabilizaria o refactoring, pois
é proibitivo inserir o mesmo item (requisito) em várias sprints.
Estão certos apenas os itens:
a) I e II.
b) I e III.
c) II e IV.
d) I, III e IV.
e) II, III e IV
41. (UFG / SANEAGO – 2017) Dentro do framework Extreme Programming (XP), uma metodologia
ágil, a ação de teste de código é responsabilidade da pessoa:

43089971860 -1644786
a) diretamente ligada à criação do artefato em questão.

b) responsável pela equipe de teste de software, que não pode ser a pessoa que o desenvolve.
c) utilizadora do código diariamente.
d) facilitadora da comunicação entre a equipe de desenvolvimento e o cliente.
42. (CESPE / TRE-TO – 2017) Em projetos de desenvolvimento de software, a extreme

programming (XP) é um método ágil que usa a prática de:
a) projetos com planejamento completo sem incrementos.

b) grandes releases.
c) grande quantidade de horas extras.
d) trabalho em pares de desenvolvedores.
e) integrações após a entrega do software completo.
43. (IBFC / EBSERH – 2017) Dentro das práticas do XP (eXtreme Programming) existe uma
fundamental que é o Jogo de Planejamento (Planning Game). Para serem realizadas
adequadamente essas reuniões com os usuários, deve(m) ter sido feito(s) antecipadamente:
a) o Sustainable Pace
b) as Small Releases
c) os Customer Tests
d) as User Stories
e) um Simple Design
44. (FCC / CREMESP – 2016) Considere que nos projetos do CREMESP baseados em XP pratica-se
a propriedade coletiva de código, de forma que todos os desenvolvedores podem fazer
alterações e refatoração de qualquer parte do código a qualquer momento. Para isso, é
necessário que também haja:
a) padrões de codificação.
b) time-box de 40 horas.
c) testes apenas depois da codificação.
d) releases grandes.
e) integração das funcionalidades, mesmo com erros.
45. (COPEVE-UFAL / UFAL – 2016) Assinale a alternativa que contém apenas características ou
práticas relacionadas ao método ágil para desenvolvimento de softwares Extreme
Programming (XP):
a) Planejamento incremental, cliente disponível em tempo integral e programação em pares.

b) Requisitos expressos como cenários, programação incremental e programação individual.
c) Cliente não participa do desenvolvimento, desenvolvimento em cascata e programação em
pares.

43089971860 -1644786
d) Equipe heterogênea especializada, requisitos expressos como histórias e desenvolvimento

em espiral.
e) Toda equipe altera qualquer parte do código, desenvolvimento em cascata e programação
individual.
46. (IF-PE / IF-PE – 2016) Extreme Programming é uma metodologia ágil para equipes pequenas e
médias que desenvolvem software com requisitos vagos e em constante mudança. Sobre os
valores do XP, analise as definições abaixo e assinale a alternativa CORRETA.
a) Simplicidade - procura-se que a equipe concentre-se, primeiro, em fazer o necessário.

b) Comunicação - prioriza-se a troca de e-mail como melhor forma de comunicação,
independente do horário.
c) Coragem - a metodologia XP prega coragem para dizer “não” ao cliente e evitar mudanças do
projeto.
d) Feedback - é valorizado o feedback positivo do cliente. Desta forma, procura-se evitar a
entrega de software sem a realização de testes detalhados.
e) Respeito - prega o respeito à hierarquia, ouvindo e respeitando, apenas, o que é determinado
pelo líder de projeto.
47. (CESPE / FUNPRESP-JUD – 2016) Uma característica da metodologia XP é a existência de uma

equipe técnica voltada para a agilidade e velocidade do desenvolvimento do software, de forma
que todo o desenvolvimento seja feito sem a interferência ou ajuda do cliente até que
os releases sejam disponibilizados para que o desenvolvimento se torne o mais ágil possível.
48. (FCC / Prefeitura de Teresina – PI – 2016) Os métodos ágeis de desenvolvimento

de software como eXtreme Programming – XP consideram um conjunto de valores
fundamentais derivados do manifesto ágil. Assim, estes métodos valorizam MENOS:
a) os indivíduos e a interação entre eles, do que os processos e ferramentas.

b) o software funcionando, do que uma documentação abrangente.
c) a colaboração com o cliente, do que negociação de contratos.
d) a resposta rápida a mudanças, do que seguir um plano previamente definido.
e) a rigorosidade dos processos, do que a adaptação às mudanças.
49. (CESPE / TCE-PA – 2016) Em XP (Extreme Programming), as user stories não objetivam definir
o escopo global do sistema, mas avaliar a complexidade de cada uma de suas partes a fim serem
estimados prazos na perspectiva dos usuários ou clientes do sistema.
50. (UFCG / UFCG – 2016) Sobre XP (Extreme Programming), marque a assertiva INCORRETA.
a) É um processo criado por Kent Beck.

b) São exemplos de boas práticas do processo: desenvolvimento orientado a testes, pair
programming e documentação em todas as suas fases.

43089971860 -1644786
c) Esse processo almeja reduzir o custo de mudanças a partir de múltiplos ciclos de

desenvolvimento de curta duração.
d) Simplicidade ao projetar e programar é uma das chaves para o sucesso na visão do XP.
e) Nesse processo, deve-se refatorar o código sempre que possível.
51. (IF-SE / IF-SE – 2016) A Programação Extrema (Extreme Programming - XP) possui diversas
práticas. Analise as afirmativas abaixo.
I. As releases do sistema são frequentes e incrementais.

II. Os requisitos são representados através de casos de uso.
III. Os desenvolvedores não trabalham em pares.
IV. Depois de qualquer integração, todos os testes de unidade devem passar.
De acordo com as afirmativas, marque a alternativa CORRETA
a) As afirmativas I e II estão incorretas.

b) Apenas as afirmativas I e II estão corretas.
c) As afirmativas II e III estão incorretas
d) As afirmativas III e IV estão incorretas
52. (FGV / Prefeitura de Paulínia - SP – 2016) A empresa de desenvolvimento de

sistemas “Inovation” tem ampla experiência no mercado e, até o momento, utilizou diversos
modelos de ciclo de vida para o desenvolvimento de sistemas. A “Inovation” já recebeu diversas
reclamações dos seus clientes por causa da demora em apresentar alguma tela em
funcionamento, bem como da falta de envolvimento dos clientes no desenvolvimento. A
empresa, assim, decidiu passar a utilizar um novo modelo de ciclo de vida. Esta decisão visa
aproveitar a grande experiência de sua equipe e trazer o cliente para a equipe de
desenvolvimento, com iterações de desenvolvimento extremamente curtas. Qualquer membro
da equipe implementa parte do código, que pode ser evoluído por qualquer outro membro.
O novo modelo adotado pela “Inovation” é denominado:
a) Extremme Programming (XP).

b) Modelo V.
c) Evolutivo.
d) Incremental.
e) Espiral.
53. (IF-PE / IF-PE – 2016) Com relação à metodologia ágil de desenvolvimento de software
conhecido como eXtreme Programming (XP), quais são os quatro processos ou atividades
metodológicas encontradas nela?
a) Análise, projeto, codificação e teste.

b) Planejamento, análise, projeto e codificação.
c) Planejamento, projeto, codificação e testes.
d) Planejamento, análise, codificação e testes.

43089971860 -1644786
e) Levantamento, análise, projeto e codificação.
54. (IBFC / EBSERH – 2016) Equipes XP (eXtreme Programming) planejam utilizando histórias
escritas em pequenos cartões. Essas histórias devem ter como objetivo:
a) a modelagem de dados
b) as métricas de software
c) os requisitos não-funcionais
d) os requisitos funcionais
e) tanto os requisitos funcionais como os requisitos não-funcionais
55. (IBFC / EBSERH – 2016) Para aplicar os valores e princípios durante o desenvolvimento de
software, a Programação Extrema (eXtreme Programming - XP) propõe uma série de práticas.
Selecione a única alternativa que NÃO seja uma dessas práticas:
a) Time Coeso (Whole Team).

b) Design Complexo (Complex Design).
c) Programação Pareada (Pair Programming).
d) Semana de 40 horas (Sustainable Pace).
e) Refatoração (Refactoring).
56. (CESPE / FUNPRESP-JUD – 2016) A programação em pares, em que os desenvolvedores

atuam avaliando entre si o trabalho do outro, é uma prática da metodologia XP.
57. (CESPE / FUNPRESP-JUD – 2016) As práticas da extreme programming, que tem por princípio
liberar grandes releases de software, visam agregar valor ao negócio.
58. (CESPE / TRT-PR – 2016) Um projeto desenvolvido mediante XP (Extreme Programming)

segue princípios opostos aos de um projeto implementado com base em KIS (Keep It Simple).
59. (IDECAN / INMETRO – 2015) Na extreme programming, todos os requisitos são expressos
como cenários (chamados histórias do usuário) que são implementados diretamente como uma
série de tarefas. Sabe-se que o extreme programming envolve um número de práticas que se
enquadram nos princípios dos métodos ágeis. Acerca de algumas dessas práticas, relacione
adequadamente as colunas a seguir.
1. Releases pequenos.
2. Refactoring.
3. Propriedade coletiva.
4. Integração contínua.
5. Ritmo sustentável.
( ) Os pares de desenvolvedores trabalham em todas as áreas do sistema, de tal maneira que não
se formem ilhas de conhecimento.

43089971860 -1644786
( ) O conjunto mínimo útil de funcionalidade que agrega valor ao negócio é desenvolvido

primeiro.
( ) Grandes quantidades de horas-extras não são consideradas aceitáveis, pois, no médio prazo,
há uma redução na quantidade de código e na produtividade.
( ) Espera-se que todos desenvolvedores recriem o código continuamente tão logo os
aprimoramentos do código forem encontrados.
( ) Tão logo o trabalho em uma tarefa seja concluído, este é integrado ao sistema como um todo
a) 5, 3, 1, 4, 2.
B) 2, 4, 3, 5, 1.
c) 4, 5, 2, 1, 3.
d) 3, 1, 5, 2, 4.
e) 5, 2, 4, 3, 1.
60. (CESPE / TRE-RS – 2015) Tendo em vista que, em um processo ágil de desenvolvimento
de software, foi adotado o XP (eXtreme Programming) e que os requisitos levantados foram
expressos na forma de histórias de usuário, assinale a opção que apresenta, corretamente,
recomendações técnicas para a elaboração de um cartão de histórias de usuário.
a) Como um professor, quero calcular as médias semestrais dos alunos de modo que eu possa
identificar quais serão aprovados.
b) O professor deseja o cálculo de notas semestrais com precisão de até duas casas decimais.
c) O sistema deve calcular as médias semestrais dos alunos com base nas notas atribuídas a eles
pelos professores.
d) Como analista de requisitos, eu preciso oferecer o cálculo das notas semestrais aos
professores em menos de um minuto.
e) Como um professor, eu preciso de releases semanais de funcionalidades, mesmo que elas
possam ser refatoradas posteriormente.
61. (FCC / TRE-PB – 2015) Extreme Programming − XP pode ser considerado um modelo de
desenvolvimento de software baseado em uma série de valores, princípios e regras, dentre eles,
a) criar obrigatoriamente uma matriz de rastreabilidade de requisitos.

b) manter o foco na documentação, detalhada e diversificada.
c) definir sprint de no máximo duas semanas.
d) escrever sempre o código, depois, o teste de unidade.
e) realizar semanalmente o jogo do planejamento (planning game).
62. (UFPel-CES / UFPEL – 2015) Em projetos nos quais se aplicam o método ágil XP, a fase em que
o propósito é empresa e cliente concordarem em uma data na qual o menor e melhor conjunto
de histórias de usuários deverá ser implementado é a fase de:
a) planejamento.
b) exploração.

43089971860 -1644786
c) iterações e entregas.
d) produção.
e) manutenção.
63. (CS-UFG / AL-GO – 2015) Extreme Programming (XP) é um exemplo de método ágil que foi
definido por Kent Beck. O XP inclui uma abordagem de teste que:
a) valoriza o desenvolvimento test-last.

b) depende da técnica de teste baseada em defeitos
c) desenvolve teste incremental baseado em cenários
d) utiliza processo de teste dirigido a planos.
64.(CESPE / TJDFT – 2015) Na metodologia XP (extreme programming), em que todos os

requisitos são expressos como cenários, deve-se aguardar, após a conclusão das tarefas, ciclos
de cento e oitenta dias para a publicação de grandes releases do software.
65. (CESPE / TJDFT – 2015) As características da metodologia XP incluem o desenvolvimento

interativo, que dispõe de um processo de testes informais.
66. (CETRO / AMAZUL – 2015) Assinale a alternativa que não apresenta um princípio/ valor da
metodologia de desenvolvimento de software XP (Extreme Programming):
a) Simplicidade.
b) Programação individual ou não em pares.
c) Comunicação.
d) Coragem.
e) Feedback.
67. (CESPE / TRE-RS – 2015) Em um desenvolvimento ágil de sistemas utilizando o XP, foram
adotadas as seguintes ações: foi dita a verdade ao cliente acerca do progresso do projeto e
acerca de suas estimativas, além de haverem sido realizadas adaptações quando mudanças
importantes aconteceram no projeto. Essas ações estão coerentes com o valor do XP
denominado:
a) sinceridade.
b) comunicação.
c) coragem.
d) feedback.
e) respeito.
68. (CESPE / TRE-RS – 2015) Assinale a opção que apresenta uma característica relacionada a
projetos que utilizam o método XP (eXtreme Programming), muito utilizado em projetos para
o desenvolvimento de softwares.

43089971860 -1644786
a) grandes releases
b) programação individual
c) cliente off-site
d) grandes volumes de horas extras
e) planejamento incremental
69. (CESPE / STJ – 2015) Na Extreme Programming, a programação em pares cria ilhas de
especialistas na equipe por meio da análise simultânea de duas pessoas no desenvolvimento
do software.
70. (IESES / TRE-MA – 2015) No desenvolvimento de software em XP, são empregadas algumas
práticas. Avalie as assertivas abaixo:
I. Programação em pares.
II. Time coeso.
III. Integração contínua.
IV. Desenvolvimento orientado a testes.
Quantas afirmativas são verdadeiras?
a) 2
b) 1
c) 4
d) 3
71. (CESPE / FUB – 2015) Práticas de desenvolvimento de software aos pares de programadores,
em que um programador verifica o trabalho do outro, são uma característica do método de
desenvolvimento XP.
72. (CESPE / FUB – 2015) É considerada como ritmo sustentável a carga horária de trabalho
extensa para gerar rapidamente entregas de produtos de software, o que provoca grande
quantidade de horas extras.
73. (FUNCAB / SEFAZ-BA – 2014) São características do Extreme Programming (XP), EXCETO:
a) apresentar desenvolvimento incremental.

b) admitir a existência de uma especificação detalhada.
c) utilizar programação com pares de desenvolvedores.
d) permitir a integração de usuário com o time de desenvolvimento.
e) suportar testes automáticos contínuos.
74. (INSTITUTO AOCP / MPE-BA – 2014) O processo ágil XP possui doze práticas que são os
princípios fundamentais do processo. A prática que encoraja a equipe inteira a trabalhar mais

43089971860 -1644786
unida em busca de qualidade no código fazendo melhorias e refatoramentos em qualquer parte

do código a qualquer tempo é conhecida como:
a) propriedade coletiva do código.

b) semana de quarenta horas.
c) programação em pares.
d) padrões de codificação.
e) integração contínua.
75. (FGV / Câmara Municipal do Recife-PE – 2014) Uma das práticas do método ágil XP (eXtreme
Programming) é:
a) documentação extensiva;
b) prototipação;
c) ciclos longos de desenvolvimento;
d) desenvolvimento orientado a testes (TDD);
e) utilização de todos os artefatos do RUP.
76. (FUNCAB / MDA – 2014) A “Extreme Programming - XP” representa um dos mais conhecidos
métodos ágeis. Uma das práticas utilizadas na XP é:
a) empregar um esquema em que os desenvolvedores trabalham individualmente.

b) integrar o sistema exclusivamente quando todos os módulos forem concluídos.
c) usar cenários para expressar requisitos implementados como uma série de tarefas.
d) impedir que o cliente interaja com a equipe de desenvolvimento na fase de especificação.
e) eliminar a necessidade da realização de testes durante a fase de desenvolvimento.
77. (CESGRANRIO / Banco da Amazônia – 2014) Uma prática que NÃO é adotada por Extreme
Programming (XP) é
a) usar duas pessoas trabalhando juntas em um único computador para produzir todo o código
que será enviado para a produção.
b) criar os testes antes do código que será testado.
c) refatorar frequentemente, e ao longo de todo o projeto, o código produzido pelos

desenvolvedores.
d) integrar continuamente o código recém-produzido com o código existente no repositório.
e) variar a duração de cada iteração durante todo o projeto para acomodar eventuais mudanças
de prioridade dos requisitos, definidas pelo cliente.

43089971860 -1644786
78. (CESPE / ANTT – 2013) São práticas ou princípios recomendados no modelo de

desenvolvimento de software XP (eXtreme Programming) proposto por Kent Beck:
programação em pares; semana de trabalho de 40 horas; refatoração sem piedade;
desenvolvimento orientado a testes TDD (Test Driven Development); e desenvolvimento de
metáforas arquiteturais.
79. (CESPE / STF – 2013) XP (Extreme Programming) é uma metodologia ágil voltada para equipes
pequenas e médias que desenvolvam software baseado em requisitos vagos e se caracteriza por
possibilitar modificações rápidas.
80. (CESPE / TCE-RO – 2013) No método XP (eXtreming programming), os sistemas são

concebidos a partir de uma metáfora e descritos em estórias do usuário. Esse método busca
facilitar a comunicação com o cliente, entendendo a realidade deste e guiando o
desenvolvimento com o uso de estória simples.
81. (CESPE / MPU 2013) XP é um método de desenvolvimento de software em que os requisitos

são especificados em user stories; requisitos, arquitetura e design surgem durante o curso do
projeto; e o desenvolvimento ocorre de maneira incremental.
82. (CESGRANRIO / BNDES – 2013) Sendo atualmente conhecida por just-in-time, a produção
enxuta contém princípios que compõem a base dos processos ágeis de desenvolvimento de
software, como o Extremme Programming (XP). Um dos princípios básicos do XP, a eliminação
de desperdícios, busca:
a) evitar o efeito negativo que uma definição de risco, na fase inicial do projeto, possa causar na
performance do software como um todo, tendo, como saída, informações não relevantes para
o processo.
b) produzir requisitos bem definidos e completos de forma a abranger todos os processos e

rotinas administrativas, funcionais e produtivas almejadas pelos stakeholders envolvidos no
projeto.
c) reduzir, o máximo possível, o volume de trabalho executado e os subprodutos envolvidos

nesse trabalho, concentrando os esforços apenas no que pode produzir um resultado objetivo e
palpável ao cliente final.
d) descrever os processos que garantam a inclusão, no projeto, de todo o serviço necessário, e

somente o serviço necessário, para que esse projeto seja finalizado com sucesso.
e) descrever os processos envolvidos no planejamento, no monitoramento e na garantia de que

o projeto será realizado dentro dos prazos definidos no escopo, mantendo a qualidade definida
e o enxugamento dos custos inicialmente programados.

43089971860 -1644786
83. (CESPE / MPE-PI – 2012) O XP (Extreme Programming) é um método ágil, que preconiza a
criação de um caso de teste unitário antes do início da codificação.
84. (CESPE / ANAC – 2012) Para o método ágil de desenvolvimento conhecido como extreme
programming, todos os requisitos funcionais são expressos como cenários (histórias do usuário)
que são implementados diretamente como uma série de tarefas.
85. (CESPE / ANAC – 2012) A técnica conhecida como refactoring é constantemente aplicada no
desenvolvimento baseado no método ágil extreme programming.
86. (CESPE / ANAC – 2012) No modelo extreme programming, os testes de software só são
realizados na etapa final de desenvolvimento do software e, somente nessa etapa, os
programadores trabalham, obrigatoriamente, em pares, utilizando cada um o próprio
computador.
87. (CESPE / ANAC – 2012) Na metodologia ágil XP (extreme programming), as metáforas são
formas de transmitir ideias complexas de maneira simples, ou seja, utiliza-se uma linguagem
simples entre a equipe e o cliente, com o objetivo de que, entre as inúmeras variáveis de controle
em projetos, tais como tempo, custo, qualidade e escopo, obtenha-se maior foco no tempo, em
detrimento do planejamento do release.
88. (FCC / TST – 2012) O XP (Extreme Programming) utiliza uma abordagem orientada a
objetos como seu paradigma de desenvolvimento predileto. Ele:
a) recomenda que duas pessoas trabalhem juntas para criar o código correspondente a uma
história.
b) recomenda que a equipe XP e os clientes trabalhem de forma separada para não mudar o
compromisso básico definido para a versão a ser entregue.
c) segue rigorosamente o princípio FDD - Feature Driven Development.
d) recomenda que depois que as histórias forem desenvolvidas e o trabalho preliminar do

projeto for feito, a equipe XP avance diretamente para o código.
e) inclui um conjunto de regras e práticas que ocorrem no contexto de 3 atividades de arcabouço:

projeto, implementação e entrega.
89. (FCC / MPE-AP – 2012) O Extreme Programming (XP) é, talvez, o mais conhecido e mais
utilizado dos métodos ágeis. Dentre suas práticas se encontram programação em pares,
integração contínua, refatoração e:
a) propriedade coletiva, que garante uma participação nos lucros aos membros da equipe de
desenvolvimento, técnica que incentiva e aumenta o desempenho de toda a equipe.

43089971860 -1644786
b) envolvimento do cliente apenas na fase final do sistema, fator que difere de outras
metodologias como SCRUM e TDD e confere agilidade ao processo de desenvolvimento.
c) processo de desenvolvimento contínuo, em que a equipe se mantém focada no sistema até

que uma funcionalidade específica seja entregue, comumente agregando horas extras ao turno
de trabalho.
d) utilização de técnicas de ofuscação do código fonte, trazendo segurança e garantindo que

apenas a equipe de desenvolvimento poderá ter acesso a este código
e) desenvolvimento incremental e sustentado por meio de pequenos e frequentes releases do

sistema. Os requisitos são baseados em cenários ou em simples histórias de clientes.
90. (FCC / MPE-PE – 2012) Dentre as práticas do método ágil Extreme Programming (XP), está a
prática de propriedade coletiva. É correto afirmar que, nessa prática,
a) os trabalhos são desenvolvidos em conjunto, para que um programador possa analisar o

trabalho do outro.
b) cada projeto é realizado para atender às necessidades globais dos usuários, focando na
coletividade da distribuição da informação.
c) os pares de desenvolvedores trabalham em todas as áreas do sistema, de modo que não se

desenvolvam ilhas de expertise.
d) grandes quantidades de horas extras não são consideradas aceitáveis, pois o resultado final,
muitas vezes, é a redução da qualidade do código e da produtividade a médio prazo, sendo que
o indivíduo pode afetar o desempenho de todo o time.
e) um representante do usuário final do sistema deve estar disponível todo o tempo à equipe de
desenvolvimento. Nesse modelo de desenvolvimento, o cliente é membro da equipe e participa
da responsabilidade do código desenvolvido.
91. (FCC / TJ-PE – 2012) Nos métodos ágeis XP e Scrum, as entregas de partes funcionais do projeto
são divididas em ciclos, geralmente compreendidos no período de 1 a 4 semanas. Estes ciclos
denominam-se, respectivamente,
a) iterações e sprint.
b) reunião de planejamento e backlog.
c) período de entrega e reunião de revisão.
d) backlog e planejamento da produção.
e) entrega e retrospectiva.

43089971860 -1644786
92. (CESPE / EBC – 2011) O XP segue um conjunto de valores, princípios e regras básicas que visam
alcançar eficiência e efetividade no processo de desenvolvimento de software. Os valores são
cinco: comunicação, simplicidade, feedback, coragem e respeito.
93. (CESPE / STM – 2011) O Extreme Programming (XP), que se inclui entre os métodos ágeis,
apresenta, entre outras, as seguintes características: pequenos releases, projeto simples,
refactoring, programação em pares e propriedade coletiva.
94. (FCC / TRT-MT – 2011) NÃO se aplica à disciplina de desenvolvimento de software extreme
programming (XP):
a) Usa notações próprias para construir os diversos produtos de trabalho do projeto.
b) Encoraja a refabricação para modificar um sofware sem alterar o comportamento externo do

código.
c) Recomenda que dois programadores trabalhem juntos no mesmo computador para escrever
um código.
d) Baseada em valores de simplicidade, comunicação, feedback e coragem.
e) Adota como um elemento-chave a criação de testes unitários antes da codificação começar.
95. (FCC / TRE-RN – 2011) Considere as seguintes características:
I. Propriedade coletiva.
II. Integração contínua.
III. Metáfora.
Dentre as práticas componentes da Extreme Programming, aplica-se o que consta em:
a) I, apenas.
b) II, apenas.
c) I e II, apenas.
e) I, II e III.
96. (FCC / TRT-23 – 2011) No desenvolvimento de software em Extreme Programming (XP) há

uma confiança muito grande na sinergia entre as práticas, já que os pontos fracos de cada uma
são superados pelos pontos fortes de outras. Dentre elas, aquela em que o código fonte não tem
dono e ninguém precisa solicitar permissão para poder modificá-lo, permitindo, assim, que a
equipe conheça todas as partes do sistema, é chamada de:
a) Whole Team (Time Coeso).

43089971860 -1644786
b) Sustainable Pace (Ritmo Sustentável).

c) Pair Programming (Programação em Pares).
d) Collective Ownership (Posse Coletiva).
e) Coding Standards (Padrões de Codificação).
97. (FCC / TRE-RN – 2011) Assegurar que a equipe se concentre em fazer, primeiro, apenas aquilo
que é claramente necessário e evite fazer o que poderia vir a ser necessário, mas ainda não se
provou essencial. Este é um dos cinco valores fundamentais do XP (Extreme Programming),
denominado:
a) coragem.
b) respeito.
c) comunicação.
d) simplicidade.
e) feedback.
98. (CESPE / TRE-BA – 2010) Em XP, a prática denominada programação em pares (pair
programming) é realizada por um desenvolvedor em dois computadores, com o objetivo de
aumentar a produtividade.
99. (CESPE / ABIN – 2010) Na Extreme Programming, os requisitos são expressos como cenários
e implementados diretamente como uma série de tarefas. O representante do cliente faz parte
do desenvolvimento e é responsável pela definição de testes de aceitação do sistema.
100. (CESPE / MPU – 2010) Extreme programming (XP) é embasado em requisitos conhecidos,
definidos de antemão, que não sofram muitas alterações, devendo ser usado por equipes de
pequeno porte, formadas por representantes de todos os stakeholders.
101. (CESPE / TRE-BA – 2010) Os quatro valores fundamentais da metodologia XP são:

comunicação, simplicidade, feedback e coragem.
102. (CESPE / TCU – 2010) O processo XP (extreme programming) envolve a realização das
atividades de planejamento, de projeto, de codificação e de teste.
103. (FCC / TRE-RS – 2010) No eXtreme Programming, XP:
a) o código é integrado e testado depois de alguns dias e, no máximo, até o final da semana.
b) a codificação é feita em grupos de programadores (no mínimo 3 integrantes),

preferencialmente num único computador.
c) as equipes de desenvolvimento estabelecem suas próprias regras, mas uma equipe pode
adotar as regras de outra equipe.

43089971860 -1644786
d) releases quando complexos não podem deixar de fora os requisitos de negócio de maior valor
para o cliente.
e) módulos não são propriedade de nenhum desenvolvedor; todo desenvolvedor da equipe tem
o direito de checar um módulo e modificá-lo.
104. (FCC / MPE-RN – 2010) Refactoring, programação em pares e Stand-up Meeting são
características das práticas do:
a) PRINCE2.
b) Rational Unified Process.
c) Extreme programming.
d) PMBOK.
e) SCRUM.
105. (CESPE / SECONT-ES – 2009) Métodos ágeis de desenvolvimento de sistemas foram

propostos principalmente para apoiar o desenvolvimento de aplicações de negócios nas quais
os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento. Entre
esses métodos está o extreme programming, que envolve um número de práticas, como o
planejamento incremental, a definição de um ritmo de trabalho sustentável e a divisão das
equipes de trabalho por meio da especialização de seus membros.
106. (CESPE / IPEA – 2009) A extreme programming (XP) é um método de desenvolvimento ágil.
Nele, os requisitos são expressos como cenários implementados diretamente como uma série
de tarefas.
107. (CESPE / TRE-MG – 2009) Extreme programming é um método centrado no usuário, na

produtividade do desenvolvimento e na documentação de apoio.
108. (CESPE / TRE-BA – 2009) A metodologia XP prevê valores e princípios básicos para serem
considerados durante o desenvolvimento de software. Feedback, coragem e respeito são
exemplos de valores; mudanças incrementais, abraçar mudanças e trabalho de qualidade são
exemplos de princípios básicos.
109. (CESPE / ANAC – 2009) Extreme Programming é um modelo de processo de

desenvolvimento de software para equipes com grande número de pessoas, que desenvolvem
software com base em requisitos vagos e que são modificados rapidamente.
110. (CESPE / ANTAQ – 2009) O extreme programming (XP) constitui método ágil de
desenvolvimento de software. Uma das práticas que se enquadram nos princípios dos métodos
ágeis é a programação em pares, que promove o compartilhamento da autoria do código do
sistema. Além dessa vantagem, a programação em pares atua como processo informal de
revisão porque cada linha de código é vista por pelo menos duas pessoas.

43089971860 -1644786
111. (FCC / TJ-PI – 2009) XP (eXtreme Programming) é uma metodologia ágil para equipes
pequenas e médias que desenvolverão software com requisitos vagos e em constante mudança.
Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos
ajustes durante o desenvolvimento de software. Para aplicar os valores e princípios durante o
desenvolvimento de software, a XP propõe uma série de práticas, sendo uma delas: sempre que
produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do
sistema a fim de evitar o aumento da possibilidade de conflitos e da possibilidade de erros no
código fonte. Tal prática é denominada:
a) Time Coeso.
b) Refatoração.
c) Integração Contínua.
d) Desenvolvimento Orientado a Testes.
e) Ritmo Sustentável.
112. (CESPE / PRODEST – 2008) Projetar detalhadamente todo o software antes de iniciar a sua
implementação é uma prática recomendada pelo XP. O software deve ser projetado para
atender tanto aos requisitos atuais quanto aos potenciais requisitos futuros. Para atingir esse
objetivo, são analisados os possíveis cenários de evolução futura e são empregados padrões de
projeto para facilitar a manutenção.
113. (CESPE / PRODEST – 2008) Constituem práticas recomendadas pelo XP a colocação rápida
de uma versão simples em produção, a liberação das novas versões em curtos intervalos de
tempo, a programação em duplas, a refatoração (refactor) dos códigos produzidos, a adoção de
padrões para a codificação; a integração e o teste contínuos de códigos; a limitação em 40 horas
da carga de trabalho semanal.
114. (CESPE / PRODEST – 2008) O XP é um processo que visa a um desenvolvimento ágil e

portanto não recomenda os testes de unidade, pois eles consomem muitos recursos. Durante o
desenvolvimento, o primeiro teste recomendado é o smoke test que foca os detalhes de
funcionamento. O smoke test é realizado após as unidades serem integradas. Após o smoke
test, é realizado o teste de sistema.
115. (FCC / TCE-AL – 2008) Originalmente, o único produto da atividade de Projeto que é
realizado como parte do processo XP (Extreme Programming):
a) é a definição do caso de uso de contexto.

b) são os cartões CRC.
c) são os diagramas de objetos.
d) são os diagramas de seqüência.
e) é a codificação, feita em pares.
116. (FCC / TRE-SE – 2007) Na XP (eXtreme Programming):

43089971860 -1644786
a) deve-se usar o modelo em cascata para o desenvolvimento do software.
b) os programadores desenvolvem o software criando primeiramente os testes.
c) deve ser evitada a comunicação pessoal entre clientes e desenvolvedores, sempre dando
preferência a outros meios de comunicação mais formais.
d) os programadores desenvolvem o software fazendo todos os testes possíveis no término do

desenvolvimento.
e) deve-se projetar todas as funções possíveis com a máxima previsão do que ocorrerá no futuro,
antes do desenvolvimento do software, a fim de evitar alterações desnecessárias.
117. (INSTITUTO AOCP / EBSERH – 207) O Extreme Programming (XP) surgiu em 1999, a partir
de uma publicação sobre o assunto, mas suas bases se conectam a princípios da década de 80 e
ao manifesto ágil. O XP é baseado em 4 atividades de arcabouços. Assinale a alternativa que
contém 3 desses arcabouços:
a) Levantamento de requisitos, análise de negócio, planejamento e documentação.

b) Levantamento de requisitos, planejamento, documentação e implantação.
c) Levantamento de requisitos, documentação, codificação e teste.
d) Planejamento, projeto, documentação e implantação.
e) Governança, planejamento, codificação e teste.

43089971860 -1644786

1. LETRA B 40. LETRA B 79. CORRETO
2. ERRADO 41. ANULADA 80.CORRETO
3. ERRADO 42. LETRA D 81. CORRETO
4. CORRETO 43. LETRA D 82. LETRA C
5. ERRADO 44.LETRA A 83. CORRETO
6. CORRETO 45. LETRA A 84.CORRETO
7. LETRA B 46.LETRA A 85. CORRETO
8. LETRA E 47. ERRADO 86. ERRADO
9. LETRA B 48.LETRA E 87. ERRADO
10. LETRA D 49.CORRETO 88. LETRA A
11. LETRA B 50. LETRA B 89. LETRA E
12. LETRA E 51. LETRA C 90.LETRA C
13. LETRA C 52. LETRA A 91. LETRA A
14. LETRA A 53. LETRA C 92. CORRETO
15. LETRA B 54. LETRA D 93. CORRETO
16. ERRADO 55. LETRA B 94.LETRA A
17. LETRA A 56. CORRETO 95. LETRA E
18. LETRA D 57. ERRADO 96. LETRA D
19. LETRA A 58. ERRADO 97. LETRA D
20. LETRA D 59. LETRA D 98. ERRADO
21. LETRA D 60.LETRA A 99. CORRETO
22. LETRA D 61. LETRA E 100. ERRADO
23. CORRETO 62. LETRA A 101. CORRETO
24. LETRA E 63. LETRA C 102. CORRETO
25. LETRA E 64.ERRADO 103. LETRA E
26. LETRA D 65. CORRETO 104. LETRA C
27. LETRA C 66. LETRA B 105. ERRADO
28. LETRA B 67. LETRA C 106. CORRETO
29. CORRETO 68. LETRA E 107. ERRADO
30. LETRA E 69. ERRADO 108. CORRETO
31. LETRA C 70. LETRA C 109. ERRADO
32. ERRADO 71. CORRETO 110. CORRETO
33. ERRADO 72. ERRADO 111. LETRA C
34. CORRETO 73. LETRA B 112. ERRADO
35. CORRETO 74. LETRA A 113. CORRETO
36. LETRA A 75. LETRA D 114. ERRADO
37. LETRA B 76. LETRA C 115. LETRA B
38. LETRA E 77. LETRA E 116. LETRA B
39. LETRA E 78. CORRETO 117. LETRA E

43089971860 -1644786

Aula 34 - TI - Engenharia de Software - Metodologias Ágeis

Enviado por

Dados do documento

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

Aula 34 - TI - Engenharia de Software - Metodologias Ágeis

Enviado por

Direitos autorais:

Formatos disponíveis

Aula 29 (Profs Diego

43089971860 - Filipe Gonçalves Costa

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

8) Metodologias Ágeis - Scrum

9) Metodologias Ágeis - Scrum - Pilares Fundamentais

10) Metodologias Ágeis - Scrum - Principais Valores

11) Metodologias Ágeis - Scrum - Papeis

12) Metodologias Ágeis - Scrum - Artefatos

13) Metodologias Ágeis - Scrum - Eventos

14) Metodologias Ágeis - Scrum - Novidades do Scrum

15) Resumo - Metodologias Ágeis - Scrum

16) Questões Comentadas - Metodologias Ágeis - Scrum - Multibancas

17) Lista de Questões - Metodologias Ágeis - Scrum - Multibancas

18) Metodologias Ágeis - XP

19) Metodologias Ágeis - XP - Principais Práticas

20) Metodologias Ágeis - XP - Processo do XP

21) Metodologias Ágeis - XP - Valores Fundamentais

22) Metodologias Ágeis - XP - Princípios Básicos

23) Resumo - Metodologias Ágeis - XP

24) Questões Comentadas - Metodologias Ágeis - XP - Multibancas

25) Lista de Questões - Metodologias Ágeis - XP - Multibancas

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 2

PROFESSOR DIEGO CARVALHO - www.instagram.com/professordiegocarvalho

INCIDÊNCIA EM PROVA: baixíssima

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 3

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 4

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 5

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

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 6

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 7

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

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 8

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

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 9

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 10

Pessoal, agora vamos falar rapidamente sobre uma diferença

maioria dos seus concorrentes. Como é, professor?

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 11

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

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 12

NÓS SEGUIMOS ESSES PRINCÍPIOS...

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 13

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

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 14

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 15

Claros e definidos. Conforme a confiança na equipe e ambiente

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

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 16

Método Ágil x Método Lean

Não, tem mais...

CARACTERÍSTICA LEAN ÁGIL

Concursos da Área Fiscal - Curso Básico de Tecnologia da Informação - 2022 17