1.

Introdução

Não adianta ter bons profissionais, com um bom planejamento e riscos calculados, se
não existir comunicação entre eles. De que adianta? Com a busca dessa ideia, o número
de softwares finalizados no prazo e dentro do orçamento previsto, teve aumento
considerável devido ao uso de métodos de desenvolvimento ágil, cujo objectivo é
rapidez na entrega, aliada a qualidade do processo e do produto, acabaremos por gerar
um cronograma e custos imprevisíveis.

Os XP (Extreme Programming) como o próprio nome diz é uma metodologia que

faz o acompanhamento constante e a realização de diversos testes e pequenos ajustes em
projectos que precisam de agilidade ou estão em constante mudança, não é só apenas
comprar algumas ideias e muda-las e aplica-las, este pode ser um fator determinante
para definir o seu sucesso ou o seu fracasso.

XP deriva da ideia de se utilizar boas práticas em extremo, bem como ser um método de
desenvolvimento ágil que auxilia na produção do software e ter inúmeras vantagens, ele
também tem algumas desvantagens, que iremos apresentar neste trabalho.

1.2 IDENTIFICAÇÃO DE PROBLEMAS

Durante anos a produção de softwere foi feita com base em modelos antigos que
aparentemente funcionavam, pois no incio da decada de 80 foram desenvolvida algumas
metodologias de desenvolvimento de softwere, mas não vingaram devido a falta de
amadurecimento dos seus processos de desenvolvimento tais como desorganização do
ambiente produtivo, má qualidade dos processos de produção.

1.3 JUSTIFICATIVA

Escolhemos debruçar sobre este tema porque o modelo XP visa resolver enumeros
problemas comuns encontrados no desenvolvimento de softwere, ajudando assim a
garantir que o softwere produzido tenha qualidade, seja robusto, confiavel e facil de
manter.
 1.4 Objectivos
A seguir serão apresentados os objectivos gerais e especificos do trabalho.

1.4.1 Objectivos Gerais

Mostrar o valor secundário que está metodoligia possue diante dos proficionais bem
como as interações do bom funcionamento do software, da colaboração com o cliente e
das respostas atenpadas às modificações efetuadas.

1.4.2 Objectivos Especificos

Garantir alta qualidade das suas entregas, executadas em menos tempo, em processos
mais curtos e com foco na satisfação dos seus clientes.
Relacionar as metodologias implementadas no desenvolvimento do softwere devido a
forma que as pequenas e médias organizações trabalham, e a forma que elas estão
habituadas a mudanças.

1.5 HIPOTESE
1.5.1 Hipotese
Promove um senso de propriedade colectiva e melhoria da qualidade de softwere,
permitindo que todos membros da equipe têm acesso e responsabilidade sobre código
fonte.
1.5.2 Hipotese
O cliente presente é envolvido no processo de desenvolvimento incluindo a definição de
requisitos e a priorização do trabalho, levará um softwere que melhor atendas suas
necessidades e espectativas.
 CAPÍTULO I-FUNDAMENTAÇÃO TÉCNICO/CIENTIFICA

2. XP (Extreme Programming)

XP é uma metodologia para desenvolvimento de software ágil, com qualidade que

atenda as necessidades do cliente, ou a prática e perseguição da mais clara simplicidade,
aplicado no desenvolvimento de software.
Foi criado no final da década de 90. uma metodologia ágil voltada a equipes pequenas e
médias que produzem software baseados em requisitos vagos e que mudam com
rapidez. As principais diferenças entre o XP e outras metodologias são feedbacks
constantes e uma abordagem incremental. Para isso é necessária uma comunicação entre
os indivíduos, ou seja, cliente e equipa de programadores.
Conforme Astelas, a necessidade de entregar o software mais rápido fez com que Kent
Beck,Wrad Cunningham e Ron Jeffries explorassem os extremos de determinadas
práticas de desenvolvimento. O primeiro projeto a usar a metodologia XP, foi o C3
(Chrysler Comprehensive Compensation) da Chrysler, por um lado restrito e por outro
lado levado aos limites. Essa prática foi chamada de "acertar os ponteiros em dez". O
resultado foi uma inovação no desenvolvimento de software, chamada XP.
A XP é considerada uma disciplina de desenvolvimento de software, porque há certas
coisas que você precisa fazer para estar desenvolvendo a XP, se você optar por não fazer
testes você não estará sendo Extremo.

