Um app, um serviço ou um sistema
Software@BuildableWorks/software
Frames de arquitetura, público, critérios e mercado, e specs agrupadas por domínio.
- Frames
- Specs
$ eidos install @BuildableWorks/softwareNo app: New Root, e depois escolha na lista.
Todo projeto de cliente, feito do mesmo jeito. Toda aprovação, uma versão.
Escreva o Framework (a estrutura) do seu estúdio uma vez e comece cada cliente a partir dele. O escopo fica em uma spec por entregável, com Out of Scope em todas; um pedido de mudança é uma decisão que o aprovador do cliente confirma, e o que ele aprovou é uma versão com nome, que você abre um ano depois.
Grátis para macOS, Windows e Linux. Sem conta, sem assinatura.
Parece familiar?
O escopo é o que alguém lembra de ter combinado.
A proposta está assinada e congelada. O escopo de verdade muda em calls, e-mails e tickets.
O escopo cresce um “sim, claro” por vez
Cada pequeno extra fazia sentido na call. Juntos, eles comeram a margem, e no fim ninguém concorda sobre o que estava no escopo original.
“O que foi combinado?” está enterrado
Cinco pessoas do lado do cliente podem pedir mudanças, e nenhuma tem a palavra final. A resposta está em uma thread de e-mail, ou na cabeça de quem estava na call.
Todo cliente começa do zero
Cada projeto copia o modelo do ano passado, que se desvia um pouco a cada vez. Quem passa de um cliente para outro reaprende a estrutura, e cada nova sessão de agente também.
Como se encaixa
Um Framework para o estúdio, uma raiz por cliente.
Comece pelo Framework de software e transforme-o no do seu estúdio: os frames (os enquadramentos) que o seu briefing pede, as seções que toda spec precisa ter, os seus papéis. A partir daí, todo projeto de cliente novo começa dele, no repositório daquele cliente.
- Frames
- O briefing: para quem é, o orçamento, o escopo e o cronograma, a arquitetura e o mercado.
- Specs
- Uma por entregável, agrupadas por área, com Acceptance Criteria e Out of Scope em todas.
- Decisões de escopo
- Cada pedido de mudança, feito para as specs que ele afeta, confirmado pelo aprovador que você nomeou.
- Versões
- Um nome para o commit que um cliente aprovou: a proposta, a fase, o pedido de mudança.
- Tarefas
- O trabalho de entrega em um quadro, cada tarefa apontando para a spec a que serve.
O que você mais vai usar
As peças que mantêm o escopo registrado.
- Blueprints
O seu Framework, publicado
As coleções, os templates, as propriedades e os papéis com que o seu estúdio trabalha, instalados em todo projeto de cliente novo com um comando ou um clique.
- Git
Aprovação é uma versão
Registre uma versão que nomeia o commit que o cliente aprovou, com uma tag no repositório. Abra a raiz como ela estava naquele momento, sempre que a pergunta voltar.
- Decisões
Pedidos de mudança registrados
Uma decisão do tipo Scope para cada mudança, atribuída ao aprovador do cliente. Ao confirmá-la, o nome dele e a data ficam carimbados na decisão e na spec.
- Comentários
Perguntas onde elas pertencem
Uma pergunta sobre um critério é uma conversa naquele critério, não um e-mail. Encerre-a quando estiver respondida; ela fica no arquivo.
- Backlog
A entrega ao lado do escopo
Tarefas em um quadro, cada uma nomeando a spec que entrega, exportadas para CSV ou Excel para o relatório do cliente.
- Agente de IA
Passagens de bastão que se sustentam
Um dev que entra no projeto, ou o agente de código dele, lê as specs e as decisões em vez de um mês de e-mails.
O que o cliente aprovou
Uma versão com nome para cada aprovação
Quando o cliente aprova, registre uma versão: um nome para aquele commit, com uma tag no repositório se você quiser. A proposta, a fase um e cada pedido de mudança viram linhas para as quais você pode apontar, e a verificação avisa se uma tag um dia se afastar do commit que ela nomeou.
- Registre uma versão pelo app ou com
eidos version record - As tags são criadas no seu repositório, e o Eidos nunca faz push delas por você
- Uma versão nomeia o commit; o git já guarda cada arquivo
Out of Scope, por escrito
Toda spec diz o que ela não vai fazer
Out of Scope é uma seção do template, não um detalhe de última hora, e as decisões tomadas para uma spec aparecem na própria spec. O “achei que isso estava incluído” encontra uma linha dizendo que não está, e o nome de quem concordou.
Um Framework, todos os clientes
Publique uma vez, instale em todo lugar
Mantenha o Framework em um repositório seu e instale-o de lá em cada projeto de cliente, ou comece pela configuração do último cliente sem nada do conteúdo dele. Para compartilhá-lo, publique no Registro: um pull request para o Registro no GitHub, um manifesto apontando para uma raiz com tag, e qualquer pessoa o instala como @your-studio/name.
$ eidos install your-studio/delivery@v3 --path framework
$ eidos install ../northwind/Blueprints --setup-only
$ eidos install @your-studio/deliveryComece por aqui
Comece pelo Framework de software e deixe-o com a sua cara.
Frames para o briefing e specs para os entregáveis, com Out of Scope em todo template. Molde-o nas Configurações do Framework até ele ter a cara do seu estúdio, publique, e todo cliente a partir daí começa pelo seu.
Comece o próximo cliente pelo seu próprio Framework.
Baixe o Eidos MD, transforme o Framework de software no do seu estúdio e registre a primeira aprovação como uma versão.
Grátis para macOS, Windows e Linux. Seus arquivos continuam texto simples, em uma pasta que é sua.