MODELOS GEIS

PROF. RAUL SIDNEI WAZLAWICK

UFSC-CTC-INE
2010

MODELOS GEIS
Os modelos geis de desenvolvimento de software
seguem uma filosofia diferente dos modelos
prescritivos.

Ao invs de apresentar uma receita de bolo com
fases ou tarefas a serem executados, eles focam
em valores humanos e sociais.

MANIFESTO GIL

Ns estamos descobrindo formas melhores de desenvolver

software fazendo e ajudando outros a fazer. Atravs deste
trabalho chegamos aos seguintes valores:

Indivduos e interaes esto acima de processos e
ferramentas.

Software funcionando est acima de documentao
compreensvel.

Colaborao do cliente est acima de negociao de
contrato.

Responder s mudanas est acima de seguir um plano.
Ou seja, enquanto forem valorizados os itens esquerda, os
itens direita valero mais.

PRINCPIOS DO MANIFESTO GIL

Nossa maior prioridade satisfazer o cliente atravs da entrega

rpida e contnua de software com valor.

Mudanas nos requisitos so bem vindas, mesmo nas etapas

finais do projeto. Processos geis usam a mudana como um
diferencial competitivo para o cliente.

Entregar software freqentemente, com intervalos que viam de

duas semanas a dois meses, preferindo o intervalo mais curto.

Administradores (business people) e desenvolvedores devem

trabalhar juntos diariamente durante o desenvolvimento do
projeto.

Construa projetos em torno de indivduos motivados. D a eles o

ambiente e o suporte e confie que eles faro o trabalho.

O meio mais eficiente e efetivo de tratar a comunicao entre e

para a equipe de desenvolvimento a conversa face a face.

PRINCPIOS DO MANIFESTO GIL

Software funcionando a medida primordial de progresso.

Processos geis promovem desenvolvimento sustentado. Os
financiadores, usurios e desenvolvedores devem ser
capazes de manter o ritmo indefinidamente.
Ateno contnua excelncia tcnica e bom projeto
melhora a agilidade.
Simplicidade a arte de maximizar a quantidade de
trabalho no feito essencial.
As melhores arquiteturas, requisitos e projetos emergem de
equipes auto-organizadas.
Em intervalos regulares a equipe reflete sobre como se
tornar mais efetiva e ento ajusta seu comportamento de
acordo.

SCRUM
Scrum um modelo gil para gesto de projetos
de software.

No Scrum um dos conceitos mais importantes o
sprint, que consiste em um ciclo de
desenvolvimento, usualmente de duas semanas a
um ms.

PERFIS
O Scrum master, que no um gerente no
sentido dos modelos prescritivos. O Scrum master
no um lder, j que as equipes so autoorganizadas, mas um facilitador (pessoa que
conhece bem o modelo) e resolvedor de conflitos

O product owner, ou seja, a pessoa responsvel
pelo projeto em si. O product owner tem, entre
outras atribuies, a de indicar quais so os
requisitos mais importantes a serem tratados em
cada sprint. O product owner o responsvel pelo
ROI (Return Of Investment), e tambm por
conhecer e avaliar as necessidades do cliente.

SCRUM TEAM
a equipe de desenvolvimento.

Essa equipe no necessariamente dividida em
papeis como analista, projetista e programador,
mas todos interagem para desenvolver o produto
em conjunto.

Usualmente so recomendadas equipes de 6 a 10
pessoas.

No caso de projetos muito grandes possvel
aplicar o conceito de Scrum of Scrums, onde
vrios Scrum teams trabalham em paralelo e
cada um contribui com uma pessoa para a
formao do Scrum of Scrums, quando ento as
vrias equipes so sincronizadas.

PRODUCT BACKLOG
As funcionalidades a serem implementadas em
cada projeto (requisitos) so mantidas em uma
lista chamada de product backlog.

Um dos princpios das metodologias geis usado
aqui: adaptao ao invs e planejamento.

O product backlog no precisa ento ser completo
no incio do projeto.

