Extreme

Programming XP
GPS Gesto de Projetos de Software
Luiz Eduardo, Luis Fernando, Smith Eduardo, Gleyton Lima

Agenda

Introduo
Valores e princpios
Papis
Fases
Prticas
Concluso

Introduo
Extreme Programming: O que ?
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. 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
Histrico

Concebido ao final dcada de 80

Kent Beck e Ward Cunningham
Tektronix
Cartes CRC (Class-responsibilitycollaboration) e design patterns
XP foi usado pela primeira vez num
sistema de Folha de Pagamento

Valores do XP

Comunicao
Simplicidade
Feedback
Coragem
Respeito

Valores do XP
Comunicao
Dilogos so mais eficazes que
videoconferncias, que so melhores que
telefonemas, que so mais expressivos
que emails e assim sucessivamente.
Conscientes
disso,
aqueles
que
trabalham com XP priorizam o uso do
dilogo presencial, com o objetivo de
garantir que todas as partes envolvidas
em um projeto tenham a chance de se
compreender da melhor maneira possvel.

Valores do XP
Simplicidade
Estudos mostram que 64% das
funcionalidades
tipicamente
produzidas no so utilizadas.
Isso representa mais da
metade delas e, possivelmente,
bem mais da metade do tempo
e dos gastos de um projeto
tpico de software.

Valores do XP
Feedback
Projetos XP estabelecem formas de
encurtar ao mximo a defasagem de
tempo entre o momento em que uma
ao executada e o seu resultado
observado. Assim, por exemplo,
desenvolvedores procuram entregar
novas funcionalidades no menor prazo
possvel,
para
que
o
cliente
compreenda
rapidamente
as
conseqncias daquilo que pediu.

Valores do XP
Coragem
Equipes XP acreditam que errar
natural e quebrar o que vinha
funcionando
pode
acontecer
eventualmente. necessrio ter
coragem para lidar com esse risco, o
que em XP se traduz em confiana nos
seus mecanismos de proteo, tais
como desenvolvimento orientado a
testes, programao em par e
integrao contnua.

Valores do XP
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. Se
ele no existir em um projeto, no 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.

Princpios do XP

Ser mais humano

Interesses Econmicos
Benefcio Mtuo
Reutilizao
Melhoria Contnua
Diversidade
Reflexo

Fluxo
Oportunidade
Redundncia
Fracasso
Qualidade
Pequenos passos
Aceitao de Responsabilidade

Princpios do XP
Ser mais humano
Normalmente o desenvolvimento de
software no valoriza as necessidades
bsicas do ser humano, inclundo suas
fraquezas e foras. Isto gera custos
extras. O correto seria
valorizar:
Segurana
Sucesso
Identificao
Crescimento
Intimidade

Princpios do XP
Interesses Econmicos
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.
Em economia, sabe-se que o valor do dinheiro varia ao longo
do tempo. Por exemplo, R$ 1,00 hoje vale mais que R$ 1,00
amanh. Por essa razo, ao desenvolvermos software
devemos nos preocupar em implementar o mais cedo
possvel as funcionalidades que puderem gerar maior retorno
financeiro. Ao mesmo tempo, devemos organizar o
desenvolvimento para que dinheiro seja aplicado ao projeto
lentamente, um pouquinho de cada vez.

Princpios do XP
Benefcio Mtuo
As prticas do XP so estruturadas de modo a serem
mutuamente benficas para todos os envolvidos em um
projeto de software. Programao em par, por exemplo,
beneficia os programadores de inmeras formas. Mas,
tambm beneficia os clientes, porque costuma ser raro
encontrar bugs em funcionalidades implementadas em par.
Gerentes, por sua vez, tambm se beneficiam porque a
programao em par ajuda a disseminar conhecimento na
equipe, o que permite que ela supere mais facilmente a
ausncia de um de seus membros enquanto estiver de frias,
por exemplo.

Princpios do XP
Reutilizao
Quando equipes XP encontram solues
que funcionem em um contexto, tambm
procuram adot-las em outros, mesmo
que em escalas diferentes. Por exemplo,
o ritmo bsico de desenvolvimento em
XP escrever um teste que falha e
ento faz-lo funcionar. Esse ritmo opera
de forma semelhante em diferentes
escalas.

Princpios do XP
Melhoria Contnua
"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. Em , no nos preocupamos em
construir o software perfeito, nem o design
perfeito, nem o processo perfeito, mas sim
em aperfeioar esses e outros aspectos dos
projetos continuamente.

