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

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

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.

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

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.

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
deve sua popularidade inicialmente ao trabalho
de Schwaber.

Uma boa referência para quem deseja 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.
VALORES

Simplicidade

Respeito

Comunicação

Feedback

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

Metáfora orientado a testes

Equipe coesa
Refatoração

Reuniões em pé
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
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.

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

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

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.

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

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.

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.

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.

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

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

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

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

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.

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

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

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.

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.
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.
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
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
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.
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
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
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 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 testar todas as classes do sistema,
ignorando usualmente os métodos básicos triviais como
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
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
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.

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.

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.