Com isso deve-se cumprir com os seguintes requisitos:

 Ter feedback antecipado, concreto e continuo pelos ciclos curtos.

 Por sua abordagem incremental de planejamento, que gera rapidamente um plano
geral que vai evoluir com o decorrer do projeto.
 Habilidade de agendar de forma flexível a implementação das funcionalidades,
respondendo as necessidades do negócio.
 Confiança nos testes automatizados escritos por programadores e clientes, para
monitorar o progresso do desenvolvimento, para permitir que o sistema evolua e para
detectar cedo alguns erros.
 Comunicação oral, testes e código fonte para comunicar a estrutura e o objetivo do
sistema.
 Confiança na intensa colaboração de programadores com habilidades comuns.
 Confiança nas práticas que combinam tanto com os instintos de curto prazo dos
programadores quanto os interesses de longo prazo do projeto.
 2.1 Aplicação da XP

A XP foi desenvolvida para ser aplicada em projetos em que:

• Os requisitos mudem com frequência;
• Utilizem desenvolvimento orientado a objetos;
• Trabalhem com times de dois a 10 programadores;
Não sejam severamente restringidos pelo ambiente computacional;
• Boa parte da execução de testes possa ser feita em pouco tempo no dia;
• E possua desenvolvimento incremental.
A XP muitas vezes assusta ou irrita algumas pessoas que tem o primeiro contacto com
ele, mas nenhumas das ideias defendidas pela XP são novas. A maioria delas é tão velha
quanto à própria programação, todas as técnicas da XP foram testadas há décadas. As
grandes mudanças que a XP traz são:

Colocar todas as práticas juntas;

• Garantir que elas sejam praticadas a fundo;
• Garantir que as práticas apoiem umas às outras em Extremo.

2.2 Valores da XP
Para guiar o desenvolvimento, o XP baseia-se em cinco valores:
Comunicação: tem como objetivo criar e manter o melhor relacionamento possível
entre a equipe desenvolvedora e o cliente, recomendando o contato direto (face-a-face),
para evitar qualquer tipo de ou mal-entendido entre os desenvolvedores e para que
possíveis dúvidas possam ser resolvidas de imediato. Além de sanar as dúvidas no
desenvolvimento, o cliente deverá estar disponível a equipa, ou mesmo presente no
ambiente de trabalho ou mesmo presente no ambiente de trabalho da empresa. Isto fará
com que o cliente entenda o sistema e enriquecerá os relacionamentos pessoais, criando
um elo de parceria e confiança mútua. Algumas equipes não se adaptam bem com isso.
Enquanto estiverem comesse problema a metodologia estará comprometida, portanto, a
equipe deve entrar em um acordo. É encorajada também a comunicação entre
desenvolvedores e gerente do projeto. Este se caracteriza como um dos fatores
principais no XP: conversar ao máximo pessoalmente, evitando o uso do telefone e
mensagens de e-mail.

