Extreme Programming (XP) é um framework ágil para desenvolvimento de software que propõe 12 práticas, incluindo releases frequentes, planejamento colaborativo, testes automatizados, pair programming e propriedade coletiva do código. O objetivo é entregar valor ao cliente rapidamente, manter a simplicidade e lidar com requisitos mutáveis.

1. Extreme Programming Ricardo L. A. Bánffy Hiperlógica

2. Motivações Requerimentos mutáveis 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 Limitação da complexidade Custo de manutenção de um sistema aumenta com o tempo se a complexidade não for limitada Agilidade Releases frequentes garantem que problemas mais críticos são resolvidos mais cedo

3. Internet-time e vantagens de first-to-market

4. 12 práticas

5. 12 práticas Processo de Planejamento (“Planning Game”)

6. Releases Frequentes

7. Metáfora do Sistema

8. O Mais Simples que Possa Funcionar

9. Testar Antes

10. Refactoring Pair-Programming

11. Propriedade Coletiva do Código

12. Integração Contínua

13. Semanas de 40 Horas

14. Cliente Sempre Presente

15. Padrões de Codificação

16. Planning Game Equipe de negócios (Cliente) escreve estórias (curtas) sobre funcionalidades do sistema, usualmente em cartões

17. Equipe técnica (Programadores) estima o custo das estórias

18. Cliente decide qual a duração do próximo ciclo

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. Garante que o cliente tenha o maior retorno em cada ciclo de desenvolvimento

21. Releases Frequentes Minimizam a quantidade de recursos investida em cada release

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. 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

24. Metáfora do Sistema Comunica de forma clara o que se espera de um produto

25. Unifica a nomenclatura e estabelece uma linguagem cumum entre negócios e tecnologia

26. Ajuda os programadores a compreender o domínio do problema

27. O Mais Simples que Possa Funcionar Menor complexidade diminui riscos – A complexidade é o inimigo

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. Software é alterado durante sua vida útil – requerimentos mudam e o software pode se tornar mais complexo que os requerimentos necessitem

30. Garante que não serão gastos recursos em estórias que alguém “acha” que serão um dia necessárias

31. Testar Antes Testes devem ser escritos ANTES de se codificar a funcionalidade do produto

32. Testes funcionam como documentação (embora não a substituam)

33. Escrever os testes obriga a pensar na forma como o componente será usado ANTES de codificá-lo

34. Um componente só está pronto se todas as formas com que ele for usado passarem nos testes correspondentes

35. Unit-testing (apêndice) Testes devem ser automatizados para serem executados sempre que possível

36. Testes de difícil execução serão eventualmente abandonados

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. Framework de testes (xUnit)

39. Refactoring Código tende a se deteriorar ao longo do tempo

40. Soluções brilhantes de um dia parecem estúpidas depois de uma semana

41. Refactoring não deve acrescentar funcionalidade – apenas “limpar” a funcionalidade existente

42. É sempre recomendável fazer refactoring antes de acrescentar alguma funcionalidade

43. Pair-Programming Duas cabeças pensam melhor do que uma

44. Uma cabeça obriga a outra a pensar no problema

45. Se um colega não entende o código ele não está suficientemente claro e não será entendido depois

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. Funciona como um code-review em tempo real

48. Menos distrações (ICQ, Slashdot, e-mail)

49. Propriedade Coletiva do Código Se algo está quebrado, complexo demais ou poderia ser melhorado, isso seve ser corrigido

50. Todos os programadores devem ser capazes de consertar qualquer código do sistema – não pode haver especialistas numa única parte

51. Evita dependência de profissionais

52. Promove o entendimento global da solução (sem caixas-pretas de funcionalidade)

53. Integração Contínua A versão “oficial”, passando em todos os testes unitários e funcionais deve estar sempre disponível

54. Todo o novo desenvolvimento deve partir dessa versão

55. Todo código pronto (que passa em todos os testes) deve ser incorporado a essa versão assim que possível

56. Semanas de 40 horas Horas extras e viradas de noite produzem código de baixa qualidade

57. Programadores devem ter uma vida própria para se manterem felizes, saudáveis e produtivos

58. Horas extras são um sinal de alarme para a equipe

59. Cliente Sempre Presente Responde dúvidas melhor e mais rapidamente

60. Comunicação pessoal é mais eficiente do que por escrito

61. Programadores não devem tomar decisões para as quais não estão preparados (e pelas quais serão responsabilizados)

62. Padrões de Codificação Se todos os programadores devem editar qualquer parte do código, eles precisam ser capazes de entendê-lo

63. Código deve ser mantido legivel para a “posteridade”, limitando o aumento de custo de manutenção ao longo do tempo

64. Os padrões não precisam ser arbitrários ou impostos com uso de violência – é desejável que sejam consensuais

65. Dificuldades Cliente ausente Procure um substituto para representar o cliente: um gerente de conta ou gerente de produto (quando o cliente for algo como “mercado”) Mais de um cliente 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 Privacidade, ambiente hostil, ferramentas estranhas 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

66. Dificuldades Custos 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 Sistemas legados É 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)

67. Dificuldades Propriedade do código Programadores não podem ter “ciúmes” de suas criações

68. Encoraje o uso das mesmas linguagens e bibliotecas por toda a aplicação Dificuldades para testar Sempre testar componentes quanto à funcionalidade.

69. Separação entre conteúdo e apresentação ajuda

70. Componentes de interface podem ser testados separadamente

71. Alguns componentes dependem de funcionalidade externa – testing frameworks podem ter que ser desenvolvidos para a sua plataforma (ex: zUnit)

72. Componentes devem ser construídos de forma a facilitar os testes

73. Dificuldades Internet-Time Pressões nos induzem a reverter a práticas menos adequadas

74. Ciclos podem se tornar curtos demais para funcionar

75. Tendência a abandonar testes acreditando que sacrificar qualidade poupe tempo (pode poupar, mas afeta a qualidade e a vida útil do software)

76. Para saber mais www.extremeprogramming.org www.xprogramming.com www.hiper.com.br [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