O XP (eXtreme Programming) é uma metodologia ágil focada na codificação, que nasceu com o propósito de desenvolver softwares de extrema qualidade e humanidade, com a preocupação de se adaptar às mudanças que aparecem no meio do caminho, mais do que seguir um plano fixo.

Falhas que o XP busca resolver

O desenvolvimento de software é complexo e passa por diversas trocas de escopos, e neste cenário o papel do XP é contornar as falhas que podem aparecer durante a trajetória. Algumas das principais falhas são:

• Cliente distante: gera confusão do que fazer quando as dúvidas de negócio começam a aparecer, criando insatisfação o cliente com a entrega;
• Cereja do bolo: entregas de features que o cliente não pediu, que causam desperdício de tempo ou complexidade desnecessária;
• Testes apenas no final: se tornam mais complexos de realizar e/ou não recebem a devida atenção;
• Trabalho empurrado: muitas vezes por conta de prazos curtos, levando a um código mal escrito e propenso a bugs;
• Dívidas técnicas: formam uma bola de neve no nível de complexidade do código, tornando-os muito caros para fazer manutenção.

Valores e princípios

O XP preza muito pela humanidade, além da qualidade. Então é importante utilizar todos os seus valores, que são complementares, para que seja possível aproveitar ao máximo os benefícios da metodologia.

• Comunicação: uma boa e constante comunicação é extremamente importante para que o time esteja sempre alinhado;
• Simplicidade: manter as entregas e o código o mais simples possível, sendo objetivo;
• Feedback: importante saber passar e receber constantemente;
• Coragem: evitar ao máximo que criem barreiras entre as boas ações;
• Respeito: as pessoas devem manter respeito entre elas em todas as situações, assim se sentirão valorizadas e confiantes.

Práticas

Cliente presente

O cliente ou seu representante (chamado de Product Owner do Scrum) precisa estar presente durante o desenvolvimento do projeto, para que ao surgirem dúvidas do time de desenvolvimento sobre a regra de negócio, elas possam ser sanadas o quanto antes.

Time coeso

Um time coeso possui uma comunicação melhor por estar integrado. Busca continuamente a simplicidade e constrói confiança para ter coragem e gerar feedback por meio de respeito mútuo.

Para o time aplicar essa prática com excelência, precisa ter as seguintes características:

• Multidisciplinar
• Auto-organizável
• Pessoas unidas/próximas
• Buscar melhorias contínuas

Posse coletiva

Todas as pessoas ou pares do time devem ser capazes de realizar os processos do projeto. Não deve haver partes do sistema que apenas uma pessoa consiga mexer. É sempre válido fazer a seguinte pergunta para saber se essa prática está sendo aplicada: “Quantas pessoas precisam faltar para que possa haver impedimentos no projeto?” – Se a resposta for um número pequeno, o projeto possui partes com donos individuais e não de posse coletiva.

Ritmo sustentável

É importante ter um ritmo sustentável para que a produtividade não comece a cair no decorrer do tempo. O desenvolvimento de software é uma maratona, não uma corrida de 100m, então não é prudente se desgastar no início do projeto, mas sim manter um ritmo constante.

Metáforas

Trazem uma visão comum para o projeto que ajuda o time e o cliente a entenderem o objetivo mútuo. Utilizar a linguagem onipresente que o DDD (Domain-Driven Design) traz, nomeando corretamente o negócio em todas as áreas do time, pode ajudar a tirar o máximo de proveito que essa prática possui.

Entregas simples

Fazer com que as entregas sejam mais objetivas, sem tentar prever o futuro e trazer funcionalidades que não foram pedidas.

Utilizar o MVP (Minimum Viable Product ou Produto Mínimo Viável) pode maximizar essa prática, criando uma versão com apenas o que é mais importante para o projeto, sem os detalhes, a fim de validar a ideia o mais rápido possível.

Planejamentos

Users Stories (Histórias de usuários)

Descrevem os requisitos de forma ágil (como o UML porém mais prático), deixando os detalhes para serem discutidos com o cliente em reuniões, fortalecendo o trabalho em conjunto.

Normalmente a história de usuário começa com apenas uma história abrangente, mas no decorrer da reunião ela é dividida em várias histórias objetivas que por final se tornam tarefas para os desenvolvedores. Elas nascem através da conversa com o cliente e devem ser anotadas em cartões.

Existem várias formas de fazê-las, mas o modelo de escrita mais utilizado é o Connextra, que possui o seguinte formato:

