aula_01__epe__engsw

Prévia do material em texto

www.tiparaconcursos.net Página 1 de 47 
AULA 01: Metodologias Ágeis 
Sumário 
1. Bibliografia .......................................................................................................................... 1 
2. Metodologias Ágeis ............................................................................................................ 2 
3. Lista das Questões Utilizadas na Aula. ............................................................................. 37 
4. Gabarito. ........................................................................................................................... 47 
 
 Oi pessoal, vamos abordar nesta aula 01 as metodologias ágeis de software. 
Começaremos o estudo com uma pequena introdução seguida pelo XP, Scrum e 
demais metodologias ágeis. 
 Nossa dificuldade maior é encontrar questões da Cesgranrio sobre o tema, 
por isso, complementamos a aula com questões de outras bancas assemelhadas, 
notadamente a FCC. 
1. Bibliografia 
Nesta aula utilizei, como referência para os comentários, os livros a seguir: 
1. Pressman, R. S. Software Engineering. A practioner’s approach. 7ª Ed. 
McGraw Hill. 2010. 
2. Sommerville, I. Software Engineering. 9ª Ed. Addison-Wesley. 2011. 
3. Beck, K. Extreme Programming Explained: Embrace Change. 2º Ed. Addison-
Wesley. 2004. 
4. Schwaber, K. Agile Project Management with Scrum. Microsoft Press. 2004. 
5. Schwaber, K.; Sutherland, J. Scrum Guide Portuguese. scrum.org. 2011. 
 
 
 
 
 
www.tiparaconcursos.net Página 2 de 47 
2. Metodologias Ágeis 
INTRODUÇÃO 
QUESTÃO 01 Prova: FCC - 2010 - TRE-RS - Analista Judiciário - Analista de Sistemas 
Suporte 
A Aliança Ágil (The Agile Alliance) define diversos princípios para aqueles que 
querem alcançar agilidade no desenvolvimento de software. Dentre eles, podem 
ser considerados: 
I. Modificações de requisitos não são bem-vindas em nenhuma etapa do 
desenvolvimento. 
II. O pessoal de negócios e os desenvolvedores devem trabalhar juntos diariamente 
durante todo o projeto. 
III. Simplicidade - a arte de maximizar a quantidade de trabalho não efetuado - não 
é essencial. 
IV. Software funcionando é a principal medida de progresso. 
Está correto o que consta em 
a) I, II, III e IV. 
 b) II e IV, somente. 
 c) I e III, somente. 
 d) I, II e IV, somente. 
 e) II, III e IV, somente. 
Comentários: A ideia por trás das metodologias ágeis de desenvolvimento de 
software é a diminuição do risco por meio do desenvolvimento em pequenos 
pedaços, ou iterações, entregando software funcionando depois de cada iteração, as 
quais gastam tipicamente entre uma e quatro semanas. Cada iteração é como um 
projeto de software em miniatura, incluindo todas as tarefas necessárias para 
implantar uma nova funcionalidade: planejamento, análise de requisitos, projeto, 
codificação, teste e documentação. 
 Assim, um projeto de software ágil busca implantar uma nova versão do 
software ao fim de cada iteração, etapa a qual a equipe responsável reavalia as 
prioridades do projeto. 
 
 
 
www.tiparaconcursos.net Página 3 de 47 
 As definições modernas de desenvolvimento de software ágil evoluíram a 
partir da metade de 1990, como parte de uma reação contra métodos "pesados", em 
especial o RUP. Cada processo ágil possui uma combinação diferente de velhas e 
novas ideias, mas todos preconizam os seguintes elementos: grande colaboração 
entre a equipe de desenvolvimento e especialistas no negócio, comunicação face-a-
face, entregas frequentes de versões com valor agregado ao negócio, times auto-
organizados e capacidade de organização da equipe e do código para que mudanças 
nos requisitos não virem crises. 
 Em 2001, o famoso Manifesto Ágil foi criado num encontro de engenharia de 
software, sendo uma declaração de 17 engenheiros de software sobre as 
metodologias ágeis. Pois bem, segue o manifesto em sua íntegra: 
"Manifesto para Desenvolvimento Ágil de Software 
 
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." 
Hoje, as metodologias ágeis se encontram em um estágio avançado de 
aceitação pela comunidade de engenharia de software. Sommerville apresenta as 
seguintes características para metodologias ágeis: 
1. Inexistência de documentação detalhada. 
2. Sistema desenvolvido em uma série de versões e participação dos usuários dos 
sistemas nas homologações. 
 
 
 
www.tiparaconcursos.net Página 4 de 47 
3. Interfaces de usuário geradas automaticamente. 
 Sommerville apresenta os princípios das metodologias ágeis. Vamos 
dar uma olhada neles: 
1. Envolvimento do usuário: os usuários do sistema devem participar ativamente de 
todo o processo de desenvolvimento. 
2. Entrega incremental: o software é desenvolvido em pedaços, cujos requisitos de 
cada incremento são definidos pelo usuário. 
3. Pessoas e não processos: deve-se explorar as qualidades individuais de cada 
membro do time de desenvolvimento. Os membros do time de desenvolvimento 
devem ter liberdade para trabalhar do jeito que achar melhor, sem necessidade de 
seguir um processo prescritivo. 
4. Abrace as mudanças: o sistema terá mudanças e desenvolva um sistema apto a 
receber mudanças. 
5. Mantenha a simplicidade: simplicidade do software e do processo de software. 
 A Agile Alliance é uma organização sem fins lucrativos formada por membros 
de todo o mundo, tendo como objetivo o avanço no desenvolvimento de princípios e 
práticas ágeis. Ela busca uma indústria de software mais produtiva, humana e 
sustentável. São 12 princípios definidos pela Agile Alliance: 
1. A maior prioridade é satisfazer o cliente por meio de entregas rápidas e contínuas 
de software com valor. 
2. Mudanças nos requisitos são bem vindas, ainda que em um momento avançado 
do desenvolvimento. Processos ágeis minimizam mudanças, trazendo vantagem 
competitiva para o cliente. 
3. Software deve ser entregue frequentemente, entre algumas semanas e alguns 
meses, preferencialmente numa escala de tempo o menor possível. 
4. Pessoas do negócio e do desenvolvimento de software precisam trabalhar juntas 
diariamente ao longo do projeto. 
 
 
 
www.tiparaconcursos.net Página 5 de 47 
5. Construir projetos motiva os indivíduos. Dê a eles o ambiente o suporte necessário 
e confie que receberá o trabalho pronto. 
6. O método mais eficiente e efetivo de comunicação com e dentro do time de 
desenvolvimento é a conversa face-a-face. 
7. Software funcionando é a medida primária de progresso. 
8. Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, 
desenvolvedores e usuários devem ser capazes de manter uma velocidade constante 
de produção indefinidamente. 
9. Atenção contínua para a excelência técnica e o bom design melhoram a agilidade. 
10. Simplicidade, a arte de maximizar a quantidade de trabalho não realizado, é 
essencial. 
11. Os melhores requisitos, projetos e arquiteturas emergem de times auto-
organizados. 
12. Os times devem refletir em intervalos regulares como se tornar mais efetivos, 
ajustando o seu comportamente de acordo com o verificado. 
 Analisando nossa questão, as afirmativas erradas são a primeira, a qual afirma 
que mudanças nos requisitos não são bem vindas, quando na verdadeé o contrário, 
e a segunda que fala que a simplicidade não é essencial. 
Gabarito: B 
QUESTÃO 02 Prova: FCC - 2012 - MPE-AP - Técnico Ministerial - Informática 
Os processos de desenvolvimento rápido de software são concebidos para 
produzir, rapidamente, softwares úteis. O software não é desenvolvido como uma 
única unidade, mas como uma série de incrementos, em que cada incremento 
inclui uma nova funcionalidade no sistema. Embora existam muitas abordagens 
para o desenvolvimento rápido de software, elas compartilham algumas 
características fundamentais, como 
a) a definição de requisitos e alterações no sistema, que devem ser definidas antes 
do início do processo, podendo ser alteradas somente após a total entrega e aceite 
 
 
 
www.tiparaconcursos.net Página 6 de 47 
do produto, trazendo agilidade ao processo, pois a equipe de desenvolvimento 
pode trabalhar sem a interferência do usuário final. 
 b) os processos de especificação, projeto e implementação, que são criados em 
uma única etapa do sistema, diferindo de processos tradicionais de 
desenvolvimento de software, que os intercalam e reduzem a velocidade em que o 
software é produzido. 
 c) a especificação detalhada de todo o projeto, que contém documentos de 
requisitos elaborados para cada detalhe funcional e não funcional e também de 
cada novo item incluído nas etapas de iteração. 
 d) a diminuição do número de versões, que aumenta a quantidade de itens 
funcionais incluídos em cada entrega. A especificação e avaliação de cada versão 
são exclusivas da equipe de desenvolvimento, fato que contribui para o aumento 
da velocidade e rapidez do processo. 
 e) as interfaces de usuário do sistema, que geralmente são desenvolvidas com o 