Pode-se iniciar apenas com as funcionalidades
mais evidentes para depois, medida que o
projeto avana tratar novas funcionalidades que
vo sendo descobertas.

SPRINT
No incio de cada sprint feito um sprint
planning meeting, no qual a equipe prioriza os
elementos do product backlog a serem
implementados e transfere estes elementos do
product backlog para o sprint backlog, ou seja, a
lista de funcionalidades a serem implementadas
no ciclo que se inicia.

A equipe se compromete a desenvolver as
funcionalidades e o product owner se compromete
a no trazer novas funcionalidades durante o
mesmo sprint.

Se novas funcionalidades forem descobertas,
sero abordadas em sprints posteriores.

SPRINT BACKLOG

Pode-se dizer que os dois backlogs tm naturezas

diferentes:
O product backlog apresenta requisitos de alto nvel,
bastante voltados s necessidades diretas do cliente.

J o sprint backlog apresenta uma viso desses
requisitos de forma mais voltada maneira como a
equipe vai desenvolv-los.

Durante o sprint, cabe ao product owner manter o

sprint backlog atualizado, indicando as tarefas j
concludas e as ainda por concluir,
preferencialmente mostradas em um grfico
atualizado diariamente e vista de todos.

REVIEW
Ao final de cada sprint a equipe deve fazer um
sprint review meeting (retrospectiva) para
verificar o que foi feito e a partir da partir para
uma nova sprint.

O sprint review meeting avalia o sucesso do plano.

DAILY SCRUM

Mais importante ainda, o modelo sugere que a equipe

realize uma reunio diria, chamada daily scrum, onde o
objetivo que cada membro da equipe fale sobre o que fez
no dia anterior, o que vai fazer no dia que se segue e, se for
o caso, o que o impede de prosseguir.
Essas reunies devem ser rpidas.
Por isso, se sugere que sejam feitas com as pessoas em p e
em frente a um quadro de anotaes.
Alm disso, recomenda-se que sejam feitas logo aps o
almoo, quando os participantes estaro mais imersos nas
questes do trabalho (longe dos problemas pessoais), alm
de ser uma boa maneira de dissipar o cansao que atinge os
desenvolvedores no incio da tarde.

MODELO SCRUM

SPRINT DEVEM SEGUIR A FILOSOFIA PDCA

Plan: planejar uma meta ou identificar um problema que

esteja impedindo o progresso, analisar o fenmeno ou os
dados relacionados ao problema, analisar o processo, ou as
causas fundamentais do problema, elaborar um plano de
ao para atingir o objetivo ou resolver o problema.
Do: executar as atividades previstas no plano de ao.
Check: avaliar e monitorar periodicamente os resultados.
Avaliar os processos utilizados. Produzir relatrios, se
necessrio.
Act: agir de acordo com os planos ou melhorar os planos e
processos se necessrio.

ORIGENS
A concepo inicial do Scrum deu-se na indstria
automobilstica (Takeuchi & Nonaka, 1986), e o
modelo pode ser adaptado a vrias outras reas
diferentes da produo de software.

Na rea de desenvolvimento de software, Scrum
deve sua popularidade inicialmente ao trabalho
de Schwaber.

Uma boa referncia para quem deseja adotar o
mtodo o livro de Schwaber e Beedle (2001), que
apresenta o mtodo de forma completa e
sistemtica.

XP EXTREME PROGRAMMING
um modelo gil inicialmente adequado a
equipes pequenas e mdias que baseado em
uma srie de valores, princpios e regras.

XP surgiu no final da dcada de 1990, nos
Estados Unidos.

VALORES
Simplicidade

Respeito

Comunicao

Feedback

Coragem

SIMPLICIDADE
Segundo o Chaos Report (Standish Group, 1995)
mais da metade das funcionalidades introduzidas
em sistemas nunca so usadas.

XP sugere como valor a simplicidade, ou seja, a
equipe deve se concentrar nas funcionalidades
efetivamente necessrias e no naquelas que
poderiam talvez ser necessrias, mas que ainda
no se tem evidncia de que so essenciais.

