Extreme Programming – XP

Uma das metodologias de grande destaque na comunidade de desenvolvedores é a Extreme Programming – XP.

Segundo Beck (apud SOARES, 2007) a XP é uma metodologia ágil para ser aplicada em pequenas e médias equipes de desenvolvimento que trabalham em projetos com requisitos vagos e que modificam rapidamente.

Segundo Astels (2002), A XP contém princípios e práticas que orientam um projeto e sua equipe de desenvolvimento.

Esses princípios são empregados como um processo de desenvolvimento de software, abaixo serão citados os princípios um a um e logo após será abordado o funcionamento de forma geral do XP:

• Trabalhe com os seus clientes;

Segundo Astels (2002), Talvez o mais extremo dos princípios da XP seja a sua insistência em fazer um cliente real trabalhar diretamente no projeto. A necessidade de envolvimento do cliente no projeto é de suma importância no XP, uma vez que é o cliente que sabe quais são as reais necessidades dele e de seus colegas que utilizarão o sistema no dia a dia.

Ao cliente é dado o poder de tomar decisões com relação as prioridades, recursos e riscos envolvidos.

• Use as metáforas para descrever os conceitos difíceis;

Uma metáfora é uma forma poderosa de relacionar uma idéia difícil em uma área desconhecida. (ASTELS, 2002)

A metáfora é uma representação de um conceito ou recurso e não significa que ela é precisa em todos os sentidos, ela fornece um contexto geral para discutir os problemas e soluções a serem aplicadas.

• Planeje;

Na XP não se prioriza um planejamento longo, que leve em consideração todos os detalhes que possam ser encontrados no decorrer do projeto, ao invés disto ela orienta que o planejamento deve ser curto e continuo uma

vez que as variáveis constantes em um projeto são inúmeras e com certeza o planejamento sofrerá mudanças no decorrer do projeto.

• Mantenha as reuniões curtas;

As reuniões não são bem vindas pelos desenvolvedores, e a XP defende reuniões curtas e diárias com duração de aproximadamente 15 minutos, onde todos ficam de pé, e cada um fala sobre o que fez desde o ultimo encontro e o que pretende fazer até a próxima reunião.

Segundo Astels (2002), As reuniões são valiosas como um fórum de comunicação, mas apenas enquanto elas são breves e focalizadas.

• Teste primeiro;

Com esta prática a XP defende que o teste passa a fornecer uma definição ou documentação do comportamento desejado, além de ser possível saber quando se tem a funcionalidade total e corretamente implementada.

• Seja simples;

A XP defende a teoria de que o processo seja simples, onde não se deve preocupar com o que pode acontecer, esse pensamento faz sentido a partir do momento que a preocupação antecipada com tudo que pode acontecer mesmo antes de se concretizar, pode trazer a perda de um tempo precioso de desenvolvimento, deixando de lado algo que é essencialmente indispensável, e faz parte dos requisitos do projeto.

• Programe em pares;

Na XP utiliza-se a programação em pares, esta metodologia prega o princípios de que dois programadores trabalhando juntos são melhores do que trabalhando em separado.

Na XP enquanto um desenvolvedor pilota (codificando), o parceiro mantém em mente nos objetivos gerais do projeto.

• Codifique dentro dos padrões;

A XP defende a necessidade de se adotar algum padrão de código para o desenvolvimento, adotando esta prática o código permanece limpo e facilita a manutenção por parte de outros desenvolvedores.

• Faça a propriedade coletiva;

Tradicionalmente em um projeto de software a propriedade das classes normalmente são de responsabilidade de um membro especifico que controla a distribuição entre os demais desenvolvedores, ou através da utilização de algum aplicativo para controle de liberação e bloqueio de leitura das classes.

Segundo Astels (2002). A XP prescreve a propriedade da equipa para tudo. Se uma alteração for necessária, a pessoa que tiver melhores condições pode fazê-la.

• Integre continuamente;

Na XP o ideal é integrar seu código produzido ao código base do projeto a cada término de uma tarefa, ou pelo menos diariamente, este procedimento força a realização de testes a cada tarefa concluída, e mantém a qualidade do projeto como um todo.

