eXtreme Programming
© Alexandre Vasconcelos
[email protected]
[email protected]
Centro de Informática da UFPE/
Qualiti Software Processes
1/44
O surgimento de 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 eXtreme Programming
2/44
O que é eXtreme Programming?


Metodologia ágil (leve) mais utilizada na
atualidade
Desenvolvida para:
 Equipes
médias e pequenas (2 a 12 pessoas)
 Requisitos vagos e em constante evolução

Possui um conjunto de valores e práticas para
nortear o desenvolvimento de software
3/44
Estudo da palavra
Extreme
Programming
Aplicação das boas práticas de
desenvolvimento de software
levadas ao extremo
Foca em Código
4/44
Manifesto ágil

Valorização de:





Principais preocupações:




Indivíduos e interação MAIS QUE processos e ferramentas
Software em funcionamento MAIS QUE documentação
abrangente
Colaboração com o cliente MAIS QUE negociação de
contratos
Responder a mudanças MAIS QUE seguir um plano
Entregar funcionalidades para o cliente de forma rápida
Procuram usar o mínimo de documentação possível
Realizam projeto simples sem se preocupar em antecipar
funcionalidades
WebSite: http://www.agilemanifesto.org/
5/44
Foco na satisfação do cliente

Desenvolver o
que o cliente
precisa no
momento que
é necessário
6/44
Princípios básicos

Comunicação
Os membros da equipe (clientes, gerentes,
programadores) devem interagir ao máximo
pessoalmente.
 Devem trabalhar na mesma sala, conversar
pessoalmente ou através de chats, etc.


Simplicidade
Projeto do SW é simplificado continuamente
 Processo adaptado, caso algo não esteja funcionando

7/44
Princípios básicos

Feedback
 Cliente
está sempre participando do
desenvolvimento do sistema
 Testes de unidade e de aceitação fornecem
feedback sobre o sistema
 Oportunidades e problemas são identificados o
mais rápido possível
8/44
Princípios básicos

Coragem
 Indicar
problemas no projeto, parar quando está
cansado, pedir ajuda quando necessário
 Simplificar código que está funcionado, dizer ao
cliente que não será possível implementar um
requisito no prazo estimado
 Seguir o XP como deve ser
9/44
Práticas e Regras de XP: Planejamento

Estórias de uso
 Usadas
como requisitos do sistema
 Mesmo propósito dos casos de uso (de UML),
porém menores e mais simples
 Escritos na linguagem do cliente com o mínimo
de detalhes para a estimativa de custos
10/44
Práticas e Regras de XP: Planejamento

Iterações
 Desenvolvimento
dividido em iterações
 Possuem duração entre 1 e 3 semanas
 Funcionalidades são entregues no final de cada
iteração
 Prazos devem ser levados a sério, negocie o
escopo se for necessário
11/44
Práticas e Regras de XP: Planejamento

Medida da velocidade de projeto
 Indica
a produtividade da equipe no projeto
 Razão entre o que foi produzido e o que foi
estimado a cada iteração
 Pode ser medido durante uma iteração
 Variações dramáticas em mais de uma iteração
sugerem renegociação de prazo e escopo das
versões
12/44
Práticas e Regras de XP: Planejamento

Jogo do planejamento
 Planejamento
de versões (Releases)
 No
início do projeto especifica-se que estórias de
uso serão implementadas em cada versão
 Define-se as datas de liberação das versões
• Geralmente de 2 a 3 meses.
 Uma
release possui diversas iterações curtas
13/44
Práticas e Regras de XP: Planejamento

Jogo do planejamento

Planejamento das iterações:

Feito no início de cada iteração
• Estórias de uso são escolhidas de acordo com a importância
pro cliente e o risco pro projeto
• Estórias são divididas em tarefas de 1 a 3 dias
• Tarefas são distribuídas entre programadores e estimadas
pelos próprios executores
– Estimativa preferencialmente baseada no passado
– Leva-se em conta a programação em pares

Estórias são adicionadas ou removidas para completar o
tempo da iteração
14/44
Práticas e Regras de XP: Planejamento

Versões freqüentes e pequenas
 Funcionalidades
implementadas são
rapidamente entregues ao cliente
 Permite um feedback mais rápido do cliente
reduzindo o impacto de mudanças de requisitos
 Versão pode ter inclusive uma única iteração