RESPEITO
Respeito entre os membros da equipe e entre a
equipe e o cliente um valor dos mais bsicos,
que d sustentao a todos os outros.

Sem respeito a comunicao falha e o projeto
afunda.

COMUNICAO
Em desenvolvimento de software a comunicao
essencial para que o cliente consiga dizer o que
realmente precisa.

XP preconiza comunicao de boa qualidade,
preferindo encontros presenciais ao invs de
videoconferncias, videoconferncias, ao invs de
telefonemas, telefonemas ao invs de emails e
assim por diante.

Ou seja, quanto mais pessoal e expressiva a
forma de comunicao melhor.

FEEDBACK
O projeto de software reconhecidamente um
empreendimento de alto risco.

Cientes disso, os desenvolvedores devem buscar
obter feedback o quanto antes para que eventuais
falhas de comunicao sejam corrigidas o mais
rapidamente possvel antes que os danos se
alastrem e o custo da correo seja alto.

CORAGEM
Pode-se dizer que a nica coisa constante no
projeto de um software a necessidade de
mudana.

Para os desenvolvedores XP necessrio confiar
nos mecanismos de gerenciamento da mudana
para ter a coragem de abraar as inevitveis
modificaes ao invs de simplesmente ignorlas, por estarem eventualmente fora do contrato
formal, ou por serem muito difceis de acomodar.

PRINCPIOS SO DEFINIDOS A PARTIR DOS

VALORES
Priorizao de funcionalidades mais importantes
de forma que, se o trabalho no puder ser todo
concludo, pelo menos as partes mais importantes
tero sido.

Mudanas incrementais, feedback rpido, e
considerar a mudana como algo positivo, que
deve ser considerado parte do processo.

Qualidade: pequenos ganhos a curto prazo pelo
sacrifcio da qualidade no so compensados
pelas perdas a mdio e longo prazo

PRTICAS
Jogo de planejamento

Metfora

Equipe coesa

Reunies em p

Projeto simples

Verses pequenas

Ritmo sustentvel

Posse coletiva

Programao em pares

Padres de codificao

Testes de aceitao

Desenvolvimento
orientado a testes

Refatorao

Integrao contnua

JOGO DE PLANEJAMENTO (PLANNING

GAME)
Semanalmente a equipe deve se reunir com o
cliente para priorizar as funcionalidades a serem
desenvolvidas.

Cabe ao cliente identificar as principais
necessidades e equipe de desenvolvimento
estimar quais podem ser implementadas no ciclo
semanal que se inicia.

Ao final da semana essas funcionalidades so
entregues ao cliente.

Esse tipo de modelo de relacionamento com o
cliente adaptativo, em oposio aos contratos
rgidos usualmente estabelecidos.

METFORA (METAPHOR)
preciso conhecer a linguagem do cliente e seus
significados.

A equipe deve aprender a se comunicar com o
cliente na linguagem que ele compreende.

EQUIPE COESA (WHOLE TEAM)

O cliente faz parte da equipe de desenvolvimento.

REUNIES EM P (STAND-UP MEETING).

Como no caso de Scrum, reunies em p tendem a

serem mais objetivas.

PROJETO SIMPLES (SIMPLE DESIGN)

Isso implica em atender a funcionalidade
solicitada pelo cliente sem sofisticar
desnecessariamente.

Deve-se fazer o que o cliente precisa, no o que o
desenvolvedor gostaria que ele precisasse.

Por vezes, projeto simples pode ser confundido
com projeto fcil.

Nem sempre o projeto simples o mais fcil de
implementar.

O projeto fcil pode no atender s necessidades,
ou pode gerar problemas de arquitetura.

VERSES PEQUENAS (SMALL RELEASES)

A liberao de verses pequenas do sistema pode
ajudar o cliente a testar as funcionalidades de
forma contnua.

XP leva ao extremo este princpio, sugerindo
verses ainda menores do que as de outros
processos incrementais como UP.

RITMO SUSTENTVEL (SUSTAINABLE

PACE).
Trabalhar com qualidade um nmero razovel de
horas por dia (no mais do que 8).

