Workflow Jira per lo sviluppo software: configurazione, esempi e best practice per il 2026

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Un workflow Jira per lo sviluppo software è il percorso che ogni storia, bug e task segue dall’idea alla produzione. Quando questo percorso corrisponde al modo in cui il team lavora davvero, la board diventa un’immagine affidabile delle consegne: chiunque vede cosa è bloccato, cosa attende la revisione e cosa è pronto per il rilascio. Quando non corrisponde, gli sviluppatori passano il tempo a trascinare card, i manager inseguono aggiornamenti di stato e i report non dicono nulla di utile.

La maggior parte dei progetti Jira che ereditiamo dai clienti soffre del secondo problema. I workflow crescono uno stato alla volta finché nessuno sa più spiegarli, e lo stesso tipo di issue si comporta in modo diverso da un team all’altro. Quando prendiamo in carico le consegne con i nostri team di product engineering gestiti, riordinare il workflow Jira di sviluppo software è di solito uno dei compiti delle prime due settimane, perché ogni metrica successiva dipende da questo.

Questa guida spiega cos’è un workflow Jira, quale workflow è adatto alla maggior parte dei team software, cinque esempi da copiare, come configurarne uno, come automatizzare le transizioni da GitHub, GitLab o Bitbucket, e quali best practice ed errori decidono se Jira vi aiuta o vi rallenta. Vale per Jira Cloud e Jira Data Center.

Cos’è un workflow Jira per lo sviluppo software?

Un workflow Jira è l’insieme degli stati in cui può trovarsi una issue e delle transizioni che la spostano dall’uno all’altro. Nello sviluppo software modella il ciclo di vita di un elemento di lavoro: dal backlog, attraverso la scrittura del codice, la code review e i test, fino al rilascio. Ogni progetto Jira usa un workflow, che il team lo abbia progettato o che abbia accettato quello predefinito.

Il workflow non è la board. Il workflow definisce quali stati esistono e quali spostamenti sono consentiti; la board è una vista che associa questi stati a colonne. Potete avere più board sullo stesso workflow e nascondere o unire stati in una colonna senza modificare il workflow sottostante.

Gli elementi costitutivi di un workflow Jira

Ogni workflow Jira è composto da sei elementi; capirli rende molto più semplice progettarne uno pulito.

I progetti company-managed espongono direttamente condizioni, validatori e post function. I progetti team-managed offrono regole di transizione più semplici per limitare, validare e attivare azioni sulle transizioni. Entrambi possono essere estesi con Jira Automation.

Schemi di workflow e tipi di issue

Uno schema di workflow (workflow scheme) associa i tipi di issue ai workflow all’interno di un progetto. È così che un progetto può usare un workflow per storie e task e uno diverso per i bug. Condividere uno schema tra più progetti è lo strumento principale per mantenere coerenti molti team, come vedremo nella sezione sulla scalabilità più avanti.

Qual è il workflow Jira migliore per lo sviluppo software?

Il workflow Jira migliore per lo sviluppo software è il più semplice che mostri ancora dove il lavoro resta in attesa. Per la maggior parte dei team di prodotto significa sei stati: Backlog, Selected for Development, In Progress, In Review, In QA e Done. Ogni stato risponde a una sola domanda sul lavoro e ha un responsabile e una regola di uscita condivisi da tutti.

Due regole fanno funzionare questo workflow. Primo, consentite i ritorni indietro: revisione e QA devono poter riportare una issue in In Progress senza l’aiuto di un amministratore. Secondo, tenete “Blocked” fuori dall’elenco degli stati e usate invece un flag. Uno stato di blocco nasconde il punto in cui il lavoro si è fermato, mentre un flag mantiene la issue nella sua colonna reale e segnala comunque il problema.

Quanti stati dovrebbe avere un workflow Jira?

Un team software tipico ha bisogno di 5–7 stati. Meno di cinque di solito nasconde la revisione o i test, così il lavoro appare “in corso” per giorni senza alcun segnale sul perché. Più di sette di solito significa stati che descrivono persone o reparti invece della condizione del lavoro. Un test utile: se il team non sa spiegare uno stato in una frase, oppure nessuna issue vi è rimasta nell’ultimo mese, eliminatelo.

