eXtreme Programming em Cinco Minutos
Autor: Andréa Negreiros | Publicado: 2011-11-18T10:00:00-03:00




A&nbsp;eXtreme Programmig&nbsp;(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&nbsp;software&nbsp;está inserido em um contexto de requerimentos vagos ou que mudam rapidamente.&nbsp; O próprio autor descreve a Programação eXtrema como:&nbsp;“A XP é uma maneira leve, eficiente, de baixo risco, flexível, previsível, científica e divertida de desenvolversoftware”.&nbsp;[BECK, 2004].&nbsp; 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&nbsp;frameworks&nbsp;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&nbsp;feedback&nbsp;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&nbsp;A principal motivação da Programação eXtrema parte do princípio que o desenvolvimento de&nbsp;software&nbsp;tem falhas na entrega e falhas nos produtos entregues caracterizando o problema básico – o risco, portanto, produz-sesoftware&nbsp;de baixa qualidade. Segundo [BECK, 2004], existem vários riscos associados ao desenvolvimento do&nbsp;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&nbsp;software&nbsp;desenvolvido não resolve o problema original; (v) as regras de negócio mudam antes que o&nbsp;software&nbsp;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&nbsp;software&nbsp;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&nbsp;software&nbsp;é 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. &nbsp;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:

Comunicação:&nbsp;deve ser extremamente aberta e franca. A XP dá uma ênfase especial à comunicação e é essencial para tudo o que acontece no contexto&nbsp;de um projeto. Segundo [BECK, 2004],&nbsp;“Os problemas nos projetos podem ser invariavelmente rastreados a alguém não ter conversado com alguém mais sobre alguma coisa importante”.
Simplicidade:&nbsp;é representada na XP pela busca pela “coisa mais simples que possa funcionar”&nbsp;[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ã.
Feedback:&nbsp;seu objetivo é criar ciclos&nbsp;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, &nbsp;planejamento e cronograma de projeto.
Coragem:&nbsp;é 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&nbsp;De acordo com [BECK, 2004] os princípios fundamentais da XP são:

Feedback&nbsp;rápido:&nbsp;o princípio é obter o&nbsp;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.
Simplicidade presumida:&nbsp;este&nbsp;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.
Mudanças incrementais:&nbsp;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.
Aceitação das mudanças:&nbsp;este princípio se apóia na premissa da XP que de desenvolver&nbsp;software&nbsp;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.
Alta qualidade:&nbsp;ninguém&nbsp;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&nbsp;[BECK, 2004] define quatro atividades básicas associadas ao desenvolvimento de&nbsp;software&nbsp;utilizando XP, sendo elas:

Codificar:&nbsp;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.
Testar:&nbsp;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.
Escutar:&nbsp;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.
Projetar:&nbsp;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&nbsp;[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:

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.
Entregas freqüentes:&nbsp;dividir o desenvolvimento em pequenos módulos de acordo com as funcionalidades de forma que possa ser rapidamente colocado em produção.
Metáfora:&nbsp;conduzir o desenvolvimento por meio de histórias simples, compartilhada por todos os envolvidos, sobre como o sistema deverá funcionar.
Projeto Simples:&nbsp;o sistema deve ser pensado e projetado de maneira simplista. Complexidades desnecessárias são removidas assim que descobertas.
Testes:&nbsp;os programadores escrevem os testes de unidade durante todo o desenvolvimento, o qual deve ser executado sem falha para o desenvolvimento continue.
Refatoração:&nbsp;os programadores se preocupam sempre em deixar o código estruturado removendo códigos redundantes, simplificando e aumentando a flexibilidade.
Programação em pares:&nbsp;todo o desenvolvimento é realizado por programadores trabalhando em pares.
Propriedade coletiva:&nbsp;todos podem alterar o código em qualquer trecho e em qualquer momento.
Integração contínua:&nbsp;integre e atualize as versões do sistema várias vezes por dia, cada vez que uma tarefa fora terminada.
Semana de 40 horas:&nbsp;como regra, trabalhe no máximo quarenta horas por semana, evitando fazer hora extra por duas semanas consecutivas.
Cliente presente:&nbsp;mantenha o cliente o mais próximo possível para responder a questões.
Padrões de codificação:&nbsp;os programadores escrevem código respeitando as regras que enfatizam comunicação através do código.


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