eXtreme Programming (xp)

  • 279 views
Uploaded on

Aula sobre eXtreme Programming. Contém a definição, características e técnicas.

Aula sobre eXtreme Programming. Contém a definição, características e técnicas.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
279
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
11
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. eXtreme Programming (XP)Renato de Pina Ferreirarenpina@gmail.com
  • 2. Conceito Geral.• Foco em agilidade de equipes e qualidade deprojetos, apoiada em valores:– Coragem;– Simplicidade;– Comunicação;– Feedback.2
  • 3. CoragemEla é necessária para que realmente se aplique XPcomo deve ser aplicado. Exemplos de atitude queexigem coragem são:• Alterar código já escrito e que está funcionando;• Jogar código fora e reescrever tudo de novo;• Permitir código compartilhado por todos.Estes exemplos de atitudes podem ser necessários paratrazer melhorias ao projeto e não devem ser evitadassimplesmente devido ao medo de tentá-las.3
  • 4. Simplicidade• XP sugere que cada membro da equipe adote asolução mais fácil que possa funcionar. Oobjetivo é fazer aquilo que é mais simples hoje ecriar um ambiente em que o custo de mudançasno futuro seja baixo.• O objetivo dessa abordagem adotada por XP éevitar a construção antecipada defuncionalidades, que acabam muitas vezes nemsendo usadas.4
  • 5. Comunicação• XP foca em construir um entendimentopessoa-a-pessoa do problema, com o usomínimo de documentação formal e com o usomáximo de interação “cara-a-cara” entre aspessoas envolvidas no projeto.5
  • 6. Feedback• Os programadores obtêm feedback sobre alógica dos programas escrevendo e executandocasos de teste. Os clientes obtêm feedbackatravés dos testes funcionais criados para todasas histórias (casos de uso simplificados).• O feedback é importante, pois possibilita que aspessoas aprendam cada vez mais sobre o sistemae assim corrijam os erros e melhorem o sistema.6
  • 7. Práticas da XP• Extreme Programming é dinâmico e flexível,porém é necessário muita disciplina para usá-la em um projeto. Para demonstrar isso,temos um conjunto sugerido de "boaspráticas" em projetos usando XP.7
  • 8. O jogo do planejamento(Planning Game)O planejamento de um release e das alterações sãofeitos com base nas histórias e conta com acolaboração de toda a equipe de desenvolvimento,inclusive o cliente, divididos em dois papéis:– Negócio: Participam as pessoas que mais entendem sobreo negócio e que possam estabelecer prioridades para asfuncionalidades a serem entregues.– Técnico: Participam as pessoas que irão implementar asfuncionalidades descritas. Os técnicos estimam qual oesforço e riscos envolvidos para implementar asfuncionalidades e comunicam ao pessoal de negócios.8
  • 9. Pequenas versões(Small Releases)• Conforme as interações são concluídas, o clienterecebe pequenas versões (releases) do sistema,visando com que seja colocado em prática evalidado aquilo que está sendo implementado;• Isto também permite que mais cedo possam serdetectadas necessidades de alterações derequisitos no software.9
  • 10. Metáfora(Metaphor)• A intenção da metáfora é oferecer uma visão geral do sistema, emum formato simples, que possa ser compartilhada por clientes eprogramadores;• A ideia da metáfora é que seja feita uma analogia entre o sistemaque está sendo desenvolvido e um sistema, não necessariamentede software, que todos entendam, com o objetivo de obter um“vocabulário comum” para a posterior criação de nomes declasses, subsistemas, métodos, entre outros.– Exemplo: "Vamos chamar nosso projeto de ‘cartão de ponto’, para umsistema que gerencie as batidas de ponto de funcionários, gerando oprovisionamento financeiro e mensal para módulo de folha depagamento".10
  • 11. Projeto simples(Simple Design)Esta prática tem o intuito de enfatizar que o projeto simplesdeve se concentrar em soluções simples e bem estruturadaspara os problemas de hoje e que não se deve perder tempoinvestindo em soluções genéricas que procurem atender afuncionalidades futuras, pois como os requisitos mudamconstantemente tais soluções genéricas podem não ser mais arealidade do futuro.Algumas características de projeto simples:– Todos os testes executam com sucesso;– O projeto expressa a ideia que o programador teve;– O projeto não possui lógica duplicada;– O projeto contém o menor número possível de classes e métodos.11
  • 12. Teste constantes(Test First Design)• Os testes em XP são feitos antes da programação. Existem doistipos de teste: teste de unidade e teste funcional.– Testes de unidade: são feitos para verificar tudo que possa darerrado. Não é preciso escrever testes de unidade para todos osmétodos. Os testes unitários são automatizados, e toda vez que oprogramador escrever código, ele irá verificar se o sistema passa emtodos os testes– Testes funcionais: são usados para verificação, junto ao cliente, dosistema como um todo. Os testes servem como um mecanismo paraassegurar que o sistema está sempre rodando livre de erros, etambém servem para dar feedback aos programadores e clientessobre as falhas encontradas.12
  • 13. Refatoração(Refactoring)• São constantes melhorias no projeto do software paraaumentar sua capacidade de se adaptar a mudanças. Arefatoração consiste em aplicar uma série de passospara melhorar o projeto do código existente, tornando-omais simples e melhor estruturado, sem alterar suafuncionalidade.• A cada nova funcionalidade adicionada, é trabalhado odesign do código até ficar na sua forma mais simples,mesmo que isso implique em "mexer" em um código queesteja em funcionamento.13
  • 14. Programação em pares(Pair Programming)• Todo o código produzido em XP é escrito por um par deprogramadores, que possuem papéis distintos, sentados lado-a-lado e olhando para o computador.• Um parceiro será responsável pela codificação e pensará nosalgoritmos e na lógica de programação. O outro parceiro observa ocódigo produzido e tenta pensar mais estrategicamente em comomelhorá-lo e torná-lo mais simples, além de apontar possíveiserros e pontos de falha.• Além disso, as duplas são constantemente trocadas e os papéistambém, com o objetivo de que todos os membros da equipepossam ter conhecimento sobre todas as partes do sistema.14
  • 15. Propriedade coletiva do código(Collective Code Ownership)• A programação em pares encoraja duas pessoas a trabalharemjuntas procurando atingir o melhor resultado possível.• A propriedade coletiva encoraja a equipe inteira a trabalhar maisunida em busca de qualidade no código fazendo melhorias erefatoração em qualquer parte do código a qualquer tempo.• A princípio pode-se pensar que esta prática possa gerar problemas,mas como todos devem respeitar um padrão de codificação edevem realizar todos os testes para verificação de erros, estaatividade é feita de uma forma controlada e pode ser facilitada como uso de uma ferramenta de controle de versão.15
  • 16. Padrões de codificação(Coding Standards)• Como a XP prega a propriedade coletiva decódigo, onde todos podem alterar e fazerrefatoração de qualquer parte do código aqualquer momento, então é mais do quenecessário que se tenha padrões decodificação. O objetivo é que todosprogramem da mesma forma, facilitando oentendimento do código e as alterações.16
  • 17. Integração contínua(Continuous Integration)• O código das funcionalidades implementadas pode serintegrado várias vezes ao dia. Um modo simples defazer isso é ter uma máquina dedicada (servidor) paraintegração. Quando a máquina estiver livre, um parcom código a integrar ocupa a máquina, carrega aversão corrente do sistema, carrega as alterações quefizeram (resolvendo os erros), e rodam os testes atéque eles passem .• O importante é que na integração as funcionalidadessó podem ser integradas se não houver erros, casocontrário os erros devem ser corrigidos.17
  • 18. Semana de quarenta horas(40 Hour Week)• Trabalhar por longos períodos écontraproducente. Portanto, sempre quepossível, deve-se evitar a sobrecarga de trabalhode todos da equipe, criando condições favoráveisao uso da carga normal de trabalho.• É necessário deixar a equipe livre para relaxar,brincar, ou fazer o quem bem entender paraequilibrar o trabalho mental e físico.18
  • 19. Cliente no local(The Customer is Always Available)• Deve ser incluído na equipe uma pessoa da parte docliente, que irá usar o sistema, para trabalhar juntocom os outros e responder as perguntas e dúvidas;• Mesmo que não seja possível obter alguém da parte docliente deve-se ter alguém que tenha conhecimentosuficiente do negócio para exercer este papel;• O cliente tem um papel importante dentro de umprojeto XP já que ele participa do planejamento doprojeto escrevendo as histórias e priorizando-as.19
  • 20. Gerência de projetos e papéisenvolvidos em XP• A estratégia de gerência adotada em XP é maisvoltada para a tomada de decisõesdescentralizada do que para o controlecentralizado.• O papel do gerente é fazer fluir o jogo doplanejamento, coletar métricas, fazer com queas métricas sejam vistas por aqueles cujotrabalho esteja sendo medido, e ocasionalmenteintervir em situações que não podem serresolvidas de forma distribuída.20
  • 21. Gerência de projetos e papéisenvolvidos em XP• A gerência em XP é dividida através de dois papéis: o treinador(coach) e o rastreador (tracker). Esses papéis podem ou não serexecutados pela mesma pessoa.– Treinador: se preocupa principalmente com a execução técnica eevolução do processo. O treinador ideal deve ser um bomcomunicador, ter um bom conhecimento técnico e ser confiante. Opapel do treinador não é de tomar decisões técnicas, mas de fazercom que todos tomem boas decisões e de facilitar o processo dedesenvolvimento.– Rastreador: coleta métricas sobre o que está sendo desenvolvido econfronta com as métricas estimadas verificando possíveisdivergências. O rastreador deve tomar cuidado para não perturbarmuito os programadores pedindo por métricas.21
  • 22. Gerência de projetos e papéisenvolvidos em XP• Além dos papéis gerenciais apresentadosanteriormente, uma equipe que utiliza XPpara desenvolver software é composta deoutros papéis. Estes são: programador,cliente, testador e consultor.22
  • 23. Gerência de projetos e papéisenvolvidos em XP• Programador: ocupa o principal papel em XP. Eleanalisa, projeta, testa, codifica, e integra osistema.– Além disso, o programador estima a dificuldade dashistórias, faz alterações nessas estimativas, casonecessário. Em XP o foco está na programação e oimportante é entregar funcionalidadesimplementadas para o cliente. O programador estásempre escrevendo testes de unidade, codificando efazendo refatoração com o objetivo de produzircódigo de alta qualidade rapidamente.23
  • 24. Gerência de projetos e papéisenvolvidos em XP• Cliente: escolhe o que vai agregar valor ao seunegócio, escolhe o que deve ser feito primeiroe o que deve ser adiado.– Além disso, o cliente define com a ajuda dostestadores, os testes funcionais que irão mostrarse o sistema realmente faz o que deve ser feito.24
  • 25. Gerência de projetos e papéisenvolvidos em XP• Testador: irá ajudar o cliente na definição eescrita dos testes funcionais. Ele não precisaser uma pessoa com apenas essa função, podedesempenhar também o papel deprogramador.25
  • 26. Gerência de projetos e papéisenvolvidos em XP• Consultor: é necessário apenas em algumassituações onde se precisa de alguém com umelevado nível de conhecimento, por exemplo,um especialista em uma determinadatecnologia sobre determinado assunto quenão está sendo bem compreendido pelaspessoas do projeto.26
  • 27. Quando não se deve usar XP• Os limites exatos de XP ainda não sãoconhecidos, mas existem alguns fatores quesão fortes indicadores para não usar XP como:equipes grandes, clientes desconfiados etecnologia que não dá suporte facilitado paramudanças.27
  • 28. Quando não se deve usar XP• Cultura: A organização pode estar inseridadentro de uma cultura tradicional dedesenvolvimento de software, produzindomuita documentação, gastando muito tempocom análise e projeto antecipado, entre outrascoisas. Fazer com que a equipe passe a adotaras práticas de XP e esqueça as antigas podeser muito difícil.28
  • 29. Quando não se deve usar XP• Tamanho da equipe: Um projeto XP devepossuir uma equipe pequena – geralmenteaté 12 programadores. É difícil imaginar comoficariam alguns conceitos de XP comocomunicação, programação em par e outrasem uma equipe grande.29
  • 30. Quando não se deve usar XP• Espaço físico: A organização do espaço físicoonde a equipe de XP trabalha deve facilitar acomunicação e deixar todos próximos uns dosoutros.30
  • 31. Quando não se deve usar XP• Cliente: XP exige que o cliente participe daequipe do projeto e trabalhe no mesmo localdos demais, estando a disposição, depreferência, o tempo todo para esclarecerdúvidas.31
  • 32. XP nas Empresas Atualmente• A utilização da XP já é notória em diversas empresas nomundo.• Desde a sua criação e aplicação na empresa Chrysler,inúmeras empresas ao redor do mundo vêm utilizandoXP. Isso mostra que essa metodologia é madura, eapresenta uma alternativa no desenvolvimento desoftware para acompanhar a tendência mundial dedesenvolver com agilidade e dinamismo, com focoprincipalmente na produção de conhecimento (TELES,2005).32
  • 33. XP nas Empresas AtualmenteTabela 1: Empresas que utilizam XP em alguns de seus projetos33
  • 34. Referências• http://www.cin.ufpe.br/~gamr/FAFICA/Desenvolvimento%20de%20sistemas/XP.pdf• http://www.gojava.org/files/artigos/ExtremePrograming.pdf• http://www.ic.unicamp.br/~ranido/mc626/XP.pdf• http://www.devmedia.com.br/extreme-programming-conceitos-e-praticas/1498• http://xprogramming.com/index.php• http://zetoniazzo.files.wordpress.com/2007/08/monografia_jose_toniazzo.pdf• TELES, Vinícius Manhães. Extreme Programming: Aprenda como encantar seususuários desenvolvendo software com agilidade e alta qualidade. São Paulo - SP:Novatec Editora Ltda, 2005.34
  • 35. eXtreme Programming (XP)Renato de Pina Ferreirarenpina@gmail.com