21. Projetos que não são software

Depois deste capítulo você consegue conduzir uma proposta, uma análise, um documento de passagem de projeto, uma regra de dados ou um livro como entregas, cada uma pronta só depois que cada item do Pronto quando da sua página tiver a sua evidência e tiver sido marcado pelo /apply. Você também consegue dizer por que um achado sem linha numa fila se perde.

O problema

Uma proposta, uma análise ou uma passagem de projeto tem decisões, um escopo e um momento em que está pronta, como o código. Ela costuma ser escrita sem processo nenhum: um arquivo numa pasta compartilhada, versões chamadas "final" e "final 2", achados enviados por email. Nada diz o que ainda está pendente, e nada confere se uma decisão tomada numa versão chegou à seguinte.

Uma entrega é qualquer coisa com valor que cabe numa página

O capítulo 12 definiu uma entrega como a menor mudança que tem valor, e nada nessa definição diz código. O formato da página se lê igual para um documento:

• Objetivo. O que o leitor do documento consegue fazer depois de lê-lo.
• Comportamento. O que o leitor consegue fazer, uma linha cada, cada linha uma checagem que uma pessoa faz lendo ou experimentando.
• Contrato. A estrutura do documento: as suas seções, o seu formato, os fatos que ele precisa trazer.
• Fora do escopo. O que o documento não cobre, e onde isso fica.
• Pronto quando. Uma lista das checagens que provam que está pronto, umas feitas por uma máquina, outras por uma pessoa lendo ou experimentando; o /apply marca cada uma quando a sua evidência está na página.

Uma página para a biblioteca de empréstimos da Parte I, escrita para este capítulo:

# guia-do-bibliotecario

**Objetivo.** Um bibliotecário novo empresta e recebe de volta um
exemplar no primeiro dia, com este guia e sem treinamento.

**Comportamento.**
* Um bibliotecário que nunca usou o sistema empresta um exemplar seguindo
  o guia.
* Um bibliotecário encontra, pelo sumário, o que dizer a um membro
  recusado.

**Contrato.**
Seções: Emprestar, Receber de volta, Recusas.
Recusas lista cada membro de RecusaDeEmprestimo com a mensagem que o
membro vê.
Markdown em guia/, e um PDF gerado a partir dele.

**Fora do escopo.**
* Gerenciar membros: tem o seu próprio guia, `guia-do-administrador`.

**Pronto quando.**
* [ ] Cada membro de RecusaDeEmprestimo aparece em Recusas.
* [ ] Uma pessoa que nunca usou o sistema empresta um exemplar só com o
      guia.
* [ ] O PDF é gerado.

O /apply escreve o guia como escreveria código: segue a página e roda o que uma máquina consegue conferir (o PDF é gerado, cada recusa está listada). O segundo item é uma checagem manual, e só uma pessoa consegue fazê-la: alguém que nunca usou o sistema tenta emprestar um exemplar só com o guia. Enquanto isso não acontecer, a entrega não está pronta, por mais verdes que estejam as checagens da máquina, e o /apply não move a página deixando esse item para marcar depois. Até o relato chegar, o /apply para como o capítulo 13 diz: a página fica em work/ e a linha da entrega na fila fica [?], com resume: apply e o relato que ela espera. Quando a pessoa relata que um bibliotecário novo emprestou um exemplar só com o guia, o /apply retomado escreve esse relato na página como a evidência do item, marca-o junto com os outros dois, e move a página para work/done/. Se o bibliotecário travou, o guia está errado onde ele travou: a pessoa diz onde, o /apply o corrige, e a checagem é feita de novo.

Os documentos do Caso A

No Caso A, um projeto para um cliente em uma plataforma low-code, o Microsoft Power Apps com o Copilot Studio, a passagem do projeto foi um conjunto de entregas. Um desenho da solução, um guia de instalação em três formatos, um documento de passagem e uma apresentação, um pacote de evidências indexado pelos critérios de aceite, um readme do repositório e um registro de trabalho tiveram cada um uma linha na fila e uma página, e cada um passou pelo /propose e pelo /apply como código. O pacote de evidências mostra o Contrato como estrutura: indexado pelos critérios de aceite, ele deixa o cliente conferir a entrega critério por critério e encontrar a prova de cada um.

Algumas entregas não produzem nada além da resposta escrita de uma pessoa. A página de uma entrega de pergunta diz o que é perguntado, a quem, e o que cada resposta possível desbloqueia, e ela está pronta quando a resposta chega (capítulo 20).

Este livro também roda no kit: uma página por capítulo em work/, uma fila de marcos no docs/06, e make verify, que confere a paridade das duas edições, as regras de prosa e uma varredura contra a lista de exposição. Um capítulo está pronto quando essas checagens estão verdes e o autor aprovou cada trecho sobre um caso privado.

Trabalho com dados como entregas

As regras de segurança de um banco de dados decidem quem pode ler ou escrever cada linha, e são trabalho com valor como uma tela. No Ninjobs, seis das suas 93 páginas concluídas mudaram só regras do banco de dados, e nada mais. Uma dessas regras impede o cliente de escrever enquanto a exclusão de uma conta está pendente; ela mora no próprio banco de dados, como uma regra de acesso, e o teste das regras de acesso do projeto a prova (o capítulo 13 conta o que a construção dela encontrou).

Uma regra no banco de dados vale para todo cliente que um dia falar com ele, e o teste dela é o Pronto quando que a prova.

O Caso B, o contraste

O Caso B é a proposta de uma consultoria para o programa de adoção de um cliente, e ele não rodou no processo. Uma análise da proposta foi escrita com uma disciplina deste livro: cada número trazia a sua procedência, se vinha da proposta, de uma medição, de uma estimativa ou da experiência. Ela encontrou seis falhas. Entre elas, a proposta nomeava a ferramenta errada, um risco contratual, e fixava um escopo sem fixar quanto trabalho esse escopo cobria, o que a deixava aberta a um crescimento que ninguém pagaria.

Os achados não tinham linha na fila nem página para carregá-los. Dois dias depois, a versão seguinte da proposta ainda continha pelo menos um deles. A análise estava certa, e estar certa não bastou: cada achado precisava de uma linha, e de uma página cujo Pronto quando dissesse "a próxima versão nomeia a ferramenta certa", para que a falha ficasse aberta à vista de todos até uma pessoa conferir a versão seguinte e o item ser marcado com base nessa evidência.

O que o time ganha

Um só processo para todo tipo de trabalho que o time faz, então a mesma fila, a mesma página e a mesma revisão carregam código, documentos, perguntas e regras de dados. No Caso A, cerca de 16 das suas 73 linhas concluídas foram perguntas a pessoas ou documentos, e cada uma passou pelos mesmos dois comandos que o código do projeto.

Pontos-chave

• Uma entrega é qualquer coisa com valor que cabe numa página, seja código ou não.
• Para um documento, o Comportamento é o que o seu leitor consegue fazer, o Contrato é a sua estrutura, e o Pronto quando é uma lista de checagens de máquina e checagens manuais.
• Uma checagem que só uma pessoa consegue fazer continua sendo da pessoa; o /apply registra o que ela relata e marca cada item, e nunca um sem a sua evidência.
• Uma pergunta a uma pessoa também é uma entrega, pronta quando a resposta chega.
• Uma regra do banco de dados é uma entrega com um teste, garantida onde todo cliente a encontra.
• Dê uma linha a cada achado, ou ele se perde.