O custo da ambiguidade
«Que o utilizador possa exportar os seus dados.» Em que formato? Todos os dados ou um período? Qualquer utilizador o pode fazer? E se forem milhões de linhas? Cada uma destas perguntas tem uma resposta, e se não for escrita antes, é decidida por quem programa, sem o saber, às onze da noite.
Depois chega a revisão, a resposta não era a esperada e refaz-se. Esse ciclo, repetido dezenas de vezes, é a maior parte do tempo perdido num projeto de software.
O que contém uma especificação útil
Não é preciso um documento longo. São precisas cinco coisas:
O problema. Para quem, o que lhe acontece hoje e porque importa. Um parágrafo.
O âmbito. O que a aplicação vai fazer, em frases concretas.
O que fica de fora. É a parte mais esquecida e a que evita mais discussões. Escrever «não inclui exportação para PDF» fecha uma conversa antes de começar.
Os critérios de aceitação. Como se saberá que está terminado, em termos verificáveis: «exporta até um milhão de linhas em menos de um minuto em formato CSV».
Os requisitos de qualidade. Disponibilidade, segurança, custo: o que ninguém diz mas todos esperam (vimo-lo na série de arquitetura).
A especificação como contrato vivo
- É a porta de aprovação de entrada na construção: sem especificação aprovada, não se começa.
- Versiona-se com o código, no mesmo repositório.
- Muda-se, mas por escrito. Se durante a construção algo mudar, atualiza-se primeiro a especificação e depois o código. Assim nunca há duas verdades.
- Os critérios de aceitação transformam-se em testes, que são os que decidem a porta de aprovação de aceitação.
Com a especificação aprovada, a aplicação pode nascer. E convém que nasça sempre igual.
Como o aplicamos: Engenharia de Plataforma.