Il Suo Modello di Dati per il Ciclo di Vita dello Sviluppo Software

Jira Software
Il Suo Modello di Dati per il Ciclo di Vita dello Sviluppo Software

Il Suo Modello di Dati per il Ciclo di Vita dello Sviluppo Software

Questo template fornisce una roadmap chiara per la raccolta dei dati essenziali necessari per analizzare il Suo ciclo di vita dello sviluppo software. Delinea i campi dati principali da raccogliere, le fasi critiche del processo da monitorare e una guida pratica su come estrarre queste informazioni da Jira Software. Utilizzi questa guida per preparare il Suo log degli eventi per un Process Mining efficace.
  • Attributi consigliati da raccogliere
  • Attività chiave da tracciare
  • Guida all'estrazione per Jira Software
È nuovo agli event log? Impari come creare un event log di Process Mining.

Attributi del ciclo di vita dello sviluppo software

Questi sono i campi dati consigliati da includere nel Suo log degli eventi per un'analisi completa del ciclo di vita dello sviluppo software.
5 Obbligatorio 6 Consigliato 11 Facoltativo
Nome Descrizione
Activity
Activity
Il nome di uno specifico evento o cambio di stato verificatosi nel ciclo di vita dello sviluppo di un elemento.
Descrizione

Questo attributo rappresenta un passaggio distinto o una pietra miliare nel processo di sviluppo software. Queste attività derivano dai cambiamenti nel campo di stato del ticket Jira o da altri eventi significativi come commit del codice o revisioni.\n\nNel Process Mining, la sequenza di queste attività forma la mappa del processo. L'analisi delle attività aiuta a identificare il flusso del processo, misurare la durata di fasi specifiche e rilevare deviazioni dal workflow standard, come cicli di rilavorazione o Quality Gate saltati.

Perché è importante

Le attività definiscono le fasi del processo e la loro sequenza è essenziale per visualizzare il flusso, identificare i bottleneck e analizzare le varianti di processo.

Dove trovare

Tipicamente derivato dalle transizioni del campo "status" nella cronologia o nel changelog del ticket Jira. Può anche essere arricchito con dati provenienti da strumenti di sviluppo collegati.

Esempi
Inizio sviluppoRevisione del codice eseguitaTesting QA completatoRilasciato in produzione
Elemento di sviluppo
DevelopmentItem
L'identificatore unico per una singola unità di lavoro, come una story, un bug o un task, all'interno di Jira Software.
Descrizione

L'Elemento di Sviluppo funge da identificatore primario del caso (case identifier), rappresentando un'unità di lavoro distinta come una funzionalità, la correzione di un bug o un task. Collega tutte le attività dalla concezione iniziale e pianificazione fino allo sviluppo, al testing e al rilascio per quello specifico elemento. In Jira, questo corrisponde solitamente alla chiave del ticket (issue key), ad esempio "PROJ-123".\n\nL'analisi di questo attributo consente di tracciare l'intero ciclo di vita end-to-end di ogni elemento di lavoro. È la base per la costruzione delle mappe di processo, il calcolo dei tempi di ciclo e l'identificazione delle variazioni nel modo in cui i diversi elementi fluiscono attraverso il processo di sviluppo.

Perché è importante

Questa è la chiave essenziale per collegare tra loro tutte le attività di sviluppo correlate, rendendo possibile tracciare il percorso di un singolo elemento di lavoro dall'inizio alla fine.

Dove trovare

Questo è il campo standard "key" per un ticket nell'oggetto dell'API Jira Software Issue.

Esempi
PROJ-101CORE-5432API-789
Timestamp Evento
EventTime
La data e l'ora esatte in cui si è verificata una specifica attività o evento di sviluppo.
Descrizione

L'Event Time è il timestamp che registra il momento esatto in cui si è svolta un'attività. Rappresenta la base temporale per ogni analisi di Process Mining, fornendo l'ordine cronologico degli eventi per 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 le performance del processo nel tempo, aiutando a capire quando e dove si verificano i ritardi nel ciclo di vita dello sviluppo.

Perché è importante

Questo timestamp è fondamentale per sequenziare correttamente gli eventi e calcolare tutte le metriche basate sulla durata, che sono fondamentali per comprendere l'efficienza dei processi e identificare i ritardi.

Dove trovare

Corrisponde al timestamp "created" per ogni voce nel changelog o nella cronologia di un ticket.

