> Miglioramento continuo dei processi > Ciclo di vita dello sviluppo software > Jira Software > Template dei dati

Il Suo template dei dati per il ciclo di vita dello sviluppo software

Jira Software

Attributi del ciclo di vita dello sviluppo software (21) Attività del ciclo di vita dello sviluppo software (14) Guide all’estrazione (4)

Il Suo template dei dati per il ciclo di vita dello sviluppo software

Questo template offre una guida chiara alla raccolta dei dati essenziali per analizzare il ciclo di vita dello sviluppo software. Indica i principali campi da raccogliere, i passaggi fondamentali da monitorare e come estrarre concretamente queste informazioni da Jira Software. Utilizzi questa guida per preparare l’event log all’analisi con il Process Mining.

Attributi consigliati da raccogliere
Attività principali da monitorare
Indicazioni per l’estrazione da Jira Software

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il template

Attributi del ciclo di vita dello sviluppo software

Questi sono i campi dati consigliati da includere nell’event log per un’analisi completa del ciclo di vita dello sviluppo software.

5 Obbligatorio 6 Consigliato 10 Facoltativo

	Nome	Descrizione
	Attività Activity	Nome di un evento specifico o di un cambiamento di stato avvenuto nel ciclo di sviluppo di un elemento.
Descrizione Questo attributo rappresenta una fase o una tappa specifica del processo di sviluppo software. Le attività si ricavano dalle modifiche al campo di stato dell’issue Jira o da altri eventi significativi, come i commit del codice o le revisioni. Nel Process Mining, la sequenza di queste attività costituisce la mappa del processo. Analizzarle aiuta a individuare il flusso del processo, misurare la durata delle singole fasi e rilevare scostamenti dal flusso di lavoro standard, come cicli di rilavorazione o controlli di qualità saltati. Perché è importante Le attività definiscono le fasi del processo e la loro sequenza è essenziale per visualizzarne il flusso, individuare i colli di bottiglia e analizzare le variazioni. Dove reperirli In genere si ricava dai passaggi del campo 'status' nella cronologia o nel registro delle modifiche dell’issue Jira. È possibile arricchirlo anche con dati provenienti dagli strumenti di sviluppo collegati. Esempi Sviluppo iniziatoRevisione del codice completataTest di controllo qualità completatiDistribuito in produzione
	Elemento di sviluppo DevelopmentItem	Identificativo univoco di una singola unità di lavoro in Jira Software, come una story, un bug o un task.
Descrizione L’elemento di sviluppo funge da identificativo del caso e rappresenta una singola unità di lavoro, come una funzionalità, la correzione di un bug o un task. Collega tutte le attività relative a quell’elemento, dall’ideazione e pianificazione iniziali fino allo sviluppo, ai test e alla distribuzione. In Jira corrisponde in genere alla chiave dell’issue, ad esempio 'PROJ-123'. L’analisi di questo attributo consente di ricostruire l’intero ciclo di vita di ogni elemento di lavoro. È la base per creare mappe di processo, calcolare i tempi di ciclo e individuare le differenze nel percorso seguito dai vari elementi durante lo sviluppo. Perché è importante È la chiave essenziale per collegare tutte le attività di sviluppo correlate e ricostruire il percorso di un singolo elemento di lavoro dall’inizio alla fine. Dove reperirli È il campo standard 'key' dell’oggetto issue nell’API Jira Software Issue. Esempi PROJ-101CORE-5432API-789
	Ora dell’evento EventTime	Data e ora esatte in cui si è verificata una specifica attività o un evento di sviluppo.
Descrizione L’ora dell’evento è il dato temporale che registra quando si è svolta un’attività. Costituisce la base cronologica di tutte le analisi di Process Mining e permette di ordinare gli eventi di ogni caso. Questo attributo è fondamentale per calcolare tutte le metriche basate sul tempo, inclusi i tempi di ciclo, i tempi di elaborazione e i tempi di attesa tra le attività. Consente di analizzare l’andamento del processo nel tempo e aiuta a individuare quando e dove si verificano ritardi nel ciclo di sviluppo. Perché è importante Questo dato temporale è fondamentale per ordinare correttamente gli eventi e calcolare tutte le metriche basate sulla durata, indispensabili per comprendere l’efficienza del processo e individuare i ritardi. Dove reperirli Corrisponde alla data e all’ora di 'created' per ogni voce del registro delle modifiche o della cronologia di un’issue. Esempi 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
	Sistema di origine SourceSystem	Sistema da cui sono stati estratti i dati sul ciclo di sviluppo.
Descrizione Questo attributo identifica l’origine dei dati. Per questo processo il valore sarà sempre 'Jira Software', ma è utile per distinguere i dati quando nell’analisi vengono combinati più sistemi di origine. In un’architettura IT più ampia, specificare il sistema di origine rende chiara la provenienza dei dati e aiuta a gestirne la qualità e l’integrazione tra piattaforme diverse. Perché è importante Fornisce informazioni chiare sulla provenienza dei dati, fondamentali quando si integrano dati provenienti da più sistemi o per le attività di governance e audit. Dove reperirli È un valore statico da aggiungere durante l’estrazione e la trasformazione dei dati. Esempi Jira Software
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora dell’ultimo aggiornamento dei dati del processo dal sistema di origine.
Descrizione Questo attributo registra la data e l’ora dell’estrazione più recente dei dati da Jira Software e fornisce un’indicazione della loro attualità. Conoscere l’ora dell’ultimo aggiornamento è importante per valutare quanto siano aggiornate le informazioni sul processo. Aiuta analisti e utenti aziendali a verificare che i dati consultati siano attuali e indica fino a quando sono inclusi gli eventi nell’analisi. Perché è importante Indica quanto sono aggiornati i dati, un’informazione essenziale per assicurarsi che le analisi e le Dashboard riflettano lo stato più recente del processo. Dove reperirli Questo dato temporale viene generato e registrato al termine del processo di estrazione, trasformazione e caricamento dei dati (ETL). Esempi 2024-03-15T02:00:00Z2024-03-16T02:00:00Z
	Assegnatario Assignee	Utente attualmente incaricato di gestire l’elemento di sviluppo.
Descrizione L’assegnatario è la persona responsabile dell’elemento di lavoro nella fase corrente. In Jira è un campo standard che cambia quando l’elemento passa da una persona o da un team a un altro. Analizzare l’assegnatario è fondamentale per comprendere l’allocazione delle risorse, la distribuzione del carico di lavoro e i passaggi di consegne. Aiuta a capire quali sviluppatori o team partecipano alle diverse fasi, chi costituisce un collo di bottiglia e come viene distribuito il lavoro nell’organizzazione. Perché è importante Identifica l’utente o la risorsa responsabile di un’attività e consente di analizzare il carico di lavoro, gestire le risorse e comprendere i passaggi di consegne tra le persone. Dove reperirli È il campo 'assignee' all’interno dell’oggetto 'fields' nella risposta dell’API Jira Issue. Esempi Alice SmithBob JohnsonNon assegnato
	Nome del progetto ProjectName	Nome del progetto Jira a cui appartiene l’elemento di sviluppo.
Descrizione In Jira, tutti gli elementi di lavoro sono organizzati in progetti. Il nome del progetto fornisce un contesto generale e spesso corrisponde a un prodotto, un team o un’iniziativa specifici. Questo attributo è una dimensione utile per filtrare e confrontare i dati. Consente di analizzare e confrontare il processo SDLC tra progetti o prodotti diversi, facendo emergere quali sono più efficienti, quali comportano più rilavorazioni e se i team seguono varianti diverse del processo. Perché è importante Consente di segmentare l’analisi del processo per progetto, prodotto o team, confrontare le prestazioni e individuare le pratiche più efficaci. Dove reperirli È il campo 'project' all’interno dell’oggetto 'fields' nella risposta dell’API Jira Issue. Esempi Sviluppo di app per dispositivi mobiliPiattaforma principaleScienza dei dati
	Nome del team TeamName	Team di sviluppo responsabile dell’elemento di lavoro.
Descrizione Rappresenta il team agile o il team di funzionalità a cui è assegnato l’elemento di sviluppo. In Jira viene spesso configurato come campo personalizzato, oppure può essere ricavato da altre informazioni, come il progetto o un componente specifico. Questo attributo è essenziale per analizzare le prestazioni dei singoli team. Consente di filtrare le Dashboard per visualizzare metriche come il tempo di ciclo, il tasso di rilavorazione e il volume di lavoro completato da ciascun team. È fondamentale per le Dashboard 'Inter-Phase Handoff Efficiency' e 'Developer Workload & Item Progress'. Perché è importante Consente di misurare e confrontare le prestazioni dei diversi team di sviluppo, individuare quelli con i risultati migliori e condividere le pratiche più efficaci. Dove reperirli Spesso si tratta di un campo personalizzato in Jira. Si rivolga all’amministratore Jira per individuare il nome specifico del campo, che potrebbe essere 'Team', 'Squad' o simile. Esempi Team PhoenixServizi principaliVendicatori UI/UX
	Priorità dell’elemento ItemPriority	Livello di priorità assegnato all’elemento di sviluppo, che ne indica l’urgenza.
