XP (eXtreme Programming)

1. XP (eXtreme Programming)

XP é uma metodologia para desenvolvimento de software ágil, com qualidade que atenda as necessidades do cliente, ou a prática e perseguição da mais clara simplicidade, aplicando no desenvolvimento de software.

Foi criado no final da década de 90. É uma metodologia ágil voltada a equipes pequenas e médias que produzem software baseados em requisitos vagos e que mudam com rapidez. As principais diferenças entre o XP e outras metodologias são feedbacks constantes e uma abordagem incremental. Para isso é necessária uma comunicação entre os indivíduos.

Conforme Astels, a necessidade de entregar o software mais rápido fez com que Kent Beck, Wrad Cunningham e Ron Jeffries explorassem os extremos de determinadas práticas de desenvolvimento. O primeiro projeto a usar a metodologia XP, foi o C3 (Chrysler Comprehensive Compensation) da Chrysler, por um lado restrito e por outro lado levado aos limites. Essa prática foi chamada de “acertar os ponteiros em dez”. O resultado foi uma inovação no desenvolvimento de software, chamada XP.

A XP é considerada uma disciplina de desenvolvimento de software, porque há certas coisas que você precisa fazer para estar desenvolvendo a XP. Se você optar por não fazer testes você não estará sendo Extremo:
      ● Ter feedback antecipado, concreto e contínuo pelos ciclos curtos;
      ● Por sua abordagem incremental de planejamento, que gera rapidamente um plano geral que vai evoluir com o decorrer do projeto;
      ● Habilidade de agendar de forma flexível a implementação das funcionalidades, respondendo às mutáveis necessidades do negócio;

     ● Confiança nos testes automatizados escritos por programadores e clientes para monitorar o progresso do desenvolvimento, para permitir que o sistema evolua e para detectar cedo os erros;
      ● Comunicação oral, testes e código fonte para comunicar a estrutura e o objetivo do sistema;
      ● Confiança na intensa colaboração de programadores com habilidades comuns;
      ● Confiança nas práticas que combinam tanto com os instintos de curto prazo dos programadores quanto os interesses de longo prazo do projeto;

2. Fundamentos da XP

Há diversos fundamentos que a XP leva ao extremo e que em sua maioria não são valorizadas ou mesmo mencionadas pelas demais metodologias de desenvolvimento. Dentre elas podemos citar:

     ● Se revisar o código é bom, revisaremos código o tempo inteiro (Programação em pares);

     ● Se testar é bom, testes serão escritos antes de programar e todos vão testar o tempo inteiro (teste de unidade), até mesmo os clientes (testes funcionais);

     ● Se o projeto é bom, ele fará parte das funções diárias de todos (refatoração);

     ● Se simplicidade é bom, sempre deixaremos o sistema com o projeto mais simples que suporte a funcionalidade atual (a coisa mais simples que possa funcionar), evoluindo constantemente a fim de adicionar a flexibilidade necessária e eliminar a complexidade desnecessária;

     ● Se arquitetura é importante, todos trabalharão para definir e redefinir a arquitetura o tempo inteiro;

     ● Se testes de integração são importantes, então vamos integrar e testar várias vezes ao dia;

     ● Se iterações curtas são boas, faremos iterações muito, muito pequenas – segundos, minutos e horas, não semanas, meses e anos;

     ● Colocar um sistema mínimo em produção rapidamente e desenvolvê-lo na direção que se mostra mais favorável;

     ● 40 horas semanais de trabalho. Na XP, horas extras não são bemvindas, na sexta feira os integrantes devem terminar o seu turno e terem 2 dias para não pensarem em trabalho, para chegarem na segunda-feira cheio de energias e idéias

     ● O cliente deve estar sempre disponível para responder questões e redefinir prioridades de menor escala;

     ● Distinguir entre decisões que devem ser tomadas por interesses dos negócios e aquelas que devem ser tomadas pelos envolvidos no projeto;

     ● Padrões de codificação. Por vezes as duplas serão trocadas e talvez partes do sistema serão feitos por outras duplas, portanto é necessário a adoção de padrões de codificação com uma restrição, o mais simples possível e que seja aprovada por todo o grupo.

