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

L’ID dell’elemento di sviluppo è la chiave primaria che identifica in modo univoco ogni istanza di caso durante l’intero ciclo di vita dello sviluppo software. Ogni ID corrisponde a un’unità di lavoro distinta, come una storia utente, un’attività o la correzione di un bug, dalla creazione fino alla risoluzione o alla distribuzione.

Nell’analisi di Process Mining, questo attributo è essenziale per ricostruire il percorso end-to-end di ogni elemento di lavoro. Consente allo strumento di collegare tutte le attività correlate, come «Sviluppo avviato», «Revisione del codice completata» e «Distribuito in produzione», in un flusso di processo coerente. Analizzare il ciclo di vita dei singoli elementi di sviluppo aiuta a individuare variazioni, ritardi e cicli di rilavorazione associati a specifiche unità di lavoro.

È l’identificativo fondamentale del caso, necessario per tracciare l’intero ciclo di vita di ogni elemento di lavoro di sviluppo, dall’inizio alla fine.

Si trova in genere nelle tabelle principali degli elementi di lavoro o di tracciamento dei problemi di un sistema di gestione dello sviluppo software.

Il nome dell’attività descrive un passaggio specifico o una modifica di stato nel processo di sviluppo. Queste attività costituiscono i nodi della mappa del processo e rappresentano tappe importanti, come «Elemento approvato per lo sviluppo», «Codice inviato per la revisione» o «Test di controllo qualità completati».

Questo attributo è fondamentale per visualizzare il flusso del processo e comprenderne la sequenza degli eventi. Analizzando le diverse attività, i team possono individuare i percorsi più frequenti, rilevare gli scostamenti dal processo e misurare il tempo trascorso nelle varie fasi. È la base per l’analisi dei colli di bottiglia, l’individuazione delle rilavorazioni e il controllo di conformità rispetto a un modello di processo di riferimento.

Definisce i passaggi del processo e consente di visualizzare e analizzare il flusso di lavoro dello sviluppo.

Spesso si ricava dai log delle modifiche di stato, dai flussi di eventi o dalle tabelle della cronologia di audit associate agli elementi di lavoro dello sviluppo.

L’ora di inizio dell’evento indica la data e l’ora esatte in cui è iniziata un’attività. Definisce l’ordine cronologico di tutti gli eventi all’interno di un singolo caso, un elemento essenziale per ricostruire con precisione il flusso del processo.

Le date e le ore sono alla base di tutte le analisi di Process Mining basate sul tempo. Servono a calcolare indicatori chiave come i tempi di ciclo, i tempi di attesa e i tempi di elaborazione tra le attività. Analizzare le date e le ore aiuta a individuare i colli di bottiglia, misurare l’efficienza del processo e comprendere la durata delle diverse fasi del ciclo di vita dello sviluppo. Per esempio, il tempo tra «Codice inviato per la revisione» e «Revisione del codice completata» può rivelare ritardi nel processo di revisione.

Questa data e ora è essenziale per ordinare correttamente gli eventi e calcolare tutte le metriche temporali, come il tempo di ciclo e i colli di bottiglia.

È disponibile nei log degli eventi, nelle tracce di audit o nelle tabelle della cronologia che registrano le modifiche agli elementi di lavoro dello sviluppo.

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

Nell’analisi, specificare il sistema di origine aiuta a convalidare i dati e fornisce il contesto necessario per interpretarli. Consente di confrontare i processi gestiti in sistemi diversi e di interpretare correttamente i dati, poiché i nomi dei campi e le convenzioni di processo possono variare da un sistema all’altro. Può inoltre essere utilizzato per filtrare l’analisi e includere i dati di uno strumento specifico.

Fornisce informazioni sull’origine dei dati, fondamentali per convalidarli e per le analisi che coinvolgono più sistemi integrati.

In genere è un valore statico aggiunto durante l’estrazione dei dati per identificarne l’origine.

