Programação Extrema (XP) 

Eduardo Freitas​1​, Ana Luíza V. Gama​1​, Carlos Antonio G. Martins​1​, Cleberson 
Teodoro​1​, Rafael Spoladore F. dos Reis​1​, Evanise Araujo Caldas​2 
1​
Graduandos de Sistemas de Informação – Faculdade de Ciências Exatas e Tecnologia 
(FACET) – Universidade Federal da Grande Dourados (UFGD) 
Caixa Postal 364 – 79.804-970 – Dourados – MS – Brazil 
2​
Professora da Faculdade de Ciências Exatas e Tecnologia (FACET) – Universidade 
Federal da Grande Dourados (UFGD) 
{oeduardofreitas,analuizavenite,boatardevei,clebersonteodoro28,
rafaspol,profevanisecaldas}@gmail

Abstract.  ​This paper presents a brief explanation about the characteristics of

Extreme Programming (XP), approaching its values and practices, as well as
its applications and limitations. At the end some case studies about this
methodology of software development are presented.  
Resumo. ​Este trabalho apresenta uma breve explicação sobre as características da
Programação Extrema (XP), abordando seus valores e práticas, bem como as
suas aplicações e limitações. Ao final são apresentados alguns estudos de
caso sobre essa metodologia de desenvolvimento de software.  

1. Introdução 
A  Programação  Extrema  (XP)  é  uma  metodologia  de  desenvolvimento  de  software  do 
tipo  Ágil  para  equipes  pequenas  e  médias  que  desenvolvem  software  baseado  em 
requisitos vagos e que se modificam rapidamente [Astels, Miller e Novak 2002]. 

Desenvolvida  nos  anos  90  do  século  XX,  a  XP  se  difundiu  rapidamente a partir 
da  primeira  década  deste  novo  século  ao  ser  adotada  como  metodologia  de 
desenvolvimento  por  muitas  companhias,  principalmente  por  startups  e  empresas  de 
consultoria, como a ThoughtWorks [Highsmith 2002]. 

Entre  as  principais diferenças da XP em relação à metodologias clássicas estão o 

feedback  c​ ontínuo,  a  abordagem  incremental  e  o  encorajamento  da  comunicação  entre 
as  pessoas  [Beck  2004].  Seu  principal  objetivo  é  dar  agilidade  ao  desenvolvimento  do 
projeto  e garantir a satisfação do cliente. Suas práticas, regras e valores buscam criar um 
ambiente  agradável  de  desenvolvimento  de  software  para  os  seus  aplicadores  [Beck  e 
Fawler 2001]. 

Ao  abordar  a  XP,  este  artigo  a  contextualiza  e  descreve  suas  características 

principais e fundamentos. 
 

2. História 
Em  1993,  a  fabricante  de  automóveis  Chrysler  iniciou  um  projeto  chamado  Chrysler 
Comprehensive  Compensation  System  (apelidado  de  C3)  [Keefler  2002],  que  visava 
substituir  o  então  conjunto  de  sistemas  que  proviam  a  folha  de  pagamento  da  empresa 
[Copeland  2001],  que  na  época  tinha  87  mil  funcionários  [Keefler  2002], por um único 
sistema,  que  seria  construído  usando  a  linguagem  de  programação  Smalltalk  e  o  banco 
de dados GemStone [Fowler 2004]. 

Três  anos  depois,  como  o  sistema  C3  parecia  longe  de  ser  completado  e  ainda 
não  tinha  produzido nem uma única folha de pagamento [Highsmith 2002], o experiente 
programador  Smalltalk  Kent  Beck  foi  contratado  para  tentar salvar o projeto [Copeland 
2001].  A  missão  de  Beck  era  otimizar  o  funcionamento  do  que  já  tinha  sido 
desenvolvido,  porém  logo  ficou  evidente  que  o  problema  era  mais  crítico  e  se  devia, 
principalmente,  à  ausência  de  uma  boa  metodologia  de  desenvolvimento,  o  que  estava 
levando  a  equipe  à  um  redemoinho  de  complexidade,  improdutividade  e  estresse 
[Hendrickson 2001]. 

Para ajudá-lo, Beck trouxe para o time Ward Cunningham e Ron Jeffries [Beck e 
Fowler  2001].  Cunningham  era  então  também  um  experiente  programador, 
especializado  em  padrões  de  projeto  de  software  e  que  hoje  é  reconhecido  como  o 
inventor  do  wiki,  pois,  em  1994,  desenvolveu  a  primeira  versão  do  WikiWikiWeb 
[Ebersbach  et  al  2008]. Já Jeffries assumiu o papel de coach, para difundir pela equipe a 
nova  metodologia  que  estavam  criando  para  tentar  dar  vazão  ao  desenvolvimento  do 
C3. Os três são considerados os fundadores da XP. 

Após  um  ano  de  trabalho,  o  trio  oficializou  a  primeira  versão  da  nova 
metodologia  com  o  nome  pelo  qual veio a ser conhecida em todo o mundo. Foi também 
em  1997  que  o  C3  foi  finalmente  lançado,  teve  vários  problemas  de  performance,  que 
foram  corrigidos  ao  longo  desse  ano  [Garzaniti  1999].  Continuou  sendo  desenvolvido 
até  1999,  um  ano  depois  da  Chrysler  ter  sido  comprada  pela  montadora  alemã 
Daimler-Benz.  Ironicamente,  o  C3  nunca  conseguiu  prover  todas  as  folhas  de 
pagamento  para  toda  a  empresa,  alcançando  no  máximo  10  mil  funcionários  até  ser 
oficialmente desativado em fevereiro de 2000 [Rosenberg e Stephens 2004]. 

Apesar  do  aparente  fracasso  do  projeto  C3,  a  metodologia  XP  passou  a  ser 
adotada  em  todo  o  mundo  com  a  difusão  das  ideias  de  Beck,  Cunningham  e  Jeffries, 
principalmente  a  partir  do  wiki  de  Cunningham,  pelo  site 
www.extremeprogramming.org  (esse  lançado  por  um  adepto)  e  pelo  "Manifesto  for 
Agile  Software  Development"  (documento  que  marca  o  pontapé  das  metodologias  de 
tipo  Ágil, do qual são signatários), mas também pelos livros que esses autores lançaram, 
nos quais defendiam, explicavam e ensinavam o funcionamento da XP. 

3. Conceitos base 
A  XP  é  uma  maneira  leve,  eficiente,  de  baixo  risco,  flexível,  previsível,  científica  e 
divertida  de  desenvolver  software  [Beck  2004].  Tem,  como  principais  diferenças  em 
relação  à  outras  metodologias  o  feedback  contínuo,  derivado  dos  ciclos  curtos  e  a 
 

abordagem  Incremental  de  planejamento,  que  gera  rapidamente  um  plano  geral  que vai 
evoluir com o decorrer do projeto [Borborema 2007]. 

A  XP  é  a  combinação  de  uma  abordagem  colaborativa,  livre  de  desconfianças, 

