Delimitando escopo com não-objetivos

O Eidos dá esse status a exatamente uma seção. Vale entender por quê, porque ela é também a seção mais fácil de deixar vazia.

Por que os não-objetivos fazem o trabalho

Uma lista do que algo faz não tem limite. Sempre há mais um comportamento que você poderia acrescentar, e nada na lista te diz onde parar. Duas pessoas podem ler o mesmo conjunto de critérios de aceitação e discordar sobre se uma funcionalidade está no escopo, porque os critérios não dizem nada sobre a fronteira.

Uma lista do que algo não vai fazer é uma decisão. Ela tem autor, data e diff. Dá para apontar para ela numa revisão. Ela responde à pergunta que de fato custa dinheiro seis meses depois: “peraí, isso não cobria X?”.

Veja o não-objetivo da spec de exemplo:

## Out of Scope

- Cross-account resume. A shared TV is one device, not one person.

Essa única linha faz três coisas que nenhuma lista de comportamentos consegue. Ela impede que um pedido de funcionalidade plausível seja tratado como um bug. Ela registra o raciocínio, para que a próxima pessoa consiga ver se o raciocínio ainda vale. E ela encerra uma discussão antes que ela aconteça, por escrito e com um responsável associado.

Escreva-a em segundo lugar

O instinto é escrever os não-objetivos por último, quando o Blueprint já está completo no resto. Isso é ao contrário, e produz seções vazias.

Escreva-a logo depois da seção de abertura:

Intent: por que isto existe, e quem tem o problema.
Out of Scope: o que ele deliberadamente não vai fazer.
Todo o resto.

A razão é que os não-objetivos ficam mais difíceis de enxergar depois que você escreveu os comportamentos. A essa altura você já vem pensando em termos do que a coisa faz, e a fronteira ficou invisível. Escreva-a enquanto a forma do problema ainda está à vista.

O que entra

Funcionalidades adjacentes que você descartou deliberadamente, com o motivo.
Casos que você decidiu não cobrir: um tipo de usuário, um dispositivo, uma localidade.
Coisas que um leitor razoável presumiria incluídas. Essas são as valiosas.
Fronteiras com outros Blueprints, de preferência como link: “Ranking é problema de Search Results, não deste.”

O que não entra

“Não na v1.” Isso é um cronograma, não uma decisão de escopo, e é acompanhamento de trabalho, que apodrece. Se está genuinamente fora, diga isso e por quê. Se é genuinamente para depois, o lugar é um documento de nível superior tipo Roadmap.

“Seria bom ter.” Ou está prometido ou não está. Não-objetivos são para o não.

Coisas que ninguém jamais presumiria. Uma lista de cem não-objetivos se lê como nervosismo e esconde os três que importam.

Continua não sendo uma barreira dura

A convenção termina com uma ressalva que importa: continua não sendo uma barreira dura.

Um Blueprint com a seção de não-objetivos vazia é trazido à tona, sinalizado primeiro entre as seções que faltam e oferecido, não recusado. Isso é portabilidade acima de prescrição se aplicando à seção com que o padrão mais se importa. O Eidos percebe; ele não bloqueia o seu commit.

O que é o design certo. Um validador que recusa arquivos acaba contornado, e um validador contornado não sinaliza nada.

Onde um flavor mais leve a mantém

Olhe o que o menor flavor da semente software retém:

`spec.micro` mantém	`spec.micro` descarta
Intent	Implementation Notes
Assumptions	As subcategorias de AC
Open Questions	Dependencies
Behaviors & Acceptance Criteria	Testing
Out of Scope	Constraints & Decisions

Testing e Dependencies podem esperar até a unidade se firmar. Escopo não, então micro carrega Out of Scope até no seu tamanho mínimo. Quando você desenhar o seu próprio flavor leve, mantenha a mesma regra: a seção de não-objetivos nunca é a que você corta.

Quando dizer não é o trabalho de alguém

Os não-objetivos são o ponto em que o papel de Framework Owner deixa de ser organizacional e passa a ser estrutural. Acrescentar um comportamento é uma decisão que qualquer um pode defender; tirar um do escopo exige autoridade.

Uma raiz sem dono claro vai acumular comportamentos e perder não-objetivos, porque ninguém se sente no direito de escrever os segundos. Esse é o modo de falha a vigiar, e ele aparece no diff antes de aparecer no produto.

A seguir

Dando forma ao seu Framework
Papéis e o ator: quem decide.