Horas extras s so recomendadas quando
efetivamente trouxerem um aumento de
produtividade, mas no podem ser rotina.

POSSE COLETIVA (COLLECTIVE

OWNERSHIP)

O cdigo no tem dono e no necessrio pedir

permisso a ningum para modific-lo.

PROGRAMAO EM PARES (PAIR

PROGRAMMING)
A programao sempre feita por duas pessoas
em cada computador.

Usualmente trata-se de um programador mais
experiente e um aprendiz.

O aprendiz deve usar a mquina enquanto o mais
experiente o ajuda a evoluir em suas capacidades.

Com isso, o cdigo gerado ter sempre sido
verificado por pelo menos duas pessoas,
reduzindo drasticamente a possibilidade de erros.

PADRES DE CODIFICAO (CODING

STANDARDS)

A equipe deve estabelecer e seguir padres de

codificao, de forma que parecer que o cdigo
foi todo desenvolvido pela mesma pessoa, mesmo
que tenham sido dezenas.

TESTES DE ACEITAO (CUSTOMER TESTS)

So testes planejados e conduzidos pela equipe

em conjunto com o cliente para verificar se
determinados requisitos foram atendidos.

DESENVOLVIMENTO ORIENTADO A TESTES

(TEST DRIVEN DEVELOPMENT)

Antes de programar uma unidade deve-se

estabelecer os testes pelos quais ela dever
passar.

REFATORAO (REFACTORING)
No se deve fugir da refatorao quando
necessria.

Ela permite manter a complexidade do cdigo em
um nvel gerencivel.

um investimento que traz benefcios a mdio e
longo prazo.

INTEGRAO CONTNUA (CONTINUOUS

INTEGRATION)
Nunca esperar at ao final do ciclo para integrar
uma nova funcionalidade.

Assim que estiver vivel ela deve ser integrada
ao sistema para evitar surpresas.

REGRAS XP
Wells (2009) vai mais alm das prticas XP
apontando um conjunto sucinto e bastante
objetivo de regras para XP.

Ele divide as regras em 5 grandes grupos:

Planejamento
Gerncia
Projeto
Codificao
Teste

REGRAS XP DE PLANEJAMENTO
Escrever histrias de usurio

O planejamento de entregas cria o cronograma de
entregas

Faa entregas pequenas freqentes

O projeto dividido em iteraes

O planejamento da iterao inicia cada iterao

ESCREVER HISTRIAS DE USURIO

Servem ao mesmo propsito de casos de uso, mas
no so a mesma coisa.

So usadas no lugar do documento de requisitos.

Devem ser escritas pelos usurios como sendo as
coisas que eles precisam que o sistema faa para
eles.

Podem ser usadas para definir os testes de
aceitao.

ESCREVER HISTRIAS DE USURIO

A equipe deve estimar se a histria pode ser
implementada em uma, duas ou trs semanas.

Tempos maiores do que este significam que a
histria deve ser subdividida em duas ou mais
histrias.

Menos de uma semana significa que a histria
est em um nvel de detalhe muito alto e precisa
ser combinada com outras.

Como as histrias so escritas pelo cliente,
espera-se que no sejam contaminadas com
aspectos tcnicos e de interfaces.

O PLANEJAMENTO DE ENTREGAS CRIA O

CRONOGRAMA DE ENTREGAS
feito um encontro de planejamento de entregas
para delinear o projeto como um todo.

importante que os tcnicos tomem as decises
tcnicas e os administradores as decises de
negcio.

Deve-se estimar o tempo de cada histria de
usurio em termos de semanas de programao
ideais e priorizar as histrias mais importantes
do ponto de vista do cliente.

Uma semana de programao ideal aquela em
que uma pessoa trabalha todas as horas da
semana unicamente em um projeto, dedicando-se
apenas a ele.

O PLANEJAMENTO DE ENTREGAS CRIA O

CRONOGRAMA DE ENTREGAS
As histrias so agrupadas em iteraes, que s
so planejadas pouco antes de iniciarem.

