Extreme Programming (XP)


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:
  1. Planejamento de um release 
  2. 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/.

Thallita Celeste

Olá! Sou Thallita, fundadora do blog ThallitaCeleste. Sou Analista de segurança, com fome de conhecimento e grande vontade de ajudar as pessoas ao redor. Aqui, tento manter meu histórico sobre diversos temas. Bem, seja Bem Vindo ao meu Blog! Espero que goste. o/

Nenhum comentário:

Postar um comentário