Extreme Programming

Extreme Programming Walfredo Cirne Universidade Federal da Paraíba

Engenharia de Software • Desenvolvimento ad-hoc de software em geral produz resultados muito ruins • Especialmente em sistemas grandes • Desejo de criar uma engenharia para que se tenha controle sobre desenvolvimento de software • Engenharias tradicionais colocam grande ênfase em projetar antes de construir

Visão Tradicional da Evolução do Software custo momento em que funcionalidade é adicionada

Queremos Poder Alterar Software • No inicio do projeto, normalmente não se sabe precisamente o que se quer • Software evolui para atender ao business • Software nunca fica “pronto” • Obviamente isso só é possível porque software é uma entidade abstrata

Portanto… • Precisamos parar de tentar evitar mudanças • Mudanças são um aspecto intrínseco da vida do software • Precisamos de uma metodologia de desenvolvimento que nos permita alterar constantemente o código sem comprometer sua qualidade

O que queremos é… custo momento em que funcionalidade é adicionada

Extreme Programming (XP) • Viva a mudança!!! • Desenvolvimento de software é … • um aprendizado • como dirigir um carro • Desenvolvimento de software não é … • como construir uma ponte • aponte e atire

Valores de XP • Simplicidade • Comunicação • Feedback • Coragem

Simplicidade e Comunicação Simplicidade clarezaconfiança menos a comunicar mais completo Comunicação

Feedback • Feedback possibilita que o software evolva • “Pergunte ao software, não a um documento” • Feedback precisa ser: • Cedo (pra gente descobrir logo se está fazendo a coisa correta) • Concreto (feedback oriundo do código) • Constante (o ciclo de desenvolvimento tem que ser curto)

Coragem • Colocar o cliente a par do que tá acontecendo • Acreditar na capacidade de responder a mudanças • Aprender com os erros • Acreditar no feedback (não na “teoria”) • Jogar pra ganhar (não pra ter uma desculpa) • Fazer o que precisa ser feito • Jogar fora código ruim

Documento = Código • Codificação é a atividade central do projeto • Testes (que também são código) servem de especificação • Comunicação oral entre desenvolvedores, baseada no código (testes e funcionalidade) que descreve o sistema

O Mantra do Programador XP • Codifique, senão o software não sai • Teste, senão você não sabe se está funcionando • Refatore, senão o código vai ficar tão ruim que será impossível dar manutenção • Escute, para que saiba qual é o problema a resolver • Planeje, para que você sempre faça a coisa mais importante ainda a fazer

Aspectos Fundamentais de XP • Refatoramento • Testes automáticos • Design mais simples possível • Programação em pares • Propriedade coletiva do código • Cliente sempre disponível • Estórias do usuário • Planejamento do release

Refatoramento • Refatorar é melhorar o código sem alterar sua funcionalidade • Antes de fazer uma mudança, você refatora o código para que a mudança seja simples de fazer • Refatoração continua possibilita manter um design legal, mesmo com mudanças freqüentes

Testes Automáticos • Testes automáticos são parte do software • Se você tem somente a funcionalidade, seu software está incompleto • Testes permitem que você refatore sem medo de quebrar o código • Testes representam uma “redundância lógica” que você adiciona ao código • Escrevendo testes antes da funcionalidade, você clareia dúvidas sobre o que o software deve fazer

O Livro de Refatoração • “Refactoring: Improving the Design of Existing Code”, escrito por Martin Fowler, contém dezenas de “receitas de refatoração” • Se você ainda não sabe, este livro vai te ensinar Orientação a Objetos • Por exemplo, teu código tem switches em atributos de tipo?