3. Aplicação da XP

A XP foi desenvolvida para ser aplicada em projetos em que:

     ● Os requisitos mudem com freqüência;

     ● Utilizem desenvolvimento orientado a objetos;

     ● Trabalhem com times de dois a 10 programadores;

     ● Não sejam severamente restringidos pelo ambiente computacional;

     ● Boa parte da execução de testes possa ser feita em pouco tempo no dia;

     ● E possua desenvolvimento incremental.

A XP assusta ou irrita algumas pessoas que tem o primeiro contato. Mas nenhuma das idéias defendidas pela XP são novas. A maioria delas é tão velha quanto à própria programação, todas as técnicas da XP foram testadas há décadas. As grandes mudanças que a XP traz são:

     ● Colocar todas as práticas juntas;

     ● Garantir que elas sejam praticadas a fundo;

     ● Garantir que as práticas apóiem umas às outras em Extremo.

4. Valores do XP

Para guiar o desenvolvimento, o XP baseia-se em cinco valores:

4.1. Comunicação

Tem como objetivo criar e manter o melhor relacionamento possível entre a equipe desenvolvedora e o cliente, recomendando o contato direto (face-a-face), para evitar qualquer tipo de mal entendido entre os desenvolvedores e para que possíveis dúvidas possam ser resolvidas de imediato.

Além de sanar as dúvidas no desenvolvimento, o cliente deverá estar disponível para a equipe, ou mesmo presente no ambiente de trabalho da empresa. Isto fará com que o cliente entenda o sistema e enriquecerá os relacionamentos pessoais, criando um elo de parceria e confiança mútua.

Algumas equipes não se adaptam bem com isso. Enquanto estiverem com esse problema a metodologia estará comprometida, portanto, a equipe deve entrar em um acordo.

É encorajada também a comunicação entre desenvolvedores e gerente do projeto. Este se caracteriza como um dos fatores principais no XP: conversar ao máximo pessoalmente, evitando o uso do telefone e mensagens de e-mail.

4.2. Simplicidade

Visa minimizar o código, descartando as funções consideradas desnecessárias ou não essenciais. Ou seja, deve ser implementado o menor número de classes e métodos.

Deve-se também estar sempre procurando atender os requisitos emergenciais, evitando adicionar funcionalidades ligadas à evolução do produto. O importante é ter em mente que os requisitos são passíveis de mudanças. Sendo assim, o interessante na prática do XP é implementar apenas o que é realmente necessário para que o cliente tenha seu pedido atendido.

Evita-se suposições, o futuro é incerto e por causa disso não necessita atenção. Os requisitos evoluem gradativamente em conjunto com o sistema e a arquitetura do projeto. Algumas vezes, o que é necessário hoje será descartado amanhã, e outras vezes o que seria necessário num futuro próximo nunca será utilizado.

4.3. Feedback

Chamamos de feedback constante o contato incessante com o cliente a respeito do projeto. Informações sobre o código são dadas por testes periódicos, os quais indicam erros um tanto individuais quanto ao software integrado. Além disso, o cliente terá sempre uma parte do software funcional para avaliar. Com isso, novas características e informações são repassadas aos desenvolvedores, que por sua vez devem implementá-las nas próximas versões. Desta maneira, o que se pretende é entregar o software de acordo com as expectativas do cliente.

4.4. Coragem

Se encaixa na implantação dos três valores anteriores. É importante que os profissionais sejam comunicativos e com facilidade de se relacionar. A coragem auxilia a simplicidade, quando a possibilidade de simplificar o software é detectada. Por fim, a coragem é necessária para garantir que o feedback do cliente ocorra com frequência, pois esta abordagem implicará na possibilidade de mudanças constantes do produto.

4.5. Respeito

É um valor que dá sustentação a todos os demais. É preciso que os membros de uma equipe se importem uns com os outros. Só assim, irão se preocupar em comunicar-se melhor. Respeito é o mais básico de todos os valores. Se ele não existir em um projeto, não há nada que possa salvá-lo. Saber ouvir, saber compreender e respeitar o ponto de vista do outro é essencial para que um projeto de software seja bem sucedido.

