01 Gil - 02 - XP

Metodologias de Desenv.
gil XP Rgis Simo e Ciro Coelho

1/59
Extreme Programming
Rgis Simo e Ciro Coelho

Metodologias de Desenv. gil XP Rgis Simo e Ciro Coelho
2/59
Agenda
Introduo
Valores
Ciclo de Vida
Prticas
Documentao
Equipe
Quando no usar XP
Como implantar
Bibliografia
3/59
Livros
Introduo
4/59
Livros The XP Series
Introduo
5/59
Outras Referncias
Site:
www.improveit.com.br/xp
Grupos:
http://tech.groups.yahoo.com/group/xprio
http://br.groups.yahoo.com/group/xprecife
http://tech.groups.yahoo.com/group/xp-rs
http://br.groups.yahoo.com/group/xpnorte
http://tech.groups.yahoo.com/group/xpsc
http://tech.groups.yahoo.com/group/xpbh
http://tech.groups.yahoo.com/group/xpsp

Introduo
6/59
Extreme Programming (XP) um processo de
desenvolvimento de software voltado para:
Projetos cujos requisitos so vagos e mudam com freqncia;
Desenvolvimento de sistemas orientados a objetos;
Equipes pequenas, preferencialmente at 12 desenvolvedores;
Desenvolvimento incremental (ou iterativo), onde o sistema
comea a ser implementado logo no incio do projeto e vai
ganhando novas funcionalidades ao longo do tempo.
Introduo
Fonte: Livro Extreme Programming.
Autor Vincius Manhes Teles
7/59
Feedback

Comunicao

Simplicidade

Coragem
Valores
8/59
Feedback
Quando o cliente aprende com o sistema que utiliza e re-avalia
as suas necessidades, gerando feedback para a equipe de
desenvolvimento.

o mecanismo fundamental que permite que o cliente
conduza o desenvolvimento diariamente.

Garante que a equipe direcione as
suas atenes para aquilo
que ir gerar mais valor.
Valores
9/59
Comunicao
O XP busca aproximar todos
os envolvidos do projeto
Permite que o cliente compartilhe
o seu aprendizado com a equipe

Valores
Promover a comunicao face-a-face
ou da forma mais rica que for vivel.
A comunicao entre o cliente e a
equipe permite que todos os detalhes
do projeto sejam tratados com a
ateno e a agilidade que merecem.
10/59
Feedback e Comunicao
Valores
11/59
Simplicidade
Temos que implementar apenas aquilo que suficiente para
atender a cada necessidade do cliente.
Ao codificar, deve-se preocupar apenas com os problemas de
hoje.
Deve-se deixar os problemas do futuro para o futuro.
As generalizaes devem ser feitas quando elas vierem na forma
de uma necessidade especfica e no como uma especulao.
Valores
12/59
Coragem

A equipe precisa ser corajosa e acreditar
que, utilizando as prticas e valores do XP,
ser capaz de fazer o software evoluir com
segurana e agilidade.

Em muitos casos, a equipe alterar
algo que vinha funcionando corretamente,
o que leva ao risco de gerar falhas
no sistema.
TELES, Vincius M. Extreme Programming.
Novatec Editora, 2006
Valores
13/59
Desenvolvimento Tradicional

Desenvolvimento gil

Ciclo Semanal
Ciclo de Vida
14/59
Ciclo de Vida em Cascata
Forte influncia da Revoluo Industrial
Software construdo linearmente, seguindo uma seqncia de fases
Ciclo de Vida
Definio de
Requisitos
Projeto de
Software
Implementao e
teste de unidade
Integrao
e teste de
sistema
Operao e
Manuteno
15/59
Ciclo de Vida em Cascata
Base de vrios processos de software
Interpretao errada do ciclo de vida do Rational Unified Process
(RUP)
Ciclo de Vida
16/59
Caractersticas do Ciclo de Vida em Cascata
Linearidade
Determinstico
Especializao
Foco na execuo