5 esempi di workflow Jira per lo sviluppo software

Tipi di lavoro diversi richiedono flussi leggermente diversi, ma dovrebbero condividere la stessa spina dorsale. Questi cinque esempi di workflow Jira coprono quasi ogni team software: copiate quello più vicino al vostro processo e modificate solo ciò che sapete giustificare.

1. Workflow di base per team piccoli

To Do → In Progress → In Review → Done. È vicino al workflow predefinito di Jira e funziona per team da due a cinque sviluppatori che testano il proprio codice o rilasciano dietro feature flag. Aggiungete uno stato di QA non appena entra un tester dedicato, altrimenti i test diventano invisibili.

2. Workflow Scrum

Backlog → Selected for Development → In Progress → In Review → In QA → Done. Il perimetro dello sprint vive in Selected for Development e la sprint board mostra i quattro stati di lavoro. I report di burndown e velocity presuppongono che Done significhi “soddisfa la Definition of Done”, quindi non lasciate mai che le issue arrivino a Done prima del QA. La nostra guida allo sviluppo software con Scrum illustra i ruoli e gli eventi alla base di questo flusso.

3. Workflow Kanban

Backlog → Ready → In Progress → Review → Testing → Ready to Release → Done. I team Kanban puntano sul flusso, quindi aggiungono un buffer “Ready to Release” e impostano limiti WIP sulle colonne della board, ad esempio tre issue in corso per sviluppatore. Il cycle time e il cumulative flow diagram diventano i principali indicatori di salute. Consultate Kanban nello sviluppo software per indicazioni sui limiti WIP.

4. Workflow di bug tracking

Open → Triaged → In Progress → In Review → Verified → Closed, con resolution come Fixed, Duplicate, Cannot Reproduce e Won’t Fix. La fase aggiuntiva Triaged garantisce che qualcuno verifichi gravità e riproducibilità prima che uno sviluppatore prenda in carico il bug. Verified dovrebbe essere eseguita da chi ha segnalato il bug o dal QA, non dallo sviluppatore che lo ha corretto.

5. Workflow di funzionalità e rilascio con UAT

Idea → Discovery → Ready → In Development → In QA → UAT → Released. È adatto a epic o funzionalità rivolte al cliente per cui un referente di business deve dare l’approvazione. Spesso gira a livello di epic, mentre le storie al suo interno usano il flusso Scrum o Kanban. La fase UAT riprende il processo descritto nella nostra guida ai test di accettazione utente.

Come configurare un workflow Jira per lo sviluppo software in 8 passi

Configurare un workflow Jira richiede un pomeriggio di impostazioni, ma dovrebbe iniziare con un’ora alla lavagna. Progettate prima il flusso su carta insieme al team, poi costruitelo in Jira e infine provatelo su alcune issue reali prima di far passare tutti al nuovo sistema.

1. Mappate il processo reale. Chiedete al team come avanza davvero una storia oggi, compresi i punti di attesa. Annotate ogni passaggio di consegne: dallo sviluppatore al revisore, dal revisore al QA, dal QA al rilascio.
2. Scegliete stati, non persone. Nominate ogni stato in base alla condizione del lavoro (“In Review”), mai in base a una persona o a un team (“Da Anna”, “Backend”). Puntate a 5–7.
3. Assegnate le categorie di stato. Inserite ogni stato in To Do, In Progress o Done. Da questo dipendono i report, le roadmap e il colore della issue.
4. Disegnate le transizioni. Consentite ogni spostamento in avanti necessario e i ritorni indietro per le rilavorazioni. Evitate “qualsiasi stato verso qualsiasi stato”, salvo un reset riservato agli amministratori.
5. Aggiungete solo le regole necessarie. Quelle tipiche: un validatore che richiede una pull request collegata prima di In Review, una condizione per cui solo il QA può spostare in Done e una post function che imposta la resolution su Done e la azzera alla riapertura.
6. Create o aggiornate lo schema di workflow. Associate storie, task e sub-task al workflow principale e i bug al workflow dei bug, se lo usate. Pubblicate prima lo schema su un progetto di prova.
7. Configurate la board. Associate gli stati alle colonne, impostate i limiti WIP per Kanban e aggiungete filtri rapidi come “Flagged” o “Assigned to me”.
8. Fate un pilota, poi estendete. Eseguite uno sprint sul nuovo workflow con un solo team, raccogliete i punti di attrito, correggeteli e solo allora migrate gli altri progetti. Scrivete una guida di una pagina che spieghi ogni stato e ogni regola di uscita.

