Nomear quem monta a prova da entrega e pode vetá-la

Exigir evidência é uma decisão. Montar e operar o pacote de evidências é trabalho de engenharia, com instrumentos, custo, calendário e alguém respondendo, e é dessa segunda parte que tudo abaixo trata.

Em inglês, a disciplina ganhou o nome de Validation Engineering (engenharia de validação: o fiscal que confere a obra antes da entrega), e o nome importa menos que os três atributos que a definem: um conjunto declarado de instrumentos, um dono com poder de veto e um rito com hora marcada. Sem instrumentos, a exigência de prova vira opinião sobre qualidade. Sem dono, vira lista morta. Sem rito, vira burocracia que o próximo prazo atropela. Suponha uma software house de quatro pessoas: os três atributos cabem no chapéu do líder técnico, com poder de veto escrito e uma hora fixa por semana de rito protegida no calendário.

Existe medição publicada sobre isso, e ela vale a explicação. Quando o setor compara agentes de software, usa benchmarks: conjuntos fixos de problemas reais, com a resposta certa conhecida, sobre os quais cada modelo é medido. O resultado sobe para um placar público, e é esse número que o fornecedor leva para a sua reunião.

Um grupo de pesquisadores refez a conferência de um desses conjuntos, com uma ferramenta chamada UTBoost, e encontrou 345 correções que tinham sido dadas como certas sem merecer. O motivo é o mesmo desta aula inteira: os testes que decidiam a aprovação eram frouxos demais para reprovar uma solução errada. Depois da correção, 40,9% das posições de um placar mudaram, e 24,4% em outro.

Traduzindo para a sua mesa: quatro em cada dez linhas de um ranking que fornecedores citam em proposta comercial mudaram de lugar quando alguém apertou o teste. A consequência prática reorganiza o pacote de provas, e a dedução é deste curso, a partir do mecanismo que o estudo expõe. Quando o agente consegue ler o teste antes de trabalhar, o teste vira alvo, e alvo não serve de evidência. Sobram em pé três instrumentos, justamente os que o agente não consegue mirar: um conjunto de casos retido, alguém que não escreveu o código lendo os testes, e a inspeção do caminho percorrido além do resultado final.

Do lado da manutenção, a série mais longa disponível publicamente mostra para onde a conta está sendo empurrada.

Numa única linha de orçamento, os dois achados se encontram. Mais código andando mais rápido sobrecarrega os portões de revisão, e parte do tempo economizado na geração volta como trabalho de auditoria. Este curso chama esse saldo de imposto de verificação. O nome é convenção didática nossa; nenhum relatório de mercado cunhou o termo, e vale dizer isso em voz alta quando o número for para um slide.

Tratada como etapa final, a verificação cobra esse imposto de forma desorganizada, em horas de plantão e retrabalho que ninguém contabiliza. Com instrumentos, dono e rito, o mesmo custo vira capacidade de aprovar mais rápido, porque aprovar deixa de depender de leitura integral.

Separe uma hora desta semana para duas tarefas, começando pela entrega mais recente.

1. 01Inventário de evidências: pegue a última entrega relevante gerada com apoio de agente no seu time e pontue os dez instrumentos, usando a calculadora desta aula. Termine com um número e nomeie as duas ausências de maior raio de dano.
2. 02Desenho do papel: preencha o modelo da descrição do papel para o seu contexto e leve para a pessoa que precisaria confirmar o veto por escrito.

Compare o resultado com três critérios: (a) você termina com um número, em vez de uma impressão; (b) as duas ausências priorizadas foram escolhidas por raio de dano, e você defende a ordem contra a pergunta "por que não a outra primeiro?"; (c) a descrição do papel diz explicitamente o que a pessoa veta, além do que ela constrói, porque é o campo do veto que separa o papel real do papel decorativo. Se um dos três faltar, a tarefa volta para a semana seguinte.