Your SlideShare is downloading. ×
0
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Introdução ao eXtreme Programming (XP) - Paulo Correia
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Introdução ao eXtreme Programming (XP) - Paulo Correia

1,115

Published on

Apresentação de Introdução ao eXtreme Programming (XP) na segunda reunião presencial da comunidade NetPonto

Apresentação de Introdução ao eXtreme Programming (XP) na segunda reunião presencial da comunidade NetPonto

Published in: Technology, News & Politics
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,115
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
30
Comments
0
Likes
3
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
  • Assumir a mudança (de requisitos) como parte do processo e não uma excepçãoObjectivo de gerar o máximo valor para o cliente com:Alta qualidadeAgilidadeFlexibilidadeCusto reduzidoPrimeiro projecto em 6 Março 1996
  • O desenvolvimento é feito em iterações semanais. No início da semana, desenvolvedores e cliente reúnem-se para estabelecer as prioridades das funcionalidades/user stories. Essa reunião recebe o nome de Jogo do Planeamento.Nela, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente é essencial neste processo e assim ele fica sabendo o que está acontecendo e o que vai acontecer no projecto. Como o escopo é reavaliado semanalmente, o projecto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projectos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção.
  • A liberação de pequenas versões funcionais do projecto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando. As versões chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP.No início do projeto, deve-se determinar o número máximo de estórias e estimá-las. A estimativa é sempre feita pelos programadores.Ao mostrar os releases, dizer que no início de cada um se faz o planejamento do release. Nele, o cliente indica as estórias que devem ser feitas. Estas estórias podem mudar ao longo do release, de acordo com as priridades do cliente.No início de cada iteração, ocorre o planejamento da iteração. O cliente decide o que será feito na iteração. Ao contrário do planejamento do release, o cliente não pode alterar as estórias que serão executadas em uma iteração. Elas ficam completamente congeladas.No início de cada semana, a equipe planeja as tarefas que serão executadas ao longo da semana.No início de cada manhã, a equipe faz um stand up meeting e prioriza as atividades do dia que se inicia.
  • A liberação de pequenas versões funcionais do projecto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando. As versões chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP.No início do projeto, deve-se determinar o número máximo de estórias e estimá-las. A estimativa é sempre feita pelos programadores.Ao mostrar os releases, dizer que no início de cada um se faz o planejamento do release. Nele, o cliente indica as estórias que devem ser feitas. Estas estórias podem mudar ao longo do release, de acordo com as priridades do cliente.No início de cada iteração, ocorre o planejamento da iteração. O cliente decide o que será feito na iteração. Ao contrário do planejamento do release, o cliente não pode alterar as estórias que serão executadas em uma iteração. Elas ficam completamente congeladas.No início de cada semana, a equipe planeja as tarefas que serão executadas ao longo da semana.No início de cada manhã, a equipe faz um stand up meeting e prioriza as atividades do dia que se inicia.
  • Procura facilitar a comunicação com o cliente, entendendo a realidade dele. O conceito de rápido para um cliente de um sistema jurídico é diferente para um programador experiente em controlar comunicação em sistemas em tempo real, como controle de tráfego aéreo. É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projecto.
  • Simplicidade é um princípio da XP. Projecto simples significa dizer que caso o cliente tenha pedido que na primeira versão apenas o usuário "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, você vai fazer o código exacto para que esta funcionalidade seja implementada, sem se preocupar com sistemas de autenticação e restrições de acesso. Um erro comum ao adoptar essa prática é a confusão por parte dos programadores de código simples e código fácil. Nem sempre o código mais fácil de ser desenvolvido levará a solução mais simples por parte de projecto. Esse entendimento é fundamental para o bom andamento do XP. Código fácil deve ser identificado e substituído por código simples.
  • A equipe de desenvolvimento é formada pelo cliente e pela equipa de desenvolvimento.
  • São testes construídos pelo cliente e conjunto de analistas e testers, para aceitar um determinado requisito do sistema.
  • Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projecto. Outra prática que se verifica neste processo é a prática de trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.
  • Reuniões em pé para não se perder o foco nos assuntos, produzindo reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.
  • O código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objectivo com isto é fazer a equipe conhecer todas as partes do sistema.
  • é a programação em par/dupla num único computador. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de erros (bugs). Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.
  • A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.
  • Primeiro crie os testes unitários (unit tests) e depois crie o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do projecto seja mantida.
  • É um processo que permite a melhoria continua da programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Reconstruirmelhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de códigofonte;
  •  Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão actual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.
  • Transcript

    • 1. http://netponto.pt<br />2ª Reunião Presencial - 19/09/2009<br />Introdução ao eXtreme ProgrammingPaulo Correia<br />
    • 2. Paulo Correia<br />14 anos de experiência profissional em TI<br />Vivi mais de 4 anos no Brasil, voltei há 4 anos<br />Experiência em projectos desde e-commerce, portais de conteúdo, banca, etc.<br />
    • 3. Agenda<br />Introdução<br />Valores do XP<br />Práticas do XP<br />Porque funciona?<br />Benefícios<br />Conclusão<br />
    • 4. Introdução / O que é?<br />Processo de desenvolvimento de software<br />Mais um?<br />
    • 5. Introdução / Tradicionalmente...<br />
    • 6. Introdução / Tradicionalmente...<br />
    • 7. Introdução / Tradicionalmente...<br />
    • 8. Introdução / Tradicionalmente...<br />
    • 9. Valores do XP<br />Feedback<br />Comunicação<br />Simplicidade<br />Coragem<br />
    • 10. Valores do XP<br />Feedback<br />Comunicação<br />Simplicidade<br />Coragem<br />
    • 11. Valores do XP<br />Feedback<br />Comunicação<br />Simplicidade<br />Coragem<br />
    • 12. Valores do XP<br />Feedback<br />Comunicação<br />Simplicidade<br />Coragem<br />
    • 13. Práticas do XP<br />
    • 14. Práticas do XP<br />Planning Game<br />
    • 15. Práticas do XP<br />Small Releases<br />Projeto: 8 meses = 32 semanas<br />8 Sem.<br />R1<br />R2<br />R3<br />R4<br />
    • 16. Práticas do XP<br />Small Releases<br />Projeto: 8 meses = 32 semanas<br />8 Sem.<br />R1<br />R2<br />R3<br />R4<br />2 Sem.<br />I2<br />I3<br />I4<br />I1<br />
    • 17. Práticas do XP<br />Metáfora<br />
    • 18. Práticas do XP<br />Simple Design<br />
    • 19. Práticas do XP<br />Equipa coesa<br />
    • 20. Práticas do XP<br />Acceptance tests<br />
    • 21. Práticas do XP<br />Ritmo Sustentável<br />
    • 22. Práticas do XP<br />Stand-up Meeting<br />
    • 23. Práticas do XP<br />Collective Ownership<br />
    • 24. Práticas do XP<br />Pair Programming<br />
    • 25. Práticas do XP<br />Coding Standards<br />
    • 26. Práticas do XP<br />Test Driven Development<br />
    • 27. Práticas do XP<br />Refactoring<br />Com<br />Sem<br />
    • 28. Práticas do XP<br />Continuous Integration<br />
    • 29. Porque funciona?<br />Assente em disciplina sem burocracia<br />Desenvolvimento como convenção<br />O código é a documentação<br />Melhor qualidade de vida<br />XP dá pica <br />
    • 30. Benefícios<br />Equipa que desenvolve<br />Requisitos e prioridades mais explícitos<br />Bom desempenho<br />Nada de horas extra<br />Conhecimento de todas as partes do projecto<br />Sentimento de concretização<br />Cliente<br />Obtém valor para o negócio logo desde o inicio<br />Feedback preciso de como está a decorrer o projecto<br />Toma decisões de negócio com bases concretas<br />Pode mudar de ideias/requisitos<br />
    • 31. Conclusão<br /><ul><li>Recomenda-se XP em projectos:
    • 32. Com requisitos mutáveis ou vagos
    • 33. Pequenas equipas
    • 34. XP funciona e é muito ágil
    • 35. XP é fácil e divertido</li></li></ul><li>Referências<br />Wikipedia<br />http://en.wikipedia.org/wiki/Extreme_Programming<br />Extreme Programming<br />http://www.extremeprogramming.org/<br />XP Rio<br />http://tech.groups.yahoo.com/group/xprio/<br />Embracing Change with Extreme Programming, K. Beck<br />http://bit.ly/leAcx<br />Software Engineering Principles and Practices<br />http://bit.ly/kcDzR<br />
    • 36. Dúvidas?<br />
    • 37. Patrocinadores desta reunião<br />
    • 38. Obrigado!<br />Paulo Correia<br />paulo.iap@gmail.com<br />http://weblogs.pontonetpt.com/paulo_iap<br />http://twitter.com/paulo_iap<br />

    ×