<ul>Extreme Programming </ul><ul>Ricardo L. A. Bánffy Hiperlógica </ul>
<ul>Motivações </ul><ul><li>Requerimentos mutáveis </li></ul><ul><ul><ul><li>Não é mais possível projetar um sistema ao lo...
Internet-time e vantagens de first-to-market </li></ul></ul></ul>
<ul>12 práticas </ul>
<ul>12 práticas </ul><ul><li>Processo de Planejamento (“Planning Game”)
Releases Frequentes
Metáfora do Sistema
O Mais Simples que Possa Funcionar
Testar Antes
Refactoring </li></ul><ul><li>Pair-Programming
Propriedade Coletiva do Código
Integração Contínua
Semanas de 40 Horas
Cliente Sempre Presente
Padrões de Codificação </li></ul>
<ul>Planning Game </ul><ul><li>Equipe de negócios (Cliente) escreve estórias (curtas) sobre funcionalidades do sistema, us...
Equipe técnica (Programadores) estima o custo das estórias
Cliente decide qual  a duração do próximo ciclo
Cliente escolhe, com base nas estimativas dos programadores, quais estórias serão atendidas nesse ciclo e quais ficarão no...
Garante que o cliente tenha o maior retorno em cada ciclo de desenvolvimento </li></ul>
<ul>Releases Frequentes </ul><ul><li>Minimizam a quantidade de recursos investida em cada release
Ciclos curtos, na ordem de dias ou semanas, permitem retorno rápido sobre o investimento – funcionalidades importantes ent...
Próximos SlideShares
Carregando em…5
×

Extreme Programming

1.374 visualizações

Publicada em

