EXtreme Programming em Cinco Minutos

A eXtreme Programmig (XP) proposta por Kent Beck [BECK, 2004] tem o objetivo de propor uma metodologia ágil para equipes de tamanho pequeno a médio, onde o desenvolvendo de software está inserido em um contexto de requerimentos vagos ou que mudam rapidamente.  O próprio autor descreve a Programação eXtrema como: “A XP é uma maneira leve, eficiente, de baixo risco, flexível, previsível, científica e divertida de desenvolver software”. [BECK, 2004].  Ainda segundo [BECK, 2004], a XP reconhece que os projetos precisam dedicar-se à obtenção da redução dos custos e tirar vantagem daquilo que foi economizado. Além disso, defende a não especialização dos membros do time, ou seja, todos participam de todas as atividades, em pares e com sistema de rodízio dos pares o desenvolvimento de infra-estrutura e frameworks durante o desenvolvimento da aplicação, e a comunicação face a face ou por meio de testes eficientes e código cuidadosamente escrito.

Segundo [BECK, 2004], a XP se distingue das outras metodologias por:

• Seu feedback antecipado;
• O planejamento incremental, que gera rapidamente um plano geral que evolui com o decorrer do projeto;
• Sua habilidade de implementar as funcionalidades de forma flexível considerando as necessidades mutáveis do negócio;
• Sua confiança nos testes automatizados;
• Sua confiança em comunicação oral;
• Sua confiança em um processo de projeto evolutivo que dura tanto quanto o sistema;

Risco: O Problema Básico

A principal motivação da Programação eXtrema parte do princípio que o desenvolvimento de software tem falhas na entrega e falhas nos produtos entregues caracterizando o problema básico – o risco, portanto, produz-se software de baixa qualidade. Segundo [BECK, 2004], existem vários riscos associados ao desenvolvimento do software, como: (i) cronograma irreal; (ii) cancelamento do projeto por vários atrasos no cronograma; (iii) o sistema é descontinuado pelo alto custo de se fazer modificações ou a taxa de erros cresce tanto que o sistema deve ser substituído; (iv) o negócio é mal compreendido e o software desenvolvido não resolve o problema original; (v) as regras de negócio mudam antes que o software seja finalizado; (vi) funcionalidades inúteis. A missão da XP é aceitar o risco como problema a ser resolvido, onde o objetivo é encontrar a solução. Nesse sentido, a necessidade é criar um modelo de desenvolvimento de software que trate desses riscos.

Além de mitigar ao máximo os riscos, a metodologia XP advoga que quatro variáveis têm de ser controladas no projeto – custo, tempo, qualidade e escopo. Dessa forma, o modelo desenvolvimento de software é dirigido sob a perspectiva de controlar as referidas variáveis. Em um projeto, as referidas variáveis são restrições inerentes ao produto final. Eventualmente se o custo e/ou o tempo forem escassos, é muito provável que a qualidade do produto entregue possa estar muito inferior àquela esperada no escopo do projeto.  A XP cria valores, princípios de atividades básicas e práticas para tentar conduzir bem os problemas correlacionados à efetivação dos riscos do projeto. Esses valores podem ser caracterizados em:

1. Comunicação: deve ser extremamente aberta e franca. A XP dá uma ênfase especial à comunicação e é essencial para tudo o que acontece no contexto de um projeto. Segundo [BECK, 2004], “Os problemas nos projetos podem ser invariavelmente rastreados a alguém não ter conversado com alguém mais sobre alguma coisa importante”.
2. Simplicidade: é representada na XP pela busca pela “coisa mais simples que possa funcionar” [BECK, 2004]. O propósito é construir algo simples e direto que solucione problemas de hoje e ter certeza de que isso seja suficientemente flexível para ser refinado e expandido de modo a solucionar os problemas de amanhã, mas fundamentalmente não se preocupa hoje com os problemas de amanhã.
3. Feedback: seu objetivo é criar ciclos de realimentação que atuam em intervalos de tempos pequenos como dias e minutos, em relação aos testes de unidade, e, grandes semanas (dias, semanas) em associação a teste de aceitação de usuário, e,  planejamento e cronograma de projeto.
4. Coragem: é o valor que permite aos participantes da XP se aventurarem em projetos de alto risco e alta recompensa nas tarefas de desenvolvimento. Isso muitas vezes se manifesta na forma de desenvolvedores que constroem protótipos descartáveis durante a codificação.

Princípios Fundamentais da XP