5. Equipe XP

5.1. Gerente de projeto

Pessoa responsável pelos assuntos administrativos do projeto, mantendo um forte relacionamento com o cliente para que o mesmo participe das atividades do desenvolvimento.

Os Maiores atributos do gerente são coragem, confiança e insistência ocasional para que façam o que dizem fazer. Isto significa comunicação franca.

O time quer colocar esta habilidade em prática quando precisarem dela. E querem mantê-la distante quando não precisarem.

5.2. Coach

Pessoa responsável pelas questões técnicas do projeto, é necessário um grande conhecimento nos processos de desenvolvimento, nos valores e práticas do XP. Sua responsabilidade é verificar o comportamento da equipe, sinalizando os eventuais erros.

5.3. Analista de teste

Pessoa responsável em garantir a qualidade do sistema através dos testes escritos. Ele deve ajudar o cliente a escrever os casos de testes e no final de cada iteração verificar se o software atende todos os casos de testes.

Recomenda-se que esta pessoa não seja um desenvolvedor, para evitar uma visão tendenciosa já que não conhece o código desenvolvido. O analista de teste deve ter uma visão muito parecida com a do cliente e em muitos projetos esta pessoa acaba exercendo o papel de redator técnico.

5.4. Redator técnico

Pessoa responsável em documentar o sistema, permitindo uma maior dedicação ao trabalho de codificação. Esta pessoa deve estar em plena sintonia com os desenvolvedores e cliente para que a documentação reflita o código escrito e as regras de negócio atendidas pelo sistema.

5.5 Desenvolvedor

Pessoa responsável em analisar, projetar e codificar o sistema. No XP não existe diferença entre analista, projetista e programador uma vez que em vários momentos do projeto o desenvolvedor estará exercendo alguma destas atividades.

É o principal membro da XP, dentre suas habilidades devem ser destacadas a programação em pares e a simplicidade, e acima de tudo a coragem.

Existem níveis distintos de desenvolvedores dentro de uma equipe, mas com a prática de programar em par, a tendência da equipe é se tornar uniforme em suas habilidades.

5.6. Rastreador

O rastreador faz estimativas de tempo e checa se está ajustado à realidade. Isto é uma questão de prática e feedback. Ele é responsável pela visão global do andamento também, se durante uma iteração o que foi previsto será executado, ou se é preciso modificar algo. A maior habilidade aqui é a capacidade de coletar informações de que precisa sem perturbar o processo.

5.7. Treinador

É o responsável por chamar a atenção das pessoas quando estas estão se desviando do processo do time. Todos no Time XP devem compreender a aplicação, mas o treinador o deve muito mais e profundamente. A necessidade deste papel diminui proporcionalmente com o amadurecimento do time.

6. Princípios ou práticas do XP

Para entender as formas que movem o projeto XP, é importante entender seus princípios e suas práticas. Alguns desses princípios são apenas bom senso, outros se tornam a base da maioria dos processos futuros de desenvolvimento de software conforme apresentado a seguir:

6.1. Cliente em conjunto com os desenvolvedores

O XP tem uma visão diferente em relação ao cliente. Este permanece o tempo todo presente, a par do desenvolvimento do software, indicando modificações e esclarecendo duvidas da equipe, onde a sua ausência representa sérios riscos ao projeto.

Ao terminar uma estória, com a presença do cliente, a mesma poderá ser validada rapidamente e a equipe receber o feedback necessário sobre a funcionalidade, criando ciclos rápidos e precisos.

6.2. Planejamento

A XP utiliza o planejamento para assegurar que a equipe de desenvolvimento esteja trabalhando naquilo que gere o máximo de valor para o cliente sempre determinando o escopo da próxima versão, combinando prioridades de negócio e estimativas técnicas. O consultor se reúne com as equipes duas vezes por semana. Nestas reuniões há uma permanente negociação de requisitos e prazos. Este planejamento é feito várias vezes durante o projeto. É o momento onde o cliente solicita as funcionalidades desejadas através de estórias, onde a equipe estima o custo de cada estória e planeja as releases e as iterações.