Simplicidade:
Visa minimizar o código, descartando as funções consideradas desnecessárias ou não
essenciais. Ou seja, deve ser implementado o menor número de classes e métodos.
Deve-se também estar sempre procurando atender os requisitos emergenciais, evitando
adicionar funcionalidades ligadas à evolução do produto.
O importante é ter em mente que os requisitos são passíveis de mudanças. Sendo assim,
o interessante na prática do XP é implementar apenas o que implementado nas o que é
realmente necessário para que o cliente tenha seu pedido atendido.
Evita-se suposições, o futuro é incerto e por causa disso não necessita atenção. Os
requisitos evoluem gradativamente em conjunto com o sistema e arquitetura do projeto.
Algumas vezes, o que é necessário hoje será descartado amanhã, e outras vezes o que
seria necessário num futuro próximo nunca será utilizado. o menor número de classes e
métodos.
Deve-se também estar sempre procurando atender os requisitos emergenciais, evitando
adicionar funcionalidades ligadas à evolução do produto. O importante é ter em mente
que os requisitos são passíveis de mudanças. Sendo assim, o interessante na prática do
XP é implementar apenas o que é realmente necessário para que o cliente tenha seu
pedido atendido.
necessário num futuro próximo nunca será utilizado. descartado amanhã, e outras vezes
o que seria

Feedback: Chamamos de feedback constante o contacto incessante com o cliente a

respeito do projeto. Informações sobre o código são dadas por testes periódicos, os
quais indicam erros um tanto individuais bem como software integrado. Além disso, o
cliente terá sempre uma parte do software funcional para avaliar. Com isso, novas
características e informações são repassadas aos desenvolvedores, que por sua vez
devem implementá-las nas próximas versões. Desta maneira, o que se pretende é
entregar o software de acordo com as expectativas do cliente.

Coragem: se encaixa na implantação dos três valores anteriores. importante que os

profissionais sejam comunicativos e com facilidade de se relacionar. A coragem auxilia
a simplicidade, quando a possibilidade de simplificar o software é detectada. Por fim, a
coragem é necessária para garantir que o feedback do cliente ocorra com frequência,
pois esta abordagem implicará na possibilidade de mudanças constantes do produto.

Respeito: é um valor que dá sustentação a todos os demais. É preciso que o membro de

uma equipe se importem uns com os outros. Só assim, irão se preocupar em comunicar-
se melhor. Respeito é o mais básico de todos os valores. Se ele não existir em um
projeto, não há nada que possa salvá-lo. Saber ouvir, saber compreender e respeitar o
ponto de vista do outro é essencial para que um projeto de software seja bem-sucedido.
 2.3 Constituiçáo da quipa XP

Gerente de projeto
Pessoa responsável pelos assuntos administrativos do projeto, mantendo um forte
relacionamento com o cliente para que o mesmo participe das atividades do
desenvolvimento.
Os Maiores atributos do gerente são: coragem, confiança e insistência ocasional para
que façam o que dizem o que fazer.

Isto significa comunicação franca. O time quer colocar esta habilidade em prática
quando precisarem dela. E querem mantê-la distante quando não precisarem.

Coach

Pessoa responsável pelas questões técnicas do projeto, é necessário um grande

conhecimento nos processos de desenvolvimento, nos valores e práticas do XP. Sua
responsabilidade é verificar o comportamento da equipe, sinalizando os eventuais erros.

Analista de teste

Pessoa responsável em garantir a qualidade do sistema através dos testes

escritos. Ele deve ajudar o cliente a escrever os casos de testes e no final de cada
iteração verificar se o software atende todos os casos de testes.
Recomenda-se que esta pessoa não seja um desenvolvedor, para evitar uma visão
tendenciosa já que não conhece o código desenvolvido. O analista de teste deve ter uma
visão muito parecida com a do cliente e em muitos projetos esta pessoa acaba exercendo
o papel de redator técnico.

Redator técnico
Pessoa responsável em documentar o sistema, permitindo uma maior dedicação ao
trabalho de codificação. Esta pessoa deve estar em plena sintonia com os
desenvolvedores e cliente para que a documentação reflita o código escrito e as regras
de negócio atendidas pelo sistema.