Esempi
2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
Sistema di Origine
SourceSystem
Il sistema da cui sono stati estratti i dati del ciclo di vita dello sviluppo.
Descrizione

Questo attributo identifica l'origine dei dati. Per questo processo sarà costantemente "Jira Software", ma è utile per distinguere i dati se più sistemi sorgente vengono combinati in un'analisi più ampia.\n\nIn un panorama IT più vasto, specificare il sistema sorgente garantisce che la stirpe dei dati (data lineage) sia chiara e aiuta a gestire la qualità dei dati e gli sforzi di integrazione tra diverse piattaforme.

Perché è importante

Garantisce una chiara provenienza dei dati, fondamentale quando si integrano informazioni da più sistemi o per scopi di governance e auditing.

Dove trovare

Questo è un valore statico che dovrebbe essere aggiunto durante il processo di estrazione e trasformazione dei dati.

Esempi
Jira Software
Ultimo `Data Update`
LastDataUpdate
Il timestamp che indica quando i dati di questo processo sono stati aggiornati l'ultima volta dal sistema sorgente.
Descrizione

Questo attributo registra la data e l'ora della più recente estrazione di dati da Jira Software. Fornisce il contesto sulla freschezza dei dati analizzati.\n\nConoscere l'ora dell'ultimo aggiornamento è importante per comprendere quanto siano attuali gli insight sul processo. Aiuta gli analisti e gli utenti aziendali a confermare che stanno consultando dati aggiornati e li informa sul punto di interruzione per gli eventi inclusi nell'analisi.

Perché è importante

Indica l'aggiornamento dei dati, fondamentale per garantire che analisi e dashboard riflettano lo stato attuale del processo.

Dove trovare

Questo timestamp viene generato e registrato alla fine del processo di estrazione, trasformazione e caricamento (ETL) dei dati.

Esempi
2024-03-15T02:00:00Z2024-03-16T02:00:00Z
Assegnatario
Assignee
L'utente attualmente assegnato alla gestione dell'elemento di sviluppo.
Descrizione

L'Assegnatario (Assignee) è la persona responsabile dell'elemento di lavoro nella sua fase attuale. In Jira, questo è un campo standard che cambia man mano che l'elemento si sposta tra persone e team diversi.\n\nL'analisi dell'assegnatario è fondamentale per comprendere l'allocazione delle risorse, la distribuzione del carico di lavoro e i punti di passaggio di consegna. Aiuta a rispondere a domande su quali sviluppatori o team siano coinvolti in fasi specifiche, chi rappresenti un collo di bottiglia e come il lavoro sia distribuito nell'organizzazione.

Perché è importante

Identifica l'utente o la risorsa responsabile di un'attività, consentendo l'analisi del carico di lavoro, la gestione delle risorse e la comprensione degli handoff.

Dove trovare

Questo è il campo "assignee" all'interno dell'oggetto "fields" della risposta dell'API Jira Issue.

Esempi
Alice SmithBob JohnsonNon assegnato
Nome del team
TeamName
Il team di sviluppo responsabile dell'elemento di lavoro.
Descrizione

Rappresenta lo specifico team agile o di funzionalità assegnato all'elemento di sviluppo. In Jira, questo è spesso implementato come campo personalizzato o può essere derivato da altre informazioni come il progetto o un componente specifico.\n\nQuesto attributo è essenziale per l'analisi delle prestazioni a livello di team. Consente di filtrare le dashboard per mostrare metriche come il tempo di ciclo, il tasso di rilavorazione e il throughput per i singoli team. È fondamentale per le dashboard "Efficienza dei passaggi di consegna tra le fasi" e "Carico di lavoro degli sviluppatori e progresso degli elementi".

Perché è importante

Consente di misurare le prestazioni e confrontare i diversi team di sviluppo, aiutando a identificare i team più performanti e a condividere le best practice.

Dove trovare

Spesso si tratta di un campo personalizzato in Jira. Consulti il Suo amministratore Jira per identificare il nome specifico del campo, che potrebbe essere "Team", "Squad" o simile.

Esempi
Team PhoenixServizi PrincipaliUI/UX Avengers
Nome progetto
ProjectName
Il 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 Progetto' fornisce un contesto di alto livello, spesso corrispondente a un prodotto, un team o un'iniziativa specifica.

