Dentre as várias vantagens que vejo no Extreme Programming, creio que o núcleo delas seja a simplicidade. Ao contrário de muitas metodologias, você não precisa de caríssimas ferramentas para fazer seu trabalho: somente um bloco de papel, um editor, um compilador e um framework de testes são necessários.

Sem diagramas de interpretação dúbia nem documentos desatualizados que ninguém lê. Os desenvolvedores só precisam desenvolver o código, documentá-lo com comentários (incluindo JavaDoc ou similar), e, se desejável, gravar as “User Stories” (escrever é obrigatório - manter gravado, nem tanto).

Uma “User Story” é similar a um “Caso de Uso” do RUP. Não obstante, são mais simples (ou seja, menos burocráticos), e, o mais importante, são escritos pelo cliente, usando termos orientados ao negócio do cliente.

Como, infelizmente, nem sempre é possível contar com o cliente para estar sempre ao nosso lado para escrever todas as “User Stories”, podemos usar saídas alternativas. Uma delas, que descobri ao acaso graças ao iGoogle, é o Google Notas.

Trata-se de um editor de notas incrivelmente simples e eficaz. Ele edita pequenas notas, contraindo-as para a primeira linha para economizar espaço visual, agrupando-as em blocos e seções.

Como eu precisava de um meio não-físico para escrever algumas stories, decidi escrevê-las no Google Notas. Serviu como uma luva: criei um bloco para o projeto, escrevi cada story em uma nota e, depois, agrupei-as conforme cada iteração ia surgindo. Ativando o compartilhamento, todos os interessados teriam acesso.

Ou seja, o cliente pode entrar no Google Notas em qualquer lugar com acesso à Internet, escrever as stories, priorizar e disponibilizar à equipe de desenvolvimento. Liberando o cliente para participar de uma reunião somente para tirar eventuais dúvidas na hora de redigir as tarefas e escolher a próxima iteração.

“No princípio, Deus criou os céus e a terra” (Gênesis 1:1)

Já passou alguma vez por uma documentação que, ao invés de descrever o que o sistema faz, conta a história deste? Algo similar a “No princípio, Fulano criou o sistema para fazer isso” - praticamente uma versão em texto corrido daquela tabela de “histórico de alterações” (cuja origem desconheço).

Implementar um sistema baseando-se nesse tipo de documentação é como fazer manualmente um “merge”, revisão por revisão, de um arquivo no sistema de controle de versão.

Se o sistema originalmente considerava multa de 20% e, por definição do chefe do setor, passou a considerar multa de 10%, por que precisa documentar isso no modelo de análise? Só para ter o gosto de ouvir o programador perguntar: “devo sempre considerar 10% ou tem algum caso que ainda vale 20%”?

Muito mais claro, resumido e conciso seria documentar que o sistema “deve considerar multa de 10%”. Se a intenção é documentar a história, existem locais melhores para isso, como a tabela de histórico da capa, o histórico no sistema de versionamento ou uma ata de reunião.