Anatomia di un Buon Ticket

La maggior parte dei ticket è scadente. Sono titoli vaghi — "correggere bug login," "aggiornare dashboard," "lavoro backend" — senza descrizione, senza criteri di accettazione e senza contesto per chiunque altro oltre alla persona che li ha scritti. Questi ticket creano l'illusione di tracciare mentre in realtà non tracciano nulla di utile.

Un buon ticket ha tre parti:

• Titolo come risultato. Il titolo dichiara cosa sarà vero quando il lavoro sarà completato, non quale attività avverrà. "Gli utenti possono reimpostare la password via email" è un risultato. "Lavorare su roba password" è attività. La differenza conta perché i titoli orientati al risultato sono testabili — puoi guardare il lavoro finito e chiedere "questo è vero?"
• Descrizione come perché. La descrizione spiega perché questo lavoro è importante e fornisce abbastanza contesto perché qualcuno non familiare possa comprendere la decisione. Non un romanzo — due o tre frasi che rispondono a "perché ora?" e "qual è l'impatto sull'utente?"
• Criteri di accettazione come cosa. Una breve lista di condizioni concrete e testabili che definiscono "fatto." Non "dovrebbe funzionare bene" — ma "l'endpoint restituisce un 200 con un token valido, un 401 con credenziali scadute e un 429 dopo 5 tentativi falliti in 60 secondi."

Il test per un buon ticket è il test di presa in carico: potrebbe un ingegnere che non era nella riunione in cui questo è stato discusso prenderlo in carico e consegnarlo senza fare domande di chiarimento? Se la risposta è no, il ticket non è completo — è un segnaposto.

I criteri di accettazione sono la parte più saltata di un ticket e la più costosa da saltare. Senza di essi, "fatto" è qualunque cosa l'ingegnere che ci ha lavorato pensi significhi — che potrebbe non corrispondere a ciò che il product manager si aspettava, a ciò contro cui il QA testerà, o a ciò di cui il cliente ha effettivamente bisogno.

Buoni criteri di accettazione sono concreti e testabili. "La ricerca dovrebbe essere veloce" non è un criterio di accettazione — è una speranza. "I risultati di ricerca vengono restituiti in meno di 200ms per query fino a 1.000 record" è testabile. "Il form dovrebbe gestire gli errori con eleganza" è vago. "Il form visualizza un messaggio di errore inline rosso quando il campo email è vuoto e l'utente clicca Invia" è abbastanza specifico da costruire e verificare.

I criteri di accettazione dovrebbero essere concordati prima che il lavoro inizi, non scritti dopo. Quando un ingegnere e un product manager si allineano sui criteri prima della prima riga di codice, si stanno allineando sullo scope. Senza quell'allineamento, l'ingegnere costruisce ciò che ha capito, il PM si aspettava qualcosa di diverso, e il ticket rimbalza indietro — costando tempo a entrambi ed erodendo la fiducia. Scrivere i criteri di accettazione in anticipo richiede 10 minuti. Rilavorare una funzionalità fraintesa richiede giorni.

La descrizione è la fonte di verità. I commenti sono la conversazione su di essa. Mescolarli è il modo in cui i ticket diventano illeggibili.

La descrizione dovrebbe contenere tutto ciò di cui qualcuno ha bisogno per comprendere il lavoro: il contesto, i requisiti, i criteri di accettazione e qualsiasi link rilevante. Viene scritta una volta (e aggiornata se lo scope cambia). È la parte che leggi per prima quando prendi in carico un ticket, e dovrebbe rispondere alle tue domande senza richiedere di scorrere attraverso 47 commenti.

I commenti sono per la discussione che avviene durante il lavoro: domande di chiarimento, negoziazioni di scope, aggiornamenti di stato, feedback di revisione. I commenti sono solo in aggiunta e cronologici — catturano la conversazione, non la conclusione. Quando un thread di commenti risolve una domanda che cambia i requisiti, la risposta torna nella descrizione. La descrizione viene modificata; il commento rimane come traccia di audit di come è stata raggiunta la decisione.

I team che scaricano tutto nei commenti finiscono con ticket dove i requisiti effettivi sono sepolti nel commento #23, incastrati tra un aggiornamento di stato e una reazione emoji. L'ingegnere che prende in carico il ticket deve leggere l'intero thread per ricostruire lo stato attuale. Questo non è coordinamento — è archeologia.