Questo attributo è una dimensione potente per il filtraggio e il confronto. Consente di analizzare e confrontare il processo SDLC tra diversi progetti o prodotti, rivelando quali sono più efficienti, quali presentano più rework e se i diversi team seguono varianti di processo differenti.

Perché è importante

Permette di segmentare l'analisi del processo per progetto, prodotto o team, consentendo confronti di performance e l'identificazione di best practice.

Dove trovare

Questo è il campo "project" all'interno dell'oggetto "fields" della risposta dell'API Jira Issue.

Esempi
Sviluppo di app mobiliPiattaforma CoreData Science
Priorità elemento
ItemPriority
Il livello di priorità assegnato all'elemento di sviluppo, che ne indica l'urgenza.
Descrizione

La Priorità definisce l'importanza relativa o l'urgenza di un ticket. Jira offre un campo standard con livelli configurabili (es. Highest, High, Medium, Low).

L'analisi della priorità è fondamentale per verificare la conformità e identificare bottleneck sugli elementi critici. Ad esempio, la dashboard 'Controllo conformità priorità' usa questo attributo per verificare se i ticket urgenti sono accelerati come previsto o se restano bloccati nelle stesse code dei ticket a bassa priorità.

Perché è importante

Aiuta ad analizzare se gli elementi ad alta priorità sono elaborati più velocemente degli altri e se seguono un percorso più snello, garantendo il rispetto degli SLA.

Dove trovare

Questo è il campo "priority" all'interno dell'oggetto "fields" della risposta dell'API Jira Issue.

Esempi
MassimaElevatoMedioBasso
Stato dell'Articolo
ItemStatus
Lo stato attuale dell'elemento di sviluppo all'interno del suo workflow.
Descrizione

Questo attributo riflette la fase specifica dell'elemento di sviluppo in un dato momento, come "In corso", "In revisione" o "Fatto". La sequenza dei cambi di stato nel tempo è ciò che genera le attività per il Process Mining.\n\nMentre l'attributo "Attività" rappresenta l'evento di cambiamento, lo "StatoElemento" fornisce lo stato dell'elemento stesso. È utile come dimensione per il filtraggio e l'analisi, consentendo di vedere quanti elementi si trovano attualmente in uno stato specifico o di analizzare le caratteristiche degli elementi che rimangono in un determinato stato per molto tempo.

Perché è importante

Fornisce un'istantanea della posizione di un elemento nel suo ciclo di vita, essenziale per l'analisi basata sullo stato e per comprendere lo stato attuale del lavoro in corso (WIP).

Dove trovare

Questo è il campo "status" all'interno dell'oggetto "fields" della risposta dell'API Jira Issue.

Esempi
Da fareIn CorsoIn RevisioneCompletato
Tipo Articolo
ItemType
La classificazione dell'elemento di sviluppo, come Bug, Story, Task o Epic.
Descrizione

Il 'Tipo di ticket' categorizza la natura del lavoro svolto. Jira usa il campo standard 'issuetype' per distinguere i diversi tipi di lavoro, che spesso seguono workflow specifici.

Questo attributo è essenziale per l'analisi comparativa. Consente di filtrare il processo per tipologie specifiche, ad esempio per confrontare il ciclo di vita di un 'Bug' rispetto a una 'Story'. Aiuta a capire quali tipi di lavoro sono più soggetti a ritardi, rework o deviazioni dal processo standard.

Perché è importante

Consente di segmentare l'analisi del processo per confrontare la gestione di diverse tipologie di lavoro (es. bug rispetto a nuove funzionalità) e scoprire dove i processi divergono.

Dove trovare

Questo è il campo "issuetype" all'interno dell'oggetto "fields" della risposta dell'API Jira Issue.

Esempi
StoryBugTaskEpic
Componente
Component
Una sottosezione o un'area funzionale del progetto a cui appartiene l'elemento.
Descrizione

I componenti in Jira vengono utilizzati per raggruppare i ticket di un progetto in parti più piccole e gestibili. Possono rappresentare un'area di funzionalità (es. 'Autenticazione utente'), un livello tecnico (es. 'API Backend') o un modulo (es. 'Reportistica').

L'analisi per componente offre una visione granulare del processo di sviluppo. Aiuta a identificare se parti specifiche dell'applicazione generano più bug, hanno cicli di sviluppo più lunghi o richiedono più rework, segnalando aree di debito tecnico o elevata complessità.

Perché è importante

