2

Giovane Mendes Costa

Kennedy da Silva Menezes

INTRODUÇÃO

• A indústria de software passou por grandes transformações e

grandes desafios, entre eles, desenvolver software com qualidade no

menor tempo possível;

• Nesse período a Engenharia de Software passa a ser valorizada com

o intuito de ajudar a aumentar a qualidade dos softwares e atender as

exigências do mercado;

• Apesar da adoção de técnicas de Engenharia de Software, ainda

eram poucos os projetos que conseguiam obter sucesso e respeitar os

prazos e orçamentos previstos.

INTRODUÇÃO

• Pesquisa realizada pelo Standish Group International em 1994,

apontava que apenas 16,2% dos projetos, obtinha sucesso levando em

conta: prazo, orçamento e necessidades atendidas;

• Em 2002, após a adoção da Engenharia de Software, o percentual

dos projetos que obtiveram sucesso subiu para 34%, ou seja, aumento

de mais de 100% em oito anos;

• Os principais motivos para baixa taxa de sucesso:

• Tempo elevado em cada fase do projeto, não acompanhado as

mudanças dos requisitos;

• Falta de conhecimento da sua real necessidade por parte do cliente;

• Linearidade no desenvolvimento do projeto;

O QUE É XP?

• Sigla para Extreme Programming;

• Metodologia Desenvolvida na década de 90 por Kent Beck;

• É uma Metodologia de Desenvolvimento com foco na Agilidade;

• Baseia-se em valores como: simplicidade, comunicação, feedback e

coragem;

• Enfatiza o trabalho em equipe, onde, gerentes, clientes e

desenvolvedores são todos parceiros iguais em uma equipe

colaborativa;

• Concebida com o intuito de desenvolver software difícil, de qualidade

e no prazo combinado.

O QUE É XP?

• Kent definiu XP como: “Uma maneira leve, eficiente, de baixo risco,

flexível, previsível, científica e divertida de desenvolver software”;

• Assemelha-se a um enorme quebra-cabeças, onde pequenas peças

formam uma grande imagem;

• Valoriza a utilização de boas práticas e valores e não apenas

algumas ideias e mudanças;

FLUXOGRAMA

PARTICULARIDADES

• Feedback antecipado, concreto e contínuo pelos ciclos curtos;

• Sua abordagem incremental de planejamento gera um plano geral

para evoluir com o decorrer do projeto;

• Implementação de forma flexível das funcionalidades, respondendo

às necessidades do projeto;

• Monitoramento dos testes visando o progresso do desenvolvimento e

permitindo a detecção de erros de forma rápida;

• Confiança na colaboração dos desenvolvedores com habilidades

comuns;

• Práticas que combinam com os instintos de curto prazo dos

programadores com os interesses de longo prazo do projeto.

COMO FAZER XP?

• A XP foi desenvolvida para ser aplicada em projetos com times de 2 a

10 programadores;

• Os colaboradores não precisam estar restringido pelo ambiente

computacional.

• A execução e os testes devem ser realizados em pouco tempo no dia;

• Apesar de irritar algumas pessoas, todas as técnicas da XP são tão

velhas quanto a própria programação;

• Todas as técnicas da XP foram testadas à décadas.

VALORES

• Os valores são as diretrizes da XP, eles ajudarão a guiar a equipe e

ajudar a decidir as prioridades da metodologia;

• Para um projeto utilizar XP, ele deverá respeitar e seguir todos os

valores;

• Caso alguns dos valores não sejam seguidos, isso implicará em dizer

que o projeto não utiliza XP;

• Os valores utilizados pela XP são:

• Feedback;

• Comunicação;

• Simplicidade;

• Coragem.

FEEDBACK

• O cliente aprende com o sistema que utiliza e assim pode sugerir à

equipe modificações e reavaliar suas necessidades;

• O cliente conduz o desenvolvimento do seu produto, estabelece e

informa aquilo que é realmente importante;

• O desenvolvedor retorna ao cliente o seu entendimento sobre o que o

