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