Aula 05

Aula 05
Caixa Econômica Federal - CEF (Técnico

Bancário - TI) Engenharia de Software
Autor:
Fernando Pedrosa Lopes , Diego
Carvalho
12 de Janeiro de 2023
Fernando Pedrosa Lopes , Diego Carvalho
Aula 05
Índice
1) Metodologias Ágeis - XP
..............................................................................................................................................................................................3
2) Questões Comentadas - Metodologias Ágeis - XP - Multibancas

..............................................................................................................................................................................................
17
3) Lista de Questões - Metodologias Ágeis - XP - Multibancas

..............................................................................................................................................................................................
34
Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 2

www.estrategiaconcursos.com.br 44
Aula 05
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á...
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...

Aula 05

Aula 05
EXTREME PROGRAMMING (XP)

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.

Aula 05
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.

Aula 05
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:
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

Aula 05
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
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...
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)

Aula 05
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:
(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.

Aula 05
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
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

Aula 05
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:
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).

Aula 05
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
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.
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.

Aula 05
==2c9479==
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
Valores Fundamentais
VALORES
DESCRIÇÃO
FUNDAMENTAIS

Aula 05
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.
coragem SIMPLICIDADE COMUNICAÇÃO FEEDBACK RESPEITO

Cor Sim Com Fe Re
CorSim ComFeRe
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:

Aula 05
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
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.

Aula 05
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.
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á...

Aula 05
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:

Aula 05
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.
==2c9479==
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.

Aula 05
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.

Aula 05
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.

Aula 05
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.

Aula 05
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).

Aula 05
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.

Aula 05
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:

Aula 05
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.

Aula 05
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

Aula 05
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.

Aula 05
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.

Aula 05
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.
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) 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.

Aula 05
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

Aula 05
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:
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 é
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 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
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
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
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

Aula 05
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).

Aula 05
Gabarito: Letra E

Aula 05
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

Aula 05
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.

www.estrategiaconcursos.com.br
2 44
10
Aula 05
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.

3 44
10
Aula 05
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.

4 44
10
Aula 05
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.

5 44
10
Aula 05
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.

6 44
10
Aula 05
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.
Quais estão corretas?
a) Apenas I.
b) Apenas I e II.
c) Apenas I e III.

7 44
10
Aula 05
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.
==2c9479==
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?

8 44
10
Aula 05
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.

9 44
10
Aula 05
1. LETRA B
2. ERRADO
3. ERRADO
4. CORRETO
5. ERRADO
6. CORRETO
7. LETRA B
8. LETRA E
9. LETRA B
10. LETRA D
11. LETRA B
12. LETRA E
13. LETRA C
14. LETRA A
15. LETRA B
16. ERRADO
17. LETRA A
18. LETRA D
19. LETRA A
20. LETRA D
21. LETRA D
22. LETRA D
23. CORRETO
24. LETRA E
25. LETRA E
26. LETRA D
27. LETRA C
28. LETRA B
29. CORRETO
30. LETRA E

1044
10

Aula 05 - Simplificado

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 05 - Simplificado

Enviado por

Direitos autorais:

Formatos disponíveis

Caixa Econômica Federal - CEF (Técnico

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

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

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 2

PROFESSOR DIEGO CARVALHO - www.instagram.com/professordiegocarvalho

INCIDÊNCIA EM PROVA: baixíssima

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 3

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 4

EXTREME PROGRAMMING (XP)

Em 1996, Kent Beck desenvolveu um novo paradigma de

O eXtreme Programming é uma metodologia ágil de desenvolvimento de software para

A equipe de desenvolvimento (ou programadores) avalia cada um dos cenários e os divide em

No XP, o desenvolvimento incremental é apoiado por pequenos e frequentes releases do

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 5

Histórias de Usuário (User Stories) são artefatos de desenvolvimento utilizados em sistemas

Histórias de usuário podem ser razoavelmente estimadas pelos desenvolvedores e as histórias

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 6

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 7

E como seria o processo do Extreme Programming? Galera, no contexto de programação, a

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 8

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 9

De forma simples, a velocidade do projeto é o número de histórias de clientes implementadas

O Extreme Programming encoraja o uso de cartões CRC (Classe – Responsabilidade -

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 10

continuamente modificado conforme a construção prossegue. O objetivo é controlar modificações

Conforme a dupla de programadores completa o trabalho, o código que desenvolveram é integrado

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 11

Como os testes de unidades individuais são organizados em um “conjunto de testes universal”, os

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 12

A equipe pode fazer algum protótipo ou desenvolvimento-teste para entender o problema e a

PROCESSO PARA DESENVOLVER UM INCREMENTO

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 13

Para se desenvolver um sistema de software, exige-se comunicar os requisitos de sistema para

O feedback ocorre quando os testes unitários ou testes de integração retornam o estado do

A coragem permite que os desenvolvedores se sintam confortáveis com ao refatorar o seu

coragem SIMPLICIDADE COMUNICAÇÃO FEEDBACK RESPEITO

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 14

Princípios básicos DESCRIÇÃO

Um preceito essencial da engenharia de software tradicional é projetar mudanças. Em outras

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 15

Como consequência, algumas abordagens para o desenvolvimento incremental têm um

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 16

1. (COMPERVE / TJ-RN – 2020) O método ágil Extreme Programming ou XP é um dos métodos

3. (CESPE / Ministério da Economia – 2020) Como forma de agilizar as implantações de

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 17

4. (CESPE / Ministério da Economia – 2020) Os programadores trabalham em pares para que um

Uma das práticas do XP é a programação em pares! Os desenvolvedores trabalham em pares, um

6. (CESPE / Ministério da Economia – 2020) O XP possui planejamento incremental com

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 18

a) Reformation - Pair Programming - PlayStation Game

- Não existe prática chamada reformation e, sim, refactoring;

Logo, trata-se de: Refactoring, Pair Programming e Planning Game.

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

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

a) Apenas as operações mais críticas devem possuir testes unitários.

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 19

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

a) é, assim como o test-driven development, uma prática da XP (Extreme Programming) que

Caixa Econômica Federal - CEF (Técnico Bancário - TI) Engenharia de Software 20

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

c) enfoca, assim como o acceptance test-driven development, a qualidade do código

d) pressupõe o uso do behavior driven development, que considera a linguagem de

e) enfoca a integração contínua como uma prática de desenvolvimento de software,