com  um  conjunto  de  boas  práticas  de  engenharia  de  software  que  são  eficientes  por  si 
só,  individual  e  independentemente  do  contexto.  Cada  uma  dessas  práticas  contribui 
para  o  aumento  da  qualidade  do  software  e  ajuda a garantir que o produto final agregue 
valor e atenda as necessidades do negócio [Prikladnicki, Will e Milani 2014]. 

Durante anos, a produção de software foi feita com base em modelos antigos que 
aparentemente  funcionavam,  tanto  que  no  início  da  década  de  80  a  revista  Business 
Week  apresenta  a  manchete  de  capa  “Software:  A  nova  força  propulsora”  [Pressman 
2011], isso devido à falta de amadurecimento dos processos de desenvolvimento. 

Passado  mais  de  20  anos,  o  Standish  Group  trazia  pesquisas  apontando  o 
insucesso  da  produção  de  software,  pois,  na  década  de  1990,  menos  de  20%  dos 
projetos  de  software  eram  concluídos  com  sucesso.  Essa  crise  levou  ao  descrédito  das 
empresas  de  softwares  no  mundo  todo  e  também  tinha  ocorrido  nas indústrias em geral 
como,  por  exemplo,  na  indústria  automobilística,  metalúrgica  e  outras.  A  crise  que  na 
década  de  1960  e  1970  fez  surgir  no  Japão  novos  modelos  de  produção,  entre  eles  a 
filosofia  ​Just  in  time  (JIT)  e  que  consiste  em  uma  proposta  de  reorganização  do 
ambiente  produtivo assentada no entendimento de que a eliminação de desperdícios visa 
o melhoramento contínuo dos processos de produção [Wake 2001]. 

3.1. Filosofia ​Just In Time​ (JIT) 

O  JIT  é  a  base  para  a  melhoria  da  posição  competitiva  de  uma  empresa,  em  particular 
no  que  se  refere  aos  fatores  velocidade,  qualidade  e  o  preço  dos produtos. JIT significa 
“produzir  bens  e  serviços  exatamente  no  momento  em  que  são  necessários  –  não  antes 
para  que  não  formem  estoques  e  não  depois  para  que  seus  clientes  não  tenham  de 
espera”.  Inspirado  no  sucesso  desta  filosofia,  Kent  Beck  criou  na  década  de  90  a 
Programação  Extrema  (XP)  que,  assim  como  o  JIT,  propõe  que  a  produção  deve  ser 
realizada  na  hora  exata,  ou  seja,  evita-se  gastar  tempo,  produzindo  por  antecedência 
[Barbosa 2005]. 

4. Valores 
A  XP  tem  como  base  quatro  valores  fundamentais  que  sustentam  as  boas  práticas  de 
desenvolvimento  de  software:  comunicação,  ​feedback​,  simplicidade  e  coragem  [Beck 
2004].  Esses  valores  são essenciais para guiar o desenvolvimento de software, mas cada 
equipe  XP  pode  definir  outros  valores  que  acreditam  ser  relevantes  dentro  da  sua 
realidade [Castro 2007]. 

4.1. Comunicação 

Geralmente,  projetos  de  software  são  produzidos  por  uma  equipe  de  desenvolvedores, 
sendo  assim,  cada  componente  da  equipe  precisa  trocar  informações  entre  si  e  com  o 
cliente  sobre  cada  detalhe  do projeto. Segundo Beck (2004), os problemas mais comuns 
ocorrem  por  erro  de  comunicação  entre  as  pessoas,  algumas  vezes  o  cliente  não 
 

conversou  sobre  algo  importante  e,  outras  vezes,  o  desenvolvedor  não  soube  fazer  as 
perguntas  corretas  para  o  cliente.  Justamente  por  isso  que  a  comunicação  é  tida  como 
um  dos  elementos  mais  importantes  no  desenvolvimento  de  software  [Borborema 
2007]. 

4.2. ​Feedback 

Feedback  ​constante  é  a  base  de  todos  os  processos  ágeis  de  desenvolvimento,  e  é  a 
filosofia  fundamental  da  XP,  pois  é  ele  que  permite  uma  maior produtividade, uma vez 
que  os  trabalhos  da  equipe  de  desenvolvimento  são  influenciados  e  direcionados  de 
acordo  com a constante resposta do cliente sobre determinada atividade. O ​feedback ​não 
é  exclusividade  da  XP  ou  das  metodologias  ágeis,  ela  também  está  presente  nos 
processos  tradicionais.  O  diferencial  está  nos  tempos  de  execução,  pois  nos  processos 
tradicionais  há  uma  defasagem  muito  grande  no  tempo  da  troca  de  informação  entre 
cliente  e  desenvolvedores,  isto  é  ruim  tanto  para  o  cliente  como  para  a  equipe  que 
precisa  encontrar  rapidamente  a  solução  que  atenda  as  necessidades  de  ambas as partes 
[Teles 2006]. 

4.3. Simplicidade 

Refere-se  a  desenvolver  apenas  o  suficiente  para  atender  as  necessidades  atuais  do 
cliente,  desprezando  qualquer  funcionalidade  não  essencial.  Mesmo  que  tal 
funcionalidade  esteja  ligada  com  a  evolução do produto, ela deve ser descartada até que 
se  tenha  absoluta  certeza  da  sua  necessidade.  Assume-se  assim  a  seguinte  estratégia: 
desenvolver  algo  simples  hoje  e  fazer  modificações  futuramente,  ao  invés  de 
desenvolver  algo  complexo  hoje  e  correr  o  risco  de  não  ser  utilizado  no  futuro  [Soares 
2004]. 

4.4. Coragem 

A  coragem  é  acima  de  tudo  uma  forma  de  pensamento  diferenciado  que  deve  ser 
adotado  por  todos  os  membros  da  equipe.  Isso  significa  que  as  mudanças  que  ocorrem 
no  projeto  não  devem  ser  encaradas  negativamente  apenas  como  problemas  a  serem 
resolvidos,  mas  sim  como  oportunidades  a  serem  exploradas  para  a  melhoria  como  um 
todo da equipe e do projeto [Beck e Fowler 2001]. 

5. Práticas 
A  XP  é  muito  flexível  e  pode  ser  utilizada  em  projetos  de  qualquer  tamanho,  mas  é 
recomendável atentar e seguir suas práticas [Medeiros 2006]. 

5.1. Cliente sempre disponível 

O  cliente  sempre  deve  estar  presente  no  projeto,  de  forma  ativa,  dando  dinamismo  ao 
desenvolvimento e colaborando com sugestões e tirando dúvidas [Medeiros 2006]. 

5.2. Uso de metáforas 

O  uso  de  metáforas  visa  facilitar  a  comunicação  entre  as  equipes,  definindo nomes que 
podem  ser  lembrado  com  mais  facilidade  pelos  envolvidos.  Por  exemplo,  um  sistema 
 

chamado  de  Cartão  de  Ponto  se refere a um software de gerência de batidas de ponto de 

funcionários em uma empresa [Medeiros 2013]. 

5.3. Planejando o jogo 

O  objetivo  do  planejamento  e  definir  o  escopo,  principalmente  o  tempo  de duração das 