Código Não-OO int JobSpec::requests(){if( js_type == jst_fixed ){ return 1;} else if( js_type == jst_downey ){ return js_options;} else if( js_type == jst_nas ){ fatal( “not implemented yet" );} else { fatal1( "unknown js_type: %s", js_type );}return 0; // this avoids a warning }

Código OO … class DowneyJobSpec: public JobSpec { … int requests(){ return js_options; }; … } …

O Design Mais Simples Possível • Designs flexíveis são uma defesa contra mudanças imprevistas no software • Porém, designs flexíveis também têm custos • Tempo para desenvolvimento e manutenção • O código fica mais complexo • Muita vezes a flexibilidade não é utilizada nunca • Como mudança é barata em XP, vamos manter o design mais simples possível, modificando-o quando for necessário suportar mais funcionalidade

O Design Mais Simples Possível • O melhor design é aquele que: • Roda todos os testes • Não contém duplicação de funcionalidade • Deixa claro as decisões de design importantes • Tem o menor número possível de classes e métodos • O melhor design não é aquele: • Mais flexível (com mais “hooks”) • Mais abstrato • Que resistirá ao tempo

Programando em Pares • Se revisão de código é legal, vamos fazê-la o tempo todo • Em XP, programação é feita em pares • Pares mudam com relativa rapidez (em dias) • Programação em pares favorece comunicação e aprendizado • Mas, você precisa estabelecer um padrão de codificação • Há casos de redução no tempo de desenvolvimento com programação em pares

Propriedade Coletiva do Código • Desenvolvimento com objetos leva a alterações por todo o código • Coordenar alterações toma tempo e gera resistências no “dono” do código • Em XP, não se coordena, simplesmente faz-se o que precisa ser feito • Mas integra-se freqüentemente • No máximo, uma vez por dia

Propriedade Coletiva do Código • Todos são responsável por todo o código • Qualquer um que vê uma oportunidade de adicionar valor ao código, devo fazê-lo • Mantendo em vista as prioridades do cliente • Mantendo o design mais simples possível • Testes protegem a funcionalidade • Padrão de codificação evita a “guerra dos parênteses”

Cliente Sempre Disponível • Um cliente (usuário da aplicação) deve trabalhar com o time para esclarecer dúvidas, resolver disputas e estabelecer pequenas prioridades • É muito caro colocar um cliente a disposição do desenvolvimento? Talvez então não valha a pena fazer o sistema

Estórias • Usuários escrevem estórias descrevendo a funcionalidade que querem • Desenvolvedores estimam o tempo necessário para implementar cada estória • Um release é um conjunto de estórias que são disponibilizados simultaneamente • As estórias mais importantes e/ou mais difíceis tem prioridade

Business decide: escopo prioridade composição do release data do release Programadores decidem: estimativas conseqüências processo planejamento intra-release (o mais arriscado primeiro) O Jogo do Planejamento

XP preconiza releases pequenos e freqüentes (a cada 2-3 meses) As quatro dimensões do desenvolvimento de software são Custo, Tempo, Qualidade e Escopo XP tenta manter escopo como variável livre Releases

Iterações • Releases são divididas em iterações de 2-3 semanas • Uma iteração alcança algum objetivo (tipicamente a adição de nova funcionalidade) • Nada é feito que não seja imediatamente útil e necessário para não impactar os prazos de desenvolvimento

Tarefas • Iterações são divididas em tarefas • Tarefas são a menor quantidade de trabalho que pode ser feita até que todos os testes voltem a funcionar • Tarefas não levam mais que um dia • Uma vez concluídas, tarefas são integradas imediatamente

Outros Aspectos de XP • Jogue pra ganhar • Adapte para a situação em mão • “Travel light” • Estimativas baseadas na experiência • Métricas customizadas

Outros Aspectos de XP • Faça o mais arriscado primeiro • Crie testes para cada bug encontrado • Trabalhe a favor dos instintos dos programadores, não contra eles • Responsabilidade é aceita, nunca imposta • Hora extra rotineira não funciona

Dificuldades em XP • Sempre fazer a coisa mais simples • Admitir que você não sabe • Colaborar • Vencer resistência nas pessoas

Problemas de XP • Times grandes • Situações em que você não pode mudar livremente o código • Escrever testes para sistemas não-deterministicos, distribuídos ou paralelos

Concluindo, use XP se você... • tem que lidar com mudanças freqüentes • se depara com requerimentos vagos • valoriza resultado mais que cerimônia • valoriza trabalho em equipe mais que “poder”

Como fica Engenharia de Software? • Dificuldades no Desenvolvimento de SW • Complexidade + detalhes • Especificações vagas • Mutabilidade • Soluções • Ênfase no projeto, métodos formais • Modularizar • Revisão • Testes

Referências Futuras • Extreme Programming Explained por Beck • Extreme Programming Installed por Jeffries, Anderson e Hendrickson • Planning Extreme Programming por Beck e Fowler • Refactoring: Improving the Design of Existing Code por Fowler • Design Patterns pela “Gangue dos Quatro”

Referências Futuras • http://www.extremeprogramming.org • http://www.xprogramming.com • http://www.martinfowler.com/articles/newMethology.html • http://www.objectmentor.com/ publications/RUPvsXP.pdf • http://www.pairprogramming.com • http://www.junit.org

Referências Futuras • http://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm

Extreme Programming