Ciclo de Vida
17/59
Desenvolvimento gil
Categorias de Trabalhadores (Drucker, 1999. In: Teles, 2006)
Trabalhador Manual
Habilidades Manuais
Fcil de Automatizar
Determinstico
Repetitivo
Trabalhador do Conhecimento
Uso intensivo de conhecimento e criatividade
O XP v o desenvolvimento de software como um processo de uso
intensivo de conhecimento e criatividade
Ciclo de Vida
18/59
Desenvolvimento gil
Ciclo de Vida Incremental
Ciclo de Vida
Definir esboo
dos requisitos
Atribuir
requisitos aos
incrementos
Projetar
arquitetura do
sistema
Desenvolver
incremento do
sistema
Validar
incremento
Integrar
incremento
Validar
sistema
Sistema incompleto
Sistema
final
19/59
Desenvolvimento gil
Ciclo de Vida em Espiral
Ciclo de Vida
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis
Proto-
type 1
Prototype 2
Prototype 3
Opera-
tional
protoype
Concept of
Operation
Simulations, models, benchmarks
S/W
requirements
Requirement
validation
Design
V&V
Product
design
Detailed
design
Code
Unit test
Integr ation
test
Acceptance
test
Service
Develop, verify
next-level product
Evaluate alternatives
identify, resolve risks
Determine objectives
alternatives and
constraints
Plan next phase
Integration
and test plan
Development
plan
Requirements plan
Life-cycle plan
REVIEW
20/59
Ciclo de Vida
Desenvolvimento gil
Fonte: Workshop Desenvolvimento gil. Autor Vincius Manhes Teles
21/59
Ciclo de Vida
Ciclo Semanal
Definio com o cliente
Desenvolvimento
Teste
Avaliao pelo cliente
Validao parcial com o cliente
22/59
Ciclo de Vida
Fonte: Palestra Extreme Programming, abraando a mudana.
Autor Helder da Rocha
Ciclo Semanal
Feedback e Aprendizagem
23/59
Prticas
Jogo do Planejamento
Cliente Presente
Stand Up Meeting
Desenvolvimento guiado
pelos Testes
Programao por Pares
Refactoring
Cdigo Coletivo
Cdigo Padronizado
Design Simples
Ritmo Sustentvel
Integrao Contnua
Releases Curtos
Metfora
24/59
Prticas
uma reunio onde o cliente avalia as funcionalidades que
devem ser implementadas e prioriza aquelas que faro parte do
prximo release ou da prxima iterao.
Visa assegurar que a equipe de desenvolvimento esteja sempre
trabalhando naquilo que ir gerar maior valor para o cliente a cada
dia de trabalho.
O projeto dividido em
Releases e Iteraes.
Cliente e a equipe podem
revisar o planejamento
constatemente.
As funcionalidades so descritas em pequenos cartes e so
chamadas de Estrias.
25/59
Prticas
Exemplos de Estrias (Teles, 2006):
Apresente ao cliente as dez tarifas mais baratas para uma determinada
rota (Beck, 2001).
Para cada conta, computar o saldo fazendo a adio de todos os
depsitos e a subtrao de todas as dedues (Jeffries, 2001).
Produzir um extrato para cada conta, mostrando a data, o nmero, o
beneficirio e a quantia da transao. Segue um extrato de exemplo
em anexo faa o relatrio parecer com o exemplo (Jeffries, 2001).
A tela de login deve permitir que o usurio pule o login. Neste caso, o
usurio entrar no sistema como guest (Newkirk, 2001).
O usurio deve poder alterar o seu perfil (email, senha, primeiro nome,
ltimo nome e filiao). Dois campos de senha para confirmao
(Newkirk, 2001).
26/59
Prticas
Estrias
So sempre escritas pelo prprio cliente.
Criam um vnculo com o cliente.
Formalizam o pensamento do cliente.
No tm formato de escrita.
Devem ser limitadas pelo tamanho do carto, simplicidade.
Podem ser dividas em tarefas, quando muito complexas.
Do a noo de custo.
Cada desenvolvedor seleciona uma estria ou tarefa a ser feita em
um determinado prazo.
27/59
Prticas
Estimativas
Estimativa baseada no conceito de Dia Ideal de Desenvolvimento
(s para implementao).
Estima-se cada estria com a unidade Ponto (dia ideal de
desenvolvimento).
No canto superior esquerdo do carto, colocam-se os pontos
estimados.
No canto superior direito do carto, ficam os pontos realmente
consumidos.
A estimativa deve ser por comparao.
A estimativa deve ser feita em equipe.
O cliente deve sempre participar.
Velocidade a quantidade de pontos que uma equipe implementou
na iterao anterior.
28/59
Prticas
Exemplo de Planejamento de uma Iterao de 2 semanas:
2 semanas = 10 dias teis
1 dia til para a reunio de planejamento da iterao
1 dia til para a reunio de encerramento da iterao
Dias teis disponveis para o desenvolvimento = 10 2 = 8
Nmeros de desenvolvedores = 6 = 3 x 2 = 3 pares
1 par / dia = 1 ponto
1 par em 8 dias = 1 x 8 = 8 pontos
3 pares em 8 dias = 3 x 8 = 24 pontos
29/59
Acompanhamento Visual
No iniciado Em andamento Finalizado
Prticas
30/59
Prticas
Cliente Presente
O cliente deve estar presente durante o desenvolvimento.
Presente em:
Reunies de Planejamento das Releases e das Iteraes
Reunies de Encerramento das Releases e das Iteraes
Alguns momentos do desenvolvimento para tirar dvidas e validar
algumas informaes.
O cliente deve conduzir o desenvolvimento a partir do feedback
que recebe do sistema.
A presena do cliente simplifica a comunicao.
31/59
Prticas
Stand Up Meeting
Reunio rpida que a equipe de desenvolvimento faz a cada
manh para avaliar o trabalho do dia anterior e priorizar aquilo que
ser implementado no dia.
Trs perguntas devem ser respondidas por cada desenvolvedor:
O que foi feito no dia anterior?
O que vai ser feito hoje?
Tem algo atrapalhando ou necessrio para o trabalho a ser realizado?
Os problemas relatados devem ser tratados fora da reunio!
32/59
Prticas
Desenvolvimento Guiado pelos Testes
Os desenvolvedores escrevem testes para cada funcionalidade
antes de implement-las.
Benefcios:
melhoram o entendimento sobre as necessidades do cliente,
projetam melhor as interfaces externas dos mtodos e classes e
limitam at onde codificar cada funcionalidades.
Tipos de Testes:
Testes de Unidade sobre cada classe, criado e executado pelo
Desenvolvedor
Testes de Aceitao sobre funcionalidade ou estrias, escrito pelo
cliente e pelo Analista de Testes, executado principalmente pelo
cliente

