Curso Superior de Tecnologia em Anlise e Desenvolvimento de

Sistemas

XP e FDD

Prof(a): Rosemary Borges

rosemary.borges@cefetrn.br

 Em

2001 Kent Beck, e mais 16

reconhecidos desenvolvedores, se
reuniram
para
estipularem
o
Manifesto for Agile Software
Development
(Manifesto
para
Desenvolvimento gil de Software).

Estamos descobrindo maneiras melhores de

desenvolver software fazendo-o ns mesmos e
ajudando outros a faz-lo. Atravs desse
trabalho, passamos a valorizar:
Indivduos

e interao entre eles mais que

processos e ferramentas;
Software
em
funcionamento
mais
que
documentao abrangente;
Colaborao com o cliente mais que negociao
de contratos;
Responder a mudanas mais que seguir um
plano.

Simplicidade acima de tudo;

Rpida
adaptao
incremental
s
mudanas;
Desenvolvimento do software preza pela
excelncia tcnica;
Projetos de sucesso surgem atravs de
indivduos motivados, e com uma relao
de confiana entre eles;
Desenvolvedores
cooperam
constantemente e trabalham junto com os
usurios/clientes;

 Atender

o usurio/cliente, entregando
rapidamente e continuamente produtos
funcionais em curto espao de tempo
(normalmente a cada 2 semanas);
Software funcionando a principal
medida de progresso;
Mudanas no escopo, ou nos requisitos,
do projeto no motivo de chateao;
A equipe de desenvolvimento se autoorganiza, fazendo ajustes constantes
em melhorias.

 Esse

Manifesto ocorreu para ser um

contraponto as Metodologias de
Desenvolvimento Prescritivas. Ou seja,
enquanto o RUP, extremamente
rgido com altos nveis de controle, e
forte documentao, as metodologias
geis caminham ao contrrio. Mesmo
assim, no inflige a uma slida prtica
da Engenharia de Software.

RUP
CONTROLE
Equipes Grandes
Alto Rigor

FDD
XP
ACOMPANHAR
Equipes Mdias
e Pequenas

LIBERDADE
Equipes pequenas
(menores de 10)

Um dos pontos de destaque na Metodologia

gil a liberdade dada para as equipes de
desenvolvimento.
A equipe seleciona quanto trabalho
acredita que pode realizar dentro da
iterao, e a equipe se compromete com o
trabalho. Nada desmotiva tanto uma equipe
quanto
algum
de
fora
assumir
compromissos por ela. Nada motiva tanto
uma equipe quanto a aceitao das
responsabilidades
de
cumprir
os
compromissos
que
ela
prpria
estabeleceu. (Ken Schwaber)

Programao Extrema uma das

metodologias geis mais conhecidas.
Foi criada por Kent Beck.
Baseada em cinco valores, alguns
princpios e vrias prticas que
ocorrem no contexto de quatro
atividades. Ela se destina a times de
at dez programadores, projetos de
curto e mdio prazo.

Os cinco valores de XP so:

Comunicao para um projeto de sucesso necessria muita interao
entre os membros da equipe, programadores, cliente, treinador. Para
desenvolver um produto, o time precisa ter muita qualidade nos canais de
comunicao. Conversas presenciais so sempre melhores do que
telefonemas, e-mails, cartas ou fax.
Feedback as respostas s decises tomadas devem ser rpidas e visveis.
Todos devem ter, o tempo todo, conscincia do que est acontecendo.
Coragem alterar um cdigo em produo, sem causar bugs, com
agilidade, exige muita coragem e responsabilidade.
Simplicidade para atender rapidamente s necessidades do cliente,
quase sempre um dos valores mais importantes simplicidade.
Normalmente o que o cliente quer muito mais simples do que aquilo que
os programadores constroem.
Respeito todos tm sua importncia dentro da equipe e devem ser
respeitados e valorizados. Isso mantm o trabalho energizado.

Em XP existem quatro papis principais:

Programadores - foco central da metodologia, sem hierarquia.
Treinador (ou coach) - pessoa com mais experincia no time,
responsvel por lembrar os outros das regras do jogo (que so as
prticas e os valores de XP). O treinador no precisa
necessariamente ser o melhor programador da equipe e sim o
que mais entende da metodologia XP.
Acompanhador (ou tracker) - responsvel por trazer para o time
dados, grficos, informaes que mostrem o andamento do
projeto e ajudem a equipe a tomar decises de implementao,
arquitetura e design. Algumas vezes o prprio coach faz papel de
tracker. Outras o time escolhe sozinho quem exercer este papel.
Cliente em XP o cliente faz parte da equipe. Deve estar sempre
presente e pronto para responder s dvidas dos programadores.

