1 / 61

Extreme Programming

Extreme Programming. Manifesto do Desenvolvimento Ágil. www.agilealliance.org Aplicar os ideais do desenvolvimento ágil ao nosso processo particular poderia nos ajudar a ser mais ágeis, mesmo que não pudéssemos adotar XP. Indivíduos e interações mais que processos e ferramentas.

nara
Download Presentation

Extreme Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Extreme Programming

  2. Manifesto do Desenvolvimento Ágil www.agilealliance.org Aplicar os ideais do desenvolvimento ágil ao nosso processo particular poderia nos ajudar a ser mais ágeis, mesmo que não pudéssemos adotar XP. Indivíduos e interaçõesmais que processos e ferramentas. Trabalhar no softwaremais que documentação abrangente. Colaboração do clientemais que negociação contratual. Responder às mudançasmais que seguir um plano.

  3. O que é XP? • Processo de desenvolvimento de software • Projetos com requisitos muito voláteis • Equipes pequenas (até ~10 pessoas) • Desenvolvimento incremental

  4. O que é um projeto de sucesso? • Cumpre o orçamento • Cumpre o prazo • Cliente fica feliz • Equipe fica feliz

  5. Premissas do desenvolvimento • Cliente é capaz de especificar um software antes de iniciar o desenvolvimento • Equipe de desenvolvimento é capaz de quantificar o esforço • Equipe é capaz de criar o software imaginado pelo cliente • Cliente ficará feliz

  6. Resumo • Divisão nítida entre “produção” e “consumo” • Cliente produz uma especificação que é consumida pela equipe de desenvolvimento • Equipe de desenvolvimento produz o software que é consumido pelo cliente

  7. Custo Tempo de Projeto $ 1 Requisitos $ 10 Análise $ 100 Design $ 1.000 Implem. $ 10.000 Testes Motivação: custo de uma alteração

  8. Premissas Básicas do Modelo Tradicional • É necessário fazer uma análise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema. • É necessário fazer um estudo minucioso e elaborar uma descrição detalhada da arquitetura antes de começar a implementá-la. • É necessário testar o sistema completamente antes de mandar a versão final para o cliente.

  9. Por que software falha?

  10. Problemas desta premissa • Premissa é irreal em vários casos • O cliente não é capaz de especificar o software previamente • Grande problema: DETALHE

  11. Premissa do desenvolvimento ágil • APRENDIZADO • FEEDBACK • DESENVOLVIMENTO ITERATIVO

  12. Aprendizado • O cliente aprende durante o desenvolvimento • Descobre novas possibilidades • Muda as prioridades

  13. Trabalho intelectual • Retrabalho é uma característica do trabalho intelectual • ExperimentaçãoCriaçãoRevisãoExperimentação ...

  14. Custo Tempo de Projeto Premissa: custo de uma alteração

  15. E se essa fosse a realidade? • A atitude dos desenvolvedores de software seria completamente diferente: • Tomaríamos as grandes decisões o mais tarde possível. • Implementaríamos agora somente o que precisamos agora. • Não implementaríamos flexibilidade desnecessária (não anteciparíamos necessidades).

  16. E essa é a nova realidade !(pelo menos em muitos casos) • Orientação a Objetos • facilita e cria oportunidades para mudanças • Técnicas de Refatoramento • possibilita melhorar continuamente a implementação aumentando constantemente a qualidade do código produzido • Testes automatizados • nos dão segurança quando fazemos mudanças • Prática / cultura de mudanças • aprendemos técnicas e adquirimos experiência em lidar com código mutante

  17. As 4 Variáveis do Desenvolvimento de Software • Tempo • Custo • Qualidade • Escopo (foco principal de XP)

  18. Valores • Feedback • Comunicação • Simplicidade • Coragem

  19. User Stories • Funcionalidades são informadas através de user stories • Estórias devem ser simples • Desenvolvedores estimam tempo

  20. Planejamento • De posse das estimativas, é possível priorizar • Cliente entrega as estórias priorizadas para serem implementadas • Desenvolvedores respeitam as prioridades dos clientes • Projeto é dividido em partes: releases e iterações

  21. Priorização • Cliente deve priorizar as estórias • Para obter o máximo de valor rapidamente • Se baseia nas suas necessidades e nas estimativas dos desenvolvedores

  22. Release e Iteração Projeto: 8 meses = 32 semanas 8 Sem. R1 R2 R3 R4 2 Sem. I2 I3 I4 I1 1 Sem. S1 S2

  23. 8 Sem. R1 R2 R3 R4 Release Planning • Cliente recebe um “orçamento” dos desenvolvedores • Seleciona as estórias prioritárias que possam ser implementadas dentro do orçamento • Pode trocar estórias durante o release

  24. 2 Sem. I2 I3 I4 I1 Iteration Planning • Cliente recebe um “orçamento” • Não pode haver troca de funcionalidades durante uma iteração • Velocidade: quantidade de estórias que a equipe consegue implementar em uma iteração

  25. Stand-up meeting • Reunião rápida • Diária • Usada para atualização da equipe

  26. Desenvolvimento: orientação a objetos • Sistema é composto por pequenas peças • Peças têm objetivos específicos • Facilita construção • Facilita evolução

  27. Buscando bugs • Sistemas podem ter defeitos • É difícil descobrir qual é a peça defeituosa • É mais fácil se o problema for detectado logo após a adoção da peça

  28. Test Driven Design • No XP, primeiro se especifica o teste • Depois se constrói a peça

  29. Unit Test • Nome dado à verificação feita sobre cada peça • Cada peça possui um unit test associado a ela • Testes são automatizados • Quando uma nova peça entra no sistema, todos os testes são executados

  30. Acceptance Test • Cliente deve especificar testes de aceitação para cada funcionalidade de uma iteração • Sistema deve passar nestes testes ao término da iteração

  31. Pair Programming • Todo código é escrito em par • Duas pessoas trabalham em um único computador • Uma digita, enquanto a outra revisa, corrige e sugere

  32. Collective code ownership • Todos são responsáveis por todas as partes do sistema • Código tem que estar sempre “limpo” • Todos são capazes de modificá-lo

  33. Refactoring • Uma [pequena] modificação no sistema que não altera o seu comportamento funcional • mas que melhora alguma qualidade não-funcional: • simplicidade • flexibilidade • clareza • desempenho

  34. Exemplos de Refactoring • Mudança do nome de variáveis • Mudanças nas interfaces dos objetos • Pequenas mudanças arquiteturais • Encapsular código repetido em um novo método • Generalização de métodos • raizQuadrada(float x)raiz(float x, int n)

  35. Desenvolvimento em equipe • Como conciliar diversos desenvolvedores? • Estrutura de diretórios • Atualização do código por várias pessoas diferentes

  36. CVS – Repositório de fontes • Check out • Add • Commit • Update • Conflict • Remove

  37. CVS

  38. 40 hour week • Desenvolvimento de software é um trabalho intelectual intenso • Não é produtivo trabalhar além do limite

  39. Customer onsite • Fator mais importante no XP: • Comunicação • Feedback • Viabiliza a simplicidade da metodologia • War room c / quadro branco

  40. Feedback constante • Permite que pequenas mudanças sejam feitas • Evita a necessidade de mudanças bruscas • Mantém o projeto em curso

  41. Integração contínua • Máquina destacada para a integração • Integração ocorre diversas vezes ao dia • Os testes são executados em cada integração • Correções são feitas imediatamente

  42. Ambientes para deployment • Como lidar com diferentes ambientes? • Exemplo: • Desenvolvimento • Aceitação • Produção

  43. Produção Aceitação Desenvolvimento Ambientes para deployment

  44. Problemas de ter vários ambientes • Possíveis erros devido a tarefas manuais repetitivas • Gasto de tempo

  45. Automatização do deployment • Agiliza as integrações • Evita erros

  46. Ant

  47. Exemplo simples <project name="projeto" default="desenvolvimento"> <target name="desenvolvimento"> <mkdir dir="build"/> <javac srcdir="src" destdir="build"/> <junit> <test name="test.SystemTester"/> </junit> </target> </project> tasks target

  48. Ambiente de Desenvolvimento • Desejável que tenha: • Code completion • Validação on-line • Suporte à depuração • Suporte a Refactoring • Integração com jUnit • Integração com CVS • Integração com Ant

More Related