33/59
Prticas
Exemplo de um Teste de Unidade
Fonte: Desenvolvimento Orientado a Testes (www.improveit.com.br).
34/59
Prticas
Exemplo de um Teste de Unidade
Fonte: Desenvolvimento Orientado a Testes (www.improveit.com.br).
35/59
Prticas
Exemplo de um Teste de Aceitao
Fonte: Livro Extreme Programming,
Autor: Vincius Manhes Teles
36/59
Prticas
Programao em Pares
A implementao sempre feita por duas pessoas.
Enquanto uma pessoa implementa, a outra avalia o cdigo que
est sendo feito, realizando uma reviso constante.
A cada 15 minutos, a pessoa que est implementado passa a
fazer a avaliao e a outra implementa.
A cada turno as duplas trocam.

37/59
Prticas
Programao em Pares
Benefcios:
Aumenta a produtividade
Melhora a soluo
Dissemina conhecimento de negcio
Nivela habilidades
Desafios:
Organizao do escritrio
Viso gerencial
Relacionamento humano
Competio
38/59
Prticas
Refactoring
O refactoring a tcnica de alterar o cdigo sem alterar a
funcionalidade.

O objetivo fazer o cdigo ficar mais simples de ser manipulado.

Anda de mos dadas com o cdigo coletivo e
testes de unidades.