Consente di segmentare il processo per aree funzionali o tecniche del prodotto, aiutando a individuare quali componenti generano ritardi o problemi qualitativi.

Dove trovare

Questo è il campo standard "components" all'interno dell'oggetto "fields" della risposta dell'API Jira Issue.

Esempi
Interfaccia utenteDatabaseAPI GatewayAutenticazione
È una Rilavorazione
IsRework
Un flag che 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, come il ritorno a "Sviluppo avviato" dopo il fallimento del testing QA. Viene determinato analizzando la sequenza delle attività per un caso.\n\nIdentificare la rilavorazione è 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 lo sforzo sprecato e di individuare le cause profonde dei problemi di qualità che portano alla rilavorazione.

Perché è importante

Contrassegna esplicitamente le attività che fanno parte di loop di rework inefficienti, permettendo una misurazione precisa degli sprechi di processo e dei problemi qualitativi.

Dove trovare

Si tratta di un attributo calcolato. Richiede la definizione del flusso di processo previsto e la successiva segnalazione di qualsiasi attività che devii tornando a una fase precedente.

Esempi
truefalse
Fix Version
FixVersion
La versione del software in cui l'elemento di sviluppo è stato effettivamente risolto e rilasciato.
Descrizione

La "Fix Version" in Jira indica il rilascio che contiene il lavoro completato per un elemento. Segna l'esito concreto dello sforzo di sviluppo.\n\nQuesto attributo fornisce il contesto del rilascio effettivo, che può essere confrontato con la "VersioneRilascioPianificata" per analizzare le prestazioni di consegna. Viene anche utilizzato per raggruppare tutti gli elementi consegnati in un rilascio specifico per una vista consolidata di quanto realizzato.

Perché è importante

Conferma in quale rilascio è stato incluso un lavoro, fornendo il dato oggettivo per l'analisi dei rilasci e il monitoraggio delle funzionalità consegnate.

Dove trovare

Corrisponde al campo "fixVersions" nella risposta dell'API Jira Issue.

Esempi
Hotfix v2.1.1Release Major v3.0.0v2.2.0
Nome sprint
SprintName
Il nome dello sprint agile a cui è assegnato l'elemento di sviluppo.
Descrizione

Per i team che usano Scrum, lo Sprint è il periodo di tempo predefinito in cui viene completato un set di lavoro. Questo attributo cattura il nome o l'identificativo dello sprint a cui appartiene un elemento.

L'analisi per sprint è fondamentale per il Process Mining orientato alle metodologie Agile. Aiuta a valutare le performance dei singoli sprint, a comprendere il lavoro residuo (carry-over) e a monitorare i progressi rispetto agli obiettivi. Fornisce un contesto temporale molto più specifico dei semplici intervalli di date.

Perché è importante

Fornisce un contesto critico per i team agile, consentendo l'analisi dell'efficienza dei processi e del throughput sprint per sprint.

Dove trovare

Queste informazioni sono solitamente 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 del PI di novembre
Ora Fine Evento
EventEndTime
Il timestamp di quando un'attività o uno stato sono stati completati.
Descrizione

Questo attributo segna il tempo di completamento di un'attività. È il timestamp dell'attività successiva nella sequenza per un dato caso.\n\nMentre l'"EventTime" (OraInizio) segna l'inizio di un'attività, l'"EventEndTime" ne segna la fine. La differenza tra questi due timestamp è il tempo di elaborazione per quell'attività. Questo è fondamentale per il calcolo del KPI "Tempo medio di elaborazione della fase" e per la creazione di dashboard che analizzano le durate delle attività.

Perché è importante

Definisce il punto finale di un'attività, rendendo possibile il calcolo della durata di ogni fase, elemento essenziale per l'analisi dei bottleneck.

Dove trovare

Si tratta di un attributo derivato. Per un dato evento, la sua ora di fine è l'ora di inizio dell'evento successivo per lo stesso caso.

Esempi
2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
Rilascio pianificato
PlannedReleaseVersion
La versione del software o il rilascio target in cui è previsto il deployment dell'elemento.
Descrizione

Questo attributo, spesso corrispondente al campo "Versione/i interessata/e" in Jira, indica il rilascio previsto per una funzionalità o una correzione. Funge da scadenza o obiettivo per il completamento del lavoro.\n\nSi tratta di un attributo critico per il KPI "Tasso di consegna puntuale dei rilasci". Confrontando la data di rilascio effettiva con la data di rilascio pianificata associata a questa versione, è possibile misurare il rispetto della tabella di marcia e la prevedibilità del Suo processo di rilascio.