Descrizione La priorità dell’elemento definisce l’importanza o l’urgenza relativa di un elemento di lavoro. Jira mette a disposizione il campo standard 'priority', con livelli configurabili come Highest, High, Medium e Low. Analizzare la priorità è fondamentale per verificare la conformità e individuare i colli di bottiglia che interessano gli elementi critici. Ad esempio, la Dashboard 'Priority Item Conformance Check' utilizza questo attributo per verificare se gli elementi ad alta priorità vengono gestiti più rapidamente, come previsto, oppure restano in coda insieme a quelli a bassa priorità. Perché è importante Aiuta a verificare se gli elementi ad alta priorità vengono gestiti più rapidamente di quelli a bassa priorità e seguono un percorso più snello, così da rispettare gli SLA. Dove reperirli È il campo 'priority' all’interno dell’oggetto 'fields' nella risposta dell’API Jira Issue. Esempi MassimaAltaMediaBassa
	Stato dell’elemento ItemStatus	Stato corrente dell’elemento di sviluppo nel flusso di lavoro.
Descrizione Questo attributo indica la fase specifica in cui si trova l’elemento di sviluppo in un determinato momento, ad esempio 'In Progress', 'In Review' o 'Done'. La sequenza dei cambiamenti di stato nel tempo genera le attività utilizzate nel Process Mining. L’attributo 'Activity' rappresenta l’evento di cambiamento, mentre 'ItemStatus' indica lo stato dell’elemento. È utile come dimensione per filtrare e analizzare i dati, ad esempio per vedere quanti elementi si trovano attualmente in un determinato stato o per analizzare le caratteristiche degli elementi che vi rimangono a lungo. Perché è importante Fornisce un quadro dello stato di avanzamento dell’elemento nel suo ciclo di vita, essenziale per le analisi basate sullo stato e per comprendere la situazione corrente del lavoro in corso. Dove reperirli È il campo 'status' all’interno dell’oggetto 'fields' nella risposta dell’API Jira Issue. Esempi Da fareIn corsoIn revisioneCompletato
	Tipo di elemento ItemType	Classificazione dell’elemento di sviluppo, ad esempio Bug, Story, Task o Epic.
Descrizione Il tipo di elemento classifica la natura del lavoro svolto. Jira utilizza il campo standard 'issuetype' per distinguere le diverse tipologie di elementi di lavoro, che spesso seguono flussi di lavoro specifici. Questo attributo è essenziale per le analisi comparative. Consente di filtrare il processo in base a specifiche tipologie di lavoro, ad esempio per confrontare il ciclo di vita di un 'Bug' con quello di una 'Story'. In questo modo è possibile individuare se alcune tipologie di lavoro sono più soggette a ritardi, rilavorazioni o scostamenti dal processo standard. Perché è importante Consente di segmentare l’analisi del processo e confrontare la gestione di diverse tipologie di lavoro, come i bug e le nuove funzionalità, individuando le differenze tra i rispettivi processi. Dove reperirli È il campo 'issuetype' all’interno dell’oggetto 'fields' nella risposta dell’API Jira Issue. Esempi StoryBugTaskEpic
	Componente Component	Sottosezione o area funzionale di un progetto a cui appartiene l’elemento.
Descrizione In Jira, i componenti consentono di suddividere le issue di un progetto in gruppi più piccoli e gestibili. Possono rappresentare un’area funzionale, come 'Autenticazione utente', un livello tecnico, come 'API di backend', o un modulo, come 'Reportistica'. L’analisi per componente offre una visione più dettagliata del processo di sviluppo. Aiuta a individuare le parti dell’applicazione che generano più bug, hanno cicli di sviluppo più lunghi o richiedono più rilavorazioni, segnalando possibili aree di debito tecnico o complessità. Perché è importante Consente di segmentare il processo in base alle aree funzionali o tecniche del prodotto e di individuare i componenti che causano ritardi o problemi di qualità. Dove reperirli È il campo standard 'components' all’interno dell’oggetto 'fields' nella risposta dell’API Jira Issue. Esempi Interfaccia utenteDatabaseGateway APIAutenticazione
	È una rilavorazione IsRework	Indica se un’attività fa parte di un ciclo di rilavorazione.
Descrizione Questo attributo booleano è vero se un’attività rappresenta un passo indietro nel processo, ad esempio quando si torna a «Sviluppo avviato» dopo il mancato superamento dei test di QA. Il valore viene determinato analizzando la sequenza delle attività di un caso. Individuare le rilavorazioni è fondamentale per migliorare l’efficienza e la qualità del processo. Questo attributo supporta direttamente il KPI «Tasso di attività di rilavorazione» e la Dashboard «Frequenza e percorsi dei cicli di rilavorazione». Consente di quantificare il lavoro sprecato e di individuare le cause profonde dei problemi di qualità che generano rilavorazioni. Perché è importante Segnala in modo esplicito le attività che fanno parte di cicli di rilavorazione inefficienti, consentendo di misurare e analizzare con precisione gli sprechi e i problemi di qualità del processo. Dove reperirli È un attributo calcolato. Occorre definire il flusso di processo previsto e segnalare le attività che se ne discostano tornando a una fase precedente. Esempi truefalse
	Nome dello sprint SprintName	Nome dello sprint agile a cui è assegnato l’elemento di sviluppo.
Descrizione Per i team che utilizzano Scrum, lo sprint è un periodo di durata definita durante il quale viene completato un insieme di attività. Questo attributo registra il nome o l’identificativo dello sprint a cui appartiene un elemento. L’analisi per sprint è fondamentale nel Process Mining applicato ai metodi agili. Aiuta a valutare i risultati dei singoli sprint, comprendere il lavoro rinviato agli sprint successivi e monitorare i progressi rispetto agli obiettivi. Fornisce un contesto temporale più preciso rispetto a un intervallo di date generico. Perché è importante Fornisce un contesto essenziale per i team agili e consente di analizzare l’efficienza del processo e il volume di lavoro completato per ciascuno sprint. Dove reperirli Queste informazioni sono in genere memorizzate in un campo personalizzato 'Sprint', gestito da Jira Software (Agile). I dati sono accessibili tramite l’API Issue. Esempi Sprint 1 PROJSprint 3 Q4-2023Sprint 2 PI di novembre
	Ora di fine dell’evento EventEndTime	Data e ora in cui un’attività o uno stato sono stati completati.
Descrizione Questo attributo indica l’ora di completamento di un’attività e corrisponde all’ora dell’attività successiva nella sequenza di un determinato caso. Mentre 'EventTime' (StartTime) indica l’inizio di un’attività, EventEndTime ne indica la fine. La differenza tra questi due dati temporali corrisponde al tempo di elaborazione dell’attività. È un dato fondamentale per calcolare il KPI 'Average Stage Processing Time' e creare Dashboard che analizzano la durata delle attività. Perché è importante Definisce il momento in cui termina un’attività e consente di calcolare la durata di ogni fase del processo, un dato essenziale per l’analisi dei colli di bottiglia. Dove reperirli È un attributo derivato. Per un dato evento, l’ora di fine corrisponde all’ora di inizio dell’evento successivo dello stesso caso. Esempi 2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
	Rilascio pianificato PlannedReleaseVersion	Versione del software o rilascio previsto per la distribuzione dell’elemento.
Descrizione Questo attributo, spesso associato al campo 'Affects Version/s' in Jira, indica il rilascio previsto per una funzionalità o una correzione. Funge da scadenza o obiettivo per il completamento del lavoro. È un attributo fondamentale per il KPI 'On-Time Release Delivery Rate'. Confrontando la data effettiva di distribuzione con quella pianificata per il rilascio associato a questa versione, è possibile misurare il rispetto delle scadenze e la prevedibilità del processo di rilascio. Perché è importante Definisce la data o il rilascio previsti per la consegna e consente di calcolare il tasso di consegna puntuale e analizzare il rispetto delle scadenze. Dove reperirli Corrisponde ai campi 'versions' o 'fixVersions' nell’API Jira Issue. Il campo utilizzato per la pianificazione può variare. Esempi Versione 2.1Rilascio Q1 2024Lancio del progetto Phoenix
	Risoluzione dell’elemento ItemResolution	Esito finale o motivo della chiusura di un elemento di sviluppo.
Descrizione La risoluzione spiega perché un elemento è passato a uno stato di chiusura. Lo stato può essere 'Closed', mentre la risoluzione può essere 'Done', 'Won’t Do', 'Duplicate' o 'Cannot Reproduce'. Fornisce quindi un contesto essenziale sull’esito del lavoro. Analizzare la risoluzione aiuta a distinguere il lavoro completato con successo dagli elementi annullati o respinti. È importante per le analisi della qualità e per comprendere il volume effettivo di lavoro utile completato rispetto alle risorse dedicate a elementi poi scartati. Perché è importante Distingue gli elementi completati con successo da quelli chiusi per altri motivi, un aspetto essenziale per analizzare con precisione la produttività e la qualità. Dove reperirli È il campo 'resolution' all’interno dell’oggetto 'fields' nella risposta dell’API Jira Issue. In genere viene compilato solo quando un’issue viene chiusa. Esempi CompletatoNon verrà svoltoDuplicatoNon riproducibile
	Segnalatore Reporter	Utente che ha creato o segnalato inizialmente l’elemento di sviluppo.