15/44
Práticas e Regras de XP: Planejamento

Reuniões rápidas (stand-up meeting)
 Faz
a comunicação entre toda a equipe para
comunicar problemas, soluções, etc.
 Reunião feita em pé com poucos minutos de
fala para cada integrante
16/44
Práticas e Regras de XP: Projeto

Simplicidade
 Projetos
simples tomam menos tempo que os
complexos
 Evitar generalizações e abstrações
desnecessárias no momento
 Um bom projeto deve conter o menor número
possível de classes e métodos
 É mais rápido e barato
 Requisitos
mudam freqüentemente
17/44
Práticas e Regras de XP: Projeto

Metáfora
Tem a intenção de oferecer uma visão geral do
sistema, em um formato simples, que possa ser
compartilhada por clientes e programadores.
 Faz-se uma analogia entre o sistema e um outro
sistema não necessariamente de software que seja de
fácil entendimento para todos
 Corresponde mais ou menos à Arquitetura do sistema
 Não tem sido muito usada

18/44
Práticas e Regras de XP: Projeto

Criar spike solutions para reduzir riscos
 Programas
muito simples (protótipos) utilizados
para verificar o uso determinadas soluções e
tecnologias
 Utilizados para reduzir os riscos técnicos do
projeto ou validar as estimativas realizadas
19/44
Práticas e Regras de XP: Projeto

Não adicionar funcionalidades
antecipadamente
 Requisitos
mudam rapidamente
 Mantém o código limpo de adivinhações sobre o
que pode ser usado no futuro
 Mantém a produtividade
20/44
Práticas e Regras de XP: Projeto

O cliente está sempre disponível
 Não
deve só ajudar a equipe de
desenvolvimento
 Deve ser parte da equipe
 Comunicação com o cliente é feita em todas as
fases de um projeto XP
 Estórias
de uso, planejamento de versões,
feedback do sistema, testes de aceitação, etc.
21/44
Práticas e Regras de XP: Codificação

Programação em pares
 Duas
pessoas programando em um mesmo
computador pensam melhor que uma
 Revezamento: um programa enquanto o outro
projeta e faz revisão on-line do código digitado
 Ganho de qualidade compensa o uso de duplas
 Auxilia a difusão de conhecimento
22/44
Práticas e Regras de XP: Codificação

Rotação de pares de programadores
 Ajuda
ainda mais a eliminar as pessoas
consideradas “ilhas de conhecimento”
 Cada um da equipe passa a conhecer todas as
partes do sistema
 Os pares devem sempre ser encorajados a
trabalhar em partes do sistema desconhecidas
por eles
23/44
Práticas e Regras de XP: Codificação

Propriedade coletiva do código
 Todos
são responsáveis por todo código
 Permite que pessoas forneçam idéias para toda
parte do sistema
 Diminui o risco de possuir pessoas
insubstituíveis no projeto
24/44
Práticas e Regras de XP: Codificação

Código tem sempre que seguir um padrão
 Mantém
o código consistente e uniforme
 Facilita a leitura e entendimento por outros
programadores
25/44
Práticas e Regras de XP: Codificação

40 horas semanais
 Não
se deve trabalhar mais de 60 h por 2 ou
mais semanas consecutivas
 Horas extras não remuneradas prejudicam
motivação da equipe
 A insatisfação de se trabalhar horas extras pode
contribuir para a queda de qualidade e aumento
de defeitos
 Ao invés disto, modifique o escopo ou o prazo
do projeto
26/44
Práticas e Regras de XP: Codificação

Integração contínua
 Módulos
do sistema são integrados diversas
vezes ao dia
 Todos os testes de unidade definidos são
executados
 Identificação rápida de bugs inseridos
 Programador
sabe que trechos de código foram
alterados nas últimas horas
27/44
Práticas e Regras de XP: Codificação

Fazer refactoring sempre que possível
 Reestruturação
sem acrescentar funcionalidade
 Remove redundâncias e melhora a qualidade do
projeto
 Retira códigos não utilizados
 Testes unitários “garantem” que código mantém
mesmo comportamento
28/44
Práticas e Regras de XP: Testes

Testes unitários
 Teste
das menores unidades (classes, métodos,
...)
 Identifica bugs no código
 Protege o código de manutenções indevidas
 De responsabilidade do programador. São
automatizados (JUnit)
 Automação dos testes paga o custo da criação
