Introdução ao Extreme Programming (XP)

Os métodos ágeis surgiram de profissionais que vieram da orientação a objetos como Kent Beck e Ward Cunningham, duas grandes personalidades no que tange o tema de métodos ágeis. Essas pessoas foram lideres na adoção dessas linguagens orientadas a objetos, ambos vieram principalmente da linguagem Smalltalk. A partir disso também surgiram outras práticas da comunidade Smalltalk como refatoração, programação em par, mudanças rápidas, feedback constante do cliente, reforçou-se o desenvolvimento iterativo, testes automatizados, etc.

Kent Beck influenciou muitas pessoas em todas essas práticas e na adoção dos métodos ágeis. Portanto, ele é considerado um grande ícone nessa área. Inclusive foi ele quem fez a família XUnit (como Junit e NUnit). Mas Kent Beck não estava sozinho, outros profissionais como Opdyke que criou a refatoração, Cunningham com os padrões de projetos, entre outros que também tem a sua importância.

O Extreme Programming (XP) tem muita semelhança com SCRUM em termos de valores e modelo de desenvolvimento de projetos, ou seja, como desenvolver projetos que possam abraçar as incertezas de forma mais seguras. No entanto, esses dois métodos também são complementares, visto que SCRUM é mais como um framework gerencial. O XP desenvolve menos esses aspectos e foca mais em práticas de engenharia.

Extreme Programming

Criada em 1997 o XP possui adeptos e outros que duvidam da sua real utilidade, muitos por falta de conhecimento ou entendimento achando que no XP apenas código é o que realmente interessa descartando o resto como planejamento, documentação, etc.

O XP é um método de desenvolvimento de software, leve, não é prescritivo, e procura fundamentar as suas práticas por um conjunto de valores que serão vistos posteriormente no artigo. O XP, diferentemente do que muito pensam, também pode ser adotar por desenvolvedores médios e não apenas por desenvolvedores experientes.

O objetivo principal do XP é levar ao extremo um conjunto de práticas que são ditas como boas na engenharia de software. Entre elas podemos citar o teste, visto que procurar defeitos é perda de tempo, nós temos que constantemente testar. Mas o XP possui mais práticas do que apenas testar, entre as práticas, o XP diz que:

• Já que testar é bom, que todos testem o tempo todo;
• Já que revisão é bom, que se revise o tempo todo;
• Se projetar é bom, então refatorar o tempo todo;
• Se teste de integração é bom, então que se integre o tempo todo;
• Se simplicidade é bom, desenvolva uma solução não apenas que funcione, mas que seja a mais simples possível;
• Se iterações curtas é bom, então mantenha-as realmente curtas;

Portanto, como podemos notar todas as coisas boas são levadas ao extremo no XP.

Os opositores do XP dizem que XP é para times ou projetos pequenos. No entanto, histórias de sucesso como a da grande empresa chamada Chrysler. A Chrysler possuía um sistema de folha de pagamento global que envolvia seus 90 mil empregados ao redor de todo o mundo. Existia um sistema COBOL e converteu-se em Smalltalk na época. Seu planejamento inicial era de quatro anos (1995-1999) e isso não ocorreu. Em 1996 Kent Beck e Jeffries foram contratados e começaram a aplicar práticas que auxiliaram a consolidar o que hoje é o XP. Esse projeto tem 2.000 classes e 30.000 métodos, foi para produção após um ano depois da contratação de Beck e Jeffries.

Outro exemplo foi o sistema Ford Motors Company VCAPS System que utilizava métodos tradicionais e enfrentava diversos problemas. Os desenvolvedores ficavam mais tempo consertando problemas encontrados do que desenvolvendo ou evoluindo o sistema. Após isso o projeto começou a adotar testes automatizados, integração contínua e outros valores do XP. Em menos de um ano, algo que não se conseguia há quatro anos, o sistema foi desenvolvido e evoluído constantemente sem maiores problemas.

O XP muda o paradigma, onde não temos o medo da mudança, pois o errar é feito com um baixo custo. Diferente do tradicional em que se diz que quanto mais tarde a mudança, maiores são os custos, e assim sendo nunca devemos fazer mudanças o XP diz que devemos sim estar constantemente fazendo mudanças e não devemos teme-las, principalmente quando seguimos os seus valores e as suas práticas. Outra situação desafiada pelo XP é a engenharia de software que afirma sempre projetarmos para mudança, ou seja, vale despender tempo e esforço antecipando mudanças quando isso reduz custos posteriores no ciclo de vida. No entanto, novamente o XP assume que este esforço não vale a pena quando as mudanças não podem ser confiavelmente previstas, ou seja, não vale a pena empregarmos um grande esforço que pode nem mesmo ser utilizada no agora, no futuro ou nunca.

Para conseguirmos se adaptar as mudanças o XP preconiza ciclos curtos que nos dá previsibilidade e redução de incertezas/riscos, Simplicidade e melhorias constantes de código (refactoring) para facilitar a mudança e Testes Automatizados e Integração Contínua para aumentar a confiança.

Por fim, o manta do desenvolvedor XP é resumido pelas palavras:

• Escute, para que saibamos qual é o problema a resolver e assim sendo conversar bastante com o cliente.
• Planeje, para que sempre que possamos fazer a coisa mais importante ainda a fazer. Planejamento é uma constante onde planejamos o tempo todo, incorporando no plano os toques de realidade que temos atualmente.
• Codifique, senão o software não sai. XP é contra a documentação que não agrega valor, portanto enquanto um documento não é codificado ele é apenas um documento, dessa forma o documento mais importante é realmente o código.
• Teste, senão não iremos realmente saber se está funcionando.
• Refatore, senão o código vai ficar tão ruim que será impossível dar manutenção. Mantemos o espaço de trabalho sempre limpo através das práticas de refatoração.