Princpios do XP
Diversidade
Desenvolver software uma atividade
complexa que demanda habilidades das mais
diversas para ser bem sucedida. Equipes onde
todos so iguais ficam limitadas a pontos de
vistas semelhantes e perdem a oportunidade
de explorar idias diferentes e inovadoras. Em
software, diferentes abordagens para um
mesmo problema podem implicar em enormes
diferenas
no
tempo
e
custo
de
implementao da soluo.

Princpios do XP
Reflexo
Boas equipes no apenas fazem seu trabalho,
mas tambm pensam sobre como esto
trabalhando e por que esto trabalhando. Elas
analisam o porqu de terem tido sucesso ou
falhado. Elas no tentam esconder seus erros,
mas os expem e aprendem com eles.

Princpios do XP
Fluxo
As prticas do XP esto baseadas num fluxo
contnuo de atividades ao invs de fases
discretas. Numa abordagem clssica, o software
liberado em grandes blocos de funcionalidades
com grandes implantaes. Nesta abordagem a
frustrao e o fracasso podem ser grandes, j
que o software liberado e integrado menos
frequentemente. O pouco feedback torna o
problema ainda pior, gerando uma tendncia de
fazer implantaes cada vez maiores e menos
frequentes.

Princpios do XP
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 do XP
Redundncia
Sim, 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 do XP
Fracasso
No h dvida, falhe! Experimentar
diferentes hipteses e falhar em
algumas
delas
prov
novos
conhecimentos.
Pode
parecer
desperdcio, mas quando se trata de
aprendizado, freqentemente a forma
mais rpida e rica de aprender
simplesmente tentar algo novo, mesmo
que mais tarde tenhamos que voltar
atrs e explorar outras alternativas.

Princpios do XP
Qualidade
Extreme Programming gera valor rapidamente e evita desperdcios ao mximo.
Software de m qualidade representa uma enorme perda, pois causa:
Perdas para o negcio
Insatisfao do cliente
Conflito entre cliente e desenvolvedores
Desconfiana
Ansiedade
Relacionamentos desgastados
Perda de tempo corrigindo defeitos
Dificuldade para adaptar o software a novas necessidades de maneira
segura
Equipes XP trabalham para criar software de alta qualidade. No se trata de
qualidade suficiente. O objetivo altssima qualidade para o software e nada
menos que isso. Por que? Porque mais satisfatrio e econmico fazer
software dessa forma.

Princpios do XP
Pequenos passos
Implicam em fazer apenas pequenas mudanas
de cada vez. Por exemplo, ao invs de escrever
todo o contedo de uma classe de uma vez,
podemos nos concentrar em um mtodo de
cada vez. Para cada um, escrevemos um teste,
vemos ele falhar, implementamos o mtodo,
vemos o teste funcionar, refatoramos se
necessrio, rodamos o teste novamente e, s
quando tudo est funcionando, passamos para
o mtodo seguinte.

Princpios do XP
Aceitao de Responsabilidades
Responsabilidade no pode ser atribuda; ela s
pode ser aceita. Se algum tenta te dar uma
responsabilidade, s voc pode decidir se
responsvel ou no.
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.

Papeis

Testador
Designer de iterao
Arquiteto
Gerente de projeto
Gerente de produto
Executivo
Documentador tcnico
Usurio
Programador

Usurio

Ajuda a escrever as estrias e a selecion-las para desenvolvimento.

recomendado que o usurio tenha bastante conhecimento e/ou experincia com sistemas
similares ao que est sendo desenvolvido.

Testador
No XP aconselhvel que se crie uma infraestrutura de testes ao invs de especificaes e muitas
documentaes.

Auxiliam os clientes a escrever os casos de testes

Criam as rotinas de testes
Aconselham os programadores quanto a tcnicas de testes

Designer de iterao
Trabalham juntamente com o cliente ajudando a escrever as estrias e no refinamento da interface do
produto, ao longo da vida do projeto.

Escolhem as metforas que sero usadas na concepo do sistema.

Avaliam o uso das partes que j foram implantadas para identificar novas estrias.

(Obs:. Metforas: Criar comparaes e analogias com o assunto que est em questo, as pessoas passaro a entender deste assunto de uma
forma muito mais rpida e possivelmente no a esquecero mais. Este tipo de artifcio chamado de metfora no XP).

Arquiteto

Buscam oportunidades de refactoring e executam

Escrevem testes de sistema que estressam a arquitetura
Implementam estrias
Particiona o sistema em pequenas partes, que possam ser expandidas isoladamente no futuro.

(Obs:. Refactoring - Seria uma forma de reescrever um codigo/funcionalidade,sem que esta alterao mude o comportamento do cdigo em
questo, afim de deixa-lo mais legivel e simples).

Gerente de Projeto

Facilita a comunicao dentro da equipe

Coordena a comunicao com clientes, fornecedores e o restante da empresa.
Mantem todos informados sobre as informaes do projeto, que mudam com muita frequncia.

