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

L'Ora Inizio Evento registra la data e l'ora esatta in cui un'attività è cominciata. Fornisce l'ordine cronologico necessario per ricostruire accuratamente il flusso del processo.

I timestamp sono la base di ogni analisi temporale nel Process Mining. Servono a calcolare KPI come Cycle Time, tempi di attesa e tempi di lavorazione tra le attività. Analizzarli aiuta a individuare i colli di bottiglia, misurare l'efficienza e capire quanto durano le varie fasi del ciclo di vita. Per esempio, il tempo tra 'Inviato per revisione' e 'Revisione completata' può rivelare intoppi nel processo di review.

Questo timestamp è essenziale per ordinare correttamente gli eventi e calcolare tutte le metriche basate sul tempo, come i cycle time e i bottleneck.

Disponibile negli event log, negli audit trail o nelle tabelle storiche che registrano le modifiche agli elementi di lavoro dello sviluppo.

L'ID Elemento di Sviluppo è la chiave primaria che identifica univocamente ogni caso durante l'intero ciclo di vita. Ogni ID rappresenta un'unità di lavoro distinta — come una User Story, un task o un bug fix — dalla creazione alla risoluzione finale.

Nell'analisi di Process Mining, questo attributo è indispensabile per ricostruire il percorso end-to-end di ogni elemento. Permette allo strumento di collegare tutte le attività correlate (es. 'Sviluppo iniziato', 'Revisione completata', 'Rilasciato') in un flusso coerente. Analizzare il ciclo di vita dei singoli elementi aiuta a identificare varianti, ritardi e cicli di rework legati a specifiche attività.

Questo è l'identificatore del caso fondamentale, necessario per tracciare il ciclo di vita completo di ogni elemento di sviluppo dall'inizio alla fine.

Solitamente si trova nelle tabelle principali degli elementi di lavoro o dei ticket di un sistema di gestione dello sviluppo software.

Il Nome Attività descrive una fase specifica o un cambio di stato nel processo di sviluppo. Queste attività costituiscono i nodi della mappa di processo, rappresentando traguardi come 'Approvato per lo sviluppo', 'Inviato per revisione' o 'Test QA completati'.

Questo attributo è essenziale per visualizzare il flusso e comprendere la sequenza degli eventi. Analizzando le diverse attività, i team possono identificare i percorsi più comuni, scoprire deviazioni e misurare il tempo trascorso in ogni stadio. È il pilastro per l'analisi dei colli di bottiglia, il rilevamento dei rework e il controllo della conformità rispetto al modello di processo target.

Definisce le fasi del processo, consentendo la visualizzazione e l'analisi del Workflow di sviluppo.

Spesso derivato dai log dei cambi di stato, dagli stream di eventi o dalle tabelle di audit history degli elementi di lavoro.

L'attributo Sistema Sorgente identifica l'applicazione o la piattaforma di origine in cui sono stati registrati i dati del ciclo di vita dello sviluppo. È particolarmente utile in ambienti in cui si utilizzano più strumenti, ad esempio Jira per il tracciamento dei ticket e GitLab per la gestione del codice sorgente.

In fase di analisi, specificare il sistema sorgente aiuta nella validazione dei dati e fornisce contesto. Consente analisi comparative tra processi gestiti in sistemi diversi e garantisce che l'interpretazione dei dati sia corretta, poiché i nomi dei campi e le convenzioni di processo possono variare. Può anche essere utilizzato per filtrare l'analisi sul set di dati di uno strumento specifico.

Fornisce il contesto sull'origine dei dati, fondamentale per la validazione e per le analisi che coinvolgono più sistemi integrati.

In genere si tratta di un valore statico aggiunto durante il processo di estrazione dei dati per identificare l'origine dei record.

L'attributo Ultimo Aggiornamento Dati registra data e ora dell'ultima estrazione dal sistema sorgente, indicando quanto le informazioni siano fresche e pertinenti.

Questa informazione è vitale per garantire che analisi e Dashboard si basino su dati attuali. Gli stakeholder possono verificare a colpo d'occhio l'aggiornamento della vista di processo, aumentando la fiducia negli insight ottenuti. Si tratta di un metadato chiave per gestire le pipeline di dati e pianificare i refresh.

Indica quanto sono aggiornati i dati, garantendo che l'analisi sia tempestiva e pertinente per le decisioni.

Questo valore viene solitamente generato e memorizzato dalla pipeline di estrazione, trasformazione e caricamento (ETL) dei dati.

Questo attributo identifica la persona o il gruppo responsabile del completamento del passaggio corrente o dell'intera attività. L'assegnatario può cambiare più volte nel corso del ciclo di vita, riflettendo i passaggi di consegne (handoff) tra diversi ruoli come sviluppatori, tester QA e revisori.

