O que é?
eXtreme Programming
(XP)
A metodologia ágil para desenvolvimento de
software mais conhecida atualmente (Kent
(Kent Beck)
Beck)
Promete:
„
„
„
„
„
(Sec 17.2 - Sommerville)
UNIVERSIDADE FEDERAL DE ALAGOAS
Curso de Ciência da Computação
Engenharia de Software I
Prof. Rômulo Nunes de Oliveira
...isso tudo graç
graças a um ajuste harmônico e coeso entre
cliente e equipe de desenvolvedores.
desenvolvedores.
A Quem se Destina XP?
E o que tem de diferente?
A XP foge do padrão tradicional de
desenvolvimento da Engenharia de Software.
Na verdade, pode ser vista como um
desenvolvimento evolucioná
evolucionário e incremental
„
São pequenas etapas por vez.
„
O cliente acompanha cada incremento (tempo curto)
„
Cada pequena etapa é planejada de forma simples
„
„
Os testes são planejados antes da programaç
programação
Somente quando a etapa está
está funcionando que é
incluí
incluída no software.
Ser mais econômica
Melhor qualidade
Baixo índice de insatisfaç
insatisfação do cliente
Menos estresse no desenvolvimento
Deixar o programador livre
Grupos de 2 a 10 programadores
Equipes onde existam programadores experientes
Projetos de 1 a 36 meses (calendá
(calendário)
De 1000 a 250 000 linhas de có
código
Papé
Papéis:
„
Programadores (foco central)(sem hierarquia)
„
“Treinador”
Treinador” ou “Técnico”
cnico” (coach)
coach)
„
“Acompanhador”
Acompanhador” (tracker)
tracker)
„
Cliente
1
As 12 Práticas de XP
As 12 Práticas de XP
1 - Jogo de Planejamento (Planning Game):
1.
2.
3.
4.
5.
6.
7.
Planejamento
Fases Pequenas
Metáfora
Design Simples
Testes
Refatoramento
Programação Pareada
8.
9.
10.
11.
Propriedade Coletiva
Integração Contínua
Ritmo Sustentável
Desenvolvimento
orientado a testes
12. Padronização do código
As 12 Práticas de XP
2 - Pequenas Versões (Small Releases):
• A liberação de pequenas versões funcionais do
projeto auxilia muito no processo de aceitação
por parte do cliente, que já pode testar uma
parte do sistema que está comprando.
• As versões chegam a ser ainda menores que as
produzidas por outras metodologias
incrementais, como o RUP.
•
•
•
•
O desenvolvimento é feito em iterações semanais.
No início da semana, desenvolvedores e cliente
reúnem-se para priorizar as funcionalidades.
O cliente é essencial neste processo e assim ele fica
sabendo o que está acontecendo e o que vai
acontecer no projeto.
Ao final de cada semana, o cliente recebe novas
funcionalidades, completamente testadas e prontas
para serem postas em produção.
As 12 Práticas de XP
3 - Metáfora (Metaphor):
• Procura facilitar a comunicação com o cliente,
entendendo a realidade dele.
• O conceito de rápido para um cliente de um
sistema jurídico é diferente para um
programador experiente em controlar
comunicação em sistemas em tempo real, como
controle de tráfego aéreo.
• É preciso traduzir as palavras do cliente para o
significado que ele espera dentro do projeto.
2
As 12 Práticas de XP
4 - Projeto Simples (Simple Design):
• Projeto simples significa dizer que caso o cliente tenha
pedido que na primeira versão apenas o usuário "teste"
possa entrar no sistema com a senha "123" e assim ter
acesso a todo o sistema, você vai fazer o código exato
para que esta funcionalidade seja implementada, sem
se preocupar com sistemas de autenticação e restrições
de acesso.
• Um erro comum ao adotar essa prática é a confusão
por parte dos programadores de código simples e
código fácil.
• Código fácil deve ser identificado e substituído por
código simples.
As 12 Práticas de XP
7 - Programação em Pares (Pair Programming):
•
É a programação em par/dupla num único computador.
•
Geralmente a dupla é formada por um iniciante na liguagem e
outra pessoa funcionando como um instrutor.
•
Como é apenas um computador, o novato é que fica à frente
fazendo a codificação, e o instrutor acompanha ajudando a
desenvolver suas habilidades.
•
Desta forma o programa sempre é revisto por duas pessoas,
evitando e diminuindo assim a possibilidade de erros (bugs).
•
Com isto busca-se sempre a evolução da equipe, melhorando a
qualidade do código fonte gerado.
As 12 Práticas de XP
5 - Testes de Aceitação (Customer Tests):
•
São testes construídos pelo cliente e conjunto de analistas e
testadores, para aceitar um determinado requisito do sistema.
6 - Refatoração (Refactoring):
•
É um processo que permite a melhoria continua da
programação, com o mínimo de introdução de erros e mantendo
a compatibilidade com o código já existente.
•
Refabricar melhora a clareza (leitura) do código, divide-o em
módulos mais coesos e de maior reaproveitamento, evitando a
duplicação de código-fonte;
•
Rodar os testes sempre!!!
As 12 Práticas de XP
8 - Posse Coletiva (Collective Ownership):
• O código fonte não tem dono e ninguém precisa
solicitar permissão para poder modificar o mesmo.
• O objetivo com isto é fazer a equipe conhecer todas as
partes do sistema.
9 - Integração Contínua (Continuous Integration):
• Sempre que produzir uma nova funcionalidade, nunca
esperar uma semana para integrar à versão atual do
sistema.
• Isto só aumenta a possibilidade de conflitos e a
possibilidade de erros no código fonte.
• Integrar de forma contínua permite saber o status real
da programação.
3
As 12 Práticas de XP
10 - Ritmo Sustentável (Sustainable Pace):
•
Trabalhar com qualidade, buscando ter ritmo de
trabalho saudável (40 horas/semana, 8
horas/dia), sem horas extras.
•
Horas extras são permitidas quando trouxerem
produtividade para a execução do projeto.
•
Outra prática que se verifica neste processo é a
prática de trabalho energizado, onde se busca
trabalho motivado sempre. Para isto o ambiente
de trabalho e a motivação da equipe devem
estar sempre em harmonia.
As 12 Práticas de XP
12 - Padrões de Codificação (Coding Standards):
•
•
A equipe de desenvolvimento precisa
estabelecer regras para programar e todos
devem seguir estas regras.
Desta forma parecerá que todo o código fonte
foi editado pela mesma pessoa, mesmo quando
a equipe possui 10 ou 100 membros.
As 12 Práticas de XP
11 - Desenvolvimento Orientado a Testes (Test
Driven Development):
•
Primeiro crie os testes unitários (unit tests) e
depois crie o código para que os testes
funcionem.
•
Esta abordagem é complexa no início, pois vai
contra o processo de desenvolvimento de
muitos anos. Só que os testes unitários são
essenciais para que a qualidade do projeto seja
mantida.
Valores que guiam o
desenvolvimento XP
1 feedback – Troca da informações relacionadas ao que é
produzido e consumido durante o projeto, entre o
cliente e a equipe de desenvolvimento
2 comunicação – aproximação da equipe de
desenvolvimento. Também refere-se ao contato intenso
com o cliente. Aqui também cabe a escrita da
documentação descritiva.
3 simplicidade – Projetos simples. Implementar apenas
aquilo que é suficiente para as necessidades atuais do
cliente. Adiar decisões.
4
Valores que guiam o
desenvolvimento XP
O início de um projeto XP
Fase de Exploraç
Exploração
4 Coragem – Lidar com o medo na solução de
problemas. Tomar medidas de segurança.
5 Respeito – Todas as pessoas são igualmente
importantes. Todos são tratados da mesma
forma. É um valor social bem visto na maioria
nos ambientes de trabalho.
„
„
„
„
„
„
Histórias X casos de uso
Caso de uso: Autenticaç
Autenticação caixa automá
automático
„ Ator: Cliente
„ Descriç
Após inserir o cartão o sistema solicita a senha. O
Descrição: Apó
sistema verifica se o cartão é válido e se a senha confere. Se não o
usuá
usuário tem mais três chances...
Várias historinhas
„
„
„
„
„
„
O sistema mostra telas de boas vindas
O sistema verifica se o cartão é válido
Implementar sistema de leitura de senha
Verificaç
Verificação de senha
Releitura de senha se a mesma não confere
...
duraç
duração: até
até 20% do tempo total.
termina quando a primeira versão do software
é enviada ao cliente.
clientes escrevem “historias”
historias” (story cards).
cards).
programadores interagem com clientes e
discutem tecnologias.
Não só
só discutem, experimentam diferentes
tecnologias e arquiteturas para o sistema.
Planejamento: 1 a 2 dias.
Um Dia na Vida de um
Programador XP
Escolhe uma histó
história do cliente.
Procura um par livre.
Escolhe um computador para programaç
programação
pareada (pair
(pair programming).
programming).
Seleciona uma tarefa claramente relacionada a
uma caracterí
característica (feature
(feature)) desejada pelo
cliente.
5
Um Dia na Vida de um
Programador XP
Discute modificaç
modificações recentes no sistema
Discute histó
história do cliente
Um Dia na Vida de um
Programador XP
Atos constantes no desenvolvimento:
„
„
„
Testes
Implementaç
Implementação
„
„
Desenho
Integraç
Integração
„
Testes
Fundamento mais importante de XP.
É o que dá
dá seguranç
segurança e coragem ao grupo.
Testes de unidades (Unit tests)
tests)
„
escritos pelos programadores para testar cada
elemento do sistema (e.g., cada mé
método em cada
caso).
Testes de funcionalidades (Functional tests)
tests)
„
escritos pelos clientes para testar a
funcionalidade do sistema.
Executa testes antigos.
Busca oportunidades para simplificaç
simplificação.
Modifica desenho e implementaç
implementação
incrementalmente baseado na funcionalidade
exigida no momento.
Escreve novos testes.
Enquanto todos os testes não rodam a 100%,
o trabalho não está
está terminado.
Integra novo có
código ao repositó
repositório.
Testes
Testes das unidades do sistema
„
„
„
Tem que estar sempre funcionando a 100%.
São executados vá
várias vezes por dia.
Executados à noite automaticamente.
Testes das funcionalidades
„
„
Vão crescendo de 0% a 100%.
Quando chegam a 100% acabou o projeto.
6
O Código
Padrões de estilo adotados pelo grupo inteiro.
O mais claro possí
possível.
„
XP não se baseia em documentaç
documentações
detalhadas e extensas (perde(perde-se sincronia).
Comentá
Comentários sempre que necessá
necessários.
Comentá
Comentários padronizados.
Programaç
Programação Pareada ajuda muito!
Programação Pareada
Erro de um detectado imediatamente pelo outro
(grande economia de tempo).
Maior diversidade de idé
idéias, té
técnicas, algoritmos.
Enquanto um escreve, o outro pensa em contracontraexemplos, problemas de eficiência, etc.
Vergonha de escrever có
código feio (gambiarras
(gambiarras)) na
frente do seu par.
Pareamento de acordo com especialidades.
• Ex.: Sistema Multimí
Multimídia Orientado a Objetos
Cliente
Responsá
Responsável por escrever “histó
histórias”
rias”.
Muitas vezes é um programador ou é
representado por um programador do grupo.
Trabalha no mesmo espaç
espaço fí
físico do grupo.
Novas versões são enviadas para produç
produção
todo mês (ou toda semana).
Feedback do cliente é essencial.
Requisitos mudam (e isso não é mau).
Coach
(treinador)
Em geral, o mais experiente do grupo.
Identifica quem é bom no que.
Lembra a todos as regras do jogo (XP).
Eventualmente faz programaç
programação pareada.
Não desenha arquitetura, apenas chama a
atenç
atenção para oportunidades de melhorias.
Seu papel diminui à medida em que o time
fica mais maduro.
7
Quando XP Não Deve Ser
Experimentada?
Tracker
(Acompanhador)
A “consciência”
consciência” do time.
Coleta estatí
estatísticas sobre o andamento do projeto.
Alguns exemplos:
•
•
•
•
Número de histó
histórias definidas e implementadas.
Número de unit tests.
tests.
Número de testes funcionais definidos e funcionando.
Número de classes, mé
métodos, linhas de có
código
Manté
Mantém histó
histórico do progresso.
Faz estimativas para o futuro.
Quando o cliente não aceita as regras do jogo.
Quando o cliente quer uma especificaç
especificação
detalhada do sistema antes de começ
começar.
Quando os programadores não estão dispostos
a seguir (todas) as regras.
Se (quase) todos os programadores do time
são medí
medíocres.
Quando XP Não Deve Ser
Experimentada?
Grupos grandes (>10 programadores).
Quando feedback rápido não é possí
possível:
„
„
„
sistema demora 6h para compilar.
testes demoram 12h para rodar.
exigência de certificaç
certificação que demora meses.
Quando o custo de mudanç
mudanças é
essencialmente exponencial.
Quando não é possí
possível realizar testes
(muito raro).
Características Comuns dos
Métodos Ágeis
Coloca o foco
„
„
Na entrega freqü
freqüente de subsub-versões do software
funcionando para o cliente.
Nos seres humanos que desenvolvem o software.
Retira o foco de
„
„
„
Processos rí
rígidos e burocratizados.
Documentaç
Documentações e contratos detalhados.
Ferramentas que são usadas pelos seres
humanos.
8
Bibliografia Complementar
Métodos Ágeis e Programaç
Programação eXtrema (Fabio Kon e
Alfredo Goldman), USP, 2003.
Desenvolvimento ágil com programaç
programação extrema eficá
eficácia
e disciplina extrema no desenvolvimento orientado a
objetos de software (Viní
(Vinícius A. Castro), UFS, 2006.
9