Essa priorizao pode ser feita com histrias
impressas em cartes que so movidos na mesa
ou num quadro para indicar prioridades.

FAA ENTREGAS PEQUENAS FREQENTES

Algumas equipes entregam software
diariamente, mas no pior caso, deveria acontecer
a cada uma ou duas semanas.

A deciso de colocar a entrega em operao ou
no do cliente.

O PROJETO DIVIDIDO EM ITERAES

Prefira iteraes de uma a duas semanas.

No planeje as atividades com muita
antecedncia.

Deixe para planejar a iterao pouco antes de ela
iniciar.

Planejamento just-in-time uma forma de estar
sempre sintonizado com as mudanas de
requisitos e arquitetura.

No tente implementar coisas que viro depois.

Leve os prazos a srio.

O PROJETO DIVIDIDO EM ITERAES

Acompanhe a produtividade.

Se perceber que no vai vencer o cronograma,
convoque uma nova reunio de planejamento de
entregas e repasse algumas entregas para outros
ciclos.

Concentre-se em completar as tarefas, e no em
deixar vrias coisas inacabadas.

O PLANEJAMENTO DA ITERAO INICIA

CADA ITERAO
No planejamento, que inicia cada iterao
seleciona-se as histrias de usurio mais
importantes a serem desenvolvidas e partes de
sistema que falharam em testes de aceitao, os
quais so quebrados em tarefas de programao.

As tarefas sero escritas em cartes, assim como
as histrias de usurio.

Enquanto as histrias de usurio esto na
linguagem do cliente, as tarefas de programao
esto na linguagem dos desenvolvedores.

O PLANEJAMENTO DA ITERAO INICIA

CADA ITERAO
Cada desenvolvedor que seleciona uma tarefa
estima quanto tempo ela levar para ser
concluda.

Tarefas devem ser estimadas em um, dois ou trs
dias ideais de programao.

Um dia ideal de programao uma jornada de
trabalho normal em que uma pessoa dedique-se
unicamente ao projeto.

REGRAS XP DE GERENCIAMENTO
D equipe um espao de trabalho aberto e
dedicado

Defina uma jornada sustentvel

Inicie cada dia com uma reunio em p

A velocidade do projeto medida

Mova as pessoas

Conserte XP quando for inadequado

D EQUIPE UM ESPAO DE TRABALHO

ABERTO E DEDICADO
importante eliminar barreiras fsicas entre os
membros da equipe para melhorar a
comunicao.

Sugere-se colocar os computadores em um espao
central para a programao em pares e mesas
nas laterais da sala para que pessoas que
precisem trabalhar a ss no se desconectem do
ambiente.

Inclua uma rea para as reunies em p com um
quadro branco e uma mesa de reunies

DEFINA UMA JORNADA SUSTENTVEL

Trabalhar alm da jornada normal desgastante
e desmoralizante.

Se o projeto atrasa melhor reprogramar as
tarefas em uma release planning meeting.

Descubra a velocidade ideal para sua equipe e
atenha-se a ela.

No tente fazer uma equipe trabalhar na
velocidade de outra.

Faa planos realistas.

INICIE CADA DIA COM UMA REUNIO EM P

Em uma reunio tpica nem sempre todos
contribuem, mas pelo menos ouvem.

Mantenha o mnimo de pessoas o mnimo de
tempo em reunies.

As reunies em p no so perda de tempo, mas
uma forma rpida de manter a equipe
sincronizada, pois cada um dir o que fez ontem,
o que vai fazer hoje e o que o impede de
prosseguir.

A VELOCIDADE DO PROJETO MEDIDA

Conta-se ou estima-se quantas histrias de
usurio e tarefas de programao so
desenvolvidas em cada iterao.

A cada encontro de planejamento de iterao os
clientes podem selecionar um nmero de
histrias de usurio igual estimativa de
velocidade do projeto.

O mesmo vale para os programadores em relao
s tarefas de programao.

Isso permite que a equipe se recupere de
eventuais iteraes difceis.

Aumentos e diminuies de velocidade so
esperadas.