Uma introdução ao XP dada na Comdex/SP de 2002

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.374
No SlideShare
0
A partir de incorporações
0
Número de incorporações
73
Ações
Compartilhamentos
0
Downloads
27
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Extreme Programming

  1. 1. <ul>Extreme Programming </ul><ul>Ricardo L. A. Bánffy Hiperlógica </ul>
  2. 2. <ul>Motivações </ul><ul><li>Requerimentos mutáveis </li></ul><ul><ul><ul><li>Não é mais possível projetar um sistema ao longo de 6 meses, implementá-lo ao longo de um ano, colocá-lo em produção e esperar que ele ainda resolva algum problema real </li></ul></ul></ul><ul><li>Limitação da complexidade </li></ul><ul><ul><ul><li>Custo de manutenção de um sistema aumenta com o tempo se a complexidade não for limitada </li></ul></ul></ul><ul><li>Agilidade </li></ul><ul><ul><ul><li>Releases frequentes garantem que problemas mais críticos são resolvidos mais cedo
  3. 3. Internet-time e vantagens de first-to-market </li></ul></ul></ul>
  4. 4. <ul>12 práticas </ul>
  5. 5. <ul>12 práticas </ul><ul><li>Processo de Planejamento (“Planning Game”)
  6. 6. Releases Frequentes
  7. 7. Metáfora do Sistema
  8. 8. O Mais Simples que Possa Funcionar
  9. 9. Testar Antes
  10. 10. Refactoring </li></ul><ul><li>Pair-Programming
  11. 11. Propriedade Coletiva do Código
  12. 12. Integração Contínua
  13. 13. Semanas de 40 Horas
  14. 14. Cliente Sempre Presente
  15. 15. Padrões de Codificação </li></ul>
  16. 16. <ul>Planning Game </ul><ul><li>Equipe de negócios (Cliente) escreve estórias (curtas) sobre funcionalidades do sistema, usualmente em cartões
  17. 17. Equipe técnica (Programadores) estima o custo das estórias
  18. 18. Cliente decide qual a duração do próximo ciclo
  19. 19. Cliente escolhe, com base nas estimativas dos programadores, quais estórias serão atendidas nesse ciclo e quais ficarão nos próximos ciclos
  20. 20. Garante que o cliente tenha o maior retorno em cada ciclo de desenvolvimento </li></ul>
  21. 21. <ul>Releases Frequentes </ul><ul><li>Minimizam a quantidade de recursos investida em cada release
  22. 22. Ciclos curtos, na ordem de dias ou semanas, permitem retorno rápido sobre o investimento – funcionalidades importantes entrarão em funcionamento mais cedo
  23. 23. Todo o código pronto (que passa em todos os testes unitários) deve ser integrado e o sistema todo testado após a integração </li></ul>
  24. 24. <ul>Metáfora do Sistema </ul><ul><li>Comunica de forma clara o que se espera de um produto
  25. 25. Unifica a nomenclatura e estabelece uma linguagem cumum entre negócios e tecnologia
  26. 26. Ajuda os programadores a compreender o domínio do problema </li></ul>
  27. 27. <ul>O Mais Simples que Possa Funcionar </ul><ul><li>Menor complexidade diminui riscos – A complexidade é o inimigo
  28. 28. Software tende naturalmente a crescer e se tornar mais complexo (mais interações entre componentes distintos aumentam o risco de quebras em alterações)
  29. 29. Software é alterado durante sua vida útil – requerimentos mudam e o software pode se tornar mais complexo que os requerimentos necessitem
  30. 30. Garante que não serão gastos recursos em estórias que alguém “acha” que serão um dia necessárias </li></ul>
  31. 31. <ul>Testar Antes </ul><ul><li>Testes devem ser escritos ANTES de se codificar a funcionalidade do produto
  32. 32. Testes funcionam como documentação (embora não a substituam)
  33. 33. Escrever os testes obriga a pensar na forma como o componente será usado ANTES de codificá-lo
  34. 34. Um componente só está pronto se todas as formas com que ele for usado passarem nos testes correspondentes </li></ul>
  35. 35. <ul>Unit-testing (apêndice) </ul><ul><li>Testes devem ser automatizados para serem executados sempre que possível
  36. 36. Testes de difícil execução serão eventualmente abandonados
  37. 37. Tuda a funcionalidade que não estiver sendo testada ou deveria estar sendo testado ou não é necessária e deveria ser removida
  38. 38. Framework de testes (xUnit) </li></ul>
  39. 39. <ul>Refactoring </ul><ul><li>Código tende a se deteriorar ao longo do tempo
  40. 40. Soluções brilhantes de um dia parecem estúpidas depois de uma semana
  41. 41. Refactoring não deve acrescentar funcionalidade – apenas “limpar” a funcionalidade existente
  42. 42. É sempre recomendável fazer refactoring antes de acrescentar alguma funcionalidade </li></ul>
  43. 43. <ul>Pair-Programming </ul><ul><li>Duas cabeças pensam melhor do que uma
  44. 44. Uma cabeça obriga a outra a pensar no problema
  45. 45. Se um colega não entende o código ele não está suficientemente claro e não será entendido depois
  46. 46. Para promover o entendimento da solução, é desejável que as duplas sejam formadas por programadores com níveis diferentes de experiência
  47. 47. Funciona como um code-review em tempo real
  48. 48. Menos distrações (ICQ, Slashdot, e-mail) </li></ul>
  49. 49. <ul>Propriedade Coletiva do Código </ul><ul><li>Se algo está quebrado, complexo demais ou poderia ser melhorado, isso seve ser corrigido
  50. 50. Todos os programadores devem ser capazes de consertar qualquer código do sistema – não pode haver especialistas numa única parte
  51. 51. Evita dependência de profissionais
  52. 52. Promove o entendimento global da solução (sem caixas-pretas de funcionalidade) </li></ul>
  53. 53. <ul>Integração Contínua </ul><ul><li>A versão “oficial”, passando em todos os testes unitários e funcionais deve estar sempre disponível
  54. 54. Todo o novo desenvolvimento deve partir dessa versão
  55. 55. Todo código pronto (que passa em todos os testes) deve ser incorporado a essa versão assim que possível </li></ul>
  56. 56. <ul>Semanas de 40 horas </ul><ul><li>Horas extras e viradas de noite produzem código de baixa qualidade
  57. 57. Programadores devem ter uma vida própria para se manterem felizes, saudáveis e produtivos
  58. 58. Horas extras são um sinal de alarme para a equipe </li></ul>
  59. 59. <ul>Cliente Sempre Presente </ul><ul><li>Responde dúvidas melhor e mais rapidamente
  60. 60. Comunicação pessoal é mais eficiente do que por escrito
  61. 61. Programadores não devem tomar decisões para as quais não estão preparados (e pelas quais serão responsabilizados) </li></ul>
  62. 62. <ul>Padrões de Codificação </ul><ul><li>Se todos os programadores devem editar qualquer parte do código, eles precisam ser capazes de entendê-lo
  63. 63. Código deve ser mantido legivel para a “posteridade”, limitando o aumento de custo de manutenção ao longo do tempo
  64. 64. Os padrões não precisam ser arbitrários ou impostos com uso de violência – é desejável que sejam consensuais </li></ul>
  65. 65. <ul>Dificuldades </ul><ul><li>Cliente ausente </li></ul><ul><ul><ul><li>Procure um substituto para representar o cliente: um gerente de conta ou gerente de produto (quando o cliente for algo como “mercado”) </li></ul></ul></ul><ul><li>Mais de um cliente </li></ul><ul><ul><ul><li>Procure obter um único representante que tenha poder de decidir pelos vários interesses do cliente. Os clientes devem poder se reunir entre si antes de se reunir com a equipe técnica </li></ul></ul></ul><ul><li>Privacidade, ambiente hostil, ferramentas estranhas </li></ul><ul><ul><ul><li>Quando desenvolvedores resistem ao pair-programming, procure criar um espaço para pair-programming – máquinas dedicadas a isso com editores e OSs que os programadores prefiram </li></ul></ul></ul>
  66. 66. <ul>Dificuldades </ul><ul><li>Custos </li></ul><ul><ul><ul><li>Pair-programming é caro à primeira vista. Argumente que os programadores vão se dispersar menos e que o código será de melhor qualidade do que se estivessem trabalhando sozinhos </li></ul></ul></ul><ul><li>Sistemas legados </li></ul><ul><ul><ul><li>É mais fácil começar o projeto em XP do que mudá-lo para XP durante sua execução. Procure fazer a transição em algum momento de descontinuidade (entrega de funcionalidade) </li></ul></ul></ul>
  67. 67. <ul>Dificuldades </ul><ul><li>Propriedade do código </li></ul><ul><ul><ul><li>Programadores não podem ter “ciúmes” de suas criações
  68. 68. Encoraje o uso das mesmas linguagens e bibliotecas por toda a aplicação </li></ul></ul></ul><ul><li>Dificuldades para testar </li></ul><ul><ul><ul><li>Sempre testar componentes quanto à funcionalidade.
  69. 69. Separação entre conteúdo e apresentação ajuda
  70. 70. Componentes de interface podem ser testados separadamente
  71. 71. Alguns componentes dependem de funcionalidade externa – testing frameworks podem ter que ser desenvolvidos para a sua plataforma (ex: zUnit)
  72. 72. Componentes devem ser construídos de forma a facilitar os testes </li></ul></ul></ul>
  73. 73. <ul>Dificuldades </ul><ul><li>Internet-Time </li></ul><ul><ul><ul><li>Pressões nos induzem a reverter a práticas menos adequadas
  74. 74. Ciclos podem se tornar curtos demais para funcionar
  75. 75. Tendência a abandonar testes acreditando que sacrificar qualidade poupe tempo (pode poupar, mas afeta a qualidade e a vida útil do software) </li></ul></ul></ul>
  76. 76. <ul>Para saber mais </ul><ul>www.extremeprogramming.org www.xprogramming.com www.hiper.com.br </ul><ul>[email_address] Hiperlógica, sites automáticos Av. Brig. Faria Lima, 628 cj. 61 São Paulo • SP • 05426-000 (55 11) 3816 7785 www.hiper.com.br </ul>

×