Perché è importante

Definisce la data di consegna prevista o il rilascio, consentendo il calcolo dei tassi di puntualità e l'analisi del rispetto dei tempi.

Dove trovare

Corrisponde ai campi "versions" o "fixVersions" nell'API Jira Issue. Il campo specifico utilizzato per la pianificazione può variare.

Esempi
Versione 2.1Rilascio Q1 2024Lancio del Progetto Phoenix
Risoluzione elemento
ItemResolution
L'esito finale o il motivo della chiusura di un elemento di sviluppo.
Descrizione

La Risoluzione spiega perché un elemento è stato spostato in uno stato chiuso. Mentre lo stato potrebbe essere "Chiuso", la risoluzione potrebbe essere "Fatto", "Non verrà fatto", "Duplicato" o "Impossibile riprodurre". Questo fornisce un contesto cruciale sull'esito del lavoro.\n\nL'analisi della risoluzione aiuta a distinguere tra lavori completati con successo ed elementi annullati o rifiutati. È importante per l'analisi della qualità e per comprendere il throughput effettivo del lavoro di valore rispetto all'impegno speso per elementi che sono stati infine scartati.

Perché è importante

Distingue tra elementi completati con successo e quelli chiusi per altri motivi, un dato vitale per analisi accurate su produttività e qualità.

Dove trovare

Questo è il campo "resolution" all'interno dell'oggetto "fields" della risposta dell'API Jira Issue. In genere viene popolato solo quando un ticket viene chiuso.

Esempi
CompletatoNon si faràDuplicatoImpossibile riprodurre
Segnalante
Reporter
L'utente che ha originariamente creato o segnalato l'elemento di sviluppo.
Descrizione

Il Segnalatore (Reporter) è la persona che ha creato il ticket in Jira. Potrebbe trattarsi di uno sviluppatore, un addetto al testing QA, un product manager o persino un cliente tramite un'integrazione con il service desk.\n\nL'analisi del segnalatore può fornire insight sull'origine del lavoro. Ad esempio, è possibile analizzare se i bug segnalati dal team QA hanno un ciclo di vita diverso rispetto a quelli segnalati dai clienti. Può anche aiutare a comprendere i modelli di comunicazione e il flusso di informazioni all'inizio del processo.

Perché è importante

Identifica l'origine dell'elemento di lavoro, permettendo di analizzare i pattern in base a chi crea i task o segnala i bug.

Dove trovare

Questo è il campo "reporter" all'interno dell'oggetto "fields" della 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 il tempo di coda tra il completamento di un'attività e l'inizio della successiva. Rappresenta il tempo in cui il lavoro è fermo in attesa che qualcuno lo prenda in carico.\n\nSi tratta di una metrica critica per il KPI "Tempo medio di attesa del passaggio di consegna" e per la dashboard "Efficienza dei passaggi di consegna tra le fasi". Tempi di consegna elevati indicano spesso problemi di coordinamento, vincoli di risorse o comunicazione inefficiente tra i team, ad esempio tra Sviluppo e QA. Ridurre al minimo questo tempo di inattività è una leva fondamentale per ridurre il tempo di ciclo complessivo.

Perché è importante

Evidenzia i tempi di inattività o di coda, esponendo inefficienze negli handoff tra team o individui e rivelando problemi di coordinamento.

Dove trovare

Si tratta di una metrica calcolata. È l'ora di inizio di un'attività meno l'ora di fine dell'attività precedente per lo stesso caso.

Esempi
017280043200
Tempo di ciclo totale
CycleTime
La durata totale end-to-end di un elemento di sviluppo.
Descrizione

Il Tempo di Ciclo (Cycle Time) misura il tempo totale trascorso dalla creazione di un ticket di sviluppo alla sua risoluzione finale, come il deployment in produzione. Viene calcolato a livello di caso come differenza tra il timestamp del primo evento e quello dell'ultimo.

È un KPI fondamentale per misurare la velocità e l'efficienza complessiva del processo. Il KPI 'Tempo medio di ciclo end-to-end' e la dashboard 'Analisi globale del cycle time SDLC' si basano direttamente su questo calcolo. Ridurre il cycle time è spesso l'obiettivo primario delle iniziative di miglioramento dei processi.