Desenvolvedor
Pessoa responsável em analisar, projetar e codificar o sistema. No XP não existe
diferença entre analista, projetista e programador uma vez que em vários momentos do
projeto o desenvolvedor estará exercendo alguma destas atividades.O principal membro
da XP, dentre suas habilidades devem ser destacadas a programação em pares e a
simplicidade, e acima de tudo coragem.
Existem níveis distintos de desenvolvedores dentro de uma equipe, mas com a prática
de programar em par, a tendência da equipe é se tornar uniforme em suas habilidades.
Rastreador
O rastreador faz estimativas de tempo e checa se se ajustou à realidade, isto é uma
questão de prática e feedback.
Ele é responsável pela visão global do andamento também, se durante uma iteração o
que foi previsto ser executado, ou se é preciso modificar algo. A maior habilidade aqui é
a capacidade de colectar informações de que precisa sem perturbar o processo.

Treinador

O responsável por chamar a atenção das pessoas quando estas estão se desviando do
processo do time. Todos no Time XP devem compreender a aplicação, mas o treinador
muito mais e profundamente. A necessidade deste papel diminui proporcionalmente
com o amadurecimento do time.

2.4 Princípios ou Práticas da XP

Para entender as formas que movem o projeto XP, é importante entender seus princípios
e suas práticas. Alguns desses princípios são apenas bom senso, outros se tornam a base
da maioria dos processos futuros de desenvolvimento de software conforme apresentado
a seguir:

Cliente em conjunto com os desenvolvedores

O XP trabalha tem uma visão diferente em relação ao cliente. Este permanece o tempo
todo presente, a par do desenvolvimento do software, indicando e modificações e
esclarecendo dúvidas da equipe onde a sua ausência representa sérios riscos ao projecto.
Ao terminar uma estória, com a presença do cliente, a mesma poderá ser validada
rapidamente e a equipe receber o feedback necessário sobre a funcionalidade, criando
ciclos rápidos e precisos.
Planejamento
A XP utiliza o planejamento para assegurar que a equipe de desenvolvimento esteja
trabalhando naquilo que gere o máximo de valor para o cliente sempre determinando o
escopo da próxima versão, combinando prioridades de negócio e estimativas técnicas. O
consultor se reúne com as equipes duas vezes por semana. Nestas reuniões há uma
permanente negociação de requisitos e prazos. Este planejamento é feito várias vezes
durante o projeto. o momento onde o cliente solicita as funcionalidades desejadas
através de estórias, onde a equipe estima o custo de cada estória e planeja as relasses e
as iterações.
Uso de Metáforas

Todo o desenvolvimento é guiado por uma simples estória compartilhada de como o