Existe um grande nfase ao trabalho

em duplas, aonde um analista mais
experiente trabalha com um novato.
Enquanto o mais jovem trabalha na
programao o mais antigo vai
revisando o cdigo. Dessa forma ao
mesmo tempo desenvolve-se a equipe,
e melhora-se automaticamente a
qualidade do cdigo fonte gerado.

Algumas prticas recomendadas pelo XP:

Testes - todo desenvolvimento inclui testes.

Kent Beck diz que cdigo sem teste no existe.

Os testes devem ser escritos de preferncia
antes do desenvolvimento (TDD - test driven
development) e sempre devem rodar de forma
automatizada.
Refatorao - um conjunto de tcnicas para
modificar o cdigo do sistema sem alterar
nenhuma
funcionalidade.
O
objetivo

simplificar, melhorar o design, limpar, enfim,

deixar o cdigo mais fcil de entender e dar
manuteno.

 Programao

Pareada - em XP dois
programadores sentam juntos no mesmo
computador
e
programam
juntos.
Enquanto um programador digita, o outro
observa, pensa em melhorias, alternativas.
Propriedade Coletiva - O cdigo fonte
no pertence a um nico programador.
Todos da equipe so responsveis. Todos
alteram cdigo de todos (mas sempre
rodando os testes para se certificar que
nada foi quebrado)

 Integrao Contnua - depois de testada,

cada
nova
funcionalidade
deve
ser
imediatamente sincronizada entre todos os
desenvolvedores. Quanto mais freqente for
essa integrao, menores so as chances de
conflitos
de
arquivos
que
vrios
programadores alteram simultaneamente.
Semana de 40 horas - programar uma
atividade intensa e que no rende se o
programador no estiver descansado e
disposto. Por isso, 40 horas de trabalho por
semana essencial para a sade do time.

 Cliente Sempre Presente - o cliente

no algum de fora, mas sim um

membro da equipe. Ele deve estar
sempre disponvel e pronto para atender
s dvidas dos desenvolvedores.
Padronizaes - se todo o time seguir
padres pr-acordados de codificao,
mais fcil ser manter e entender o que
j est feito. O uso de padres uma das
formas de reforar o valor comunicao.

Feature
Driven
Development
(Desenvolvimento
Guiado
por
Funcionalidades) uma metodologia gil
para gerenciamento e desenvolvimento
de software. Ela combina as melhores
prticas do gerenciamento gil de
projetos com uma abordagem completa
para Engenharia de Software orientada
por objetos.

A FDD chama a ateno

caractersticas peculiares:

por

algumas

Resultados teis a cada duas semanas ou menos

Blocos bem pequenos de funcionalidade valorizada

pelo cliente, chamados "Features"

Planejamento detalhado e guia para medio
Rastreabilidade e relatrios com preciso
Monitoramento detalhado dentro do projeto, com
resumos de alto nvel para clientes e gerentes,
tudo em termos de negcio
Fornece uma forma de saber, dentro dos primeiros
10% de um projeto, se o plano e a estimativa so
slidos

FDD uma metodologia muito

objetiva. Possui apenas duas fases:
Concepo & Planejamento: Pensar

um pouco antes de fazer (tipicamente

de 1 a 2 semanas)
Construo: Fazer de forma iterativa
(tipicamente
em
iteraes
de
2
semanas)

FDD - Estrutura

 Dentro

do contexto do FDD, o
significado de caracterstica vem a
ser
uma
funo,
relativamente
pequena, acertada com o cliente que
pode ser implementada em menos de
duas semanas, com os seguintes
benefcios:
Sendo as caractersticas pequenos blocos

de
funcionalidade,
os
usurios
e
desenvolvedores tm melhor controle e
entendimento de todo o processo.

 Organizam-se as caractersticas em

um
agrupamento
hierrquico
relacionado ao negcio, melhorando a
viso para o usurio. E para os
desenvolvedores
facilitando
o
planejamento de todo o projeto.
A equipe tem metas de desenvolvimento
dessas caractersticas a cada duas
semanas.

 Site

do MANIFESTO GIL:
http://www.agilemanifesto.org/
Sobre a metodologia FDD:
http://www.featuredrivendevelopmen
t.com/