Extreme Programming (XP) é uma metodologia de desenvolvimento de software, criada por Kent Beck em 1996. Esta metodologia ajuda a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais ágil e flexível. Estes objetivos são alcançados através do conjunto de valores, princípios e práticas, que diferem substancialmente da forma tradicional de se desenvolver software.
Para implementar XP não é preciso usar diagramas ou processos formais. É preciso fazer uma equipe se unir em torno de algumas práticas simples, obter feedback suficiente e ajustar as práticas para a sua situação particular.
Valores do XP
• Comunicação
• Simplicidade
• Feedback
• Coragem
Comunicação
• Várias práticas do XP promovem uma maior comunicação entre os membros da equipe
• A comunicação não é limitada por procedimentos formais.
– Usa-se o melhor meio possível, que pode ser
– Uma conversa ou reunião informal
– Um e-mail, um bate-papo, um telefonema
– O próprio código
• Preferência à comunicação mais ágil.
Simplicidade
• XP incentiva ao extremo práticas que reduzam a complexidade do sistema
• A solução adotada deve ser sempre a mais simples que alcance os objetivos esperados
– Use as tecnologias, algoritmos e técnicas mais simples que permitirão atender aos requisitos do usuário-final
– Design, processo e código podem ser simplificados a qualquer momento
Feedback
• Várias práticas de XP garantem um rápido feedback sobre várias etapas/partes do processo
– Feedback sobre qualidade do código (testes de unidade, programação em pares, posse coletiva)
– Feedback sobre estado do desenvolvimento (estórias do usuário-final, integração contínua, jogo do planejamento)
• Permite maior agilidade
– Erros detectados e corrigidos imediatamente
– Requisitos e prazos reavaliados mais cedo – Permite estimativas mais precisas
coragem
• Testes, integração contínua, programação em pares e outras práticas de XP aumentam a confiança do programador e ajudam-no a ter coragem para
– melhorar o código que está funcionando para torná-lo mais simples
– investir tempo no desenvolvimento de testes
– mexer no design em estágio avançado
– pedir ajuda aos que sabem mais
– abandonar processos formais e ter o projeto e a documentação em forma de código
Princípios XP
• Feedback Rápido
• Simplicidade
• Mudanças Incrementais
• Aceitar Mudanças
• Trabalho de Qualidade
Feedback Rápido
• O retorno entre os desenvolvedores é rápido
– Cliente sabe se o produto que está sendo desenvolvido atende às suas necessidades
• Modele um pouco, mostre ao cliente e então modele novamente.
– Garante que o seu modelo será preciso enquanto seu conhecimento do projeto aumenta
Simplicidade
• Deixe o seu modelo tão simples quanto possível e assuma que a solução mais simples é a melhor
• O design do sistema deve ser feito para a iteração corrente. Não deve ser feito design sobre uma possível necessidade futura.
Mudanças Incrementais
• O modelo não será perfeito na primeira tentativa, ele irá mudar de acordo com o desenvolvimento do projeto
• Os problemas devem ser solucionados com um conjunto de pequenas modificações
Aceitar Mudanças
• Mudanças ocorrerão no projeto de acordo com o crescimento do entendimento do mesmo
• Aceite as mudanças e tenha coragem para reconstruir
Trabalho de Qualidade
• A qualidade do trabalho nunca deve ser comprometida
• XP eleva a importância da codificação e do teste antes da programação – test-first programming
Atividades XP
• Listening - (escutar)
• Testing - (testar)
• Coding - (codificar)
• Designing – (projetar)
Escutar
• XP é baseado em comunicação
• Menor importância na documentação formal, maior necessidade de uma comunicação verbal de qualidade
• Além de dizer que os desenvolvedores devem escutar os clientes, XP tem práticas que dirigem e guiam para uma comunicação melhor
Testar
• Teste é um passo integrado no processo de desenvolvimento
• Desenvolvedores escrevem os teste antes de desenvolverem o código
Codificar
• Escrever código que é refinado através de práticas como: – Refactory - refatoração – Pair programming – programação em pares – Code review – revisão de código
Projetar
• O design não é estático nem designado a um cargo (pessoa), ele é dinâmico e de responsabilidade de toda equipe
• XP aceita a evolução natural do sistema, o que implica em mudanças constantes
Práticas XP
• Equipe
• Planejamento
• Testes de aceitação
• Versões pequenas
• Projeto simples
• Programação em pares
• Desenvolvimento orientado a testes (TDD)
• Refinamento do projeto
• Integração contínua
• Posse coletiva
• Padrões de codificação
• Metáfora
• Ritmo saudável
A equipe
• Todos em um projeto XP são parte de uma equipe.
• A equipe deve incluir um representante do cliente:
– estabelece os requisitos do projeto
– define as prioridades
– controla o rumo do projeto
• Outros papéis assumidos pelos integrantes da equipe:
– programadores
– testadores (que ajudam o cliente com testes de aceitação)
– analistas (que ajudam o cliente a definir requerimentos)
– gerente (garante os recursos necessários)
– coach (orienta a equipe, controla a aplicação de XP)
– tracker (coleta métricas)
Planejamento
• Dois passos chaves:
- Planejamento de um release
- Planejamento de uma iteração
Planejamento de um release
• Cliente propõe funcionalidades desejadas (estórias)
• Programadores avaliam a dificuldade de implementá-las
Planejamento de uma iteração
• Cliente define as funcionalidades prioritárias para a iteração;
• Programadores as quebram em tarefas e avaliam o seu custo (tempo de implementação)
Teste de aceitação
• Testes de aceitação são elaborados pelo cliente
– São testes automáticos
– Quando rodarem com sucesso, funcionalidade foi implementada
– Devem ser rodados novamente em cada iteração
– Oferecem feedback: pode-se saber, a qualquer momento, quanto do sistema já foi implementado e quanto falta.
Versões Pequenas
• Disponibiliza, a cada iteração, software 100% funcional
– Benefícios do desenvolvimento disponíveis imediatamente
– Menor risco (se o projeto não terminar, parte existe e funciona)
– Cliente pode medir com precisão quanto já foi feito
– Feedback do cliente permitirá que problemas sejam detectados cedo e facilita a comunicação entre o cliente e os desenvolvedores
• Lançamento pode ser destinado a:
– usuário-cliente (que pode testá-lo, avaliá-lo, oferecer feedback)
– usuário-final (sempre que possível)
Design simples
• Design está presente em todas as etapas no XP
– Projeto começa simples e se mantém simples através de testes e refinamento do design (refactory).
– Não é permitido que se implemente nenhuma função adicional que não será usada na atual iteração.
• Implementação ideal é aquela que:
– Roda todos os testes
– Expressa todas as idéias que você deseja expressar
– Não contém código duplicado
– Tem o mínimo de classes e métodos
Programação em duplas
• Todo o desenvolvimento em XP é feito em pares
– Um computador, um teclado, dois programadores
– Um piloto, um co-piloto
– Papéis são alternados freqüentemente
– Pares são trocados periodicamente
• Benefícios – Melhor qualidade do design, código e testes
– Revisão constante do código
– Nivelamento da equipe
– Maior comunicação
Desenvolvimento orientado a testes TDD
• "Test first, then code"
– Programadores XP escrevem testes primeiro, escrevem código e rodam testes para validar o código escrito – Cada unidade de código só tem valor se seu teste funcionar 100%
– Testes são a documentação executável do sistema
Refatoração
• Não existe uma etapa isolada de projeto em XP
– O código é o projeto!
• O projeto é melhorado continuamente através de refactory
– Mudança proposital de código que está funcionando
– Objetivos: melhorar o design, simplificar o código, remover código duplicado, aumentar a coesão, reduzir o acoplamento
– Realizado o tempo todo, durante o desenvolvimento
Integração contínua
• Projetos XP mantêm o sistema integrado o tempo todo
– Integração de todo o sistema pode ocorrer várias vezes ao dia (pelo menos uma vez ao dia)
– Todos os testes (unidade e integração) devem ser executados
• Benefícios
– Expõe o estado atual do desenvolvimento (viabiliza lançamentos pequenos e freqüentes)
– Estimula design simples, tarefas curtas, agilidade
– Oferece feedback sobre todo o sistema
– Permite encontrar problemas de design rapidamente
Posse coletiva
• Em um projeto XP qualquer dupla de programadores pode melhorar o sistema a qualquer momento.
• Todo o código em XP pertence a um único dono: a equipe
– Todo o código recebe a atenção de todos os participantes resultando em maior comunicação
– Maior qualidade (menos duplicação, maior coesão)
– Menos riscos e menos dependência de indivíduos
• Todos compartilham a responsabilidade pelas alterações
Padrões de codificação
• O código escrito em projetos XP segue um padrão de codificação, definido pela equipe – Padrão para nomes de métodos, classes, variáveis
– Organização do código (chaves, etc.)
• Código com estrutura familiar facilita e estimula
– Posse coletiva
– Comunicação mais eficiente
– Simplicidade
– Programação em pares
– Refinamento do design
Metáfora
• Pode ser uma analogia com algum outro sistema (computacional, natural, abstrato) que facilite a comunicação entre os membros da equipe e cliente
• Facilita a escolha dos nomes de métodos, classes, campos de dados, etc.
– Serve de base para estabelecimento de padrões de codificação
Ritmo saudável
• Projetos com cronogramas apertados que sugam todas as energias dos programadores não são projetos XP
– "Semanas de 80 horas" levam à baixa produtividade
– Produtividade baixa leva a código ruim, relaxamento da disciplina (testes, refactoring, simplicidade), dificulta a comunicação, aumenta a irritação e o stress da equipe
– Tempo "ganho" será perdido depois
• Eventuais horas extras são aceitáveis quando produtividade é maximizada ao longo prazo
Dificuldades para implementar e utilizar XP
• Vencer barreiras culturais
– Deixar alguém mexer no seu código
– Trabalhar em pares
• Ter coragem de admitir que não sabe
• Pedir ajuda
• Vencer hábitos antigos
– Manter as coisas simples (e não tentar prever o futuro escrevendo "design flexível")
– Jogar fora código desnecessário
– Escrever testes antes de codificar
– Refactory com freqüência (vencer o medo)
Bom pessoal, é isso. O conteúdo é um pouco extenso mas vale a pena.
Até a próxima metodologia o/.
0 comments:
Postar um comentário