6.3. Uso de metáforas

Todo o desenvolvimento é guiado por uma simples estória compartilhada de como o sistema funciona e todas as funcionalidades do sistema são descritas.

A metáfora ajuda a equipe a entender sobre o vocabulário utilizado pelo domínio do projeto e assim ajuda-o a nomear funções e variáveis apropriadamente.

São relatadas através de pequenos cartões em que o cliente deve descrever o que deseja com suas palavras e da forma mais simples possível. Lembrando que a simplicidade também deve ser respeitada pelo cliente.

Após a definição das estórias é necessário estimar o tempo das mesmas para que o cliente priorize o que deve ser implementado. A XP utiliza uma unidade chamada ponto, que refere-se a um dia de trabalho ideal do desenvolvedor, onde o mesmo não precisaria atender telefonemas, participar de reuniões, ou seja, estaria preocupado apenas com a estória em questão.

Muitas vezes algumas estórias consomem semanas de trabalho, oferecendo uma certa dificuldade de serem estimadas. A XP recomenda que estas estórias sejam quebradas em tarefas menores e que as mesmas não utilizem mais que alguns pontos de um desenvolvedor, recomenda-se 4 pontos no máximo.

Em cada estória é escrita a quantidade de pontos estimadas pelo desenvolvedor, o XP recomenda que as estimativas sejam efetuadas em equipe e, se possível, com a presença do cliente para que durante a estimativa eventuais dúvidas sejam sanadas.

O XP tem por objetivo gerar valor para o cliente ao longo do projeto, e para isto o software é desenvolvido de forma incremental, onde a cada entrega o cliente possa utilizar o sistema e obter benefícios do mesmo. Estas entregas o XP denomina como sendo releases, pequenos intervalos de tempo, máximo de 2 meses, onde funcionalidades que gerem valor ao cliente sejam entregues.

A divisão dos releases é efetuada no início do projeto, geralmente com tamanhos fixos e pequenos. Após esta divisão o cliente define as estórias que farão parte dos realises.

Mesmo os releases sendo efetuados em curto espaço de tempo, continua representando um tempo muito longo para o feedback do cliente. Por esta razão os releases são divididos em espaços menores, chamados de iterações.

Uma iteração contêm um conjunto de estórias a serem implementadas, com duração entre uma a três semanas, onde ao final da mesma o cliente possa validar as implementações efetuadas e fornecer o feedback necessário à equipe.

6.4. Teste primeiro

Os programadores escrevem unidades de teste continuamente e os executam para que o processo de desenvolvimento continue. Esta atividade é considerada extremamente chata e dispensada por muitos desenvolvedores na modelagem conceitual por exemplo, porém para os desenvolvedores de uma equipe XP esta atividade deve ser encarada. Todo código implementando deve coexistir com um teste automatizado, assim garantindo o pleno funcionamento da nova funcionalidade.

Em cada ciclo eles apresentam uma versão de teste do software ao cliente. Os clientes escrevem os testes para validar o sistema.

É com base nestes testes automatizados que qualquer desenvolvedor terá coragem para alterar uma parte do código que não tenha sido implementada por ele. Com a implementação de testes o desenvolvedor poderá amadurecer o entendimento sobre o problema que irá solucionar, já que os testes são codificados antes da nova implementação.

No XP existem dois tipos de testes, os testes de unidade e de aceitação. O teste de unidade verifica se os resultados gerados por cada classe estão corretos, já o teste de aceitação verifica se a interação entre as classes que implementam uma funcionalidade atendem a necessidade de forma correta. Os testes de aceitação são descritos pelo cliente e implementados pelos desenvolvedores, facilitando ainda mais a interação entre as partes.

6.5. Simplicidade

O sistema deve ser projetado da forma mais simples possível. A complexidade extra é removida assim que detectada. Deve-se implementar apenas a funcionalidade que foi solicitada. Mas deve-se ter atenção para não confundir simplicidade com facilidade.