No próximo tópico falaremos sobre os valores do XP, um dos tópicos mais importantes para entendermos o XP.

Valores do Extreme Programming

As práticas do XP são fundamentadas em valores. Veremos cada um dos valores do XP. Entre os valores temos:

• Comunicação: segundo Beck “Os problemas nos projetos invariavelmente recaem sobre alguém não falando com alguém sobre algo importante”. Assim, a comunicação enfatiza que devemos sempre estar se comunicando seja entre desenvolvedores ou com os clientes. XP é organizado em práticas que não podem ocorrer se não houver comunicação. De preferencia os clientes devem estar sempre presentes para criar Histórias de usuário e cliente on-site (CCC) ou ainda tirar dúvidas. Outra forma de comunicação no XP é a Programação em pares, onde os desenvolvedores programam num mesmo computador, nesse formato de programação ambos estão constantemente se comunicando e trocando ideias. O Jogo do planejamento (planning poker) também é outra forma de comunicação visto que a equipe de desenvolvimento está dando sua visão técnica, o cliente por sua vez está dando requisitos em pró do negocio e dando as prioridades. A comunicação ajuda na eliminação de documentos e favorece a comunicação face a face.
• Simplicidade: é tentar fazer o mais simples possível e caso seja necessário faremos algo mais complexo amanhã. Muitas vezes algo é feito de forma completa e posteriormente não é mais sequer usado ou necessário. Portanto, entre os princípios temos: Qual é a coisa mais simples que funciona?

Aqui também temos a importância do coach que deve estar sempre verificando se a simplicidade esta sempre sendo seguida nos projetos.

Fazendo um paralelo entre a simplicidade e a comunicação conclui-se que a simplicidade faz com que temos menos a comunicar e de uma forma mais completa e por sua vez a comunicação faz com que transmitimos mais clareza e confiança para alimentar a simplicidade.

• Feedback: é muito presente no SCRUM através das reuniões diárias, retrospectiva, reuniões de revisão do produto, etc. Feedback é o valor primordial dentro do desenvolvimento ágil. O XP foi o precursor a falar em feedback e afirma que ele possibilita que o software evolua. O XP, como algo mais técnico que o SCRUM, diz que devemos sempre “Perguntar ao software, e não a um documento", uma forma de alcançar isso é através dos testes automatizados que permitem feedback rápido. Os teste automatizados respondem de forma imediata se aquilo que foi introduzido ainda esta funcionando.

O Feedback precisa ser cedo para sabermos se estamos fazendo a coisa correta, precisa ser concreto perguntando diretamente ao código e precisa ser constante através de iterações curtas, incrementos, e releases. Aqui garantimos constantemente junto ao cliente se estamos fazendo certo e o prazo esta seguindo bem o planejado.

• Coragem: muitas vezes não fazemos as coisas porque não temos coragem de fazer as mudanças. XP diz que devemos ter coragem de sempre colocar o cliente a par do que está acontecendo. Entre aquilo que o XP considera que devemos ter coragem de fazer destacam-se:
  • Acreditar na capacidade de reagir a mudanças;
  • Trocar de paradigma;
  • Aprender com os erros;
  • Dar e receber feedback sem medo das consequências;
  • Acreditar no feedback concreto (não na “teoria”);
  • Fazer o que precisa ser feito;
  • Jogar fora código ruim;
  • Jogar fora protótipos criados para testar ideias.
• Coach: é uma pessoa responsável por garantir a aderência a estes valores nas práticas. O Coach normalmente é uma pessoa experiente que também ajuda as equipes a implementarem o XP e monitorar se as coisas estão sendo bem seguidas.

Por fim, XP preconiza que Codificação é a atividade central do projeto, que os Testes (que também são código) servem de especificação de requisitos, e a Comunicação oral entre desenvolvedores é fundamental.

Isto não quer dizer que a equipe XP não constrói documentos e não faz modelagem, ela só não considera que um modelo é um documento. Modelos são feitos o tempo todo seja como quadro branco, sessões de design, etc, mas servem como um suporte para o concreto que realmente importa.

Adoção do XP na Organização

Não existe uma regra geral de como devemos adotar o XP na nossa organização. Como experiência pessoal e compartilhada com outros colegas posso dizer que se você nunca utilizou XP antes e quer começar a utilizar com um cliente que já está há algum tempo trabalhando com você e a sua equipe o ideal é que esse processo seja gradual, tanto com o cliente quando com a equipe. Ou seja, começa-se a utilizar os valores e as práticas do XP aos poucos criando testes automatizados aos poucos com as partes mais importantes, chamando o cliente para participar das reuniões e mostrando a importância disso para o próprio cliente, para a equipe e para o bem do projeto. Se você quer utilizar XP desde o início é mais simples, basta começar a utilizar e envolver o cliente no processo, seguindo sempre os valores e práticas do XP.

Conclusão

Neste artigo, vimos o que é o XP, quais são os seus valores e o que são cada um deles. Também vimos o que o XP preconiza como sendo realmente importante e fizemos algumas comparações com o SCRUM que também é bastante utilizado hoje, porém mais como um framework gerencial, diferente do XP que é mais técnico.