05/21/2009

XP – eXtreme Programming

Enviado em Processos tagged ágil, Processo, XP às 19:16 por julianamessias

XP é um processo ágil de desenvolvimento de software destinado a times pequenos e médios. Kent Beck: “XP é uma maneira leve, eficiente, de baixo risco, flexível, previsível, científica e divertida de desenvolver software”.

Valores

• Comunicação: é muito importante a comunicação entre todos os envolvidos no projeto para um melhor entendimento do mesmo;
• Simplicidade: fazer sempre a coisa mais simples que pode funcionar (KISS – Keep It Simple);
• Feedback: as funcionalidades são entregues no menor prazo possível e com isso o cliente pode verificar se o que ele precisa foi realmente implementado;
• Coragem: ao invés de evitar mudanças de requisitos, os times XP as consideram inevitáveis e procuram se adaptar com segurança e com coragem, isto é, com confiança em seus mecanismos de proteção, como por exemplo, desenvolvimento orientado a testes, programação em par e integração contínua;
• Respeito: saber ouvir, respeitar e compreender o ponto de visto do outro é essencial para o sucesso de um projeto.

Práticas do XP

• Processo de planejamento (“Planning Game”): diálogo constante entre pessoas de negócio e técnicas. Pessoas de negócio são responsáveis por decidir escopo, prioridade, datas de lançamento e composição de releases. Já as pessoas técnicas são responsáveis por decidir estimativas, processo de desenvolvimento do produto, técnicas e cronograma detalhado. O XP define dois níveis de planejamento:
  • Planejamento de release: o cliente explica as estórias (user stories) e o time avalia sua dificuldade;
  • Planejamento de iteração: geralmente a duração de uma iteração varia entre uma a três semanas e cada release pode possuir várias iterações, que implementarão um conjunto de estórias. Caso não seja possível implementar todas as estórias em uma iteração, as que faltaram serão implementadas na próxima iteração;
• Releases curtos: cada release precisa conter os requisitos de negócio mais importantes para o cliente. O release deve fazer sentido como um todo (um requisito não pode ser implementado pela metade). A entrega das releases é importante no processo de aceitação por parte do cliente, que pode testar a parte do software que está comprando;
• Metáfora: é uma forma de auxiliar clientes e desenvolvedores a compreender melhor o objetivo do software a ser criado. Ao criar comparações e analogias com o domínio em questão o time passa criar um vocabulário comum, que passa a ser usado para modelar o sistema e definir sua arquitetura;
• Projeto (design) simples: é importante criar design simples capazes de acolher a mudanças nos requisitos. Somente a funcionalidade que foi solicitada deve ser implementada. Não confundir simples com fácil;
• Testes: podem ser de diversos tipos: de aceitação, funcionalidade, integração e TDD (test-driven development – testes de unidade automatizados são criados antes da codificação de uma funcionalidade);
• Refactoring: é uma prática criada por Martin Fowler que tem como objetivo melhorar o design e a arquitetura do código já existente. O XP prega o refactoring constante. Pode ser utilizado em códigos duplicados e métodos longos;
• On-Site Customer: o cliente deve sempre estar presente auxiliando o time;
• Programação em pares: todo o design e código é produzido sempre por duas pessoas agindo como um par. Os pares não são fixos, cada membro da equipe irá trabalhar com todos os membros pelo menos uma vez durante o projeto;
• Propriedade coletiva do código: todos os desenvolvedores do time podem modificar o código, ele é de propriedade do time. Dessa forma todo o time se familiariza com o código.
• Integração Contínua: é recomendado que no máximo até o final de cada dia todo código produzido seja integrado e testado.
• Semana de 40 horas: tempo extra é sintoma de problemas. O XP sugere que o tempo extra não deve passar de uma semana seguida. Se problemas graves são descobertos, a iteração ou release devem ser planejados novamente;
• Padrões de codificação: cada time deve possuir padrões de codificação que deverão adotados por todos.

Direitos do Cliente

• Definir planos para saber o que será realizado, quando e a que custo;
• Alcançar o máximo desempenho dos desenvolvedores;
• Possuir ambientes de testes para monitorar o andamento do desenvolvimento;
• Possibilidade de mudar de idéias, substituir funcionalidades;
• Ser informado sobre mudanças de cronograma em tempo de escolher como reduzir o escopo para restaurar a data original;
• Cancelar a qualquer tempo o projeto e obter o software funcionando refletindo o investimento realizado até o momento.

Direitos do Desenvolvedor

• Saber o que é necessário, com claras declarações de prioridade;
• Produzir trabalho de qualidade o tempo todo;
• Pedir e receber ajuda de seus pares, superiores e clientes;
• Fazer e atualizar suas próprias estimativas;
• Aceitar as suas responsabilidades, ao invés de tê-las impostas a você de cima para baixo.

Problemas de desenvolvimento X Práticas do XP

Link Permanente