auxílio de um sistema interativo que permite a criação rápida do projeto da 
interface por meio de desenho e inserção de ícones. 
Comentários: Analisando cada alternativa: 
a) Na verdade, as mudanças podem ocorrer ao longo do processo e essa é a ideia da 
agilidade: aceitar as mudanças nos requisitos numa boa. O examinador tenta 
enganar quem sabe um pouco do Scrum e viu que durante uma sprint (uma iteração) 
os requisitos devem ser estabilizados para trazer paz à equipe de desenvolvimento. 
No entanto, uma sprint pode ser cancelada a qualquer momento, como por exemplo, 
a mudança de um requisito previsto para implementação durante a referida iteração. 
Alternativa errada. 
b) Na verdade, as diferentes fases da engenharia de software, como a especificação, 
o projeto e a implementação se repetem ao longo de diversas etapas do sistema ou 
iterações. Alternativa errada. 
c) Nada disso, tendo como premissa a manutenção do projeto simples e a capacidade 
de reagir a mudanças, os métodos ágeis não necessitam de uma especificação 
completa da arquitetura no começo do desenolvimento nem documentos de 
requisitos com a especificação de todos os requisitos. Este nível de maturidade da 
 
 
 
www.tiparaconcursos.net Página 7 de 47 
documentação só será alcançado quando o software estiver próximo de sua versão 
final (e olhe lá!). Alternativa errada. 
d) Nada disso! São características dos métodos ágeis a entrega de softwares em 
iterações pequenas e rápidas, com a implementação de poucas funcionalidades a 
cada iteração. Além disso, o cliente trabalha junto com a equipe de desenvolvimento, 
trazendo agilidade às especificações de requisitos e validação do software entregue, 
trabalhos que necessitam da participação da área de negócio. Alternativa errada. 
e) Exato! Frameworks de desenvolvimento e ferramentas CASE são amplamente 
utilizados em metodologias ágeis, trazendo velocidade ao desenvolvimento. Em 
especial, telas do sistemas podem ser desenhadas com o auxílio de ferramentas CASE 
de construção de interfaces gráficas. 
Gabarito: E 
XP 
QUESTÃO 03 Prova: FCC - 2011 - TRE-RN - Técnico Judiciário - Programação de 
Sistemas 
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: XP é a metodologia de desenvolvimento ágil mais conhecida, cuja ideia 
básica é a seguinte: se uma prática é boa, vamos fazê-la ao extremo. Exemplificando, 
se testar é bom, vamos fazer nosso desenvolvimento voltado a testes. Se integrar os 
pedaços do software é uma boa prática, vamos integrar continuamente nosso 
software. 
 
 
 
www.tiparaconcursos.net Página 8 de 47 
 XP apresenta 05 valores que vão dar origem às práticas do modelo, que serão 
apresentadas a seguir. Tais práticas refletem as principais características dos 
métodos ágeis, a saber: 
1. Desenvolvimento incremental por meio de pequenas e frequentes releases. Os 
requisitos do sistema são definidos por Histórias contadas pelo cliente ou cenários 
imaginados que servem de base para os incrementos. 
2. O cliente participa ativamente da equipe de desenvolvimento e é responsável 
pelos testes de aceitação do sistema. 
3. Pessoas (e não processos) participam por meio de práticas como programação em 
pares, propriedade coletiva do código e um processo sustentável sem longas horas 
de trabalho. 
4. Mudanças são controladas por meio de pequenas releases avaliadas pelo cliente, 
refactoring e integração contínua de novas funcionalidades. 
5. Simplicidade é promovida por meio de refactoring e manutenção de um design 
simples do software. 
 Continuando esta introdução sobre o XP, vale a pena citar também os 
princípios do XP, previstos no livro de Beck e a seguir: 
1. Feedback rápido 
2. Assuma simplicidade 
3. Mudanças incrementais 
4. Abrace mudanças 
5. Trabalho de qualidade 
 Pressman traz o processo XP na figura a seguir: 
 
 
 
www.tiparaconcursos.net Página 9 de 47 
 
 Analisando cada uma das etapas do processo: 
1. Planejamento: conhecida também como Planning Game, a primeira etapa do XP 
envolve ouvir (Listening) o cliente para identificar as Histórias, que descrevem os 
requisitos e funcionalidades do sistema. Estas Histórias são priorizadas pelo cliente e 
estimadas pela equipe de desenvolvimento (em termos de prazo). Critérios de 
aceitação são definidos e um plano para a próxima iteração. 
2. Design: A principal ideia aqui é o design simples. A única documentação existente 
são os cartões CRC (Classe - Responsável - Colaboração), técnica que será vista mais a 
frente ao longo do curso. É criado um protótipo do design, que será avaliado, 
chamado "spike solution". Refactoring é utilizado continuamente para melhoria do 
design. 
3. Codificação: antes de iniciar a codificação, são criados os testes de unidade. A 
programação em pares (vista já já) é uma prática chave desta etapa. 
4. Teste: os testes de unidade, escritos na etapa de codificação e os testes de 
aceitação (elaborados pelo cliente) são aplicados. 
5. Depois segue-se a release de um incremento de software. 
 
 
 
www.tiparaconcursos.net Página 10 de 47 
 De acordo com Pressman, seguem os cincos valores do XP, que servem de 
base para as práticas do método: 
Comunicação: comunicação em XP significa a participação dos clientes na equipe de 
desenvolvimento, comunicação verbal informal, uso de metáforas para entender o 
projeto, feedback contínuo e menos documentação. 
Simplicidade: design simples de ser implementado em código, refatorado 
posteriormente. 
Feedback: feedback do código por meio de testes, feedback dos usuários e da equipe 
de desenvolvimento. 
Coragem:coragem para implementar as ideias inovadoras do XP como a 
programação em pares. Coragem para implementar um design simples tendo como 
base que as mudanças necessariamente ocorrerão no futuro. 
Respeito: A entrega contínua de incrementos e a utilização correta das práticas 
implicam em aumento de respeito pela equipe de desenvolvimento dos usuários, 
clientes e partes interessadas no sistema. 
 Nossa questão fala da simplicidade! 
Gabarito: D 
QUESTÃO 04 Prova: FCC - 2007 - TRE-SE - Analista Judiciário - Especialidade - 
Análise de Sistemas - Desenvolvimento 
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. 
 
 
 
www.tiparaconcursos.net Página 11 de 47 
Comentários: As práticas do XP nasceram da necessidade de implementar ao 
extremo tudo aquilo que é considerado bom na engenharia de software. 
Aproveitemos a questão para apresentar as práticas do XP, segundo Sommerville: 
Planejamento incremental: requisitos são armazenados em histórias que são 
incluídas nos incrementos conforme priorização. Os desenvolvedores quebram as 
histórias em tarefas de desenvolvimento. 
Pequenas entregas: o conjunto mínimo de funcionalidades que possuem valor para o 
negócio é desenvolvido primeiro. As entregas posteriores são frequentes e 
adicionam funcionalidade à primeira release incrementalmente. 
Design simples: o design é elaborado para atender os requisitos atuais e nada mais. 
Desenvolvimento orientado a testes: um framework de testes de unidade 
automatizado é utilizado para escrever os testes de uma funcionalidade antes desta 
ser implementada. 
Refatoração: todos os desenvolvedores devem refatorar o código sempre que 
possível com o objetivo de manter o código simples e passível de manutenção. 
Programação em pares: Desenvolvedores trabalham em dupla, checando o trabalho 
um do outro e garantindo que o trabalho seja bem feito. 
Propriedade coletiva do código: Os desenvolvedores atuam em todas as áreas do 
sistema. Não existe ilha de expertise e todas as duplas possuem responsabilidade por 
todo o código. Qualquer um pode mudar qualquer código. 
Integração contínua: Sempre que uma tarefa é completada, todo o sistema é 
integrado. Antes da integração, todos os testes unitários são rodados. 
Velocidade sustentável: Muitas horas extras de trabalho não é uma prática aceitável, 
pois a consequência é a redução da qualidade do software e da produtividade média 
da equipe. 
Cliente presente: Um representante do usuário final do sistema deve ficar disponível 
full time para uso da equipe XP. Este cliente é um membro da equipe de 
desenvolvimento e é responsável por trazer os requisitos do sistema para a equipe. 
 
 
 
www.tiparaconcursos.net Página 12 de 47 
apesar de Sommerville ter apresentado um bom apanhado das práticas da XP, ele 
deixou algumas de fora. Além das citadas por Sommerville anteriormente, Beck 
também apresentou ao mundo as seguintes práticas no seu livro "Extreming 
Programing Explained": 
Metáforas: o projeto deve ser tratado como um todo por uma metáfora, para 
facilitar a comunicação da equipe. Exemplo de metáfora seria tratar o projeto como 
um avião ou um time de futebol... 
40 horas de trabalho: Sommerville fala em ritmo sustentável de trabalho, Beck vai 
direto ao ponto: "Eu quero acordar de manhã bem disposto e chegar no fim da tarde 
com a sensação de dever cumprido. Eu quero sair do trabalho na sexta feliz porque 
terei dois dias de descanso. Eu quero chegar na segunda-feira cheio de ideias novas 
que apareceram no fim de semana". Preciso falar mais nada né? 
Padrões de codificação: deve ser utilizado um único padrão de codificação, adotado 
pela equipe e que tenha como objetivo facilitar a comunicação entre os 
desenvolvedores. 
 A questão está falando da prática do XP de desenvolvimento orientado a 
