Extreme Programming (XP) é uma metodologia de engenharia de software e uma forma de desenvolvimento ágil. Esta metodologia oferece um conjunto de práticas que devem ser tomadas por um grupo de stakeholders e que encoraja determinados valores. Os autores afirmam que exercitando as práticas sugeridas, que nada mais são do que práticas bem estabelecidas na indústria de desenvolvimento como “boas” a níveis extremos, é possível atender de melhor forma as necessidades do patrocinador e dos usuários e criar software de melhor qualidade em relação a métodos tradicionais.

 

Além disso, os proponentes da metodologia também enxergam mudanças como uma parte natural do processo de desenvolvimento. Eles aceitam e incorporam mudanças a metodologia. Ter a capacidade de se adaptar a novas circunstâncias é mais importante do que tentar prever o futuro (como no ciclo de vida em cascata) antes do início do trabalho.

 

A XP foi criada por Kent Back durante seu trabalho na Crhysler em um projeto de desenvolvimento de um sistema de folha de pagamentos. Ele se tornou o líder do projeto em 1996 e neste período buscou formas de aprimorar a maneira como o software era desenvolvido. Inclusive, esta foi sua primeira tarefa antes de vir a se tornar líder do projeto.

 

The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I thought, "Damn the torpedoes, at least this will make a good article," [and] asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else. —Kent Beck

 

Em 1999, Kent Beck lançou o livro Extreme Programming Explained, onde descreveu as práticas e uma série de outros elementos de sua metodologia.

 

Descrito como uma tentativa de reconciliar a “humanidade com a produtividade” e como “mecânismo de mudança social”, o XP tem como principal objetivo a redução do custo da mudança. Num sistema tradicional de desenvolvimento, os requisitos do software devem ser determinados no começo do trabalho. Isso significa que o custo de mudar um requisito ao longo do trabalho é caro.

 

A metodologia propõe valores básicos, princípios e práticas para reduzir o custo da mudança. Abaixo, serão apresentados os principais conceitos do Extreme Programming.

 

Ativididades XP

 

A metodologia cita quatro atividades que devem ser inseridas no processo de software:

 

Código

 

Os proponentes do XP afirmam que o código é o que realmente importa no processo de desenvolvimento de software. Na metodologia, o “código” é visto com mais profundidade do que em métodos tradicionais. Codificar pode significar estar trabalhando em datagramas, banco de dados, desenhar algorítimos em papel ou codificando um programa que precisa ser compilado.

 

Um programador também pode transformar suas idéias e conceitos em código, utilizando o mesmo para comunicar-se com o restante da equipe. Seus colegas, por sua vez, podem trabalhar com este código e responder utilizando a mesma linguagem ou lógica.

 

Testes

 

Ninguém pode ter certeza de que alguma coisa funciona até que a tenha testado. O teste, entretanto, não é uma necessidade sentida em primeira instância pelo cliente. Muitos softwares são vendidos e entregues sem os devidos testes, e ainda assim funcionam. O XP afirma que todas as funções devem ser testadas. Para tanto, é preciso saber porque testar.

 

Você pode não ter certeza que determinado código é aquilo que você espera que seja. Para tirar esta dúvida, o XP utiliza Unit Tests, testes em sequência feitos de maneira a tentar quebrar o código, achar erros. Se todos os testes forem bem sucedidos, então o código está completo.

Você pode não estar certo se o que você fez era o que deveria ser feito. Para testar esta questão, o XP propõe Acceptance Tests,  que são testes feitos com base nos requisitos dados pelo cliente no início da iteração.

O “Testathon” é um evento onde os programadores se encontram para trabalhar de forma colaborativa em testes.

 

Escutando o Cliente

 

Muitas vezes os programadores não tem a menor idéia do negócio que está por trás da necessidade de desenvolvimento de determinado software. As funções do sistema são determinadas pelo cliente. Para programadores entendderem como devem ser as funções do sistema, eles precisam escutar/entender quais são as necessidades do cliente. Eles precisam tentar entender o negócio e passar suas dificuldades para o cliente, para que ele possa entender ainda melhor suas próprias necessidades.

 

Designing 

 