Gerente de Produto
Priorizam as estrias pelas regras de negocio, no por razes tcnicas, com o objetivo de que o
sistema seja usual desde a primeira iterao.

priorizam estorias da semana e trimestre

esclarece duvidas dos programadores

Executivo

Encoraja e passa confiana a equipe

Mantem o foco nos objetivos, mesmo quando h reduo ou aumento de escopo, e a despeito
de problemas que possam vir a existir
Representa a equipe perante o resto da empresa

Documentador tcnico

Elabora e mantem toda a documentao necessria para o trabalho de programao.

Busca um feedback sobre as features o mais breve possvel
Tem uma relao estreita com o cliente

Programador

Estima estorias e tarefas

Decompe as estorias em tarefas
Escrevem rotinas de teste unitrios e cdigos-fontes para implementar as features
Melhoram o design do sistema gradualmente

Fases
Ciclo de vida de um projeto XP
Um projeto XP atravessa algumas fases durante o seu ciclo de vida. Essas fases so compostas de
vrias tarefas que so executadas.
Um projeto XP passa pelas seguintes fases: explorao, planejamento inicial, iteraes do
release, produo, manuteno e morte.

Fases - Explorao

anterior construo do sistema;

Investigaes de possveis solues so feitas e verifica-se a viabilidade de tais solues;
Os programadores elaboram possveis arquiteturas;
Tenta-se visualizar como o sistema funcionar considerando o ambiente tecnolgico
sugere-se que seja gasto no mximo duas semanas nessa fase

Fases - Planejamento inicial

Usada para que os clientes concordem em uma data para lanamento do primeiro release
Definidas as estrias do usurio
Escolhidas as estrias de maior valor para serem implementadas nas iteraes

Fases - Iteraes do release

So escritos os casos de teste funcionais e de unidade

Escrita dos casos de testes;
Projeto e refatoramento;
Codificao;
Realizao dos testes; e integrao.

Fases - Produo

colocado para funcionar em um ambiente que simula o ambiente de produo

Pode-se fazer testes de aceitao adicionais para simular o funcionamento real do sistema no
ambiente alvo.

Fases - Manuteno

uma caracterstica inerente a um projeto XP

Em XP voc est simultaneamente produzindo novas funcionalidades, mantendo o sistema
existente rodando, incorporando novas pessoas na equipe e melhorando o cdigo.

Fases - Morte
Equivale ao trmino de um projeto XP

Prticas
Categorias:

Bsicas
Complementares

As bsicas deveriam ser implementadas em qualquer projeto XP e as Demais

poderiam ser consideradas opcionais.

Lista das Prticas Bsicas

Estrias;
Pequenas releases;
Refactoring;
Programao em Par;
Cdigo Compartilhado;
Integrao Continua;
Envolvimento Real dos Clientes;
Padro de Cdificao;
Ciclo semanal de 40 Horas
Mtafora do Sistema;

Prtica Bsica 1- Estrias - Part 1

As estrias representam unidades de funcionalidade da forma como so
percebida pelos usurios.
Geralmente as estrias so escritas pelos prprios clientes, caso no seja
possvel o prprio desenvolvedores devem escrev-las e depois valid-las e
depois valida com o cliente.
Uma Estria contm:

Nome curto e objetivo;

Descrio relativamente detalhada
na forma de um texto ou grfico;
Documentos de aceitao;
Story Points

Prtica Bsica 1- Estrias - Part 2

Trabalho realizado em cima das Estrias:

Estimativas;
Restimativas;
Descomposio de Estrias;
Planejamento;

Diretrizes:
Planejar para agora
Responsabilidade
Dependncias
Simplicidade no Planejamento
Priorizao

Prtica Bsica 2-Pequenas Releases

No XP o software desenvolvido iterativamente em pequenas releases que
adicionam features ao sistema e permite um feedback rpido.
As releases dever menor tamanho possivel e que ainda possam produzir
algum valor para o negcio.
Planejamento da pequenas releases:

Plano de release;
Pode conter 2 ou mais iteraes;
Durao de 3 a 12 meses de durao;
Iterao de uma semana;
Projeto tcnico incremental;
Teste antecipado

Prtica Bsica 3-Refactoring

Implica na melhoria contnua do cdigo-fonte, sem alterar seu comportamento.

Prat. B. 4-Programao em Par

A prtica mais popular do xp(E mais polmica).
Objetivos:

Ajudar programador ajuda o outro manter o foco na tarefa.

Fazer brainstorm.
Clarear as ideias.
Quando um no souber mais o que fazer, o outro toma o controle.
Ajudar a no perder de vista as prticas e valores.
Disseminar conhecimento.
Cdigo dinamicamente revisado.