Come dovrebbe collegarsi un workflow Jira a Git, code review e CI/CD?

Un workflow Jira per lo sviluppo software dovrebbe essere guidato dagli eventi di sviluppo, non dal trascinamento manuale. Quando branch, pull request, build e deployment aggiornano automaticamente le issue, la board resta accurata e gli sviluppatori restano nel loro editor.

• Collegate tutto con la chiave della issue. Inserite la chiave, ad esempio PAY-142, nei nomi dei branch, nei messaggi di commit e nei titoli delle pull request. Jira mostrerà così sulla issue il pannello di sviluppo con branch, commit, pull request, build e deployment.
• Usate gli smart commit con moderazione. Con Bitbucket e altri strumenti collegati, messaggi di commit come PAY-142 #comment fixed rounding o PAY-142 #time 2h aggiornano Jira direttamente. Funzionano anche i comandi di transizione, ma le regole di automazione sono più facili da governare.
• Collegate GitHub o GitLab tramite le app ufficiali. GitHub for Jira e GitLab for Jira Cloud inviano a Jira i dati di sviluppo e le informazioni sui deployment, che alimentano anche la vista dei deployment e il monitoraggio dei rilasci.
• Riportate build e deployment. Quando la pipeline CI/CD pubblica lo stato di build e deployment, la issue mostra se il suo codice è in staging o in produzione, e Done può significare “distribuito” anziché “unito”.

È qui che il workflow incontra la vostra pipeline di consegna. Se la state ancora costruendo, la nostra guida alla CI/CD nello sviluppo software spiega quali fasi dovrebbero inviare aggiornamenti a Jira.

Quali transizioni del workflow Jira conviene automatizzare?

Automatizzate le transizioni che seguono un evento prevedibile e lasciate il giudizio umano dove serve una decisione. Una buona regola pratica: se la transizione avviene sempre quando accade qualcos’altro, deve occuparsene una regola; se qualcuno deve decidere, lasciatela manuale.

Mantenete manuali approvazioni, sign-off del QA e UAT. Le funzionalità di IA integrate di Atlassian ora sono in grado di riassumere le issue e suggerire i passi successivi, ma uno stato che rappresenta una decisione di qualità dovrebbe comunque essere spostato dalla persona che ne risponde. L’automazione è più efficace quando il workflow è già pulito: automatizzare un workflow disordinato rende solo il disordine più veloce.

Best practice per il workflow Jira: una checklist in 7 punti

I migliori workflow Jira condividono le stesse abitudini: pochi stati, responsabilità chiare e revisioni regolari. Usate questa checklist quando progettate un nuovo workflow o ne verificate uno esistente.

1. Limitatevi a 5–7 stati e nominateli in base alla condizione del lavoro.
2. Date a ogni stato un responsabile e una regola di uscita, scritti nella guida di una pagina del progetto.
3. Rendete esplicite le rilavorazioni con transizioni all’indietro invece di riaprire ticket o creare duplicati.
4. Usate flag ed etichette per gli stati secondari come bloccato, serve il design o in attesa del cliente, invece di stati aggiuntivi.
5. Impostate correttamente le resolution: ogni issue in Done deve avere una resolution e la riapertura deve azzerarla, altrimenti i report conteranno come completato il lavoro non finito.
6. Condividete un unico schema di workflow tra i team che costruiscono lo stesso prodotto e ammettete variazioni locali solo a livello di board.
7. Rivedete il workflow ogni trimestre usando cycle time, tempo in stato e cumulative flow diagram.