interações  e  o  desenvolvimento  dos  requisitos  do  sistema,  onde  os  programadores 
estimam  o  prazo para as atividades serem realizadas. Geralmente, é utilizado um quadro 
branco  para  o  levantamento  de  informações  por  meio  de  textos  claros  ou  diagramas 
UML [Medeiros 2013]. 

5.4. Pequenas versões 

Ao  mesmo  tempo  que  as  interações  são  concluídas,  essas  pequenas  versões  são 
disponibilizadas  ao  cliente  para  validação e verificação de possíveis novas necessidades 
[Medeiros 2006]. 

5.5. Testes 

Essa  fase  é  técnica,  envolve  o  cliente  no  desenvolvimento  e na validação dos testes. Os 

testes  são  escritos  antes mesmo das funcionalidades, utilizando a técnica de ​Test-Driven 
Development​ (TDD, ou desenvolvimento orientado a testes) [Medeiros 2006]. 

5.6. Integração contínua 

O  código é integrado diariamente, todos os testes devem passar 100% em todas as fases, 
antes  e  depois  da  integração.  Caso  algum  problema  seja  encontrado,  ele  é  corrigido 
imediatamente [Medeiros 2013]. 

5.7. Simplicidade 

O  código  segue  padrões  definidos  pela  equipe  de  desenvolvimento,  facilitando  a 

manutenção do código por todos os membros da equipe [Medeiros 2006]. 

5.8. Refatoração 

Em  cada  nova  funcionalidade  é  trabalhado  o  código  com  a intenção de deixá-lo melhor 

e  o  mais  simples  possível,  mesmo  que  “mexer  em  código  funcionando”  cause  algumas 
divergências.  Essa prática nem sempre é aceita, por questões de prazo e custo [Medeiros 
2006]. 

5.9. Programação em pares 

Apesar  dessa  prática  por  em  discussão  a  questão  de  estar  gastando  dois  recursos 
humanos  ao  mesmo  tempo,  ela  possui  suas  vantagens,  como,  por  exemplo,  o 
nivelamento  de  conhecimento  técnico  na  equipe,  compartilhamento  de  conhecimento 
nas  regras  de  negócio  e  fortalece  as  propriedades  dos  padrões  adotados  pela  equipe 
[Medeiros 2006]. 

5.10. Otimização de jornadas de trabalho 

 

É  importante  o  gerenciamento  da  carga  horária  de  trabalho,  a  sobrecarga  pode 

fortemente  impactar  de  forma  negativa  a  qualidade  do  trabalho da equipe. O período 
de descanso da equipe é tão importante quanto o trabalho a fazer [Medeiros 2013]. 

6. Ciclo de vida 
Em  um ciclo de vida, um projeto XP passa por algumas fases [Santana 2014]. Cada uma 
dessas fases é composta de várias tarefas. 

Ao  invés  de  estruturar  as  atividades  de  forma  sequencial  como  em  processos 
tradicionais,  se  representa  cada  aspecto  que  o cliente deseja como uma estória onde, em 
conjunto, elas estão organizadas em sequência [Wells 2013]. 

Então  agora  é  possível  criar  a  estrutura  do  processo  em  ordem  de  importância. 
Também  podemos  mudar  de  ideia  em  relação  ao  que  quisermos  no  projeto  sem  altos 
custos [Wells 2013]. 

Também,  dessa  maneira,  esse  processo  permite que os gerentes estimem o custo 

por  cada  aspecto  ao invés de por cada atividade. É como se houvesse um tipo de lista de 
compra de requerimentos [Wells 2013]. 

O  ciclo  de  vida  do  processo  é  dividido  em  cinco partes que são o Planejamento, 

Gestão,  Modelo,  Codificação  e  Teste  [Wells  2013].  Estão  explicados  de  forma  mais 
detalhada nas figuras abaixo essas atividades. 

O  início  das  iterações  geralmente  se  dão  pelo  planejamento,  onde  é  feita  uma 
discussão  sobre  os  roteiros  de  testes, sobre o que houve de errado na iteração anterior, o 
que pode ser melhorado na atual, dentre outros [Medeiros 2007]. 

No  planejamento  as  estórias  são  escritas,  pequenas  unidades  de  funcionalidade 
do  projeto  são  feitas,  o  projeto  é  dividido  em  iterações,  etc.  Essa  fase  pode  ser 
observada mais detalhada figura 3 [Wells 2013]. 

As  estórias  servem  para  o  mesmo  propósito  que  os  casos  de  uso.  Elas  são 
escritas  pelo  cliente  dizendo  quais  as funcionalidades que o sistema precisam fazer para 
ele [Wells 2013]. 

Na  fase  de  gestão  é  interessante  que  se  tenha  um  ambiente  de  serviço  mais 
aberto  eliminando  possíveis  barreiras  que  dividem  as  pessoas,  definir  um  ritmo 
sustentável,  reuniões  em  pé  diariamente,  saber  do  andamento,  dentre  outros  [Wells 
2013]. 

A  comunicação  é  muito  importante para um time XP. Colocar computadores em 

uma  área  central  facilita  a  programação  em  par  e  encoraja  o  trabalho  em  grupo, 
quebrando barreiras que dividem as pessoas [Wells 2013]. 

Na etapa de projeto é importante simplicidade, uso de metáforas, a refatoração, o 
foco nas funcionalidades de maior prioridade, dentre outros [Wells 2013]. 
 

Um  design  simples  leva  menos  tempo  para  terminar  do  que  um  complexo.  É 
sempre  mais  barato  e  mais  rápido  substituir  um  código  complexo  por  um  código 
simples nessa fase [Wells 2013]. 

Na  codificação  é  relevante  a  disponibilidade  e  presença  do  cliente,  a 

padronização  dos  códigos,  a  programação  em  dupla,  a  integração  de  códigos,  dentre 
outros [Wells 2013]. 

O  código  deve  estar  formatado  de  acordo  como  padrão  aceito  pelo  grupo.  A 
padronização  mantém  o  código  consistente  e  fácil  para  todo  o  time  ler  e  refatorar, 
também incentiva o trabalho coletivo [Wells 2013]. 

Finalmente,  na  fase  de  Testes  todo  o  código  precisa  usar  os  testes  de  unidade, 
toda  entrega  de  código  deve  passar  pelos  testes  de  unidade  [Wells  2013].  E  testes  são 
criados quando um bug é encontrado. 

7. Gerência e papéis na XP 

Os papéis em times que usam a metodologia XP variam conforme o tamanho do 
projeto, a quantidade de pessoas envolvidas, entre outros fatores, o que deve ser 
considerado caso a caso [Pfleeger 2004]. 

Mesmo com essas variações, na XP há alguns papéis fundamentais e muito bem 

definidos, que todos os times em projetos XP precisam ter, a saber: gerência, cliente, 
desenvolvimento e testes. Esses quatro papéis principais compreendem funções que 
podem estar distribuídas e organizadas em indivíduos que os exercem sozinhos ou em 
times que os cumprem ao longo do projeto [Sommerville 2011]. 