Exemplos em imagens? prxima pgina ...

Prtica B. 4-Programao em Par

Ser que funciona mesmo? ...

Prat. B. 4-Programao em Par

Prat. B. 5- Cdigo Compartilhado

No XP qualquer membro da equipe pode melhorar parte do sistema.

Prat. B. 6 - Integrao Continua

A cada atividade concluda, o resultado deve ser integrado na verso corrente.

Pra.B. 7-Envolvimento Real dos Clientes

Colocar as pessoas com as necessidades de ngocio em contato direto com os desenvolvedores
facilita a compreenso dos requisitos.
Feedback rpido.

Pra.B. 8 - Padro

de codificao

Quanto mais pessoas trabalham juntas no cdigo-fonte, desenvolvendo um cdigo novo, fazendo
mudanas e refactoring, mais importante ser a adoo de um padro comum.
Exemplo:

Nomes de classes
Nomes de interfaces
Nomes de propriedades
Nomes de mtodos
Nome de variveis

Pra.B. 9 - Metfora

do Sistema

Mantm uma viso compartilhado do projeto.

Lista das Prticas Complementares

Proximidade das pessoas;

Trabalho em equipe;
Ambiente Informativo;
Trabalho com energia;
Ciclo mensal;
Descanso(Slack);
Construo em dez minutos;
Continuidade da equipe;
Dividindo equipes;
Anlise de causa e efeito;
Codificao e teste;
Entrega diria;
Contrato de negociao de escopo;

Pra.C. 1- Proximidade das Pessoas

A proximidade entre as pessoas, que so os membros que haja comunicao
com todos os elementos sensorias.
Ambientes mais abertos a chave.

Pra.C. 2- Trabalho em equipe

Em geral, as pessoas tm a necessidade de trabalhar em equipe, elas
precisam de sensao de pertencimento, de que podem contar com outras
pessoas, de identificao, de aprendizado e crescimento mtuo.

Pra.C. 3- Ambiente Informativo

O ambiente de trabalho deve estar relacionado com o trabalho-um observadro
deveria conseguir obter uma boa idia sobre como o projeto est evoluindo
apenas de circulando no ambiente de trabalho

Pra.C. 4- Trabalho com Energia

A equipe deve trabalhar tantas horas quanto puderem enquanto estiverem
sendo produtivas.

Pra.C. 5- Ciclo mensal

No XP a recomendao que o trabalho seja planejado um trimestre de cada
vez.

Identificao de gargalos.
Fazer ajustes
Planejar os temas para o trimestre.
Pegar as estrias de maior valor
Manter o foco na viso

Pra.C. 6- Descanso
Nada como um descanso merecido programado pela equipe.

Pra.C. 6- Construo em dez minuto

O sistema inteiro deve ser construido e totalmente testado em at dez minutos.
Um script que demore mais que dez minutos vai ser utilizado com menis
frequncia.

Pra.C. 7- Continuidade da equipe

Se a equipe efetiva e com bom desempenho devem ser mantidas juntas.

Pra.C. 8- Dividindo equipes

A medida que as equipes aumentam em tamanho, a carga de trabalho
individual de cada membro pode comear a diminuir, gerando ociosidade.

Pra.C. 9- nalise de causa e efeito

Sempre que um defeito for localizado durante o desenvolvimento, tanto a
causa como o efeito devem ser eliminados.
Evitar que a equipe cometa o mesmo erro duas vezes.

Pra.C. 10- Codificao e teste

O teste de software representa uma dupla checagem.
Primeiro, define-se como o sistema vai se comportar ao escrever a rotina de
teste, depois se faz a mesma coisa quando o sistema implementado.

Pra.C. 11- Entrega Diria

Uma nova verso do sistema deve ser colocada em produo todas as noites.
Toda variao entre a verso que est em produo e a que est em
desenvolvimento representa um risco.
Ao fazer mais mudanas na verso de desenvolvimento, sem o feedback dos
usurio, o desenvolvedor corre o risco de avanar na direo errada.

Pra.C. 12- Contrato de Ngociao

Os

contratos de desenvolvimento de software devem fixar o prazo, os custos e

a qualidade, e permitir que o escopo seja detalhado e priorizado durante a
execuo do projeto. O risco pode ser reduzido atravs de uma srie de
pequenos contratos, em vez de um nico.

Bnus -Reunio em P
O que voc fez ontem?
Quais foram os impedimentos?
O que voc vai fazer hoje?

Concluso
Uma das caractersticas mais marcantes do XP
a forte nfase nos testes.
Alm de um processo que aplica desing
evolutivo, que se baseia em refactoring de uma
base cdigo simples a cada iterao.