Impacto da aplicação da metodologia XP nas ... - Artigo Científico

THIAGO BORBOREMA
IMPACTO DA APLICAÇÃO DA METODOLOGIA XP NAS
ORGANIZAÇÕES DE DESENVOLVIMENTO DE
SOFTWARE
UNIVERSIDADE DO VALE DO SAPUCAÍ
POUSO ALEGRE
2007

THIAGO BORBOREMA
IMPACTO DA APLICAÇÃO DA METODOLOGIA XP NAS
ORGANIZAÇÕES DE DESENVOLVIMENTO DE
SOFTWARE
1
Trabalho apresentado ao
Departamento de Sistemas de
Informação da Faculdade de
Filosofia Ciências e Letras Eugênio
Pacelli da Universidade do Vale do
Sapucaí, como requisito parcial
para obtenção do título de bacharel
em Sistemas de Informação.
Orientador: Professor Márcio
Emílio Cruz Vono de Azevedo.
Co-orientador: Professor Artur Luis
Ribas Barbosa.
UNIVERSIDADE DO VALE DO SAPUCAÍ
POUSO ALEGRE
2007

THIAGO BORBOREMA
IMPACTO DA APLICAÇÃO DA METODOLOGIA XP NAS
ORGANIZAÇÕES DE DESENVOLVIMENTO DE
SOFTWARE
Monografia defendida e aprovada em 26/10/2007 pela banca examinadora
constituída pelos professores:
____________________________________
Prof. Márcio Emílio Cruz Vono de Azevedo
Orientador
_____________________________
Prof. Evandro Luís Brandão Gomes
Examinador
_____________________________
Prof. Ms. Paulo César do Nascimento
Examinador
2

3
Dedico,
à minha família, à Crishna
sinônimo de amor e carinho e
ao Thom meu pequeno grande
amigão.

AGRADECIMENTOS
Primeiramente a Crishna, que nos momentos mais difíceis ainda teve forças
para me apoiar nessa etapa de minha vida.
A minha família, onde tenho apoio e onde consigo forças para poder continuar
na empreitada que é a vida.
Aos amigos, pelo qual estimo muito. Ao orientador e amigo Márcio, ao co-
orientador Artur e a DEUS que me colocou pessoas importantes.
Muito Obrigado!
4

“A mente que se abre a uma nova idéia
jamais voltará ao seu tamanho original.”
5
(Albert Einstein)

BORBOREMA, Thiago. Impacto da aplicação da metodologia XP nas organizações
de desenvolvimento de software. Monografia – Curso de Sistemas de Informação,
Faculdade de Filosofia Ciência e Letras Eugênio Pacelli, Universidade do vale do
Sapucaí, Pouso Alegre, 2007.
RESUMO
Trata-se de um estudo, que apresenta o impacto do uso da metodologia ágil
Extreme Programming (XP) com objetivo de obtenção de sucesso em desenvolvimento
de sistemas. Baseado em estudos que demonstram falhas em projetos de software,
envolvendo orçamento, cronograma, funcionalidades, causando insatisfação do cliente.
Foram estudadas e desenvolvidas as metodologias ágeis, as quais propõem uma
diminuição na burocracia do desenvolvimento de software, sendo a extreme
programming um exemplo que proporciona softwares de maior qualidade e aceitação.
Sendo assim, apresenta-se neste os seus conceitos e aplicações, mostrando um estudo
de caso com várias empresas que aplicaram essa metodologia e demonstraram seu
impacto.
Palavras-Chaves: cliente, Extreme Programming, metodologia ágil, projetos.
6

BORBOREMA, Thiago. Impacto da aplicação da metodologia XP nas organizações
de desenvolvimento de software. Monografia – Curso de Sistemas de Informação,
Faculdade de Filosofia Ciência e Letras Eugênio Pacelli, Universidade do vale do
Sapucaí, Pouso Alegre, 2007.
ABSTRACT
This paper is intended to present the impact of using the agile methodology
Extreme Programming (XP) as a goal to obtain success on system development. The
agile methodologies was developed based on researches demonstrating failures on
software projects, involving budget, schedule and functionalities, demonstrating the
client discontentment. These methodologies have the approach of reducing paperwork
on software development. Extreme Programming is one of the approaches to increase
software quality and client satisfaction. This paper introduces the Extreme
Programming concepts and applications, presenting a case study with many companies
that adopted this methodology and showing its impact.
Keywords: client, Extreme Programming, agile methodology, impact.
7

Figura 1 Práticas da XP.
Figura 2 Motivos da adoção da XP.
LISTA DE FIGURAS
Figura 3 Utilização das práticas da XP.
Figura 4 Combinação da XP com outras metodologias.
Figura 5 Principais metodologias usadas com a XP.
Figura 6 Dificuldades na implantação da metodologia XP.
Figura 7 Práticas mais fáceis de implantar nas organizações pesquisadas.
Figura 8 Práticas mais difíceis de implantar, segundo pesquisa.
Figura 9 Tipos de documentações.
Figura 10 Sucesso do uso da XP na organização.
8

LISTA DE ABREVIATURAS E SIGLAS
ASD Adaptive Programming.
DSDM Dynamic Systems Development Method.
FDD Feature-Driven Development.
XP Extreme Programming.
XP2 Extreme Programming segunda versão.
9

