Visão Geral sobre o XP –
eXtreme Programming
Alexandre Monteiro
1/30
Manifesto Ágil [1/5]



Assinado por 17 desenvolvedores com
reconhecimento mundial em Utah em
fevereiro/2001.
Declaração de 4 valores
http://www.agilemanifesto.org/
2/30
Manifesto Ágil [2/2]
“Estamos evidenciando maneiras melhores de desenvolver
software fazendo-o nós mesmos e ajudando outros a fazê-lo.
Através desse trabalho, passamos a entender que:




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.
Ou seja, mesmo tendo valor os itens à direita, valorizamos
mais os itens à esquerda. “
3/30
Metodologias Ágeis






eXtreme Programming
FDD
Lean Software Development
Cristal Family
Scrum
(...)
4/30
O surgimento do XP

Em meados de 1990, Kent Beck procurou
formas mais simples e eficientes de
desenvolver software


Identificou o que tornava simples e o que
dificultava o desenvolvimento de software
Em Março de 1996, ele iniciou um projeto
com novos conceitos que resultaram na
metodologia XP - eXtreme Programming
5/30
O que é eXtreme Programming?
“Trata-se de uma metodologia ágil para
equipes pequenas e médias desenvolvendo
software com requisitos vagos e em
constante mudança”
Kent Beck
6/30
Programando ao Extremo

Levar todas as boas práticas ao Extremo




Se testar é bom, vamos testar toda hora!!
Se projetar é bom, vamos fazer disso parte do
trabalho diário de cada pessoa!
Se integrar é bom, vamos integrar a maior
quantidade de vezes possível!
Se iterações curtas é bom, vamos deixar as
iterações realmente curtas!
7/30
Mudanças sempre ocorrem



Clientes não sabem o que querem no
início
Desenvolvedores não sabem qual a
melhor maneira de fazer o software
no início
Medo da mudança trava o
desenvolvimento
8/30
Avanços

Nos últimos 30 anos...

Melhoria nos processos


Melhorias nas ferramentas


Iterativo Incremental
IDEs, automação...
Maior abstração no desenvolvimento



Orientação a Objetos
Orientação a Aspectos
Orientação a ...
9/30
Mudar não é tão caro
custo
Requisitos
Análise
Projeto
Implementação
Testes
Produção
t
10/30
XP inclui...





Comunicação
Coragem
Feedback
Simplicidade
Respeito
11/30
Comunicação



Soluções de problemas normalmente
já são conhecidas...
O problema é a solução chegar a quem
precisa
Comunicação face a face é a maneira
mais rápida de “espalhar”
conhecimento
12/30
Coragem



Extreme Programming é novo e
diferente
Atitude é mais importante que
processo
Coragem pra dizer a verdade, para
recomeçar do zero, para inovar
13/30
Feedback


Feedback <-> Comunicação
Feedback aumenta aprendizado e
produtividade
14/30
Simplicidade



Regra geral
Pensar sempre : “ O que pode ser
feito que seja o mais simples que
funciona?”
Simplicidade normalmente gera mais
valor
Geração de
valor
overhead
Simplicidade
15/30
Respeito



Coragem, Feedback, Simplicidade,
Comunicação...
Respeito é necessário para tirar o
máximo desses valores
Respeito pelo próximo


Feedback, Comunicação
Respeito por si mesmo

Coragem, Simplicidade
16/30
Boas Práticas

Test First Design

Refactoring

Stand-up Meeting

Continuous
Integration
A criação de testes leva em conta não o
tempo ganho com a criação dos
mesmos antes da codificação, mas
conhecer previamente as possíveis
falhas do seu sistema.
A reconstrução baseia-se na remoção
de redundância, eliminação de
funcionalidades inúteis, e reconstrução
de projetos obsoletos.
Reuniões rápidas e
diárias com a equipe
Os diversos módulos do
software são integrados
diversas vezes por dia e todos
os testes unitários são
executados. O código não
passa até obter sucesso em
100% dos testes unitários.
17/30
Boas Práticas




Pair Programming
Todo código de produção é
desenvolvido por duas pessoas
trabalhando com o mesmo teclado, o
mesmo mouse e o mesmo monitor.
Move People
Around
As duplas de programação são
revezadas em média a cada 2h.
Collective Code
Ownership
E equipe como um todo é responsável
por cada arquivo de código. Não é
preciso pedir autorização para alterar
qualquer arquivo.
Coding Standards
Todo código é desenvolvido
seguindo um padrão.
18/30
Boas Práticas