Umas das premissas do desenvolvimento conceitual é que o custo de uma alteração no sistema cresce exponencialmente ao longo do projeto, com isto tenta-se criar soluções genéricas preparando o sistema para futuras alterações.

No XP o custo de uma alteração tende a crescer lentamente e se estabilizar ao longo do projeto. Esta premissa é dita em função dos avanços nas linguagens e práticas de programação, dos novos ambientes e ferramentas de desenvolvimento, e da utilização de orientação a objetos no desenvolvimento. E em conjunto com estes novos avanços existe o fruto das outras práticas XP, deixando o código simples, legível e passível de alteração a qualquer momento.

6.6. Programação pareada

O XP exige que todo e qualquer código implementado no projeto seja efetuado em dupla, chamada de programação em par. É uma técnica onde dois desenvolvedores trabalham no mesmo problema. Um deles é responsável pela digitação (condutor - menos experiente) e outro acompanhando o trabalho do parceiro (navegador - mais experiente).

Esta prática agrega diversas técnicas de programação, enquanto o condutor codifica o problema o navegador permanentemente revisa o código digitado, onde pequenos erros de programação que demoraria algumas horas para serem depurados, facilmente são percebidos pelo navegador da dupla. Um dos grandes benefícios da programação em par é a troca de experiências e idéias entre os desenvolvedores. A solução para um problema geralmente é a soma das idéias da dupla, tornando uma solução e codificação muito mais rápida e fácil. É com esta prática que o XP uniformiza o nível dos desenvolvedores da equipe, através da troca de experiências. Após alguns meses trabalhando em duplas todos os desenvolvedores conhecerão todas as rotinas do sistema, e estarão prontos para qualquer modificação ou para auxiliar algum iniciante.

6.7. Padronização do código

Um dos valores do XP é a comunicação, e o código também é uma forma da equipe se comunicar. Uma forma clara de se comunicar através do código é manter um padrão no projeto para que qualquer um possa rapidamente entender o código lido.

O XP recomenda a adoção de um padrão desde o início do projeto, preferencialmente padrões utilizados pela comunidade da linguagem de desenvolvimento. Havendo a necessidade de modificações e adaptações durante o projeto, que visam agilizar o desenvolvimento, as mesmas devem ser efetuadas.

A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. O código fonte final deve parecer ter sido feito por apenas um programador.

6.8. Propriedade coletiva

O XP prega que todo desenvolvedor ao encontrar um código duplicado, pouco legível, mal codificado, sem padronização, lento, com código legado ou uso incorreto de outras implementações, mas que esteja funcionando, tem por obrigação alterar este código deixando-o mais legível e simples, porém esta alteração não pode mudar o comportamento do código em questão. Ou seja, o código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema.

6.9. Integração contínua

Visa integrar e construir o sistema muitas vezes ao dia, todas as vezes que uma tarefa tiver sido finalizada.

6.10. Refactoring

É um processo que permite a melhoria contínua da programação. Os programadores reestruturam o sistema sem mudar seu comportamento, para remover duplicação, melhorar a comunicação, simplificar ou adicionar flexibilidade.

6.11. Fases pequenas

Visa produzir um sistema simples rapidamente, planejando novas versões em um ciclo muito pequeno. A liberação de pequenas versões funcionais do projeto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando.

6.12. Semanas curtas (Semana de 40 horas)

Impõe que a equipe não trabalhe mais do que 40 horas por semana / 8 horas por dia. Mas se necessário que não faça hora-extra duas semanas seguidas. Trabalhar com qualidade, buscando ter ritmo de trabalho saudável.

6.13. Stand up meeting

O stand up meeting é uma reunião rápida (em torno de 15 minutos) realizada no início de cada dia, onde os participantes normalmente ficam em pé (daí a origem do nome), cujo objetivo é atualizar todos os membros da equipe a respeito do que ocorreu no dia anterior e priorizar as atividades do dia que se inicia. Ela é uma forma simples de assegurar que as pessoas obtenham feedback rápido sobre qualquer aspecto do projeto, bem como um mecanismo para planejar o que precisa ser feito primeiro, fazendo com que todos relembrem e reavaliem frequentemente o que é mais importante de se fazer a cada dia.

