eXtreme Programming

Metodologia gil para equipes pequenas a mdias

desenvolvendo software com requesitos vagos ou
eXtreme Programming (XP) que mudam freqentemente. [Beck 2000]
Em XP, codificao principal tarefa
Baseia-se em
reviso permanente do cdigo, testes freqentes,
participao do usurio final, refatorao contnua,
refinamento contnuo da arquitetura, integrao
contnua, planejamento, projeto e reprojeto a qualquer
hora

Metodologia gil
Estamos descobrindo maneiras melhores de
Partes do XP
desenvolver software fazendo-o ns mesmos e
ajudando outros a faz-lo. Atravs desse trabalho,
passamos a valorizar: 1. Values (valores): estabelecem a forma do
Indivduos e interaes mais que processos e desenvolvimento XP
ferramentas; Principles (princpios): guiam o
Software em funcionamento mais que documentao desenvolvimento do software
abrangente;
Colaborao com o cliente mais que negociao de Activities (atividades): devem ser executadas
contratos; por todo o ciclo de vida XP
Responder a mudanas mais que seguir um plano. Practices (prticas): so utilizadas pelas equipes
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
XP para desenvolver sistemas
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern,
Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave
Thomas

1. Valores do XP Communication (comunicao)

Vrias prticas do XP promovem uma maior
Communication - (comunicao) comunicao entre os membros da equipe
Simplicity - (simplicidade) A comunicao no limitada por procedimentos
formais.
Feedback - (retroalimentao) Usa-se o melhor meio possvel, que pode ser
Uma conversa ou reunio informal
Courage - (coragem)
Um e-mail, um bate-papo, um telefonema
O prprio cdigo
Preferncia comunicao mais gil

1
 Simplicity (simplicidade)
XP incentiva ao extremo prticas que
reduzam a complexidade do sistema
A soluo adotada deve ser sempre a mais
simples que alcance os objetivos esperados
Use as tecnologias, algoritmos e tcnicas mais
simples que permitiro atender aos requisitos
do usurio-final
Design, processo e cdigo podem ser
simplificados a qualquer momento
Courage (coragem)
Testes, integrao contnua, programao em
pares e outras prticas de XP aumentam a
confiana do programador e ajudam-no a ter
coragem para
melhorar o cdigo que est funcionando para torn-lo
mais simples
investir tempo no desenvolvimento de testes
mexer no design em estgio avanado
pedir ajuda aos que sabem mais
abandonar processos formais e ter o projeto e a
documentao em forma de cdigo
Rapid Feedback (retorno rpido)
O retorno entre os desenvolvedores rpido
Cliente sabe se o produto que est sendo
desenvolvido atende s suas necessidades
Modele um pouco, mostre ao cliente e ento
modele novamente.
Garante que o seu modelo ser preciso
enquanto seu conhecimento do projeto aumenta
Feedback (retroalimentao)
Vrias prticas de XP garantem um rpido
feedback sobre vrias etapas/partes do processo
Feedback sobre qualidade do cdigo (testes de unidade,
programao em pares, posse coletiva)
Feedback sobre estado do desenvolvimento (estrias do
usurio-final, integrao contnua, jogo do
planejamento)
Permite maior agilidade
Erros detectados e corrigidos imediatamente
Requisitos e prazos reavaliados mais cedo
Permite estimativas mais precisas
2. Princpios XP
Rapid Feedback - (retorno rpido)
Assume Simplicity - (simplicidade)
Incremental Change - (mudanas
incrementais)
Embrace Change - (aceitar mudanas)
Quality work - (trabalho de qualidade)
Assuma Simplicity (simplicidade)
Deixe o seu modelo to simples quanto
possvel e assuma que a soluo mais
simples a melhor
O design do sistema deve ser feito para a
iterao corrente. No deve ser feito design
sobre uma possvel necessidade futura.
2
 Incremental Change (mudanas
incrementais)
O modelo no ser perfeito na primeira
tentativa, ele ir mudar de acordo com o
desenvolvimento do projeto
Os problemas devem ser solucionados com
um conjunto de pequenas modificaes
Embrace Change (aceitar
mudanas)
Mudanas ocorrero no projeto de acordo
com o crescimento do entendimento do
mesmo
Aceite as mudanas e tenha coragem para
reconstruir