The Customer is
Always Available
Small Release
Simple Design
O cliente está sempre disponível
para resolver dúvidas, alterar o
escopo de uma iteração e definir
prioridades.
O software é entregue em pequenas
versões para que o cliente possa
obter o seu ganho o mais cedo
possível e para minimizar riscos.
O código está, a qualquer
momento, na forma mais
simples que passe todos os
testes.
19/30
Boas Práticas



40-Hour Week
On-Site Customer
Acceptance Tests
Cada programador trabalha
40 horas por semana.
Se o horário for flexível,
deve-se respeitar o horário do
par naquele período, senão
enquanto um trabalha o outro
vai pra casa .
Ter um papel de cliente
na equipe XP em
tempo integral para
responder as perguntas
São definidos pelo
usuário e são os critérios
de aceitação do software.
20/30
Boas Práticas

System Metaphor
Ajuda a manter todos os
desenvolvedores em sintonia
com o projeto quando dando
nomes a objetos ou classes.
A Fábrica
A idéia é que exista um objeto "produto" que sofre várias
modificações ao longo da "linha de montagem", onde outros
objetos trabalham sobre o produto.
A vantagem é que é simples adicionar "máquinas novas" a
linha de montagem.
O Correio
Quando o "produto" precisa passar pela mão de várias pessoas, às vezes
para conhecimento, aprovação ou modificação do conteúdo. Podem existir
modificações feitas pelo sistema, nesse caso, existem "destinatários
virtuais" que recebem a mensagem, analisam e despacham para quem
deve. A diferença básica do Correio para a Fábrica é que ele não segue
uma linha.
Turista
O objeto é um "turista", o Servlet e o Banco são hospedagens, os
dados são a bagagem, o objeto que tira os dados do "turista" e coloca
ou no Servlet (em XML) ou no Banco são "carregadores de
bagagem". Quando a "bagagem" está guardada no hotel "Banco de
Dados" o "turista" recebe um ticket da bagagem para poder pegar ela
depois (o Identificador único da tabela).
21/30
Papéis no XP
Big Boss / XpManager
Deve fazer:
• Agendar reuniões;
• Escrever atas;
• Manter o XP Tracker informado dos
acontecimentos das reuniões
Não deve fazer:
•Deixar que problemas externos interfiram no
desenvolvimento
•Dizer quando as coisas devem acontecer
•Dizer às pessoas o que fazer
•Cobrar das pessoas
22/30
Papéis no XP
Xp Gold Owner (Cliente - O proprietário do
ouro)
É quem paga pelo sistema, geralmente o dono da empresa.
Xp Goal Donor
Deve fazer:
• Escrever User Stories
• Definir prioridades
• Definir testes de aceitação
Não deve fazer:
• Implementar código
• Definir quanto tempo uma
tarefa leva para ser feita
• Validar testes de aceitação
• Esclarecer dúvidas
23/30
Papéis no XP
Xp Coach
Coordenadores
Xp Tracker
Responsável pela negociação
com o cliente quanto ao
escopo e pela coordenação
do Planning Game.
Deve fazer:
• Coletar métricas
• Manter todos informados
do que está acontecendo
• Definir testes de aceitação
• Tomar atitudes diante de
problemas
• Sugerir sessões de CRC
(Class, Responsabilities ,
Collaboration)
24/30
Papéis no XP
Programador
(Driver/Partner)
Deve fazer:
• Estimar prazos de User Stories
• Implementar código de produção
• Trabalhar em par
• Fazer refactoring
• Corrigir bugs
Não deve fazer:
• Criar/Alterar novas funcionalidades
• Escrever testes de aceitação
25/30
Um Projeto XP
26/30
27/30
Planejamento das iterações





Divida o projeto em etapas de 1 ou 2 semanas;
Considere prazos fixos e escolha um dia da semana
para integrações e entregas; (segunda ou sextafeira);
Planeje reuniões diárias para acompanhar a
evolução do projeto (“stand-up”, meeting matinal);
As iterações serão as unidades de referência para
fazer estimativas;
Entre no jogo para entregar um produto a cada
iteração.
28/30
Conclusão

Extreme Programming



Mudança é algo normal


Atitude
Disciplina
Aceitar, não fugir
Conjunto de boas práticas
29/30
Referências

XPRecife – Grupo de Estudos de
Métodos Ágeis de Recife


www.cin.ufpe.br/~xprecife
Xispê – Portal Brasileiro de XP

www.xispe.com.br
30/30