Analizzare l'attributo Assegnato A è fondamentale per comprendere il carico di lavoro del team, l'efficienza degli handoff e i modelli di collaborazione. Consente di filtrare la mappa del processo per vedere il lavoro di una persona o di un team specifico, aiutando a identificare i bottleneck relativi alle risorse. L'analisi dei social network basata sui passaggi di consegne tra gli assegnatari può rivelare lacune comunicative o strutture di collaborazione eccessivamente complesse.

Consente di analizzare il carico di lavoro, la frequenza dei passaggi di consegne e i modelli di collaborazione, ottimizzando l'efficienza dei team.

Presente nel record dell'elemento di lavoro o della segnalazione, spesso tracciato nello storico o nell'audit log.

Questo attributo identifica il team, la squad o il gruppo specifico responsabile della consegna dell'elemento di sviluppo. Nelle grandi organizzazioni, il lavoro è spesso distribuito tra più team specializzati come 'Frontend', 'Backend', 'Mobile' o 'Platform'.

L'analisi per Nome Team consente il confronto delle prestazioni e la condivisione delle best practice tra i team. Aiuta a rispondere a domande come: "Quale team ha il cycle time più breve?" o "Un team subisce più rework rispetto agli altri?". Questa analisi può scoprire differenze nei workflow, nelle competenze o nella disponibilità di risorse che influiscono sulle prestazioni complessive di consegna, offrendo opportunità per miglioramenti mirati del processo.

Permette il benchmarking delle performance tra diversi team, aiutando a identificare le best practice e le aree di miglioramento.

Spesso associato all'utente assegnato o presente come campo diretto nel record del progetto o dell'elemento di lavoro.

Il Nome Progetto fornisce il contesto raggruppando le attività che appartengono a un prodotto, un'iniziativa o una codebase specifica. Le pratiche di sviluppo e i cycle time possono variare significativamente tra i progetti, ad esempio tra un sistema legacy e una nuova applicazione greenfield.

Questo attributo consente un'aggregazione di alto livello e il confronto dei processi di sviluppo tra le diverse aree dell'organizzazione. Filtrando l'analisi per progetto, i manager possono valutare lo stato di salute e l'efficienza di ogni sforzo di sviluppo. È inoltre essenziale per capire come le performance del processo siano correlate al contesto specifico e all'ambiente tecnico di un progetto.

Consente di segmentare l'analisi dei processi per prodotto o iniziativa, evidenziando differenze di performance legate al contesto del progetto.

Un campo standard nel record dell'elemento di lavoro o della segnalazione, oppure il nome del repository in sistemi come Git.

L'Ora Fine Evento indica la conclusione di un'attività. Molti passaggi sono registrati come istantanei, ma alcune attività hanno una durata misurabile (es. una 'Code Review' con inizio e fine distinti).

Questo attributo è essenziale per calcolare il tempo di lavorazione attivo, distinguendolo dai tempi morti o di attesa. Confrontando l'inizio e la fine dell'evento, è possibile misurare l'impegno reale speso in attività che portano valore. Ciò abilita un'analisi granulare dell'uso delle risorse e aiuta a capire quali task assorbono più tempo di lavoro effettivo.

Consente di calcolare il tempo di lavorazione attivo per le singole attività, separandolo dai tempi di attesa e offrendo una visione più chiara dell'impegno richiesto.

Reperibile negli event log o derivabile dal timestamp dell'attività successiva nella sequenza per lo stesso elemento di lavoro.

L'attributo Priorità indica l'urgenza aziendale o tecnica di un'attività. In genere è impostato su valori come 'Alta', 'Media' o 'Bassa' e aiuta i team a decidere su cosa lavorare.

Nel Process Mining, la priorità è una dimensione di analisi fondamentale. Consente ai team di verificare se gli elementi ad alta priorità vengono effettivamente elaborati più velocemente di quelli a bassa priorità. Il confronto dei cycle time tra i diversi livelli di priorità può rivelare se il processo rispetta le priorità aziendali. Se gli elementi ad alta priorità subiscono frequenti ritardi, ciò può indicare problemi nella pianificazione, nell'allocazione delle risorse o nel design del workflow.

Aiuta a verificare se il lavoro ad alta priorità scorre più velocemente e identifica i colli di bottiglia che colpiscono in modo sproporzionato gli elementi critici.

Un campo standard presente nel record dell'elemento di lavoro o della segnalazione nella maggior parte dei sistemi di gestione dello sviluppo.

Lo Stato Elemento di Sviluppo rappresenta la condizione di un'attività in un dato momento. Mentre il Nome Attività registra l'evento del cambio di stato, questo attributo ne fotografa la situazione. È utile per analizzare in che stato si trovasse il lavoro quando si è verificato un evento.

Spesso usato per generare il Nome Attività, può fornire un contesto extra. Per esempio, permette di analizzare quanto tempo gli elementi trascorrono in stati specifici come 'Bloccato' o 'In attesa di revisione'. Comprendere il tempo speso in stati non produttivi è vitale per identificare ritardi sistemici e migliorare l'efficienza del flusso.

Permette di analizzare il tempo trascorso nei vari stati, aiutando a identificare ritardi e tempi morti in fasi senza valore aggiunto come 'Bloccato'.

