Idea principale

Ogni scheda di un repertorio di prodotto porta un diario in cui si aggiungono voci senza mai correggere le precedenti. Una voce che cita una versione del codice segnala che il prodotto è cambiato. Una voce che non ne cita nessuna segnala altro: è la nostra comprensione a essere cambiata, non il software.

La distinzione sembra minore nel momento in cui la si scrive. È lei che permette, sei mesi dopo, di rispondere a una domanda che nessuno sa trattare in altro modo: si è corretta una scheda, o è il prodotto a essere evoluto? Senza di lei, i due movimenti si confondono in un unico «aggiornato il».

Il meccanismo di manutenzione si regge su di essa: la versione di riferimento fa da cursore e dà, con un comando, la lista di ciò che è cambiato nel prodotto dall'ultimo aggiornamento — quindi la lista di ciò che resta da registrare.

Perché è importante

Separa due forme di obsolescenza che richiedono interventi diversi. Una scheda in ritardo sul prodotto si recupera meccanicamente, rileggendo le fonti della nuova versione. Una scheda corretta perché si era capito male solleva una domanda: cosa ci aveva tratti in inganno, e quella causa è scomparsa?

Permette anche di giudicare l'affidabilità di una descrizione: una scheda il cui diario contiene solo correzioni di comprensione è stata scritta troppo in fretta.

Sfumature e limiti

Il meccanismo presuppone che una versione del prodotto sia citabile — un repository, un numero di release. Su un sistema senza un riferimento di versione netto, la distinzione diventa dichiarativa e si logora.

E il diario in sola aggiunta cresce senza limiti: oltre un certo volume bisogna sapere cosa farne, ed è un problema che questa nota non risolve.

Domande aperte

• Con quale ritmo aggiornare la versione di riferimento, sapendo che ogni rinvio allunga la lista di ciò che bisognerà registrare tutto in una volta?