cliente deseja, informando-o sobre os riscos, estimativas e sugerindo

alternativas;

• O cliente deve está em contato permanente com a equipe,

principalmente depois do último feedback passado.

COMUNICAÇÃO

• Para que o Feedback seja possível é necessário uma boa

comunicação;

• A XP prega que essa comunicação deve ser feita de forma direta e

eficaz, agilizando os assuntos a serem tratados;

• É recomendado que essa comunicação seja feita face-a-face,

evitando mal entendidos e dúvidas entre as partes;

• Para que isso seja possível é necessária a disponibilização do cliente

ou a presença do mesmo no ambiente de trabalho;

• A comunicação agiliza o processo além de fortalecer o

relacionamento interpessoal;

• Pessoas introvertidas não são aconselháveis para as equipes

de XP.

SIMPLICIDADE “Se simplicidade é bom, sempre deixe o sistema com o projeto mais simples que suporte a

funcionalidade atual”.

• É necessária desde o primeiro momento com o cliente para que ele

possa aprender e conseguir dar o feedback necessário à equipe;

• Ser simples não é o mesmo que ser fácil. Nem sempre a solução

mais simples será a mais fácil de ser implementada.

• Codificar com simplicidade significa deixar o código mais legível para

que qualquer outro membro da equipe possa dar continuidade;

• Simplicidade significa codificar o necessário para que um requisito

seja atendido e entregue ao cliente;

• Neste processo, a simplicidade também deve ser respeitada

pelo cliente;

CORAGEM

• Ser um cliente XP não é fácil.

• O programador sabe como programar e o cliente deve saber o que

programar.

• O cliente precisa saber tomar decisões. Dizer o que é mais

importante, o momento de realizar uma modificação e o momento de

mudar de ideia.

• O programador precisa de coragem para modificar qualquer parte do

código que não tenha sido implementada por ele;

• O programador precisa de coragem para dizer “não” quando

necessário, ou dizer que o projeto vai demorar mais do que o estimado

por causa das novas solicitações;

CORAGEM

• O processo de desenvolvimento requer coragem para:

• Desenvolver de forma incremental;

• Manter o sistema simples;

• Fazer os desenvolvedores trabalharem em pares;

• Expor códigos a todos os membros da equipe;

• Propor adoção de um novo processo;

• Colocar desenvolvedores e clientes frente-a-frente;

• Apostar em seus colaboradores aumentando a sua

responsabilidade;

• Modelar e documentar apenas quando for necessário.

PRÁTICAS “Os valores somados às Práticas formam um conjunto de atividades que devem ser seguidas

pela equipe que desejar usar XP”.

• Cliente presente ou disponível;

• Jogo de Planejamento;

• Stand up Meeting;

• Programação em dupla;

• Refactoring;

• Desenvolvimento guiado por testes;

• Código coletivo;

• Padrões de desenvolvimento;

PRÁTICAS

• Design simples;

• Metáfora;

• Ritmo sustentável;

• Integração contínua;

• Releases curtos

CLIENTE PRESENTE

OU DISPONÍVEL “A ausência do cliente pode significar sérios riscos ao projeto”

• O XP prega que o cliente faz parte do processo de desenvolvimento

do projeto e por isso deve estar envolvido em todas as etapas;

• Estórias são bem vindas quando visam ilustrar o entendimento de

cada funcionalidade.

• Na presença do cliente a validação do entendimento do requisito

pode ser realizada e a equipe pode receber o feedback necessário,

criando ciclos rápidos e precisos.

• A presença do cliente dá maior dinamismo ao projeto;

JOGO DE PLANEJAMENTO

• Assegura que a equipe gastará maior tempo naquilo que gere o

máximo de valor para o cliente;

• É o momento em que o cliente solicita as funcionalidades através de

estórias e a equipe estima o custo de cada uma;

• A equipe estima o tempo para que o cliente priorize o que é

necessário;

• A XP utiliza uma unidade de medida chamada Ponto, que refere-se a

um dia de trabalho ideal do desenvolvedor;

• Uma estória não deve passar de 4 pontos;