Perché è importante

Misura la velocità end-to-end del processo di sviluppo, fornendo un indicatore chiave di prestazione (KPI) per l'efficienza complessiva e la velocità di consegna.

Dove trovare

Si tratta di un attributo calcolato a livello di caso. È il timestamp dell'ultimo evento meno il timestamp del primo evento per un determinato "ElementoDiSviluppo".

Esempi
12096002592000604800
Tempo di Elaborazione
ProcessingTime
Il tempo attivo totale trascorso su una specifica attività.
Descrizione

Il Tempo di Elaborazione è la durata trascorsa da un elemento in uno stato o attività specifica. Viene calcolato come differenza tra l'EventEndTime e l'EventTime per un singolo evento nel log.\n\nQuesta metrica è un componente fondamentale dell'analisi dei colli di bottiglia e viene utilizzata direttamente nel KPI "Tempo medio di elaborazione della fase". Aggregando il tempo di elaborazione per ogni attività, è possibile vedere chiaramente quali fasi del ciclo di vita dello sviluppo richiedono più tempo, aiutando a focalizzare gli sforzi di miglioramento.

Perché è importante

Misura direttamente la durata di ogni attività, rendendola una metrica primaria per identificare quali fasi del processo rappresentano i colli di bottiglia più lenti.

Dove trovare

Si tratta di una metrica calcolata, derivata sottraendo l'"EventTime" dall'"EventEndTime" per ogni riga nel log degli eventi.

Esempi
86400360000604800
Obbligatorio Consigliato Facoltativo

Attività del ciclo di vita dello sviluppo software

Questi sono i passaggi chiave del processo e le pietre miliari (milestone) da acquisire nel log degli eventi per una scoperta accurata del processo SDLC.
6 Consigliato 8 Facoltativo
Activity Descrizione
Elemento di sviluppo creato
Questo segna l'inizio del ciclo di vita, quando un nuovo elemento di sviluppo, come una story, un bug o un task, viene formalmente registrato in Jira. Questo evento viene catturato esplicitamente dal sistema con un timestamp di creazione per ogni ticket.
Perché è importante

Questa attività funge da inizio definitivo del processo, il che è essenziale per calcolare i tempi di ciclo end-to-end e monitorare il volume totale del lavoro in entrata.

Dove trovare

Si tratta di un evento fondamentale per ogni ticket Jira. Il timestamp di creazione è memorizzato nel campo "created" del record del ticket, accessibile tramite l'API di Jira.

Acquisisci

Il campo timestamp "created" sull'oggetto Issue di Jira.

Tipo di evento explicit
Inizio sviluppo
Rappresenta il momento in cui uno sviluppatore inizia a lavorare attivamente sull'elemento di sviluppo. Questo dato viene quasi sempre catturato deducendo un cambio di stato all'interno del workflow di Jira, ad esempio quando lo stato del ticket passa a "In corso".
Perché è importante

Si tratta di una pietra miliare cruciale per misurare il tempo di sviluppo attivo. Aiuta a distinguere tra tempo di attesa e lavoro a valore aggiunto, una metrica chiave per identificare i colli di bottiglia.

Dove trovare

Dedotto dal changelog di Jira come timestamp del primo passaggio dello stato a 'In Progress', 'In Development' o stati simili di attività.

Acquisisci

Timestamp del cambio di stato in "In corso".

Tipo di evento inferred
Rilasciato in produzione
Questo evento segna il momento in cui le modifiche al codice associate all'elemento di sviluppo sono live nell'ambiente di produzione. Questo può essere dedotto da un cambio di stato finale in "Fatto" o "Rilasciato", oppure catturato tramite un evento esplicito da uno strumento di CI/CD integrato.
Perché è importante

Questo è l'endpoint di successo primario per il processo. È essenziale per calcolare il tempo di ciclo totale end-to-end e misurare la frequenza di deployment e il throughput.

Dove trovare

Può essere dedotto dal changelog del ticket Jira quando lo stato passa a 'Released' o 'Done'. Per una maggiore accuratezza, può essere acquisito dagli eventi di deployment inviati da strumenti CI/CD come Jenkins, Bamboo o tramite la funzione Deployments di Jira.

Acquisisci

Timestamp del cambio di stato in "Fatto" o "Rilasciato".

