1.3 - modelos Ágeis.pdf

8/11/2019 1.3 - Modelos geis.pdf

1/84

MODELOS GEIS PROF. RAUL SIDNEIWAZLAWICKUFSC-CTC-INE2010


2/84

MODELOSGEIS

Os modelos geis de desenvolvimento de software

seguem uma filosofia diferente dos modelosprescritivos.Ao invs de apresentar uma receita de bolo com

,em valores humanos e sociais.


3/84

MANIFESTOGIL

Ns estamos descobrindo formas melhores de desenvolversoftware fazendo e ajudando outros a fazer. Atravs deste

trabalho chegamos aos seguintes valores: Indivduos e interaes esto acima de processos e

ferramentas.

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, ositens direita valero mais.


4/84

PRINCPIOS DO MANIFESTO GIL

Nossa maior prioridade satisfazer o cliente atravs da entregarpida e contnua de software com valor.

Mudanas nos requisitos so bem vindas, mesmo nas etapasfinais do projeto. Processos geis usam a mudana como umdiferencial 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 doprojeto.

Construa projetos em torno de indivduos motivados. D a eles oambiente e o suporte e confie que eles faro o trabalho.

O meio mais eficiente e efetivo de tratar a comunicao entre epara a equipe de desenvolvimento a conversa face a face.


5/84

PRINCPIOS DO MANIFESTO GIL

Software funcionando a medida primordial de progresso.

Processos geis promovem desenvolvimento sustentado. Osfinanciadores, usurios e desenvolvedores devem sercapazes de manter o ritmo indefinidamente.

Ateno contnua excelncia tcnica e bom projetome ora a ag a e.

Simplicidade a arte de maximizar a quantidade detrabalho 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 deacordo.


6/84

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,

um ms.


7/84

PERFIS

O Scrum master, que no um gerente no