Existem livros especficos sobre tcnicas de
refactoring.
39/59
Prticas
Cdigo Coletivo
Procura evitar ilhas de conhecimento.
Quando s uma pessoa conhece uma
soluo, pode ser um gargalho no
desenvolvimento.
Com a programao em pares, os
desenvolvedores passam a ser
conhecedores de todas as
funcionalidades.
Eles tm acesso a todas as
funcionalidades, podendo alter-las sem
necessitar de autorizao, inclusive
fazendo refactoring.

40/59
Prticas
Cdigo Padronizado
A equipe deve estabelecer padres de implementao que devem
ser seguidos por todos.
Isto agiliza as manutenes e torna o cdigo mais homogneo.
Exemplo:
Code Conventions for the Java Programming Language da SUN
Writting Robust Java Code de Scott Ambler
Caractersticas de um padro:
Indentao
Letras maisculas e minsculas
Comentrios
Nome
41/59
Prticas
Cdigo Padronizado

Quando algum encontra algo fora do padro deve-se:
Alertar a equipe o que est fora do padro e forma correta de fazer.
Fazer refactoring do cdigo, colocando-o no padro.

Dificuldades
Ter um padro. Se no tiver, utilize um pronto!
Mudana de hbito.
42/59
Prticas
Design Simples
Para ser gil, a equipe deve optar por um cdigo que seja
suficiente para atender as necessidades atuais do cliente.
Necessidades futuras sero atendidas quando elas forem
requisitadas, fazendo-se uso do refactoring e testes, por exemplo.
A nica coisa constante em um projeto de software a mudana
(Beck, 2000. In: Teles, 2006):
Os requisitos mudam
O design muda
A tecnologia muda
A equipe muda
Os membros da equipe mudam
43/59
Prticas
Design Simples
Estratgia do XP para um cdigo simples (Teles, 2006):
Comece escrevendo um teste para funcionalidade a ser desenvolvida.
Faa o design e implemente apenas o suficiente para passar nos
testes.
Repita os passos 1 e 2 quantas vezes forem necessrias.
Se voc identificar a oportunidade de tornar o design mais simples,
faa-o.
44/59
Prticas
Design Simples
Ferramentas:
Utilize as ferramentas mais simples.
Se desejar gerar documentaes e diagramas, lembre que tem que
mant-las atualizadas.
A documentao sempre tem que refletir o cdigo, seno no serve
pra nada!
Documente as decises importantes.
45/59
Prticas
Ritmo Sustentvel
Os desenvolvedores devem trabalhar apenas 8 horas por dia.
As horas-extras devem ser evitadas.
Isto para permitir que os desenvolvedores se mantenham atentos,
criativos e dispostos a solucionar os problemas.
Sugesto:
08:00 s 08:30 Ler e-mails
08:30 s 09:00 Stand Up Meeting
09:00 s 12:00 Programao em Pares
14:00 s 17:00 Programao em Pares
17:00 s 17:30 Ler e-mails
17:30 s 18:00 Estudo para refactoring

46/59
Prticas
Integrao Contnua
Consiste da equipe integrarem seus cdigos com o restante do
sistema vrias vezes ao dia.
Para garantir que o sistema esteja funcionando corretamente aps
uma integrao, necessrio realizar todos os testes (testes de
regresso).
Cdigo avana atravs de trs fases:
local,
candidato liberao e
disponibilizado no repositrio
Utilize uma mquina em separado para a integrao: backup e
ritual.