7.1. Gerência 

A  gerência  é  normalmente  feita  por  um  gerente  ou  gestor.  Sua  responsabilidade  é 
coordenar  o  projeto,  auxiliando  os  outros  times  no  planejamento  e  organização.  Ele 
deve  agendar  as  reuniões  necessárias,  pautando-as  previamente,  estabelecendo  um 
tempo  máximo  para  que  elas  se  realizem  e,  ao  final,  componha  uma  ata  que  será 
enviada  aos  envolvidos  ou  times,  conforme  a  necessidade.  Essa  dinâmica  é  importante 
para  que  todos  os  convocados  já  conheçam  os  temas  que  serão  discutidos  na  reunião 
antes  dela  acontecer,  saibam  quanto  tempo  ela  deverá  durar,  assim  como  possam  ter 
uma compilação das resoluções definidas [Astels, Miller e Novak 2002]. 

Na  XP,  a  gerência  assume  um  outro  papel  fundamental,  que  é  a  de  mediar 
conflitos  internos  e  externos.  É  por  isso  que  seu  responsável  deve  continuamente 
estimular  a  comunicação,  o  feedback  e  o  respeito  entre  os  times  e  os  profissionais 
relacionados  ao  projeto,  que  são  alguns  dos  valores  que  embasam  a  XP.  No 
cumprimento  dessas  atividades,  a  gerência  exerce  o  papel  de  ​coach  (técnico  ou 
treinador),  que  é  o  de  ser  um  facilitador  que  guia  o  projeto  conforme  a  metodologia, 
seus  processos,  valores  e  práticas,  e  também  o  de  ​tracker  (rastreador),  instituindo 
métricas  necessárias  para  acompanhar  o  andamento  projeto  e  sua  eficácia  quanto  aos 
objetivos  traçados,  reunindo  e  difundindo  essas  informações  entre  os  participantes  em 
torno  de  parâmetros  quantitativos,  qualitativos,  temporais,  entre  outros.  Essas  duas 
 

funções,  de  coach  e  de  tracker,  podem  ser  feitas  pelo  próprio  gestor  ou,  quando 
necessário, delegados a um ou dois outros membros da gerência [Sommerville 2011]. 

Além disso, é também papel da gerência validar os prazos e responsabilidades 

acordados entre os times, cobrar esses times ou seus indivíduos para que esses prazos e 
responsabilidades se cumpram, e obter recursos requeridos pelos times (como mão de 
obra, equipamentos, alimentação etc.) [Loddi, Pereira, Casadei e de Souza 2010]. 

7.2. Cliente 

O cliente assume o papel de demandante do sistema ao qual o projeto busca atender. 

Pode ser representado por uma pessoa ou um conjunto delas, que normalmente, mas 
nem sempre, podem ser os usuários desse sistema ou mesmo uma área da empresa, 
como um departamento, representado por um interlocutor [Beck 2004]. 

O cliente não é um mero demandante na XP, tendo um papel crucial. O cliente é 

quem define o escopo do projeto, seu objetivo e a extensão da solução que será 
construída, bem como é sua responsabilidade alterar esse escopo sempre que necessário 
[Reis 2008]. 

Sendo as histórias de usuário uma ferramenta importante da XP, é o cliente 

quem as escreve, ordena e prioriza, para depois extrair, trabalhando em conjunto com a 
equipe de desenvolvimento, os requisitos que virarão atividades a serem desenvolvidas 
pelo projeto. Para isso, o cliente deve estar sempre disponível para tirar dúvidas e 
atender os outros times quando esses precisarem esclarecer quaisquer pontos. A partir 
dessas tarefas, o cronograma de desenvolvimento é acordado com os programadores (e 
depois validado com a gerência) [Sommerville 2011]. 

Cabe também ao cliente especificar os testes de aceite (ou testes de aceitação) 

[Sommerville 2011] e validar os resultados dos testes quando esses forem feitos. 

7.3. Desenvolvimento 

Um outro papel, dos mais importantes, obviamente é o de desenvolvimento, feito pela 

equipe de programadores. Além da codificação do projeto, implementando-o em seus 
devidos ambientes (desenvolvimento, homologação, produção etc.), refatorando e 
corrigindo bugs, na XP os programadores têm uma maior autonomia. Por isso, eles 
podem organizar e distribuir as responsabilidades dos membros do time, delegando 
conforme considerarem pertinente. Vale lembrar que isso é importante, dado que na XP 
grande parte da programação é feita em pares, procedimento que pode ser dificultado 
quando a formação desses pares é feita por imposição de alguma liderança do time ou 
pela gerência. Ou seja, é melhor que o próprio time tenha autonomia para decidir sobre 
os pares e a distribuição das tarefas [Teles 2006]. 

Para a plena fluidez do projeto, é importante que os programadores se 

mantenham próximos do cliente, pois é com ele que deverão extrair os requisitos das 
histórias de usuários, transformar esses requisitos em tarefas realizáveis e estimar o 
esforço, recursos necessários e, principalmente, os prazos para o cumprimento de cada 
tarefa, seguindo a ordem e prioridades estabelecidas pelo cliente — o que impacta 
 

diretamente no cronograma do projeto e resulta dessa interação entre programadores e 

cliente [Castro 2007]. 

7.4. Testes 

Por fim, o último papel essencial à um projeto XP é o de testes, que, dependendo do 
tamanho do projeto, podem ser feitos por testadores e analistas de testes trabalhando em 
uma equipe específica apenas para testes ou, como quando o projeto é enxuto, por 
membros de outros times, no desenvolvimento ou por usuários do sistema que está 
sendo desenvolvido e fazem parte da equipe do cliente. 

Basicamente, os testadores são responsáveis por, ao longo do projeto, atestar a 

qualidade do que está sendo desenvolvido, executando testes automatizados, testando 
novas funcionalidades e apresentando e validando junto ao cliente os resultados dos 
testes [Leite 2001]. 

Esses quatro papéis são os fundamentais para a concretização de um projeto 

dentro da XP, ainda que, conforme cada projeto, escopo e prazo, possam existir muitos 
outros papéis trabalhando nesses ou em outros times, como analista de recursos 
humanos, arquiteto de informação, arquiteto de sistema, consultor especialista, designer, 
gestor de produto, redator etc. 

8. Aplicação, uso e limitações 

A  equipe  que  usa  a  XP  deve  estar  preparada  para  mudanças  e  sempre  entregar  aquilo 
que  seja  realmente  funcional  em  seu  software  ao  cliente  [Tavares  2016].  Por  ser  uma 
metodologia  apoiada  em valores como simplicidade, comunicação, ​feedback e​  coragem, 
com  foco  na  qualidade  do  projeto  e  na  agilidade  dos  desenvolvedores,  a  XP  não  pode 
ser  aplicado  a  qualquer  projeto,  sendo  preferível  para  aqueles  que  possuem  alto  risco 
[Souza  2007]  e  que  lidam  com  mudanças  constantes  em  seus  requisitos.  Além  disso,  é 
apropriado  para  equipes  pequenas  e  médias  de  desenvolvimento,  que  tenham  de  dois  a 
doze integrantes [Loddi, Pereira, Casadei e de Souza 2010].  

