Cosa i Ticket Non Sanno Fare

I ticket tracciano il lavoro. Sono pessimi per conservare la conoscenza. Un ticket che dice "migra il servizio di autenticazione al nuovo formato token" cattura cosa deve succedere e perché — ma la decisione architetturale risultante, la specifica del formato token e la strategia di migrazione non appartengono al ticket. Appartengono alla documentazione che sopravvive al ciclo di vita del ticket.

Il modo di fallire è familiare: un team usa i ticket come base di conoscenza, e sei mesi dopo, trovare la decisione sulla migrazione dell'autenticazione richiede di cercare tra 2.000 ticket chiusi con parole chiave che corrispondono a dozzine di risultati non correlati. La decisione è lì da qualche parte — sepolta in una descrizione, un commento o un allegato — ma non è trovabile in un tempo ragionevole.

I ticket sono effimeri per design. Rappresentano un'unità di lavoro con un inizio, una fine e uno stato. Le decisioni architetturali, i contratti API, le procedure dei runbook e le guide di onboarding sono conoscenza persistente che necessita di una casa persistente: una wiki, una directory /docs nel repository, un file ADR (Architecture Decision Record). Il ticket può linkare al documento. Il documento non dovrebbe vivere dentro il ticket.

Un thread di 30 commenti su un ticket è una conversazione che avrebbe dovuto avvenire altrove. I ticket sono strumenti di coordinamento — rispondono a "cosa deve succedere?" e "è fatto?" Non sono il mezzo giusto per dibattiti di design, negoziazioni sui requisiti o sessioni di troubleshooting.

Quando un ticket diventa un thread di chat, tre cose vanno storte. Primo, il rapporto segnale-rumore crolla: i requisiti effettivi sono sepolti tra aggiornamenti di stato, domande tangenziali e ping "ci sono novità?". Secondo, la conversazione non è visibile alle persone che non stanno seguendo quel ticket — una decisione di design presa in un commento del ticket non appare nel canale Slack del team, nelle note delle riunioni o nella documentazione. Terzo, i metadati del ticket (stato, assegnatario, data di scadenza) si disconnettono dalla realtà di uno scope ancora in evoluzione.

La discussione appartiene agli strumenti di discussione: thread Slack con un riepilogo riportato nel ticket, documenti di design linkati dal ticket, o una chiamata di 15 minuti con note catturate nella descrizione. Il ticket è la landing page per un pezzo di lavoro, non la trascrizione di ogni conversazione a riguardo.

Un backlog non è un parcheggio per idee — ma la maggior parte dei team lo tratta come tale. Ogni richiesta di funzionalità, bug minore, "sarebbe bello avere" e "dovremmo probabilmente farlo un giorno" ottiene un ticket, e quel ticket rimane intoccato per mesi. Il backlog cresce. Nessuno lo pota. Alla fine hai 800 ticket e nessun modo per distinguere i 30 che contano dai 770 che non contano.

I backlog stagnanti comportano costi reali. Gli sviluppatori perdono tempo scorrendo ticket morti nella pianificazione dello sprint. I nuovi membri del team non riescono a capire quali ticket sono attuali e quali sono fossili di due pivot di prodotto fa. Le ricerche restituiscono rumore. Il backlog diventa un monumento che induce senso di colpa al lavoro che il team non farà mai — e ogni sguardo ad esso mina la fiducia nel processo di pianificazione.

L'igiene del backlog è una disciplina, non una pulizia una tantum. Una cadenza sana: una volta al mese, rivedi ogni ticket più vecchio di 90 giorni. Se non è stato prioritizzato in tre mesi, o non è abbastanza importante da fare o non è abbastanza ben definito da stimare. Chiudilo. Se conta, tornerà — e quando lo farà, tornerà con contesto fresco e priorità attuali.

L'istinto è mantenere i ticket aperti "per ogni evenienza". Quell'istinto è sbagliato. Un ticket chiuso non è cancellato — è ricercabile, linkabile e riapribile. Chiuderlo significa solo che il team è onesto su cosa è effettivamente nello scope. Un backlog di 50 ticket che riflette priorità reali è infinitamente più utile di un backlog di 800 ticket che riflette ogni idea che chiunque abbia mai avuto.