Você está na página 1de 19

XP (Extreme Programming)

Desenvolvimento ágil

Fundamentos

Aplicações

Valores
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? O que
acabaremos gerando serão: cronograma e custos imprevisíveis. Com a
busca dessa idéia, o numero 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 objetivo é rapidez na entrega, aliada a
qualidade do processo e do produto. Hoje há vários métodos de
desenvolvimento ágil, entre eles está o XP (Extreme Programming) que
será estudado nesse trabalho. Os valores defendidos pela XP como o
próprio nome diz deriva-se da idéia de se utilizar boas práticas em extremo,
e não apenas comprar algumas idéias e mudanças e aplicar, este pode ser
um fator determinante para definir o seu sucesso ou o seu fracasso.
Apesar de o XP 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 serão apresentadas a seguir.
Desenvolvimento Ágil

As metodologias tradicionais (modelos em cascata, iterativo e prototipação)


faziam parte de um desenvolvimento de software muito diferente do atual. As
modificações necessárias tinham um custo alto, devido às limitações dos
computadores e falta de ferramentas modernas para apoiar a criação do
software. Por isso, primeiro o software era planejado e documentado para
então ser implementado. O modelo clássico caracterizado como metodologia
tradicional é utilizado até hoje. Seguem alguns motivos para o pequeno
rendimento e sucesso desses modelos:

● Tempo elevado entre cada fase do projeto, não acompanhando as


mudanças de requisitos do projeto;
● Falta de conhecimento por parte do cliente da sua real necessidade;
● Forte linearidade no desenvolvimento do projeto.
Nos últimos anos, começaram a aplicar novas metodologias, visando sempre à
rapidez no fornecimento do software junto com a qualidade do processo e do
produto.

Surgem, então, os métodos ágeis, popularizados quando Kent Beck criou o


Manifesto Ágil, indicando alguns princípios compartilhados por tais métodos:
● Foco em indivíduos e interações: melhores do que processos e
ferramentas evitando especulações dos desenvolvedores;
● Software funcionando: é mais importante do que documentação
detalhada;
● Colaboração do cliente: ao invés de negociação de contratos;
● Adaptação a mudanças: é mais viável do que seguir um plano inicial
(Ausência de linearidade no desenvolvimento do projeto).

O objetivo do Manifesto Ágil não é desconsiderar processos, ferramentas,


documentação, negociação de contratos ou planejamento, mas mostrar o valor
secundário que estes possuem diante dos indivíduos e interações, do bom
funcionamento do software, da colaboração do cliente e das respostas velozes
às modificações. Esses conceitos estão mais relacionados à forma que as
pequenas e médias organizações trabalham, devido a estarem habituadas a
mudanças. A mais conhecida dentre as metodologias ágeis é o XP.

3 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, aplicando 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.
Conforme Astels, 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.

● Ter feedback antecipado, concreto e contínuo 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 às mutáveis 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 os 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.

4 Fundamentos da XP

Há diversos fundamentos que a XP leva ao extremo e que em sua maioria não


são valorizadas ou mesmo mencionadas pelas demais metodologias de
desenvolvimento. Dentre elas podemos citar:
● Se revisar o código é bom, revisaremos código o tempo inteiro
(Programação em pares);
● Se testar é bom, testes serão escritos antes de programar e todos vão
testar o tempo inteiro (teste de unidade), até mesmo os clientes (testes
funcionais);
● Se o projeto é bom, ele fará parte das funções diárias de todos
(refatoração);
● Se simplicidade é bom, sempre deixaremos o sistema com o projeto
mais simples que suporte a funcionalidade atual (a coisa mais simples
que possa funcionar), evoluindo constantemente a fim de adicionar a
flexibilidade necessária e eliminar a complexidade desnecessária;
● Se arquitetura é importante, todos trabalharão para definir e redefinir a
arquitetura o tempo inteiro;
● Se testes de integração são importantes, então vamos integrar e testar
várias vezes ao dia;
● Se iterações curtas são boas, faremos iterações muito, muito pequenas
– segundos, minutos e horas, não semanas, meses e anos;
● Colocar um sistema mínimo em produção rapidamente e desenvolvê-lo
na direção que se mostra mais favorável;
● 40 horas semanais de trabalho. Na XP, horas extras não são bem-
vindas, na sexta feira os integrantes devem terminar o seu turno e terem
2 dias para não pensarem em trabalho, para chegarem na segunda-feira
cheio de energias e idéias
● O cliente deve estar sempre disponível para responder questões e
redefinir prioridades de menor escala;
● Distinguir entre decisões que devem ser tomadas por interesses dos
negócios e aquelas que devem ser tomadas pelos envolvidos no projeto;
● Padrões de codificação. Por vezes as duplas serão trocadas e talvez
partes do sistema serão feitos por outras duplas, portanto é necessário a
adoção de padrões de codificação com uma restrição, o mais simples
possível e que seja aprovada por todo o grupo.