Descrizione Il segnalatore è la persona che ha creato l’issue in Jira. Può essere uno sviluppatore, un addetto al controllo qualità, un responsabile di prodotto o anche un cliente tramite un’integrazione con un Service Desk. Analizzare il segnalatore può aiutare a comprendere l’origine del lavoro. Ad esempio, è possibile verificare se i bug segnalati dal team di controllo qualità seguono un ciclo di vita diverso da quelli segnalati dai clienti. L’analisi può inoltre chiarire le modalità di comunicazione e il flusso delle informazioni all’inizio del processo. Perché è importante Identifica l’origine dell’elemento di lavoro e consente di analizzare le tendenze in base a chi crea i task o segnala i bug. Dove reperirli È il campo 'reporter' all’interno dell’oggetto 'fields' nella risposta dell’API Jira Issue. Esempi Charles DarwinMarie CurieIsaac Newton
	Tempo di attesa nel passaggio di consegne HandoffWaitTime	Il tempo di inattività tra due attività consecutive.
Descrizione Questa metrica calcola il tempo di attesa, o di accodamento, tra il completamento di un’attività e l’inizio della successiva. Indica per quanto tempo il lavoro resta fermo in attesa che qualcuno se ne occupi. È una metrica fondamentale per il KPI «Tempo medio di attesa nel passaggio di consegne» e la Dashboard «Efficienza dei passaggi tra le fasi». Tempi di attesa elevati spesso segnalano problemi di coordinamento, vincoli di capacità o comunicazione inefficiente tra i team, ad esempio tra sviluppo e QA. Ridurre questi tempi di inattività è una leva importante per accorciare il tempo di ciclo complessivo. Perché è importante Evidenzia i tempi di inattività o di accodamento nel processo, mettendo in luce le inefficienze nei passaggi di consegne tra team o persone e i relativi problemi di coordinamento. Dove reperirli È una metrica calcolata: per lo stesso caso, corrisponde all’ora di inizio di un’attività meno l’ora di fine dell’attività precedente. Esempi 017280043200
	Tempo di ciclo totale CycleTime	La durata complessiva, dall’inizio alla fine, di un elemento di sviluppo.
Descrizione Il tempo di ciclo misura il tempo totale trascorso dalla creazione di un elemento di sviluppo fino alla sua risoluzione definitiva, ad esempio con la distribuzione in produzione. Si calcola a livello di caso sottraendo il timestamp del primo evento da quello dell’ultimo. È un KPI fondamentale per misurare la velocità e l’efficienza complessive del processo. Il KPI «Tempo medio di ciclo dall’inizio alla fine» e la Dashboard «Analisi complessiva del tempo di ciclo SDLC» si basano direttamente su questo calcolo. Ridurre il tempo di ciclo è spesso uno degli obiettivi principali delle iniziative di miglioramento dei processi. Perché è importante Misura la velocità complessiva del processo di sviluppo dall’inizio alla fine e fornisce un indicatore chiave dell’efficienza e della rapidità di consegna. Dove reperirli È un attributo calcolato a livello di caso. Per un dato «DevelopmentItem», corrisponde al timestamp dell’ultimo evento meno quello del primo. Esempi 12096002592000604800
	Versione di correzione FixVersion	Versione del software in cui l’elemento di sviluppo è stato effettivamente risolto e rilasciato.
Descrizione In Jira, 'Fix Version' indica il rilascio che include il lavoro completato per un elemento e ne registra il risultato concreto. Questo attributo fornisce il contesto del rilascio effettivo, che può essere confrontato con 'PlannedReleaseVersion' per analizzare i risultati della consegna. Consente inoltre di raggruppare tutti gli elementi inclusi in un rilascio specifico e ottenere una panoramica complessiva del lavoro completato. Perché è importante Conferma in quale rilascio è stato incluso un lavoro e fornisce un riferimento concreto per analizzare i rilasci e monitorare le funzionalità consegnate. Dove reperirli Corrisponde al campo 'fixVersions' nella risposta dell’API Jira Issue. Esempi v2.1.1 Correzione urgentev3.0.0 Rilascio principalev2.2.0

Obbligatorio Consigliato Facoltativo

Attività del ciclo di vita dello sviluppo software

Questi sono i principali passaggi e traguardi da registrare nell’event log per ricostruire con precisione il ciclo di vita dello sviluppo software.

6 Consigliato 8 Facoltativo

	Attività	Descrizione
	Distribuito in produzione	Questo evento indica il momento in cui le modifiche al codice associate all’elemento di sviluppo vengono rese disponibili nell’ambiente di produzione. Si può dedurre dal passaggio finale dello stato a 'Done' o 'Released', oppure registrare tramite un evento esplicito inviato da uno strumento CI/CD integrato.
Perché è importante È il principale punto di arrivo del processo e ne indica il completamento. È essenziale per calcolare il tempo di ciclo complessivo e misurare la frequenza e il volume delle distribuzioni. Dove reperirli Si può dedurre dal registro delle modifiche dell’issue Jira quando lo stato passa a 'Released' o 'Done'. Per una maggiore precisione, è possibile acquisire gli eventi di distribuzione inviati da strumenti CI/CD come Jenkins o Bamboo, oppure tramite la funzionalità Deployments di Jira. Acquisizione Data e ora del passaggio di stato a 'Done' o 'Released'. Tipo di evento inferred
	Elemento di sviluppo creato	Segna l’inizio del ciclo di vita, quando un nuovo elemento di sviluppo, ad esempio una storia, un bug o un’attività, viene registrato formalmente in Jira. Per ogni segnalazione, il sistema registra esplicitamente questo evento con la data e l’ora di creazione.
Perché è importante Questa attività segna l’inizio effettivo del processo ed è essenziale per calcolare i tempi di ciclo complessivi e monitorare il volume totale del lavoro in ingresso. Dove reperirli È un evento fondamentale per ogni segnalazione Jira. La data e l’ora di creazione sono memorizzate nel campo «created» del record della segnalazione e sono accessibili tramite l’API di Jira. Acquisizione Il campo «created» con la data e l’ora dell’oggetto Jira Issue. Tipo di evento explicit
	Sviluppo iniziato	Indica il momento in cui uno sviluppatore inizia a lavorare attivamente all’elemento di sviluppo. In Jira, di solito si deduce da una modifica dello stato nel flusso di lavoro, ad esempio quando la segnalazione passa a «In corso».
Perché è importante È una tappa fondamentale per misurare il tempo dedicato allo sviluppo attivo. Aiuta a distinguere i tempi di attesa dal lavoro che crea valore, una metrica essenziale per individuare i colli di bottiglia. Dove reperirli Si deduce dalla cronologia delle modifiche della segnalazione Jira. È la data e l’ora in cui il campo «status» passa per la prima volta a «In corso», «In sviluppo» o a uno stato attivo simile. Acquisizione Data e ora della modifica dello stato a «In corso». Tipo di evento inferred
	Test di accettazione da parte degli utenti approvati	Indica il completamento positivo dei test di accettazione da parte degli utenti e l’approvazione degli stakeholder per il rilascio. Si deduce da una modifica dello stato da «In UAT» a uno stato come «Pronto per il rilascio» o «Completato».
Perché è importante Questa tappa conferma l’accettazione da parte dell’azienda e autorizza il rilascio dell’elemento in produzione. È un passaggio fondamentale per verificare che il lavoro consegnato soddisfi le aspettative degli utenti. Dove reperirli Dedotto dal registro delle modifiche dell’issue Jira. Corrisponde alla data e all’ora in cui lo stato passa da 'In UAT' allo stato successivo nel flusso di lavoro, indicando l’approvazione. Acquisizione Data e ora del passaggio di stato da 'In UAT' a 'Ready for Release'. Tipo di evento inferred
	Test di controllo qualità completati	Indica che l’elemento di sviluppo ha superato tutti i controlli di qualità ed è pronto per la fase successiva, ad esempio i test di accettazione da parte degli utenti o il rilascio. Si deduce da una modifica dello stato che porta fuori dallo stato principale di test.
Perché è importante Segna il completamento di un importante controllo di qualità. Analizzare la durata della fase di controllo qualità aiuta a ottimizzare i processi di test e l’allocazione delle risorse. Dove reperirli Si deduce dalla cronologia delle modifiche della segnalazione Jira. È la data e l’ora in cui il campo «status» passa da «In controllo qualità» a uno stato successivo, come «Pronto per gli UAT» o «Pronto per il rilascio». Acquisizione Data e ora della modifica dello stato da «In controllo qualità» a «Pronto per gli UAT». Tipo di evento inferred
	Test di controllo qualità iniziati	Questo evento segna l’inizio della fase formale di controllo qualità dell’elemento di sviluppo. Si deduce da una modifica dello stato in Jira, quando la segnalazione passa a uno stato come «In controllo qualità», «In test» o «Pronto per i test».