L’attributo dell’ultimo aggiornamento dei dati registra la data e l’ora dell’estrazione o dell’aggiornamento più recente dal sistema di origine. Indica chiaramente quanto siano aggiornati e pertinenti i dati.

Questa informazione è fondamentale per garantire che le analisi e le Dashboard si basino su dati aggiornati. Gli stakeholder possono verificare a colpo d’occhio quanto sia attuale la vista del processo, acquisendo così maggiore fiducia nelle informazioni ricavate. È un metadato importante per gestire le pipeline dei dati e pianificarne gli aggiornamenti.

Indica quanto sono aggiornati i dati e aiuta a garantire che l’analisi sia tempestiva e pertinente ai fini decisionali.

Questo valore viene in genere generato e archiviato dalla pipeline di estrazione, trasformazione e caricamento dei dati (ETL).

Questo attributo identifica la persona o il gruppo responsabile del completamento della fase corrente o dell’intero elemento di lavoro. L’assegnatario può cambiare più volte nel corso del ciclo di vita, in corrispondenza dei passaggi di consegne tra ruoli diversi, come sviluppatori, addetti al controllo qualità e revisori.

L’analisi dell’attributo «Assegnato a» è fondamentale per comprendere il carico di lavoro del team, l’efficienza dei passaggi di consegne e le modalità di collaborazione. Consente di filtrare la mappa del processo per visualizzare il lavoro di una persona o di un team specifico e individuare i colli di bottiglia legati alle risorse. L’analisi della rete sociale basata sui passaggi di consegne tra assegnatari può far emergere lacune nella comunicazione o strutture di collaborazione eccessivamente complesse.

Consente di analizzare il carico di lavoro delle risorse, la frequenza dei passaggi di consegne e le modalità di collaborazione, contribuendo a migliorare l’efficienza del team.

È riportato nell’elemento di lavoro o nella scheda dell’attività, spesso nella cronologia dell’elemento o nel registro di controllo.

Il nome del progetto fornisce un contesto raggruppando gli elementi di lavoro associati a un prodotto, un’iniziativa o una base di codice specifici. Le pratiche di sviluppo e i tempi di ciclo possono variare notevolmente da un progetto all’altro, per esempio tra un sistema legacy e una nuova applicazione sviluppata da zero.

Questo attributo consente di aggregare e confrontare a livello generale i processi di sviluppo nelle diverse aree dell’organizzazione. Filtrando l’analisi per progetto, i responsabili possono valutare lo stato e l’efficienza di ciascuna iniziativa di sviluppo. È inoltre essenziale per capire in che modo le prestazioni del processo siano legate al contesto specifico e all’ambiente tecnico del progetto.

Consente di segmentare l’analisi dei processi per prodotto o iniziativa, facendo emergere differenze nelle prestazioni legate al contesto del progetto.

Campo standard nell’elemento di lavoro o nella scheda dell’attività, oppure nome del repository in sistemi come Git.

Questo attributo identifica il team, la squadra o il gruppo specifico responsabile della consegna dell’elemento di sviluppo. Nelle organizzazioni più grandi, il lavoro è spesso distribuito tra team specializzati, come «Frontend», «Backend», «Dispositivi mobili» o «Piattaforma».

L’analisi per nome del team consente di confrontare le prestazioni e condividere le buone pratiche tra i team. Aiuta a rispondere a domande come «Quale team ha il tempo di ciclo più breve?» oppure «Un team deve rifare il lavoro più spesso degli altri?». L’analisi può rivelare differenze nei flussi di lavoro, nelle competenze o nella disponibilità delle risorse che incidono sulle prestazioni complessive delle consegne, offrendo spunti per interventi mirati sui processi.

Consente di confrontare le prestazioni dei diversi team, individuando le buone pratiche e le aree da migliorare.

Spesso è associato all’utente assegnatario oppure è disponibile come campo diretto nella scheda del progetto o dell’elemento di lavoro.