Sendo  um  processo  dinâmico  e  flexível,  a  XP  não  é  recomendada  para  aquelas 
empresas  que  produzem  software  em  massa,  visto  que  se  aproximam  do  modelo  de 
desenvolvimento  em  cascata  [Teles  2005],  que  vai  contra  todas  as  práticas  e  valores 
adotados  pela  XP.  Dessa  forma,  deve  ser  usado  por  organizações  que  priorizam  os 
feedbacks  dos  clientes  e  o  aprendizado  contínuo  da  equipe  de  desenvolvimento, onde a 
comunicação  é  feita  a  todo  instante  e  os esforços são direcionados somente naquilo que 
agrega valor e que precisa entrar em produção [Medeiros 2013]. 

A  transição  dos  processos  de desenvolvimento tradicionais para a XP não é fácil 

no  começo,  onde  a  barreira  cultural  é  um  grande  obstáculo  a  ser  transposto  [Medeiros 
2013].  Os  velhos  hábitos,  como  os  contratos  de  escopo  fechado,  que  não  permitem 
mudanças  nos  prazos  e  custos,  são difíceis de serem abandonados. A solução para esses 
problemas  de  adaptação  não  ocorre  subitamente,  sendo que é preciso elaborar um plano 
 

para  que  essa  substituição  seja  feita  sem  aumentar  a  complexidade  da  situação 
enfrentada pela equipe. 

As  práticas  da  XP,  como  programação  em  par  e  a  disponibilidade  diária  do 
cliente,  podem  causar  surpresa  em  um  primeiro  contato,  e  apesar  do  sucesso  do  dele 
depender  do  conjunto  de  todas  as  práticas  e  valores  [Reis  2008],  elas  devem  ser 
adotadas  de  forma  incremental,  para  que  a  equipe  se  acostume  com  o  novo  modelo  de 
desenvolvimento. 

Ainda  no  contexto  dos  desafios  enfrentados  ao  usar  a  XP,  a equipe que trabalha 
com  essa  metodologia  deve  ser  um  grupo  maduro  o  suficiente  para  saber  lidar  com  as 
mudanças  inesperadas  em  fases  já  avançadas  do  projeto  e  saber  trabalhar  com  elas, 
elaborando  um  plano  que  tenha  sempre  como  objetivo  a  qualidade  do  que  está  sendo 
produzido.  

9. Estudos de caso 
9.1. Projeto do Comitê Olímpico 

O  Comitê Olímpico de um certo estado do Brasil procurou a equipe de desenvolvimento 
para  que  fizesse  os  seguintes  sistemas:  Sistema  de  Verificação  e  Planejamento  de 
Condicionamento  dos  Atletas,  que  deveria  se  comunicar  com  o  Sistema  de 
Condicionamento  dos  Atletas,  dentro  do  Portal  de  Aperfeiçoamento  Esportivo  [Teles 
2005].  Essa  comunicação  é  importante  para  que  se  tenha  um  controle  sobre  as 
atividades  realizadas e para que seja possível gerar boletins dos desportistas contendo os 
exercícios por eles feitos.  

O  comitê  tinha  o  objetivo  de  aprimorar  as  habilidades  de  seus  atletas  para  que 
eles  obtivessem melhores resultados nas competições. Tais habilidades são identificadas 
anualmente,  através  do Sistema de Verificação e Planejamento de Condicionamento dos 
Atletas  (a  partir  de  agora  chamaremos  apenas  de  Sistema  de  Verificação),  nesse 
momento  as equipes esportivas devem definir um conjunto de níveis de proficiência que 
esperam  que  os  atletas  alcancem  nas  habilidades  que  possuem  e,  caso  existam algumas 
que  são  deficitárias,  deve-se  elaborar  um  Plano  de  Condicionamento  para  que  sejam 
aperfeiçoadas.  

Um  ​workshop  ​foi  realizado  para  ter  um  levantamento  detalhado  dos  requisitos 
do  projeto  e  para  promover  um  ambiente  aberto  para  discussões  e  sugestões.  Dessa 
forma,  a  equipe  de  Consórcio,  responsável pela execução do projeto, conheceu todos os 
detalhes  e  elaborou  um  relatório  que  serviu  para  a  contratação  e  implementação  do 
sistema  [Teles  2005].  Ao  propor  o  uso  da  XP  no  projeto,  a  equipe  de  Consórcio  gerou 
uma  divisão  entre  o  cliente  e  a  equipe  de  desenvolvimento.  O  cliente,  que  possuía 
conhecimentos  na  área esportiva, achava benéfico essa participação ativa com sugestões 
 

de  mudanças,  caso  necessário.  Já  a  equipe  de  desenvolvimento  via  essa  presença 
constante  como um risco, já que o cliente poderia sugerir muitas alterações e dificultar o 
prazo de entrega do projeto. 

Após  muitas  discussões  sobre  a  melhor  forma de usar a XP, com escopo fixo ou 

escopo  priorizável,  o  cliente  escolher  a última opção por possuir um valor menor. Além 
disso,  era  algo  favorável  para  a  própria  equipe  de  Consórcio,  pois  se  isentava  da 
imposição  de  entregar  todo  o  escopo  (tudo o que foi pedido) dentro do prazo. Assim, se 
comprometeu  em  entregar  apenas  aquilo  que  era  prioridade  e  estivesse  dentro do prazo 
estabelecido [Teles 2005].  

Logo  no  início  do  processo  de  desenvolvimento  ficou  evidente  que  não  seria 
possível  entregar  os  dois  sistemas  pedidos  dentro  do  prazo,  sendo  assim,  os  esforços 
foram  direcionados  exclusivamente  ao  Sistema  de  Verificação.  Muitos  fatores 
contribuíram  para  essa  inviabilidade,  como  o  fato  de  ser  algo  inédito  e  complexo  para 
desenvolver,  sendo  preciso  lidar  com  diversos  fatores  desconhecidos  de  risco,  como  o 
conjunto  específico  das  habilidades  e  o  nível  de  proficiência  em  cada  uma  delas.  O 
tamanho  da  equipe  foi  outro  fator  que  dificultou  a  implementação,  já  que  contava 
apenas  com  quatro  desenvolvedores  e  um  ​coach  [Teles  2005],  o  que  era  um  número 
pequeno para o tanto de trabalho a ser feito. 

O  representante do cliente foi a pessoa que teve o contato diário com a equipe de 
desenvolvimento  e,  por  possuir  pouco  conhecimento  e  o adquirir durante a evolução do 
projeto,  sugeriu  que  muitas  mudanças  fossem  feitas  nos  aspectos  conceituais,  visuais  e 
estéticos.  Todas  essas  modificações  levaram  a  uma  demora  para  o  que  os  prazos 
estipulados  fossem  atingidos,  mas  foram  importantes  para  que  as  falhas  fossem 
corrigidas  e  não  colocassem  em  risco  o  funcionamento  do  sistema,  mostrando  a 
importância  das  iterações  e  dos  ​feedbacks  ​rápidos  [Teles  2005].  Os  desenvolvedores, 
seguindo  as  práticas  da  XP,  optaram  por  manter  um  design  simples  e  fazer  a  evolução 
da arquitetura de acordo com as necessidades das funcionalidades.   