Perché è importante È una tappa fondamentale che dà inizio al ciclo di convalida della qualità. Misurare il tempo che intercorre tra «Sviluppo completato» e questo momento mette in luce i ritardi nel passaggio di consegne tra i team di sviluppo e di controllo qualità. Dove reperirli Si deduce dalla cronologia delle modifiche della segnalazione Jira. È la data e l’ora in cui il campo «status» passa a uno stato dedicato ai test di controllo qualità, come «In controllo qualità». Acquisizione Data e ora della modifica dello stato a «In controllo qualità» o «In test». Tipo di evento inferred
	Elemento di sviluppo annullato	Indica l’interruzione di un elemento di sviluppo prima del completamento. Si deduce dal passaggio di stato a uno stato finale come 'Canceled', 'Rejected' o 'Won’t Do' e spesso è accompagnato da una risoluzione specifica.
Perché è importante Questa attività monitora gli esiti non positivi del processo. Analizzare i motivi per cui gli elementi vengono annullati può far emergere problemi di pianificazione, definizione delle priorità o dei requisiti. Dove reperirli Dedotto dal registro delle modifiche dell’issue Jira. Corrisponde alla data e all’ora in cui lo 'status' dell’issue passa a 'Canceled' o 'Won’t Do' e viene impostata la relativa risoluzione. Acquisizione Data e ora del passaggio di stato a 'Canceled', 'Rejected' o 'Won’t Do'. Tipo di evento inferred
	Elemento di sviluppo chiuso	È l’ultima operazione amministrativa e conferma che non sono previste altre attività sull’elemento. Spesso si deduce dal passaggio di stato a 'Closed' e dall’impostazione di un valore nel campo 'Resolution'.
Perché è importante Indica la conclusione definitiva del percorso di un elemento. Il confronto con 'Deployed to Production' può far emergere ritardi amministrativi o periodi di monitoraggio successivi alla distribuzione. Dove reperirli Dedotto dal registro delle modifiche dell’issue Jira. Corrisponde alla data e all’ora in cui il campo 'status' passa a 'Closed' e viene impostata una risoluzione. Acquisizione Data e ora del passaggio di stato a 'Closed'. Tipo di evento inferred
	Elemento pronto per lo sviluppo	Indica che un elemento di sviluppo è stato descritto in modo completo, revisionato e prioritizzato, ed è pronto per essere preso in carico da uno sviluppatore. In genere, si deduce da una modifica dello stato nel flusso di lavoro, ad esempio dal passaggio da «Backlog» a «Da fare» o «Pronto per lo sviluppo».
Perché è importante Monitorare questo passaggio aiuta a valutare quanto è pronto il backlog e per quanto tempo gli elementi attendono prima dell’inizio dello sviluppo. Permette di distinguere il tempo dedicato alla pianificazione e alla definizione dei requisiti da quello dello sviluppo attivo. Dove reperirli Si deduce dalla cronologia delle modifiche della segnalazione Jira. Si cerca la data e l’ora in cui il campo «status» cambia in un valore come «Pronto per lo sviluppo», «Da fare» o «Selezionato per lo sviluppo». Acquisizione Data e ora della modifica dello stato a uno stato che indica la disponibilità per lo sviluppo. Tipo di evento inferred
	Preparato per il rilascio	Indica che l’elemento di sviluppo ha superato tutti i controlli ed è stato incluso in una specifica versione del software, in attesa della distribuzione. Spesso si deduce quando lo stato di un’issue passa a 'Ready for Release' o viene compilato il campo 'Fix Version'.
Perché è importante Questa attività consente di monitorare la preparazione al rilascio e il tempo che gli elementi trascorrono in attesa di una finestra di distribuzione, una volta completate tutte le attività di sviluppo e test. Dove reperirli In genere si deduce dal registro delle modifiche dell’issue Jira, quando lo stato passa a 'Ready for Release'. In alternativa, si può ricavare dalla data e dall’ora in cui viene compilato il campo 'Fix Version/s'. Acquisizione Data e ora del passaggio di stato a 'Ready for Release' o della compilazione del campo 'Fix Version'. Tipo di evento inferred
	Revisione del codice completata	Indica che un collega o un responsabile ha revisionato il codice per verificarne la qualità, la conformità agli standard e il funzionamento. Si può dedurre da una modifica dello stato, ad esempio da «In revisione» a «Pronto per il controllo qualità», oppure rilevare esplicitamente tramite strumenti di sviluppo integrati.
Perché è importante È un controllo di qualità fondamentale. Analizzarne la durata e i risultati, ad esempio le rilavorazioni, aiuta a migliorare la qualità del codice e a ridurre i bug individuati nelle fasi successive. Dove reperirli In genere, si deduce dalla cronologia delle modifiche della segnalazione Jira quando lo stato esce da «Revisione del codice». Può anche essere registrato come evento esplicito se sono integrati strumenti per i repository di codice, come Bitbucket o GitHub. Acquisizione Data e ora della modifica dello stato da «In revisione» allo stato successivo. Tipo di evento inferred
	Sviluppo completato	Indica che lo sviluppatore ha terminato la programmazione e che l’elemento è pronto per la fase successiva, ad esempio la revisione del codice o i test. Si deduce da una modifica dello stato in Jira, come il passaggio da «In corso» a «In revisione» o «Pronto per il controllo qualità».
Perché è importante Segna la fine della fase principale di sviluppo e consente di analizzare la durata della programmazione e l’efficienza del passaggio di consegne al team di controllo qualità. Dove reperirli Si deduce dalla cronologia delle modifiche della segnalazione Jira, registrando la data e l’ora in cui il campo «status» passa da uno stato di sviluppo attivo a uno stato successivo, come «In revisione» o «Pronto per il controllo qualità». Acquisizione Data e ora della modifica dello stato da «In corso» a «In revisione» o «Pronto per il controllo qualità». Tipo di evento inferred
	Test di accettazione da parte degli utenti iniziati	Segna l’inizio dei test di accettazione da parte degli utenti, durante i quali gli stakeholder aziendali o gli utenti finali convalidano le nuove funzionalità. Si deduce da una modifica dello stato in Jira a uno stato come «In UAT» o «Test di accettazione da parte degli utenti».
Perché è importante Questa attività segna l’inizio della fase finale di convalida prima del rilascio. Analizzarne la durata è fondamentale per comprendere e ridurre i ritardi dovuti alla disponibilità degli stakeholder o ai cicli di riscontro. Dove reperirli Si deduce dalla cronologia delle modifiche della segnalazione Jira. È la data e l’ora in cui il campo «status» viene aggiornato a «In UAT» o a uno stato analogo. Acquisizione Data e ora della modifica dello stato a «In UAT». Tipo di evento inferred
	Test di controllo qualità non superati	Indica che il team di controllo qualità ha individuato un difetto e ha rimandato l’elemento di sviluppo agli sviluppatori per la rilavorazione. Si deduce da un passaggio a uno stato precedente, ad esempio da «In controllo qualità» a «In corso» o «Da fare».
Perché è importante Questa attività è fondamentale per individuare i cicli di rilavorazione. Monitorarne la frequenza aiuta a quantificare il costo della scarsa qualità e a individuare gli aspetti dello sviluppo o dei requisiti da migliorare. Dove reperirli Si deduce dalla cronologia delle modifiche della segnalazione Jira. Viene registrata quando il campo «status» passa da uno stato di test, ad esempio «In controllo qualità», a uno stato precedente dello sviluppo, come «In corso». Acquisizione Data e ora della modifica dello stato da uno stato di test a uno stato di sviluppo. Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Jira Software

Passaggi

Acceda alla Sua istanza di Jira Software.
Nella barra di navigazione principale, selezioni Issues, quindi faccia clic su Search for issues. Si aprirà Issue Navigator.
Nella pagina di ricerca, passi dalla modalità predefinita Basic alla modalità Avanzate per utilizzare Jira Query Language (JQL).
Inserisca la query JQL fornita nell’apposita barra. Sostituisca i valori segnaposto relativi alla chiave del progetto e all’intervallo di date in base alle Sue esigenze.
Esegua la query facendo clic sull’icona di ricerca o premendo Invio. Verrà visualizzato l’elenco di tutti gli elementi di sviluppo che soddisfano i criteri.
Nell’angolo in alto a destra della pagina dei risultati, faccia clic sull’icona Export (potrebbe avere l’aspetto di un’icona di condivisione o riportare esplicitamente questa dicitura) e selezioni l’opzione XML. Non utilizzi il formato CSV: il formato XML contiene la cronologia completa e strutturata delle modifiche, necessaria per creare l’Event Log.
Salvi il file XML scaricato sul computer. Il file contiene un record per ogni segnalazione Jira, con tutte le modifiche storiche annidate al suo interno.
Passaggio di trasformazione importante: il file XML esportato non è un Event Log tabellare. È necessario analizzarlo con uno script esterno o uno strumento ETL. Lo script deve scorrere ogni tag <item> (che rappresenta una segnalazione Jira) nel file XML.
Per ogni segnalazione, lo script deve innanzitutto generare una riga per l’attività Elemento di sviluppo creato, utilizzando la marca temporale del campo created.
Successivamente, lo script deve analizzare i dati <changelog> di ogni segnalazione. Per ciascun <changeitem> che rappresenta una transizione di stato, generi una nuova riga nel file di output. Associare la transizione di stato Jira (ad esempio, da «In Progress» a «In Review») all’attività aziendale corrispondente (ad esempio, «Sviluppo completato») e utilizzare la marca temporale della transizione come EventTime.
Lo script deve compilare tutti gli attributi obbligatori e consigliati per ogni riga, estraendo dalla struttura XML dati quali chiave della segnalazione, tipo di segnalazione, assegnatario e progetto.
Dopo aver elaborato tutte le segnalazioni e le relative cronologie, salvi i dati trasformati in un file CSV con intestazioni corrispondenti agli attributi specificati, pronto per il caricamento nello strumento di Process Mining.