SUMÁRIO
1 INTRODUÇÃO...................................................................................................... 12
2 DESENVOLVIMENTO ÁGIL.............................................................................. 14
2.1 Movimento ágil................................................................................................. 14
2.2 Metodologia ágil ............................................................................................... 15
3 EXTREME PROGRAMMING ............................................................................... 17
3.1 Valores do XP...................................................................................................... 17
3.1.1 Retorno(Feedback)......................................................................................... 18
3.1.2 Comunicação.................................................................................................. 18
3.1.3 Simplicidade .................................................................................................. 19
3.1.4 Coragem......................................................................................................... 19
3.2 Princípios do XP.................................................................................................. 20
3.2.1 Feedback rápido ............................................................................................. 20
3.2.2 Simplicidade presumida ................................................................................. 21
3.2.3 Mudanças incrementais .................................................................................. 21
3.2.4 Aceitação das mudanças................................................................................. 21
3.2.5 Alta qualidade ................................................................................................ 22
3.2.6 Ensinar aprendendo ........................................................................................ 22
3.2.7 Investimento inicial pequeno .......................................................................... 22
3.2.8 Jogar para ganhar ........................................................................................... 22
3.2.9 Experimentação concreta................................................................................ 23
3.2.10 Comunicação honesta e franca...................................................................... 23
3.2.11 Trabalhar a favor dos instintos do pessoal e não contra eles.......................... 23
3.2.12 Aceitação de responsabilidades..................................................................... 24
3.2.13 Adaptação local............................................................................................ 24
3.2.14 Viajar com pouca bagagem........................................................................... 24
3.2.15 Métricas genuínas......................................................................................... 25
3.3 Práticas do XP..................................................................................................... 25
3.3.1 A equipe (whole team).................................................................................... 26
3.3.2 Jogo do planejamento(planning game) ........................................................... 26
3.3.3 Teste de aceitação(customer tests) .................................................................. 27
3.3.4 Pequenos lançamentos(small releases) ........................................................... 27
3.3.5 Design simples(simple design)........................................................................ 27
3.3.6 Programação em par(pair programming)........................................................ 28
3.3.7 Desenvolvimento orientado a testes(test-driven development)......................... 29
3.3.8 Refinamento do design(refactoring) ............................................................... 29
3.3.9 Integração contínua(continuous integration)................................................... 29
3.3.10 Posse coletiva(collective ownership)............................................................. 30
3.3.11 Padrões de codificação(coding standards) .................................................... 30
3.3.12 Metáfora(metaphor) ..................................................................................... 31
3.3.13 Ritmo saudável(sustainable pace) ................................................................ 31
3.4 Mudanças no XP ................................................................................................. 31
3.4.1 Valores........................................................................................................... 32
3.4.2 Princípios ....................................................................................................... 32
3.4.3 Práticas........................................................................................................... 32
4 ESTUDO DE CASO............................................................................................... 33
5 CONSIDERAÇÕES FINAIS................................................................................. 41

REFERÊNCIAS BIBLIOGRÁFICAS..................................................................... 42
ANEXOS ................................................................................................................... 44
Anexo I................................................................................................................... 44
11

1 INTRODUÇÃO
Com o mercado cada vez mais competitivo, técnicas de programação surgem
para suprir as necessidades e agilizar o processo de desenvolvimento de sistemas. Por
isso as organizações estão cada vez mais preocupadas em ter qualidade em seus
processos, visando o produto final e um dos problemas que afetam o desenvolvimento
de software é a enorme quantidade de detalhes que precisam ser considerados.
Normalmente, ao especificar um sistema, o cliente tem o conhecimento de
alguns aspectos do software que deseja, mas muitos outros só ficam claros quando ele
tem a oportunidade de utilizar o sistema. Portanto, o cliente não especifica estes
detalhes no início do projeto por uma razão muito simples: ele não os conhece (BECK,
2000). Além do mais, mesmo que tais detalhes fossem conhecidos previamente, seria
muito difícil especificá-los através de documentos devido à grande quantidade de
elementos que precisariam ser descritos.
O movimento ágil conseguiu abertura para muitas novas idéias de
desenvolvimento de softwares, mas ganhou força em 2001 com a publicação do
manifesto ágil de desenvolvimento de software, que define os seguintes princípios:
Indivíduos e interações são mais importantes que processos e ferramentas.
Software funcionando é mais importante do que documentação completa e
detalhada.
Colaboração com o cliente é mais importante do que negociação de
contratos.
Adaptação a mudanças é mais importante do que seguir o plano inicial.
Esses princípios buscam tornar o desenvolvimento de software um pouco mais
simples, com qualidade e rapidez do que os modelos tradicionais, onde o qual tem tido
um aumento de adeptos da nova maneira de desenvolver sistemas.
O desenvolvimento ágil se baseia na premissa de que o cliente aprende ao
longo do desenvolvimento, à medida que é capaz de manipular o sistema. O
aprendizado decorre do feedback que o software oferece ao cliente quando este o
manipula, pois está presente ao longo de todo o desenvolvimento do software e exerce
um papel fundamental (MANHÃES, 2004).
12

A aplicabilidade dos métodos ágeis em geral pode ser examinada de múltiplas
perspectivas. Da perspectiva do produto, métodos ágeis são mais adequados quando os
requisitos estão emergindo e mudando rapidamente, embora não exista um consenso
completo neste ponto (COHEN et al, 2004).
Hoje em dia com as rápidas mudanças, seja em tecnologia, requisitos e perfil
do consumidor as empresas têm que se adaptar a essa nova realidade.
Com a metodologia ágil, que consiste em um conjunto de práticas, definiu um
novo conceito e a mais conhecida é Extreme Programming (XP), que é uma técnica de
desenvolvimento de software que vai contra uma série de premissas adotadas por
métodos mais tradicionais de desenvolvimento, XP consiste numa série de práticas e
regras que permitem aos programadores desenvolver software de uma forma dinâmica e
muito ágil considerando aspectos que se aplicam no conceito de agilidade, custo, escopo
e qualidade no desenvolvimento de sistemas (BECK, 2000). O objetivo deste projeto é
apresentar as práticas da XP e sua aplicabilidade dentro das organizações de
desenvolvimento de software, buscando novos adeptos e levando a metodologia ao
conhecimento amplo a todos.
Este trabalho busca contribuir com empresas e pesquisadores que tenham
interesse em conhecer a metodologia XP em seus princípios e práticas aplicados em
organização e algumas de suas características quanto a sua aplicação.
Este trabalho está organizado em cinco capítulos, ao qual, no capítulo dois trata
do desenvolvimento ágil, já no capítulo três aborda Extreme Programming, no capítulo
quatro trata do estudo de caso com empresas que utilizam XP como metodologia de
desenvolvimento, no capítulo cinco será analisado o estudo de caso.
13