Queste abitudini contano perché l’attrito con gli strumenti costa caro. Il report State of Developer Experience di Atlassian (2024) ha rilevato che il 69% degli sviluppatori perde otto o più ore a settimana a causa di inefficienze, e processi poco chiari e incombenze legate agli stati fanno parte di questo conto. Per il quadro più ampio delle metriche da monitorare, consultate la nostra guida ai KPI dello sviluppo software e ai benchmark DORA.

Errori comuni nel workflow Jira e come correggerli

La maggior parte dei workflow Jira problematici fallisce sempre negli stessi pochi modi, e ognuno ha una correzione semplice. La tabella seguente elenca i problemi che vediamo più spesso durante gli audit dei progetti dei clienti.

Come scalare i workflow Jira su più team?

Scalate i workflow Jira con una spina dorsale condivisa e libertà locale solo dove non compromette i report. Tutti i team che lavorano sullo stesso prodotto dovrebbero usare gli stessi stati e le stesse categorie di stato, così una vista di portfolio, un piano di rilascio o una dashboard trasversale hanno lo stesso significato ovunque.

• Uno schema di workflow per linea di prodotto, condiviso da tutti i suoi progetti e gestito da un solo amministratore Jira o da un piccolo gruppo di lavoro.
• Un progetto con più board quando i team lavorano sullo stesso codebase: ogni team filtra la propria board per componente o campo team, mentre il workflow resta comune.
• Variazioni locali a livello di board: limiti WIP, swimlane e filtri rapidi possono differire da team a team senza toccare il workflow.
• Un processo di modifica: le modifiche al workflow passano da una breve richiesta motivata, vengono testate su un progetto sandbox e annunciate prima del rilascio.
• Pulizia regolare di stati inutilizzati, campi personalizzati e workflow inattivi, che rallentano Jira e confondono i nuovi membri del team.

Lo stesso principio vale quando lavorate con un partner di consegna esterno o un team esteso: deve lavorare all’interno del vostro workflow condiviso, non in uno parallelo. La nostra guida alla gestione dei team di sviluppo software illustra il ritmo operativo che lo circonda.

Come si verifica un workflow Jira? Un check-up trimestrale

Verificate un workflow Jira ogni trimestre misurando dove le issue restano in attesa, non quanti stati esistono. Tre report integrati bastano a individuare la maggior parte dei problemi e l’intero controllo richiede circa un’ora.

1. Cumulative flow diagram. Una fascia che continua ad allargarsi indica un collo di bottiglia; una fascia In Review sempre più larga, ad esempio, significa che il vincolo sono le revisioni.
2. Control chart o report del cycle time. Osservate la media e i valori anomali. Le issue che richiedono tre volte la media di solito rivelano requisiti poco chiari o dipendenze nascoste.
3. Tempo in stato. Gli stati in cui le issue restano ferme per giorni sono candidati all’automazione, ai limiti WIP o a una modifica del processo.
4. Stati e transizioni inutilizzati. Tutto ciò che non è stato usato nell’ultimo trimestre può essere rimosso.
5. Feedback del team. Chiedete quali transizioni le persone aggirano. Gli aggiramenti sono il segnale più onesto che un workflow non è più adatto.

Punti chiave

• Un workflow Jira è un insieme di stati e transizioni; la board ne è solo una vista.
• Il workflow Jira migliore per lo sviluppo software ha 5–7 stati, ciascuno con un responsabile e una regola di uscita.
• Copiate uno dei cinque modelli collaudati: di base, Scrum, Kanban, bug tracking o funzionalità con UAT.
• Usate i flag invece di uno stato Blocked e consentite sempre le transizioni all’indietro per le rilavorazioni.
• Guidate le transizioni da branch, pull request, build e deployment con Jira Automation.
• Condividete un unico schema di workflow tra i team dello stesso prodotto e rivedetelo ogni trimestre.

Domande frequenti

Pubblicato il 30 ottobre 2026. Fonti: Atlassian Support, lavorare con i workflow; Atlassian Support, smart commit; Atlassian, Jira Automation; Atlassian, State of Developer Experience Report 2024. I modelli di workflow riflettono la pratica di consegna di YuSMP Group e sono raccomandazioni, non impostazioni predefinite di Atlassian.