Configurazione

Filtri della query JQL: la query JQL è lo strumento principale per selezionare i dati. Tra i filtri più importanti figurano project, per selezionare progetti di sviluppo specifici, issuetype, per includere solo gli elementi pertinenti come Story, Bug o Task, e created, per definire il periodo di analisi.
Intervallo di date: per l’analisi iniziale si consiglia di estrarre dati relativi a un periodo compreso tra 3 e 6 mesi. Si ottengono così dati sufficienti per individuare schemi significativi, mantenendo gestibili le dimensioni del file esportato. Specifichi l’intervallo nella query JQL con created >= 'YYYY-MM-DD' e created <= 'YYYY-MM-DD'.
Tipi di issue: specifichi con precisione i valori di issuetype. In genere è opportuno includere Story, Bug, Task e Spike, escludendo le issue contenitore come Epic o quelle più granulari come Sub-task, se non rappresentano il caso principale.
Formato di esportazione: selezioni XML come formato di esportazione. L’esportazione CSV standard non include in modo affidabile i dati strutturati della cronologia delle modifiche necessari per ricostruire la sequenza delle attività.
Autorizzazioni utente: l’utente che esegue l’esportazione deve disporre dell’autorizzazione «Browse Projects» per i progetti Jira specificati nella query JQL.

a Query di esempio config

project = "[Your Project Key]" AND issuetype in (Story, Bug, Task) AND created >= "[Start Date in YYYY-MM-DD format]" AND created <= "[End Date in YYYY-MM-DD format]" ORDER BY created DESC

Passaggi

Stabilisca la connessione al database: verifichi di disporre di credenziali di accesso in sola lettura e della connettività di rete al database SQL di backend dell’istanza Jira. Questo metodo è disponibile solo per le installazioni autonome di Jira.
Si connetta con un client SQL: utilizzi un client per database, ad esempio DBeaver, SQL Server Management Studio o pgAdmin, per collegarsi al database Jira con le credenziali fornite.
Individui gli stati del flusso di lavoro: prima di eseguire la query, apra le impostazioni del flusso di lavoro del progetto Jira (Project settings > Workflows). Prenda nota dei nomi esatti degli stati corrispondenti alle attività da monitorare, ad esempio «Backlog», «In Progress», «In Review» e «Done».
Personalizzi la query SQL: copi la query SQL fornita nel client. Dovrà modificare i valori segnaposto. Presti particolare attenzione ai nomi degli stati nelle clausole WHERE di ciascun blocco UNION ALL, che devono corrispondere esattamente al flusso di lavoro del progetto.
Imposti i parametri della query: modifichi il filtro dell’intervallo di date (WHERE ji.created >= '2023-01-01') per definire il periodo da analizzare. È inoltre fortemente consigliato filtrare uno o più progetti specifici, rimuovendo i commenti e impostando il filtro della chiave del progetto (--AND p.pkey IN ('PROJ1', 'PROJ2')).
Configuri i campi personalizzati: individui l’ID del campo personalizzato «Nome team» nell’istanza Jira. Può trovarlo nella pagina di amministrazione dei campi personalizzati di Jira. Sostituisca nella query il segnaposto 'customfield_10100' con l’ID effettivo.
Esegua la query: esegua la query SQL modificata sul database Jira.
Riveda i risultati: controlli brevemente i dati restituiti per verificare che siano presenti righe relative a diverse attività e che le colonne siano compilate come previsto.
Esporti l’event log: esporti l’intero insieme di risultati dal client SQL in un file CSV. Verifichi che la codifica del file sia UTF-8.
Prepari il caricamento: verifichi che le intestazioni delle colonne nel file CSV esportato corrispondano ai nomi degli attributi richiesti: DevelopmentItem, Activity, EventTime, SourceSystem, LastDataUpdate, Assignee, ItemType, ItemPriority, ItemStatus, ProjectName e TeamName.

Configurazione

Credenziali del database: è necessario un account utente con accesso in sola lettura al database Jira, per evitare modifiche accidentali ai dati.
Nomi degli stati del flusso di lavoro: la query si basa principalmente sul filtro per nome dello stato, ad esempio «In Progress» o «Done». I nomi variano in base al flusso di lavoro e al progetto Jira. Sostituisca nella query i valori segnaposto con i nomi esatti della Sua configurazione.
Intervallo di date: la query include una clausola WHERE ji.created >= '[YYYY-MM-DD]' per limitare la quantità di dati elaborati. Per l’analisi iniziale si consiglia un intervallo da 3 a 6 mesi, così da mantenere gestibile il volume dei dati e ridurre i tempi di esecuzione.
Filtro per progetto: per circoscrivere l’analisi, è fortemente consigliato filtrare le chiavi dei progetti specifici con la condizione p.pkey IN ('[YourProjectKey]'). Interrogare tutti i progetti di un’istanza Jira di grandi dimensioni può richiedere molto tempo.
Campo personalizzato del team: si presuppone che «Nome team» sia un campo personalizzato. La query fornita utilizza l’ID segnaposto customfield_10100, che deve essere sostituito con l’ID corretto della configurazione Jira.
Prestazioni: le query dirette al database possono richiedere molte risorse. Esegua l’estrazione nelle ore di minore attività oppure, preferibilmente, su una replica di lettura del database di produzione, per evitare di incidere sulle prestazioni di Jira per gli utenti.

a Query di esempio sql

WITH EventLogBase AS (
    SELECT
        p.pkey || '-' || ji.issuenum AS DevelopmentItem,
        au.display_name AS Assignee,
        it.pname AS ItemType,
        pr.pname AS ItemPriority,
        p.pname AS ProjectName,
        (SELECT cfv.stringvalue FROM customfieldvalue cfv JOIN customfield cf ON cfv.customfield = cf.id WHERE cf.cfname = 'Team' AND cfv.issue = ji.id LIMIT 1) AS TeamName,
        ji.created AS created_timestamp,
        cg.created AS change_timestamp,
        ci.fieldtype,
        ci.field,
        ci.oldstring,
        ci.newstring,
        s.pname as CurrentItemStatus
    FROM jiraissue ji
    LEFT JOIN project p ON ji.project = p.id
    LEFT JOIN issuetype it ON ji.issuetype = it.id
    LEFT JOIN priority pr ON ji.priority = pr.id
    LEFT JOIN issuestatus s ON ji.issuestatus = s.id
    LEFT JOIN app_user au ON ji.assignee = au.user_key
    LEFT JOIN changegroup cg ON cg.issueid = ji.id
    LEFT JOIN changeitem ci ON ci.groupid = cg.id
    WHERE ji.created >= '2023-01-01' --<<< Set your desired start date here
    --AND p.pkey IN ('PROJ1', 'PROJ2') --<<< Uncomment and set your project keys here
)
-- 1. Development Item Created
SELECT
    b.DevelopmentItem,
    'Development Item Created' AS Activity,
    b.created_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.CurrentItemStatus AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM (
    SELECT DISTINCT DevelopmentItem, created_timestamp, Assignee, ItemType, ItemPriority, CurrentItemStatus, ProjectName, TeamName
    FROM EventLogBase
) b

UNION ALL

-- 2. Item Ready for Development
SELECT DISTINCT
    b.DevelopmentItem,
    'Item Ready for Development' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'Backlog' AND b.newstring = 'To Do' --<<< Adjust status names

UNION ALL

-- 3. Development Started
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In Progress' --<<< Adjust status names

UNION ALL

-- 4. Development Completed
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Completed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In Progress' AND b.newstring = 'In Review' --<<< Adjust status names

UNION ALL

-- 5. Code Review Performed
SELECT DISTINCT
    b.DevelopmentItem,
    'Code Review Performed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In Review' AND b.newstring = 'Ready for QA' --<<< Adjust status names

UNION ALL

-- 6. QA Testing Started
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In QA' --<<< Adjust status names

UNION ALL

-- 7. QA Testing Failed
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Failed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In QA' AND b.newstring = 'In Progress' --<<< Adjust status names

UNION ALL

-- 8. QA Testing Completed
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Completed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In QA' AND b.newstring = 'Ready for UAT' --<<< Adjust status names

UNION ALL

-- 9. UAT Started
SELECT DISTINCT
    b.DevelopmentItem,
    'UAT Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In UAT' --<<< Adjust status names

UNION ALL

-- 10. UAT Approved
SELECT DISTINCT
    b.DevelopmentItem,
    'UAT Approved' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In UAT' AND b.newstring = 'Ready for Release' --<<< Adjust status names

UNION ALL

-- 11. Prepared For Release
SELECT DISTINCT
    b.DevelopmentItem,
    'Prepared For Release' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Ready for Release' --<<< Adjust status names