2 DESENVOLVIMENTO ÁGIL
O manifesto de desenvolvimento ágil, no qual, questionam práticas de
engenharia de software, foi proposto por um grupo de especialistas em desenvolvimento
de software por causa de diversos fracassos, estouros de prazos e orçamento dos
métodos tradicionais de desenvolvimento de software.
O manifesto defende o que necessita ser valorizado ao se desenvolver software,
a comunicação entre os indivíduos, o código fonte funcional, a colaboração com o
cliente (AGILCOOP, 2007).
2.1 Movimento ágil
Segundo Manhães (2007), o movimento ágil foi iniciado por programadores e
consultores experientes, originando uma nova forma de desenvolvimento de software
em curto tempo com qualidade. Porém, só ganhou forças com a publicação do
manifesto ágil em fevereiro de 2001.
O movimento define alguns princípios:
Indivíduos e interações são mais importantes que processos e ferramentas.
Software funcionando é mais importante do que documentação completa e
detalhada.
Colaboração com o cliente é mais importante do que negociação de
contratos.
Adaptação a mudanças é mais importante do que seguir o plano inicial.
O desenvolvimento de software ganhou uma nova forma de criação com maior
rapidez e aceitação do cliente, ou seja, o manifesto ágil não rejeita os processos, a
documentação, a negociação de contratos ou o planejamento, mas, simplesmente mostra
que eles possuem importância secundária quando comparado com os indivíduos e
14

interações, com o software executável, com a colaboração do cliente e as respostas
rápidas a mudanças e alterações.
2.2 Metodologia ágil
Como reação às metodologias tradicionais, consideradas muito pesadas para
equipes pequenas, um novo grupo de metodologias surgiu, chamado de metodologias
ágeis, entre as quais a XP se enquadra e, propõem uma diminuição na burocracia do
desenvolvimento de software (NAPHTA, 2007).
Além da XP existem outras metodologias ágeis, entre elas:
1. Crystal Clear.
2. Scrum.
3. DSDM.
4. FDD.
5. ASD.
A XP foi criada nos Estados Unidos ao final da década de 90 e vem fazendo
sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, em menor
tempo e de forma mais econômica que o habitual.
Indicada para equipes pequenas e médias de desenvolvimento, às quais tem que
lidar com requisitos vagos ou em constante mudança surgiu com a proposta de aumentar
o foco nas pessoas e não nos processos de desenvolvimento. Além disso, existe a
preocupação de se gastar menos tempo com a documentação e mais com a resolução do
problema, gerando produtos com melhor aceitação e qualidade (IMPROVEIT, 2007).
Tais objetivos são alcançados devido a um conjunto de valores, práticas e
princípios, que diferem da forma tradicional de se desenvolver software.
Segundo Fowler (2007), as duas principais diferenças entre as metodologias
ágeis e as tradicionais:
Elas são adaptativas, ao invés de previsivas – as metodologias tradicionais
tentam planejar uma grande parte do software em muitos detalhes com
bastante antecedência. Por isto elas são resistentes à mudança. Já nas
metodologias ágeis, as mudanças de requisitos durante o desenvolvimento
15

são bem-vindas. Elas tendem a ajustar o desenvolvimento do software às
mudanças de requisitos, tornando-se mais flexíveis.
Elas são orientadas às pessoas, não aos processos – a meta das metodologias
de desenvolvimento é desenvolver um processo que vai funcionar da mesma
maneira, independente de quem o esteja utilizando. Metodologias ágeis
levam mais em conta a habilidade da equipe de desenvolvimento e, tendem
por isto, a se ajustar à equipe.
Pesquisas feitas pelo Standish Group International em 1994, apontam que
apenas 16,2% dos projetos de software atingiam sucesso, já em 2002 esta taxa havia
subido para 34%, ou seja, aumento de 100% em 8 anos. Mas estas taxas ainda se
encontram muito aquém do esperado pelo mercado.
As metodologias utilizadas nos projetos pesquisados eram as mais variadas,
entre elas o modelo em cascata, modelo interativo e alguns modelos de prototipação
(JAVAFREE, 2007).
16

3 EXTREME PROGRAMMING
XP é uma abreviação de Extreme Programming (programação extrema) que é
uma metodologia ágil com foco em qualidades de projetos e agilidade de equipes .
Segundo Beck (2000) a XP é uma maneira leve, eficiente, de baixo risco,
flexível, previsível, científica e divertida de se desenvolver software. Distingue-se de
outras metodologias por:
Feedback rápido, concreto e contínuo.
Abordagem incremental de planejamento, obtendo um plano geral do
projeto.
Confiança nos testes automatizados escritos por programadores e clientes
para monitorar o desenvolvimento, evolução e detecção de erros nos
projetos, dentre outras.
É voltada para projetos cujos requisitos são vagos e mudam com freqüência,
equipes pequenas (em geral, 12 desenvolvedores), desenvolvimento de sistemas
orientados a objeto e incremental.
XP é um processo de desenvolvimento que busca assegurar que o cliente
receba o máximo de valor de cada dia de trabalho da equipe de desenvolvimento e é
organizado em torno de um conjunto de valores e práticas que atuam de forma
harmônica e coesa para assegurar que o cliente sempre receba um alto retorno do
investimento em software (MANHÃES, 2004).
3.1 Valores da XP
XP enfatiza o desenvolvimento rápido do projeto e visa garantir a satisfação do
cliente, além de favorecer o cumprimento das estimativas, proporcionando um
agradável ambiente de desenvolvimento de software para os seus seguidores, que são
conduzidos por quatro valores: Retorno(feedback), Comunicação, Simplicidade e
Coragem (SOARES, 2007).
17