testes. Falando mais dele, o desenvolvimento orientado a testes ou "Test Driven 
Development" - TDD é uma estratégia evolucionária de desenvolvimento criada pelo 
Beck (mesmo autor da XP), cuja ideia encontra-se representada no diagrama da 
próxima página, que foi retirado do site http://www.agiledata.org/essays/tdd.html. 
 Ou seja, você primeiro cria o teste para depois criar o código e executar o 
teste. Caso o teste passe, você segue para a construção de um novo pedaço de 
código (nova funcionalidade). Caso o teste falhe, você muda o seu código e testa de 
novo... 
 
 
 
 
www.tiparaconcursos.net Página 13 de 47 
 
Gabarito: B 
QUESTÃO 05 Prova: FCC - 2010 - TRF - 4ª REGIÃO - Analista Judiciário - Tecnologia 
da Informação 
A Extreme Programming (XP) baseia-se em 12 práticas, que são um conjunto de 
atividades que deverão ser seguidas pelas equipes que desejam utilizar a XP. Na 
prática do Jogo do Planejamento, as funcionalidades são descritas em pequenos 
cartões que são conhecidos como 
 a) cartões de requisitos. 
 b) cartões de planejamento. 
 c) cartões chave. 
 d) cartões inteligentes. 
 e) histórias de usuário. 
 
 
 
www.tiparaconcursos.net Página 14 de 47 
Comentários: Estamos falando do planejamento incremental, prática assim batizada 
pelo Sommerville, mas que na verdade era chamada originalmente de "Jogo do 
planejamento", onde "histórias de usuário" são criadas para descrever as 
funcionalidades do sistema. 
Gabarito: E 
QUESTÃO 06 Prova: FCC - 2008 - TCE-AL - Analista de Sistemas 
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: Lembre-se que no projeto XP, tal como apresentado por Pressman, o 
produto principal é o cartão CRC. Um cartão CRC (Classe, Responsabilidade, 
Colaboração) é um cartão de papel 3x5 no qual você descreve o nome da classe em 
que está pensando no momento, com suas responsabilidades e colaboradores. O 
maior valor dos Cartões CRC é permitir que as pessoas rompam com o modo 
procedural de pensar e apreciem de modo mais completo a orientação a objetos. 
Exemplo: 
 
Gabarito: B 
 
 
 
www.tiparaconcursos.net Página 15 de 47 
QUESTÃO 07 Prova: CESGRANRIO - 2010 - IBGE - Analista de Sistemas - 
Desenvolvimento de Aplicações O XP (Extreme Programming) usa uma abordagem 
orientada a objetos como seu paradigma de desenvolvimento predileto. Nessa 
perspectiva, analise as afirmativas abaixo. 
I - A atividade de Codificação começa com a criação de um conjunto de histórias 
que descreve as características e as funcionalidades requeridas para o software a 
ser construído. 
II - O XP encoraja o uso de cartões CRC (Class- Responsibility-Colaborator) como um 
mecanismo efetivo para raciocinar sobre o software no contexto orientado a 
objetos. 
III - O XP emprega a técnica de refectoring na codificação, mas desaconselha a 
utilização da programação por pares. 
IV - A criação de testes unitários antes da codificação começar é uma prática do XP. 
V - Se um difícil problema de projeto é encontrado como partedo projeto de uma 
história, o XP recomenda a criação imediata de um protótipo operacional daquela 
parte do projeto. 
Estão corretas APENAS as afirmativas 
 a) I, II e IV. 
 b) I, III e IV. 
 c) I, IV e V. 
 d) II, III e V. 
 e) II, IV e V. 
Comentários: Vamos analisar cada afirmativa: 
I - A atividade de Codificação começa com a criação de um conjunto de histórias 
que descreve as características e as funcionalidades requeridas para o software a 
ser construído. A criação das histórias ocorre na etapa de planejamento e não de 
codificação. 
II - O XP encoraja o uso de cartões CRC (Class- Responsibility-Colaborator) como um 
mecanismo efetivo para raciocinar sobre o software no contexto orientado a 
objetos. Legal! Já aprendemos que o uso destes cartões é uma prática comum na 
etapa de Design. 
 
 
 
www.tiparaconcursos.net Página 16 de 47 
III - O XP emprega a técnica de refactoring na codificação, mas desaconselha a 
utilização da programação por pares. Dizer que o XP desaconselha a programação 
em pares é dose... Só quem nunca ouviu falar em XP ou em programação em pares 
na vida é que erraria esta. 
IV - A criação de testes unitários antes da codificação começar é uma prática do XP. 
É o famoso TDD. 
V - Se um difícil problema de projeto é encontrado como parte do projeto de uma 
história, o XP recomenda a criação imediata de um protótipo operacional daquela 
parte do projeto. Exato! Copiado e colado de Pressman. 
Gabarito: E 
QUESTÃO 08 Prova: CESGRANRIO - 2009 - BNDES - Profissional Básico - Análise de 
Sistemas - Desenvolvimento 
Determinado projeto de software utiliza XP (eXtreme Programming) como 
metodologia de desenvolvimento. A esse respeito, é INCORRETO afirmar que 
 a) o cliente participa ativamente e acompanha os passos dos desenvolvedores 
diariamente. 
 b) os integrantes da equipe se reúnem rapidamente no início do dia, de 
preferência em pé. 
 c) a equipe de desenvolvimento concentra esforços naquilo que gera maior valor 
para o cliente. 
 d) a programação em pares dispensa o desenvolvimento orientado a testes no 
projeto. 
 e) as funcionalidades do software são descritas em histórias, da forma mais 
simples possível. 
Comentários: Vamos lá, em XP temos a participação ativa do cliente, as daily 
meetings, a concentração dos esforços naquilo que gera maior valor ao cliente (por 
meio da priorização do product backlog) e o uso de histórias. A única alternativa 
incorreta é a D que afirma que com o uso da programação em pares, TDD se torna 
dispensável. Um disparate! 
Gabarito: D 
 
 
 
www.tiparaconcursos.net Página 17 de 47 
QUESTÃO 09 Prova: CESGRANRIO - 2010 - ELETROBRÁS - Analista de Sistemas - 
Suporte Basis SAP R3 
No âmbito de desenvolvimento de sistemas, o XP tem como característica a 
programação em par, na qual o(a) 
 a) programador codifica em companhia do analista de requisitos. 
 b) testador realiza os casos de teste em companhia do programador. 
 c) código é escrito em par, reduzindo a inserção de bugs. 
 d) programador codifica em companhia do gestor do sistema. 
 e) disseminação do conhecimento não é priorizada, mas, sim, a individualidade. 
Comentários: Na programação em pares o código é escrito por dois programadores, 
reduzindo a possibilidade de bugs. Normalmente, um programador codifica 
enquanto que outro vai revisando ao mesmo tempo. Resultado disso é termos um 
código com melhor qualidade. Assim, nosso gabarito é a alternativa c. 
 As demais alternativas falam besteira: analista de requisitos não programa 
em pares, testador também não e gestor do sistema também não. Por fim, 
logicamente que a disseminação do conhecimento é priorizada, pois o código é 
compartilhado entre os programadores (e a principal documentação do sistema é o 
código). 
Gabarito: C 
QUESTÃO 10 Prova: FCC - 2012 - TST - Técnico Judiciário - Programação 
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. 
 
 
 
www.tiparaconcursos.net Página 18 de 47 
Comentários: A resposta é a letra a que fala na programação em pares. A letra b está 
errada porque o cliente está sempre presente. Letra c: FDD é outra metodologia ágil, 
ou seja, XP não segue rigorosamente outra metodologia. 
 Segundo Pressman, o XP recomenda que depois que as histórias forem 
desenvolvidas e o trabalho preliminar de projeto for feito, a equipe não avance para 
o código mas, em vez disso, desenvolva uma série de testes unitários que exercitarão 
cada uma das histórias que devem ser incluídas na versão atual. Ou seja, estamos 
falando do desenvolvimento orientado a testes na letra d. 
 Por fim, Pressman fala em 04 atividades e não 03 como apresentado na letra 
e. Olha a figura a seguir: 
 
Gabarito: A 
QUESTÃO 11 Prova: CESGRANRIO - 2007 - REFAP SA - Analista de Sistemas Júnior 
NÃO é uma característica da Extreme Programming (XP): 
 a) simplicidade. 
 b) agilidade. 
 c) desenvolvimento orientado a testes. 
 d) programação em par. 
 e) documentação extensa e abundante em artefatos. 
Comentários: A simplicidade está presente nas histórias. XP é uma metodologia ágil. 
TDD e programação em pares são duas das mais famosas práticas de XP. Só essa 
ideia equivocada de XP se caracterizar por uma documentação extensa e com muitos 
artefatos é que é absurda, pois "a melhor documentação é o próprio código". 
Gabarito: E 
 
 
 