Tipo di evento inferred
Testing QA avviato
Questo evento segna l'inizio della fase formale di testing di Quality Assurance per l'elemento di sviluppo. Viene dedotto da un cambio di stato in Jira quando il ticket viene spostato in uno stato come "In QA", "In Testing" o "Pronto per il testing".
Perché è importante

Si tratta di una pietra miliare fondamentale che avvia il ciclo di convalida della qualità. Misurare il tempo da "Sviluppo completato" a questo punto mette in evidenza i ritardi nel passaggio di consegna tra i team Dev e QA.

Dove trovare

Dedotto dal changelog di Jira come timestamp del passaggio allo stato di test designato (es. 'In QA').

Acquisisci

Timestamp del cambio di stato in "In QA" o "In testing".

Tipo di evento inferred
Testing QA completato
Indica che l'elemento di sviluppo ha superato con successo tutti i controlli di Quality Assurance ed è pronto per la fase successiva, come lo User Acceptance Testing o il rilascio. Viene dedotto da un cambio di stato dallo stato di test principale.
Perché è importante

Questo segna il completamento di un importante Quality Gate. L'analisi della durata della fase QA aiuta a ottimizzare i processi di testing e l'allocazione delle risorse.

Dove trovare

Dedotto dal changelog di Jira come timestamp del passaggio da 'In QA' a uno stato successivo come 'Ready for UAT' o 'Ready for Release'.

Acquisisci

Timestamp del cambio di stato da "In QA" a "Pronto per lo UAT".

Tipo di evento inferred
UAT approvato
Rappresenta il completamento con successo dello User Acceptance Testing, indicando l'approvazione del rilascio da parte degli stakeholder. Viene dedotto da un cambio di stato da "In UAT" a uno stato come "Pronto per il rilascio" o "Fatto".
Perché è importante

Questa pietra miliare conferma l'accettazione da parte del business e dà il via libera all'elemento per il deployment in produzione. È un gate critico per garantire che il lavoro consegnato soddisfi le aspettative degli utenti.

Dove trovare

Dedotto dal changelog di Jira come timestamp del passaggio dallo stato 'In UAT' allo stato successivo, a indicare l'approvazione.

Acquisisci

Timestamp del cambio di stato da "In UAT" a "Pronto per il rilascio".

Tipo di evento inferred
Elemento di sviluppo annullato
Rappresenta l'interruzione di un elemento di sviluppo prima del completamento. Viene dedotto da un cambio di stato verso uno stato terminale come "Annullato", "Rifiutato" o "Non verrà fatto", spesso accompagnato da una risoluzione specifica.
Perché è importante

Questa attività traccia gli esiti non positivi del processo. Analizzare il motivo per cui gli elementi vengono annullati può rivelare problemi nella pianificazione, nella definizione delle priorità o dei requisiti.

Dove trovare

Dedotto dal changelog di Jira come timestamp del cambio di stato in 'Annullato' (Canceled) o 'Non verrà fatto' con relativa risoluzione.

Acquisisci

Timestamp del cambio di stato in "Annullato", "Rifiutato" o "Non verrà fatto".

Tipo di evento inferred
Elemento di sviluppo chiuso
Questa è l'azione amministrativa finale, che conferma che non è previsto ulteriore lavoro sull'elemento. Spesso viene dedotta da un cambio di stato in "Chiuso" e dall'impostazione di un valore nel campo "Risoluzione".
Perché è importante

Rappresenta la fine assoluta del percorso di un elemento. Il confronto con "Distribuito in produzione" può rivelare ritardi amministrativi o periodi di monitoraggio post-rilascio.

Dove trovare

Dedotto dal changelog di Jira come timestamp del momento in cui lo stato diventa 'Chiuso' (Closed) e viene impostata una risoluzione.

Acquisisci

Timestamp del cambio di stato in "Chiuso".

Tipo di evento inferred
Elemento pronto per lo sviluppo
Indica che un elemento è stato pienamente specificato, revisionato e prioritizzato, pronto per lo sviluppo. In genere si deduce da un cambio di stato nel workflow, come il passaggio da 'Backlog' a 'To Do' o 'Pronto per lo sviluppo'.
Perché è importante

Monitorare questo dato aiuta a misurare la prontezza del backlog e il tempo di attesa degli elementi prima dell'inizio dello sviluppo. Isola il tempo di pianificazione e affinamento dal tempo di sviluppo attivo.

