Extreme Programming

Extreme Programming

Ricardo L. A. BnffyHiperlgica

Motivaes

Requerimentos mutveis

No mais possvel projetar um sistema ao longo de 6 meses, implement-lo ao longo de um ano, coloc-lo em produo e esperar que ele ainda resolva algum problema real

Limitao da complexidade

Custo de manuteno de um sistema aumenta com o tempo se a complexidade no for limitada

Agilidade

Releases frequentes garantem que problemas mais crticos so resolvidos mais cedo

Internet-time e vantagens de first-to-market

12 prticas

12 prticas

Processo de Planejamento (Planning Game)

Releases Frequentes

Metfora do Sistema

O Mais Simples que Possa Funcionar

Testar Antes

Refactoring

Pair-Programming

Propriedade Coletiva do Cdigo

Integrao Contnua

Semanas de 40 Horas

Cliente Sempre Presente

Padres de Codificao

Planning Game

Equipe de negcios (Cliente) escreve estrias (curtas) sobre funcionalidades do sistema, usualmente em cartes

Equipe tcnica (Programadores) estima o custo das estrias

Cliente decide qual a durao do prximo ciclo

Cliente escolhe, com base nas estimativas dos programadores, quais estrias sero atendidas nesse ciclo e quais ficaro nos prximos ciclos

Garante que o cliente tenha o maior retorno em cada ciclo de desenvolvimento

Releases Frequentes

Minimizam a quantidade de recursos investida em cada release

Ciclos curtos, na ordem de dias ou semanas, permitem retorno rpido sobre o investimento funcionalidades importantes entraro em funcionamento mais cedo

Todo o cdigo pronto (que passa em todos os testes unitrios) deve ser integrado e o sistema todo testado aps a integrao

Metfora do Sistema

Comunica de forma clara o que se espera de um produto

Unifica a nomenclatura e estabelece uma linguagem cumum entre negcios e tecnologia

Ajuda os programadores a compreender o domnio do problema

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 interaes entre componentes distintos aumentam o risco de quebras em alteraes)

Software alterado durante sua vida til requerimentos mudam e o software pode se tornar mais complexo que os requerimentos necessitem

Garante que no sero gastos recursos em estrias que algum acha que sero um dia necessrias

Testar Antes

Testes devem ser escritos ANTES de se codificar a funcionalidade do produto

Testes funcionam como documentao (embora no 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

Unit-testing (apndice)

Testes devem ser automatizados para serem executados sempre que possvel

Testes de difcil execuo sero eventualmente abandonados

Tuda a funcionalidade que no estiver sendo testada ou deveria estar sendo testado ou no necessria e deveria ser removida

Framework de testes (xUnit)

Refactoring

Cdigo tende a se deteriorar ao longo do tempo

Solues brilhantes de um dia parecem estpidas depois de uma semana

Refactoring no deve acrescentar funcionalidade apenas limpar a funcionalidade existente

sempre recomendvel fazer refactoring antes de acrescentar alguma funcionalidade

Pair-Programming

Duas cabeas pensam melhor do que uma

Uma cabea obriga a outra a pensar no problema

Se um colega no entende o cdigo ele no est suficientemente claro e no ser entendido depois

Para promover o entendimento da soluo, desejvel que as duplas sejam formadas por programadores com nveis diferentes de experincia

Funciona como um code-review em tempo real

Menos distraes (ICQ, Slashdot, e-mail)

Propriedade Coletiva do Cdigo

Se algo est quebrado, complexo demais ou poderia ser melhorado, isso seve ser corrigido

Todos os programadores devem ser capazes de consertar qualquer cdigo do sistema no pode haver especialistas numa nica parte

Evita dependncia de profissionais

Promove o entendimento global da soluo (sem caixas-pretas de funcionalidade)

Integrao Contnua

A verso oficial, passando em todos os testes unitrios e funcionais deve estar sempre disponvel

Todo o novo desenvolvimento deve partir dessa verso

Todo cdigo pronto (que passa em todos os testes) deve ser incorporado a essa verso assim que possvel

Semanas de 40 horas

Horas extras e viradas de noite produzem cdigo de baixa qualidade

Programadores devem ter uma vida prpria para se manterem felizes, saudveis e produtivos

Horas extras so um sinal de alarme para a equipe

Cliente Sempre Presente

Responde dvidas melhor e mais rapidamente

Comunicao pessoal mais eficiente do que por escrito

Programadores no devem tomar decises para as quais no esto preparados (e pelas quais sero responsabilizados)

Padres de Codificao

Se todos os programadores devem editar qualquer parte do cdigo, eles precisam ser capazes de entend-lo

Cdigo deve ser mantido legivel para a posteridade, limitando o aumento de custo de manuteno ao longo do tempo

Os padres no precisam ser arbitrrios ou impostos com uso de violncia desejvel que sejam consensuais

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 vrios interesses do cliente. Os clientes devem poder se reunir entre si antes de se reunir com a equipe tcnica

Privacidade, ambiente hostil, ferramentas estranhas

Quando desenvolvedores resistem ao pair-programming, procure criar um espao para pair-programming mquinas dedicadas a isso com editores e OSs que os programadores prefiram

Dificuldades

Custos

Pair-programming caro primeira vista. Argumente que os programadores vo se dispersar menos e que o cdigo ser de melhor qualidade do que se estivessem trabalhando sozinhos

Sistemas legados

mais fcil comear o projeto em XP do que mud-lo para XP durante sua execuo. Procure fazer a transio em algum momento de descontinuidade (entrega de funcionalidade)

Dificuldades

Propriedade do cdigo

Programadores no podem ter cimes de suas criaes

Encoraje o uso das mesmas linguagens e bibliotecas por toda a aplicao

Dificuldades para testar

Sempre testar componentes quanto funcionalidade.

Separao entre contedo e apresentao 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 construdos de forma a facilitar os testes

Dificuldades

Internet-Time

Presses nos induzem a reverter a prticas menos adequadas

Ciclos podem se tornar curtos demais para funcionar

Tendncia a abandonar testes acreditando que sacrificar qualidade poupe tempo (pode poupar, mas afeta a qualidade e a vida til do software)

Para saber mais

www.extremeprogramming.orgwww.xprogramming.comwww.hiper.com.br

ricardo@hiper.com.brHiperlgica, sites automticosAv. Brig. Faria Lima, 628 cj. 61So Paulo SP 05426-000(55 11) 3816 7785www.hiper.com.br