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
- Attributi consigliati da raccogliere
- Attività chiave da tracciare
- Guida all'estrazione per Jira Software
Attributi del ciclo di vita dello sviluppo software
| 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
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
|
|||
Attività del ciclo di vita dello sviluppo software
| 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
|
|||