Introdução ao eXtreme Programming (XP) - Paulo Correia
•Descargar como PPTX, PDF•
3 recomendaciones•835 vistas
Este documento apresenta uma introdução ao Extreme Programming (XP), um framework ágil para desenvolvimento de software. Apresenta os valores e práticas centrais do XP, incluindo feedback constante, comunicação, lançamentos frequentes e pequenos, design simples e pair programming. Explica como estas práticas levam a benefícios como maior qualidade de software e satisfação do cliente.
Recomendados
Más contenido relacionado
Similar a Introdução ao eXtreme Programming (XP) - Paulo Correia
Similar a Introdução ao eXtreme Programming (XP) - Paulo Correia (20)
Más de Comunidade NetPonto
Más de Comunidade NetPonto (20)
Último
Último (9)
Introdução ao eXtreme Programming (XP) - Paulo Correia
- 1. http://netponto.org 2ª Reunião Presencial - 19/09/2009 Introdução ao eXtreme ProgrammingPaulo Correia
- 2. Paulo Correia 14 anos de experiência profissional em TI Vivi mais de 4 anos no Brasil, voltei há 4 anos Experiência em projectos desde e-commerce, portais de conteúdo, banca, etc.
- 3. Paulo Correia 14 anos de experiência profissional em TI Vivi mais de 4 anos no Brasil, voltei há 4 anos Experiência em projectos desde e-commerce, portais de conteúdo, banca, etc.
- 4. Agenda Introdução Valores do XP Práticas do XP Porque funciona? Benefícios Conclusão
- 5. Introdução / O que é? Processo de desenvolvimento de software Mais um?
- 10. Valores do XP Feedback Comunicação Simplicidade Coragem
- 11. Valores do XP Feedback Comunicação Simplicidade Coragem
- 12. Valores do XP Feedback Comunicação Simplicidade Coragem
- 13. Valores do XP Feedback Comunicação Simplicidade Coragem
- 14. Práticas do XP
- 15. Práticas do XP Planning Game
- 16. Práticas do XP Small Releases Projeto: 8 meses = 32 semanas 8 Sem. R1 R2 R3 R4
- 17. Práticas do XP Small Releases Projeto: 8 meses = 32 semanas 8 Sem. R1 R2 R3 R4 2 Sem. I2 I3 I4 I1
- 18. Práticas do XP Metáfora
- 19. Práticas do XP Simple Design
- 20. Práticas do XP Equipa coesa
- 21. Práticas do XP Acceptance tests
- 22. Práticas do XP Ritmo Sustentável
- 23. Práticas do XP Stand-up Meeting
- 24. Práticas do XP Collective Ownership
- 25. Práticas do XP Pair Programming
- 26. Práticas do XP Coding Standards
- 27. Práticas do XP Test Driven Development
- 28. Práticas do XP Refactoring Com Sem
- 29. Práticas do XP Continuous Integration
- 30. Porque funciona? Assente em disciplina sem burocracia Desenvolvimento como convenção O código é a documentação Melhor qualidade de vida XP dá pica
- 31. Benefícios Equipa que desenvolve Requisitos e prioridades mais explícitos Bom desempenho Nada de horas extra Conhecimento de todas as partes do projecto Sentimento de concretização Cliente Obtém valor para o negócio logo desde o inicio Feedback preciso de como está a decorrer o projecto Toma decisões de negócio com bases concretas Pode mudar de ideias/requisitos
- 33. Com requisitos mutáveis ou vagos
- 34. Pequenas equipas
- 35. XP funciona e é muito ágil
- 37. Dúvidas?
- 39. Obrigado! Paulo Correia paulo.iap@gmail.com http://weblogs.pontonetpt.com/paulo_iap http://twitter.com/paulo_iap
Notas del editor
- 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.