3.1.1 Retorno (Feedback)
do cliente.
O retorno constante significa que o programador terá informações do código e
A informação do código é dada pelos testes, que indicam os erros tanto
individuais quanto do software integrado (SOARES, 2007).
O cliente recebe o sistema o quanto antes, afim de dar um retorno rápido,
guiando assim o desenvolvimento do software (NAPHTA, 2007).
Pode-se, com isso, reavaliar necessidades com relação às funcionalidades
apresentadas, e também com relação às futuras.
3.1.2 Comunicação
A forma de comunicação é um fator chave na XP: procura-se o máximo
possível comunicar-se pessoalmente, evitando o uso de telefone e o envio de mensagens
por correio eletrônico (SOARES, 2007). É através dela que o cliente e o time irão tratar
dos detalhes do projeto, devendo ser feito com atenção e agilidade, buscando o melhor
relacionamento possível entre clientes e desenvolvedores e entre os desenvolvedores e o
gerente do projeto.
Segundo Beck (2000), analisando os problemas que ocorreram nos projetos,
muitos foram provocados por alguém que não conversou com outro sobre algo
importante. Algumas vezes o programador não fala para os outros uma mudança
fundamental no projeto, outras vezes, o programador não faz a pergunta correta para
cliente, fazendo com que uma importante decisão de domínio seja prejudicada.
A comunicação é o principal valor da XP, a maioria das práticas está baseada
nela, e se esta não for eficiente, pode causar problemas e atrasos no desenvolvimento do
sistema (NAPHTA, 2007).
18

3.1.3 Simplicidade
Conseguindo que o time entenda essa importância, é possível simplificar o
sistema podendo até diminuir o número de programadores ou o tempo de
implementação, ou seja, reduzir o valor do projeto.
XP aposta que é melhor fazer algo simples e de desenvolvimento rápido hoje, e
ter de gastar um pouco mais no futuro se for necessário para fazer modificações
necessárias do que implementar algo complicado hoje que talvez não venha a ser usado
(NAPHTA, 2007).
Ao codificar uma funcionalidade devem se preocupar apenas com os
problemas de hoje e deixar os problemas do futuro para o futuro, sem tentar prevê-lo,
pois raramente irá acertar.
Evitando especular sobre o futuro, o time ganhará tempo e permite que o
cliente tenha acesso à funcionalidade rapidamente, podendo utilizá-lo no seu negócio,
gerando valor e tornando viável que ele dê feedback para a equipe o quanto antes
(MANHÃES, 2004).
Segundo Beck (2000), simplicidade e comunicação têm uma relação de suporte
mútuo. Quanto maior a comunicação, mais claramente se observa o que precisa ser feito
e tem-se mais certeza do que não precisa.
3.1.4 Coragem
Como o sistema é desenvolvido de forma incremental, o time estará sempre
fazendo manutenção do software ou adicionando novas funcionalidades. Algumas vezes
será necessário alterar algo que estava funcionando corretamente, o que poderá gerar
falha. Daí a necessidade do time ter coragem e acreditar que com as práticas e valores
da XP o software será desenvolvido de forma segura e ágil.
Segundo MANHÃES (2004), XP não tem uma solução mágica para eliminar
esse risco, ele existe como em qualquer outro projeto, o que muda é a forma de lidar.
19

Equipes XP acreditam que errar é natural e quebrar o que vinha funcionando pode
acontecer eventualmente. É necessário ter coragem para lidar com esse risco, o que em
XP se traduz em confiança nos seus mecanismos de proteção.
A comunicação dá suporte à coragem porque abre a possibilidade para mais
experiências de alto risco e alta recompensa. A simplicidade também dá suporte a
coragem, pois podemos ser muito mais corajosos com um sistema simples e é menos
provável que estrague o sistema. O feedback concreto dá suporte à coragem, porque
temos a confiança de experimentar algo extremo no código e obter os resultados
positivos nos testes, ou não (BECK, 2000).
3.2 Princípios da XP
Alguns princípios da XP vão contra as técnicas de engenharia de software
tradicionais, uma vez que nela o foco principal é nas pessoas e não nos processos
formais.
XP coloca seus princípios em níveis extremos, por isso extreme no nome e
incorpora os valores neles.
3.2.1 Feedback Rápido
É importante o cliente fornecer esse feedback em relação ao sistema o mais
rápido possível, pois o tempo decorrido entre uma ação e seu feedback é fundamental
para o progresso do projeto e aprendizado da equipe.Tendo este feedback rápido pode-
se interpretá-lo e aplicar o que é aprendido no sistema o mais rápido possível.
Os programadores aprendem qual a melhor forma de se projetar, implementar e
testar o sistema, e realimentam o que foi aprendido em segundos ou minutos, em vez de
dias, semanas ou meses (BECK, 2000).
20

3.2.2 Simplicidade presumida
Tratar cada problema da maneira mais simples possível, XP recomenda que os
trabalhos de hoje sejam resolvidos hoje e que os desenvolvedores confiem em suas
habilidades.
Segundo Beck(2000), esse princípio os programadores têm mais dificuldades
de aceitar. Tradicionalmente, somos orientados a planejar para o futuro, para se poder
reutilizar.
3.2.3 Mudanças incrementais
Grandes mudanças de uma só vez em qualquer projeto é muito difícil que dê
certo, no XP o projeto é alterado gradualmente em seu tempo de desenvolvimento. Essa
mudança deve ser planejada e estudada para que não atrapalhe o funcionamento normal
do sistema, a própria metodologia XP precisa ser feita em pequenos passos (BECK,
2000).
3.2.4 Aceitação das mudanças
Como em todo XP, a aceitação de mudanças é bem vinda, e não questionada.
Segundo Beck (2000), a melhor estratégia é aquela que preserva o maior números de
opções enquanto resolve o seu problema mais urgente.
As mudanças servem também como aprendizado, amadurecimento da equipe
de desenvolvimento de software.
21