Quality work (trabalho de

3. Atividades XP
qualidade)
A qualidade do trabalho nunca deve ser Listening - (escutar)
comprometida Testing - (testar)
XP eleva a importncia da codificao e do Coding - (codificar)
teste antes da programao test-first Designing (projetar)
programming

Listening (escutar) Testing (testar)

XP baseado em comunicao Teste um passo integrado no processo de
Menor importncia na documentao desenvolvimento
formal, maior necessidade de uma Desenvolvedores escrevem os teste antes de
comunicao verbal de qualidade desenvolverem o cdigo
Alm de dizer que os desenvolvedores
devem escutar os clientes, XP tem prticas
que dirigem e guiam para uma comunicao
melhor

3
 Coding (codificar) Designing (projetar)
Escrever cdigo que refinado atravs de O design no esttico nem designado a um
prticas como: cargo (pessoa), ele dinmico e de
Refactory - refatorao responsabilidade de toda equipe
Pair programming programao em pares XP aceita a evoluo natural do sistema, o
Code review reviso de cdigo que implica em mudanas constantes

4. Prticas XP Prticas XP
Whole Team Equipe Refactoring Refinamento do projeto
Plannig Game Jogo do planejamento Continuos Integration Integrao contnua
Customer Tests Testes de aceitao
Collective Ownership Posse coletiva
Small releases Verses pequenas
Coding Standards Padres de codificao
Simple Design Projeto simples
Pair programming Programao em pares
Metaphor Metfora
Test-driven Development Desenvolvimento Sustainable Place Ritmo saudvel
orientado a testes (TDD)

A equipe (Whole Team) Jogo do Planejamento (Planning

Todos em um projeto XP so parte de uma equipe. Game)
A equipe deve incluir um representante do cliente:
estabelece os requisitos do projeto
Dois passos chaves:
define as prioridades Planejamento de um release
controla o rumo do projeto Cliente prope funcionalidades desejadas (estrias)
Outros papis assumidos pelos integrantes da equipe: Programadores avaliam a dificuldade de
implement-las
programadores
testadores (que ajudam o cliente com testes de Planejamento de uma iterao
aceitao) Cliente define as funcionalidades prioritrias para a
analistas (que ajudam o cliente a definir requerimentos) iterao;
gerente (garante os recursos necessrios) Programadores as quebram em tarefas e avaliam o
seu custo (tempo de implementao)
coach (orienta a equipe, controla a aplicao de XP)
tracker (coleta mtricas)

4
 Teste de aceitao
(Customer Tests)
Testes de aceitao so elaborados pelo cliente
So testes automticos
Quando rodarem com sucesso, funcionalidade foi
implementada
Devem ser rodados novamente em cada iterao
Oferecem feedback: pode-se saber, a qualquer
momento, quanto do sistema j foi implementado e
quanto falta.
Design simples (Simple Design)
Design est presente em todas as etapas no XP
Projeto comea simples e se mantm simples atravs de
testes e refinamento do design (refactory).
No permitido que se implemente nenhuma funo
adicional que no ser usada na atual iterao
Implementao ideal aquela que
Roda todos os testes
Expressa todas as idias que voc deseja expressar
No contm cdigo duplicado
Tem o mnimo de classes e mtodos
TDD (Test-driven Development)
"Test first, then code"
Programadores XP escrevem testes primeiro,
escrevem cdigo e rodam testes para validar o
cdigo escrito
Cada unidade de cdigo s tem valor se seu
teste funcionar 100%
Testes so a documentao executvel do
sistema
Verses Pequenas (Small Releases)
Disponibiliza, a cada iterao, software 100%
funcional
Benefcios do desenvolvimento disponveis
imediatamente
Menor risco (se o projeto no terminar, parte existe e
funciona)
Cliente pode medir com preciso quanto j foi feito
Feedback do cliente permitir que problemas sejam
detectados cedo e facilita a comunicao entre o cliente
e os desenvolvedores
Lanamento pode ser destinado a
usurio-cliente (que pode test-lo, avali-lo, oferecer
feedback)
usurio-final (sempre que possvel)
Programao em duplas
(Pair programming)
Todo o desenvolvimento em XP feito em pares
Um computador, um teclado, dois programadores
Um piloto, um co-piloto
Papis so alternados freqentemente
Pares so trocados periodicamente
Benefcios
Melhor qualidade do design, cdigo e testes
Reviso constante do cdigo
Nivelamento da equipe
Maior comunicao
Refatorao (Refactoring)
No existe uma etapa isolada de projeto em XP
O cdigo o projeto!
O projeto melhorado continuamente atravs de
refactory
Mudana proposital de cdigo que est funcionando
Objetivos: melhorar o design, simplificar o cdigo,
remover cdigo duplicado, aumentar a coeso, reduzir o
acoplamento
Realizado o tempo todo, durante o desenvolvimento
5
 Integrao contnua
