Por que o Eidos existe

O problema

Pergunte a um time o que ele está construindo e você recebe quatro respostas, nenhuma escrita em um só lugar. O ticket fechou há dezoito meses. A página da wiki estava certa na semana em que foi escrita. A decisão de não cobrir um caso foi tomada em voz alta, e a pessoa que se lembra dela foi embora. O código diz o que a coisa faz hoje, não o que ela deveria ser.

Então a resposta honesta a “o que isto deveria ser?” é uma reunião.

Por que os tickets não dão conta

Uma tarefa descreve trabalho. Tem um responsável, uma estimativa e um estado que vai de aberto a fechado. O propósito dela é deixar de importar. Quando o trabalho é entregue, tudo o que o ticket registrava sobre o produto envelhece no mesmo instante.

Um Blueprint (o plano) descreve uma parte do seu produto. É escrito antes de o trabalho começar, corrigido enquanto o trabalho acontece e continua exato depois. Não tem fim.

É por isso que o Eidos proíbe campos de acompanhamento de trabalho: nada de sprint, estimate ou assignee. Acrescente-os e um Blueprint vira uma tarefa e apodrece no mesmo calendário. Em vez disso, linke para o seu gerenciador de tarefas.

O que o Eidos faz a respeito

Guarda a resposta a “o que é esta coisa” como markdown, no repositório, ao lado do seu produto, revisado nos mesmos pull requests.

Ao lado do seu produto, então está na frente das pessoas que, de outro modo, adivinhariam.
No git, então cada mudança tem autor, data e diff. O Eidos se apoia nesse histórico em vez de inventar a própria trilha de auditoria.
Markdown puro, então uma pessoa e um agente de código leem o mesmo arquivo. Duas fontes de verdade é como a deriva começa.

Por que uma pessoa precisa escrevê-lo

Uma spec é uma verificação do código. Uma verificação só funciona se vier de outro lugar.

Deixe um agente escrever a spec, depois o código, depois verificar o código contra a própria spec. Tudo bate. Nada foi verificado: duas saídas de um mesmo processo corroborando uma à outra não dizem nada sobre nenhuma das duas.

Um Blueprint vale exatamente a intenção humana que foi posta nele. Um sem nenhuma é pior do que nenhum Blueprint, porque carrega a autoridade de estar escrito.

Quando não usar o Eidos

Se você vai ser totalmente autônomo, sem revisão e com o agente escolhendo a direção, não escreva Blueprints. Eles acrescentam cerimônia, não correção. Deixe o código ser a fonte de verdade, porque ele já é. Para um protótipo ou algo descartável, essa é a decisão certa.

O Eidos é para o caso em que alguém responde pelo que a coisa é: uma pessoa que precisa defender uma decisão de escopo, ou explicar daqui a um ano por que ela não cobre um caso que alguém deu por coberto.

O que ele não é

Não é uma ferramenta de gestão de projetos. Responde a “o que é isto”, nunca a “como está indo”.
Não é um gerador de documentação. Nada é derivado do código. Uma pessoa decidiu algo e escreveu.
Não é um formulário para preencher. Se um Blueprint se lê como texto de enchimento, remodele-o até que se leia como se alguém o tivesse escrito.
Não é uma estrutura rígida. O padrão não nomeia nenhuma coleção, template (modelo) ou seção. O seu Framework (a estrutura) nomeia tudo.

Quem o sustenta

As pessoas donas do produto: sustentam a intenção, o escopo e as decisões, seja qual for o papel de cada uma. Uma raiz sem dono vira uma wiki com formatação melhor: todo mundo edita, ninguém decide, e os non-goals se esvaziam em silêncio, porque dizer não exige autoridade.