www.tiparaconcursos.net Página 19 de 47 
QUESTÃO 12 Prova: IADES - 2013 - EBSERH - Analista de Tecnologia da Informação - 
Teste e Qualidade 
Existem no mercado algumas metodologias de desenvolvimento, que facilitam o 
processo de produção de software. Uma dessas metodologias é o XP (Extreme 
Programming), o qual tem um cuidado especial com os processos de teste de 
software. Como é feito o processo de teste de software, utilizando o XP? 
a) Todos os testes são efetuados, ao fim do desenvolvimento pois, assim, o usuário 
pode ter uma visão ampla do software. 
b) As etapas de teste são suprimidas do processo 
c) Ao final de cada etapa, o usuário é convidado a testar o módulo pronto, 
evitando, assim, erros muito complexos, ao final do desenvolvimento. 
 d) O processo é efetuado, apenas por profissionais que trabalharam no 
desenvolvimento do produto, tornando assim, o teste mais eficaz e próximo da 
realidade do cliente. 
 e) Todos os testes são realizados na etapa de concepção do software. 
Comentários: Bem pessoal, até que enfim uma questão da IADES. Ela aborda o 
processo de testes no XP, sendo bastante simples sua resolução. Tanto a alternativa 
a quanto a b tenta engessar o momento em que os testes ocorrem no XP, algo que 
não é razoável, pois temos testes ao longo de todo o processo de desenvolvimento. 
A alternativa b dispara o absurdo de dizer que com XP não temo testes. A alternativa 
d restringe os testes aos desenvolvedores, o que não é verdade, pois podemos ter a 
participação de uma equipe de testes específica e também a realização de testes 
pelo usuário / cliente. 
 Por fim,temos nossa alternativa correta que é a c, que afirma que a cada 
iteração o usuário testa o módulo pronto, corrigindo a rota do processo de 
desenvolvimento de software, o que é uma boa prática no contexto das 
metodologias ágeis. 
Gabarito: C 
QUESTÃO 13 Prova: IADES - 2010 - CFA - Analista de Sistemas 
Assinale a alternativa correta acerca da Programação Extrema (Extreme 
Programming - XP). 
 
 
 
www.tiparaconcursos.net Página 20 de 47 
 a) Na programação por pares, os códigos são escritos por dois programadores em 
cada máquina. Enquanto um dos programadores codifica, o outro é responsável 
para aspectos como a simplificação do código. 
 b) A refatoração tem por objetivo reestruturar um software e modificar as 
funcionalidades disponibilizadas pelo mesmo. Ao refatorar, um desenvolvedor 
pode eliminar duplicações e simplificar o projeto. 
 c) A estratégia adotada no projeto de software se baseia em contemplar todos os 
possíveis cenários de evolução empregando-se padrões de projeto. A 
implementação não inicia até ser concluído todo o projeto. 
 d) É recomendável que não se adotem padrões para as práticas de codificação e 
que não se limite a quantidade de horas trabalhadas por semana. 
Comentários: XP parece ser a metodologia favorita da IADES e esta questão aborda 
algumas práticas preconizadas pelo XP. A primeira alternativa apresenta a 
programação por pares, detalhando o papel de cada programador, sendo nosso 
gabarito. 
 A afirmativa b peca ao dizer que com a refatoração se modifica as 
funcionalidades do sistema, o que não é verdade, pois essa prática tem como 
objetivo apenas melhorar a qualidade do código (diminuindo o acoplamento ou 
aumentando a coesão, por exemplo). 
 A afirmativa c rompe um dos princípios das metodologias ágeis que é a 
simplicidade, pois não de deve "perder tempo" analisando todos os possíveis 
cenários de projeto. Além disso, podemos ter codificação antes de finalizado todo o 
projeto (por exemplo, pode se criar um protótipo previamente para esclarecer 
determinado requisito do sistema). 
 Por fim, a alternativa d tem dois erros. XP preconiza o uso de padrões de 
codificação e limita a quantidade de horas trabalhadas por semana em 40 horas. 
Gabarito: A 
 
SCRUM 
 Scrum é uma metodologia ágil mais preocupada no gerenciamento do projeto 
como um todo do que em detalhes de programação. No seu Scrum Guide, o criador 
 
 
 
www.tiparaconcursos.net Página 21 de 47 
da metodologia, Schwaber define Scrum como um framework. Ele diz o que fazer e 
não como fazer. Desta forma, é comum vermos equipes ágeis utilizando uma 
combinação das duas principais metodologias: a XP e o Scrum. 
QUESTÃO 14 Prova: FCC - 2010 - TRF - 4ª REGIÃO - Analista Judiciário - Tecnologia 
da Informação 
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: Existem 03 fases no Scrum, segundo Sommerville, são elas: 
1. Esboço do planejamento e do projeto da arquitetura: estabelecimento do projeto 
e da arquitetura do sistema. 
2. Ciclo de Sprints: Cada ciclo ou Sprint desenvolve um incremento do sistema 
3. Fechamento do projeto: criação de documentação restante (como manuais do 
usuário) e análise das lições aprendidas. 
 No entanto, Pressman nos apresenta uma visão mais completa do Scrum, 
trazendo uma figura que mostra o processo como um todo: 
 
 
 
www.tiparaconcursos.net Página 22 de 47 
 
 Assim, o início de tudo é a criação do "Product Backlog", documento que 
apresenta todas as funcionalidades do produto a ser gerado, priorizadas pelo cliente. 
Por ser um processo incremental, o Scrum reparte o Product Backlog entre uma série 
de iterações, que são chamadas de Sprints, que correspondem a um período 
previamente definido de 2-4 semanas (segundo Sommerville, 30 dias para Pressman 
e Schwaber). 
 O coração do Scrum é a Sprint, onde uma versão incremental potencialmente 
utilizável do produto é criado. A ideia é que, ao término da Sprint, um pedaço do 
Product Backlog seja desenvolvido e entregue ao cliente. 
 Para isso, precede à Sprint uma fase de planejamento onde o Sprint Backlog é 
produzido. O Sprint Backlog é a lista das funcionalidades que serão desenvolvidas na 
Sprint. Esta fase é chamada de Reunião de Planejamento da Sprint, que tem em 
média 08 horas de duração. Nas primeiras 04 horas é produzido o Sprint Backlog, 
enquanto que nas últimas 04 horas, a equipe de desenvolvimento analisa e detalha 
as funcionalidades escaladas para a Sprint, finalizando a reunião sabendo o que deve 
fazer ao longo da Sprint. 
 
 
 
www.tiparaconcursos.net Página 23 de 47 
 Mudanças no backlog não são inseridas na Sprint para que a equipe de 
desenvolvimento possa trabalhar em um ambiente estável. 
 No início de cada dia ocorre a Reunião Diária do Scrum, que é um evento de 
15 minutos, para que a Equipe de Desenvolvimento possa sincronizar as atividades e 
criar um plano para as próximas 24 horas. Durante a reunião cada integrante da 
Equipe de Desenvolvimento esclarece: 
1. O que foi completado desde a última reunião? 
2. O que será feito até a próxima reunião? 
3. Quais os obstáculos que estão no caminho? 
 Ao término da Sprint, o incremento é entregue e ocorre a Revisão da Sprint, 
encontro com o objetivo de inspecionar o incremento e revisar o Product Backlog. A 
duração desta reunião é de 04 horas para uma Sprint de um mês. 
 Depois do término da Sprint e antes de iniciar a reunião de planejamento da 
próxima Sprint, ocorre a Retrospectiva da Sprint, com 03 horas de duração. O 
propósito da Retrospectiva da Sprint é: 
1. Inspecionar como a última Sprint foi em relação às pessoas, relações, processos e 
ferramentas; 
2. Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; 
e, 
3. Criar um plano para implementar melhorias no modo que o Time Scrum faz seu 
trabalho. 
 Isto posto, a resposta de nossa questão é a Sprint, que são os processos 
iterativos nos quais o software é desenvolvido. 
Gabarito: C 
 
 
 
 
 
 
www.tiparaconcursos.net Página 24 de 47 
QUESTÃO 15 Prova: FCC - 2010 - DPE-SP - Agente de Defensoria - Analista de 
Sistemas 
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: As sprints são do Scrum. Complementando, o ciclo PDCA é composto 
por 4 passos, que são executados no sentido horário. As descrições e finalidades dos 
passos são as seguintes: 
Plan (Planejar): neste passo é estabelecida uma meta com base em um problema a 
ser resolvido. Uma vez que a meta está definida, são determinadas as ações 
necessárias para alcançá-la e a forma de monitoramento dos resultados. 
Do (Executar): neste passo são executadas as ações definidas no planejamento com o 
objetivo de alcançar a meta estabelecida e também são coletadas informações para 
acompanhamento do progresso dos trabalhos. 
Check (Verificar): neste passo avaliamos os resultados alcançados com a execução 
das ações e confrontamos com a meta estabelecida, com o objetivo de identificar a 
ocorrência de desvios. 
Act (Agir): neste passo, caso algum desvio tenha sido identificado, definimos ações 
corretivas necessárias para assegurar o alcance dos resultados esperados a partir da 
próxima execução do ciclo. 
 A figura abaixo mostra porque uma sprint segueo ciclo PDCA: 
 
 
 