9.2. Aplicação desenvolvida para um sistema acadêmico 

O  sistema  deveria  fazer  o  controle  de  alunos,  professores,  cursos,  disciplinas,  turmas  e 
notas dos alunos referentes a cada disciplina [Barbosa 2005].  

Diferentes  atores  do  sistema  possuem  diferentes  acessos  a  ele.  O  administrador 

pode  cadastrar  alunos,  professores,  cursos,  disciplinas,  turmas  e  notas.  Os  professores 
podem  acessar  somente  as  disciplinas  por  eles  ministradas  e  as  notas  dos  alunos,  e 
também  modificar  suas  senhas  de  acesso.  E  os  alunos,  por  sua  vez,  têm  acesso  restrito 
às  suas  notas  e  podem  alterar  suas  senhas  de  acesso.  Administradores  e  professores 
 

podem  gerar  relatórios  sobre  os  alunos,  contendo  suas  notas,  e  frequência  nas  matérias 
em que estão matriculados.  

Após  ter  todos  os  requisitos  definidos,  o  primeiro  release  foi  implementado  e 
entregue,  com  as  interfaces  e  funcionalidades  referentes  aos  cadastros  de  alunos  e 
cursos.  O  cliente  enviou  alguns  feedbacks,  relatando  aquilo  que  deveria  ser  alterado, 
como marcar campos para somente leitura para evitar a ocorrência de erros.  

O  segundo  release  contou  com  o  controle  das  disciplinas,  professores  e  turmas. 

E,  assim  como  no  release  anterior,  as  funcionalidades  de  inclusão,  alteração  e exclusão 
foram implementadas, aqui o cliente também sugeriu algumas mudanças.  

Esse  projeto  contou  com  quatro  releases,  porém  nem  todas  as  práticas  da  XP 
foram  utilizadas, como a programação em par e o código coletivo, visto que são práticas 
realizáveis  apenas  em  equipe,  e  a  aplicação  foi  desenvolvida  por  apenas  uma  pessoa. 
Mas  é  evidente  a  participação  ativa  do  cliente  em  todas  as  fases  do  desenvolvimento, 
contribuindo  para  que  o  projeto  fosse  cumprido  dentro  do  prazo  e  do  custo 
anteriormente estabelecidos e garantindo que os requisitos fossem atendidos. 

9.3.  Estudo  de  caso  sobre  uma  pequena  empresa  voltada  para  o  desenvolvimento 
Web 

A  empresa  Ilha  Web  não  seguia  nenhum  modelo  de  desenvolvimento  de  software  até 
algum  tempo  depois  de  sua  fundação.  E,  por  causa  dessa  cultura,  muitos  problemas 
surgiram,  como  a  falta  de  padronização  nos  projetos  feitos,  atrasos  na  entrega  de 
produtos  de  qualidade  e  altas  taxas  de  retrabalho,  causadas  pela  necessidade  de 
repetição  de  tarefas.  Além  disso,  tudo  o  que  um  desenvolvedor  produzia  ficava 
vinculado  à  ele,  ou  seja,  essa  pessoa  era  a  única  que  entendia  como  aquele  trecho  de 
código  funcionava  e  se  integrava  com  o  restante  do  sistema  [dos  Santos  2013], 
sobrecarregando  o  seu  trabalho,  visto  que  ele  já  estava  envolvido  em  outros  projetos  e 
tinha que pausar o que estava fazendo e ajustar o código antigo.   

O  uso  da  XP  foi  sugerido  por  um  membro  da  equipe  de  desenvolvimento  para 
que  os  problemas  anteriormente  citados  fossem  resolvidos.  Se  os  resultados  obtidos 
fossem  satisfatórios,  a XP seria adotado como modelo definitivo de desenvolvimento de 
software.  

A  empresa foi procurada para que desenvolvesse uma rede social que deveria ser 
capaz  de  criar  uma  rede  de  amigos,  álbum  de  fotos,  postar  vídeos,  enviar  convites, 
realizar  enquetes,  enviar  mensagens  privadas  entre  os  usuários,  criar  fóruns  de 
discussão,  ter  bate-papo,  além  de  ter  uma  identidade  visual  [dos  Santos  2013].  As 
discussões  sobre  como  prosseguir  com  o  trabalho  foram  iniciadas  e  o  cliente  cedeu um 
de  seus  colaboradores  para  que  trabalhasse  junto  com  os  desenvolvedores,  sendo  sua 
 

participação  muito  importante  para  que  as  características  do  projeto  fossem  passadas  à 
equipe de maneira correta [dos Santos 2013]. 

Assim  como  em  outros  casos,  essa  presença  diária  do  cliente  não  foi  bem 
recebida  no  começo,  pois,  ainda  habituados  com  a  cultura  antiga,  a  equipe  acreditava 
que  ele  pediria  coisas  fora  do  escopo,  dificultando  o  trabalho  realizado.  Mas  logo 
percebeu-se  que esse contato direto seria algo benéfico, pois assim era possível entender 
exatamente  aquilo que o cliente pedia e receber ​feedbacks r​ ápidos, evitando o retrabalho 
em muitos casos. 

As  funcionalidades  foram  levantadas  pelo  cliente  e  foram  transformadas  em 

histórias  para  que  fossem  implementadas.  E  assim,  em  cada  entrega  das  releases,  uma 
reunião  era  convocada  para  que  o  cliente  realizasse  os  testes  de  aceitação e relatasse as 
mudanças  necessárias,  além  de  definir  as  novas  prioridades  que  deveriam ser entregues 
na reunião seguinte.  

A ideia de design simples foi adotada desde o começo do planejamento, para que 
a  equipe  tivesse  uma  maior  agilidade  para  implementar  somente  o  que  era  prioritário  e 
para que respondesse de maneira rápida às modificações pedidas.  

A  programação  em  par  contribuiu  para  que  o  conhecimento  da  equipe  fosse 
nivelado  e  legibilidade  de  código  fosse melhorada, visto que todos precisavam entender 
o  que  estava  sendo  feito,  além  de  facilitar a detecção de erros. A equipe passou a usar o 
Desenvolvimento  Orientado  a  Testes  (TDD),  onde  cada  funcionalidade  era  concluída 
com  seus  próprios  conjuntos  de  testes  unitários,  ajudando na refatoração e contribuindo 
para  que  a  equipe  ficasse  tranquila  em  fazer  as  modificações,  pois  os  erros  eram 
automaticamente percebidos e resolvidos. 

Com  o  projeto  já finalizado e entregue, a equipe concluiu que, com o uso da XP, 

o  produto  entregue  foi  de  qualidade  superior  aos projetos anteriores [dos Santos, 2013]. 
O  cliente  também  avaliou  essa  abordagem  como  positiva,  visto  que  participou 
ativamente  do  processo  de  desenvolvimento,  destacando  a  facilidade  de comunicação e 
a oportunidade de fornecer feedbacks rápidos à equipe. 

