Extreme Programming -XP

Prévia do material em texto

Análise e Desenvolvimento de 
Sistemas – 

Extreme Programming - XP
Prof. Eduardo Vasconcelos 
eduardo.vasconcelos@garanhuns.ifpe.edu
.br
XP
Introdução
• O que é XP: 
– É uma metodologia de desenvolvimento 
ágil cujo foco está nas práticas de 
programação. 
– Nesta metodologia, o produto é 
desenvolvido pela integração de versões 
entregues após ciclos de 
desenvolvimento curtos.
Introdução
• O XP é composto basicamente por um 
conjunto de: 
– Conceitos; 
– Práticas.
Conceitos
• Objetivos: 
– O principal Objetivo do XP é organizar as 
pessoas para produzir software de alta 
qualidade, de forma mais produtiva. 
– Busca a atender as mudanças dos 
requisitos através do desenvolvimento de 
ciclos curtos, em vez de um ciclo longo. 
Conceitos
• Objetivos: 
– Para o XP, as mudanças são aspectos 
naturais e desejados no projeto de 
desenvolvimento de software;
Conceitos
• Atividades 
– Em XP, existe a descrição de 4 atividades 
básicas para o desenvolvimento do 
produto de software; 
• Codificação; 
• Teste; 
• Escuta; 
• Desenho.
Conceitos
• Atividades: 
– Codificação; 
• Para o XP, o único produto importante de um 
software é o código; 
– Documentos não realizam processos; 
– Sem Código, o produto não funciona;
Conceitos
• Atividades: 
– Codificação; 
• Existem outras características que podem ser 
atribuídas a codificação: 
– Permite aos desenvolvedores encontrarem 
soluções mais adequadas; 
– Ajuda a comunicar problemas no código;
Conceitos
• Atividades: 
– Codificação: 
• Em alguns casos, para explicar problemas 
complexos, é mais fácil utilizar código para 
descrever a solução do problema do que 
explicações em linguagem natural.
Conceitos
• Atividades: 
– Codificação: 
• Diferentemente da documentação, o código 
não pode ter mais de uma interpretação, o 
que o torna mais legível e confiável.
Conceitos
• Atividades: 
– Testes: 
• São um importante aspecto do 
desenvolvimento em XP; 
• Cada código desenvolvido deve ser testado 
com o objetivo de encontrar falhas e/ou 
desconformidade com os requisitos. 
• Os tipos de testes são: 
– Teste de Unidade; 
– Teste de Aceitação;
Conceitos
• Atividades: 
– Testes: 
• Testes de Unidade: 
– Verifica se uma característica funciona da forma 
desejada; 
– Todo código desenvolvido deve ser testado; 
– O desenvolvedor deve testar todas as formas 
possíveis de erro no código desenvolvido antes de 
passar para a próxima fase; 
– O código só é integrado quando todos os testes 
forem feitos.
Conceitos
• Atividades: 
– Testes: 
• Testes de aceitação: 
– Serve para verificar se os requisitos entendidos 
pelo desenvolvedor, atentem as necessidades do 
cliente.
Conceitos
• Atividades 
– Escuta: 
• Os desenvolvedores devem escutar as 
necessidades dos clientes; 
• Os desenvolvedores precisam entender bem 
as necessidades dos clientes, pois, estes 
precisam dar respostas técnicas aos clientes, 
ou informar a impossibilidade de desenvolver 
determinado requisito.
Conceitos
• Atividades 
– Desenho: 
• A idéia básica é que o sistema deve ter sua 
arquitetura desenvolvida de uma forma que, a 
adição de novas funcionalidades não afetem o 
funcionamento do sistema. 
– Se a codificação, o teste e a escuta fossem 
realizadas corretamente, não existiria a 
necessidade de desenvolver uma arquitetura 
enxuta. 
• Basicamente, o sistema deve ser planejado 
evitando o máximo de dependências possíveis.
Conceitos
• Valores: 
– O XP emprega 5 valores: 
• Comunicação; 
• Simplicidade; 
• Feedback; 
• Coragem; 
• Respeito.
Conceitos
• Valores 
– Comunicação: 
• Este é um dos valores mais importantes no 
desenvolvimento de um software: 
– Requisitos e conhecimentos devem ser passados 
para todos os desenvolvedores do sistema, todos 
devem conhecer o domínio da aplicação; 
• O XP prega a rápida disseminação do 
conhecimento entre os membros;
Conceitos
• Valores 
– Comunicação: 
• A comunicação geralmente é verbal; 
– Em outros métodos, grande parte da comunicação 
é feita através de documentos; 
• O XP prega que o cliente deve estar sempre 
disponível para se comunicar; 
– Isto é basicamente uma utopia;
Conceitos
• Valores 
– Simplicidade: 
• Em XP, o ideal é que toda funcionalidade 
deve der implementada inicialmente com 
uma solução simples; 
• Basicamente, todo código gerado é 
projetado para atender as necessidades de 
hoje; 
– Necessidades futuras serão planejadas no futuro;
Conceitos
• Valores 
– Feedback: 
• Está relacionado as diferentes visões do 
desenvolvimento do sistema; 
• Feedback do Sistema: 
– É obtido através dos testes unitários ou testes de 
integração. Desta forma os programadores têm 
total entendimento do estado do sistema após a 
adição de mudanças.
Conceitos
• Valores 
– Feedback: 
• Feedback do cliente: 
– São obtidos a partir dos testes de aceitação; 
– Clientes juntamente com os engenheiros de 
testes, escrevem os casos de teste. 
– Desta forma o cliente possui um entendimento de 
como o sistema esta sendo construído, e qual o 
estado atual do sistema a cada iteração.
Conceitos
• Valores 
– Feedback: 
• Feedback da equipe: 
– Sempre que um cliente apresenta alguma 
mudança nos requisitos, a equipe deve oferecer a 
este uma estimativa de esforço e tempo para 
desenvolver esta nova funcionalidade.
Conceitos
• Valores 
– Coragem: 
• A coragem está relacionada a forma como os 
desenvolvedores devem encarar seu trabalho; 
– O desenvolvedor não deve “correr da raia”, ele 
deve estar pronto para as mudanças no código; 
– Ele deve estar sempre disposto a refatorar o seu 
próprio código, o que nem sempre é algo 
desejável; 
– Ele deve ser capas de, uma vez que alguma 
mudança radical ocorra, se preciso for, jogar seu 
código fora.
Conceitos
• Valores 
– Respeito: 
• O desenvolvedor deve respeitas os outros 
membros da equipe, e a si mesmo; 
– O desenvolvedor nunca deve atualizar um código 
que atrapalhe outro, que gere falha nos testes de 
códigos já existentes ou que atrapalhe o trabalho 
dos outros. 
• Cada membro deve respeitar seu trabalho: 
– Cada código gerado deve ser desenvolvido com a 
maior qualidade possível, e sempre com o melhor 
design.
Conceitos
• Valores 
– Respeito: 
• Ninguém dentro da equipe é desvalorizado, 
desrespeitado ou ignorado; 
• Este pensamento eleva a motivação da 
equipe e encoraja a lealdade entre os 
participantes, visando sempre alcançar os 
objetivos do projeto.
Conceitos
• Princípios 
– Em XP, os princípios são bastante 
parecidos com os valores, a diferença é 
que os princípios são mais bem definidos 
que os valores.
Conceitos
• Princípios 
– Feedback: 
• Em XP, quanto menor o tempo entre uma 
ação e seu feedback, melhor ele será 
disseminado e compreendido pela equipe e 
clientes. 
• Em XP, diferente de outras metodologias, o 
ideal é que o contato entre a equipe e o 
cliente seja feito de forma mais interativa, 
facilitando assim a troca de informações.
Conceitos
• Princípios 
– Assumindo a simplicidade: 
• Para o XP, cada solução para o problema 
deve ser vista de forma mais simples 
possível; 
– Nos métodos convencionais, o código é 
desenvolvido visando o futuro e as soluções são 
desenvolvidas de forma mais complexa; 
– Para o XP, o sistema deve ser construído de forma 
incremental, parte-se de uma solução mais 
simples, para depois incrementá-la aos poucos.
Conceitos
• Princípios 
– Abraçar as Mudanças: 
• Todo desenvolvedor deve ser capaz de aceitar 
as mudanças sem maiores problemas; 
– Os desenvolvedores não devem rejeitaruma 
mudança nos requisitos ou simplesmente se sentir 
“chateado” pelo acontecimento de uma mudança 
que vá necessitar de mais retrabalho. 
• Se ocorrer uma mudança dramática nos 
requisitos, os desenvolvedores devem estar 
dispostos a aceitar as mudanças, não importa 
o que aconteça;
Práticas
• O XP apresenta 12 práticas de 
programação divididas em 4 áreas: 
– Fine Scale Feedback 
– Processo Contínuo 
– Conhecimento Distribuído 
– Bem estar do programador
Práticas – Fine Scale Feedback
• Programação em pares: 
– Todo código deve ser desenvolvido por 
dois programadores utilizando a mesma 
estação de trabalho; 
• Isto garante que o código é revisado 
enquanto é desenvolvido; 
• Na prática a produtividade cai, porém o 
código sai com pouquíssimos erros. 
• Sempre que um desenvolvedor estiver com 
dificuldade, o outro estará próximo para 
ajudar.
Práticas – Fine Scale Feedback
• Planning Game: 
– É um processo de planejamento que 
ocorre geralmente uma vez por semana; 
– Este processo é dividido em duas partes: 
• Release Planning; 
• Interaction Planning;
Práticas – Fine Scale Feedback
• Planning Game 
– Release Planning: 
• É utilizado para determinar quais requisitos 
devem ser incluídos no próximo ciclo e 
quando devem ser entregues; 
– Os requisitos devem ser descritos em User Stories; 
• Deve haver a presença tanto dos 
desenvolvedores quanto dos clientes;
Práticas – Fine Scale Feedback
• Planning Game 
– Interaction Planning: 
• Nesta fase, os desenvolvedores devem 
planejar as atividades a serem desenvolvidas; 
• Não há a presença do cliente; 
• Nesta fase ocorre: 
– Os requisitos são divididos em tarefas; 
– Cada desenvolvedor assina uma tarefa e estima o 
tempo de desenvolvimento; 
– Ao final do desenvolvimento, o produto 
desenvolvido é confrontado com a user story.
Práticas – Fine Scale Feedback
• Desenvolvimento orientado a testes: 
– Em XP, antes do desenvolvimento de 
cada pedaço de código, é escrito um 
teste de unidade. 
• Esta prática é interessante, pois, estimula o 
desenvolvedor a pensar nos eventuais 
problemas que o código pode apresentar, 
antes de codificar.
Práticas – Fine Scale Feedback
• Whole Team 
– Para o XP, O cliente não é somente a 
pessoa que paga pelo sistema, mas sim a 
pessoa que irá utilizá-lo, sendo assim a 
pessoa mais importante; 
• Ela deve também fazer parte da equipe; 
– O cliente deve estar disponível a 
qualquer momento para responder 
eventuais perguntas
Práticas – Processo Contínuo
• Integração Contínua 
– Como o desenvolvimento do software é 
feito em pedaços, geralmente estes 
pedaços ficam armazenado localmente 
nas estação de trabalho; 
– Para o XP, os desenvolvedores devem 
tentar atualizar suas modificação em 
períodos curtos de tempo; 
• Isto evitaria problemas de incompatibilidade, 
atraso no desenvolvimento…
Práticas – Processo Contínuo
• Melhoria do Design ou Refactoring 
– O princípio da simplicidade que diz que o 
código deve ser desenvolvido pensando 
apenas no hoje, a médio prazo gera 
alguns problemas; 
• Mudança nos requisitos podem mudar grande 
parte dos códigos já produzidos; 
– Sempre que isto acontece, a arquitetura 
do sistema deve ser refatorada para 
tornar-la mais simples.
Práticas – Processo Contínuo
• Pequenas Versões 
– Para o XP, o sistema deve ser 
desenvolvido em versões menores do que 
em uma versão única; 
• Isto ajuda o cliente a verificar como o 
sistema está sendo desenvolvido, dando 
maior credibilidade a equipe de 
desenvolvimento; 
• Com partes do sistema em funcionamento, o 
cliente pode se sentir mais seguro para 
participar mais ativamente do processo.
Práticas – Conhecimento Distribuído
• Padrão de Codificação 
– A idéia é padronizar o estilo do 
desenvolvimento do código; 
• Ex. Como os nomes dos métodos devem ser 
criados, qual a posição da chave após a 
criação de um método, como os atributos 
devem ser nomeados… 
• Como cada desenvolvedor tem sua forma de 
escrever os códigos, se não existir um padrão 
o código final ficará muito bagunçado, o que 
aumenta a probabilidade de surgirem defeitos.
Práticas – Conhecimento Distribuído
• Código Coletivo: 
– Todos são responsáveis por todo o código 
do sistema; 
• Sendo assim, qualquer um pode alterar 
qualquer parte do sistema; 
• Isto permite que toda a equipe conheça 
intimamente o código; 
• Se surgir algum problema, qualquer 
desenvolvedor pode resolve-lo.
Práticas – Conhecimento Distribuído
• Design Simples 
– A arquitetura do sistema deve ser simples o 
suficiente para que novas funcionalidades 
possam ser adicionadas sem maiores 
problemas 
• Sempre que um desenvolvedor for adicionar 
alguma funcionalidade ao sistema, ele deve se 
perguntar se esta adição será feita de forma 
rápida; 
• Caso não seja, o desenvolvedor deve refatorar 
o código do sistema para o tornar mais simples.
Práticas – Conhecimento Distribuído
• Metáforas do sistema 
– A idéia é simplificar termos técnicos para 
o entendimento de todos os envolvidos; 
• Um método que poderia ser chamado de 
commitingDataValue() poderia se chamar 
AtualizandoBancoDados().
Práticas – Bem estar do programador
• Ritmo Sustentável: 
– Para o XP, desenvolvedores trabalham 
melhor e de forma mais criativa se 
estiverem descasados. 
• As semanas de trabalho devem ser 40 horas; 
• Não deve haver hora extra, se houver numa 
semana, na outra não poderá; 
– Inicialmente o projeto pode até andar mais 
rapidamente com as horas extras, porém com o 
tempo o rendimento dos desenvolvedores vai 
diminuindo drasticamente.