Como um … Eu quero … Para que …

Jogo do planejamento

Tem o objetivo de melhorar a organização do tempo de desenvolvimento através de jogos que dão pontos para cada tarefa.

Um jogo que é bastante utilizado é o Planning Poker, onde o time dá pontos para cada tarefa e, se houver alguma discrepância desproporcional entre duas pessoas ou grupos, eles devem conversar para entender o porquê dessa diferença.

Para realizar esse planejamento é importante sempre ter um limite de pontos, com cada ponto representando um tempo, mantendo o objetivo de sempre chegar o mais próximo desse limite, mas não o ultrapassar.

Entregas pequenas

Cada release do projeto deve ser entregue com o menor tamanho e menor tempo possível, sem perder o valor de negócio, por isso é preciso saber priorizar as entregas.

As vantagens de realizar pequenas entregas são:

• Entrega de valor adiantado e contínuo;
• Processo aprimorado durante o desenvolvimento com o conceito: se for falhar, falhe rápido;
• Código sendo atualizado com frequência;
• Maior confiança, qualidade e estabilidade;
• Motivação do time por ver seu trabalho sendo utilizado.

Além desses benefícios, é possível realizar testes de aceitação, que devem ser automatizados da forma mais simples, garantindo que o sistema não quebre a cada entrega. Esses testes devem utilizar um ou mais critérios de aceitação criados pelo cliente.

Um modelo de escrita para fazer esses testes é o BDD (Behavior Driven Development ou Desenvolvimento Orientado ao Comportamento) que possui o seguinte formato:

Dado que … Quando … Então …

Spikes de planejamento

Utilizado quando não se tem conhecimento de como realizar a tarefa, tem como objetivo fazer um protótipo consumindo o menor tempo possível antes do jogo de planejamento, para que  no momento de organizar as entregas, seja possível realizar o jogo. Importante saber que o que foi criado para o protótipo não deve ser continuado quando realizar a tarefa.

Práticas de codificação

É importante que o time defina um padrão de codificação e que seja seguido por todos, isso torna o código e o time uma unidade, de forma que não tenhamos diferentes donos e padrões de códigos, porque isso facilita a integração contínua.

Os builds das pequenas entregas são construídos por meio da integração contínua. Ela verificará o build automaticamente a cada commit realizado no repositório. Em cada um o padrão de codificação pode ser verificado automaticamente, além de ter testes de aceitação executados também.

Outra prática muito utilizada no XP é a do TDD (Test Driven Development ou Desenvolvimento Orientado por Testes) que se baseia em realizar testes automatizados antes da implementação das funcionalidades, independente se são novas ou não. Isso faz com que o desenvolvedor pense mais sobre a implementação e consiga torná-la o mais independente possível, o que facilita a escalabilidade do projeto. O TDD possui o seguinte fluxo:

1. Escreva os testes (irão falhar);
2. Escreva as funcionalidades e faça os testes passarem;
3. Refatore.

Evolução contínua

Ter um código simples é uma ótima prática no mundo de desenvolvimento de software e adotada pelo XP. Códigos são desenvolvidos por pessoas para pessoas, por isso é extremamente importante refatorar o código depois de criar ou fazer uma manutenção, tentando deixá-lo mais simplificado do que era antes, sempre pensando no próximo desenvolvedor que irá precisar mexer no futuro.

Outra prática muito utilizada no desenvolvimento de software, e também adotada pelo XP, é a do Pair Programming (Programação em par), onde duas pessoas programam juntas com apenas um computador. Por mais estranho que possa parecer em questão de recursos, por termos dois desenvolvedores fazendo o trabalho que poderia ser feito por um, essa prática traz ótimos resultados e garante mais qualidade no código, principalmente quando se trata de implementações complexas, sem contar que fortalece os laços entre os membros do time e ajuda na posse coletiva.

A comunicação também possui um papel muito importante para manter o projeto em uma evolução contínua e com qualidade, por isso é recomendado que todos os dias o time faça uma reunião rápida, de pé (para garantir que não se estenda), no mesmo local e horário para economizar tempo de planejamento.

Conclusão

Ao utilizar os conceitos do XP, o time pode vir a realizar entregas com mais qualidade e agilidade, mas é importante saber que ele não precisa ser o único método ágil utilizado. O XP combinado com outros métodos/framewroks causará impactos positivos e mais fortes.