7. Vantagens e desvantagens

7.1. Vantagens

As práticas do XP são usadas pelos integrantes da equipe, para facilitar no desenvolvimento e agregar qualidade no projeto, com isso todos do time devem estar cientes de cada fase do sistema. Um dos benefícios que a mesma oferece é tornar o processo mais ágil e flexível. Conforme Astels, as práticas do XP são criadas para funcionarem juntas e fornecer mais valor do que cada uma poderia fornecer individualmente:

     ● Análise prévia de tudo que pode acontecer durante o desenvolvimento do projeto, oferecendo qualidade, confiança, data de entregas e custos promissores;

     ● O XP é ideal para ser usada em projetos em que o cliente não sabe exatamente o que deseja e pode mudar muito de opinião durante o desenvolvimento do projeto. Com feedback constante, é possível adaptar rapidamente eventuais mudanças nos requisitos;

     ● Estas alterações nos requisitos são muitas vezes críticas nas metodologias tradicionais, que não apresentam meios de se adaptar rapidamente às mudanças;

     ● Outro ponto positivo das metodologias ágeis são as entregas constantes de partes operacionais do software. Desta forma, o cliente não precisa esperar muito para ver o software funcionando, como nas metodologias tradicionais.

7.2. Desvantagens

É freqüente acontecer bugs em todos os projetos de desenvolvimento de software, e no XP não é diferente. Existem pontos fracos no uso dessa metodologia, como:

     ● Não existe uma avaliação de riscos, devendo, portanto implementar uma análise e estratégias que buscam diminuir os erros;

     ● A análise de requisitos é informal e com isso pode não ser bem vista pelos clientes, que poderão se sentir inseguros quanto ao bom funcionamento do sistema;

     ● Refatoração do código pode ser vista como irresponsabilidade e incompetência, pois, não existe uma preocupação formal na utilização do código;

     ● A falta de documentação é característica do processo XP, pois, o mesmo não dá muita ênfase em burocracias (documentos, formulários, processos, controles rígidos, etc.);

     ● Sendo, portanto, importante a elaboração de documentos e diagramas que facilitem no entendimento e identificação do problema;

Além dessas desvantagens, existem algumas situações em que não é indicado o uso do XP, conforme listado a seguir:

     ● A maior barreira para o sucesso de um projeto XP é a cultura empresarial. Qualquer negócio que gerencie  projetos tentando apontar o carro para a direção certa logo de cara terá conflitos com o time que insiste em ir acertando a direção continuamente;

     ● Outra cultura que não contribui para o XP é aquela na qual você é requisitado a trabalhar horas e mais horas para provar o seu “comprometimento com a empresa”. Você não consegue executar o XP se estiver cansado. Se aquilo que o seu time produz trabalhando em velocidade máxima não é suficiente para a sua empresa então o XP não é a solução;

     ● E existe também uma barreira tecnológica para o XP, um ambiente no qual é necessário um longo tempo para se obter feedback. Por exemplo, se o seu sistema leva 24 horas para compilar e linkar, será difícil integrar, compilar e testar várias vezes ao dia.

8. Conclusão

O XP é uma metodologia que estimula a interação contínua entre cliente e desenvolvedor para que as necessidades do cliente sejam visualizadas e compreendidas, obtendo assim, o sucesso do projeto. Ela é baseada em valores e princípios exclusivos que devem ser cultivados para que o projeto obtenha o sucesso desejado.

As desvantagens existem, porém, é através delas que se devem buscar melhorias. É necessário satisfazer os pontos fortes dessa metodologia e buscar o aprimoramento dos pontos fracos, para que ela evolua e consiga espaço no mercado tecnológico de software cada vez mais competitivo.

Podemos, assim, concluir que a inclusão do XP, bem como outras metodologias ágeis, é fundamental para profissionais que buscam melhorias contínuas e sofisticação do software evitando redundâncias e erros incontroláveis no seu desenvolvimento, estando lado a lado com o cliente buscando parceria.