www.tiparaconcursos.net Página 25 de 47 
 
Gabarito: A 
QUESTÃO 16 Prova: FCC - 2010 - TRE-RS - Técnico Judiciário - Programação de 
Sistemas 
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: Detalharemos o papel do Scrum Master em instantes. Por enquanto, 
vamos revisar as Scrum meetings*. 
Daily Scrum: Cada dia, durante o sprint, uma reunião de status do projeto ocorre. 
Esta reunião começa precisamente no horário marcado, sendo que todos são bem-
 
 
 
www.tiparaconcursos.net Página 26 de 47 
vindos, mas apenas "poucos" podem falar. O encontro tem duração determinada de 
15 minutos. A reunião deve acontecer no mesmo local e mesma hora todos os dias. 
Durante a reunião, cada membro da equipe responde a três perguntas (que já 
vimos). 
Reunião de Planejamento da Sprint (Sprint Planning Meeting): No início do ciclo de 
sprint (a cada 7-30 dias), um Sprint Planning Meeting é realizado. Ele seleciona o 
trabalho que está a ser feito, prepara o Sprint Backlog e identifica o quanto o 
trabalho é susceptível de ser feito durante o sprint atual. Dividida em duas partes: 
Parte 1 (Primeiras quatro horas): diálogo para priorizar o Product Backlog e Parte 2 
(Próximas quatro horas): elaboração de um plano para a Sprint, resultando na Sprint 
Backlog. 
[No final de um ciclo de sprint, são realizadas duas reuniões: a "Sprint Review" e do 
"Sprint Retrospective"] 
Reunião de Revisão da Sprint (Sprint Review): Rever o trabalho que foi concluído e 
não concluído, apresentando o trabalho realizado para os interessados. Um trabalho 
incompleto não pode ser demonstrado. 
Retrospectiva da Sprint (Sprint Retrospective): Todos os membros da equipe 
refletem sobre a sprint passada. Três questões principais são feitas na retrospectiva 
sobre o sprint: O que deu errado? O que deu certo? O que poderia ser melhorado 
para o próximo sprint? 
* Todos os eventos do Scrum possuem duração fixa (time-box), não podendo 
ultrapassar o limite de tempo determinado para a reunião. 
 Aparentemente, a questão está tratando da daily Scrum, que ocorre 
diariamente. 
Gabarito: E 
QUESTÃO 17 Prova: CESGRANRIO - 2010 - ELETROBRÁS - Analista de Sistemas - 
Suporte Basis SAP R3 
No âmbito do desenvolvimento ágil de sistemas de informação, é INCORRETO 
afirmar que, no SCRUM, 
 a) as atividades são definidas com uma duração fixa. 
 b) o foco é nas tarefas e não nos objetivos e resultados. 
 
 
 
www.tiparaconcursos.net Página 27 de 47 
 c) o desenvolvimento é iterativo e incremental. 
 d) cada iteração foca nas necessidades mais prioritárias. 
 e) cada iteração é finalizada com funcionalidades completas. 
Comentários: Vamos analisar cada afirmativa desta questão da Cesgranrio: 
a) as atividades são definidas com uma duração fixa. Esta questão possui uma 
ligeira impropriedade, pois os eventos é que são definidos com uma duração fixa e 
não as atividades (que são desenvolvidas regularmente pelo time do Scrum). No 
entanto, a questão não foi considerada errada pelo examinador e nenhum recurso 
derrubou o gabarito final. 
 b) o foco é nas tarefas e não nos objetivos e resultados. Claro que não... é 
justamente o contrário! Ta aí o gabarito da questão (perceba claramente que estão 
alternativa é mais errada do que é a primeira). 
 c) o desenvolvimento é iterativo e incremental. Isto! Cada iteração é uma sprint, 
onde um pedaço do software é entregue. 
 d) cada iteração foca nas necessidades mais prioritárias. Exato. O Product Backlog é 
priorizado na reunião de planejamento da sprint. 
 e) cada iteração é finalizada com funcionalidades completas. Exato. Ao fim de cada 
sprint temos software entregue funcionando. 
Gabarito: B 
QUESTÃO 18 Prova: FCC - 2011 - TRT - 1ª REGIÃO (RJ) - Analista Judiciário - 
Tecnologia da Informação 
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. 
 
 
 
www.tiparaconcursos.net Página 28 de 47 
Comentários: Já já falo dos papéis do Scrum, por enquanto vamos revisar as partes 
da Sprint Planning Meeting: Parte 1 (Primeiras quatro horas): diálogo para priorizar o 
Product Backlog e Parte 2 (Próximas quatro horas): elaboração de um plano para a 
Sprint, resultando na Sprint Backlog. 
Gabarito: B 
QUESTÃO 19 Prova: FCC - 2011 - INFRAERO - Analista de Sistemas - Arquitetura de 
Software 
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 Time Scrum é composto pelo Product Owner, a Equipe de 
Desenvolvimento e o Scrum Master. Estes são os papéis definidos para a 
metodologia. 
 O Product Owner - PO, ou dono do produto, é o responsável por maximizar o 
valor do produto e do trabalho da equipe de Desenvolvimento. O PO é o único 
indíviduo responsável por controlar o Product Backlog. Este gerenciamento do 
Product Backlog envolve as seguintes atividades: 
1. Expressar claramente os itens do Product Backlog; 
2. Ordenar os itens do Product Backlog para alcançar melhor as metas e missões; 
3. Garantir o valor do trabalho realizado pela Equipe de Desenvolvimento; 
4. Garantir que o Product Backlog seja visível, transparente, claro para todos, e 
mostrar o que o Time Scrum vai trabalhar a seguir; e, 
 
 
 
www.tiparaconcursos.net Página 29 de 47 
5. Garantir que a Equipe de Desenvolvimento entenda os itens do Product Backlog no 
nível necessário. 
 O Product Owner pode estar presente durante a segunda parte da reunião de 
planejamento da Sprint, para clarificar os itens do Product Backlog selecionados e 
para ajudar nas decisões conflituosas de troca. Se a Equipe de Desenvolvimento 
determina que tem excesso ou falta de trabalho, os itens do Sprint Backlog pode ser 
renegociados com o Product Owner. 
 Outra atividade importante que pode ser exercida pelo PO é o cancelamento 
da Sprint. Conforme Scrum Guide: "Somente o Product Owner tem a autoridade para 
cancelar a Sprint, embora ele (ou ela) possa fazer isso sob influência das partes 
interessadas, da Equipe de Desenvolvimento ou do Scrum Master." 
 A Equipe de Desenvolvimento é responsável por desenvolver as 
funcionalidades do sistema. Somente integrantes da Equipe de Desenvolvimento 
criam incrementos. 
 A equipe é auto-gerenciável e multifuncional, sendo responsável por 
transformar o Product Backlog em um incremento de software. A responsabilidade 
pelo sucesso de uma iteração ou do projeto como um todo é compartilhada por 
todos os membros da equipe. 
 O Scrum Guide apresenta 05 características para a Equipede 
Desenvolvimento: 
1. São auto-organizadas: ninguém diz à equipe como ela deve conduzir o seu 
trabalho. 
2. São multifuncionais: apresenta todas as especialidades necessárias ao trabalho. 
3. Não tem papéis definidos como analista de sistemas, analista de negócios ou 
testador: a equipe é formada apenas por desenvolvedores. 
4. Um desenvolvedor pode possuir conhecimentos especializados em um tema, 
mas a responsabilidade pelo sucesso é de todos. 
 
 
 
www.tiparaconcursos.net Página 30 de 47 
5. Não existem subequipes especializadas: por exemplo, em testes ou em análise de 
negócio. 
 Com relação ao tamanho da equipe, o Scrum Guide declara que: 
1. O tamanho ideal da Equipe de Desenvolvimento é pequeno o suficiente para se 
manter ágil e grande o suficiente para completar uma parcela significativa do 
trabalho. 
2. Menos de três integrantes na Equipe de Desenvolvimento diminuem a interação e 
resultam em um menor ganho de produtividade. 
3. Havendo mais de nove integrantes é exigida muita coordenação. 
4. Nesta contagem, não se leva em consideração o PO ou o Scrum Master (último 
papel previsto no Scrum que será detalhado a seguir). 
 O Scrum Master - SM é responsável pelo processo Scrum (gerenciando os 
encontros e verificando a aderência dos artefatos gerados), por ensinar a todos 
acerca da metodologia Scrum, por implementar a cultura Scrum na organização e por 
garantir que todos seguem as regras e práticas do framework. 
 O papel do Scrum Master é ajudar a todos os envolvidos no projeto: o PO, a 