De acordo com [BECK, 2004] os princípios fundamentais da XP são:

1. Feedback rápido: o princípio é obter o feedback, interpretá-lo e aplicar o que é aprendido no sistema o mais rápido possível, realimentando o que foi aprendido em dias ou semanas, em vez de meses ou de anos.
2. Simplicidade presumida: este princípio dita que a equipe deve pressupor que todo problema tem uma solução razoavelmente simples. Como conseqüência, o tempo poupado na maioria dos problemas para os quais isso é válido pode ser usado para abordar problemas que realmente necessitem de soluções complexas.
3. Mudanças incrementais: parte do princípio que grandes modificações feitas de uma só vez têm grandes chances de não dar certo. Assim, qualquer problema é resolvido por meio de uma série de mudanças menores.
4. Aceitação das mudanças: este princípio se apóia na premissa da XP que de desenvolver software no contexto de requerimentos vagos ou que mudam rapidamente. As idéias é que os membros da equipe devem simplesmente aceitar as mudanças como algo natural, diário, em vez de algo que ocorre eventualmente.
5. Alta qualidade: ninguém gosta de fazer um trabalho de baixa qualidade. Todos gostam de fazer um bom trabalho. A XP defende que se você não vai fazer algo bem, então não faça independentemente das restrições de cronograma e orçamento.

Atividades Básicas do Desenvolvimento

[BECK, 2004] define quatro atividades básicas associadas ao desenvolvimento de software utilizando XP, sendo elas:

1. Codificar: as práticas da XP utilizam o código como um mecanismo para atingir objetivos secundários incluindo o aprendizado rápido e uma melhor comunicação. Algumas das práticas citadas no tópico a seguir estão ligadas à codificação: refatoração, programação em pares e integração continua.
2. Testar: está fortemente relacionada à codificação. Os desenvolvedores devem escrever códigos de teste de unidade antes escrever o código e verificar se o código passa por todos esses testes antes de se tornar um sistema. O cliente também é envolvido nos testes funcionais, onde os mesmos devem confirmar se o sistema satisfaz as regras de negócio.
3. Escutar: refere-se à necessidade de estruturar a comunicação de modo que as conversas, sempre que possível, envolvam os problemas de hoje, não os de amanha, em um nível de detalhe apropriado.
4. Projetar: está associado a necessidade de criar uma estrutura que organiza a lógica dentro do sistema de modo a torná-lo robusto e possível de manter. Nesse contexto, a prática utilizada é projetar simples.

Práticas do XP

[BECK, 2004] lista algumas práticas que devem ser seguidas pela equipe de desenvolvimento para que os valores, princípios e atividades básicas da metodologia sejam alcançados, são elas:

1. O jogo do planejamento: determinar o escopo da próxima versão de forma que os requisitos mais importantes sejam contemplados e a entrega possa ser um praza não muito longo. Quando o planejado fugir do realizado, então o plano deve ser reajustado.
2. Entregas freqüentes: dividir o desenvolvimento em pequenos módulos de acordo com as funcionalidades de forma que possa ser rapidamente colocado em produção.
3. Metáfora: conduzir o desenvolvimento por meio de histórias simples, compartilhada por todos os envolvidos, sobre como o sistema deverá funcionar.
4. Projeto Simples: o sistema deve ser pensado e projetado de maneira simplista. Complexidades desnecessárias são removidas assim que descobertas.
5. Testes: os programadores escrevem os testes de unidade durante todo o desenvolvimento, o qual deve ser executado sem falha para o desenvolvimento continue.
6. Refatoração: os programadores se preocupam sempre em deixar o código estruturado removendo códigos redundantes, simplificando e aumentando a flexibilidade.
7. Programação em pares: todo o desenvolvimento é realizado por programadores trabalhando em pares.
8. Propriedade coletiva: todos podem alterar o código em qualquer trecho e em qualquer momento.
9. Integração contínua: integre e atualize as versões do sistema várias vezes por dia, cada vez que uma tarefa fora terminada.
10. Semana de 40 horas: como regra, trabalhe no máximo quarenta horas por semana, evitando fazer hora extra por duas semanas consecutivas.
11. Cliente presente: mantenha o cliente o mais próximo possível para responder a questões.
12. Padrões de codificação: os programadores escrevem código respeitando as regras que enfatizam comunicação através do código.

Referência:  BECK, Kent (2004). Programação eXtrema explicada: escolha as mudanças, Bookman, 2004.