dos testes
29/44
Práticas e Regras de XP: Testes

Testes unitários são escritos para detectar bugs
identificados
 Criação
do teste unitário que identifique o bug
antes de corrigi-lo
 Bugs têm tendência de ressurgir posteriormente
30/44
Práticas e Regras de XP: Testes

Testes antes da codificação
 Limita
o escopo da solução a ser implementada
 Serve de especificação do código testado
 Facilita o entendimento do código a ser criado
 Garante que os testes vão ser criados
31/44
Práticas e Regras de XP: Testes

Execução periódica de testes de aceitação
(testes funcionais)
 Procuram
testar uma funcionalidade como um
todo (Ex: Venda).
 Criados a partir das estórias de uso a serem
implementadas na iteração
 Clientes verificam a corretude dos testes
escritos
 Devem ser automatizados e regressivos
32/44
Dependência entre práticas

Algumas práticas possuem inter-dependências
 Refactoring:
Testes unitários
 Rotação de pessoas: programação em pares
 Propriedade coletiva de código: refactoring,
testes unitários, integração contínua
 40h semanais: planejamento junto ao cliente
 Etc.
33/44
Ciclo de Vida em XP

Um projeto XP passa por algumas fases
durante seu ciclo de vida
 Fase
de exploração: Anterior à construção do
sistema. Visa verificar a viabilidade do sistema e
experimentar possíveis soluções
 Fase de planejamento inicial: Visa definir as
estórias e fechar com cliente o escopo e data do
primeiro Release
34/44
Ciclo de Vida XP


Fase de iterações do release: Em uma iteração
algumas estórias são implementadas.
Atividades de uma iteração: escrita dos casos
de testes  projeto e refatoramento 
codificação  realização dos testes 
integração.
Fase de produção: O sistema é posto em
operação em um ambiente que simula o
ambiente de produção para verificar
performance e desempenho.
35/44
Ciclo de Vida XP


Fase de manutenção: XP considera que
manutenção faz parte da sua natureza e suas
práticas consideram um ambiente onde
alterações são constantes
Fase de morte: Término de um projeto XP
36/44
Papéis envolvidos em XP



Treinador: Preocupa-se com a execução técnica e
evolução do processo. Possui conhecimentos de XP
e orienta a equipe.
Rastreador: Coleta dados sobre o andamento do
projeto e a sua conformidade com o planejamento
feito para as iterações e release.
Programador: Escreve o código e os casos de teste
unitários sempre em pares. É responsável por
estimar o tempo para a implementação das estórias.
37/44
Papéis envolvidos em XP


Cliente: Responsável por escrever as estórias
junto com os programadores e priorizá-las.
Também ajuda na escrita dos casos de teste
funcionais.
Testador: Ajuda o cliente na definição e escrita
dos testes funcionais. Ele não precisa ser uma
pessoa com apenas essa função, pode
desempenhar também o papel de
programador.
38/44
Exemplo de uma Iteração em XP
•Planejar Iteração
•Detalhar Estórias(Criar Tarefas)
•Descrever Prioridades
•Estimar Tarefas
–Estimar por Comparação
–Estimar por Intuição
–Spike Soluctions
•Distribuir Estórias
•Construir Testes de Aceitação
•Programar
–Fazer Teste Unitário
–Implementar
•Stand-up meetings
•Executar Testes de Aceitação
•Disponibilizar Iteração
39/44
Xplanner


http://www.xplanner.org
Ferramenta que permite
o planejamento e
acompanhamento de
equipes de
desenvolvimento XP.
40/44
Ferramenta Xplanner - Tela da estória
41/44
Ferramenta Xplanner - Tela da iteração
42/44
Quando não se deve usar XP

Possíveis barreiras para o sucesso de um projeto XP
Cultura: Quando a empresa possui uma cultura
fortemente tradicional com ênfase em muita
documentação, modelagem, etc.
 Tamanho da equipe: Beck considera que a equipe
deve ser pequena (até 12 pessoas).
 Espaço físico: O local de trabalho deve servir para
aproximar a equipe e facilitar a comunicação.
 Cliente: Em XP o cliente ou alguém que o represente
deve trabalhar junto à equipe.

43/44
eXtreme Programming
© Alexandre Vasconcelos
[email protected]
[email protected]
Centro de Informática da UFPE/
Qualiti Software Processes
44/44