Luiz Esmiralha liked my Extreme Stake in the Ground entry so much, he translated it to Brazilian Portuguese. How cool is that?

Um Desafio Extremo, por Jim Shore

Nos primórdios de Extreme Programming, as pessoas a saudavam, e algumas a criticavam, como um desafio. A metodologia XP, nessa época, era bem objetiva quanto à maneira correta de se desenvolver software. Ela tinha uma postura extremista e se orgulhava disso.

Desde então, tornou-se comum a adoção uma atitude mais "desiludida" por uma grande da comunidade XP. "Claro, existem muitos pontos de vista." "Qualquer processo irá funcionar, se você tiver uma equipe excelente." "XP é um lindo ideal, mas no mundo real não conseguimos (programar em pares, ter o cliente presente, desenvolver testes primeiro, etc.)".

Esse tipo de ponto de vista é muito maduro, sábio e soa profundo. Mas começa a me cansar. Sim, existem vários processos. Sim, pessoas inteligentes sempre dão um jeito de serem bem-sucedidas. Sim, XP não é adequada em algumas situações.

Ainda assim, sinto falta do idealismo daqueles dias. Há algo de satisfatório em dizer: "Nós sabemos o que funciona e não vamos abrir mão de realizar o melhor trabalho possível. Se o ambiente não permite que se realize um ótimo trabalho, mudaremos o ambiente e não nosso trabalho."

Eu já liderei equipes dessa maneira... Elas foram incrivelmente bem sucedidas. Quando você se livra da "desilusão", abraça XP, a leva até o extremo lógico e diz: "consertaremos os problemas do ambiente, não nos adaptaremos a eles", as coisas funcionam. Não, isso é mentira. As coisas não apenas funcionam, elas funcionam melhor do que em qualquer outra situação que eu tenha vivido.

Inspirado por uma recente discussão sobre integração contínua, tento lançar novamente o desafio. Aqui vai uma visão renovada das 12 práticas originais de XP, apresentadas com uma total falta de humildade, maturidade e visão desiludida do mundo. Pense nisso como o Juramento XP. Faça essas coisas, acredito nessas coisas--mesmo uma já é um bom começo--e você será mais bem sucedido. Eu garanto.

Leia sempre a letra miúda. Embora eu garanta que você será mais bem sucedido, eu não garanto que você terá sucesso. Talvez você evolua de um fracasso vergonhoso para um fracasso total, ou algo assim. Infelizmente, é preciso mais que programação brilhante para se garantir o sucesso. Além disso, você tem que fazer as coisas da maneira correta e, se eu teria dificuldades para transmitir isso pessoalmente, imagine com 500 palavras. Basicamente, pessoal, vocês estão por sua conta. Imaginem uma risada diabólica ao fundo e tenham um bom dia.

O Juramento XP (para ser feito pela Equipe como um todo)

• Sempre criaremos planos em acordo com nossas estimativas mais precisas. Estimaremos o esforço em partes pequenas o bastante para que possamos estimar com precisão. Avaliaremos continuamente nosso plano, parando a intervalos predeterminados e fixos e comparando nosso plano com a realidade dos fatos. Quando nosso plano for diferente da realidade, mudaremos o plano. (também conhecido como o Jogo do Planejamento)

• Entregaremos software funcional em produção aos clientes o mais cedo possível. Encontraremos maneiras de entregar valor significativo em menos de 3 meses. Incluiremos em nossos planos, apenas o trabalho que o Cliente possa reconhecer e entender. Sempre entregaremos primeiro as funcionalidades de maior valor. (também conhecido como Releases Curtos)

• Encontraremos um especialista de negócios que entenda o ponto de vista dos Clientes e Usuários de forma impecável e ele será parte da Equipe em tempo integral. Jamais faremos especulações a respeito do ponto de vista do usuário. Em vez disso, nós perguntaremos ao especialista sempre que necessário. (também conhecido como Cliente Presente.)

• A versão mais recente do código em nosso repositório sempre será compilável e passará em todos os testes. Integraremos as últimas alterações e as enviaremos ao repositório a cada duas ou quatro horas. Nosso sistema de build automático construirá uma versão capaz de ser entregue aos Clientes, mesmo que a falta de funcionalidades ainda não permita realmente fazê-lo. (também conhecido como Integração Contínua)

• Minimizaremos o custo de mudança, implementando o projeto mais simples possível, sem ser simplório, para as funcionalidades de hoje. Não adicionaremos antecipadamente ganchos ou pontos de entrada para funcionalidades, se não as estamos implementando hoje. Nos manteremos atentos à duplicação e outros erros de projeto que aumentam o custo de mudança e melhoraremos nosso projeto ao remover esses erros. (também conhecido como Projeto Simples)

• Sempre que nosso trabalho diário revelar uma falha em nosso projeto e sempre que, melhorando o projeto, possamos terminar o trabalho de hoje mais rapidamente, nós mudaremos o código e aperfeiçoaremos o projeto. Sempre faremos uma mudança, por menor que seja, como renomear uma variável, desde que ela deixe o projeto hoje melhor do que era ontem. Nunca permitiremos que a qualidade do projeto hoje seja pior do que ontem. (também conhecido como Refatoração Impiedosa)

• Testaremos tudo que possa dar errado. Teremos testes ao nível do Cliente, assim como do Programador. Escreveremos os testes antes do código, possivelmente momentos antes. Automatizaremos os testes e os projetaremos de forma que seu resultado seja binário: sucesso ou falha. (também conhecido como Testes Incansáveis)

• Somos todos co-responsáveis pela qualidade do código. Quando encontrarmos um problema que precisa ser consertado, nós consertaremos, não importa quem seja o autor original. Quando encontrarmos uma funcionalidade que precisa ser implementada, nós a implementaremos, trabalhando em qualquer parte do código para atingir um resultado de qualidade. Nós não reclamaremos quando alguém da Equipe alterar código que nós escrevemos. (também conhecido como Propriedade Coletiva do Código)

• Trabalharemos na maior velocidade que nos permita realizar o nosso melhor e mais produtivo trabalho de forma contínua. Nós responderemos a emergências e solicitações de mais tempo, de forma atenciosa, porém firme, sugerindo alterações de escopo e recursos, ao invés de trabalhar de uma forma que comprometa a qualidade do produto final ou nossa produtividade. (também conhecido como Ritmo Sustentável)

• Reconhecemos a dificuldade de ser totalmente fiel a esse juramento dia após dia. Daremos apoio a cada Programador, trabalhando em pares. Quando fraquejarmos, confiaremos em nosso par para lembrar-nos de nossos deveres. Quando eles fraquejarem, os apoiaremos com compaixão e não os julgaremos. Todos os dias, ajudaremos uns aos outros a ser mais produtivos e a fazer o melhor que somos capazes de fazer hoje. Nós evitaremos rancores e compartilharemos a informação trocando de par várias vezes ao dia. (também conhecido como Programação em Pares)

Existem nuances. Existem questões de aplicabilidade. Existem até maneiras de ser mais extremo. Tudo isso é verdade, e esse artigo é um desafio. Comece por aqui.

(Traduzido por Luiz Esmiralha <esmiralha@gmail.com>, a partir do artigo de Jim Shore publicado em seu blog: http://www.jamesshore.com/Blog/An-Extreme-Stake-in-the-Ground.html)