STAND UP MEETING

• Reunião rápida pela manhã;

• Duração de cerca de 20 minutos;

• Preferencialmente em pé;

• Objetiva atualizar a equipe sobre o que foi implementado no dia

anterior e trocar experiências a cerca dos problemas enfrentados;

• Durante a reunião é decidida as estórias a serem implementadas,

bem como os responsáveis por cada uma delas;

PROGRAMAÇÃO EM DUPLA

• A XP exige que todo e qualquer código implementado no projeto seja

efetuado em dupla;

• Evita a demora na detecção e correção dos erros;

• Facilita a troca de experiências, sugestão de soluções, conhecimento

das regras de negócio e o nivelamento de conhecimento entre a dupla;

• O desenvolvedor que não está utilizando o teclado e mouse

supervisiona e revisa o código do parceiro;

• Apesar de parecer perda de recurso, o método pair programming é

preferido por cerca de 90% dos desenvolvedores;

REFACTORING

• Ao contrário de outras metodologias, a XP prega que todo código mal

escrito, duplicado, lento ou sem padronização deve ser alterado;

• Todo programador que encontrar este tipo de código deve realizar as

alterações necessárias sem modificar o comportamento do mesmo;

• Todo programador tem a possiblidade de melhorar o código;

• Facilita a manutenção do código.

DESENVOLVIMENTO

GUIADO POR TESTES

• Todo código implementado deve coexistir com um teste

automatizado;

• Garante o pleno funcionamento da nova funcionalidade;

• É baseado nesses testes que o desenvolvedor terá coragem para

modificar um código já existente;

• São separados em dois tipos: Teste de Unidade e de Aceitação;

• O teste de unidade verifica se cada resultado gerado por uma classe

está correto;

• O teste e aceitação verifica se o resultado de uma classe atende a

uma funcionalidade de forma correta.

CÓDIGO COLETIVO “A parte do projeto de responsabilidade de uma única pessoa impossibilita que outra torne-se

conhecedora da mesma”.

• Ao contrário do modelo tradicional, onde é comum dividir tarefas e

delegar responsáveis por cada uma delas, a XP não responsabiliza

pessoas unitárias;

• A programação em dupla torna possível o rodízio de desenvolvedores

bem como o conhecimento do código;

• Todo dupla tem acesso e liberdade para alterar qualquer parte do

código a qualquer momento sem qualquer tipo de aviso;

• Essa prática torna o código revisado e caso não esteja claro torna

possível o refactoring.

PADRÕES DE

DESENVOLVIMENTO

• Todo o código desenvolvido pela equipe, deve ser padronizado;

• A padronização deve ser definida desde do início do projeto;

• Cada dupla deve conseguir ler e interpretar o código de forma rápida;

• Recomenda-se que utilize-se a padronização da comunidade da

linguagem de desenvolvimento;

• O código deve parecer que foi escrito por uma única e competente

pessoa;

DESIGN SIMPLES

• Assim como tudo em XP, o design do projeto deve ser o mais simples

possível;

• Evita que o custo de uma alteração no sistema cresça

exponencialmente ao longo do projeto;

• Evita especulações e implementações que não terão utilidades para

o cliente;

• Em XP, o custo de uma alteração deve crescer lentamente e se

estabilizar ao longo do projeto;

• Os avanços nas linguagens, as práticas de desenvolvimento, a

orientação à objetos e os ambientes de desenvolvimento ajudam a

deixar o código mais simples, legível e passível de alteração a

qualquer momento;

METÁFORA “Falar as coisas assim como elas são nem sempre ajudam a entender. É necessário utilizar

Metáforas”.

• Em XP o uso de metáforas é tratado como obrigação;

• Evite repetir a mesma coisa várias vezes, a utilização de analogias

facilita o entendimento das pessoas;

• As analogias ajuda a fixar os assuntos entre as partes;

• Criar boas metáforas exige criatividade e desenvolvimento de ideias,

esteja bem condicionado fisicamente e mentalmente para realizar tias

atividades;