L’ora di fine dell’evento indica quando si conclude un’attività. Molte fasi del processo vengono registrate come eventi istantanei, con ora di inizio e di fine coincidenti, mentre altre hanno una durata misurabile. Per esempio, un’attività di «revisione del codice» può avere un’ora di inizio e un’ora di fine distinte.

Questo attributo è essenziale per calcolare il tempo di elaborazione effettivo delle singole attività, distinguendolo dai tempi di inattività o di attesa. Confrontando l’intervallo tra l’ora di inizio e l’ora di fine dell’evento, gli analisti possono misurare il tempo dedicato alle attività che generano valore. In questo modo è possibile analizzare più nel dettaglio l’impiego delle risorse e individuare le attività che assorbono più tempo di lavoro effettivo.

Consente di calcolare il tempo di elaborazione effettivo delle singole attività, distinguendolo dai tempi di attesa e offrendo una visione più chiara dell’impegno richiesto.

È disponibile nei log degli eventi oppure si può ricavare utilizzando l’indicazione temporale dell’attività successiva nella sequenza relativa allo stesso elemento di lavoro.

L’attributo della priorità indica l’urgenza commerciale o tecnica di un elemento di lavoro. In genere assume valori come «Alta», «Media» o «Bassa» e aiuta i team a decidere su quale attività concentrarsi per prima.

Nel Process Mining, la priorità è una dimensione di analisi utile: permette ai team di verificare se gli elementi ad alta priorità vengono effettivamente gestiti più rapidamente di quelli a bassa priorità. Il confronto dei tempi di ciclo tra i diversi livelli di priorità mostra se il processo rispetta le priorità aziendali. Se gli elementi ad alta priorità subiscono spesso ritardi, potrebbero esserci problemi nella pianificazione, nell’allocazione delle risorse o nella progettazione del flusso di lavoro.

Aiuta a verificare se il lavoro ad alta priorità avanza più rapidamente nel processo e a individuare i colli di bottiglia che incidono in misura sproporzionata sugli elementi critici.

Campo standard presente nell’elemento di lavoro o nella scheda dell’attività nella maggior parte dei sistemi di gestione dello sviluppo.

Lo stato dell’elemento di sviluppo rappresenta la condizione di un elemento di lavoro in un determinato momento. Mentre il nome dell’attività registra il passaggio di stato, questo attributo ne descrive la condizione. Può quindi essere utile per analizzare lo stato del lavoro al momento in cui si è verificato un evento.

Spesso questo attributo viene utilizzato per creare il nome dell’attività, ma può fornire ulteriori informazioni. Per esempio, l’analisi del campo dello stato consente di misurare quanto tempo gli elementi rimangono in una determinata condizione, come «Bloccato» o «In attesa di revisione». Capire quanto tempo viene trascorso in stati non produttivi è fondamentale per individuare ritardi sistemici e migliorare l’efficienza del flusso.

Consente di analizzare il tempo trascorso nei diversi stati, individuando ritardi e permanenze in condizioni che non generano valore, come «Bloccato».

Disponibile come campo principale nell’elemento di lavoro o nella scheda dell’attività e registrato nella relativa cronologia.

Questo attributo classifica la natura del lavoro svolto. Le diverse tipologie di elementi di lavoro seguono spesso percorsi di processo differenti e hanno aspettative diverse in termini di prestazioni. Per esempio, un bug può richiedere un processo rapido di correzione urgente, mentre una funzionalità segue un ciclo standard di sviluppo e test.

Questo attributo permette agli analisti di confrontare i flussi di processo e le prestazioni delle diverse tipologie di lavoro. Aiuta a rispondere a domande come «Il processo di correzione dei bug è più rapido di quello di sviluppo delle funzionalità?» oppure «Gli elementi relativi al debito tecnico richiedono più rilavorazioni?». È una dimensione fondamentale per segmentare i dati e ottenere informazioni più specifiche e utili per intervenire.

Consente di confrontare i processi e le prestazioni tra diverse categorie di lavoro, facendo emergere le inefficienze specifiche di alcune tipologie di sviluppo.