3.2.5 Alta qualidade
Esse ponto não se tem negociação, qualidade é prioridade em projetos XP,
sempre em busca da excelência, caso contrário o projeto foi um fracasso.
3.2.6 Ensinar aprendendo
É proposto que ao contrário de criar “manuais doutrinários” mostrando passo-
a-passo o que? E como fazer? O foco é ensinar estratégias para aprender quantos testes,
refatoração e quanto de todas as outras coisas deve ser feito (BECK, 2000).
3.2.7 Investimento inicial pequeno
Em projetos em que os recursos são supérfluos, é um caminho para o desastre,
por isso temos que ter em mente apenas requisitos necessários.
Orçamento apertado força o programador e o cliente a cortar requisitos e
reduzir propostas, pois a concentração gerada leva a fazer um bom trabalho.
Segundo Beck (2000), na maioria das vezes, todos podem viver com menos
recursos do que gostariam, mas atenta também que recursos apertados demais pode
gerar um sistema nada interessante.
3.2.8 Jogar para ganhar
Muitas equipes de desenvolvimento de software seguem procedimentos
estabelecidos em reuniões, para se guardarem de futuras falhas no projeto, isto é jogar
22

para não perder, caso no final o projeto não seja bem sucedido, a equipe se resguarda
que seguiu os procedimentos.
Extreme programming acredita que o desenvolvimento de software jogado para
ganhar faz tudo que ajuda o time a chegar na excelência do projeto e nada daquilo que
não alcançar o objetivo (BECK, 2000).
3.2.9 Experimentação concreta
Segundo Beck (2000), toda decisão abstrata deve ser testada, quanto mais se
testa, mais os riscos se diminuem, pois a cada decisão tomada e não testada existe uma
probabilidade de que a decisão esteja errada, e gera insatisfação do cliente e até mesmo
da equipe.
3.2.10 Comunicação honesta e franca
A comunicação é um fator importante, e esse princípio permite o programador
a ter liberdade em falar um ao outro onde o código encontra-se com problema,
comunicar má noticias a gerência e à clientes.
Beck (2007) afirma, que os desenvolvedores precisam ter liberdade de
expressar seus receios e precisam receber apoio.
3.2.11 Trabalhar a favor dos instintos do pessoal e não contra eles
Pessoas gostam de aprende, de ganhar, de interagir com outras pessoas, de
estar no controle e que confiem nelas. Em particular desenvolvedores gostam de fazer
um bom trabalho e que seus softwares funcione.
23

