Extreme Programming Projeto de Desenvolvimento Software de Software/12-XP.pdf · XP provê práticas integradas de engenharia de software. Extreme Programming Extreme Programming

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


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



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



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



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



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



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



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



Extreme Programming

1919


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


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


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



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



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.



Extreme Programming

2525


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


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



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



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



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



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


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



Extreme Programming

3333


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



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



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



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


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


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

Documents

Extreme Programming Projeto de Desenvolvimento Software de Software/12-XP.pdf · XP provê práticas integradas de engenharia de software. Extreme Programming Extreme Programming