5 Aplicação da XP

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

● Os requisitos mudem com freqüê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 assusta ou irrita algumas pessoas que tem o primeiro contato. Mas
nenhumas das idéias 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 apóiem umas às outras em Extremo.
6 Valores do XP

Para guiar o desenvolvimento, o XP baseia-se em cinco valores:

6.1 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 para a equipe, 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 com
esse 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.

6.2 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 é 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 a
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.

6.3 Feedback: Chamamos de feedback constante o contato 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 quanto do
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.

6.4 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 freqüência, pois esta abordagem
implicará na possibilidade de mudanças constantes do produto.

6.5 Respeito: É um valor que dá sustentação a todos os demais. É


preciso que os membros 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.

7 Equipe XP

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

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

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

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

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

7.6 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 coletar informações de que precisa sem perturbar o processo.

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

8 Princípios ou Práticas do 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:

8.1 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
modificações e esclarecendo duvidas da equipe, onde a sua ausência
representa sérios riscos ao projeto.
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.

8.2 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 releases e as iterações.

8.3 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 variáveis
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 refere-se 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órias
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 quantidade de pontos estimadas pelo


desenvolvedor, o XP recomenda que as estimativas sejam efetuadas em
equipe e se possível 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 realises .

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 .

Uma iteração 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 à
equipe

8.4 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 atendem a necessidade de forma correta. Os
testes de aceitação são descritos pelo cliente e implementados pelos
desenvolvedores, facilitando ainda mais a interação entre as partes.

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

8.6 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. É uma 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


idéias entre os desenvolvedores. A solução para um problema geralmente é a
soma das idéias 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 nível dos
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.

8.7 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 início 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.

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

8.9 Integração Contínua

Visa integrar e construir o sistema muitas vezes ao dia, todas as vezes que
uma tarefa tiver sido finalizada.

8.10 Refactoring
É um processo que permite a melhoria contínua da programação. Os
programadores reestruturam o sistema sem mudar seu comportamento, para
remover duplicação, melhorar a comunicação, simplificar ou adicionar
flexibilidade.

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

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

8.13 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é (daí 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 primeiro, fazendo com que todos
relembrem e reavaliem frequentemente o que é mais importante de se fazer a
cada dia.

9 Vantagens e Desvantagens

9.1 Vantagens

As práticas do 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 cada fase 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 do que cada uma
poderia fornecer individualmente.
● 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. Com feedback constante, é possível
adaptar rapidamente eventuais mudanças nos requisitos.
● Estas alterações nos requisitos são muitas vezes críticas nas
metodologias tradicionais, que não apresentam meios de se adaptar
rapidamente às mudanças.
● Outro ponto positivo das metodologias ágeis são as entregas constantes
de partes operacionais do software. Desta forma, o cliente não precisa
esperar muito para ver o software funcionando, como nas metodologias
tradicionais.

9.2 Desvantagens
É freqüente acontecer bugs em todos os projetos de desenvolvimento de
software, e no XP não é diferente. Existem pontos fracos no uso dessa
metodologia, como:
● Não existe uma avaliação de riscos, devendo, portanto implementar uma
análise e estratégias que buscam diminuir os erros.
● 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 bom
funcionamento do sistema.
● Refatoração do código pode ser vista como irresponsabilidade e
incompetência, pois, não existe uma preocupação formal na utilização
do código.
● 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.).
● Sendo, portanto, importante a elaboração de documentos e diagramas
que facilitem no entendimento e identificação do problema.
● Além dessas desvantagens, existem algumas situações em que não é
indicado o uso do XP conforme apresentado a seguir:
● 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 o seu
“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.
10 Conclusão

O XP é uma metodologia que estimula a interação contínua entre cliente e


desenvolvedor 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
contínuas e sofisticação do software evitando redundâncias e erros
incontroláveis no seu desenvolvimento, estando lado a lado com o cliente
buscando parceria.
11 Referências

● Extreme Programming, XP: Metodologia Desenvolvimento Ágil.


[S.1], 2008. Disponível em: <http://www.improveit.com.br/xp>. Acesso
em: 06/03/2009.

● GOLDMAN, Alfredo; KON, Fabio. Programação Extrema – Ime. [S.1],


2002. Disponível em:<http://www.ime.usp.br/~kon/presentations/XP-
interlegis.ppt>. Acesso em: 06/03/2009.

● JEFFREIS ,Ron. What is Extreme Programming. [S.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
Extreme Programming. [S.1], 2007. Disponível em:
<http://www.ivaldirjunior.com/disciplinas/poo/seminarios/ Equipe
%2010%20-%20Extrem%20Program%20-%20%20XP.pdf>. Acesso em:
16/02/2009.