MOVA AS PESSOAS
Mobilidade de pessoas em projetos importante
para evitar perda de conhecimento e gargalos de
programao.

Ficar na dependncia de um nico funcionrio
perigoso.

Deve-se evitar criar ilhas de conhecimento
porque elas so susceptveis a perda.

Se precisar de conhecimento especializado,
contrate um consultor por prazo determinado.

CONSERTE XP QUANDO FOR INADEQUADO

No hesite em mudar aquilo que no funciona em
XP.

Isso no significa que se pode fazer qualquer
coisa.

Segue-se as regras at que se perceba que elas
precisam ser mudadas.

Todos os desenvolvedores devem saber o que se
espera deles e o que eles esperam dos outros.

A existncia de regras a melhor forma de
garantir isso.

REGRAS XP DE PROJETO (DESGIN)

Simplicidade

Escolha uma metfora de sistema

Use Cartes CRC durante reunies de projeto

Crie solues afiadas para reduzir risco

Nenhuma funcionalidade adicionada cedo

Use refatorao sempre e onde for possvel

SIMPLICIDADE
Um projeto simples sempre executado mais
rpido do que um projeto complexo.

Porm, simplicidade subjetiva e difcil de ser
medida.

Ento a equipe que deve decidir o que
simples.

Uma das melhores formas de obter simplicidade
em um projeto levar a srio o Design Pattern
Alta Coeso (Wazlawick, 2004).

QUALIDADES PARA OBTER SIMPLICIDADE

Testabilidade

Browseabilidade

Compreensibilidade e Explicabilidade

TESTABILIDADE
Pode-se escrever testes de unidade para verificar
se o cdigo est correto.

O sistema deve ser quebrado em unidades
testveis.

BROWSEABILIDADE
Pode-se encontrar os elementos quando se precisa
deles.

Bons nomes e uso de boas disciplinas como
polimorfismo, herana e delegao ajudam nisso.

COMPREENSIBILIDADE E
EXPLICABILIDADE
Compreensibilidade uma qualidade subjetiva
porque um sistema pode ser bastante
compreensvel para quem est trabalhando nele,
mas difcil para quem est de fora.

Ento essa propriedade pode ser definida em
termos de quo fcil explicar o sistema para
quem no participou do desenvolvimento.

ESCOLHA UMA METFORA DE SISTEMA

Uma boa metfora de sistema ajuda a explicar
seu funcionamento a algum de fora do projeto.

Deve-se evitar que a compreenso sobre o
sistema resida em pilhas de documentos.

Nomes significativos e padres de nomeao de
elementos de programa devem ser
cuidadosamente escolhidos e seguidos para que
fragmentos de cdigo sejam efetivamente
reusveis.

USE CARTES CRC DURANTE REUNIES

DE PROJETO
Trata-se de uma tcnica para encontrar
responsabilidades e colaboraes entre objetos.

A equipe se rene em torno de uma mesa e cada
membro recebe um ou mais cartes
representando instncias de diferentes classes.

Uma atividade (operao ou consulta) simulada
e a medida que ela ocorre os detentores dos
cartes anotam responsabilidades do objeto no
lado esquerdo do carto e colaboraes do objeto
no lado direito.

A documentao dos processos pode ser feita com
diagramas de seqncia ou de comunicao da
UML.

CRIE SOLUES AFIADAS PARA REDUZIR RISCO

Em face de riscos importantes de projeto deve-se
explorar o risco de forma definitiva e exclusiva,
ou seja, uma soluo afiada ou spike para o
problema identificado.

Um spike ento um desenvolvimento ou teste
projetado especificamente para analisar e
possivelmente resolver um risco.

Caso o risco se mantenha, deve-se colocar um par
de programadores durante uma ou duas semanas
exclusivamente trabalhando para examinar e
mitigar este risco.

A maioria dos spikes no sero aproveitados no
projeto, podendo ser classificados como uma das
formas de prototipao (throw-away).

NENHUMA FUNCIONALIDADE
ADICIONADA CEDO
Deve-se evitar a tentao de adicionar
funcionalidade desnecessria s porque seria fcil
fazer isso agora e deixaria o sistema melhor.

