O primeiro projeto XP (Extreme Programming) foi iniciado em 6 de Maro de 1996.

Ex
treme Programming apenas uma de muitas Metodologias geis populares. Extreme Progr
amming bem sucedida porque reala a satisfao do cliente. Invs de entregar tudo que vo
c possivelmente poderia querer em uma data longe no futuro, esse processo entrega
o software que voc precisa quando voc precisa. Extreme Programming d poder seus de
senvolvedores para responder s mudanas dos requisitos dos clientes com confiana, me
smo que tais mudanas sejam tardias no ciclo de vida.
Extreme Programming melhora o projeto de software em cinco maneiras essenciais;
comunicao, simplicidade, feedback, respeito e coragem. Quem usa Extreme Programmin
g esto em comunicao constante com seus clientes e companheiros programadores. Eles
mantem seu design simples e limpo. Eles recebem feedback testando o software des
de o primeiro dia. Eles entregam o sistema para os clientes o mais rapido possiv
el e implementam as mudanas no momento em que foram sugeridas. Cada pequeno suces
so aprofunda o respeito pela contribuio unica de cada membro do time. Com essa fun
dao, o Extreme Programming capaz de responder bravamente s mudanas de requisitos e t
ecnologia.
O aspecto mais surpreendente do Extreme Programming so suas regras simples. Extre
me Programming muito parecido com um quebracabeas. Existem muitas peas pequenas. I
ndividualmente, as peas no fazem sentido, mas quando combinadas, uma figura comple
ta pode ser vista.
Nossas regras geram expectativas entre os membros do time, mas por si s no so o obj
etivo final.
Voc vai perceber que essas regras definem um ambiente que promove a colaborao em eq
uipe e empoderamento, esse o objetivo. Uma vez alcanado, a produtividade do traba
lho em equipe continuar mesmo que as regras mudem para se ajustar s necessidades e
specificas de sua compania.
O fluxograma a seguir mostra como as regras do Extreme Programming funcionam jun
tas. Os clientes gostam de ser parceiros no processo de software, os desenvolved
ores contribuem ativamente independente do nivel de experiencia, e os gestores s
e concentram na comunicao e relacionamento. Atividades improdutivas foram aparadas
para reduzir custos e frustrao de todos os envolvidos.
REGRAS
Planejamento
User stories so escritas.
Stories servem para o mesmo proprosito de casos de uso mas nao sao a mesma coisa
. Eles sao usados para criar uma estimativa de tempo para a reuniao de planejame
nto de release. Sao tambem usados no lugar de uma documentaao de requisitos volum
osa. As user stories sao escritas pelo usuario como as coisas que o sistema prec
isa fazer para eles.
Planejamento de Release cria a Agenda de Release
A reuniao de planejamento da release usada para criar o plano de release. O plan
o de release etnao usado para criar o plano de iteraao para cada iteraao
Faa releases pequenos frequentemente
O projeto dividido em iteraes
O Planejamento de Iterao comea a cada iterao
Gerenciamento
D um espao de trabalho aberto ao time
comunicao muito importante para o time XP. Voce pode adicionair caminhos vitais pa
ra comunicao do time apenas tirando as barreiras que dividem as pessoas. Colocando
os computadores em uma area central que ninguem faa par consigo mesmo e encorage
as pessoas a trabalharem juntas com um sentimento de igualdade. Colocando algun
s desks ao redor do perimetro da as pessoas um lugar para trabalhar sozinha sem
se desconectar do resto do time.
Incluindo uma area grande para stand up meetings evita que as pessoas nao compar
eam as reunioes. Adicionando uma mesa de conferencia te da um lar para discussoes

em grupo que ocorrem espontaneamente ao longo do dia. Sendo capaz de ver as dis
cues encoraja as pessoas a ouvir ou se juntar a discuo quando elas possuirem interes
se no resultado.
Adicionar lousas brancas para rascunhos ou anotaoes importantes ou paredes branca
s onde os cartoes de user stories possam ser coladas adiciona ainda mais canais
para comunicao. Postando um par de graficos mirando melhorias ou o progresso do pr
ojeto informa os times evitando a perseguinao da gerencia.
Defina um ritmo sustentvel
Trabalhar mais horas suga o espirito e a motivaao do time. Quando seu time se tor
na cansado e desmoralizado eles produzem menos, nao mais, mesmo que fizerem hora
extra. Trabalhar mais do que o sustentavel hoje rouba a produtividade do futuro
. Voce nao capaz de fazer planos reais quando seu time faz mais nesse mes e meno
s no proximo mes. Inves de forar as pessoas a fazer mais do que o humanamente imp
ossivel, use a reuniao de planejamento do release para adaptar o escopo ou o pra
zo.
Uma reunio de p ao comeo de cada dia
A velocidade do projeto medida
Revezamento periodico de pessoas
Movimente as pessoas ao redor para evitar serias perdas de conhecimento e gargal
os na codificao. Se apenas uma pessoa no seu time capaz de trabalhar em dada area
e aquela pessoa sai ou apenas tem muito trabalho a fazer voce descobrira que o p
rogresso do seu time drasticamente reduzido.
Treinamento cruzado frequentemente uma consideraao importante em companias tentan
do evitar ilhas de conhecimento, que ento, sucetivel a perda. Movendo as pessoas
ao redor do codigo em combinao com a programao em par faz isso para voce. Inves de u
ma pessoa que sabe tudo sobre dada seo de codigo, todos do time sabem muito sobre
o codigo em cada seo.
Um time muito mais flexivel se todos sabem o suficiente para trabalhar em todas
as partes do sistema. Inves de ter poucas pessoas sobrecarregadas com trabalho e
nquanto outros tem pouco trabalho a fazer, o time todo pode ser produtivo. Qualq
uer numero de desenvolvedores pode ser designado as partes mais criticas do sist
ema. Balanceamento flexivel de carga desse tipo o sonho do gerente virando reali
dade.
Simplesmente encorage a todos trabalharem em uma nova seo do sistema em uma parte
minima a cada iterao. Programaao em par torna possivel sem a perda de produtividade
e garannte a continuidade de pensamento. Uma pessoa de um par pode ser trocada
enquanto a outra continua com um novo perceiro se desejar.
Concerte o Extremme Programming quando parar de funcionar
Design
Simplicidade
Escolha uma metfora de sistema
Use cartes de colaborao durante as sesses de design
Nenhuma funcionalidade nova adicionada logo
Refatorar sempre e onde for possvel
Codificao
O cliente sempre est disponvel
O cdigo precisa estar escrito de acordo com os padres
Codifique o teste unitrio primeiro
Toda a produo de cdigo feita em programao em par
Apenas um par integra cdigo por vez
Integrao constante
Definir um computador dedicado para integrao
Propriedade coletiva, todos so donos do cdigo
Testes

Todos os cdigos precisam ter testes unitrios

Todos os cdigos precisam passar em todos os testes unitrios antes de ser lanado
Quando um erro encontrado, testes so criados.
Testes de aceitao so realizados frequentemente e a pontuao publicada
VALORES
O Extreme Programming baseado em valores. As regras que examinamos agora a pouco
so uma extenso e consequencia natural da maximizao dos nossos valores. XP no somente
um conjunto de regras, mais do que isso, uma maneira de trabalhar em harmonia c
om seus valores pessoas e corporativos. Comece o XP com os valores listados aqui
e depois adicione seus proprios, refletindoos nas mudanas que voce fizer nas reg
ras.
Simplicidade: Faremos o que preciso e solicitado, no mais.