9.4. Aplicativo para calcular a Gratificação de Incentivo à Docência (GID) 

O  GID  foi  construído  com  base  nas  normas  do  Comitê  de  Avaliação  Docente  do 
CEFET/SC.  A  escolha  da  Programação  Extrema  se  deu  pelo  fato  que  a XP se destina a 
projetos  nos  quais  o  cliente  não  necessita  de  uma  documentação  formal,  o  time  de 
desenvolvimento  pode  ser  pequeno  e  o  prazo  de  execução  dura  poucos  meses  [Bona  e 
Thiry 2003].  
 

A  fase  de exploração consistiu numa conversa com o cliente para compreender o 
que  o  sistema  deveria  fazer.  Foi  definido  que  os  professores  deveriam  ser  classificados 
em  grupos  para  que  a  pontuação  fosse  aplicada  e,  conforme  o  grupo,  existiria  um 
critério  de  avaliação,  isto  é,  uma  sequência  de  procedimentos  e  cálculos  que  o  sistema 
executa  [Bona  e  Thiry  2003].  ​O  objetivo  do  sistema  é  gerenciar  esses  pontos  obtidos 
pelos docentes e gerar informações para os recursos humanos. 

Para  obter  o  sucesso  esperado,  um  representante  do  cliente  foi  incluído  no  time 
de  desenvolvimento para que guiasse o projeto definindo requisitos e prioridades. Sendo 
assim,  o  uso  das  metáforas  se  fez  necessário  para  que  os  termos  utilizados  fossem 
entendidos  por  todos,  sanando  os  problemas  de  comunicação  e  facilitando a elaboração 
de uma interface para o usuário [Bona e Thiry 2003]. 

As  histórias  elaboradas  pelo  cliente  foram  classificadas  de  acordo  com  a  sua 
prioridade.  As  de  prioridade  alta  deveriam  ser  implementadas  rapidamente,  as  de 
prioridade  média  poderiam  esperar  por  um  tempo,  mas  continuavam  sendo  necessárias 
para  o  bom  funcionamento  do  sistema  e,  por  fim,  as  de  prioridade  baixa  seriam  feitas 
somente  após  a  conclusão  das  outras.  Com  a  definição  do  que  deveria  ser  feito  por 
primeiro,  a  equipe  estabeleceu  também  o  prazo  para  a  finalização  dessas  prioridades, 
dividindo-as  em  tarefas  para  que  o  tempo  fosse melhor organizado e facilitar o trabalho 
da equipe. 

A  equipe  fez  uso  do  TDD  também para que os testes fossem aceitos. Eles foram 

realizados  de  forma  incremental,  sendo  incluídos  um  de  cada  vez  e  fazendo  com  que 
fossem validados.   

O  primeiro teste foi para especificar e validar o comportamento do sistema, onde 
o  objetivo  era  examinar  a  pontuação  do  docente  que  foi  obtida  através  de  uma fórmula 
para calcular a carga horária [Bona e Thiry 2003].   

O  segundo  consistia  em  validar  a  pontuação  obtida  através  da  relação  existente 
entre as responsabilidades do professor e o número de alunos.   

O  terceiro  teste,  por  sua  vez,  foi  feito  com  o  intuito  de  avaliar  a  quantidade  de 
aulas  ministradas,  onde  os  pontos  foram  limitados  por  assiduidade  e  atribuições 
didáticas e pedagógicas [Bona e Thiry 2003].   

O  quarto  e  último  teste  foi  feito  para  atribuir  os  pontos  pela  participação  do 
docente  em  projetos  de  pesquisa,  utilizando  uma  fórmula  de  acordo  com  o grupo que o 
professor estava inserido. 

A  XP  foi  indicado  para  esse  projeto  pois  o  ritmo  de  desenvolvimento  tinha  que 
ser  rápido  e porque o cliente não sabia exatamente por onde começar a especificar o que 
 

ele  precisava,  o  que  leva  a  uma  maior  probabilidade  de  mudança  de  ideias  [Bona  e 
Thiry 2003] durante o ciclo de vida do sistema.  

10. Conclusão 
A  Programação  Extrema  foi  fortemente  alavancada  no  início  do  século  XXI 
principalmente  pelo  crescimento  vertiginoso  de  novas  empresas  de tecnologia, como as 
startups  de  software  e  ​cloud  computing  [Tavares  2016].  A  adesão  a  essa  metodologia 
demonstra  que  ela  teve  boa  fundamentação  teórica  e  prática,  munindo  seus  adeptos  de 
passos  concretos,  críveis  e  exequíveis  para  a  construção  de  sistemas  em  torno  de 
projetos dinâmicos e equipes enxutas [Copeland 2001]. 

Ainda  que  a  partir  da  segunda  década  deste  século  a  XP  perca  tração  diante  de 
novas  outras  metodologias  ágeis,  como  DevOps,  OKR  e  o  trabalho  especializado 
aplicado  pelo  Agile  Coach  [Castro  2015,  Silva  2019],  a  XP  foi  importantíssima  ao 
difundir  boas  práticas  que  foram  importadas,  adaptadas  ou  mesmo  adotadas  por  novas 
metodologias.  Como  demonstram  os  estudos  de  caso  citados  neste  trabalho,  a  XP 
deixou  claro  a  importância  de  uma  boa  metodologia  para  toda  uma  geração,  que 
entendeu a criticidade de sua abordagem e o quão caótico pode se tornar um projeto sem 
um guia metodológico eficiente como referência. 
  A  XP  perdendo  espaço  hoje  em  dia  não  quer  dizer  que  ela  nunca  mais  será 
usada:  sua  aplicação  está  diluída  nessas  novas  metodologias  e  certamente  continuará  a 
ser  utilizada  em  outras  novidades  que  estão  por  vir  —  seu  legado  prosseguirá  nas 
impactantes  influências  que  suas  reconhecidas  qualidades  deixaram  no  mercado  de 
tecnologia e na engenharia de software. 
 

Referências 
Astels, D., Miller, G. e Novak, M. (2002) "Extreme Programming – Guia prático", 
Campos, 1 ed. 

Barbosa, W. H. M. (2005) “A metodologia Extreme Programming: um estudo de caso”, 

Monografia da Graduação em Ciência da Computação (Centro Universitário 
Eurípides de Marília - Fundação de Ensino Eurípides Soares da Rocha), Marília. 

Beck, K. et. al. (2001) "Manifesto para Desenvolvimento Ágil de Software", 

https://agilemanifesto.org/iso/ptbr/manifesto.html, Maio. 

Beck, K. (2004) "Programação Extrema Explicada", Bookman, 1 ed. 

Beck, K. e Fawler, M. (2001) "Planning Extreme Programming", Addison-Wesley 

Professional, 1 ed. 

Beck, K. e Fowler, M. (2001) "Interview with Kent Beck and Martin Fowler", 
http://www.informit.com/articles/article.aspx?p=20972, Maio. 
 