Apenas o necessrio feito no sistema.

Desenvolver o que no necessrio jogar tempo
fora.

Manter o cdigo aberto a possveis mudanas
futuras tem a ver com simplicidade de projeto,
mas adicionar funcionalidade ou flexibilidade
desnecessria, sempre deixa o projeto mais
complexo.

Requisitos futuros s devem ser considerados
quando estritamente exigidos pelo cliente.

USE REFATORAO SEMPRE E ONDE FOR

POSSVEL

Refatore sem pena.

XP no recomenda que se continue usando design
antigo e ruim s porque ele funciona.

Deve-se remover redundncias, eliminar
funcionalidades desnecessrias e rejuvenecer
designs antiquados.

REGRAS XP PARA CODIFICAO DE

PROGRAMAS
O cliente est sempre disponvel

O cdigo deve ser escrito de acordo com padres
aceitos

Escreva o teste de unidade primeiro

Todo o cdigo produzido por pares

S um par faz integrao de cdigo de cada vez

Integrao deve ser freqente

Defina um computador exclusivo para integrao

A posse do cdigo deve ser coletiva

O CLIENTE EST SEMPRE DISPONVEL

XP necessita que o cliente esteja disponvel

preferencialmente pessoalmente ao longo de todo o processo
de desenvolvimento.
Entretanto, devido ao longo tempo de um projeto, a
empresa cliente pode ser tentada a associar um funcionrio
pouco experiente ou estagirio ao projeto. Ele no serve.
Deve ser um especialista. Ele dever escrever as histrias
de usurio, bem como prioriz-las e negociar sua incluso
em iteraes.
Pode parecer um investimento alto em tempo de
funcionrios, mas compensado por ser desnecessrio um
levantamento de requisitos detalhado ao incio, bem como
pela no entrega de um sistema inadequado.

O CDIGO DEVE SER ESCRITO DE ACORDO

COM PADRES ACEITOS
Padres de codificao mantm o cdigo
compreensvel e passvel de refatorao por toda
a equipe.

Alm disso, cdigo que se parece encoraja a posse
coletiva do mesmo.

ESCREVA O TESTE DE UNIDADE PRIMEIRO

Usualmente, escrever o teste antes do cdigo
ajuda a escrever o cdigo melhor.

O tempo para escrever o teste e cdigo passa a
ser o mesmo que se gastaria para escrever
apenas o cdigo.

TODO O CDIGO PRODUZIDO POR PARES

Embora parea contra-sensual, duas pessoas
trabalhando em um computador produzem tanto
cdigo quanto duas pessoas trabalhando
separadamente, mas com mais qualidade.

Embora seja recomendado que haja um
programador mais experiente, a relao no deve
ser de professor/aluno, mas de iguais.

S UM PAR FAZ INTEGRAO DE CDIGO

DE CADA VEZ
A integrao em paralelo pode trazer problemas
de compatibilidade imprevistos, pois duas partes
do sistema que nunca foram testadas juntas
acabam sendo integradas sem serem testadas.

Deve haver verses claramente definidas do
produto.

Ento, para que equipes trabalhando em paralelo
no tenham problemas na hora de integrar seu
cdigo ao produto, elas devem esperar a sua vez.

Deve-se estabelecer turnos de integrao que
sejam obedecidos.

INTEGRAO DEVE SER FREQENTE

Desenvolvedores devem estar integrando cdigo
ao repositrio a cada poucas horas.

Postergar integrao pode agravar o problema de
todos estarem trabalhando em verses
desatualizadas do sistema.

DEFINA UM COMPUTADOR EXCLUSIVO PARA

INTEGRAO

Este computador funciona como uma ficha de exclusividade

