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.