Equipe de Desenvolvimento e a Organização. Por exemplo, durante uma Sprint, a 
equipe é isolada da organização. Toda a comunicação deve ser feita via Scrum 
Master. 
Gabarito: A 
QUESTÃO 20 Prova: FCC - 2012 - TST - Técnico Judiciário - Programação 
A Sprint é considerada o coração do Scrum. Uma nova Sprint inicia-se 
imediatamente após a conclusão da Sprint anterior. Durante a Sprint 
a) o escopo pode ser clarificado e renegociado entre o Product Owner e a Equipe de 
Desenvolvimento. 
 b) a composição da Equipe de Desenvolvimento muda constantemente. 
 c) as metas de qualidade podem ser reduzidas para dar mais agilidade ao 
desenvolvimento. 
 
 
 
www.tiparaconcursos.net Página 31 de 47 
 d) são permitidas alterações no time-box da próxima Sprint para horizontes 
superiores a um mês, de acordo com os padrões flexíveis de tempo do Scrum. 
 e) são permitidas as definições de mudanças que podem afetar o seu objetivo. 
Comentários: Saiba que isso é verdade: durante uma sprint, o escopo (ou o sprint 
backlog) pode clarificado e negociado pela equipe de desenvolvimento e pelo PO, o 
que faz com o que a letra a seja nosso gabarito. Assim, se a Equipe de 
Desenvolvimento determina que tem excesso ou falta de trabalho, os itens do 
Backlog da Sprint pode ser renegociados com o Product Owner. As demais 
alternativas estão erradas porque: 
b) Não é de bom tom que a equipe de desenvolvimento tenha alta rotatividade. 
c) Diminuir meta de qualidade significa gambiarra e amadorismo. o Scrum não vai se 
passar por isso. 
d) Nada disso, nos aprendemos que uma sprint pode ter no máximo 01 mês. 
e) A sprint tem seu objetivo (ou pedaço de software a ser realizado) definido 
previamente e mudanças do sprint backlog não são permitidas no meio da sprint. 
Gabarito: A 
QUESTÃO 21 Prova: CESGRANRIO - 2010 - ELETROBRÁS - Analista de Sistemas - 
Suporte Basis SAP R3 
Disciplina: Engenharia de Software | Assuntos: Metodologias Ageis; Scrum; 
No SCRUM, que papel é responsável pela visão do produto e pelo retorno do 
investimento? 
 a) Scrum Master. 
 b) Product Owner. 
 c) Sprint Planner. 
 d) Gerente do Projeto. 
 e) Analista de Sistemas Sênior. 
Comentários: Nosso querido SM é responsável por ter uma visão do produto final ao 
longo do processo de desenvolvimento e por analisar o retorno do investimento a ser 
feito pelo PO. 
Gabarito: A 
 
 
 
www.tiparaconcursos.net Página 32 de 47 
 
 
 
 
OUTRAS METODOLOGIAS 
QUESTÃO 22 Prova: FCC - 2011 - TRE-AP - Técnico Judiciário - Programação de 
Sistemas 
As práticas se baseiam em técnicas ágeis, tais como, Test Driven Development 
(TDD), Agile Model Driven Development (AMDD) e Database Refactoring, 
concentrando as atividades de análise, desenho e requisitos unicamente na 
disciplina Modelagem. Trata-se de 
 a) AUP. 
 b) SCRUM. 
 c) XP. 
 d) AUP e SCRUM. 
 e) XP e SCRUM. 
Comentários: As práticas citadas são do XP. Isso nós já vimos. Só quero aproveitar a 
questão para falar do AUP ou Agile Unified Process, que é uma versão mais leve do 
famoso RUP. No entanto, diferente do RUP, que apresenta 09 disciplinas, o AUP tem 
07: Modelagem, Implementação, Teste, Entrega, Gerência de Configuração, Gerência 
de Projetos e Ambiente. 
 As principais filosofias do AUP são: Sua equipe sabe o que está fazendo (ou 
seja, nao precisam de documentação detalhada), simplicidade (tudo deve ser escrito 
de forma concisa), agilidade (AUP é aderente às boas práticas do desenvolvimento 
ágil), foco em atividades de alto valor, independência de ferramentas e você pode 
tirar do AUP aquilo que você não precisa. 
 Saber mais do que isso de AUP é bobeira, por isso vamos parar por aqui! 
Gabarito: A 
QUESTÃO 23 Prova: FCC - 2011 - TRT - 23ª REGIÃO (MT) - Técnico Judiciário - 
Tecnologia da Informação 
 
 
 
www.tiparaconcursos.net Página 33 de 47 
FDD (Feature Driven Development) é uma metodologia muito objetiva, possuindo 
apenas duas fases: 
 a) Concepção & Planejamento e Construção. 
 b) Decomposição Funcional e Construção. 
 c) Análise dos Requisitos e Desenvolvimento. 
 d) Planejamento Incremental e Desenvolvimento por Funcionalidade. 
 e) Planejamento por Funcionalidade e Construção por Funcionalidade. 
Comentários: O Desenvolvimento Guiado por Funcionalidades (do inglês, Feature 
Driven Development; FDD) é uma das seis metodologias ágeis originais do 
desenvolvimento de software. Seus representantes redigiram o Manifesto Ágil para 
Desenvolvimento de Software, em 2001. Nessa ocasião, o representante da FDD foi 
Jon Kern, que trabalhava na TogetherSoft, substituindo Peter Coad. 
 O processo pode ser entendido completamente apenas estudando a imagem 
a seguir: 
 
 Veja que temos duas fases apenas: uma etapa de planejamento (Concepção e 
Planejamento) e uma etapa de construção. Na primeira etapa, temos 03 processos, 
onde se desenvolve um modelo, uma lista de features, ou características, do 
software e um planejamento para cada feature. A construção envolve dois 
processos: o detalhamento de uma feature, que resulta no modelo de domínio mais 
 
 
 
www.tiparaconcursos.net Página 34 de 47 
detalhado e os esqueletos de código prontos para serem preenchidos, e a 
construção. 
 Acho que saber isso de FDD já tá bom demais. Não vamos detalhar mais, tudo 
bem? 
Gabarito: A 
QUESTÃO 24 Prova: FCC - 2010 - TRF - 4ª REGIÃO - Analista Judiciário - Tecnologia 
da Informação 
A Feature Driven Development (FDD) é uma metodologia ágil de desenvolvimento 
de software, sobre a qual é correto afirmar: 
 a) Não pode ser combinada a outras técnicas para a produção de sistemas. 
 b) Possui cinco processos: Desenvolver um Modelo Abrangente, Construir a Lista 
de Funcionalidades, Planejar por Funcionalidade, Detalhar por Funcionalidade e 
Implementar por Funcionalidade. 
 c) Divide os papéis em dois grupos: papéis chave e papéis de apoio. Dentro de cada 
categoria, os papéis são atribuídos a um único participante que assume a 
responsabilidade pelo papel. 
 d) Mantém seu foco apenas na fase de modelagem. 
 e) Mantém seu foco apenas na fasede implementação. 
Comentários: Observe que pela figura apresentada na questão, matamos a questão, 
cujo gabarito é a alternativa b, a qual apresenta os 05 processos do FDD. A letra a 
está errada porque FDD pode ser combinado com Scrum. Nesta combinação. As 
práticas do FDD são utilizadas para o desenvolvimento do software e o Scrum é 
usado para gerenciamento do projeto. 
 Agora, para sabermos se a alternativa c está certa ou errada, precisaremos 
detalhar um pouco mais FDD e entrar no mérito dos papéis desta metodologia. E 
aqui temos um ponto interessante, enquanto que XP e Scrum não possuem papéis 
definidos relacionados ao desenvolvimento (por exemplo: programador ou gerente 
de projetos), FDD possui 03 tipos de papéis: papéis principais, papéis de apoio e 
papéis adicionais (alternativa errada). 
 
 
 
www.tiparaconcursos.net Página 35 de 47 
 Os papéis principais são: Gerente de Projeto, Arquiteto Chefe, Gerente de 
Desenvolvimento, Programador Chefe, Proprietário de Classe, Especialista de 
Domínio. Os papéis de apoio são: Gerente de Domínio, Gerente de Versão, 
Especialista (Guru) da Linguagem, Coordenador de Construção, Ferramenteiro 
(toolsmith) e Administrador de Sistema. Os papéis adicionais são: Testador, 
Desenvolvedores e Escritor Técnico. 
Gabarito: B 
QUESTÃO 25 Prova: FCC - 2010 - AL-SP - Agente Técnico Legislativo Especializado - 
Tecnologia da Informação 
São consideradas metodologias ágeis de desenvolvimento de software: 
a) XP e UP. 
 b) SCRUM de DSDM. 
 c) SCRUM e RUP. 
 d) DSDM e Cascata. 
 e) Cascata e PRINCE2. 