sistema funciona e todas as funcionalidades do sistema são descritas.
A metáfora ajuda a equipe a entender sobre o vocabulário utilizado pelo domínio do
projeto e assim ajuda-o a nomear funções e varia apropriadamente.
São relatadas através de pequenos cartões em que o cliente deve descrever o que deseja
com suas palavras e da forma mais simples possível. Lembrando que a simplicidade
também deve ser respeitada pelo cliente.
Após a definição das estórias é necessário estimar o tempo das mesmas para que o
cliente priorize o que deve ser implementado. A XP utiliza uma unidade chamada ponto,
que se refere a um dia de trabalho ideal do desenvolvedor, onde o mesmo não precisaria
atender telefonemas, participar de reuniões, ou seja, estaria preocupado apenas com a
estória em questão.
Muitas vezes algumas estórias consomem semanas de trabalho, oferecendo uma certa
dificuldade de serem estimadas. A XP recomenda que estas estória sejam quebradas em
tarefas menores e que as mesmas não utilizem mais que alguns pontos de um
desenvolvedor, recomenda-se 4 pontos ao máximo.
Em cada estória é escrita a quantidades estimadas pelo desenvolvedor, o XP recomenda
que as estimativas sejam efetuadas em equipe e se possivel com a presença do cliente
para que durante a estimativa eventuais dúvidas sejam sanadas.
O XP tem por objetivo gerar valor para o cliente ao longo do projeto, para isto o
software é desenvolvido de forma incremental, onde a cada entrega o cliente possa
utilizar o sistema e obter benefícios do mesmo. Estas entregas o XP denomina como
sendo releases, pequenos intervalos de tempo, máximo 2 meses, onde funcionalidades
que gerem valor ao cliente sejam entregues.
A divisão dos releases é efetuada no início do projeto, geralmente com tamanhos fixos e
pequenos. Após esta divisão o cliente define as estórias que farão parte dos releases.
Mesmo os releases sendo efetuados em curto espaço de tempo, continua representando
um tempo muito longo para o feedback do cliente. Por esta razão os releases são
divididos em espaços menores, chamados de iterações.
Umas iterações contêm um conjunto de estórias a serem implementadas, com duração
entre uma a três semanas, onde ao final da mesma o cliente possa validar as
implementações efetuadas e fornecer o feedback necessário à equipa.
Teste Primeiro
Os programadores escrevem unidades de teste continuamente e os executam para que o
processo de desenvolvimento continue. Esta atividade considerada extremamente chata
e dispensada por muitos desenvolvedores na modelagem conceitual por exemplo, porém
para os desenvolvedores de uma equipe XP esta atividade deve ser encarada. Todo
código implementando deve coexistir com um teste automatizado, assim garantindo o
pleno funcionamento da nova funcionalidade.
Em cada ciclo eles apresentam uma versão de teste do software ao cliente. Os clientes
escrevem os testes para validar o sistema. com base nestes testes automatizados que
qualquer desenvolvedor terá coragem para alterar uma parte do código que não tenha
sido implementada por ele. Com a implementação de testes o desenvolvedor poderá
amadurecer o entendimento sobre o problema que irá solucionar, já que os testes são
codificados antes da nova implementação.
No XP existem dois tipos de testes, os testes de unidade e de aceitação. O teste de
unidade verifica se os resultados gerados por cada classe estão corretos, já o teste de
aceitação verifica se a interação entre as classes que implementam uma funcionalidade
atende a necessidade de forma correta. Os testes de aceitação são descritos pelo cliente e
implementados pelo desenvolvedores, facilitando ainda mais a interação entre as partes.

Simplicidade
O sistema deve ser projetado da forma mais simples possível. A complexidade extra é
removida assim que detectada. Deve-se implementar apenas a funcionalidade que foi
solicitada. Mas deve-se ter atenção para não confundir simplicidade com facilidade.
Umas das premissas do desenvolvimento conceitual é que o custo de uma alteração no
sistema cresce exponencialmente ao longo do projeto, com isto tenta-se criar soluções
genéricas preparando o sistema para futuras alterações.

No XP o custo de uma alteração tende a crescer lentamente e se estabilizar ao longo do

projeto, esta premissa é dita em função dos avanços nas linguagens e práticas de
programação. novos ambientes e ferramentas de desenvolvimento, utilização de
orientação a objetos no desenvolvimento e em conjunto com estes novos avanços existe
o fruto das outras práticas XP, deixando o código simples, legível e passível de alteração
a qualquer momento.

Programação Pareada
O XP exige que todo e qualquer código implementado no projeto seja efetuado em
dupla, chamada de programação em par. É urna técnica onde dois desenvolvedores
trabalham no mesmo problema. Um deles é responsável pela digitação (condutor -
menos experiente) e outro acompanhando o trabalho do parceiro (navegador - mais
experiente).
Esta prática agrega diversas técnicas de programação, enquanto o condutor codifica o
problema o navegador permanentemente revisa o código digitado, onde pequenos erros
de programação que demoraria algumas horas para serem depurados, facilmente são
percebidos pelo navegador da dupla.
Um dos grandes benefícios da programação em par é a troca de experiências e ideias
entre os desenvolvedores. A solução para um problema geralmente é a soma das ideias
da dupla, tornando uma solução e codificação muito mais rápida e fácil. com esta
prática que o XP uniformiza o mv desenvolvedores da equipe, através da troca de
experiências. Após alguns meses trabalhando em duplas todos os desenvolvedores
conhecerão todas rotinas do sistema, prontos para qualquer modificação ou para auxiliar
algum iniciante.
Padronização do Código
Um dos valores do XP é a comunicação, e o código também é uma forma da equipe se
comunicar. Uma forma clara de se comunicar através do código, é manter um padrão no
projeto para que qualquer um possa rapidamente entender o código lido.

