8/11/2019 1.3 - Modelos geis.pdf
1/84
MODELOS GEIS PROF. RAUL SIDNEIWAZLAWICKUFSC-CTC-INE2010
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
13/84
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
15/84
MODELO SCRUM
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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
.
8/11/2019 1.3 - Modelos geis.pdf
19/84
VALORES
Simplicidade
Respeito Comunicao Feedback
Coragem
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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
.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
29/84
EQUIPE COESA (WHOLE TEAM) O cliente faz parte da equipe de desenvolvimento.
8/11/2019 1.3 - Modelos geis.pdf
30/84
REUNIES EM P(STAND-UP MEETING). Como no caso de Scrum, reunies em p tendem a
serem mais objetivas.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
32/84
8/11/2019 1.3 - Modelos geis.pdf
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, .
8/11/2019 1.3 - Modelos geis.pdf
34/84
POSSE COLETIVA (COLLECTIVEOWNERSHIP) O cdigo no tem dono e no necessrio pedir
permisso a ningum para modific-lo.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
38/84
DESENVOLVIMENTO ORIENTADO A TESTES
(TEST DRIVEN DEVELOPMENT)Antes de programar uma unidade deve-se
estabelecer os testes pelos quais ela deverpassar.
8/11/2019 1.3 - Modelos geis.pdf
39/84
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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
.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
48/84
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
57/84
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
60/84
8/11/2019 1.3 - Modelos geis.pdf
61/84
QUALIDADES PARA OBTER SIMPLICIDADE Testabilidade Browseabilidade Compreensibilidade e Explicabilidade
8/11/2019 1.3 - Modelos geis.pdf
62/84
TESTABILIDADE Pode-se escrever testes de unidade para verificar
se o cdigo est correto. O sistema deve ser quebrado em unidades
testveis.
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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
.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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
8/11/2019 1.3 - Modelos geis.pdf
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.
8/11/2019 1.3 - Modelos geis.pdf
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.
Top Related