Campo standard presente nell’elemento di lavoro o nella scheda dell’attività nella maggior parte dei sistemi di gestione dello sviluppo.

L’attributo del creatore identifica la persona che ha avviato l’elemento di lavoro. Può trattarsi di un responsabile di prodotto che crea una storia utente, di un addetto al controllo qualità che registra un bug o di un operatore del servizio clienti che segnala un problema.

L’analisi di chi crea gli elementi di lavoro può fornire indicazioni sulle fonti del lavoro. Per esempio, un numero elevato di bug segnalati dagli utenti finali potrebbe indicare problemi di qualità nelle versioni recenti. L’attributo può inoltre aiutare a valutare la chiarezza e la qualità dei requisiti iniziali, mettendo in relazione il creatore con le rilavorazioni o i ritardi successivi.

Aiuta a identificare chi avvia il lavoro e a comprendere le fonti della domanda, dei bug o delle richieste di nuove funzionalità.

Campo standard, come «Segnalato da» o «Autore», nella registrazione iniziale di un elemento di lavoro.

La gravità è diversa dalla priorità: misura l’impatto tecnico di un problema, mentre la priorità ne indica l’urgenza di risoluzione. Per esempio, un errore di battitura in una pagina visitata raramente può avere gravità e priorità basse, mentre un problema critico che corrompe i dati avrebbe gravità e priorità elevate.

Questo attributo è fondamentale per l’analisi della qualità, soprattutto quando si esaminano i processi di correzione dei bug. Consente ai team di valutare se stanno affrontando con efficacia i problemi più gravi. Analizzando i tempi di ciclo per ciascun livello di gravità, le organizzazioni possono verificare che i problemi critici del sistema vengano risolti rapidamente, limitando l’impatto sui clienti.

Consente di analizzare l’efficacia con cui il team affronta i problemi in base al loro impatto tecnico e di verificare che quelli critici vengano risolti tempestivamente.

Campo standard nei sistemi di gestione dello sviluppo, in particolare per gli elementi di lavoro di tipo «Bug» o «Incidente».

L’indicatore di rilavorazione è un attributo booleano o categoriale derivato, che segnala gli eventi appartenenti a un ciclo di rilavorazione. In genere viene rilevato quando il flusso del processo torna a una fase precedente, per esempio da «Test di controllo qualità» a «Sviluppo in corso», oppure quando si verificano attività specifiche, come «Rilavorazione individuata durante il controllo qualità».

Questo attributo è molto utile per analizzare la qualità e l’efficienza. Consente di calcolare direttamente il tasso di rilavorazione e mette in evidenza le fasi del processo che ne generano di più. Filtrando le attività di rilavorazione, i team possono analizzarne le cause profonde e capire perché i problemi di qualità non vengono individuati prima. Ridurre le rilavorazioni è una leva importante per migliorare sia la velocità di sviluppo sia la qualità del prodotto.

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

In genere viene ricavato durante la trasformazione dei dati, individuando i passaggi a ritroso nel flusso del processo o i nomi delle attività che indicano un errore.

L’attributo della versione pianificata collega un elemento di sviluppo a una specifica pianificazione di consegna o versione. Viene spesso utilizzato nella pianificazione dei rilasci per raggruppare funzionalità e correzioni da distribuire insieme.

L’analisi per versione pianificata aiuta a valutare la prevedibilità e l’affidabilità del processo di rilascio. Consente di monitorare la puntualità delle consegne confrontando la versione pianificata con la data effettiva di distribuzione. Inoltre, aiuta a gestire l’ambito e a comprendere il flusso del lavoro previsto per un determinato rilascio, mettendo in evidenza potenziali rischi o ritardi che potrebbero incidere sui tempi di consegna.

Collega il lavoro di sviluppo alle pianificazioni di consegna e consente di analizzare la puntualità delle consegne e la prevedibilità dei rilasci.

Campo standard, come «Versione di correzione», «Rilascio previsto» o «Percorso di iterazione», negli strumenti di pianificazione agile e sviluppo.