View
220
Download
0
Category
Preview:
Citation preview
Extreme Programming
Prof.: Ari Oliveira
Projeto deDesenvolvimentoSoftware
Extreme Programming
22
│ O Extreme Programming (XP) é uma metodologia de desenvolvimento de software que auxilia na produção de sistemas de maior qualidade, em menos tempo e de forma econômica;
│ O XP se baseia nos princípios dos métodos ágeis:‖ Desenvolvimento incremental;‖ Envolvimento do cliente.
│ Criada por Kent Beck‖ Projeto da Daimler-Chrysler (de 1997 a 1999), dona da Mercedes-Benz.
│ 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
Extreme Programming
33
│ Scrum é interessante porque fornece um mecanismo de informação de status que é atualizado continuamente, e porque utiliza a divisão de tarefas dentro da equipe de forma explicita.
│ Scrum e XP são complementares pois Scrum provê práticas ágeis de gerenciamento enquanto XP provê práticas integradas de engenharia de software.
Extreme Programming
Extreme Programming
Aplicação das boas práticas de desenvolvimento de
software levadas ao extremo
Foca em Código
Extreme Programming
55
Princípios Básicos
Comunicação Simplicidade Feedback Coragem Retorno Respeito
5
Extreme Programming
66
│ 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
Extreme Programming
77
│ 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
Extreme Programming
88
│ 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
│ Respeito‖ Evite complicar o trabalho dos demais. Preserve a
qualidade do código, do design.
Extreme Programming
99
Práticas e Regras do XP
Planejamento Projeto Codificação Testes
Extreme Programming
1010
Práticas e Regras do XP
Planejamento
Estórias Iterações VelocidadeJogo do
Planejamento
Versões pequenas e frequentes
Extreme Programming
1111
│ 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
Práticas e Regras do XP
Planejamento Projeto Codificação Testes
Extreme Programming
1212
Extreme Programming
1313
│ 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 do XP
Planejamento Projeto Codificação Testes
Extreme Programming
1414
│ 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
Práticas e Regras do XP
Planejamento Projeto Codificação Testes
Extreme Programming
1515
│ 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
Práticas e Regras do XP
Planejamento Projeto Codificação Testes
Extreme Programming
1616
│ 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
Práticas e Regras do XP
Planejamento Projeto Codificação Testes
Extreme Programming
1717
│ 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 do XP
Planejamento Projeto Codificação Testes
Extreme Programming
1818
│ 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 do XP
Planejamento Projeto Codificação Testes
Extreme Programming
1919
Práticas e Regras do XP
Projeto
Simplicidade Metáforas SpikeNão adicionar
Funcionalidades previamente
Contato constante com
Cliente
Extreme Programming
2020
│ 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 frequentemente Práticas e Regras do XP
Planejamento Projeto Codificação Testes
Extreme Programming
2121
│ 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 usadaPráticas e Regras do XP
Planejamento Projeto Codificação Testes
Extreme Programming
2222
│ 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
Práticas e Regras do XP
Planejamento Projeto Codificação Testes
Extreme Programming
2323
│ 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 do XP
Planejamento Projeto Codificação Testes
Extreme Programming
2424
│ 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 do XP
Planejamento Projeto Codificação Testes
Extreme Programming
2525
Práticas e Regras do XP
Codificação
Em paresRotação de
ParesPadrão de
NomenclaturaHoras
SemanaisIntegração Contínua
Refatorarsempre que
possível
Extreme Programming
2626
│ 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 conhecimentoPráticas e Regras do XP
Planejamento Projeto Codificação Testes
Extreme Programming
2727
│ 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 do XP
Planejamento Projeto Codificação Testes
Extreme Programming
2828
│ 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 do XP
Planejamento Projeto Codificação Testes
Extreme Programming
2929
│ 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 do XP
Planejamento Projeto Codificação Testes
Extreme Programming
3030
│ 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
Práticas e Regras do XP
Planejamento Projeto Codificação Testes
Extreme Programming
3131
│ 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 horasPráticas e Regras do XP
Planejamento Projeto Codificação Testes
Extreme Programming
3232
│ 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 do XP
Planejamento Projeto Codificação Testes
Extreme Programming
3333
Práticas e Regras do XP
Testes
UnitáriosTestes antes da
codificaçãoTestes de aceitação
Extreme Programming
3434
│ 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
Práticas e Regras do XP
Planejamento Projeto Codificação Testes
Extreme Programming
3535
│ 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
Práticas e Regras do XP
Planejamento Projeto Codificação Testes
Extreme Programming
3636
│ 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 do XP
Planejamento Projeto Codificação Testes
Extreme Programming
3737
│ 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 regressivosPráticas e Regras do XP
Planejamento Projeto Codificação Testes
Extreme Programming
3838
│ “Dono da grana” (GoldOwner)‖ Patrocinador (quem paga pelo software)
│ “Dono dos objetivos” (GoalOwner)‖ Quem define os requisitos (em geral, um usuário)
│ Gerente‖ Facilitador do projeto
│ Testador de aceitação‖ Define os critérios de aceitação junto ao cliente
│ Programador‖ Responsável pela implementação
│ Rastreador‖ Coleta sinais do projeto (métricas). Avalia desempenho
│ Técnico‖ Especialista do processo. Dá suporte à equipe que está mudando.
Extreme Programming
3939
• Planejar Iteração
• Detalhar Estórias (criar tarefas)
• Descrever Prioridades
• Estimar Tarefas
– Estimar por Comparação
– Estimar por Intuição
– Spike Solutions
• 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
Extreme Programming
4040
Extreme Programming
414141
Extreme Programming
424242
Princípios Básicos
Comunicação Simplicidade Feedback Coragem Retorno Respeito
Práticas e Regras do XP
Planejamento
Estó
rias
Iter
açõ
es
Vel
oci
dad
e
Jogo
do
Pla
nej
amen
to
Ver
sões
peq
uen
as e
fre
qu
ente
s
ProjetoSi
mp
licid
ade
Met
áfo
ras
Spik
e
Não
ad
icio
nar
Fu
nci
on
alid
ades
p
revi
amen
te
Co
nta
to c
on
stan
te c
om
Clie
nte
Codificação
Em p
ares
Ro
taçã
o d
e P
ares
Pad
rão
de
No
men
clat
ura
Ho
ras
Sem
anai
s
Inte
graç
ão C
on
tín
ua
Ref
ato
rar
sem
pre
qu
e p
oss
ível
Testes
Un
itár
ios
Test
es a
nte
s d
a co
dif
icaç
ão
Test
es d
e ac
eita
ção
Extreme Programming
Prof.: Ari Oliveira
Projeto deDesenvolvimentoSoftware
Recommended