• Faça o refactoring;

Refactoring é o processo de alterar um sistema de software de tal forma que ele não altere o comportamento externo do código e melhore a sua estrutura interna. Essa é uma forma disciplinada de limpar o código que minimiza as chances de introdução de bugs (ASTELS, 2002).

• Faça releases em incrementos pequenos;

A XP defende a idéia de disponibilizar releases freqüentes, com a utilização de releases pequenos, se coloca a nova funcionalidade nas mãos dos usuários o mais cedo possível.

Deve se observar que mesmo sendo pequeno um release deve estar completo, e fazer sentido, ou seja, agregar alguma nova funcionalidade ao projeto, o tempo de um release na XP é de aproximadamente 1 mês, sendo que 6 meses já é considerado um período longo.

• Não se desgaste;

A XP prima pela qualidade no ambiente de trabalho, e segundo seus princípios uma semana de trabalho não deve ter mais de 40 horas.

• Adote as alterações;

Segundo Astels (2002), a alteração dos requisitos é uma necessidade no ambiente de negócios em rápida evolução no qual todos trabalhamos.

Atualmente não só na área de desenvolvimento de software como em muitas outras áreas profissionais, só existe uma regra, e essa regra diz que em algum momento haverá uma mudança.

Não se tem certeza do que pode ocorrer no transcorrer de um projeto de desenvolvimento de software, mas inevitavelmente uma mudança se fará necessária no meio do percurso, e a XP encara a mudança como uma constante no processo de desenvolvimento de software.

A XP é um conjunto de regras e práticas inclusas em quatro atividades principais: planejamento, projeto, codificação e teste (PRESSMAN, 2006).

Na atividade de planejamento, criam-se as user stories que são pequenas descrições de partes do negócio e que são escritas pelo próprio cliente. Estas user stories são analisadas pela equipe de desenvolvimento e a elas são atribuídas um custo (tempo de desenvolvimento). De posse de todas as user stories, estas são classificadas de acordo com o custo e complexidade, e é decidido quais serão entregues na primeira iteração do projeto. As user stories mais complexas são executadas primeiro.

Durante o andamento do projeto, o cliente pode fazer alterações na user

stories, bem como criar e eliminar outras, fazendo com que a equipe de desenvolvimento

tenha que considerar as mudanças e re-planejar as próximas versões.

Na atividade de projeto, objetiva-se manter a simplicidade, mantendo o foco nas características originais das user stories, desencorajando o projeto de funcionalidades que os desenvolvedores acham que serão necessárias posteriormente.

A XP orienta o uso de cartões CRC (Classe-Responsabilidade-Colaborador), que identificam e organizam as classes. Se considerarmos orientação a objetos este é o principal resultado da fase de projeto quando a metodologia utilizada é a XP.

A atividade de codificação é a fase em que é feita a implementação do código. A

XP recomenda que antes da escrita do código, sejam desenvolvidos testes unitários que

vão executar cada user storie aprovando assim o código tão logo ele foi produzido.

Uma das características mais polêmicas da XP é a programação em pares, que orienta que dois programadores sentem diante de um computador, um fazendo a codificação direta e o outro orientando e revisando o código em tempo real, garantindo a qualidade do código e auxiliando para que ambos mantenham o foco no desenvolvimento. Na seqüência, a estratégia da integração contínua reúne o código desenvolvido pelos vários pares de programadores, re-compilando com certa freqüência o código do projeto, com o objetivo de identificar rapidamente problemas de compatibilidade (PRESSMAN, 2006).

Na atividade de teste, podemos automatizar a execução de todos os testes unitários, ou um sub-conjunto de testes focados na parte do projeto que foi alterada. Também são realizados os testes de aceitação que envolvem o cliente na validação das características e funcionalidades do sistema.

A XP também orienta que os envolvidos em um projeto XP organizem-se, atribuindo papéis, tanto na equipe do cliente como na equipe de desenvolvedores. Entre os desenvolvedores, podemos citar papeis como o técnico, acompanhador, facilitador, e o arquiteto (ASTELS, 2002).