Disponibile come campo principale nel record dell'elemento di lavoro o della segnalazione e tracciato nel relativo registro storico.

Questo attributo categorizza la natura del lavoro svolto. Diversi tipi di attività seguono spesso percorsi di processo differenti e hanno diverse aspettative di performance. Ad esempio, un 'Bug' potrebbe richiedere un processo di hotfix rapido, mentre una 'Feature' segue un ciclo standard di sviluppo e test.

Utilizzando questo attributo, gli analisti possono confrontare i flussi di processo e le prestazioni per diversi tipi di lavoro. Ciò aiuta a rispondere a domande come: "Il nostro processo di bug-fixing è più veloce dello sviluppo di nuove feature?" o "Gli elementi di debito tecnico subiscono più rework?". È una dimensione fondamentale per segmentare i dati e ottenere insight più specifici e pronti all'uso.

Permette di confrontare processi e performance tra diverse categorie di lavoro, rivelando inefficienze specifiche di determinati tipi di sviluppo.

Un campo standard presente nel record dell'elemento di lavoro o della segnalazione nella maggior parte dei sistemi di gestione dello sviluppo.

L'attributo Autore identifica chi ha dato inizio all'elemento di lavoro. Può trattarsi di un Product Manager che crea una User Story, di un tester QA che registra un bug o di un addetto al supporto clienti.

Analizzare l'autore degli elementi fornisce insight sulle fonti del lavoro. Per esempio, un alto numero di bug segnalati dagli utenti finali potrebbe indicare problemi qualitativi nei rilasci recenti. Inoltre, correlando l'autore con eventuali rework o ritardi successivi, è possibile valutare la chiarezza e la qualità dei requisiti iniziali.

Aiuta a identificare chi genera il lavoro, permettendo di analizzare l'origine di richieste, bug o nuove funzionalità.

Un campo standard come 'Reporter' o 'Autore' nel record di creazione iniziale di un elemento di lavoro.

La gravità (Severity) è distinta dalla priorità: la prima misura l'impatto tecnico di un problema, mentre la seconda ne misura l'urgenza di risoluzione. Ad esempio, un refuso su una pagina poco visitata può avere gravità e priorità basse, mentre un problema di corruzione dei dati avrà gravità e priorità massime.

Questo attributo è fondamentale per l'analisi della qualità, specialmente nei processi di bug-fixing. Permette ai team di valutare se stanno affrontando tempestivamente le criticità maggiori. Analizzando il Cycle Time per i diversi livelli di gravità, le organizzazioni possono assicurarsi che i problemi critici vengano risolti rapidamente per minimizzare l'impatto sui clienti.

Consente di analizzare l'efficacia con cui il team affronta i problemi in base al loro impatto tecnico, assicurando che le criticità siano risolte tempestivamente.

Un campo standard, particolarmente indicato per gli elementi di lavoro di tipo 'Bug' o 'Incident', nei sistemi di gestione dello sviluppo.

L'Indicatore di Rework è un attributo derivato (booleano o categoriale) che contrassegna gli eventi come parte di un ciclo di rework. In genere viene identificato quando il flusso del processo torna indietro, ad esempio da 'QA Testing' a 'Development in Progress', o quando si verificano specifiche attività come 'Rework identificato in QA'.

Questo attributo è prezioso per l'analisi della qualità e dell'efficienza. Consente il calcolo diretto dei tassi di rework e mette in luce le fasi del processo che ne generano di più. Filtrando per le attività di rework, i team possono eseguire un'analisi delle cause radice (root cause analysis) per capire perché i problemi di qualità non vengono individuati prima. Ridurre il rework è una leva fondamentale per migliorare sia la velocità di sviluppo che la qualità del prodotto.

Quantifica direttamente il rework, permettendo ai team di misurarne la frequenza, analizzarne le cause e monitorare i miglioramenti della qualità nel tempo.

In genere viene derivato durante la trasformazione dei dati identificando loop all'indietro nel flusso di processo o nomi di attività specifici legati a errori o fallimenti.

L'attributo Rilascio pianificato collega un elemento di sviluppo a uno specifico piano di consegna o versione. Viene spesso utilizzato nella pianificazione delle release per raggruppare feature e bug fix per un deployment coordinato.

Analizzare i dati in base al Rilascio pianificato aiuta a valutare la prevedibilità e l'affidabilità del processo di rilascio. Consente di monitorare i tassi di puntualità nelle consegne confrontando la release pianificata con la data di deployment effettiva. Inoltre, aiuta a gestire lo scope e a comprendere il flusso di lavoro destinato a una specifica release, evidenziando potenziali rischi o ritardi che potrebbero influire sulla timeline di consegna.

Collega il lavoro di sviluppo ai programmi di consegna, permettendo di analizzare i tassi di puntualità e la prevedibilità dei rilasci.

Un campo standard come 'Fix Version', 'Target Release' o 'Iteration Path' negli strumenti di pianificazione e sviluppo Agile.