• Utilize as metáforas na hora de descrever como o sistema funciona.

RÍTMO SUSTENTÁVEL “Trabalho deve ser deixado no trabalho! Trabalhe a 100% durante as 40 horas e descanse a

100% no resto”.

• A maioria dos projetos não são finalizados a tempo;

• Desenvolvedores são levados a trabalharem até tarde e sacrificarem

seus finais de semana;

• Sobrecarga de trabalho gera perda de concentração, queda de

rendimento, aumento no índice de erros dos desenvolvedores;

• XP proíbe que os desenvolvedores trabalhem até tarde;

• Sugere um ritmo sustentável de 40h semanais;

• Visa o bem-estar físico e mental da equipe.

INTEGRAÇÃO CONTÍNUA

• O projeto é divido em módulos;

• Cada módulo do projeto deve estar interligado com os demais;

• Os módulos não devem ser responsabilidades individualizadas;

• Módulos individualizados são mais propícios a erros de integração;

• Compilações devem ser realizadas várias vezes ao dia;

RELEASES CURTOS

• Assim que as integrações vão sendo realizadas, novas versões

(releases) do projeto vão sendo entregues ao cliente;

• Facilita a detecção de novas funcionalidades;

• Agiliza a detecção de falhas pois vão sendo avalidadas no mesmo

momento;

• Visam gerar valor econômico imediato ao cliente, já que na maioria

dos casos o cliente só começa a ter benefícios do sistema quando ele

já está quase finalizado.

EQUIPE XP

“Em uma equipe XP existem papeis a serem desempenhados por um ou mais desenvolvedores”.

Gerente de Projeto: Responsável pelos assuntos administrativos e por

manter um forte relacionamento com o cliente e a equipe. Ele deve filtrar os

assuntos sem importância aos desenvolvedores bem como as

implementações futuras;

Coach: Responsável pelas questões técnicas do projeto bem como os

processos de desenvolvimento, valores e práticas de XP;

EQUIPE XP

Analista de Teste: Responsável por garantir a qualidade do sistema através

de testes escritos. Ele deve ajudar o cliente a escrever os casos de testes e no

final de cada iteração verificar se o software atende todos os casos de testes. Recomenda-se que esta pessoa não seja um desenvolvedor, para evitar uma

visão tendenciosa já que não conhece o código desenvolvido. O analista de

teste deve ter uma visão muito parecida com a do cliente e em muitos

projetos esta pessoa acaba exercendo o papel de redator técnico

Redator Técnico: Pessoa responsável em documentar o sistema, evitando

um forte trabalho dos desenvolvedores neste tipo de atividade, permitindo

uma maior dedicação ao trabalho de codificação.

Esta pessoa deve estar em plena sintonia com os desenvolvedores e cliente

para que a documentação reflita o código escrito e as regras de

negócio atendidas pelo sistema.

EQUIPE XP

Desenvolvedor: Pessoa responsável em analisar, projetar e codificar o

sistema. No XP não existe diferença entre analista, projetista e programador

uma vez que em vários momentos do projeto o desenvolvedor estará

exercendo alguma destas atividades.

Naturalmente existem níveis distintos de desenvolvedores dentro de uma

equipe, mas com as práticas do XP, como pair programming, a tendência é a

equipe se tornar uniforme em suas habilidades.

REFERÊNCIAS

• http://improveit.com.br/xp

• http://www.extremeprogramming.org/

• http://www.linhadecodigo.com.br/artigo/764/xp---extreme-programming---

parte-1.aspx

• http://www.cin.ufpe.br/~gamr/FAFICA/Desenvolvimento%20de20sistemas/XP.p

df

• http://www.spinsp.org.br/apresentacao/SpinXP.pdf

• http://javafree.uol.com.br/artigo/871447/Apresentando-XP-

Encante-seus-clientes-com-Extreme-Programming.html

• http://www.devmedia.com.br/articles/viewcomp.asp?comp=1498

• http://xprogramming.com/what-is-extreme-programming/

DÚVIDAS?

OBRIGADO PELA ATENÇÃO