O XP recomenda a adoção de um padrão desde o inicio do projeto (preferencialmente

padrões utilizados pela comunidade da linguagem de desenvolvimento. Havendo a
necessidade de modificações e adaptações durante o projeto, que visam agilizar o
desenvolvimento, as mesmas devem ser efetuadas.
A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem
seguir estas regras. O código fonte final deve parecer ter sido feito por apenas um
programador.

Propriedade Coletiva

O XP prega que todo desenvolvedor ao encontrar um código duplicado, pouco legível,

mal codificado, sem padronização, lento, com código legado ou uso incorreto de outras
implementações, mas que esteja funcionando, tem por obrigação alterar este código
deixando-o mais legível e simples, porém esta alteração não pode mudar o
comportamento do código em questão. Ou seja, o código fonte não tem dono e ninguém
precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a
equipe conhecer todas as partes do sistema.
Integração Continua
Visa integrar e construir o sistema muitas vezes ao dia, todas as vezes que uma tarefa
tiver sido finalizada.

Refactoring um processo que permite a melhoria continua da programação.

Programadores reestruturam o sistema sem mudar seu comportamento, para remover
duplicação, melhorar a comunicação, simplificar ou adicionar flexibilidade.

Fases Pequenas

Visa produzir um sistema simples rapidamente, planejando novas versões em um ciclo

muito pequeno. A liberação de pequenas versões funcionais do projeto auxilia muito no
processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que
está comprando.
Semanas Curtas (Semana de 40 horas)

Impõe que a equipe não trabalhe mais que 40 horas por semana / 8 horas por dia. Mas se
necessário que não faça hora-extra duas semanas seguidas.
Trabalhar com qualidade, buscando ter ritmo de trabalho saudável.

Stand up meeting
O stand up meeting é uma reunião rápida (em torno de 15 minutos) realizada no início
de cada dia, onde os participantes normalmente ficam em pé (dai a origem do nome),
cujo objetivo é atualizar todos os membros da equipe a
respeito do que ocorreu no dia anterior e priorizar as atividades do dia que se inicia. Ela
é uma forma simples de assegurar que as pessoas obtenham feedback rápido sobre
qualquer aspecto do projeto, bem como um mecanismo para planejar o que precisa ser
feito primeiros fazendo com que todos relembrem e reavaliem frequentemente o que é
mais importante de se fazer a cada dia.

2.5 Vantagens e Desvantagens da XP

2.5.1 Vantagens
As práticas da XP são usadas pelos integrantes da equipe, para facilitar no
desenvolvimento e agregar qualidade no projeto, com isso todos do time devem estar
cientes de todas as fases do sistema. Um dos benefícios que a mesma oferece é tornar o
processo mais ágil e flexível. Conforme Astels, as práticas do XP são criadas para
funcionarem juntas e fornecer mais valor como:
 Análise prévia de tudo que pode acontecer durante o desenvolvimento do projeto,
oferecendo qualidade, confiança, data de entregas e custos promissores.
 O XP é ideal para ser usada em projetos em que o cliente não sabe exatamente o que
deseja e pode mudar muito de opinião durante o desenvolvimento do projeto.
 Feedback constante, é possível adaptar rapidamente eventuais mudanças nos
requisitos.
 Estas alterações nos requisitos são muitas vezes criticas nas metodologias
tradicionais, que não apresentam meios de se adaptar rapidamente às mudanças.
 Outro ponto positivo do XP são as entregas constantes de partes operacionais do
software. Desta forma, o cliente não precisa esperar muito para ver o software funcionar
como nas metodologias tradicionais.
2.5.2 Desvantagens

É frequente acontecer bugs em todos os projetos de desenvolvimento de software, e no

XP não é diferente. Existem pontos fracos no uso dessa metodologia, como:
 A análise de requisitos é informal e com isso pode não ser bem-vista pelos clientes,
que poderão se sentir inseguros quanto ao funcionamento do sistema.
 A maior barreira para o sucesso de um projeto XP é a cultura empresarial.
Qualquer negócio que gerencie projetos tentando apontar o carro para a direção
certa logo de cara terá conflitos com o time que insiste em ir acertando a direção
continuamente.

 Outra cultura que não contribui para o XP é aquela na qual você é requisitado a
trabalhar horas e mais horas para provar "comprometimento com a empresa".
Você não consegue executar o XP se estiver cansado. Se aquilo que o seu time
produz trabalhando em velocidade máxima não é suficiente para a sua empresa
então o XP não é a solução.
 A falta de documentação é característica do processo XP, pois, o mesmo não dá
muita ênfase em burocracias (documentos, formulários, processos, controles
rígidos, etc.).

 A maior barreira para o sucesso de um projeto XP é a cultura empresarial. Qualquer

negócio que gerencie projetos tentando apontar o carro para a direção certamente terá
conflitos com o time que insiste em ir acertando a direção continuamente.

 Outra cultura que não contribui para o XP é aquela na qual você é requisitado a
trabalhar horas e mais horas para provar "comprometimento com a empresa". Você não
consegue executar o XP se estiver cansado. Se aquilo que o seu time produz trabalhando
em velocidade máxima não é suficiente para a sua empresa então o XP não é a solução.
 E existe também uma barreira tecnológica para o XP é um ambiente no qual é
necessário um longo tempo para se obter feedback. Por exemplo, se o seu
sistema leva 24 horas para compilar e linkar, será difícil integrar, compilar e
testar várias vezes ao dia.
 Conclusão

O XP é uma metodologia que estimula a interação continua entre cliente e a equipa de

desenvolvedores para que as necessidades do cliente sejam visualizadas e
compreendidas, obtendo assim, o sucesso do projeto. Ela é baseada em valores e
princípios exclusivos que devem ser cultivados para que o projeto obtenha o sucesso
desejado.
As desvantagens existem, porém é através delas que se devem buscar melhorias. É
necessário satisfazer os pontos fortes dessa metodologia e buscar o aprimoramento dos
pontos fracos, para que ela evolua e consiga espaço no mercado tecnológico de
software cada vez mais competitivo.
Podemos,assim, concluir que a inclusão do XP, bem como outras metodologias
ágeis, é fundamental para profissionais que buscam melhorias continuas, sofisticação do
software evitando redundâncias e incontroláveis no seu desenvolvimento, estando lado a
lado com o cliente buscando melhor parceria.
 Referências Bibliograficas

Extreme Programming, XP: Metodologia Desenvolvimento Ági [SA], 2008.

Disponível em: <http•]/www.improveit.com.br/xp>. Acesso em: 06/03/2009.
GOLDMAN, Alfredo; KON, Fabio. Programação Extrema — 'me. [S.l],
2002.Disponível em:<http://www.ime.usp.br/-kon/presentations/XPinterlegis.ppt>.
Acesso em: 06/03/2009. JEFFREIS ,Ron.What is Extreme Programminé3.1], 2008.
Disponível em: <http://www.xprogramming.com/xpmag/whatisxp.htm>. Acesso em:
07/03/2009. SANTOS, Dayse Islany Farias; CARVALHO, Emerson Silva de;
MACÊDO, Juliana Kataline Lopes. Vantagens e desvantagens do XP
ExtremeProgramming 2007. Disponível
<http://wvwu.ivaldirjunior.com/disciplinas/poo/seminarios/Equipe Acesso em:
16/02/2009.