Comentários: PRINCE2 é um framework de boas práticas de gerenciamento de 
projeto (like PMBOK). UP e Cascata são processos tradicionais de desenvolvimento. 
DSDM é uma metodologia ágil. Logo, nosso gabarito é a letra b. Vamos aproveitar 
para falar um pouco do DSDM. Para isso, deixa eu consultar a wikipedia 
(http://pt.wikipedia.org/wiki/Dynamic_Systems_Development_Method), amigona da FCC: 
Metodologia de Desenvolvimento de Sistemas Dinâmicos (do inglês Dynamic Systems 
Development Method - DSDM) é uma metodologia de desenvolvimento de software 
originalmente baseada em "Desenvolvimento Rápido de Aplicação" (RAD). DSDM é 
uma metodologia de desenvolvimento iterativo e incremental que enfatiza o 
envolvimento constante do usuário. 
Seu objetivo é entregar softwares no tempo e com custo estimados através do 
controle e ajuste de requisitos ao longo do desenvolvimento. DSDM é um dos 
modelos de Metodologia Ágil de desenvolvimento de software, e seu formato é 
propriedade da Agile Alliance. 
 Pra completar, vamos só dar uma olhada na imagem abaixo: 
 
 
 
www.tiparaconcursos.net Página 36 de 47 
 
 Esta figura apresenta os diferentes estágios de desenvolvimento e a interação 
entre eles. Falando um pouco mais dos estágios: 
Estágio 1 - Análise de Viabilidade: Durante este estágio do projeto, a viabilidade de 
uso do DSDM é examinada. Pré-requisitos para o uso do DSDM são avaliados 
respondendo-se algumas questões como: ‘Pode este projeto atender as necessidades 
do negócio?’, ‘Este projeto é próprio para o DSDM?’ e ‘Quais os riscos mais 
importantes que estão envolvidos?’. 
Estágio 2 - Iteração do Modelo Funcional: Os requisitos identificados nos estágios 
anteriores serão convertidos em modelos funcionais. 
Estágio 3 - iteração de desenho e construção: O maior intuito desta Iteração do 
DSDM é integrar os componentes funcionais de fases anteriores em um sistema que 
satisfaça as necessidades do usuário. 
Estágio 4 - implantação: Na fase de Implantação, o sistema testado e mais a 
documentação de usuário é entregue aos usuários e treinos à estes futuros usuários 
são aplicados. 
Gabarito: B 
QUESTÃO 26 Prova: FCC - 2009 - TRE-AM - Técnico Judiciário - Programação de 
Sistemas 
São algumas das metodologias de desenvolvimento de software consideradas ágeis 
(Agile Software Process Models): 
 a) RUP, XP e DSDM. 
 b) Waterfall, RUP e FDD. 
 c) XP, FDD e RUP. 
 d) Scrum, XP e FDD. 
 
 
 
www.tiparaconcursos.net Página 37 de 47 
 e) Scrum, Waterfall e DSDM. 
Comentários: Scrum, XP, FDD e DSDM são metodologias ágeis. Aproveitando o 
momento, segue a lista de metodologias ágeis citada por Pressman: Adaptive 
Software Development (ASD), Scrum, Dynamic Systems Development Method 
(DSDM), Crystal, Feature Drive Development (FDD), Lean Software Development 
(LSD), Agile Modeling (AM) e Agile Unified Process (AUP) 
Gabarito: D 
3. Lista das Questões Utilizadas na Aula. 
QUESTÃO 01 Prova: FCC - 2010 - TRE-RS - Analista Judiciário - Analista de Sistemas 
Suporte 
A Aliança Ágil (The Agile Alliance) define diversos princípios para aqueles que querem 
alcançar agilidade no desenvolvimento de software. Dentre eles, podem ser 
considerados: 
I. Modificações de requisitos não são bem-vindas em nenhuma etapa do 
desenvolvimento. 
II. O pessoal de negócios e os desenvolvedores devem trabalhar juntos diariamente 
durante todo o projeto. 
III. Simplicidade - a arte de maximizar a quantidade de trabalho não efetuado - não é 
essencial. 
IV. Software funcionando é a principal medida de progresso. 
Está correto o que consta em 
a) I, II, III e IV. 
 b) II e IV, somente. 
 c) I e III, somente. 
 d) I, II e IV, somente. 
 e) II, III e IV, somente. 
QUESTÃO 02 Prova: FCC - 2012 - MPE-AP - Técnico Ministerial - Informática 
Os processos de desenvolvimento rápido de software são concebidos para produzir, 
rapidamente, softwares úteis. O software não é desenvolvido como uma única 
unidade, mas como uma série de incrementos, em que cada incremento inclui uma 
 
 
 
www.tiparaconcursos.net Página 38 de 47 
nova funcionalidade no sistema. Embora existam muitas abordagens para o 
desenvolvimento rápido de software, elas compartilham algumas características 
fundamentais, como 
a) a definição de requisitos e alterações no sistema, que devem ser definidas antes 
do início do processo, podendo ser alteradas somente após a total entrega e aceite 
do produto, trazendo agilidade ao processo, pois a equipe de desenvolvimento pode 
trabalhar sem a interferência do usuário final. 
 b) os processos de especificação, projeto e implementação, que são criados em uma 
única etapa do sistema, diferindo de processos tradicionais de desenvolvimento de 
software, que os intercalam e reduzem a velocidade em que o software é produzido. 
 c) a especificação detalhada de todo o projeto, que contém documentos de 
requisitos elaborados para cada detalhe funcional e não funcional e também de cada 
novo item incluído nas etapas de iteração. 
 d) a diminuição do número de versões, que aumenta a quantidade de itens 
funcionais incluídos em cada entrega. A especificação e avaliação de cada versão são 
exclusivas da equipe de desenvolvimento, fato que contribui para o aumento da 
velocidade e rapidez do processo. 
 e) as interfaces de usuário do sistema, que geralmente são desenvolvidas com o 
auxílio de um sistema interativo que permite a criação rápida do projeto da interface 
por meio de desenho e inserção de ícones. 
QUESTÃO 03 Prova: FCC - 2011 - TRE-RN - Técnico Judiciário - Programação de 
Sistemas 
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. 
 
 
 
www.tiparaconcursos.net Página 39 de 47 
QUESTÃO 04 Prova: FCC - 2007 - TRE-SE - Analista Judiciário - Especialidade- Análise 
de Sistemas - Desenvolvimento 
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. 
QUESTÃO 05 Prova: FCC - 2010 - TRF - 4ª REGIÃO - Analista Judiciário - Tecnologia 
da Informação 
A Extreme Programming (XP) baseia-se em 12 práticas, que são um conjunto de 
atividades que deverão ser seguidas pelas equipes que desejam utilizar a XP. Na 
prática do Jogo do Planejamento, as funcionalidades são descritas em pequenos 
cartões que são conhecidos como 
 a) cartões de requisitos. 
 b) cartões de planejamento. 
 c) cartões chave. 
 d) cartões inteligentes. 
 e) histórias de usuário. 
QUESTÃO 06 Prova: FCC - 2008 - TCE-AL - Analista de Sistemas 
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. 
 
 
 
www.tiparaconcursos.net Página 40 de 47 
QUESTÃO 07 Prova: CESGRANRIO - 2010 - IBGE - Analista de Sistemas - 
Desenvolvimento de Aplicações O XP (Extreme Programming) usa uma abordagem 
orientada a objetos como seu paradigma de desenvolvimento predileto. Nessa 
perspectiva, analise as afirmativas abaixo. 
I - A atividade de Codificação começa com a criação de um conjunto de histórias que 
descreve as características e as funcionalidades requeridas para o software a ser 
construído. 
II - O XP encoraja o uso de cartões CRC (Class- Responsibility-Colaborator) como um 
mecanismo efetivo para raciocinar sobre o software no contexto orientado a objetos. 
III - O XP emprega a técnica de refectoring na codificação, mas desaconselha a 
utilização da programação por pares. 
IV - A criação de testes unitários antes da codificação começar é uma prática do XP. 
V - Se um difícil problema de projeto é encontrado como parte do projeto de uma 
história, o XP recomenda a criação imediata de um protótipo operacional daquela 
parte do projeto. 
Estão corretas APENAS as afirmativas 
 a) I, II e IV. 
 b) I, III e IV. 
 c) I, IV e V. 
 d) II, III e V. 
 e) II, IV e V. 
QUESTÃO 08 Prova: CESGRANRIO - 2009 - BNDES - Profissional Básico - Análise de 
Sistemas - Desenvolvimento 
Determinado projeto de software utiliza XP (eXtreme Programming) como 
metodologia de desenvolvimento. A esse respeito, é INCORRETO afirmar que 
 a) o cliente participa ativamente e acompanha os passos dos desenvolvedores 
diariamente. 
 b) os integrantes da equipe se reúnem rapidamente no início do dia, de preferência 
em pé. 
 c) a equipe de desenvolvimento concentra esforços naquilo que gera maior valor 
para o cliente. 
 
 
 
www.tiparaconcursos.net Página 41 de 47 
 d) a programação em pares dispensa o desenvolvimento orientado a testes no 
projeto. 
 e) as funcionalidades do software são descritas em histórias, da forma mais simples 
possível. 
QUESTÃO 09 Prova: CESGRANRIO - 2010 - ELETROBRÁS - Analista de Sistemas - 
Suporte Basis SAP R3 
No âmbito de desenvolvimento de sistemas, o XP tem como característica a 
programação em par, na qual o(a) 
 a) programador codifica em companhia do analista de requisitos. 
 b) testador realiza os casos de teste em companhia do programador. 
 c) código é escrito em par, reduzindo a inserção de bugs. 
 d) programador codifica em companhia do gestor do sistema. 
 e) disseminação do conhecimento não é priorizada, mas, sim, a individualidade. 
