Xp Comdex

863 views

Published on

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
863
On SlideShare
0
From Embeds
0
Number of Embeds
35
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Xp Comdex

  1. 1. Extreme Programming Ricardo L. A. Bánffy Hiperlógica
  2. 2. Motivações <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 </li></ul></ul></ul><ul><ul><ul><li>Internet-time e vantagens de first-to-market </li></ul></ul></ul>
  3. 3. 12 práticas
  4. 4. 12 práticas <ul><li>Processo de Planejamento (“Planning Game”) </li></ul><ul><li>Releases Frequentes </li></ul><ul><li>Metáfora do Sistema </li></ul><ul><li>O Mais Simples que Possa Funcionar </li></ul><ul><li>Testar Antes </li></ul><ul><li>Refactoring </li></ul><ul><li>Pair-Programming </li></ul><ul><li>Propriedade Coletiva do Código </li></ul><ul><li>Integração Contínua </li></ul><ul><li>Semanas de 40 Horas </li></ul><ul><li>Cliente Sempre Presente </li></ul><ul><li>Padrões de Codificação </li></ul>
  5. 5. Planning Game <ul><li>Equipe de negócios (Cliente) escreve estórias (curtas) sobre funcionalidades do sistema, usualmente em cartões </li></ul><ul><li>Equipe técnica (Programadores) estima o custo das estórias </li></ul><ul><li>Cliente decide qual a duração do próximo ciclo </li></ul><ul><li>Cliente escolhe, com base nas estimativas dos programadores, quais estórias serão atendidas nesse ciclo e quais ficarão nos próximos ciclos </li></ul><ul><li>Garante que o cliente tenha o maior retorno em cada ciclo de desenvolvimento </li></ul>
  6. 6. Releases Frequentes <ul><li>Minimizam a quantidade de recursos investida em cada release </li></ul><ul><li>Ciclos curtos, na ordem de dias ou semanas, permitem retorno rápido sobre o investimento – funcionalidades importantes entrarão em funcionamento mais cedo </li></ul><ul><li>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>
  7. 7. Metáfora do Sistema <ul><li>Comunica de forma clara o que se espera de um produto </li></ul><ul><li>Unifica a nomenclatura e estabelece uma linguagem cumum entre negócios e tecnologia </li></ul><ul><li>Ajuda os programadores a compreender o domínio do problema </li></ul>
  8. 8. O Mais Simples que Possa Funcionar <ul><li>Menor complexidade diminui riscos – A complexidade é o inimigo </li></ul><ul><li>Software tende naturalmente a crescer e se tornar mais complexo (mais interações entre componentes distintos aumentam o risco de quebras em alterações) </li></ul><ul><li>Software é alterado durante sua vida útil – requerimentos mudam e o software pode se tornar mais complexo que os requerimentos necessitem </li></ul><ul><li>Garante que não serão gastos recursos em estórias que alguém “acha” que serão um dia necessárias </li></ul>
  9. 9. Testar Antes <ul><li>Testes devem ser escritos ANTES de se codificar a funcionalidade do produto </li></ul><ul><li>Testes funcionam como documentação (embora não a substituam) </li></ul><ul><li>Escrever os testes obriga a pensar na forma como o componente será usado ANTES de codificá-lo </li></ul><ul><li>Um componente só está pronto se todas as formas com que ele for usado passarem nos testes correspondentes </li></ul>
  10. 10. Unit-testing (apêndice) <ul><li>Testes devem ser automatizados para serem executados sempre que possível </li></ul><ul><li>Testes de difícil execução serão eventualmente abandonados </li></ul><ul><li>Tuda a funcionalidade que não estiver sendo testada ou deveria estar sendo testado ou não é necessária e deveria ser removida </li></ul><ul><li>Framework de testes (xUnit) </li></ul>
  11. 11. Refactoring <ul><li>Código tende a se deteriorar ao longo do tempo </li></ul><ul><li>Soluções brilhantes de um dia parecem estúpidas depois de uma semana </li></ul><ul><li>Refactoring não deve acrescentar funcionalidade – apenas “limpar” a funcionalidade existente </li></ul><ul><li>É sempre recomendável fazer refactoring antes de acrescentar alguma funcionalidade </li></ul>
  12. 12. Pair-Programming <ul><li>Duas cabeças pensam melhor do que uma </li></ul><ul><li>Uma cabeça obriga a outra a pensar no problema </li></ul><ul><li>Se um colega não entende o código ele não está suficientemente claro e não será entendido depois </li></ul><ul><li>Para promover o entendimento da solução, é desejável que as duplas sejam formadas por programadores com níveis diferentes de experiência </li></ul><ul><li>Funciona como um code-review em tempo real </li></ul><ul><li>Menos distrações (ICQ, Slashdot, e-mail) </li></ul>
  13. 13. Propriedade Coletiva do Código <ul><li>Se algo está quebrado, complexo demais ou poderia ser melhorado, isso seve ser corrigido </li></ul><ul><li>Todos os programadores devem ser capazes de consertar qualquer código do sistema – não pode haver especialistas numa única parte </li></ul><ul><li>Evita dependência de profissionais </li></ul><ul><li>Promove o entendimento global da solução (sem caixas-pretas de funcionalidade) </li></ul>
  14. 14. Integração Contínua <ul><li>A versão “oficial”, passando em todos os testes unitários e funcionais deve estar sempre disponível </li></ul><ul><li>Todo o novo desenvolvimento deve partir dessa versão </li></ul><ul><li>Todo código pronto (que passa em todos os testes) deve ser incorporado a essa versão assim que possível </li></ul>
  15. 15. Semanas de 40 horas <ul><li>Horas extras e viradas de noite produzem código de baixa qualidade </li></ul><ul><li>Programadores devem ter uma vida própria para se manterem felizes, saudáveis e produtivos </li></ul><ul><li>Horas extras são um sinal de alarme para a equipe </li></ul><ul><li>Quando o programador acha que um prazo foi superestimado, vai deixar tarefas para depois e vai ter que virar noites no fim do período, pois é ele nunca vai lembrar que é extremamente raro superestimar prazos </li></ul>
  16. 16. Cliente Sempre Presente <ul><li>Responde dúvidas melhor e mais rapidamente </li></ul><ul><li>Comunicação pessoal é mais eficiente do que por escrito </li></ul><ul><li>Programadores não devem tomar decisões para as quais não estão preparados (e pelas quais serão responsabilizados) </li></ul>
  17. 17. Padrões de Codificação <ul><li>Se todos os programadores devem editar qualquer parte do código, eles precisam ser capazes de entendê-lo </li></ul><ul><li>Código deve ser mantido legivel para a “posteridade”, limitando o aumento de custo de manutenção ao longo do tempo </li></ul><ul><li>Os padrões não precisam ser arbitrários ou impostos com uso de violência – é desejável que sejam consensuais </li></ul>
  18. 18. Dificuldades <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>
  19. 19. Dificuldades <ul><li>Custos do pair-programming </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><ul><ul><li>Às vezes pair-design é mais interessante. Algumas duplas planejam uma solução juntas e programam separadamente. Isso funciona às vezes </li></ul></ul></ul><ul><li>Algumas duplas não funcionam </li></ul><ul><ul><ul><li>Rearrange sempre as duplas. Algumas combinações vão funcionar melhor que outras. Fatores técnicos ou culturais podem influir </li></ul></ul></ul>
  20. 20. Dificuldades <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><ul><li>Propriedade do código </li></ul><ul><ul><ul><li>Programadores não podem ter “ciúmes” de suas criações </li></ul></ul></ul><ul><ul><ul><li>Encoraje o uso das mesmas linguagens e bibliotecas por toda a aplicação </li></ul></ul></ul>
  21. 21. Dificuldades <ul><li>Dificuldades para testar </li></ul><ul><ul><ul><li>Sempre testar componentes quanto à funcionalidade. </li></ul></ul></ul><ul><ul><ul><li>Separação entre conteúdo e apresentação ajuda </li></ul></ul></ul><ul><ul><ul><li>Componentes de interface podem ser testados separadamente </li></ul></ul></ul><ul><ul><ul><li>Alguns componentes dependem de funcionalidade externa – testing frameworks podem ter que ser desenvolvidos para a sua plataforma (ex: zUnit) </li></ul></ul></ul><ul><ul><ul><li>Componentes devem ser construídos de forma a facilitar os testes </li></ul></ul></ul>
  22. 22. Dificuldades <ul><li>Internet-Time </li></ul><ul><ul><ul><li>Pressões nos induzem a reverter a práticas menos adequadas (com as quais crescemos e que as gerências entendem melhor) </li></ul></ul></ul><ul><ul><ul><li>Ciclos podem se tornar curtos demais para funcionar </li></ul></ul></ul><ul><ul><ul><li>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>
  23. 23. Para saber mais <ul><li>www.extremeprogramming.org </li></ul><ul><li>www.xprogramming.com </li></ul><ul><li>www.xpdeveloper.com </li></ul><ul><li>www.hiper.com.br </li></ul>[email_address] Hiperlógica, sites automáticos Av. Brig. Faria Lima, 628 cj. 61 São Paulo • SP • 05426-000 (55 11) 3816 8067 www.hiper.com.br

×