Modelos de processo de software: eXtreme Programming Arthur Bispo de Castro ra992659 Luciano Antonio Digiampietri ra992075

Tópicos abordados: Porque surgiu o XP Princípios, regras e diretrizes para o desenvolvimento Ciclo das atividades Qualidade Estratégias de testes Diretrizes para o gerenciamento do projeto Conclusão

Porque surgiu o XP? Atrasos na programação; Cancelamento de projeto; Sistema demora muito para fazer algo; Taxa de falhas é muito grande; Software não atende aos requisitos; Mudanças de requisitos; Mudança na equipe de funcionários.

Princípios, regras e diretrizes para o desenvolvimento (I) O Jogo do planejamento Pequenas liberações Metáfora Projeto simplificado Teste Re-fatoração

Princípios, regras e diretrizes para o desenvolvimento (II) Programação em pares Posse coletiva Integração contínua 40 horas por semana Cliente no local (feedback rápido) Padronização do código

Ciclo das atividades (I) Fase de Exploração duração: 2 a 6 meses. clientes escrevem “historias” (story cards). programadores interagem com clientes e discutem o problem, soluções e tecnologias. Planejamento: 1 a 2 dias.

Ciclo das atividades (II) Escolha de uma história do cliente; Pair programming para aquela história; Discução da história do cliente; Elaboração de testes; Implementação; Execução dos testes;

Ciclo das atividades (III) Busca de oportunidades para simplificação; Modificações do projeto e implementação baseadas na funcionalidade exigida no momento; Elaboração e execução de novos testes; Correção do código até que todos os testes passem; Integração do novo código ao repositório e liberação ao cliente.

Qualidade (I) Um processo de desenvolvimento é essencial No modelo tradicional: Tempo, escopo e custo Manipula-se a Qualidade No modelo XP Tempo, custo e qualidade Manipula-se o Escopo Comunicação, simplicidade, feedback e coragem

Qualidade (II) Força o (mau) programador a se comportar de forma similar ao bom programador Simplicidade é o melhor negócio Cartões de CRC (Classe, Responsabilidade e Colaboração) Refatoração para melhorar a manutenibilidade

Estratégias de testes (I) Determina as funcionalidades Falsos negativos Automático Criado por Programadores e Clientes Outros testes Paralelos Stress Monkey

Estratégias de testes (II) Testes de unidade Escrito pelo desenvolvedor, antes do código Código deve passar no teste antes da integração Testes de aceitação Escrito pelo cliente, pelas suas necessidades Executado com freqüência

Diretrizes para o gerenciamento do projeto (I) Responsabilidade Qualidade Mudança incremental Adaptação Travel light Honestidade Metrica Intervenção

Diretrizes para o gerenciamento do projeto (II) Planejamento História do cliente e cronograma Design Simplicidade, cartões CRC e refatoração Teste Unidade e aceitação Codificação Duplas, cliente disponível e sem sobrecarga.

Conclusão XP não é para todo mundo Mas todo mundo pode aprender com ela

Bibliografia Beck, Kent. Extreme programming explained: embrace change. 2000. Addison-Wesley. http://www.xispe.com.br http://www.xp2003.org http://www.extremeprogramming.org Santos, Jefferson. Extraindo o Melhor de XP, Agile Modeling e RUP para melhor produzir software. PUC-Rio. Bonato, Antonio. Extreme Programming e Software de Qualidade. 2002. Politécnica-USP. Kon, Fabio. Goldman, Alfredo. Programação eXtrema - Desenvolvendo Software com Qualidade e Agilidade. 2002. IME-USP.