O que é XP (Extreme Programming) e por que suas práticas estão em todo lugar

XP, ou Extreme Programming, é um método de desenvolvimento de software criado em 1996 que se distingue por uma escolha: ele fala de como o código é escrito, não só de como o trabalho é organizado. É o único do repertório ágil que desce a esse nível.

Ele também é anterior ao Manifesto Ágil. Quando o manifesto foi assinado em 2001, o XP já existia havia cinco anos, e Kent Beck, seu criador, foi um dos signatários.

E há um detalhe que diz muito sobre o valor dele: quase ninguém hoje diz "nós usamos XP", mas a maior parte dos times de engenharia usa oito das suas treze práticas. O XP venceu pelas práticas e perdeu pelo nome.

De onde veio

As práticas do XP foram desenvolvidas no projeto C3, na Chrysler, entre 1996 e 1997, onde Kent Beck buscava uma forma de lidar com a imprevisibilidade de desenvolvimento de software. Ron Jeffries, Ward Cunningham e Martin Fowler estiveram envolvidos naquele contexto inicial.

Em 1999, Beck formalizou tudo no livro Extreme Programming Explained: Embrace Change. A segunda edição, de 2004, revisou o material e acrescentou um valor novo, o que vale conhecer porque muito material em português apresenta os cinco como se fossem originais.

Uma correção de vocabulário antes de seguir, porque ela atrapalha o entendimento: o que costuma ser chamado de "os cinco princípios do XP" são os valores. O XP separa três camadas: cinco valores, catorze princípios e as práticas. Valor é o que orienta, prática é o que se faz. Confundir os dois é o que produz adoção de cerimônia sem mudança de comportamento.

Os cinco valores

Comunicação. Conversa direta, de preferência com todos os envolvidos na mesma sala ou na mesma chamada. O XP trata mal entendido como o defeito mais caro que existe, porque ele só aparece depois, transformado em código errado.

Simplicidade. Construir o que é necessário agora, e da forma mais simples que resolva. Não é descuido: é recusa a pagar hoje pela flexibilidade que talvez nunca seja usada.

Feedback. Iterações curtas para que a resposta chegue enquanto mudar ainda é barato. Feedback do cliente, do teste, do próprio código.

Coragem. O menos compreendido dos cinco. Coragem para jogar código fora, para dizer que a estimativa não cabe, para aceitar crítica e para dizer não. Beck define coragem como ação eficaz em face do medo, e a formulação é boa porque não romantiza: o medo continua ali.

Respeito. O valor que entrou na segunda edição, em 2004. Respeito entre quem faz o trabalho, com quem usa o produto e com o próprio código que outra pessoa vai manter.

Na minha visão, os dois últimos são os que explicam por que XP é difícil de adotar. Comunicação, simplicidade e feedback se traduzem em prática. Coragem e respeito dependem de como a organização reage a erro, e isso nenhum método instala.

As práticas, que são o que sobrou

Aqui está a contribuição real do XP, e a razão de ele merecer um lugar no repertório mesmo tendo saído de moda como método.

O que governa time e planejamento

Cliente presente. Alguém com poder real de decisão de negócio faz parte do time, disponível para tirar dúvida. É a prática mais difícil de conseguir, e a que mais falta quando um projeto dá errado.

Planejamento por iteração. Uma reunião semanal, ou de no máximo duas semanas, em que o time planeja o ciclo e acorda a entrega com o cliente. Para quem vem do Scrum: a iteração do XP corresponde à Sprint.

Stand up. Reunião curta, em pé, para expor impedimento e dar visibilidade. Não é para resolver problema nem para dar status ao gestor. Virou a Daily do Scrum, e a distorção é a mesma nos dois: transformar coordenação em prestação de contas.

Ritmo sustentável. Na formulação original chamava-se "semana de 40 horas". A segunda edição renomeou para ritmo sustentável, e a mudança de nome é boa: o ponto não é o número, é que time cansado produz defeito, e defeito custa mais que a hora extra economizou.

Metáfora. Construir um vocabulário compartilhado entre negócio e técnica para falar da mesma arquitetura. É a prática menos adotada e uma das mais úteis, porque a maior parte do desalinhamento entre área técnica e área de negócio é vocabulário, não intenção.