Dove trovare

Dedotto dal changelog di Jira come timestamp del passaggio dello stato a 'Pronto per lo sviluppo', 'To Do' o 'Selezionato per lo sviluppo'.

Acquisisci

Timestamp del cambio di stato verso uno stato pronto pre-sviluppo.

Tipo di evento inferred
Preparato per il rilascio
Indica che l'elemento ha superato i controlli ed è stato assegnato a una versione specifica, in attesa di rilascio. Si deduce spesso quando lo stato diventa 'Ready for Release' o viene popolato il campo 'Fix Version'.
Perché è importante

Questa attività aiuta a tracciare la prontezza per il rilascio e il tempo che gli elementi trascorrono in attesa di una finestra di deployment dopo il completamento di tutto il lavoro di sviluppo e testing.

Dove trovare

In genere viene dedotto dal changelog del ticket Jira come cambio di stato in "Pronto per il rilascio". In alternativa, può essere dedotto dal timestamp in cui viene impostato il campo "Fix Version/s".

Acquisisci

Timestamp del cambio di stato in "Pronto per il rilascio" o di quando viene popolata la "Fix Version".

Tipo di evento inferred
Revisione del codice eseguita
Indica che un collega o un lead ha controllato il codice. Si deduce da un cambio di stato (es. da 'In Review' a 'Ready for QA') o direttamente dagli strumenti di sviluppo integrati.
Perché è importante

Questa attività è un Quality Gate fondamentale. L'analisi della sua durata e dei suoi esiti, come la rilavorazione, aiuta a migliorare la qualità del codice e a ridurre i bug riscontrati nelle fasi successive.

Dove trovare

In genere si deduce dal changelog di Jira quando lo stato esce da 'Code Review'. Può anche essere un evento esplicito se sono integrati repository come Bitbucket o GitHub.

Acquisisci

Timestamp del cambio di stato da "In revisione" allo stato successivo.

Tipo di evento inferred
Sviluppo ultimato
Questa attività indica che lo sviluppatore ha terminato la stesura del codice e l'elemento è pronto per la fase successiva, come la revisione del codice o il testing. Viene dedotta da un cambio di stato in Jira, come il passaggio da "In corso" a "In revisione" o "Pronto per la QA".
Perché è importante

Questo segna la fine della fase di sviluppo principale, consentendo l'analisi della durata della stesura del codice e dell'efficienza dei passaggi di consegna al team di Quality Assurance.

Dove trovare

Dedotto dal changelog di Jira catturando il timestamp in cui il campo 'status' passa da uno stato di sviluppo attivo a uno successivo come 'In Review' o 'Ready for QA'.

Acquisisci

Timestamp del cambio di stato da "In corso" a "In revisione" o "Pronto per la QA".

Tipo di evento inferred
Testing QA fallito
Indica che il team QA ha rilevato un difetto, rispedendo il ticket agli sviluppatori. Si deduce da una transizione all'indietro, ad esempio da 'In QA' a 'In Progress' o 'To Do'.
Perché è importante

Questa attività è fondamentale per identificare i cicli di rilavorazione. Tracciarne la frequenza aiuta a quantificare il costo della scarsa qualità ed evidenzia le aree di miglioramento nello sviluppo o nella definizione dei requisiti.

Dove trovare

Dedotto dal changelog di Jira quando lo stato passa da una fase di test (es. 'In QA') a una fase di sviluppo precedente (es. 'In Progress').

Acquisisci

Timestamp del cambio di stato da uno stato di testing a uno stato di sviluppo.

Tipo di evento inferred
UAT avviato
Segna l'inizio dello User Acceptance Testing (UAT), fase in cui gli stakeholder aziendali o gli utenti finali convalidano le nuove funzionalità. Questo viene dedotto da un cambio di stato in Jira verso una fase come "In UAT" o "User Acceptance Testing".
Perché è importante

Questa attività traccia l'inizio della fase di convalida finale prima del rilascio. L'analisi della sua durata è fondamentale per comprendere e ridurre i ritardi causati dalla disponibilità degli stakeholder o dai cicli di feedback.

Dove trovare

Dedotto dal changelog di Jira come timestamp dell'aggiornamento allo stato 'In UAT' o stati equivalenti.

Acquisisci

Timestamp del cambio di stato in "In UAT".

Tipo di evento inferred
Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i dati da Jira Software