QUESTÃO 10 Prova: FCC - 2012 - TST - Técnico Judiciário - Programação 
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. 
QUESTÃO 11 Prova: CESGRANRIO - 2007 - REFAP SA - Analista de Sistemas Júnior 
NÃO é uma característica da Extreme Programming (XP): 
 a) simplicidade. 
 b) agilidade. 
 c) desenvolvimento orientado a testes. 
 d) programação em par. 
 
 
 
www.tiparaconcursos.net Página 42 de 47 
 e) documentação extensa e abundante em artefatos. 
12 Prova: IADES - 2013 - EBSERH - Analista de Tecnologia da Informação - Teste e 
Qualidade 
Existem no mercado algumas metodologias de desenvolvimento, que facilitam o 
processo de produção de software. Uma dessas metodologias é o XP (Extreme 
Programming), o qual tem um cuidado especial com os processos de teste de 
software. Como é feito o processo de teste de software, utilizando o XP? 
a) Todos os testes são efetuados, ao fim do desenvolvimento pois, assim, o usuário 
pode ter uma visão ampla do software. 
b) As etapas de teste são suprimidas do processo 
c) Ao final de cada etapa, o usuário é convidado a testar o módulo pronto, evitando, 
assim, erros muito complexos, ao final do desenvolvimento. 
 d) O processo é efetuado, apenas por profissionais que trabalharam no 
desenvolvimento do produto, tornando assim, o teste mais eficaz e próximo da 
realidade do cliente. 
 e) Todos os testes são realizados na etapa de concepção do software. 
QUESTÃO 13 Prova: IADES - 2010 - CFA - Analista de Sistemas 
Assinale a alternativa correta acerca da Programação Extrema (Extreme 
Programming - XP). 
 a) Na programação por pares, os códigos são escritos por dois programadores em 
cada máquina. Enquanto um dos programadores codifica, o outro é responsável para 
aspectos como a simplificação do código. 
 b) A refatoração tem por objetivo reestruturar um software e modificar as 
funcionalidades disponibilizadas pelo mesmo. Ao refatorar, um desenvolvedor pode 
eliminar duplicações e simplificar o projeto. 
 c) A estratégia adotada no projeto de software se baseia em contemplar todos os 
possíveis cenários de evolução empregando-se padrões de projeto. A implementação 
não inicia até ser concluído todo o projeto. 
 d) É recomendável que não se adotem padrões para as práticas de codificação e que 
não se limite a quantidade de horas trabalhadas por semana. 
 
 
 
www.tiparaconcursos.net Página 43 de 47 
QUESTÃO 14 Prova: FCC - 2010 - TRF - 4ª REGIÃO - Analista Judiciário - Tecnologia 
da Informação 
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. 
QUESTÃO 15 Prova: FCC - 2010 - DPE-SP - Agente de Defensoria - Analista de 
Sistemas 
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. 
QUESTÃO 16 Prova: FCC - 2010 - TRE-RS - Técnico Judiciário - Programação de 
Sistemas 
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. 
 
 
 
www.tiparaconcursos.net Página 44 de 47 
QUESTÃO 17 Prova: CESGRANRIO - 2010 - ELETROBRÁS - Analista de Sistemas - 
Suporte Basis SAP R3 
No âmbito do desenvolvimento ágil de sistemas de informação, é INCORRETO 
afirmar que, no SCRUM, 
 a) as atividades são definidas com uma duração fixa. 
 b) o foco é nas tarefas e não nos objetivos e resultados. 
 c) o desenvolvimento é iterativo e incremental. 
 d) cada iteração foca nas necessidades mais prioritárias. 
 e) cada iteração é finalizada com funcionalidades completas. 
QUESTÃO 18 Prova: FCC - 2011 - TRT - 1ª REGIÃO (RJ) - Analista Judiciário - 
Tecnologia da Informação 
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. 
QUESTÃO 19 Prova: FCC - 2011 - INFRAERO - Analista de Sistemas - Arquitetura de 
Software 
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. 
 
 
 
www.tiparaconcursos.net Página 45 de 47 
 e) Sprint, Scrum Team e Product Backlog. 
QUESTÃO 20 Prova: FCC - 2012 - TST - Técnico Judiciário - Programação 
A Sprint é considerada o coração do Scrum. Uma nova Sprint inicia-se imediatamente 
após a conclusão da Sprint anterior. Durante a Sprint 
a) o escopo pode ser clarificado e renegociado entre o Product Owner e a Equipe de 
Desenvolvimento. 
 b) a composição da Equipe de Desenvolvimento muda constantemente. 
 c) as metas de qualidade podem ser reduzidas para dar mais agilidade ao 
desenvolvimento. 
 d) são permitidas alterações no time-box da próxima Sprint para horizontes 
superiores a um mês, de acordo com os padrões flexíveis de tempo do Scrum. 
 e) são permitidas as definições de mudanças que podem afetar o seu objetivo. 
QUESTÃO 21 Prova: CESGRANRIO - 2010 - ELETROBRÁS - Analista de Sistemas - 
Suporte Basis SAP R3 
Disciplina: Engenharia de Software | Assuntos: Metodologias Ageis; Scrum; 
No SCRUM, que papel é responsável pela visão do produto e pelo retorno do 
investimento? 
 a) Scrum Master. 
 b) Product Owner. 
 c) Sprint Planner. 
 d) Gerente do Projeto. 
 e) Analista de Sistemas Sênior. 
QUESTÃO 22 Prova: FCC - 2011 - TRE-AP - Técnico Judiciário - Programação de 
Sistemas 
As práticas se baseiam em técnicas ágeis, tais como, Test Driven Development (TDD), 
Agile Model Driven Development (AMDD) e Database Refactoring, concentrando as 
atividades de análise, desenho e requisitos unicamente na disciplina Modelagem. 
Trata-se de 
 a) AUP. 
 b) SCRUM. 
 c) XP. 
 
 
 
www.tiparaconcursos.net Página 46 de 47 
 d) AUP e SCRUM. 
 e) XP e SCRUM. 
QUESTÃO 23 Prova: FCC - 2011 - TRT - 23ª REGIÃO (MT) - Técnico Judiciário - 
Tecnologia da Informação 
FDD (Feature Driven Development) é uma metodologia muito objetiva, possuindo 
apenas duas fases: 
 a) Concepção & Planejamento e Construção. 
 b) Decomposição Funcional e Construção. 
 c) Análise dos Requisitos e Desenvolvimento. 
 d) Planejamento Incremental e Desenvolvimento por Funcionalidade. 
 e) Planejamento por Funcionalidade e Construção por Funcionalidade. 
QUESTÃO 24 Prova: FCC - 2010 - TRF - 4ª REGIÃO - Analista Judiciário - Tecnologia 
da Informação 
A Feature Driven Development (FDD) é uma metodologia ágil de desenvolvimento de 
software, sobre a qual é correto afirmar: 
 a) Não pode ser combinada a outras técnicas para a produção de sistemas. 
 b) Possui cinco processos: Desenvolver um Modelo Abrangente, Construir a Lista de 
Funcionalidades, Planejar por Funcionalidade, Detalhar por Funcionalidade e 
Implementar por Funcionalidade. 
 c) Divide os papéis em dois grupos: papéis chave e papéis de apoio. Dentro de cada 
categoria, os papéis são atribuídos a um único participante que assume a 
responsabilidade pelo papel. 
 d) Mantém seu foco apenas na fase de modelagem. 
 e) Mantém seu foco apenas na fase de implementação. 
QUESTÃO 25 Prova: FCC - 2010 - AL-SP - Agente Técnico Legislativo Especializado - 
Tecnologia da Informação 
São consideradas metodologias ágeis de desenvolvimento de software: 
a) XP e UP. 
 b) SCRUM de DSDM. 
 c) SCRUM e RUP. 
 d) DSDM e Cascata. 
 
 
 
www.tiparaconcursos.net Página 47 de 47 
 e) Cascata e PRINCE2. 
QUESTÃO 26 Prova: FCC - 2009 - TRE-AM - Técnico Judiciário - Programação de 
Sistemas 
São algumas das metodologias de desenvolvimento de software consideradas ágeis 
(Agile Software Process Models): 
 a) RUP, XP e DSDM. 
 b) Waterfall, RUP e FDD. 
 c) XP, FDD e RUP. 
 d) Scrum, XP e FDD. 
 e) Scrum, Waterfall e DSDM. 
4. Gabarito. 
01 - B 
02 - E 
03 - D 
04 - B 
05 - E 
06 - B 
07 - E 
08 - D 
09 - C 
10 - A 
11 - E 
12 - C 
13 - A 
14 - C 
15 - A 
16 - E 
17 - B 
18 - B 
19 - A 
20 - A 
21 - A 
22 - A 
23 - A 
24 - B 
25 - B 
26 - D