Bona, C. e Thiry, M. (2003) “Processo de software: um estudo de caso em XP”, 

https://pdfs.semanticscholar.org/d2ff/3309063515802bc735003576199877914452.pd
f, Maio 

Borborema, T. (2007) "Impacto da aplicação da metodologia XP nas organizações de 

desenvolvimento de software", Monografia do Curso de Sistemas de Informação, 
Faculdade de Filosofia Ciência e Letras Eugênio Pacelli, Pouso Alegre. 

Castro, F. (2015) “Metas Ágeis com OKR”, 

https://www.infoq.com/br/articles/agile-goals-okr/, Maio. 

Castro, V. A. (2007) "Desenvolvimento Ágil com Programação Extrema". Monografia 

do Curso de Ciência da Computação, Universidade Federal de Sergipe, São 
Cristóvão, Sergipe. 

Copeland, L. (2001) "How-to: Extreme Programming", 

https://www.computerworld.com/article/2585634/extreme-programming.html, Maio. 

Dos Santos, R. (2013) “Estudo de caso sobre a utilização do Extreme Programming em 
uma pequena empresa de desenvolvimento para Web”, Trabalho de Conclusão de 
Curso (Universidade do Sul de Santa Catarina), Florianópolis. 

Ebersbach, A., Glaser, M., Heigl, R. and Warta, A. (2008) "Wiki: Web collaboration", 
Berlin Heidelberg: Springer-Verlag, 2 ed. 

Fowler, M. (2004) "C3", https://www.martinfowler.com/bliki/C3.html, Maio. 

Garcia, L. F. "Qualidade de Software – Aula 5", 

https://slideplayer.com.br/slide/11377092/, Maio. 

Garzaniti, R. (1999) "Optimizing a Payroll System", In: Refactoring: Improving the 

Design of Existing Code, Edited by Martin Fowler, Addison-Wesley Professional, 1 
ed., p. 72-73. 

Hendrickson, C. (2001) "Will Extreme Programming kill your customer?", 

http://www.coldewey.com/publikationen/conferences/oopsla2001/agileWorkshop/he
ndrickson.html, Maio. 

Highsmith, J. (2002) "Agile Software Development Ecosystems", Addison-Wesley 

Professional, 1 ed. 

Jeffries, R. (2011) "What is Extreme Programming?", 

https://ronjeffries.com/xprog/what-is-extreme-programming/, Maio. 

Keefer, G. (2002) "Extreme Programming Considered Harmful for Reliable Software 

Development", 
https://www.stickyminds.com/sites/default/files/article/file/2012/XDD3248filelistfile
name1_0.pdf, Maio. 
 

Kniberg, H. (2008) "Scrum e XP direto das Trincheiras", 

https://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches, Maio. 

Leite, J. C. S. P. (2001) "Qualidade de Software: Teoria e Prática", Prentice-Hall, 

Capítulo 17. 

Loddi, S. A., Pereira, S., Casadei, C., & de Souza, M. (2010) "Metodologias Ágeis: Um 
Exemplo de Aplicação da Extreme Programming (XP", FaSCi-Tech, p. 163-177. 

Medeiros, H. (2013) "Práticas em XP - Extreme Programming", 

https://www.devmedia.com.br/praticas-em-xp-extreme-programming/29330, Maio. 

Medeiros, M. P. (2006) "Extreme Programming – Conceitos e Práticas", 

https://www.devmedia.com.br/extreme-programming-conceitos-e-praticas/1498, 
Maio. 

Medeiros, M. P. (2007) "Planejando seu projeto com eXtreme Programming – 

Parte I", 
https://www.devmedia.com.br/planejando-seu-projeto-com-extreme-programming-p
arte-i/4273, Maio. 

Neto, C. L. M. (2008) "As implicações da técnica de refatoração em desenvolvimento e 

manutenção de Software", Monografia de Bacharel Sistemas de Informação, 
Faculdade Zacarias de Góes, Valença. 

Pfleeger, Shari L. (2004) "Engenharia de Software: Teoria e Prática", Prentice-Hall, 

Pearson, 2 ed. 

Pressman, R. S. (2011) "Engenharia de Software", McGraw-Hill-Bookman, 7 ed. 

Prikladnicki, R., Will, R., Milani, F. (2014) "Métodos Ágeis Para o Desenvolvimento de 
Software", Bookman, 1 ed. 

Reis, D. F. (2008) "Conceitos básicos sobre Metodologias Ágeis para Desenvolvimento 

de Software (Metodologias Clássicas x Extreme Programming)", 
https://www.devmedia.com.br/conceitos-basicos-sobre-metodologias-ageis-para-dese
nvolvimento-de-software-metodologias-classicas-x-extreme-programming/10596, 
Maio. 

Rodrigues, A. N., Moura, M., Rodrigues, P., Santos, V. "Qualidade de Software – parte 
1 e 2", https://www.devmedia.com.br/qualidade-de-software/9408, Maio. 

Rosenberg, D. and Stephens, M. (2003) "Extreme Programming Refactored: The Case 

Against XP", Apress, 1 ed. 

Santana, R. (2014) “Ciclo de vida de um projeto em Extreme Programming - XP", 

https://rafaellsantana.wordpress.com/2014/10/01/ciclo-de-vida-do-extreme-programi
ng/, Maio. 
 

Silva, L. (2019) “7 lições aprendidas de um Agile Coach!”, 

https://www.infoq.com/br/presentations/7-licoes-aprendidas-de-um-agile-coach/, 
Maio. 

Slack, N., Johnston, R., Chambers, S. (2009) “Administração da Produção”, Editora 

Atlas, 3 ed. 

Soares, M. dos S. (2004) "Comparação entre Metodologias Ágeis e Tradicionais para o 

Desenvolvimento de Software", Unipac – Universidade Presidente Antônio Carlos, 
Faculdade de Tec. e Ciências de Conselheiro Lafaiete, Conselheiro Lafaiete. 

Sommerville, I. (2011) "Engenharia de Software", Pearson Prentice Hall, 9 ed. 

Souza, L. M. (2007) "Método Ágil XP (Extreme Programming)", 

http://intranet.fainam.edu.br/acesso_site/fia/academos/revista3/6.pdf, Maio. 

Tavares, L. (2016) "Metodologias: Parte 2 – XP (Extreme Programming)", 

http://redspark.io/metodologias-parte-2-xp-extreme-programming/, Maio. 

Teles, V. M. (2005) "Um estudo de caso da adoção das práticas e valores do Extreme 
Programming", Dissertação de Mestrado em Informática (IM-NCE/UFRJ), Rio de 
Janeiro. 

Teles, V. M. (2006) "Extreme Programming – Aprenda como encantar seus usuários 

desenvolvendo software com agilidade e alta qualidade", Novatec Editora, 1 ed. 

Wake, W. C. (2001) "Extreme Programming Explored", Addison-Wesley Professional, 

1 ed. 

Wells, D. (2013) “Extreme Programming: A gentle introduction”, 

http://www.extremeprogramming.org, Maio.