47/59
Prticas
Integrao Contnua
Ferramentas:
Ferramenta de build
Sistema de controle de verso
O processo de integrao feito corretamente quando:
Deve ser fcil e rpido obter o cdigo fonte do qual voc necessita;
Deve ser fcil e rpido armazenar as suas mudanas;
O repositrio deve detectar conflitos e importante que seja simples
resolv-los;
No deve haver espera, isto , se um par precisa editar alguma coisa,
ele deve seguir adiante sem que nada o impea.
48/59
Prticas
Releases Curtos
A equipe deve produzir um conjunto pequeno de funcionalidades
(release)
Colocar a release em produo rapidamente para que o cliente
possa fazer uso das funcionalidades o mais cedo possvel.
Durante o projeto, a equipe colocar diversas verses do sistema
em produo, gerando um fluxo contnuo de valor para o cliente.
Aumenta Feedback
Aumenta o Retorno do Investimento
49/59
Prticas
Releases Curtos
50/59
Prticas
Metfora
A equipe de desenvolvimento transmite idias complexas de forma
simples atravs de metforas.
A metfora do time de futebol para entender a utilizao das
prticas de futebol
51/59
Documentao
Por que documentar?
Permitir que rapidamente um desenvolvedor possa criar ou manter
um cdigo.
At que ponto documentar?
O suficiente para apoiar o cdigo: testes de unidade, testes de
aceitao e outras documentaes.
Quando documentar?
Prximo da implementao (antes ou depois), para que o negcio
no mude enquanto se documenta.
Dentro da mesma iterao.

52/59
Documentao
Sugesto de Documentao
Estrias
Testes de Aceitao
Testes de Unidade
Javadoc
Modelo de Classes
Modelo de Dados
Processo de Negcio
Manual do Usurio
Acompanhamento Dirio
Acompanhamento do Projeto
Fotos
53/59
Gerente de Projeto
Coach
Analista de Teste
Redator Tcnico
Desenvolvedor
Equipe
54/59
Equipe
Gerente de Projeto
responsvel pelos assuntos administrativos do projetos. Libera a
equipe de questes no ligadas ao desenvolvimento. Administra o
relacionamento com o cliente, assegurando que o mesmo
participe ativamente do desenvolvimento.
Coach
o responsvel tcnico pelo projeto. Orienta a equipe nas boas
prticas do XP. Pode atuar na implementao, mas a sua funo
principal assegurar o bom funcionamento do processo e buscar
formas de melhor-lo continuamente.
Analista de Teste
responsvel por ajudar o cliente a escrever os testes de
aceitao. Quando o teste no automtico, ele deve executar os
testes diversas vezes ao longo das iteraes.
55/59
Equipe
Redator Tcnico
Ajuda a equipe a documentar o sistema. A equipe pode fazer
documentao, mas a preocupao principal deve ser o cdigo.
O redator quem faz a maior parte do trabalho de documentao.
Desenvolvedor
a pessoa que analisa, projeta e codifica. No existe distino
entre analista, projetista e programadores. O desenvolvedor faz
estes diferentes papis em diversos momentos do projeto.
56/59
Quando no usar XP
Sistemas de premiao individuais
Contratos de escopo fechado
Clientes que fazem questo de um grande nmero de
artefatos
Empresas onde os layouts de escritrios so fixos
Quando no se tem apoio das pessoas que decidem
Equipes grandes e espalhadas geograficamente
Situaes onde no se tem controle sobre o cdigo
(sistemas legados)
Situaes onde o feedback demorado
57/59
Como implantar
Uma prtica de cada vez
Enfatize o problema mais importante
Dificuldades culturais
Deixar algum mexer no seu cdigo
Trabalhar em pares
Dificuldades devido a mudana de hbitos
Manter as coisas simples (e no tentar prever o futuro escrevendo
"design flexvel")
Jogar fora cdigo desnecessrio
Escrever testes antes de codificar
Refatorar com freqncia (vencer o medo)
58/59
TELES, Vincius M. Extreme Programming. Novatec
Editora, 2006.
TELES, Vincius M. Workshop sobre Desenvolvimento
gil. 2007.
DA ROCHA, Helder. Palestra sobre Extreme
Programming: abraando a mudana. 2002.
Bibliografia
59/59
FIM!!!

01 Gil - 02 - XP

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

01 Gil - 02 - XP

Enviado por

Direitos autorais:

Formatos disponíveis

Metodologias de Desenv.

gil XP Rgis Simo e Ciro Coelho

Você também pode gostar