sentido dos modelos prescritivos. O Scrum masterno um lder, j que as equipes so auto-organizadas, mas um facilitador (pessoa queconhece bem o modelo e resolvedor de conflitos

Oproduct owner, ou seja, a pessoa responsvelpelo projeto em si. Oproduct owner tem, entreoutras atribuies, a de indicar quais so os

requisitos mais importantes a serem tratados emcada sprint. Oproduct owner o responsvel peloROI(Return Of Investment), e tambm porconhecer e avaliar as necessidades do cliente.


8/84

SCRUM TEAM

a equipe de desenvolvimento.

Essa equipe no necessariamente dividida empapeis como analista, projetista e programador,mas todos interagem para desenvolver o produto

. Usualmente so recomendadas equipes de 6 a 10

pessoas. No caso de projetos muito grandes possvel

aplicar o conceito de Scrum of Scrums, ondevrios Scrum teams trabalham em paralelo ecada um contribui com uma pessoa para aformao do Scrum of Scrums, quando ento asvrias equipes so sincronizadas.


9/84

PRODUCT BACKLOG

As funcionalidades a serem implementadas em

cada projeto (requisitos) so mantidas em umalista chamada deproduct backlog. Um dos princpios das metodologias geis usado

. Oproduct backlogno precisa ento ser completo

no incio do projeto. Pode-se iniciar apenas com as funcionalidades

mais evidentes para depois, medida que oprojeto avana tratar novas funcionalidades quevo sendo descobertas.


10/84

SPRINT

No incio de cada sprint feito um sprint

planning meeting, no qual a equipe prioriza oselementos doproduct backloga seremimplementados e transfere estes elementos do

roduct backlo ara o s rint backlo ou se a a

lista de funcionalidades a serem implementadasno ciclo que se inicia.

A equipe se compromete a desenvolver as

funcionalidades e oproduct owner se comprometea no trazer novas funcionalidades durante omesmo sprint.

Se novas funcionalidades forem descobertas,

sero abordadas em sprints posteriores.


11/84

SPRINT BACKLOG

Pode-se dizer que os dois backlogs tm naturezas

diferentes: Oproduct backlogapresenta requisitos de alto nvel,

bastante voltados s necessidades diretas do cliente. J o s rint backlo a resenta uma viso desses

requisitos de forma mais voltada maneira como aequipe vai desenvolv-los.


12/84

Durante o sprint, cabe aoproduct owner manter o

sprint backlogatualizado, indicando as tarefas jconcludas e as ainda por concluir,preferencialmente mostradas em um grficoatualizado diariamente e vista de todos.


13/84


14/84

DAILYSCRUM

Mais importante ainda, o modelo sugere que a equiperealize uma reunio diria, chamada daily scrum, onde o

objetivo que cada membro da equipe fale sobre o que fezno dia anterior, o que vai fazer no dia que se segue e, se foro caso, o que o impede de prosseguir.

.

Por isso, se sugere que sejam feitas com as pessoas em p eem frente a um quadro de anotaes.

Alm disso, recomenda-se que sejam feitas logo aps oalmoo, quando os participantes estaro mais imersos nas

questes do trabalho (longe dos problemas pessoais), almde ser uma boa maneira de dissipar o cansao que atinge osdesenvolvedores no incio da tarde.


15/84

MODELO SCRUM


16/84

SPRINT DEVEM SEGUIR A FILOSOFIAPDCA 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 ascausas fundamentais do problema, elaborar um plano deao para atingir o objetivo ou resolver o problema.

.

Check: avaliar e monitorar periodicamente os resultados.Avaliar os processos utilizados. Produzir relatrios, senecessrio.

Act: agir de acordo com os planos ou melhorar os planos e

processos se necessrio.


17/84

ORIGENS

A concepo inicial do Scrum deu-se na indstria

automobilstica (Takeuchi & Nonaka, 1986), e omodelo pode ser adaptado a vrias outras reasdiferentes da produo de software.

,

deve sua popularidade inicialmente ao trabalhode Schwaber.

Uma boa referncia para quem deseja adotar o

mtodo o livro de Schwaber e Beedle (2001), queapresenta o mtodo de forma completa esistemtica.


18/84

XP EXTREME PROGRAMMING

um modelo gil inicialmente adequado a

equipes pequenas e mdias que baseado emuma srie de valores, princpios e regras.XPsurgiu no final da dcada de 1990, nos

.


19/84

VALORES

Simplicidade

Respeito Comunicao Feedback

Coragem


20/84

SIMPLICIDADE

Segundo o Chaos Report (Standish Group, 1995)

mais da metade das funcionalidades introduzidasem sistemas nunca so usadas. XP sugere como valor a simplicidade, ou seja, a

efetivamente necessrias e no naquelas quepoderiam talvez ser necessrias, mas que aindano se tem evidncia de que so essenciais.


21/84

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

.


22/84

COMUNICAO

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

XP preconiza comunicao de boa qualidade,

videoconferncias, videoconferncias, ao invs detelefonemas, telefonemas ao invs de emails eassim por diante.

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


23/84

FEEDBACK

O projeto de software reconhecidamente umempreendimento de alto risco.

Cientes disso, os desenvolvedores devem buscarobterfeedback o quanto antes para que eventuais

rapidamente possvel antes que os danos sealastrem e o custo da correo seja alto.


24/84

CORAGEM

Pode-se dizer que a nica coisa constante noprojeto de um software a necessidade demudana.

Para os desenvolvedoresXP necessrio confiar

para ter a coragem de abraar as inevitveismodificaes ao invs de simplesmente ignor-las, por estarem eventualmente fora do contratoformal, ou por serem muito difceis de acomodar.


25/84

PRINCPIOS SO DEFINIDOS A PARTIR DOSVALORES

Priorizao de funcionalidades mais importantesde forma que, se o trabalho no puder ser todoconcludo, pelo menos as partes mais importantestero sido.

, ,

considerar a mudana como algo positivo, quedeve ser considerado parte do processo.

Qualidade: pequenos ganhos a curto prazo pelo

sacrifcio da qualidade no so compensadospelas perdas a mdio e longo prazo


26/84

PRTICAS

Jogo de planejamento

Metfora Equipe coesa Reunies em p

Desenvolvimento

orientado a testes Refatorao Integrao contnua

Projeto simplesVerses pequenas Ritmo sustentvel

Posse coletiva Programao em pares Padres de codificao

Testes de aceitao


27/84

JOGO DE PLANEJAMENTO (PLANNINGGAME) Semanalmente a equipe deve se reunir com o

cliente para priorizar as funcionalidades a seremdesenvolvidas.

Cabe ao cliente identificar as principais

estimar quais podem ser implementadas no ciclosemanal 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 contratosrgidos usualmente estabelecidos.


28/84

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.


29/84

EQUIPE COESA (WHOLE TEAM) O cliente faz parte da equipe de desenvolvimento.


30/84

REUNIES EM P(STAND-UP MEETING). Como no caso de Scrum, reunies em p tendem a

serem mais objetivas.


31/84

PROJETO SIMPLES(SIMPLE DESIGN) Isso implica em atender a funcionalidade

solicitada pelo cliente sem sofisticardesnecessariamente.

Deve-se fazer o que o cliente precisa, no o que o.

Por vezes, projeto simples pode ser confundidocom 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.


32/84


33/84

RITMO SUSTENTVEL (SUSTAINABLEPACE). 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, .


34/84

POSSE COLETIVA (COLLECTIVEOWNERSHIP) O cdigo no tem dono e no necessrio pedir

permisso a ningum para modific-lo.


35/84

PROGRAMAO EM PARES(PAIRPROGRAMMING)A programao sempre feita por duas pessoas

em cada computador. Usualmente trata-se de um programador mais

experiente e um aprendiz.apren z eve usar a m qu na enquan o o ma s

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.


36/84

PADRES DE CODIFICAO (CODINGSTANDARDS)A equipe deve estabelecer e seguir padres de

codificao, de forma que parecer que o cdigofoi todo desenvolvido pela mesma pessoa, mesmoque tenham sido dezenas.


37/84

TESTES DE ACEITAO (CUSTOMER TESTS) So testes planejados e conduzidos pela equipe

em conjunto com o cliente para verificar sedeterminados requisitos foram atendidos.


38/84

DESENVOLVIMENTO ORIENTADO A TESTES

(TEST DRIVEN DEVELOPMENT)Antes de programar uma unidade deve-se

estabelecer os testes pelos quais ela deverpassar.


39/84


40/84

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.


41/84

REGRAS XP Wells (2009) vai mais alm das prticas XP

apontando um conjunto sucinto e bastanteobjetivo de regras para XP.

Ele divide as regras em 5 grandes grupos:

Gerncia Projeto Codificao

Teste


42/84

REGRAS XP DE PLANEJAMENTO Escrever histrias de usurio

O planejamento de entregas cria o cronograma deentregas Faa entregas pequenas freqentes

projeto ivi i o em iteraes O planejamento da iterao inicia cada iterao


43/84

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

co sas que e es prec sam que o s s ema aa para

eles. Podem ser usadas para definir os testes de

aceitao.


44/84

ESCREVER HISTRIAS DE USURIOA 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.

Menos de uma semana significa que a histriaest em um nvel de detalhe muito alto e precisaser combinada com outras.

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


45/84

O PLANEJAMENTO DE ENTREGAS CRIA O

CRONOGRAMA DE ENTREGAS

feito um encontro de planejamento de entregaspara delinear o projeto como um todo.

importante que os tcnicos tomem as decisestcnicas e os administradores as decises de

.

Deve-se estimar o tempo de cada histria deusurio em termos de semanas de programaoideais e priorizar as histrias mais importantesdo ponto de vista do cliente.

Uma semana de programao ideal aquela emque uma pessoa trabalha todas as horas dasemana unicamente em um projeto, dedicando-se

apenas a ele.


46/84

O PLANEJAMENTO DE ENTREGAS CRIA O

CRONOGRAMA DE ENTREGAS

As histrias so agrupadas em iteraes, que sso planejadas pouco antes de iniciarem.

Essa priorizao pode ser feita com histriasimpressas em cartes que so movidos na mesa

.


47/84

FAA ENTREGAS PEQUENAS FREQENTESAlgumas equipes entregam software

diariamente, mas no pior caso, deveria acontecera cada uma ou duas semanas.

A deciso de colocar a entrega em operao ou.


48/84


49/84

O PROJETO DIVIDIDO EM ITERAESAcompanhe a produtividade. Se perceber que no vai vencer o cronograma,

convoque uma nova reunio de planejamento deentregas e repasse algumas entregas para outros

.

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

O


50/84

O PLANEJAMENTO DA ITERAO INICIA

CADA ITERAO

No planejamento, que inicia cada iteraoseleciona-se as histrias de usurio mais

importantes a serem desenvolvidas e partes desistema que falharam em testes de aceitao, os

uais so uebrados em tarefas de ro rama o.

As tarefas sero escritas em cartes, assim comoas histrias de usurio. Enquanto as histrias de usurio esto na

linguagem do cliente, as tarefas de programaoesto na linguagem dos desenvolvedores.

O


51/84

O PLANEJAMENTO DA ITERAO INICIA

CADA ITERAO

Cada desenvolvedor que seleciona uma tarefaestima quanto tempo ela levar para ser

concluda. Tarefas devem ser estimadas em um, dois ou trs

.

Um dia ideal de programao uma jornada detrabalho normal em que uma pessoa dedique-seunicamente ao projeto.


52/84

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

ve oci a e o projeto me i a Mova as pessoas Conserte XP quando for inadequado

D EQUIPE UM ESPAO DE TRABALHO


53/84

D EQUIPE UM ESPAO DE TRABALHO

ABERTO E DEDICADO

importante eliminar barreiras fsicas entre osmembros da equipe para melhorar a

comunicao. Sugere-se colocar os computadores em um espao

nas laterais da sala para que pessoas queprecisem trabalhar a ss no se desconectem doambiente.

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


54/84

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.escu ra a ve oc a e ea para sua equ pe e

atenha-se a ela. No tente fazer uma equipe trabalhar na

velocidade de outra.

Faa planos realistas.


55/84

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.s reun es em p n o s o per a e empo, mas

uma forma rpida de manter a equipesincronizada, pois cada um dir o que fez ontem,o que vai fazer hoje e o que o impede deprosseguir.


56/84

AVELOCIDADE 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

histrias de usurio igual estimativa develocidade 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.


57/84


58/84

CONSERTE XP QUANDO FOR INADEQUADO No hesite em mudar aquilo que no funciona em

XP. Isso no significa que se pode fazer qualquer

coisa.egue-se as regras a que se perce a que e as

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 degarantir isso.


59/84

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


60/84


61/84

QUALIDADES PARA OBTER SIMPLICIDADE Testabilidade Browseabilidade Compreensibilidade e Explicabilidade


62/84

TESTABILIDADE Pode-se escrever testes de unidade para verificar

se o cdigo est correto. O sistema deve ser quebrado em unidades

testveis.


63/84

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


64/84

EXPLICABILIDADE Compreensibilidade uma qualidade subjetiva

porque um sistema pode ser bastante

compreensvel para quem est trabalhando nele,mas difcil para quem est de fora.

termos de quo fcil explicar o sistema paraquem no participou do desenvolvimento.


65/84

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.omes s gn ca vos e pa r es e nomea o e

elementos de programa devem sercuidadosamente escolhidos e seguidos para quefragmentos de cdigo sejam efetivamentereusveis.

USE CARTES CRC DURANTE REUNIES


66/84

DE PROJETO

Trata-se de uma tcnica para encontrarresponsabilidades e colaboraes entre objetos.

A equipe se rene em torno de uma mesa e cadamembro recebe um ou mais cartes

.

Uma atividade (operao ou consulta) simuladae a medida que ela ocorre os detentores doscartes anotam responsabilidades do objeto nolado 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


67/84

Em face de riscos importantes de projeto deve-seexplorar 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 epossivelmente resolver um risco.

Caso o risco se mantenha, deve-se colocar um parde programadores durante uma ou duas semanasexclusivamente trabalhando para examinar e

mitigar este risco.A maioria dos spikes no sero aproveitados no

projeto, podendo ser classificados como uma dasformas de prototipao (throw-away).

NENHUMA FUNCIONALIDADE


68/84

ADICIONADA CEDO

Deve-se evitar a tentao de adicionarfuncionalidade desnecessria s porque seria fcil

fazer isso agora e deixaria o sistema melhor.Apenas o necessrio feito no sistema.

esenvo ver o que n o necess r o ogar empo

fora. Manter o cdigo aberto a possveis mudanas

futuras tem a ver com simplicidade de projeto,mas adicionar funcionalidade ou flexibilidadedesnecessria, sempre deixa o projeto maiscomplexo.

Requisitos futuros s devem ser considerados

quando estritamente exigidos pelo cliente.

USE REFATORAO SEMPRE E ONDE FOR


69/84

POSSVEL

Refatore sem pena. XP no recomenda que se continue usando design

antigo e ruim s porque ele funciona. Deve-se remover redundncias, eliminar

unc ona a es esnecess r as e re uvenecer

designs antiquados.

REGRAS XP PARA CODIFICAO DE


70/84

PROGRAMAS O cliente est sempre disponvel O cdigo deve ser escrito de acordo com padres

aceitos Escreva o teste de unidade primeiro

o o o c igo pro uzi o por pares S um par faz integrao de cdigo de cada vez Integrao deve ser freqente Defina um computador exclusivo para integraoA posse do cdigo deve ser coletiva


71/84

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. .

Deve ser um especialista. Ele dever escrever as histriasde usurio, bem como prioriz-las e negociar sua inclusoem iteraes.

Pode parecer um investimento alto em tempo de

funcionrios, mas compensado por ser desnecessrio umlevantamento de requisitos detalhado ao incio, bem comopela no entrega de um sistema inadequado.

O CDIGO DEVE SER ESCRITO DE ACORDO


72/84

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

.


73/84

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.


74/84

TODO O CDIGO PRODUZIDO POR PARES Embora parea contra-sensual, duas pessoas

trabalhando em um computador produzem tanto

cdigo quanto duas pessoas trabalhandoseparadamente, mas com mais qualidade.

programador mais experiente, a relao no deveser de professor/aluno, mas de iguais.

S UM PAR FAZ INTEGRAO DE CDIGO


75/84

DE CADA VEZA integrao em paralelo pode trazer problemas

de compatibilidade imprevistos, pois duas partes

do sistema que nunca foram testadas juntasacabam sendo integradas sem serem testadas.

produto. Ento, para que equipes trabalhando em paralelo

no tenham problemas na hora de integrar seucdigo ao produto, elas devem esperar a sua vez.

Deve-se estabelecer turnos de integrao quesejam obedecidos.


76/84

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.

DEFINA UM COMPUTADOR EXCLUSIVO PARA


77/84

INTEGRAO Este computador funciona como uma ficha de exclusividade

(token) para a integrao.

A existncia dele no ambiente de trabalho permite que toda aequipe veja quem est integrando funcionalidade e qual afuncionalidade.

resu a o a n egra o eve passar nos es es e un a e, e

forma que se obtm estabilidade em cada verso e localidade nasmudanas 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 depuraoadicional 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.


78/84

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.ara sso unc onar os esenvo ve ores evem

sempre desenvolver os testes de unidadejuntamente 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.


79/84

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,

es es s o cr a os

Testes de aceitao so executados comfreqncia e os resultados so publicados

TODO O CDIGO DEVE TER TESTES DE


80/84

UNIDADE Esta uma das pedras fundamentais do XP.

Inicialmente o desenvolvedorXPdeve criar ou obter um

framework de teste de unidade. Depois ele deve testar todas as classes do sistema,

ignorando usualmente os mtodos bsicos triviais comoge ers e se ers.

Testes de unidade favorecem a posse coletiva do cdigoporque protegem o cdigo de ser acidentalmente danificado.

Um bom local para baixarframeworks para testes deunidade 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 paradesenvolvimento dirigido por testes em Java.

TODO CDIGO DEVE PASSAR PELOS TESTES DE


81/84

UNIDADE ANTES DE SER ENTREGUE

Exigir que o cdigo passe por todos os testes deunidade antes de ser integrado ajuda a garantir

que sua funcionalidade est corretamenteimplementada.

refatorao, porque protegem o cdigo demudanas 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


82/84

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

modificado.

TESTES DE ACEITAO SO EXECUTADOS COMFREQNCIA E OS RESULTADOS SO


83/84

PUBLICADOS

Testes de aceitao so criados a partir dehistrias de usurio.

Durante uma iterao, as histrias de usurioselecionadas sero traduzidas em testes de

.

Estes testes so do tipo caixa preta erepresentam uma ou mais funcionalidadesdesejadas.

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


84/84

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.

.

Takeuchi, H., Nonaka, I. (1986). The new productdevelopment game. Harvard Business Review 137-146.January-February.

Wazlawick, R. S. (2004). Anlise e Projeto de Sistemas deInformao Orientados a Objetos. Rio de Janeiro: Elsevier.

Wells, D. (2009). The Rules of Extreme Programming.Disponvel em:http://www.extremeprogramming.org/rules.html. Acessadoem 10/03/2010.

1.3 - modelos Ágeis.pdf

Documents