Baixar para ler offline
Carregado porceife
Extreme Programming
O documento resume os princípios e práticas da metodologia de desenvolvimento ágil Extreme Programming (XP). O XP tem como objetivos levar ao extremo boas práticas de engenharia de software, como testes constantes, revisões frequentes e desenvolvimento incremental. Os valores fundamentais do XP incluem comunicação, simplicidade, feedback rápido e respeito. As principais práticas são programação em pares, propriedade coletiva do código, desenvolvimento guiado por testes e integração contínua.
Extreme Programming
- 1. eXtreme Programming Aluno: Felipeda Conceição Silva Data: 26/10/2017 Curso: ADS
- 2. O XP O queé? Objetivos Valores Princípios
- 3. Oque é? » Éuma metodologia de desenvolvimento ágil para criação de software; » Criado em 1997 por Kent Beck; » Livro publicado em 1999 por Kent Beck; » Manifesto Ágil em 2001 » http://www.extremeprogramming.org
- 4. Objetivos » Levar aoextremo um conjunto de práticas que são boas na engenharia de Software.
- 5. Boas práticas emengenharia de Software » Já que testar é bom, que todos testem o tempo todo; » Já que revisão é bom, que se revise o tempo todo; » Se projetar é bom, então refatorar o tempo todo; » Se teste de integração é bom, então que se integre o tempo todo; » Se simplicidade é bom, desenvolva uma solução não apenas que funcione, mas que seja a mais simples possível; » Se iterações curtas é bom, então mantenha-as realmente curtas;
- 6. Valores » Comunicação » Simplicidade »Feedback » Coragem » Respeito
- 7. Valores » Comunicação: Sejaentre desenvolvedores ou com clientes; » Simplicidade: Caso seja necessário faremos algo mais complexo amanhã; » Feedback: Precisa ser cedo para sabermos se estamos fazendo a coisa correta; » Coragem: Paradigma, fora código ruim, erros, mudanças; » Respeito: Pelos colegas de time e pelo cliente é muito importante;
- 8. Princípios » Feedback rápido »Presumir simplicidade » Mudanças incrementais » Abraçar mudanças » Trabalho de alta qualidade
- 9. Práticas Jogo de Planejamento Fasespequenas Design simples Testes de Aceitação Semana de 40 horas Trabalho energizado Propriedade coletiva Programação pareada ou em pares Padronização do código TDD Integração Continua
- 10. Jogo de Planejamento(Planning game) Reunião com clientes e desenvolvedores para priorizar funcionalidades e custos.
- 11. Fases pequenas (Smallreleases) Pequenas versões funcionais do projeto auxiliam no processo de aceitação do cliente, cujo já pode testar parte do sistema que está comprando.
- 12. Design simples (Simpledesign) Desenvolvedor faz exatamente como o cliente pediu.
- 13. Testes de Aceitação(Customer tests) Testes construídos pelo cliente em conjunto de analistas e testadores para aceitar determinado requisito.
- 14. Semana de 40horas (Sustainable place) Trabalhar com qualidade buscando um ritmo de trabalho saudável, sem horas extras se possível.
- 15. Trabalho energizado Trabalho motivado,com ambiente e equipe em harmonia.
- 16. Propriedade coletiva (CollectiveOwnership) Código fonte sem dono, não precisa pedir permissão para alterá-lo. Assim a equipe pode conhecer todas as partes do sistema.
- 17. Programação pareada ouem pares (Pair programming) Programação em dupla com um único computador, geralmente um iniciante com outra mais experiente. O novato fica à frente do computador enquanto que o experiente auxilia. Assim o programa é revisto por duas pessoas, diminuindo defeitos e evoluindo a equipe.
- 18. Programação pareada ouem pares (Pair programming) Programação em dupla com um único computador, geralmente um iniciante com outra mais experiente. O novato fica à frente do computador enquanto que o experiente auxilia. Assim o programa é revisto por duas pessoas, diminuindo defeitos e evoluindo a equipe.
- 19. Padronização do código(Coding Standards) A equipe estabelece regras para programar, assim diminui a dificuldade nas revisões do código.
- 20. Desenvolvimento Orientado aTestes (Test Driven Development (TDD)) Ciclos de repetições onde a cada funcionalidade que for implementada.
- 21. Integração Contínua (ContinuousIntegration) Não adiar integração de novas funcionalidades do projeto.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.