Giulio su LinkedIn commenta:

Nella mia esperienza, la documentazione con maggior valore è scritta prima del codice, quella in cui spieghi il contesto di riferimento, l'ambito di applicazione del sistema, l'architettura generale e il Quick start manual. È l'equivalente del TDD, anzi dell'ATDD, ma a livello dell'intero sistema è con la prospettiva di ciascun ruolo: semplice utente, amministratore, manutentore del codice, incluso il marketing. Non deve essere un ritratto, ma uno schizzo che coglie i lineamenti essenziali, che andrà rifinita ad ogni iterazione. Gran parte del suo valore è prospettico: è un esercizio di analisi e comprensione che spesso svela elementi critici del sistema. Se ricordo bene The mythical man month aveva già colto tutto questo diecine di anni fa (purtroppo non posso andare a verificarlo adesso).

Avevo cercato di dire la stessa cosa in precedenza, evidentemente senza lo stesso impatto:

Allo stesso modo trovo molto valore nella documentazione, vi dirò di più trovo molto valore nello scrivere la documentazione. È una forma di testing, spesso ci ritroviamo a scrivere documentazione prima dell’implementazione stessa. L’operazione di scrittura, comprensiva di esempi completi e snippet di codice, impone di mettersi nei panni dall’utilizzatore finale provando in prima persona l’ergonomia di quello che si sta per produrre.

Che va a braccetto con quello che scrive Giulio nel commento:

Nella mia esperienza, la documentazione con maggior valore è scritta prima del codice […] È l'equivalente del TDD […] ma a livello dell'intero sistema è con la prospettiva di ciascun ruolo

Questo per (riba)dire che nella mia esperienza la documentazione serve prima a noi che all’utente finale.