XP

Extreme Programming

Apresentador

Luis Cludio

Introduo

Extreme Programming (XP) uma metodologia

de desenvolvimento de software, nascida nos
Estados Unidos ao final da dcada de 90.
Vem fazendo sucesso em diversos pases, por
ajudar a criar sistemas de melhor qualidade,
que so produzidos em menos tempo e de
forma mais econmica que o habitual.

Introduo

Tais objetivos so alcanados atravs

de um pequeno conjunto de valores,
princpios e prticas, que diferem
substancialmente da forma
tradicional de se desenvolver
software.

Introduo
Projetos cujos requisitos so vagos e
mudam com frequncia.
Desenvolvimento de sistemas orientados
a objetos.
Equipes pequenas, preferencialmente
at 12 desenvolvedores.
Desenvolvimento incremental (ou
iterativo), onde o sistema comea a ser
implementado logo no incio do projeto e
vai ganhando novas funcionalidades ao
longo do tempo.

Valores

Feedback
Respeito
Comunicao

Coragem
Simplicidade

Valores
Feedback
Quando o cliente aprende com o sistema que utiliza e reavalia as suas
necessidades, gerando feedback para a equipe de desenvolvimento.

o mecanismo fundamental que permite que o cliente conduza o

desenvolvimento diariamente.
Garante que a equipe direcione as
suas atenes para aquilo
que ir gerar mais valor.

Valores
Comunicao
O XP busca aproximar todos
os envolvidos do projeto.
Permite que o cliente compartilhe
o seu aprendizado com a equipe.
Promover a comunicao face-a-face ou da forma mais rica que for vivel.
A comunicao entre o cliente e a equipe permite que todos os detalhes do
projeto sejam tratados com a ateno e a agilidade que merecem.

Valores

Feedback
Comunicao

Valores
Simplicidade
Temos que implementar apenas aquilo que suficiente para atender a cada
necessidade do cliente.
Ao codificar, deve-se preocupar apenas com os problemas de hoje.
Deve-se deixar os problemas do futuro para o futuro.
As generalizaes devem ser feitas quando elas vierem na forma de uma
necessidade especfica e no como uma especulao.

Valores
Respeito
Respeito um valor que d sustentao a todos os
demais.
Membros de uma equipe s iro se preocupar em
comunicar-se melhor, por exemplo, se se
importarem uns com os outros.
Respeito o mais bsico de todos os valores.

Valores
Coragem
A equipe precisa ser corajosa e acreditar
que, utilizando as prticas e valores do XP,
ser capaz de fazer o software evoluir com
segurana e agilidade.
Em muitos casos, a equipe alterar
algo que vinha funcionando corretamente,
o que leva ao risco de gerar falhas
no sistema.
TELES, Vincius M. Extreme Programming.
Novatec Editora, 2006

Princpios

Princpios existem para

servir de ponte entre
valores e prticas.

Princpios servem como

guias que se aplicam a um
domnio especfico.

Princpios
Auto semelhana

O principio da auto semelhana sugere

que, quando equipes XP encontrarem
solues que funcionem em um
contexto, tambm procurem adot-las
em outros, mesmo que em escalas
diferentes.

Princpios
Benefcio mtuo
Benefcio mtuo um dos princpios mais
importantes do XP e, ao mesmo tempo, um
dos mais difceis de serem adotados.
Projetos de software so complexos e
normalmente sofrem presses de tempo e
outras que podem levar a equipe a adotar
prticas benficas para uns, mas prejudiciais
a outros. preciso ateno. O bom
funcionamento de uma equipe algo frgil.

Princpios
Diversidade

Prticas como Equipe Integral sugerem

que a equipe envolva, alm dos
desenvolvedores, arquitetos, designers de
interao, executivos entre outros. Opinies
diferentes ajudam a complementar as
solues e torn-las mais ricas.

Economia
Software um investimento.
Desenvolver uma atividade que
consome dinheiro e tempo. Investe-se
em software com a expectativa de que
gere retornos para os negcios.
XP reconhece essa premissa e
suas prticas so organizadas para
antecipar receitas e adiar despesas.

Princpios
Falha
Experimentar diferentes hipteses e falhar
em algumas delas prov novos
conhecimentos. Pode parecer desperdcio,
mas quando se trata de aprendizado,
frequentemente a forma mais rpida e rica
de aprender simplesmente tentar algo
novo, mesmo que mais tarde tenhamos que
voltar atrs e explorar outras alternativas.
Em XP, buscamos feedback concreto.

Princpios
Fluidez
Software conhecimento inserido no
meio digital.
Sendo assim, fludo.

Edifcios, por outro lado, so estruturas

estticas em um mundo fsico.
Apesar disso, muitos comparam fazer
software a construir prdios.
Esse um erro grave.

Princpios
Humanismo
Pessoas desenvolvem software.
Metodologias e ferramentas apenas as ajudam
a realizar o trabalho.
Portanto, importante compreender a
natureza humana para que possamos
potencializar o que ela tem de melhor e
suprimir o que tem de pior.
Em particular, devemos compreender os
programadores para que possamos nos aliar a
favor e no contra seus instintos.

Princpios
Melhoria

"Software no ouro, alface: um bem perecvel. Se

no for aprimorado ao longo do tempo, acaba
estragando."
Essa frase, atribuda a Brian Behlendorf no livro
The World is Flat, resume o princpio da melhoria.