Se a XP não trabalhar com os interesses de curto prazo do pessoal, ela estará
destinada ao fracasso das metodologias.
2000).
XP é como a observação de programadores no seu habitat natural (BECK,
3.2.12 Aceitação de responsabilidades
A cooperação do time depende da responsabilidade perante suas tarefas. Para
que seja aplicada de melhor maneira possível a responsabilidade deve ser aceita e não
imposta, sendo que as necessidades do time, em qualquer âmbito, devem ser atendidas
por um elemento voluntário do time, por pior que ela seja (BECK, 2000).
3.2.13 Adaptação local
Na adoção da metodologia ágil extreme programming, deve-se adaptar o seu
ambiente de trabalho às condições em que se propõe desenvolver sistemas.
Adotar XP não significa seguir suas práticas metodicamente, e sim, saber
adaptá-las à sua realidade (BECK, 2000).
3.2.14 Viajar com pouca bagagem
Times XP estão sempre preparados para eventuais mudanças, mas mantendo
sempre o padrão de valor para o cliente, testes e código (BECK, 2000).
Essas mudanças podem ser o design, o cliente que resolve mudar de idéia,
membro da equipe que vai embora ou mesmo uma tecnologia que não supre as
necessidades do projeto.
24

3.2.15 Métricas genuínas
Para obter o controle do desenvolvimento de software adota-se certas métricas,
às quais forçam um nível de detalhamento excessivo que não é suportado pelos
desenvolvedores, por isso, devem-se adequar as métricas que estejam correlacionadas
ao perfil de trabalho do time (BECK, 2000). Por isso equipes XP estimam as estórias
dos cliente, e sempre
3.3 Práticas da XP
Conjunto de atividades, conforme figura 1, que as equipes de XP tem como
base para seu desempenho, tem-se uma confiança muito grande nas práticas onde, os
pontos fracos de uma se compensa nos pontos fortes de outra.
Aplicadas em conjunto o desenvolvimento de software funciona melhor
tornando mais eficaz.
Figura 1: Práticas XP
Fonte: XPROGRAMMING, 2007
25

3.3.1 A equipe (whole team)
seguintes papéis:
Todos em um projeto XP são parte de uma equipe, no qual é composta pelos
Desenvolvedor: É a pessoa que constrói o software, análise, projeta e
codifica o sistema.
Redator Técnico: Auxilia a equipe na parte de documentação do projeto.
Analista de Teste: Ajuda o cliente a definir requerimentos e procura fazer
26
com que eventuais defeitos do sistema sejam identificados o quanto antes.
Gerente: Responsável pela parte administrativa e relacionamento com o
cliente, garante os recursos necessários para o projeto.
Coach: Pessoa com responsabilidade técnica do projeto, orienta a equipe e
controla a aplicação da XP.
3.3.2 Jogo do planejamento (planning game)
Esta prática define estimativas e prioridades. Em XP todo projeto é dividido
em release e iterações, com isso, equipe e cliente podem se reunir para rever o
planejamento.
O cliente em cada reunião recebe um cartão no qual descreve as
funcionalidades que deseja do sistema, que se chama de estórias, e no jogo do
planejamento se estima cada estória para o cliente saber o custo da implementação
(JAVAFREE, 2007).
Como uma estória não descreve os detalhes da funcionalidade, quando um par
de desenvolvedores for implementá-la, devem buscar estes detalhes com o cliente. As
estórias também são usadas como uma forma de documentação do projeto.
Segundo Beck (2000), o desenvolvimento de software é sempre um diálogo
evolutivo entre o possível e o desejável, as pessoas da área do negócio precisam decidir
sobre: o escopo, prioridade, composição das versões e datas de entrega.

A área de negócio não consegue tomar essas decisões no vácuo, a partir de
nada, a área de desenvolvimento precisa tomar decisões técnicas para auxiliar nas
decisões de negócio.
3.3.3 Teste de aceitação (customer tests)
Verifica se a interação entre as classes que implementam uma funcionalidade
atende a necessidade descrita na estória do cliente, facilitando ainda mais a interação
entre as partes.
3.3.4 Pequenos lançamentos (small releases)
comprando.
Liberação de pequena versão ao qual o cliente testa parte do sistema que está
Como o objetivo da XP é gerar um fluxo contínuo de valor para o cliente, as
releases devem ser curtas. Assim, coloca-se rapidamente em produção um conjunto
reduzido de funcionalidades, para que o cliente possa beneficiar-se o quanto antes. Cada
vez que o sistema for colocado em produção, novas funcionalidades deverão ser
adicionadas gerando maior valor agregado ao produto final (MANHÃES, 2004).
3.3.5 Design simples (simple design)
A equipe em cada interação(estória) pensa em uma arquitetura simples em
questão, mesmo conhecendo interações futuras, isto ajuda no caso de haver alterações
nos requisitos.
Ao desenvolver um código, deve-se focar em atender às necessidades da
funcionalidade que está sendo implementada, sem preocupar-se em prepará-lo para
27

necessidades futuras. Isso leva a um desenvolvimento muito mais ágil (MANHÃES,
2004).
O projeto correto é aquele que:
1. Executa todos os testes.
2. Não possui lógica duplicada.
3. Expressa todas as intenções importantes para os programadores.
4. Tem o menor número possível de classes e métodos.
Cada parte do projeto do sistema precisa justificar sua existência nesses termos (BECK,
2000).
3.3.6 Programação em par (pair programming)
Estilo de programação ao qual se tem uma segurança na redução de risco do
projeto. Um desenvolver programa (condutor) e o outro fazem uma inspeção no código
gerado (navegador). Normalmente o navegador é o programador com maior experiência
e o condutor novato ou com experiência menor, e este, que fica na condição de gerar os
comando, enquanto o outro, o navegador, trabalha como um instrutor, gerando assim
uma redução de bugs, aprendizado rápido, solução mais simples e eficaz para o
problema.
Está prática consegue-se uniformizar o nível dos desenvolvedores da equipe,
logo, todos terão conhecimento do projeto como um todo (MANHÃES, 2004).
A programação em par é dinâmica, se duas pessoas formam um par pela
manhã, à tarde elas podem facilmente formar duplas com outros colegas (BECK, 2000).
28

3.3.7 Desenvolvimento orientado a testes (test-driven development)
Segundo Manhães (2004), uma equipe XP está acostumada com os teste, pois
assim garante o funcionamento pleno do sistema, primeiro cria-se o teste unitário de
cada funcionalidade antes da codificação. O uso de ferramentas de automação de testes
poderá reduzir o esforço desta prática. Dessa maneira, pode-se melhorar o entendimento
das necessidades, o design e mantendo a simplicidade do código. Sua principal
importância é a alta qualidade do sistema
Os programadores escrevem testes de unidade para que sua confiança na
operação do programa possa se tornar parte do programa. O resultado é um programa
que se torna cada vez mais confiável com o tempo, tornando-se capaz de aceitar
modificações, e não menos (BECK, 2000).
3.3.8 Refinamento do design (refactoring)
A equipe altera pequenas partes do sistema, freqüentemente, sempre que
encontram uma oportunidade para melhorar o código, dando maior clareza (leitura) do
código, tendo um reaproveitamento, evitando a duplicação de código-fonte e fácil de ser
compreendido.
Segundo Beck (2000), a refatoração é feita quando o programa necessita,
quando o sistema requer código duplicado, e ainda mantendo todos os testes
funcionando.
3.3.9 Integração contínua (continuous integration)
A cada nova funcionalidade produzida e testada integrar à versão final do
sistema, sempre tendo a versão atualizada.
29

Como se trata de uma equipe, pode ocorrer de dois ou mais desenvolvedores
terem que alterar determinados arquivos, com isso, o objetivo é ter o código fonte
sempre atualizado, utiliza-se um sistema de controle de versão ou repositório.
Com isto, pequenos problemas de integração podem ser descobertos e
corrigidos logo no início (MANHÃES, 2004).
3.3.10 Posse coletiva (collective ownership)
Todos em um projeto tem acesso a todo o código e liberdade para alterar, por
isso os pares de programadores se revezam ou seja, o código é coletivo, todos são
responsáveis por ele.
Na XP, todos são responsáveis pelo sistema inteiro. Nem todos conhecem
todas as partes igualmente bem, mas todos sabem um pouco sobre cada parte. Se um par
está trabalhando e vê uma oportunidade de melhorar o código, eles vão em frente e o
melhoram (BECK, 2000).
Segundo Manhães (2004), como outros irão ler o código no futuro próximo, é
importante que ele seja sempre escrito da maneira mais legível possível. Por isto é o que
garantirá que a equipe conseguirá continuar a implementar o sistema e leva a equipe a
ser mais ágil no desenvolvimento.
Esta prática depende fortemente de duas outras: refatoração e o
desenvolvimento guiado por testes.
3.3.11 Padrões de codificação (coding standards)
devem seguir.
A equipe XP tem que criar regras para programação, um padrão que todos
A equipe deve se comunicar de forma clara através do código, assim como faz
verbalmente ou através de modelos. Para ajudar neste sentido, a XP sugere a utilização
de padrões de codificação (MANHÃES, 2004).
30

O Padrão adotado deve exigir a menor quantidade de trabalho possível,
consistente com a regra do “uma e somente uma vez” (sem código duplicado). O padrão
deve enfatizar a comunicação. Finalmente, o padrão deve ser adotado voluntariamente
por todo o time (BECK, 2000).
3.3.12 Metáfora (metaphor)
Procura facilitar a comunicação entre desenvolvedor e o cliente, estabelecendo
um vocabulário com o qual o cliente esteja habituado em seu dia-a-dia, de modo a
elevar a compreensão mútua, ajuda todos os envolvidos no projeto a entenderem os
elementos básicos e seus relacionamentos (BECK, 2000).
3.3.13 Ritmo saudável (sustainable pace)
Consiste em trabalhar com qualidade, respeitando a individualidade e o físico
de cada desenvolvedor, sem horas extras. XP sugere um ritmo de 40 horas/semana, o
horas/dias, nunca exceder estas horas duas semanas seguidas (JAVAFREE, 2007).
Trabalhar por longos períodos é contraproducente.
3.4 Mudanças no XP
As mudanças propostas por Kent Beck e Cynthia Andrés são referenciadas
como a XP2, devido ao fato de terem reescrito a metodologia, mantendo a proposta
inicial de Beck, mas buscando o lado mais humano nos princípios, valores e práticas.
31

3.4.1 Valores
Aos já conhecidos valores da XP Comunicação, simplicidade, feedback e
coragem, no XP2 acrescenta um novo valor o de respeito. Tornando a necessidade de se
criar bons relacionamentos entre as pessoas envolvidas no projeto.
3.4.2 Princípios
Os princípios com maior importância, pois são os guias específicos ao contexto
do desenvolvimento de software.
Segundo Beck e Andrés(2004), os princípios ajudam na adaptação da XP para
a realidade de cada um, por isso, á necessidade de identificar princípios particulares em
cada ambiente de trabalho.
3.4.3 Práticas
Embora as 13 práticas ainda representam a essência da XP, muitas delas foram
renomeadas, novas práticas foram acrescentadas na metodologia e outras foram
subdivididas.
A grande mudança da XP para o XP2, encontra-se na separação entre as
práticas primárias e práticas corolárias ou resultante.(JAVAMAGAZINE).
Segundo Beck e Andres(2004), as práticas primárias podem ser aplicadas
individualmente e o resultado implicará em melhoria imediata no processo de
desenvolvimento da equipe. Já as corolárias precisam que as práticas primárias já
estejam em funcionamento para que possam contribuir efetivamente para a melhoria do
trabalho.
32

4 ESTUDO DE CASO
O estudo de caso representa uma pesquisa de campo realizado com empresas
que de uma forma ou de outra tiveram contato com a XP.
Para a pesquisa, foi desenvolvido um questionário com 10 (dez) perguntas,
conforme anexo I, no qual lideres de projetos de empresas responderam e auxiliou no
resultado final.
As empresas sujeitas à pesquisa foram selecionadas pelos seguintes critérios:
Conhecimento da XP.
Empresa ligada a tecnologia.
Possuir equipe de desenvolvimento.
Experiência em desenvolvimento de sistemas.
O objetivo da pesquisa foi levantar dados para comprovação do uso da
metodologia pelas empresas e seus efeitos.
A região pesquisada foi a Sudeste, com empresas em São Paulo, Rio de Janeiro
e Santa Rita do Sapucaí, de porte pequena, média e grande.
Como resultado, chega-se as seguintes demonstrações abaixo:
O Motivo pela qual as organizações optaram pela metodologia ágil extreme
programming como forma de desenvolvimento de software apura-se na figura 2, ao
qual, conseguimos observar a importância que as organizações estão tendo para a
qualidade de seus produtos.
33

33,40%
16,65% 16,65% 16,65% 16,65%
Qualidade Agilidade Produtividade Confiabilidade Adaptação da equipe
Figura 2: Motivos da adoção da XP
Mesmo com todas as afirmações sobre a XP, ainda as organizações estão
cautelosas quanto à forma de desenvolvimento de sistemas propostos pela XP,
conforme ilustra a figura 3.
34

37,50%
25%
12,50% 12,50% 12,50%
Todas Pequenos Lançamentos Integração contínua Jogo do Planejamento Metáfora
Figura 3: Utilização das práticas da XP
Nas figuras 4 e 5, nota-se que as organizações utilizam a XP com outras
metodologias, ou seja, adaptam a XP com o perfil da equipe de desenvolvimento,
buscando sempre a qualidade final, e utilizam também como maneira de integrar XP
sem muitas resistências.
35

80%
20%
Sim Não
Figura 4: Combinação da XP com outras metodologias
50%
25% 25%
Scrum Lean CMM
Figura 5: Principais metodologias usadas integradas a XP
36

Na implantação da XP, como a metodologia tem foco diferenciado das
metodologias tradicionais, encontra-se algumas facilidades e muitas resistências quanto
ao uso das práticas proposta por Kent Beck, no estudo de caso temos nas figuras 6, 7 e 8
o demonstrativo dessas facilidades e resistências.
33,40%
16,60% 16,60%
33,40%
Vender a idéia utilização da metodologia pura falta de presença do cliente Resistência de gerentes
Figura 6: Dificuldades na implantação da XP
37

22,20% 22,20% 22,20%
11,13% 11,13% 11,13%
Programação em par Código coletivo Pequenos lançamentos Jogo do planejamento Testes de aceitação Integração contínua
Figura 7: Práticas mais fáceis de implantar nas organizações pesquisada
16,65% 16,65%
Desenvolvimento orientado
a teste
.
33,40%
16,65% 16,65%
38
Jogo do Planejamento Programação em par Metáfora Pequenos lançamentos
Figura 8: práticas mais difíceis de implantar, segundo pesquisa

11,11% 11,11% 11,11%
cronograma de projeto documento de
acompanhamento de
bugs
22,22% 22,22% 22,22%
39
documento de testes javadoc quadros brancos diagramas UML
Figura 9: Tipos de documentações
Foi analisado, pela figura 9, os tipos de documentações utilizados nos projetos
nas empresas entrevistadas. Já na figura 10, ilustra o uso da metodologia nas
organizações foi bem sucedido, ou não.

80%
20%
sim sim, mas adaptado
Figura 10: Sucesso do uso da XP na organização
40

5 CONSIDERAÇÕES FINAIS
Analisando os fatos da pesquisa realizada, nota-se que muitas organizações
adotam a metodologia XP como alternativa para auxiliar no processo de
desenvolvimento de softwares, para atender a clientes visando cumprir o cronograma e
obter a satisfação do cliente juntamente com a qualidade.
Em um projeto de software, arrumar bugs, ou seja, reparar erros do sistema é a
parte mais cara para o cliente, pois esses bugs traumáticos são encontrados tardios nos
processos tradicionais e com as metodologias ágeis são encontrados mais cedo, durante
o desenvolvimento, tornando-se menos traumáticos. Este é apenas um dos ganhos que a
metodologia proporciona.
Muitas organizações deixam de usar XP por falta de conhecimento da
metodologia e por resistências de toda a equipe, sem a aprovação e colaboração de
todos os membros da empresa, não se obtém o sucesso que a XP gera, pois a
metodologia é voltada para o lado humano. Os problemas no desenvolvimento de
sistemas estão mais relacionados com pessoas, fator humano, do que com a tecnologia.
Muitas empresas e colaboradores amam XP e já outros odeiam não se encontra
meio termo para essa questão, o próprio nome da metodologia gera certo pânico em
algumas pessoas. Programação extrema, para quem adora programar se considera que
está em casa, mas para aquele que não gosta de programação certamente fará com que
não se adotem a metodologia, e na verdade não é isso que a XP propõem. Ao contrário
do que pensam XP não é somente programação, XP se planeja, estima, documenta, mas
de um modo bem diferenciado.
Apesar da resistência inicial de algumas equipes, quem utiliza XP não volta a
utilizar metodologias tradicionais, procura sempre adaptar XP para cada projeto, pois a
metodologia permite essa adaptação para o perfil da equipe ou projeto. Isto se deve ao
fato da XP impactar muito mais positivamente do que negativamente no processo de
desenvolvimento de software da organização.
41

REFERÊNCIAS BIBLIOGRÁFICAS
AGILCOOP, disponível em
http://agilcoop.incubadora.fapesp.br/portal/eventos/seminarioUNICAMP/ acessado em
02 de Setembro de 2007.
AGILCOOP 2, disponível em http://agilcoop.incubadora.fapesp.br/portal/agilvideo
acessado em 14 de Setembro de 2007.
BECK, Kent. Extreme Programming Explained.,New York: 2000, Addison Wesley.
BECK, Ken; ANDRÉS Cynthia.. Extreme Programming Explained Embrace
Chance .,New York: 2004, Addison Wesley.
COHEN, D.; LINDVALL, M.; COSTA, P. An introduction to agile methods. In
Advances in Computers. New York: 2004, Elsevier Science.
FOWLER, Martin,
http://www.naphta.com.br/xpmanager/xpmanager_metodologiasageis.html acessado em
21 de Agosto de 2007.
IMPROVEIT, disponível em www.improveit.com.br/xp, acessado em 16 de Agosto de
2007.
42

JAVAFREE, -Apresentando XP, encante seus clientes com Extreme Programming,
disponível em www.javafree.org, acessado em 29 de Janeiro de 2007 as 14:58.
JAVAMAGAZINE, o novo XP Explicado, edição 25 ano III .
MANHÃES, Vinícius Teles. Extreme Programming - Aprenda como encantar seus
usuários desenvolvendo software com agilidade e alta qualidade, Rio de Janeiro:
2004, Novatec Editora.
NAPHTA, disponível em
http://www.naphta.com.br/xpmanager/xpmanager_metodologiasageis.html acessado em
21 de Agosto de 2007.
SIMPLUS, disponível em http://simplus.com.br/artigos/a-nova-metodologia/ acessado
em 02 de Setembro de 2007.
SOARES, Michel dos S. disponível em
http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf acessado em 21 de Agosto 2007
XPROGRAMMING, disponível em www.xprogramming.com acessado em 12 de
Setembro de 2007.
43

ANEXOS
Anexo I
Pesquisa para o Trabalho de Conclusão de Curso(TCC)
Instituição: Universidade do vale do Sapucaí – UNIVÀS
Curso: Sistemas de Informação
Aluno: Thiago Borborema (thiago_borborema@ yahoo.com.br).
IMPACTO DA UTILIZAÇÃO DA XP NAS ORGANIZAÇÕES DE
DESENVOLVIMENTO DE SOFTWARE.
1. Qual motivo o levou a utilizar a XP?
2. Utiliza todas as práticas da XP? Caso contrário, quais?
3. Possui experiência em outros métodos ágeis ou não? Quais?
4. Utiliza XP combinado com outros métodos?
5. Quais as dificuldades na implantação da XP?
6. A XP é a abordagem mais adequada para sua organização? Justifique.
7. Quais práticas foram mais fáceis de se incorporar em uma organização e
quais as mais difíceis? Por quê?
8. Sua organização você julga madura ou imatura em processo de
desenvolvimento?
9. Utiliza documentação? Quais?
10. Durante a implantação da XP, houve resistência? Como a organização
lidou com isso?
44