Projetos XP mantm o sistema integrado o tempo
todo
Integrao de todo o sistema pode ocorrer vrias vezes
ao dia (pelo menos uma vez ao dia)
Todos os testes (unidade e integrao) devem ser
executados
Benefcios
Expe o estado atual do desenvolvimento (viabiliza
lanamentos pequenos e freqentes)
Estimula design simples, tarefas curtas, agilidade
Oferece feedback sobre todo o sistema
Permite encontrar problemas de design rapidamente
Padres de codificao
(Coding Standards)
O cdigo escrito em projetos XP segue um padro de
codificao, definido pela equipe
Padro para nomes de mtodos, classes, variveis
Organizao do cdigo (chaves, etc.)
Cdigo com estrutura familiar facilita e estimula
Posse coletiva
Comunicao mais eficiente
Simplicidade
Programao em pares
Refinamento do design
Ritmo saudvel (Sustainable
Place)
Projetos com cronogramas apertados que sugam
todas as energias dos programadores no so
projetos XP
"Semanas de 80 horas" levam baixa produtividade
Produtividade baixa leva a cdigo ruim, relaxamento da
disciplina (testes, refactoring, simplicidade), dificulta a
comunicao, aumenta a irritao e o stress da equipe
Tempo "ganho" ser perdido depois
Eventuais horas extras so aceitveis quando
produtividade maximizada ao longo prazo
Posse coletiva (Collective
Ownership)
Em um projeto XP qualquer dupla de
programadores pode melhorar o sistema a
qualquer momento.
Todo o cdigo em XP pertence a um nico dono: a
equipe
Todo o cdigo recebe a ateno de todos os
participantes resultando em maior comunicao
Maior qualidade (menos duplicao, maior coeso)
Menos riscos e menos dependncia de indivduos
Todos compartilham a responsabilidade pelas
alteraes
Metfora ( Metaphor)
Pode ser uma analogia com algum outro
sistema (computacional, natural, abstrato)
que facilite a comunicao entre os
membros da equipe e cliente
Facilita a escolha dos nomes de mtodos,
classes, campos de dados, etc.
Serve de base para estabelecimento de padres
de codificao
Dificuldades
Vencer barreiras culturais
Deixar algum mexer no seu cdigo
Trabalhar em pares
Ter coragem de admitir que no sabe
Pedir ajuda
Vencer hbitos antigos
Manter as coisas simples (e no tentar prever o futuro
escrevendo "design flexvel")
Jogar fora cdigo desnecessrio
Escrever testes antes de codificar
Refactory com freqncia (vencer o medo)
6
 Quando no usar XP
Equipes grandes e espalhadas geograficamente
Comunicao um valor fundamental de XP
No fcil garantir o nvel de comunicao requerido
em projetos XP em grandes equipes
Situaes onde o feedback demorado
Testes muito difceis, arriscados e que levam tempo
Programadores espalhados em ambientes fsicos
distantes e sem comunicao eficiente
Referncias
Beck, K. Extreme Programming Explained:
Embrace Change, 2000. Addison-Wesley.
Manifesto for Agile Software Development,
Agile Alliance, 2001, webpage: Manifesto-for-
Agile-Software-Dev
Concluses
Extreme Programming (XP) uma metodologia de
desenvolvimento de software baseada nos valores
simplicidade, comunicao, feedback e coragem.
Para implementar XP no preciso usar diagramas ou
processos formais. preciso fazer uma equipe se unir em
torno de algumas prticas simples, obter feedback
suficiente e ajustar as prticas para a sua situao
particular.
XP pode ser implementada aos poucos, porm a maior
parte das prticas essencial.
Nem todos os projetos so bons candidatos a usar uma
metodologia gil como XP. XP mais adequado a
equipes pequenas ou mdias.