Princpios
Oportunidade
Um acontecimento no projeto pode ser uma
crise ou uma oportunidade dependendo
apenas de como a equipe reage.
Quando enxergamos problemas como
oportunidades de aprendizado e mudana,
podemos adotar atitudes mais proveitosas para
todos os envolvidos.

Princpios
Passos de beb

Passos de beb implicam em fazer apenas

pequenas mudanas de cada vez.

Princpios
Qualidade
Equipes XP trabalham para criar software de
alta qualidade.
O objetivo altssima qualidade para o
software e nada menos que isso.
Por que?
Porque mais satisfatrio e econmico fazer
software dessa forma.

Princpios
Redundncia
Os problemas difceis e crticos em
desenvolvimento de software devem ser
resolvidos de vrias formas diferentes.
Mesmo que uma soluo falhe completamente,
as outras solues iro prevenir um desastre.
O custo da redundncia mais que pago pela
economia de no ter um desastre.

Princpios
Reflexo
Desenvolvimento de software tem uma longa tradio de
pessoas que se mantm to ocupadas pensando sobre
desenvolvimento de software que elas no tm sequer
tempo para desenvolver software.
Reflexo vem depois da ao.
Aprendizado ao refletida.
Para maximizar o feedback, reflexes em equipes XP so
misturadas com ao.

Princpios
Responsabilidade aceita

As prticas refletem responsabilidade aceita, por

exemplo, sugerindo que, quem quer que aceita
fazer um trabalho tambm o estime.
Da mesma forma, a pessoa responsvel por
implementar uma histria tambm responsvel
pelo design, implementao e teste da mesma.

Prticas

Prticas
Primrias
Ambiente Informativo

Build de Dez Minutos

Ciclo Semanal

Ciclo Trimestral
Desenvolvimento Orientado a Testes

Design Incremental

Prticas
Primrias
Folga

Sentar-se Junto

Histrias

Trabalho Energizado

Integrao Contnua

Programao em Par

Prticas

Corolrias
Anlise da Raiz do Problema

Base de Cdigo Unificada

Cdigo Coletivo

Prticas

Corolrias
Cdigo e Testes

Continuidade da Equipe

Contrato de Escopo Negocivel

Prticas

Corolrias
Envolvimento do Cliente Real

Equipes que Encolhem

Implantao Diria

Prticas

Corolrias

Implantao Incremental

Pagar Por Uso

Reunio em p
Stand up meeting
uma breve reunio realizada diariamente,
normalmente de manh, pela equipe de
desenvolvimento com o objetivo de compartilhar
informaes sobre o projeto e priorizar suas
atividades.

Trata-se de um dilogo entre todos os membros da

equipe, se possvel envolvendo tambm a presena
do cliente.

Refatorao

Metfora

Metforas so usadas frequentemente

durante o desenvolvimento de sistemas, na
medida em que os desenvolvedores criam
elementos dentro do computador para simular
outros que existem regularmente fora dele, no
mundo fsico.

Documentao

Documentao
Por que documentar?
Permitir que rapidamente um desenvolvedor possa criar ou manter um
cdigo.

At que ponto documentar?

O suficiente para apoiar o cdigo: testes de unidade, testes de aceitao e
outras documentaes.

Quando documentar?
Prximo da implementao (antes ou depois), para que o negcio no mude
enquanto se documenta.
Dentro da mesma iterao.

Equipe

Equipe
Gerente de Projeto

responsvel pelos assuntos administrativos

do projetos. Libera a equipe de questes no
ligadas ao desenvolvimento. Administra o
relacionamento com o cliente, assegurando
que o mesmo participe ativamente do
desenvolvimento.

Equipe
Coach

o responsvel tcnico pelo projeto.

Orienta a equipe nas boas prticas do XP.
Pode atuar na implementao, mas a sua
funo principal assegurar o bom
funcionamento do processo e buscar formas de
melhor-lo continuamente.

Equipe
Analista de Teste

responsvel por ajudar o cliente a escrever

os testes de aceitao.
Quando o teste no automtico, ele deve
executar os testes diversas vezes ao longo das
iteraes.

Equipe
Redator Tcnico

Ajuda a equipe a documentar o sistema.

A equipe pode fazer documentao, mas a preocupao
principal deve ser o cdigo.
O redator quem faz a maior parte do trabalho de
documentao.

Equipe
Desenvolvedor
a pessoa que analisa, projeta e codifica.

No existe distino entre analista, projetista

e programadores.
O desenvolvedor faz estes diferentes papis
em diversos momentos do projeto.

Quando no usar XP
Sistemas de premiao individuais

Contratos de escopo fechado

Clientes que fazem questo de um grande nmero de artefatos

Empresas onde os layouts de escritrios so fixos

Quando no usar XP
Quando no se tem apoio das pessoas que decidem

Equipes grandes e espalhadas geograficamente

Situaes onde no se tem controle sobre o cdigo (sistemas

legados)

Situaes onde o feedback demorado

Como implantar

Como implantar
Uma prtica de cada vez
Enfatize o problema mais importante

Dificuldades culturais
Deixar algum mexer no seu cdigo
Trabalhar em pares

Dificuldades devido a mudana de hbitos

Manter as coisas simples (e no tentar prever o futuro escrevendo "design flexvel")
Jogar fora cdigo desnecessrio
Escrever testes antes de codificar
Refatorar com frequncia (vencer o medo)

XP - Extreme Programming

Obrigado!