(token) para a integrao.
A existncia dele no ambiente de trabalho permite que toda a
equipe veja quem est integrando funcionalidade e qual a
funcionalidade.
O resultado da integrao deve passar nos testes de unidade, de
forma que se obtm estabilidade em cada verso e localidade nas
mudanas e possveis erros.
Se os testes de unidade falharem, a unidade deve ser depurada.
Se a atividade de integrao levar mais do que cerca de dez
minutos, porque a unidade ainda precisa de alguma depurao
adicional antes de ser integrada.
Neste caso, a integrao deve ser abortada, retornando o sistema
ultima verso estvel, e a depurao da unidade deve seguir
sendo feita pelo par.

A POSSE DO CDIGO DEVE SER COLETIVA

No devem ser criados gargalos pela existncia de
donos de cdigo.

Todos devem ter autorizao para modificar,
consertar ou refatorar partes do sistema.

Para isso funcionar os desenvolvedores devem
sempre desenvolver os testes de unidade
juntamente com o cdigo, seja novo ou modificado.

Desta forma existe sempre uma garantia de que o
software satisfaz as condies de funcionamento.

No ter um dono de partes do sistema tambm
diminui o impacto da perda de membros da equipe.

REGRAS XP PARA TESTE DE SOFTWARE

Todo o cdigo deve ter testes de unidade

Todo cdigo deve passar pelos testes de unidade
antes de ser entregue

Quando um erro de funcionalidade encontrado,
testes so criados

Testes de aceitao so executados com
freqncia e os resultados so publicados

TODO O CDIGO DEVE TER TESTES DE

UNIDADE

Esta uma das pedras fundamentais do XP.

Inicialmente o desenvolvedor XP deve criar ou obter um
framework de teste de unidade.
Depois ele deve testar todas as classes do sistema,
ignorando usualmente os mtodos bsicos triviais como
getters e setters.
Testes de unidade favorecem a posse coletiva do cdigo
porque protegem o cdigo de ser acidentalmente danificado.
Um bom local para baixar frameworks para testes de
unidade para vrias linguagens
http://www.xprogramming.com/software.
Alm disso, em http://www.junit.org/ pode-se encontrar o
JUnit, que vem se tornando um padro para
desenvolvimento dirigido por testes em Java.

TODO CDIGO DEVE PASSAR PELOS TESTES DE

UNIDADE ANTES DE SER ENTREGUE

Exigir que o cdigo passe por todos os testes de

unidade antes de ser integrado ajuda a garantir
que sua funcionalidade est corretamente
implementada.

Os testes de unidade tambm favorecem a
refatorao, porque protegem o cdigo de
mudanas indesejadas de funcionalidade.

A introduo de nova funcionalidade dever
provocar a adio e mais testes no teste de
unidade especfico.

QUANDO UM ERRO DE FUNCIONALIDADE

ENCONTRADO, TESTES SO CRIADOS
Um erro de funcionalidade identificado exige que
testes de aceitao sejam criados para proteger o
sistema.

Assim, os clientes explicam claramente aos
desenvolvedores o que eles esperam que seja
modificado.

TESTES DE ACEITAO SO EXECUTADOS COM

FREQNCIA E OS RESULTADOS SO
PUBLICADOS

Testes de aceitao so criados a partir de

histrias de usurio.

Durante uma iterao, as histrias de usurio
selecionadas sero traduzidas em testes de
aceitao.

Estes testes so do tipo caixa preta e
representam uma ou mais funcionalidades
desejadas.

Testes de aceitao devem ser automatizados, de
forma que possam ser executados com freqncia.

BIBLIOGRAFIA

Beck, K. et al. (2001). Manifesto for Agile Software

Development. Disponvel em: http://agilemanifesto.org/.
Consultado em: 08/03/2010.
Standish Group (1995). Chaos Report. Acessvel em:
http://www.projectsmart.co.uk/docs/chaos-report.pdf.
Consultado em: 10/03/2010.
Takeuchi, H., Nonaka, I. (1986). The new product
development game. Harvard Business Review 137-146.
January-February.
Wazlawick, R. S. (2004). Anlise e Projeto de Sistemas de
Informao Orientados a Objetos. Rio de Janeiro: Elsevier.
Wells, D. (2009). The Rules of Extreme Programming.
Disponvel em:
http://www.extremeprogramming.org/rules.html. Acessado
em 10/03/2010.