Do ponto de vista da simplicidade, alguém poderia afirmar que um sistema de desenvolvimento não precisa mais do que codificação, testes e comunicação. Se estas atividades forem bem sucedias, o resultado sempre será um sistema que funciona. Na prática, isso não funciona. Em determinado momento o código se tornará tão complexo que o desenvolvimento irá ficar paralizado. Para solucionar este problema, é preciso criar uma lógica (design) que faça com que não hajam muitas dependências. Fazendo isso, modificações nunca irão alterar profundamente o todo. O design deve fazer parte do processo inteiro.

 

Valores do XP

 

Inicialmente, existiam 4 valores. Novos valores foram adicionados com o livro Extreme Programming Explained.

 

Comunicação

 

No desenvolvimento formal de software a comunicação é realizada, muitas vezes, através da documentação. Técnicas de XP podem ser vistas como maneiras rápidas de se construir e disseminar conhecimento institucional para membros de uma equipe de desenvolvimento. O objetivo é oferecer a todos os desenvolvedores uma visão do sistema que se equipare com a compreensão do cliente sobre o mesmo. Para tanto, a Extreme Programming favorece um design simples, metáforas comuns, colaboração de usuários e programadores e comunicação entre stakeholders (formal e através de feedbacks).

 

Simplicidade

 

XP encoraja começar com a solução mais simples. Funcionalidades adicionais podem ser inseridas durante o processo. A diferença entre esta abordagem e o desenvolvimento tradicional é o foco no design e no trabalho de programação direcionados para as necessidades de hoje, nmão para requisitos de amanhã (do futuro). É reconhecido por parte dos proponentes que isto pode gerar dificuldades em mudanças futuras, mas esta deficiência é compensada pela vantagem em não investir em trabalho que pode simplesmente ser descartado no decorrer do processo.

 

Em termos de comunicação, simplicidade favorece uma compreensão maior por parte de todos e a qualquer momento. Seja um código escrito de maneira objetiva e coerente como um design simples e eficiente.

 

Feedback 

 

O feedback está presente em várias dimensões do desenvolvimento:

Feedback do sistema: escrevendo unit tests ou executando testes de interação periódigos os programadores podem ter feedback direto do estado do sistema depois te ter implementado alterações.

 

Feedback do cliente: testes funcionais, como acceptance tests, são feitos/definidos pelo cliente e seus testadores. Eles irão ter um feedback real e concreto sob o estado real de seu sistema. Este tipo de revisão é planejada a cada duas ou três semanas.

 

Feedback por parte da equipe: quando clientes trazem novos requisitos no projeto o time deve oferecer resposta imediata das estimativas de tempo para implementar tal requisito.

 

Coragem

 

Várias práticas incluem a coragem. Um dos mandamentos da coragem é desenvolver código para hoje, não para amanhã. Este é um esforço para evitar ficar prezo em um design que requer muito esforço para que seja implementada qualquer coisa que fuja de seu escopo. Coragem permite que desenvolvedores sintam-se a vontade quando reescrevendo seu próprio trabalho. Isso significa que revisar um sistema, modificar código ou simplesmente jogá-lo fora fazem parte do dia-a-dia. É preciso coragem para remover um código obsoleto, não importa quanto tempo tenha sido gasto para criar aquele trabalho. É preciso ter coragem para ter persistência, trabalhar um dia inteiro tentando resolver um problema para, no dia seguinte, resolvê-lo em um piscar de olhos.

 

Respeito

No XP, membros de uma equipe respeitam uns aos outros porque programadores numca devem executar alterações que venham a interferir no trabalho de outros sem comunicação/entendimento prévio. Membros de uma equipe respeitam seu trabalho por trabalhar intensamente para obter o melhor resultado e as melhores soluções.

 

Adotar os quatro valores anteriores leva ao respeito. Ninguém em uma equipe deve se sentir depreciado ou ignorado. Isso garante alto nível de satisfação e encoraja lealdade para com o time.

 

Regras do XP

 

Regras de Comprometimento

 

Estas regras são aquelas que fazem o desenvolvimento ser ágil e são, inclusive, parecidas ao princípios do desenvolvimento ágil:

 

- Trabalho conjunto entre desenvolvedores e representantes do negócio: ambos devem trabalhar juntos, dia-a-dia, durante o trabalho do projeto.

 

