Issue triage: severità, priorità, proprietario

In parole semplici

Un issue tracker pieno di ticket senza categoria è una discarica. Il triage è il processo che ad ogni ticket assegna: severità, priorità, proprietario, scadenza. Senza triage, tutto è importante; quando tutto è importante, niente lo è.

Parole nuove

• triage: processo di classificazione dei ticket (dal francese “scegliere”).
• severità: impatto del bug (tecnico, utente).
• priorità: urgenza di lavorarci.
• owner / assignee: persona responsabile del fix.
• due date / SLA: scadenza, accordo sui tempi.

Cosa impari

• Distinguere severità da priorità (di nuovo, perché ci si casca sempre).
• Assegnare priorità con criteri oggettivi.
• Tenere una coda di lavoro che riflette le decisioni di triage.

Severità: quattro livelli

Severità	Definizione	Esempio
critica	sistema inutilizzabile, perdita dati, vulnerabilità	crash, leak credenziali
alta	funzionalità chiave compromessa, niente workaround	checkout impossibile
media	funzionalità secondaria, workaround possibile	export PDF rotto, JSON ok
bassa	difetto cosmetico, edge case	tooltip mal posizionato

Severità è tecnica/oggettiva. La decide chi capisce l’impatto.

Priorità: tre o quattro livelli

Priorità	Definizione
P0 (subito)	va sistemato adesso, sospende altro lavoro
P1 (sprint)	va sistemato in questo sprint
P2 (backlog vicino)	nelle prossime 2-4 settimane
P3 (backlog)	quando capita

Priorità è business. La decide product + tech.

Severità vs priorità: la classica confusione

• Bug severità critica ma bassa priorità: vulnerabilità in feature usata da 3 utenti l’anno.
• Bug severità bassa ma priorità alta: errore di copyright nel piè di pagina prima di un keynote.

Tenerle separate è essenziale: comunicano cose diverse a pubblici diversi.

Owner unico

Ogni issue ha un owner. Non due, non “il team”. Una persona responsabile di:

• Indagare o delegare con criterio.
• Tenere aggiornato lo stato.
• Chiudere quando risolto.

Più owner = nessun owner. Diffusione di responsabilità è già un bug di processo.

SLA: accordo sui tempi

Per priorità alte è utile fissare una scadenza informale (SLA):

• P0: contenimento entro 4 ore, fix entro 24.
• P1: fix entro 5 giorni lavorativi.
• P2: fix entro 4 settimane.
• P3: nessuna SLA.

Le SLA aiutano a misurare: stiamo rispettando i tempi che ci diamo? Se no, perché?

Triage operativo: la matrice

Tieni una tabella o una vista filtrata:

ID	Titolo	Sev	Pri	Owner	SLA	Stato
#142	Carrello non persiste	alta	P1	Carlo	5 gg	indagine
#143	Tooltip sfasato	bassa	P3	–	–	backlog
#144	500 su POST utenti	critica	P0	Anna	4 h	fix
#145	Export PDF	media	P2	–	4 sett	backlog

La matrice dice cosa fare adesso: P0 prima, P1 dopo, P2/P3 quando finiti i precedenti.

Quando rifare il triage

• Settimanalmente (anche solo dieci minuti).
• Quando un incidente cambia il quadro (nuova P0).
• Quando lo SLA si sta avvicinando.

Un ticket “fermo da 6 mesi in P1” è un sintomo: o non è P1 (declassa a P2/P3), o non ha owner (assegna), o non è davvero un bug (chiudi come limitazione).

Anti-pattern: tutto urgente

Sintomi:

• Metà dei ticket in P0.
• Nessuno rispetta gli SLA.
• Team in modalità reattiva permanente.

Cause:

• Mancanza di criteri condivisi per priorità.
• Pressione di stakeholder che chiedono “subito” per default.
• Paura di declassare.

Antidoto:

• Definire criteri scritti.
• Forzare distribuzione: max N ticket in P0 contemporaneamente.
• Comunicare i declassamenti con motivazione.

Esercizio guidato

Prendi un issue tracker pubblico (un progetto open source su GitHub). Scegli dieci issue aperte.

1. Leggi titolo e descrizione.
2. Assegna severità, priorità (immaginando di essere maintainer), owner ipotetico.
3. Annota i criteri che hai usato.
4. Confronta con le label reali del progetto. Discrepanze?

Errori frequenti del principiante

• Mettere tutto P0 per paura di sbagliare.
• Severità in base alla “voce” del segnalante: chi urla di più ottiene “alta”.
• Owner = “team”: nessuna responsabilità.
• Triage solo in crisi: serve un ritmo regolare.