1 3 - Modelos Ágeis

Prévia do material em texto

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 invés de apresentar uma receita de bolo com 
fases ou tarefas a serem executados, eles focam fases ou tarefas a serem executados, eles focam 
em valores humanos e sociais.
MANIFESTO ÁGIL
� Nós estamos descobrindo formas melhores de desenvolver 
software fazendo e ajudando outros a fazer. Através deste 
trabalho chegamos aos seguintes valores:
� Indivíduos e interações estão acima de processos e 
ferramentas.
� Software funcionando está acima de documentação � Software funcionando está acima de documentação 
compreensível.
� Colaboração do cliente está acima de negociação de 
contrato.
� Responder às mudanças está acima de seguir um plano.
� Ou seja, enquanto forem valorizados os itens à esquerda, os 
itens à direita valerão mais.
PRINCÍPIOS DO MANIFESTO ÁGIL
� Nossa maior prioridade é satisfazer o cliente através da entrega 
rápida e contínua de software com valor.
� Mudanças nos requisitos são bem vindas, mesmo nas etapas 
finais do projeto. Processos ágeis usam a mudança como um 
diferencial competitivo para o cliente.
� Entregar software freqüentemente, com intervalos que viam de Entregar software freqüentemente, 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 indivíduos motivados. Dê a eles o 
ambiente e o suporte e confie que eles farão o trabalho.
� O meio mais eficiente e efetivo de tratar a comunicação entre e 
para a equipe de desenvolvimento é a conversa face a face.
PRINCÍPIOS DO MANIFESTO ÁGIL
� Software funcionando é a medida primordial de progresso.
� Processos ágeis promovem desenvolvimento sustentado. Os 
financiadores, usuários e desenvolvedores devem ser 
capazes de manter o ritmo indefinidamente.
� Atenção contínua à excelência técnica e bom projeto 
melhora a agilidade.melhora a agilidade.
� Simplicidade – a arte de maximizar a quantidade de 
trabalho não 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 então ajusta seu comportamento de 
acordo.
SCRUM
� Scrum é um modelo ágil para gestão 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 desenvolvimento, usualmente de duas semanas a 
um mês.
PERFIS
� O Scrum master, que não é um gerente no 
sentido dos modelos prescritivos. O Scrum master
não é um líder, já que as equipes são auto-
organizadas, mas um facilitador (pessoa que 
conhece bem o modelo) e resolvedor de conflitosconhece bem o modelo) e resolvedor de conflitos
� O product owner, ou seja, a pessoa responsável 
pelo projeto em si. O product owner tem, entre 
outras atribuições, a de indicar quais são os 
requisitos mais importantes a serem tratados em 
cada sprint. O product owner é o responsável pelo 
ROI (Return Of Investment), e também por 
conhecer e avaliar as necessidades do cliente.
SCRUM TEAM
� É a equipe de desenvolvimento. 
� Essa equipe não é necessariamente dividida em 
papeis como analista, projetista e programador, 
mas todos interagem para desenvolver o produto 
em conjunto. em conjunto. 
� Usualmente são recomendadas equipes de 6 a 10 
pessoas. 
� No caso de projetos muito grandes é possível 
aplicar o conceito de Scrum of Scrums, onde 
vários Scrum teams trabalham em paralelo e 
cada um contribui com uma pessoa para a 
formação do Scrum of Scrums, quando então as 
várias equipes são sincronizadas.
PRODUCT BACKLOG
� As funcionalidades a serem implementadas em 
cada projeto (requisitos) são mantidas em uma 
lista chamada de product backlog. 
� Um dos princípios das metodologias ágeis é usado 
aqui: adaptação ao invés e planejamento. aqui: adaptação ao invés e planejamento. 
� O product backlog não precisa então ser completo 
no início do projeto. 
� Pode-se iniciar apenas com as funcionalidades 
mais evidentes para depois, à medida que o 
projeto avança tratar novas funcionalidades que 
vão sendo descobertas.
SPRINT
� No início 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 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 não trazer novas funcionalidades durante o 
mesmo sprint. 
� Se novas funcionalidades forem descobertas, 
serão abordadas em sprints posteriores.
SPRINT BACKLOG
� Pode-se dizer que os dois backlogs têm naturezas 
diferentes: 
� O product backlog apresenta requisitos de alto nível, 
bastante voltados às necessidades diretas do cliente. 
� Já o sprint backlog apresenta uma visão desses � Já o sprint backlog apresenta uma visão 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á 
concluídas e as ainda por concluir, 
preferencialmente mostradas em um gráfico 
atualizado diariamente e à vista de todos.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.� O sprint review meeting avalia o sucesso do plano.
DAILY SCRUM
� Mais importante ainda, o modelo sugere que a equipe 
realize uma reunião diária, 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 reuniões devem ser rápidas. � Essas reuniões devem ser rápidas. 
� Por isso, se sugere que sejam feitas com as pessoas em pé e 
em frente a um quadro de anotações. 
� Além disso, recomenda-se que sejam feitas logo após o 
almoço, quando os participantes estarão mais imersos nas 
questões do trabalho (longe dos problemas pessoais), além 
de ser uma boa maneira de dissipar o cansaço que atinge os 
desenvolvedores no início 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 fenômeno ou os 
dados relacionados ao problema, analisar o processo, ou as 
causas fundamentais do problema, elaborar um plano de 
ação para atingir o objetivo ou resolver o problema.
� Do: executar as atividades previstas no plano de ação.� Do: executar as atividades previstas no plano de ação.
� Check: avaliar e monitorar periodicamente os resultados. 
Avaliar os processos utilizados. Produzir relatórios, se 
necessário.
� Act: agir de acordo com os planos ou melhorar os planos e 
processos se necessário.
ORIGENS
� A concepção inicial do Scrum deu-se na indústria 
automobilística (Takeuchi & Nonaka, 1986), e o 
modelo pode ser adaptado a várias outras áreas 
diferentes da produção de software. 
� Na área de desenvolvimento de software, Scrum� Na área de desenvolvimento de software, Scrum
deve sua popularidade inicialmente ao trabalho 
de Schwaber. 
� Uma boa referência para quemdeseja adotar o 
método é o livro de Schwaber e Beedle (2001), que 
apresenta o método de forma completa e 
sistemática.
XP – EXTREME PROGRAMMING
� É um modelo ágil inicialmente adequado a 
equipes pequenas e médias que é baseado em 
uma série de valores, princípios e regras. 
� XP surgiu no final da década de 1990, nos 
Estados Unidos.Estados Unidos.
VALORES
� Simplicidade
� Respeito
� Comunicação
� Feedback
Coragem� Coragem
SIMPLICIDADE
� Segundo o Chaos Report (Standish Group, 1995) 
mais da metade das funcionalidades introduzidas 
em sistemas nunca são usadas. 
� XP sugere como valor a simplicidade, ou seja, a 
equipe deve se concentrar nas funcionalidades equipe deve se concentrar nas funcionalidades 
efetivamente necessárias e não naquelas que 
poderiam talvez ser necessárias, mas que ainda 
não se tem evidência de que são essenciais.
RESPEITO
� Respeito entre os membros da equipe e entre a 
equipe e o cliente é um valor dos mais básicos, 
que dá sustentação a todos os outros. 
� Sem respeito a comunicação é falha e o projeto 
afunda.afunda.
COMUNICAÇÃO
� Em desenvolvimento de software a comunicação é 
essencial para que o cliente consiga dizer o que 
realmente precisa. 
� XP preconiza comunicação de boa qualidade, 
preferindo encontros presenciais ao invés de preferindo encontros presenciais ao invés de 
videoconferências, videoconferências, ao invés de 
telefonemas, telefonemas ao invés de emails e 
assim por diante. 
� Ou seja, quanto mais pessoal e expressiva a 
forma de comunicação 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 comunicação sejam corrigidas o mais falhas de comunicação sejam corrigidas o mais 
rapidamente possível antes que os danos se 
alastrem e o custo da correção seja alto.
CORAGEM
� Pode-se dizer que a única coisa constante no 
projeto de um software é a necessidade de 
mudança. 
� Para os desenvolvedores XP é necessário confiar 
nos mecanismos de gerenciamento da mudança nos mecanismos de gerenciamento da mudança 
para ter a coragem de abraçar as inevitáveis 
modificações ao invés de simplesmente ignorá-
las, por estarem eventualmente fora do contrato 
formal, ou por serem muito difíceis de acomodar.
PRINCÍPIOS SÃO DEFINIDOS A PARTIR DOS
VALORES
� Priorização de funcionalidades mais importantes 
de forma que, se o trabalho não puder ser todo 
concluído, pelo menos as partes mais importantes 
terão sido.
�Mudanças incrementais, feedback rápido, e �Mudanças incrementais, feedback rápido, e 
considerar a mudança como algo positivo, que 
deve ser considerado parte do processo. 
� Qualidade: pequenos ganhos a curto prazo pelo 
sacrifício da qualidade não são compensados 
pelas perdas a médio e longo prazo
PRÁTICAS
� Jogo de planejamento
�Metáfora
� Equipe coesa
� Reuniões em pé
Projeto simples
� Desenvolvimento 
orientado a testes
� Refatoração
� Integração contínua
� Projeto simples
� Versões pequenas
� Ritmo sustentável
� Posse coletiva
� Programação em pares
� Padrões de codificação
� Testes de aceitação
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 necessidades e à equipe de desenvolvimento 
estimar quais podem ser implementadas no ciclo 
semanal que se inicia. 
� Ao final da semana essas funcionalidades são 
entregues ao cliente. 
� Esse tipo de modelo de relacionamento com o 
cliente é adaptativo, em oposição aos contratos 
rígidos usualmente estabelecidos.
METÁFORA (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.
REUNIÕES EM PÉ (STAND-UP MEETING). 
� Como no caso de Scrum, reuniões 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, não o que o 
desenvolvedor gostaria que ele precisasse. desenvolvedor gostaria que ele precisasse. 
� Por vezes, projeto simples pode ser confundido 
com projeto fácil. 
� Nem sempre o projeto simples é o mais fácil de 
implementar. 
� O projeto fácil pode não atender às necessidades, 
ou pode gerar problemas de arquitetura.
VERSÕES PEQUENAS (SMALL RELEASES)
� A liberação de versões pequenas do sistema pode 
ajudar o cliente a testar as funcionalidades de 
forma contínua. 
� XP leva ao extremo este princípio, sugerindo 
versões ainda menores do que as de outros versões ainda menores do que as de outros 
processos incrementais como UP.
RITMO SUSTENTÁVEL (SUSTAINABLE
PACE). 
� Trabalhar com qualidade um número razoável de 
horas por dia (não mais do que 8). 
� Horas extras só são recomendadas quando 
efetivamente trouxerem um aumento de 
produtividade, mas não podem ser rotina.produtividade, mas não podem ser rotina.
POSSE COLETIVA (COLLECTIVE
OWNERSHIP)
� O código não tem dono e não é necessário pedir 
permissão a ninguém para modificá-lo.
PROGRAMAÇÃO EM PARES (PAIR
PROGRAMMING)
� A programação é sempre feita por duas pessoas 
em cada computador. 
� Usualmente trata-se de um programador mais 
experiente e um aprendiz. 
� O aprendiz deve usar a máquina enquanto o mais � O aprendiz deve usar a máquina enquanto o mais 
experiente o ajuda a evoluir em suas capacidades.
� Com isso, o código gerado terá sempre sido 
verificado por pelo menos duas pessoas, 
reduzindo drasticamente a possibilidade de erros.
PADRÕES DE CODIFICAÇÃO (CODING
STANDARDS)
� A equipe deve estabelecer e seguir padrões de 
codificação, de forma que parecerá que o código 
foi todo desenvolvido pela mesma pessoa, mesmo 
que tenham sido dezenas.
TESTES DE ACEITAÇÃO (CUSTOMER TESTS)
� São 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. 
REFATORAÇÃO (REFACTORING)
� Não se deve fugir da refatoração quando 
necessária. 
� Ela permite manter a complexidade do código em 
um nível gerenciável. 
� É um investimento que traz benefícios a médio e � É um investimento que traz benefícios a médio e 
longo prazo.
INTEGRAÇÃO CONTÍNUA (CONTINUOUS
INTEGRATION)
� Nunca esperar até ao final do ciclo para integrar 
uma nova funcionalidade. 
� Assim que estiver viável ela deve ser integrada 
ao sistema para evitar surpresas.
REGRAS XP
�Wells (2009) vai mais além das práticas XP 
apontando um conjunto sucinto e bastante 
objetivo de regras para XP. 
� Ele divide as regras em 5 grandes grupos: 
� Planejamento� Planejamento
� Gerência
� Projeto
� Codificação
� Teste
REGRAS XP DE PLANEJAMENTO
� Escrever histórias de usuário
� O planejamento de entregas cria o cronograma de 
entregas
� Faça entregas pequenas freqüentes
O projeto é dividido em iterações� O projeto é dividido em iterações
� O planejamento da iteração inicia cada iteração
ESCREVER HISTÓRIAS DE USUÁRIO
� Servem ao mesmo propósito de casos de uso, mas 
não são a mesma coisa. 
� São usadas no lugar do documento de requisitos. 
� Devem ser escritas pelos usuários como sendo as 
coisas que eles precisam que o sistema faça para coisasque eles precisam que o sistema faça para 
eles. 
� Podem ser usadas para definir os testes de 
aceitação. 
ESCREVER HISTÓRIAS DE USUÁRIO
� A equipe deve estimar se a história pode ser 
implementada em uma, duas ou três semanas. 
� Tempos maiores do que este significam que a 
história deve ser subdividida em duas ou mais 
histórias. histórias. 
�Menos de uma semana significa que a história 
está em um nível de detalhe muito alto e precisa 
ser combinada com outras. 
� Como as histórias são escritas pelo cliente, 
espera-se que não sejam contaminadas com 
aspectos técnicos 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 técnicos tomem as decisões 
técnicas e os administradores as decisões de 
negócio. negócio. 
� Deve-se estimar o tempo de cada história de 
usuário em termos de semanas de programação 
ideais e priorizar as histórias mais importantes 
do ponto de vista do cliente. 
� Uma semana de programação 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 histórias são agrupadas em iterações, que só 
são planejadas pouco antes de iniciarem.
� Essa priorização pode ser feita com histórias 
impressas em cartões que são movidos na mesa 
ou num quadro para indicar prioridades. ou num quadro para indicar prioridades. 
FAÇA ENTREGAS PEQUENAS FREQÜENTES
� Algumas equipes entregam software 
diariamente, mas no pior caso, deveria acontecer 
a cada uma ou duas semanas. 
� A decisão de colocar a entrega em operação ou 
não é do cliente.não é do cliente.
O PROJETO É DIVIDIDO EM ITERAÇÕES
� Prefira iterações de uma a duas semanas. 
� Não planeje as atividades com muita 
antecedência. 
� Deixe para planejar a iteração pouco antes de ela 
iniciar. iniciar. 
� Planejamento just-in-time é uma forma de estar 
sempre sintonizado com as mudanças de 
requisitos e arquitetura. 
� Não tente implementar coisas que virão depois. 
� Leve os prazos a sério. 
O PROJETO É DIVIDIDO EM ITERAÇÕES
� Acompanhe a produtividade. 
� Se perceber que não vai vencer o cronograma, 
convoque uma nova reunião de planejamento de 
entregas e repasse algumas entregas para outros 
ciclos. ciclos. 
� Concentre-se em completar as tarefas, e não em 
deixar várias coisas inacabadas.
O PLANEJAMENTO DA ITERAÇÃO INICIA
CADA ITERAÇÃO
� No planejamento, que inicia cada iteração 
seleciona-se as histórias de usuário mais 
importantes a serem desenvolvidas e partes de 
sistema que falharam em testes de aceitação, os 
quais são quebrados em tarefas de programação. quais são quebrados em tarefas de programação. 
� As tarefas serão escritas em cartões, assim como 
as histórias de usuário. 
� Enquanto as histórias de usuário estão na 
linguagem do cliente, as tarefas de programação 
estão na linguagem dos desenvolvedores. 
O PLANEJAMENTO DA ITERAÇÃO INICIA
CADA ITERAÇÃO
� Cada desenvolvedor que seleciona uma tarefa 
estima quanto tempo ela levará para ser 
concluída. 
� Tarefas devem ser estimadas em um, dois ou três 
dias ideais de programação. dias ideais de programação. 
� Um dia ideal de programação é uma jornada de 
trabalho normal em que uma pessoa dedique-se 
unicamente ao projeto.
REGRAS XP DE GERENCIAMENTO
� Dê à equipe um espaço de trabalho aberto e 
dedicado
� Defina uma jornada sustentável
� Inicie cada dia com uma reunião em pé
A velocidade do projeto é medida� A velocidade do projeto é medida
�Mova as pessoas
� Conserte XP quando for inadequado
DÊ À EQUIPE UM ESPAÇO DE TRABALHO
ABERTO E DEDICADO
� É importante eliminar barreiras físicas entre os 
membros da equipe para melhorar a 
comunicação. 
� Sugere-se colocar os computadores em um espaço 
central para a programação em pares e mesas central para a programação em pares e mesas 
nas laterais da sala para que pessoas que 
precisem trabalhar a sós não se desconectem do 
ambiente. 
� Inclua uma área para as reuniões em pé com um 
quadro branco e uma mesa de reuniões
DEFINA UMA JORNADA SUSTENTÁVEL
� Trabalhar além 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 � Descubra a velocidade ideal para sua equipe e 
atenha-se a ela. 
� Não tente fazer uma equipe trabalhar na 
velocidade de outra. 
� Faça planos realistas.
INICIE CADA DIA COM UMA REUNIÃO EM PÉ
� Em uma reunião típica nem sempre todos 
contribuem, mas pelo menos ouvem. 
�Mantenha o mínimo de pessoas o mínimo de 
tempo em reuniões. 
� As reuniões em pé não são perda de tempo, mas � As reuniões em pé não são perda de tempo, mas 
uma forma rápida 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 histórias de 
usuário e tarefas de programação são 
desenvolvidas em cada iteração. 
� A cada encontro de planejamento de iteração os 
clientes podem selecionar um número de clientes podem selecionar um número de 
histórias de usuário igual à estimativa de 
velocidade do projeto. 
� O mesmo vale para os programadores em relação 
às tarefas de programação. 
� Isso permite que a equipe se recupere de 
eventuais iterações difíceis. 
� Aumentos e diminuições de velocidade são 
esperadas.
MOVA AS PESSOAS
�Mobilidade de pessoas em projetos é importante 
para evitar perda de conhecimento e gargalos de 
programação. 
� Ficar na dependência de um único funcionário é 
perigoso. perigoso. 
� Deve-se evitar criar ilhas de conhecimento 
porque elas são susceptíveis a perda. 
� Se precisar de conhecimento especializado, 
contrate um consultor por prazo determinado. 
CONSERTE XP QUANDO FOR INADEQUADO
� Não hesite em mudar aquilo que não funciona em 
XP. 
� Isso não significa que se pode fazer qualquer 
coisa. 
� Segue-se as regras até que se perceba que elas � 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 existência de regras é a melhor forma de 
garantir isso.
REGRAS XP DE PROJETO (DESGIN)
� Simplicidade
� Escolha uma metáfora de sistema
� Use Cartões CRC durante reuniões de projeto
� Crie soluções afiadas para reduzir risco
Nenhuma funcionalidade é adicionada cedo� Nenhuma funcionalidade é adicionada cedo
� Use refatoração sempre e onde for possível
SIMPLICIDADE
� Um projeto simples sempre é executado mais 
rápido do que um projeto complexo. 
� Porém, simplicidade é subjetiva e difícil de ser 
medida. 
� Então a equipe é que deve decidir o que é � Então a equipe é que deve decidir o que é 
simples. 
� Uma das melhores formas de obter simplicidade 
em um projeto é levar a sério o Design Pattern
“Alta Coesão” (Wazlawick, 2004). 
QUALIDADES PARA OBTER SIMPLICIDADE
� Testabilidade
� Browseabilidade
� Compreensibilidade e Explicabilidade
TESTABILIDADE
� Pode-se escrever testes de unidade para verificar 
se o código está correto. 
� O sistema deve ser quebrado em unidades 
testáveis.
BROWSEABILIDADE
� Pode-se encontrar os elementos quando se precisa 
deles. 
� Bons nomes e uso de boas disciplinas como 
polimorfismo, herança e delegação ajudam nisso.
COMPREENSIBILIDADE E
EXPLICABILIDADE
� Compreensibilidade é uma qualidade subjetiva 
porque um sistema pode ser bastante 
compreensível para quem está trabalhando nele, 
mas difícil para quem está de fora.� Então essa propriedade pode ser definida em � Então essa propriedade pode ser definida em 
termos de quão fácil é explicar o sistema para 
quem não participou do desenvolvimento.
ESCOLHA UMA METÁFORA DE SISTEMA
� Uma boa metáfora de sistema ajuda a explicar 
seu funcionamento a alguém de fora do projeto. 
� Deve-se evitar que a compreensão sobre o 
sistema resida em pilhas de documentos. 
� Nomes significativos e padrões de nomeação de � Nomes significativos e padrões de nomeação de 
elementos de programa devem ser 
cuidadosamente escolhidos e seguidos para que 
fragmentos de código sejam efetivamente 
reusáveis.
USE CARTÕES CRC DURANTE REUNIÕES
DE PROJETO
� Trata-se de uma técnica para encontrar 
responsabilidades e colaborações entre objetos. 
� A equipe se reúne em torno de uma mesa e cada 
membro recebe um ou mais cartões 
representando instâncias de diferentes classes. representando instâncias de diferentes classes. 
� Uma atividade (operação ou consulta) é simulada 
e a medida que ela ocorre os detentores dos 
cartões anotam responsabilidades do objeto no 
lado esquerdo do cartão e colaborações do objeto 
no lado direito. 
� A documentação dos processos pode ser feita com 
diagramas de seqüência ou de comunicação da 
UML.
CRIE SOLUÇÕES AFIADAS PARA REDUZIR RISCO
� Em face de riscos importantes de projeto deve-se 
explorar o risco de forma definitiva e exclusiva, 
ou seja, uma solução afiada ou spike para o 
problema identificado. 
� Um spike é então um desenvolvimento ou teste 
projetado especificamente para analisar e 
possivelmente resolver um risco. 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 não serão aproveitados no 
projeto, podendo ser classificados como uma das 
formas de prototipação (throw-away).
NENHUMA FUNCIONALIDADE É
ADICIONADA CEDO
� Deve-se evitar a tentação de adicionar 
funcionalidade desnecessária só porque seria fácil 
fazer isso agora e deixaria o sistema melhor. 
� Apenas o necessário é feito no sistema. 
� Desenvolver o que não é necessário é jogar tempo � Desenvolver o que não é necessário é jogar tempo 
fora. 
�Manter o código aberto a possíveis mudanças 
futuras tem a ver com simplicidade de projeto, 
mas adicionar funcionalidade ou flexibilidade 
desnecessária, sempre deixa o projeto mais 
complexo. 
� Requisitos futuros só devem ser considerados 
quando estritamente exigidos pelo cliente.
USE REFATORAÇÃO SEMPRE E ONDE FOR
POSSÍVEL
� Refatore sem pena. 
� XP não recomenda que se continue usando design 
antigo e ruim só porque ele funciona. 
� Deve-se remover redundâncias, eliminar 
funcionalidades desnecessárias e rejuvenecer funcionalidades desnecessárias e rejuvenecer 
designs antiquados.
REGRAS XP PARA CODIFICAÇÃO DE
PROGRAMAS
� O cliente está sempre disponível
� O código deve ser escrito de acordo com padrões 
aceitos
� Escreva o teste de unidade primeiro
Todo o código é produzido por pares� Todo o código é produzido por pares
� Só um par faz integração de código de cada vez
� Integração deve ser freqüente
� Defina um computador exclusivo para integração
� A posse do código deve ser coletiva
O CLIENTE ESTÁ SEMPRE DISPONÍVEL
� XP necessita que o cliente esteja disponível 
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 funcionário 
pouco experiente ou estagiário ao projeto. Ele não serve. pouco experiente ou estagiário ao projeto. Ele não serve. 
� Deve ser um especialista. Ele deverá escrever as histórias 
de usuário, bem como priorizá-las e negociar sua inclusão 
em iterações. 
� Pode parecer um investimento alto em tempo de 
funcionários, mas é compensado por ser desnecessário um 
levantamento de requisitos detalhado ao início, bem como 
pela não entrega de um sistema inadequado.
O CÓDIGO DEVE SER ESCRITO DE ACORDO
COM PADRÕES ACEITOS
� Padrões de codificação mantêm o código 
compreensível e passível de refatoração por toda 
a equipe. 
� Além disso, código que se parece encoraja a posse 
coletiva do mesmo.coletiva do mesmo.
ESCREVA O TESTE DE UNIDADE PRIMEIRO
� Usualmente, escrever o teste antes do código 
ajuda a escrever o código melhor. 
� O tempo para escrever o teste e código passa a 
ser o mesmo que se gastaria para escrever 
apenas o código.apenas o código.
TODO O CÓDIGO É PRODUZIDO POR PARES
� Embora pareça contra-sensual, duas pessoas 
trabalhando em um computador produzem tanto 
código quanto duas pessoas trabalhando 
separadamente, mas com mais qualidade. 
� Embora seja recomendado que haja um � Embora seja recomendado que haja um 
programador mais experiente, a relação não deve 
ser de professor/aluno, mas de iguais.
SÓ UM PAR FAZ INTEGRAÇÃO DE CÓDIGO
DE CADA VEZ
� A integração 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 versões claramente definidas do � Deve haver versões claramente definidas do 
produto. 
� Então, para que equipes trabalhando em paralelo 
não tenham problemas na hora de integrar seu 
código ao produto, elas devem esperar a sua vez. 
� Deve-se estabelecer turnos de integração que 
sejam obedecidos. 
INTEGRAÇÃO DEVE SER FREQÜENTE
� Desenvolvedores devem estar integrando código 
ao repositório a cada poucas horas. 
� Postergar integração pode agravar o problema de 
todos estarem trabalhando em versões 
desatualizadas do sistema.desatualizadas do sistema.
DEFINA UM COMPUTADOR EXCLUSIVO PARA
INTEGRAÇÃO
� Este computador funciona como uma ficha de exclusividade 
(token) para a integração. 
� A existência dele no ambiente de trabalho permite que toda a 
equipe veja quem está integrando funcionalidade e qual a 
funcionalidade. 
� O resultado da integração deve passar nos testes de unidade, de � O resultado da integração deve passar nos testes de unidade, de 
forma que se obtém estabilidade em cada versão e localidade nas 
mudanças e possíveis erros. 
� Se os testes de unidade falharem, a unidade deve ser depurada. 
� Se a atividade de integração levar mais do que cerca de dez 
minutos, é porque a unidade ainda precisa de alguma depuração 
adicional antes de ser integrada. 
� Neste caso, a integração deve ser abortada, retornando o sistema 
à ultima versão estável, e a depuração da unidade deve seguir 
sendo feita pelo par.
A POSSE DO CÓDIGO DEVE SER COLETIVA
� Não devem ser criados gargalos pela existência de 
donos de código. 
� Todos devem ter autorização para modificar, 
consertar ou refatorar partes do sistema. 
� Para isso funcionar os desenvolvedores devem � Para isso funcionar os desenvolvedores devem 
sempre desenvolver os testes de unidade 
juntamente com o código, seja novo ou modificado. 
� Desta forma existe sempre uma garantia de que o 
software satisfaz as condições de funcionamento. 
� Não ter um dono de partes do sistema também 
diminui o impacto da perda de membros da equipe.
REGRAS XP PARA TESTE DE SOFTWARE
� Todo o código deve ter testes de unidade
� Todo código deve passar pelos testes de unidade 
antes de ser entregue
� Quando um erro de funcionalidade é encontrado, 
testes são criadostestes são criados
� Testes de aceitação são executados com 
freqüência e os resultados são publicados
TODO O CÓDIGO 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 testartodas as classes do sistema, 
ignorando usualmente os métodos básicos triviais como 
getters e setters. getters e setters. 
� Testes de unidade favorecem a posse coletiva do código 
porque protegem o código de ser acidentalmente danificado. 
� Um bom local para baixar frameworks para testes de 
unidade para várias linguagens é 
http://www.xprogramming.com/software. 
� Além disso, em http://www.junit.org/ pode-se encontrar o 
JUnit, que vem se tornando um padrão para 
desenvolvimento dirigido por testes em Java.
TODO CÓDIGO DEVE PASSAR PELOS TESTES DE
UNIDADE ANTES DE SER ENTREGUE
� Exigir que o código passe por todos os testes de 
unidade antes de ser integrado ajuda a garantir 
que sua funcionalidade está corretamente 
implementada. 
� Os testes de unidade também favorecem a � Os testes de unidade também favorecem a 
refatoração, porque protegem o código de 
mudanças indesejadas de funcionalidade. 
� A introdução de nova funcionalidade deverá 
provocar a adição e mais testes no teste de 
unidade específico.
QUANDO UM ERRO DE FUNCIONALIDADE É
ENCONTRADO, TESTES SÃO CRIADOS
� Um erro de funcionalidade identificado exige que 
testes de aceitação sejam criados para proteger o 
sistema. 
� Assim, os clientes explicam claramente aos 
desenvolvedores o que eles esperam que seja desenvolvedores o que eles esperam que seja 
modificado.
TESTES DE ACEITAÇÃO SÃO EXECUTADOS COM
FREQÜÊNCIA E OS RESULTADOS SÃO
PUBLICADOS
� Testes de aceitação são criados a partir de 
histórias de usuário. 
� Durante uma iteração, as histórias de usuário 
selecionadas serão traduzidas em testes de 
aceitação. aceitação. 
� Estes testes são do tipo caixa preta e 
representam uma ou mais funcionalidades 
desejadas. 
� Testes de aceitação devem ser automatizados, de 
forma que possam ser executados com freqüência.
BIBLIOGRAFIA
� Beck, K. et al. (2001). Manifesto for Agile Software 
Development. Disponível em: http://agilemanifesto.org/. 
Consultado em: 08/03/2010.
� Standish Group (1995). Chaos Report. Acessível em: 
http://www.projectsmart.co.uk/docs/chaos-report.pdf. 
Consultado em: 10/03/2010.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). Análise e Projeto de Sistemas de 
Informação Orientados a Objetos. Rio de Janeiro: Elsevier.
� Wells, D. (2009). The Rules of Extreme Programming. 
Disponível em: 
http://www.extremeprogramming.org/rules.html. Acessado 
em 10/03/2010.