O que governa o código

Programação em par. Duas pessoas na mesma tarefa, uma escrevendo e outra revisando e pensando à frente. Parece desperdício de metade da capacidade, e é a objeção que sempre aparece. A troca é: menos defeito, conhecimento espalhado em vez de concentrado, e a revisão de código acontecendo no momento em que o código nasce, em vez de virar fila depois.

Testes constantes e TDD. Teste unitário cobrindo pequenas partes do código, de forma contínua. O TDD leva isso mais longe: escrever o teste antes do código que o faz passar. Parece trabalhoso no começo, e o ganho menos óbvio não é a redução de defeito, é que escrever o teste primeiro obriga a definir o comportamento esperado antes da implementação, o que costuma simplificar o desenho.

Refatoração. Melhorar código existente sem mudar o que ele faz. É o que impede que a simplicidade de hoje se transforme na dívida de amanhã.

Design simples. O desenho atende o que é necessário agora. Quanto mais simples o código, melhor.

Padrão de código. Convenção comum para que qualquer pessoa do time consiga trabalhar em qualquer parte, e para que a discussão seja sobre a solução e não sobre formatação.

Rodízio de duplas. Trocar quem faz par com quem, de forma que o conhecimento circule em vez de ficar preso em duas cabeças.

O que governa a entrega

Integração contínua. Integrar o código com frequência, de preferência automatizada, para que o conflito e a quebra apareçam em horas e não em semanas.

Entregas curtas. Releases frequentes de software funcionando, em vez de esperar o fim do projeto. É o mesmo princípio que sustenta o MVP no Lean Startup e o pipeline em DevOps.

Repare no que aconteceu com essa lista. Integração contínua, entregas curtas, TDD, programação em par, refatoração, padrão de código e stand up são hoje default em times que nunca leram Beck. O XP foi absorvido prática por prática, e o rótulo ficou para trás.

O ciclo, em linhas gerais

O fluxo começa com o objetivo do cliente, que é detalhado em histórias de usuário, enquanto o time pensa arquitetura e desenho da solução. As metáforas nascem aí, para dar vocabulário comum.

Vem então um planejamento de release para estimar esforço, e com as releases definidas começam as iterações, que produzem código funcionando. Durante a iteração podem surgir histórias novas, técnicas ou funcionais.

No fim da iteração, a funcionalidade vai para teste de aceitação com o cliente, usando cenários derivados das próprias histórias. Se não passa, volta para a iteração. Se passa, entra no pacote da release.

A referência que sustenta esse desenho é o site oficial do método, em extremeprogramming.org.

Onde o XP se encaixa

O XP ocupa um lugar que os outros deixam vazio, e é por isso que ele combina em vez de competir.

Essa é a razão prática de conhecer XP mesmo trabalhando com Scrum. Um time pode ter Sprint, Daily, Review e Retrospectiva impecáveis e ainda assim produzir software difícil de mudar, porque nada nesse arranjo fala de teste, de integração ou de refatoração. O Scrum não é omisso por descuido: ele deliberadamente não opina sobre engenharia. O XP é onde essa parte está.

E há uma restrição que o próprio XP declara: ele foi feito para desenvolvimento de software. Scrum e Kanban atravessam qualquer tipo de trabalho, XP não. Não faz sentido falar de programação em par em uma equipe de marketing.

O que costuma travar

Programação em par é a primeira a cair. Ela aparece na planilha como duas pessoas produzindo o trabalho de uma, e o ganho, menos defeito e conhecimento distribuído, não aparece em nenhuma métrica de curto prazo. Quem corta o par sob pressão de prazo paga depois, em uma linha de orçamento diferente.

Cliente presente quase nunca acontece. O que se consegue costuma ser um representante sem autoridade de decisão, e aí o time volta a adivinhar. Vale o mesmo que escrevi sobre Product Owner: quem precisa pedir aprovação para decidir não está decidindo.

Ritmo sustentável é a que a organização viola primeiro. E é a que mais custa, porque time cansado gera defeito, e defeito custa mais caro que a hora extra que ele economizou.

Na sua organização, existe alguma prática de engenharia que é tratada como negociável quando o prazo aperta? E o que costuma acontecer com o custo dela depois?