eXtreme Programming
Eduardo Aranha
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
O que é eXtreme Programming?


Metodologia ágil, leve
Desenvolvido para:
–
–


Equipes médias e pequenas (2 a 12 pessoas)
Requisitos vagos e em constante evolução
Possui um conjunto de valores para nortear
desenvolvimento
Conjunto de práticas mostra sua estrutura
Foco na satisfação do cliente

Desenvolver o
que o cliente
precisa no
momento que
é necessário
Manifesto ágil

Valorização de:
–
–
–
–
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
Princípios básicos

Comunicação
–
–

Programadores comunicam-se frequentemente
entre si e com os clientes
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
funcionado
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
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
Práticas e Regras de XP: Planejamento

Estórias de uso
–
–
–
–
Usados como requisitos do sistema
Mesmo propósito dos casos de uso, porém
menores e mais simples
Escritos na linguagem do cliente com o mínimo
de detalhes para a estimativa de custos
São estimados em “tempo ideal de trabalho”

Deve custar entre 1 e 3 semanas de desenvolvimento
Práticas e Regras de XP: Planejamento


Jogo do planejamento
Planejamento de versões
–
–
–
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
Versões são divididas em iterações
Práticas e Regras de XP: Planejamento

Versões frequentes 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
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
Práticas e Regras de XP: Planejamento

Planejamento de 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 do 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
Práticas e Regras de XP: Planejamento

Planejamento de Iterações (cont.)
–
–
Estórias são adicionadas ou removidas para
completar o tempo da iteração
Usa a velocidade do projeto para transformar
estimativas em tempo ideal para tempo real
Práticas e Regras de XP: Planejamento

Medida da velocidade de projeto
–
–
–
–
Indica a produtividade da equipe no projeto
Razão entre a 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
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
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
É mais rápido e barato

Requisitos mudam frequentemente
Práticas e Regras de XP: Codificação

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.
Práticas e Regras de XP: Projeto

Cartões CRC
–
–
–
Class, Responsibilities, and Collaboration
Descrevem as classes e métodos do sistema
Permitem a simulação da execução do sistema
através da invocação dos métodos das classes
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
Práticas e Regras de XP: Planejamento

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
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
Práticas e Regras de XP: Projeto

Criar spike solutions para reduzir riscos
–
–
Programas muito simples utilizados para verificar
o uso determinadas soluções e tecnologias
Utilizados para reduzir os riscos técnicos do
projeto ou validar as estimativas realizadas
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
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
Práticas e Regras de XP: Codificação

40 horas semanais
–
–
Horas extras não remuneradas prejudicam
motivação da equipe
Ao invés disto, modifique o escopo ou o prazo do
projeto
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
Automação dos testes paga o custo da criação
dos testes
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 corrigí-lo
Bugs tem tendência de ressurgir posteriormente
Práticas e Regras de XP: Codificação

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
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 são executados
Identificação rápida de bugs inseridos

Programador sabe que trechos de código foram
alterados nas últimas horas
Práticas e Regras de XP: Projeto

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
Práticas e Regras de XP: Testes

Execução periódica de testes de aceitação e
publicação de score
–
–
–
Testes de aceitação 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
Dependência entre práticas

Algumas práticas possuem interdependê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.
Modelagem de XP


Site oficial não tem modelo preciso do
processo
Trabalho realizado por Américo no CIn
modela XP usando a meta-linguagem SPEM
Meta-linguagem SPEM




Software Process Engeneering Metamodel
Padrão formal da OMG aprovado em
novembro de 2002
Apoiado pela Rational, IBM, Computer
Associates e outras
Orientado a objetos, utiliza UML como
notação
Principais elementos de SPEM
Principais elementos de SPEM
Diagrama de atividades – Modelagem
de XP (parcial)
Diagrama de atividades – Modelagem
de XP
Diagrama de atividades – Modelagem
de XP
Diagrama de classe – Ponto de vista
estático de XP (parcial)
Fluxo de XP mostrado no site oficial
Fluxo de XP
Fluxo de XP
Fluxo de XP
Papeis

Oficiais
–

Cliente, programador, testador
Outros papéis encontrados em sites sobre
XP
–
Tracker, gerente, goldOwner, goalDonor, ...
eXtreme Programming
Eduardo Aranha