As Origens do XP

Em 1996, Kent Beck foi contratado para resgatar um projeto de folha de pagamento fracassado na Chrysler chamado C3 (Chrysler Comprehensive Compensation). O projeto estava em apuros—o desenvolvimento clássico em cascata havia produzido um sistema que não funcionava e não podia ser consertado.

Beck não apenas consertou o projeto. Ele sintetizou décadas de sabedoria em engenharia de software em uma metodologia coerente. Ele pegou práticas que desenvolvedores experientes sabiam que funcionavam—testes, revisão de código, desenvolvimento iterativo—e as levou aos seus extremos lógicos.

Se testar é bom, teste constantemente. Se revisão de código é boa, revise continuamente via programação em par. Se integração é boa, integre várias vezes ao dia. Se iterações curtas são boas, torne-as ainda mais curtas.

O projeto C3 foi entregue. Mais importante, ele criou um modelo que reformularia o desenvolvimento de software.

Em 1999, Kent Beck publicou "Extreme Programming Explained"—frequentemente chamado de "o Livro Branco" por sua capa. Este se tornou o documento fundador do XP e um dos primeiros manifestos ágeis.

O livro foi controverso. Programação em par o tempo todo? Nenhum grande design inicial? Clientes no local? Muitos na indústria acharam que Beck estava louco. Mas as equipes que experimentaram o XP relataram resultados notáveis:

• Dramaticamente menos bugs chegando à produção
• Ritmo sustentável em vez de marchas da morte
• Software funcionando em vez de promessas de documentação
• Desenvolvedores felizes que se sentiam no controle

Dois anos depois, em 2001, Beck se juntou a dezesseis outros praticantes de software em Snowbird, Utah. Juntos eles escreveram o Manifesto Ágil. A influência do XP é visível por toda parte—indivíduos sobre processos, software funcionando, colaboração com o cliente, responder a mudanças.

O XP foi a primeira metodologia ágil completa, e de muitas maneiras, continua sendo a mais rigorosa.

A visão tradicional do desenvolvimento de software era que mudança é cara. O custo de corrigir um bug cresce exponencialmente dos requisitos ao design à codificação aos testes à produção. Portanto, você deveria fazer tudo o possível para acertar na primeira vez—daí a ênfase da cascata em design abrangente inicial.

Beck propôs uma alternativa radical: E se você pudesse achatar a curva de custo de mudança?

Se você tem:

• Testes automatizados abrangentes (mudanças podem ser validadas instantaneamente)
• Design simples (menos para mudar)
• Propriedade coletiva do código (qualquer um pode fazer mudanças)
• Integração contínua (mudanças são integradas imediatamente)
• Habilidades de refatoração (código pode evoluir com segurança)

Então o custo de mudança se torna aproximadamente constante ao longo do tempo. E se mudança é barata, você não precisa prever o futuro. Você pode abraçar a mudança como uma vantagem competitiva.

Esta é a percepção fundamental do XP: práticas técnicas podem tornar a mudança barata, e mudança barata muda tudo.