UNION ALL

-- 12. Deployed To Production
SELECT DISTINCT
    b.DevelopmentItem,
    'Deployed To Production' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Released' --<<< Adjust status names

UNION ALL

-- 13. Development Item Closed
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Item Closed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Closed' --<<< Adjust status names

UNION ALL

-- 14. Development Item Canceled
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Item Canceled' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring IN ('Canceled', 'Won''t Do', 'Rejected'); --<<< Adjust status names

Passaggi

Prerequisiti: verifichi che Python 3 sia installato sul sistema. Installi le librerie necessarie, requests per le chiamate API e pandas per la manipolazione dei dati, eseguendo il comando: pip install requests pandas.
Generi un token API Jira: acceda all’istanza Jira. Apra le impostazioni del profilo utente, acceda a Security e selezioni «Create and manage API tokens». Crei un nuovo token e lo copi in modo sicuro. Lo script utilizzerà questo token al posto della password per l’autenticazione.
Configuri lo script Python: copi lo script Python fornito in un file, ad esempio extract_jira_log.py. Apra il file e aggiorni la sezione di configurazione iniziale con l’URL del sito Jira, il Suo indirizzo e-mail e il token API appena generato.
Definisca la query JQL: modifichi la variabile JQL_QUERY nello script. La query definisce l’ambito delle issue da estrarre. Per iniziare, può filtrare per progetto, tipo di issue e intervallo di date specifico, ad esempio: project = "MyProject" AND issuetype in (Story, Bug, Task) AND updated >= -180d.
Personalizzi la mappatura degli stati: riveda il dizionario STATUS_MAPPING nello script. Questa mappatura è essenziale per convertire gli stati specifici del flusso di lavoro Jira dell’organizzazione nelle attività standardizzate per il Process Mining. Aggiorni le chiavi, che corrispondono ai nomi degli stati Jira, affinché coincidano esattamente con il flusso di lavoro in uso.
Esegua lo script: avvii lo script dal terminale con il comando python extract_jira_log.py. Lo script si collegherà all’API Jira, recupererà i dati delle issue ed elaborerà le cronologie delle modifiche.
Gestisca la paginazione dell’API: lo script gestisce automaticamente la paginazione recuperando le issue in gruppi di 50. Continuerà a inviare richieste finché non avrà recuperato tutte le issue corrispondenti alla query JQL.
Elabori le cronologie delle issue: per ogni issue, lo script recupera l’intera cronologia. Individua l’evento di creazione e scorre tutte le modifiche di stato, aggiungendo all’event log una riga per ogni transizione pertinente in base a STATUS_MAPPING.
Generi il file dell’event log: al termine dell’elaborazione, lo script raccoglie gli eventi in un DataFrame pandas, aggiunge le colonne di metadati obbligatorie, come SourceSystem e LastDataUpdate, e salva l’event log finale in un file CSV denominato jira_event_log.csv nella stessa cartella.

Configurazione

JIRA_URL: l’URL di base dell’istanza Jira, ad esempio https://your-company.atlassian.net.
JIRA_EMAIL: l’indirizzo e-mail dell’account utente utilizzato per l’autenticazione.
JIRA_API_TOKEN: il token API generato nelle impostazioni di sicurezza dell’utente Jira per autenticare lo script.
JQL_QUERY: la stringa Jira Query Language che filtra le issue da estrarre. Per gestire il volume dei dati, è fortemente consigliato impostare un intervallo di date, ad esempio gli ultimi 6-12 mesi. È inoltre opportuno filtrare per progetto e per i tipi di issue pertinenti, come Story, Bug e Task, così da analizzare il processo corretto.
STATUS_MAPPING: un dizionario Python che associa i nomi specifici degli stati del flusso di lavoro Jira ai nomi generici richiesti per le attività. È la configurazione più importante per garantire la precisione del modello di processo. La personalizzi in base al flusso di lavoro del progetto.
Prerequisiti: lo script richiede un account utente Jira con accesso in lettura ai progetti e alle issue da estrarre. L’utente deve inoltre disporre delle autorizzazioni necessarie per utilizzare l’API REST.

a Query di esempio python

import requests
import pandas as pd
from requests.auth import HTTPBasicAuth
from datetime import datetime, timezone
import json

class=class="hl-string">"hl-comment"># --- CONFIGURATION SECTION ---
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://[your-company].atlassian.net"
JIRA_EMAIL = class="hl-string">"[your-email@example.com]"
JIRA_API_TOKEN = class="hl-string">"[your-jira-api-token]"

class=class="hl-string">"hl-comment"># JQL query to select the issues for extraction
class=class="hl-string">"hl-comment"># Best practice: Filter by project, issue type, and a date range
JQL_QUERY = class="hl-string">'project = "PROJ" AND issuetype in (Story, Bug, Task) AND updated >= -180d'

class=class="hl-string">"hl-comment"># --- STATUS MAPPING ---
class=class="hl-string">"hl-comment"># CRITICAL: Customize this mapping to match your Jira workflow statuses.
class=class="hl-string">"hl-comment"># The key is the Jira status name (case-sensitive) and the value is the desired Activity name.
STATUS_MAPPING = {
    class=class="hl-string">"hl-comment"># Example Mappings - Adjust to your workflow
    class="hl-string">'To Do': class="hl-string">'Item Ready for Development',
    class="hl-string">'In Progress': class="hl-string">'Development Started',
    class="hl-string">'In Review': class="hl-string">'Development Completed',
    class="hl-string">'Code Review': class="hl-string">'Code Review Performed', class=class="hl-string">"hl-comment"># Often combined with class="hl-string">'In Review' -> class="hl-string">'In QA' transition
    class="hl-string">'In QA': class="hl-string">'QA Testing Started',
    class="hl-string">'QA In Progress': class="hl-string">'QA Testing Started',
    class="hl-string">'Done from QA to In Progress': class="hl-string">'QA Testing Failed', class=class="hl-string">"hl-comment"># Special case for backward transitions
    class="hl-string">'UAT': class="hl-string">'UAT Started',
    class="hl-string">'Ready for Release': class="hl-string">'Prepared For Release',
    class="hl-string">'Done': class="hl-string">'Deployed To Production', class=class="hl-string">"hl-comment"># Often corresponds to final class="hl-string">'Done' state
    class="hl-string">'Released': class="hl-string">'Deployed To Production',
    class="hl-string">'Closed': class="hl-string">'Development Item Closed',
    class="hl-string">'Canceled': class="hl-string">'Development Item Canceled',
    class="hl-string">'Won\'t Doclass="hl-string">': 'Development Item Canceled',
    class=class="hl-string">"hl-comment"># Transitions to specific activities
    class="hl-string">'transition_In Review_to_In QA': class="hl-string">'Code Review Performed',
    class="hl-string">'transition_In QA_to_Ready for Release': class="hl-string">'QA Testing Completed',
    class="hl-string">'transition_UAT_to_Ready for Release': class="hl-string">'UAT Approved',
}

def get_team_from_issue(issue_fields):
    class=class="hl-string">"hl-comment"># Placeholder function to extract Team Name.
    class=class="hl-string">"hl-comment"># Customize this based on how team information is stored in your Jira.
    class=class="hl-string">"hl-comment"># Common sources are Components, Labels, or a custom field.
    if class="hl-string">'components' in issue_fields and issue_fields[class="hl-string">'components']:
        return issue_fields[class="hl-string">'components'][0][class="hl-string">'name']
    return None