- A satisfação do cliente é prioridade: o cliente deve ajustar e alterar os objetivos baseado em informações fornecidas pelos desenvolvedores e em estimativas próprias.

 

- Entregar partes que funcionem: entregar partes de software frequentemente que sejam  utilizáveis. As entregas podem acontecer com intervalos entre semanas e até dois meses.

 

- Software: é a principal medida de progresso.

 

- Adaptabilidade: a qualquer momento do trabalho, um membro da equipe deve ser capaz de medir o progresso do desenvolvimento em relação aos objetivos do cliente. Além disso, deve ser capaz de adaptar seu comportamento em função do trabalho.

 

- A equipe deve agir eficientemente como uma rede social, o que significa:

 

- Comunicação honesta com ênfase no tete-a-tete e no aprendizado contínuo.

 

- Distância mínima entre o que precisa ser feito e as ferramentas necessárias para sua execução.

 

- Alinhamento entre responsabilidade e autoridade.          

 

Regras do Jogo

 

Estas são regras que fazem do Extreme Programming único e são baseadas nos valores da metodologi: comunicação, simplicidade, feedback e coragem.

 

- Testes contínuos: o trabalho produzido deve ser continuamente validado.

 

- Qualidade do código: todo código escrito deve ser feito para uso potencial em um produto (software) e deve ser claro e expressar todos os conceitos embuídos no mesmo.

 

- Vocabulário comum: criar um rascunho que guie todo o desenvolvimento e explique o sistema emt ermos universais, assim, todos podem entender a essência do produto a qualquer sistema.

 

- Todos tem autoridade: todos os membros da equipe tem a autoridade e pelo menos duas pessoas devem saber o que é preciso para executar uma tarefa.

 

Princípios

 

Os princípios que formam a essência do XP são baseados nos valores já citados e existem afim de fomentar decisões em um projeto de desenvolvimento de software. Os princípios são mais concretos que valores e mais facilmente traduzido em questões práticas.

 

Feedback

           

Extreme Programming enxerga o feedback como realmente eficáz quando aplicado no momento em que é crítico ter acesso a informações, ou seja, durante o desenvolvimento. Diferentemente de outras metodologias, no XP o contato com o cliente é e deve ser feito em iterações mais frequentes. O cliente tem uma visão clara do sistema que está sendo desenvolvido.  

 

Incorporando a Simplicidade

 

Incorporar a simplicidade é tratar qualquer problema como se a solução fosse extremamente simples. Relembra o K.I.S.S, Keep it Simple, Stupid!. As metodologias tradicionais tentam prever o futuro e buscam programar para reutilizar. O XP não admite este conceito.

 

Fazer mudanças radicais em uma só vez não funciona. Por isso é que XP trabalha com mudanças incrementais.

 

Abraçar a mudança

 

Este princípio prega que não se deve trabalhar contra a mudança, mas trabalhar com ela, como parte do processo. Se em uma reunião com o cliente ficar definido que o sistema terá de ser alterado drásticamente, os programadores devem imediatamente aceitar a idéia e planejar o trabalho.

 

Papéis e Práticas do XP

 

Membros de uma mesma equipe podem representar mais de um dos papéis a serem listados a seguir. O projeto e o desenvolvimento, assim como a modelagem, são feitos por todos e a todo instante. Diferente dos métodos tradicionais, onde encontramos papéis rígidos, o analista de sistemas e o engenheiro de software são incorporados por todos os membros da equipe. É preciso compreender os papéis sugeridos pela metodologia para melhor compreender a aplicação de suas práticas.

 

- Customer – O cliente participa de maneira ativa do projeto. Ele é quem fornece o feedback mais importante do desenvolvimento. É ele, também, quem testa o software através de acceptance tests e descreve os requisitos e o escopo de cada iteração (preferencialmente). Além disso, é sua a aprovação e a aceitação do resultado de cada iteração. É comum haver mais de um “customer”, sendo um deles o responsável exclusivo pelos acceptance tests, sendo conhecido como o acceptance tester.

 

- Programmer – Responsável pela implementação do sistema, assim como por fornecer estimativas para user stories, definir engeneering tasks, testar o sistema (através de unit tests), implementar o programa e garantir que o mesmo passará por todos os testes e será aprovado.

 