def extract_jira_event_log():
    class="hl-string">"""Extracts an event log from Jira based on a JQL query."""
    auth = HTTPBasicAuth(JIRA_EMAIL, JIRA_API_TOKEN)
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json"
    }
    search_url = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"

    event_log = []
    start_at = 0
    max_results = 50
    total_issues = 1 class=class="hl-string">"hl-comment"># Initialize to enter loop

    while start_at < total_issues:
        params = {
            class="hl-string">'jql': JQL_QUERY,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        response = requests.get(search_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if the request fails
        data = response.json()

        total_issues = data[class="hl-string">'total']
        issues = data[class="hl-string">'issues']

        last_data_update = datetime.now(timezone.utc).isoformat()

        for issue in issues:
            issue_key = issue[class="hl-string">'key']
            fields = issue[class="hl-string">'fields']
            
            class=class="hl-string">"hl-comment"># Common attributes for all events of this issue
            common_attrs = {
                class="hl-string">'DevelopmentItem': issue_key,
                class="hl-string">'ItemType': fields.get(class="hl-string">'issuetype', {}).get(class="hl-string">'name'),
                class="hl-string">'ProjectName': fields.get(class="hl-string">'project', {}).get(class="hl-string">'name'),
                class="hl-string">'SourceSystem': class="hl-string">'Jira Software'
            }

            class=class="hl-string">"hl-comment"># 1. Development Item Created event
            created_time = pd.to_datetime(fields[class="hl-string">'created']).isoformat()
            event_log.append({
                **common_attrs,
                class="hl-string">'Activity': class="hl-string">'Development Item Created',
                class="hl-string">'EventTime': created_time,
                class="hl-string">'Assignee': fields.get(class="hl-string">'creator', {}).get(class="hl-string">'displayName'),
                class="hl-string">'ItemPriority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                class="hl-string">'ItemStatus': class="hl-string">'Created',
                class="hl-string">'TeamName': get_team_from_issue(fields),
                class="hl-string">'LastDataUpdate': last_data_update
            })

            class=class="hl-string">"hl-comment"># Process changelog for status transitions
            if class="hl-string">'changelog' in issue and issue[class="hl-string">'changelog'][class="hl-string">'histories']:
                for history in issue[class="hl-string">'changelog'][class="hl-string">'histories']:
                    event_time = pd.to_datetime(history[class="hl-string">'created']).isoformat()
                    author = history.get(class="hl-string">'author', {}).get(class="hl-string">'displayName')

                    for item in history[class="hl-string">'items']:
                        if item[class="hl-string">'field'] == class="hl-string">'status':
                            from_status = item[class="hl-string">'fromString']
                            to_status = item[class="hl-string">'toString']
                            activity = None

                            class=class="hl-string">"hl-comment"># Handle specific transitions first
                            transition_key = fclass="hl-string">"transition_{from_status.replace(' ', '')}_to_{to_status.replace(' ', '')}"
                            if transition_key in STATUS_MAPPING:
                                activity = STATUS_MAPPING[transition_key]
                            class=class="hl-string">"hl-comment"># Handle backward transitions (rework)
                            elif to_status == class="hl-string">'In Progress' and from_status in [class="hl-string">'In QA', class="hl-string">'QA In Progress', class="hl-string">'In Review']:
                                activity = class="hl-string">'QA Testing Failed'
                            class=class="hl-string">"hl-comment"># Handle general status changes
                            elif to_status in STATUS_MAPPING:
                                activity = STATUS_MAPPING[to_status]
                            
                            if activity:
                                event_log.append({
                                    **common_attrs,
                                    class="hl-string">'Activity': activity,
                                    class="hl-string">'EventTime': event_time,
                                    class="hl-string">'Assignee': author, class=class="hl-string">"hl-comment"># Person who made the change
                                    class="hl-string">'ItemPriority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                                    class="hl-string">'ItemStatus': to_status,
                                    class="hl-string">'TeamName': get_team_from_issue(fields),
                                    class="hl-string">'LastDataUpdate': last_data_update
                                })
        
        start_at += len(issues)
        print(fclass="hl-string">"Processed {start_at} of {total_issues} issues...")

    if not event_log:
        print(class="hl-string">"No events were generated. Check your JQL query and STATUS_MAPPING.")
        return

    class=class="hl-string">"hl-comment"># Convert to DataFrame
    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Ensure required columns are present
    required_cols = [class="hl-string">'DevelopmentItem', class="hl-string">'Activity', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate']
    recommended_cols = [class="hl-string">'Assignee', class="hl-string">'ItemType', class="hl-string">'ItemPriority', class="hl-string">'ItemStatus', class="hl-string">'ProjectName', class="hl-string">'TeamName']
    all_cols = required_cols + [col for col in recommended_cols if col in df.columns]
    df = df[all_cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    df.to_csv(class="hl-string">'jira_event_log.csv', index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to jira_event_log.csv")

if __name__ == class="hl-string">"__main__":
    extract_jira_event_log()

Passaggi

Verifichi che per il progetto Jira siano disponibili Jira Automation, i webhook in uscita e un ricevitore HTTPS. Il ricevitore deve accettare richieste POST e conservare l’intero payload JSON, compresi i metadati dell’evento e i campi dell’issue.
Definisca il contratto degli eventi prima di creare le regole. Utilizzi Development Item come identificativo del caso, Activity come nome dell’attività, EventTime come timestamp dell’evento, SourceSystem per indicare Jira Software e LastDataUpdate come timestamp di acquisizione o aggiornamento. Configuri il ricevitore affinché conservi la chiave dell’issue Jira in DevelopmentItem.
Crei regole Jira Automation con trigger basati sugli eventi delle issue. Configuri regole per la creazione delle issue, le transizioni di stato del flusso di lavoro, le modifiche alla risoluzione, le modifiche a Fix Version, se pertinenti, e gli eventuali eventi di distribuzione o revisione integrati disponibili nella configurazione Jira. Jira non prevede un unico flusso di lavoro valido per tutti: associ i nomi degli stati e le condizioni di transizione locali alle attività richieste.
Configuri ogni regola affinché invii un webhook a [Your webhook endpoint]. Utilizzi POST e il formato JSON. Includa la chiave dell’issue, il tipo di issue, l’assegnatario, la priorità, lo stato, il progetto, il campo del team se disponibile, il timestamp dell’evento, le informazioni sulla transizione, la risoluzione, i valori di Fix Version e l’identificativo dell’evento Jira. Non faccia affidamento su ProcessMind per dedurre le attività dalla cronologia degli stati.
Definisca mappature esplicite delle attività nel ricevitore webhook o nel livello di acquisizione. Ogni webhook pertinente deve generare una riga nell’event log. Associare la creazione di un’issue a Elemento di sviluppo creato, le transizioni di disponibilità a Elemento pronto per lo sviluppo, le transizioni a In Progress a Sviluppo avviato, le transizioni di completamento dello sviluppo o della revisione a Sviluppo completato, le transizioni o gli eventi integrati di revisione a Revisione del codice eseguita, le transizioni ai test a Test QA avviati, le transizioni che segnalano un esito negativo dei test QA a Test QA non superati, quelle che segnalano il superamento dei test a Test QA completati, le transizioni UAT a UAT avviato e UAT approvato, la preparazione al rilascio a Pronto per il rilascio, la distribuzione in produzione o il completamento del rilascio configurato a Distribuito in produzione, la chiusura a Elemento di sviluppo chiuso e l’annullamento o il rifiuto a Elemento di sviluppo annullato.
Applichi la mappatura in base al flusso di lavoro Jira e alla configurazione degli eventi approvati dal responsabile del processo. Ad esempio, associ stati locali come Backlog, To Do, Ready for Dev, In Progress, In Review, Ready for QA, In QA, In Testing, In UAT, Ready for Release, Done, Released, Closed, Canceled, Rejected o Won’t Do solo quando corrispondono al significato aziendale previsto. Eviti di creare più righe per un singolo webhook, a meno che il payload non rappresenti esplicitamente più eventi pertinenti.
Normalizzi ogni evento secondo lo schema richiesto. DevelopmentItem deve contenere la chiave dell’issue Jira, Activity deve corrispondere esattamente a uno dei 14 nomi di attività richiesti, EventTime deve contenere il timestamp dell’evento, SourceSystem deve indicare Jira Software e LastDataUpdate deve contenere il timestamp di aggiornamento dell’acquisizione. Se disponibili, compili anche gli attributi consigliati, tra cui Assignee, ItemType, ItemPriority, ItemStatus, ProjectName e TeamName.
Elimini i duplicati delle consegne webhook utilizzando l’identificativo dell’evento Jira, la chiave dell’issue, il timestamp dell’evento, l’identificativo della transizione e la mappatura dell’attività. Le consegne webhook possono essere ritentate, quindi il ricevitore deve garantire l’idempotenza. Conservi il timestamp originale dell’evento senza sostituirlo con quello di acquisizione.
Convalidi l’event log risultante verificando schema, timestamp, identificativi dei casi, nomi delle attività, gestione dei duplicati e copertura dell’intervallo di date configurato. Verifichi che tutte le 14 attività possano essere registrate come righe e che ProcessMind non debba dedurne nessuna in un secondo momento.
Esporti l’event log normalizzato in formato CSV o in un altro formato di event log supportato da ProcessMind. Includa una riga per ogni evento esplicito e le colonne DevelopmentItem, Activity, EventTime, SourceSystem, LastDataUpdate, Assignee, ItemType, ItemPriority, ItemStatus, ProjectName e TeamName. Carichi il file oppure colleghi l’output del ricevitore in base alla configurazione di acquisizione di ProcessMind.

Configurazione

Metodo e linguaggio di query: configuri le regole Jira Automation e un ricevitore webhook HTTPS. Il valore della query è config, perché l’estrazione si basa sulla configurazione delle regole e sulla normalizzazione degli eventi, non su una query al database Jira.
Identificativo del caso: utilizzi la chiave dell’issue Jira come DevelopmentItem. Non accorpi più issue in un unico caso.
Attività richieste: configuri mappature esplicite per Elemento di sviluppo creato, Elemento pronto per lo sviluppo, Sviluppo avviato, Sviluppo completato, Revisione del codice eseguita, Test QA avviati, Test QA non superati, Test QA completati, UAT avviato, UAT approvato, Pronto per il rilascio, Distribuito in produzione, Elemento di sviluppo chiuso ed Elemento di sviluppo annullato.
Trigger degli eventi: abiliti i trigger per la creazione delle issue, le transizioni del flusso di lavoro, la risoluzione, Fix Version, le integrazioni di revisione e quelle di distribuzione solo quando sono supportati e pertinenti per la configurazione Jira.
Mappatura degli stati: mantenga una tabella o una configurazione di mappatura specifica per progetto, con gli stati e le transizioni Jira locali. Interpreti stati come In Progress, In QA, Done o Closed in base alla semantica approvata del flusso di lavoro.
Intervallo di date: per la convalida iniziale, raccolga gli eventi relativi a un periodo da 3 a 6 mesi. Per la trasmissione continua, avvii il ricevitore prima del periodo di osservazione previsto e predisponga una strategia di riproduzione o recupero degli eventi generati durante le interruzioni.
Filtri: filtri i progetti Jira, i tipi di issue, l’ambito del flusso di lavoro e l’intervallo di date degli eventi desiderati. Company Code e Document Type non sono concetti standard di Jira Software: utilizzi invece il progetto, il tipo di issue e gli altri campi Jira configurati.
Campi del payload: includa la chiave dell’issue, il tipo di issue, l’assegnatario, la priorità, lo stato, il progetto, il campo del team se disponibile, il timestamp dell’evento, i dettagli della transizione, la risoluzione, Fix Version e l’identificativo dell’evento.
Gestione dei timestamp: conservi i timestamp con le informazioni sul fuso orario, quando disponibili. Utilizzi il timestamp dell’evento di origine per EventTime e quello di aggiornamento del ricevitore per LastDataUpdate.
Consegna e sicurezza: utilizzi HTTPS, l’autenticazione supportata dal ricevitore, la convalida delle richieste, la gestione dei nuovi tentativi e l’elaborazione idempotente. Non inserisca credenziali nelle righe dell’event log.
Prestazioni: utilizzi l’acquisizione asincrona, l’elaborazione in gruppi dopo la ricezione se supportata, chiavi di deduplicazione indicizzate e il partizionamento per data dell’evento per i volumi elevati. Eviti di conservare senza limiti i payload webhook nel ricevitore operativo.
Prerequisiti: autorizzazioni per Jira Automation, autorizzazione a configurare le regole del progetto, autorizzazione a visualizzare le issue e i campi pertinenti, un endpoint HTTPS accessibile e gli eventuali piani o strumenti di integrazione Jira necessari per i webhook in uscita e gli eventi di distribuzione.
Qualità dei dati: definisca come gestire le issue eliminate, gli stati rinominati, gli assegnatari mancanti, i campi del team mancanti, la conversione dei fusi orari, le consegne duplicate e gli eventi ricevuti fuori ordine.

a Query di esempio config

{
  "method": "Real-time Event Streaming via Automation Webhooks",
  "approach": "Jira Automation rules send issue event JSON payloads to a configured HTTPS endpoint. The receiver normalizes each qualifying payload into one explicit event-log row.",
  "queryLanguage": "config",
  "confidence": "verified",
  "caseIdentifier": "DevelopmentItem",
  "sourceSystem": "Jira Software",
  "endpoint": "[Your webhook endpoint]",
  "dateFrom": "[Start date and time]",
  "dateTo": "[End date and time]",
  "filters": {
    "projects": "[Configure based on your Jira projects]",
    "issueTypes": "[Configure based on your Jira issue types]"
  },
  "outputColumns": [
    "DevelopmentItem",
    "Activity",
    "EventTime",
    "SourceSystem",
    "LastDataUpdate",
    "Assignee",
    "ItemType",
    "ItemPriority",
    "ItemStatus",
    "ProjectName",
    "TeamName"
  ],
  "activityMappings": [
    {
      "activity": "Development Item Created",
      "trigger": "Issue created",
      "condition": "The Jira issue creation event is received within the configured scope"
    },
    {
      "activity": "Item Ready for Development",
      "trigger": "Workflow transition",
      "condition": "The issue transitions from a configured backlog or specification status to a configured ready-for-development status"
    },
    {
      "activity": "Development Started",
      "trigger": "Workflow transition",
      "condition": "The issue transitions to the configured active development status, commonly In Progress"
    },
    {
      "activity": "Development Completed",
      "trigger": "Workflow transition",
      "condition": "The issue transitions from active development to a configured development-complete, review, or QA-ready status"
    },
    {
      "activity": "Code Review Performed",
      "trigger": "Workflow transition or configured review integration event",
      "condition": "A qualifying code review completion event is received, such as a transition from review to QA-ready"
    },
    {
      "activity": "QA Testing Started",
      "trigger": "Workflow transition",
      "condition": "The issue transitions to a configured QA or testing status"
    },
    {
      "activity": "QA Testing Failed",
      "trigger": "Workflow transition",
      "condition": "The issue transitions backward from a configured QA or testing status to a development or rework status"
    },
    {
      "activity": "QA Testing Completed",
      "trigger": "Workflow transition",
      "condition": "The issue leaves the configured primary QA or testing status through a successful testing transition"
    },
    {
      "activity": "UAT Started",
      "trigger": "Workflow transition",
      "condition": "The issue transitions to a configured UAT or user acceptance testing status"
    },
    {
      "activity": "UAT Approved",
      "trigger": "Workflow transition",
      "condition": "The issue transitions from UAT to a configured approval, release-ready, or completed status"
    },
    {
      "activity": "Prepared For Release",
      "trigger": "Workflow transition or Fix Version field change",
      "condition": "The issue reaches a configured release-ready status or receives a qualifying Fix Version value"
    },
    {
      "activity": "Deployed To Production",
      "trigger": "Configured deployment event or workflow transition",
      "condition": "A production deployment event is received, or the configured final release transition represents production deployment"
    },
    {
      "activity": "Development Item Closed",
      "trigger": "Workflow transition or resolution change",
      "condition": "The issue reaches the configured Closed status and, where required, has a qualifying Resolution value"
    },
    {
      "activity": "Development Item Canceled",
      "trigger": "Workflow transition or resolution change",
      "condition": "The issue reaches a configured canceled, rejected, or won't-do terminal state and, where required, has a qualifying Resolution value"
    }
  ],
  "normalization": {
    "oneRowPerEvent": true,
    "developmentItem": "payload.issue.key",
    "eventTime": "payload.event.timestamp or the source timestamp supplied by the Jira event",
    "sourceSystem": "Jira Software",
    "lastDataUpdate": "receiver ingestion timestamp",
    "assignee": "payload.issue.fields.assignee.displayName or account identifier when available",
    "itemType": "payload.issue.fields.issuetype.name",
    "itemPriority": "payload.issue.fields.priority.name",
    "itemStatus": "payload.issue.fields.status.name",
    "projectName": "payload.issue.fields.project.name",
    "teamName": "payload.issue.fields.team or the configured team field when available"
  },
  "deduplication": {
    "key": "payload.event.id, payload.issue.key, payload.event.timestamp, payload.transition.id, mapped activity",
    "behavior": "Ignore repeated deliveries with the same deduplication key while retaining the first valid event row"
  },
  "requiredConfiguration": [
    "Configure one or more Jira Automation rules for each qualifying event type",
    "Configure the webhook receiver at [Your webhook endpoint]",
    "Configure local Jira status and transition mappings",
    "Configure project and issue-type filters at [Configure based on your Jira projects] and [Configure based on your Jira issue types]",
    "Configure authentication and request validation according to the receiver implementation"
  ]
}

È pronto a iniziare?

Inizi subito a ottimizzare il ciclo di vita dello sviluppo software preparando i dati con questo template. Ottenga informazioni utili per accelerare le consegne e migliorare la qualità.

Torna alla guida al miglioramento Scarica il template

Ottimizzi oggi il ciclo di vita dello sviluppo software in Jira Software!

Individui le inefficienze e riduca del 30% il tempo di ciclo dell’SDLC.

Inizi la prova gratuita

Non è richiesta una carta di credito: inizi a ottimizzare in pochi minuti.

Il Suo template dei dati per il ciclo di vita dello sviluppo software

Il Suo template dei dati per il ciclo di vita dello sviluppo software

Attributi del ciclo di vita dello sviluppo software

Attività del ciclo di vita dello sviluppo software

Guide all’estrazione

Query JQL di Jira con esportazione CSV o XML integrata

Passaggi

Configurazione

a Query di esempio config

Query diretta al database Jira tramite SQL (installazione autonoma)

Passaggi

Configurazione

a Query di esempio sql

Script Python con l’API REST ufficiale di Jira

Passaggi

Configurazione

a Query di esempio python

Trasmissione degli eventi in tempo reale tramite webhook di automazione

Passaggi

Configurazione

a Query di esempio config

È pronto a iniziare?

Ottimizzi oggi il ciclo di vita dello sviluppo software in Jira Software!

Il Suo template dei dati per il ciclo di vita dello sviluppo software

Il Suo template dei dati per il ciclo di vita dello sviluppo software

Attributi del ciclo di vita dello sviluppo software

Attività del ciclo di vita dello sviluppo software

Guide all’estrazione

Query JQL di Jira con esportazione CSV o XML integrata

Passaggi

Configurazione

a Query di esempio config

Query diretta al database Jira tramite SQL (installazione autonoma)

Passaggi

Configurazione

a Query di esempio sql

Script Python con l’API REST ufficiale di Jira

Passaggi

Configurazione

a Query di esempio python

Trasmissione degli eventi in tempo reale tramite webhook di automazione

Passaggi

Configurazione

a Query di esempio config

È pronto a iniziare?

Ottimizzi oggi il ciclo di vita dello sviluppo software in Jira Software!

La Sua privacy è importante