- Coach – É quem motiva a equipe e gerencia o trabalho. Garante que a equipe seguirá os princípios, valores e práticas do Extreme Programming durante o ciclo de vida do desenvolvimento. Ele é o responsável pela negociação do escopo e das iterações com o cliente.

 

- Tracker –  Monitora e acompanha o desenvolvimento do projeto a fim de medir o andamento de tarefas sendo implementadas, assim como é o responsável pelas métricas. Ele deve publicar e coletar os dados para toda a equipe e repassar qualquer problema imediatamente para o Coach. Este papel é geralmente alternado entre os membros da equipe e requer que o membro que execute esta função não esteja intimamente relacionado com a implementação do sistema.

 

Release Plan

 

O Release Plan é o plano de desenvolvimento gerado a partir das sessões de planning game. Neste plano estão definidas quais as stories farão parte de cada iteração dentro da release, qual o desenvolvedor responsável por cada story e a estimativa de prazo.

 

Um termo importante dentro do planejamento de projetos XP é velocity. A velocity é a relação entre funcionalidades entregues e as funcionalidades planejadas por cada desenvolvedor. Para medir a velocity de cada desenvolvedor, deve ser feita a medição em uma iteração. Se um desenvolvedor não teve tempo suficiente, seu load factor  foi estimado muito baixo para aquele período. Por outro lado, se ele não teve tarefas suficientes seu load factor estimado foi muito alto. Combinando o load factor de todos os desenvolvedores se obtém a velocity.

 

Como a medição da velocity requer que pelo menos uma iteração esteja concluída, o planejamento feito para a primeira iteração é o mais sujeito a erros e não deve jamais servir como um compromisso de entrega junto ao cliente.

 

Métricas

 

Abaixo, serão listadas as métricas mais importantes para a medição do desempenho dentro da metodologia Extreme Programming.

 

- Velocity –  Número de funcionalidades prometidas versus número de  funcionalidades entregues. Com esta métrica o coach pode, durante o desenvolvimento, conferir o quão próximo está de seu encerramento. É importante salientar que esta métrica só passa a valer após a primeira iteração, quando serão gerados os primeiros dados. Ainda assim, o XP trabalha com a idéia de que a melhor forma de se saber quanto tempo falta e se os objetivos estão no prazo é saber quantos dias já se passaram em relação ao que foi previsto para a conclusão do trabalho.

 

- 40 Hour Week – XP sustenta a idéia de que longos períodos de trabalho podem vir a ser pouco produtivos. Saber a quantidade total de horas trabalhadas por cada membro da equipe é fundamental para  saber a qualidade interna do trabalho.

 

- Test Coverage of the Code – Unit Tests totais por cada classe. Também serve para definir o quão testado foi e está um sistema em desenvolvimento.

 

- Acceptance Test Coverage – Quantidade total de testes de aceitação do projeto.

 

- Acceptance Test Pass – Relação de testes aceitos pelo cliente em função com os testes enviados em cada iteração.

 

- Relative Bug Density – É a quantidade de erros registrados pelo usuário em cada classo multiplicado pelo tempo que demorou para ser corrigido. Cada unidade de tempo investida recebe pontos, assim o cálculo pode ser feito.  

 

Quando Adotar a Metodologia

 

Assim como outras metodologias, nem sempre o XP se aplica a todos os tipos de projeto. É de senso comum a utilização da metodologia em projetos com as seguintes características:

 

- O projeto envolve tecnologias novas e tem seus requisitos alterados constantemente.

 

- Projetos de pesquisa, onde o resultado do trabalho não é um produto, mas o domínio de determinado conhecimento.

 

- Em ambientes onde é preciso adaptar modificações nos requisitos e nas necessidades de negócio rapidamente.

 

Referências Bibliográficas

 

BECK, K., ANDRES, C., Extreme Programming Explained: Embrace

Change. Second Edition, 2004.

 

Phoren, Daniel, Gerência de Projetos de Software. XP Manager, 2004. Disponível em: . Acessado em 4 de março de 2009.

 

Wikipédia – A Enciclopédia Livre, Extreme Programming. Disponível em:. Acesso em 01 de março de 2009.