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

Azure DevOps
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 offre una guida chiara per preparare i dati dell'SDLC per il process mining. Spiega quali attributi raccogliere e come estrarli da Azure DevOps per un'ottimizzazione efficace.
  • Attributi consigliati da raccogliere
  • Attività chiave da monitorare per il Suo SDLC
  • Guida dettagliata all'estrazione per Azure DevOps
È nuovo agli event log? Impari come creare un event log di Process Mining.

Attributi dell'SDLC

Questi sono i campi dati raccomandati per un'analisi e ottimizzazione completa dell'SDLC.
5 Obbligatorio 8 Consigliato 6 Facoltativo
Nome Descrizione
Elemento di sviluppo
DevelopmentItem
L'ID univoco dell'unità di lavoro, che funge da identificatore del caso per il processo.
Descrizione

Rappresenta l'unità di lavoro in Azure DevOps. In ambito process mining, è fondamentale per correlare gli eventi in un unico percorso (case journey), permettendo l'analisi di tempi di ciclo e rework.

Perché è importante

Identificatore principale che connette i passaggi in un caso coerente per l'analisi end-to-end.

Dove trovare

Corrisponde al campo 'ID' di un work item in Azure DevOps Boards.

Esempi
10234102351023610237
Nome attività
ActivityName
Il nome dell'evento o task specifico verificatosi nel ciclo di vita.
Descrizione

Descrive una fase specifica, come 'Sviluppo avviato'. Questo attributo è essenziale per costruire la mappa di processo e identificare percorsi comuni e bottleneck tra le attività.

Perché è importante

Definisce le fasi del processo, costituendo l'ossatura della mappa di processo e permettendo l'analisi di workflow, bottleneck e deviazioni.

Dove trovare

Derivato solitamente dai cambi di stato o da eventi collegati come commit e PR.

Esempi
Sviluppo iniziatoPull Request completataTest QA fallitiDistribuito in produzioneWork Item chiuso
Timestamp Evento
EventTime
Il timestamp preciso di quando si è verificata l'attività.
Descrizione

L'Event Time acquisisce la data e l'ora di ogni attività nel ciclo di vita dello sviluppo. Questo timestamp è l'elemento temporale fondamentale utilizzato per ordinare gli eventi cronologicamente e calcolare le durate tra di essi.

Nell'analisi, questo attributo è fondamentale per calcolare tutte le metriche basate sul tempo, inclusi tempi di ciclo, tempi di elaborazione e tempi di attesa. Consente la creazione di un event log ordinato temporalmente, input necessario per qualsiasi analisi di Process Mining. Viene utilizzato per diagnosticare ritardi, misurare le prestazioni rispetto agli SLA e monitorare i trend nel tempo.

Perché è importante

Fornisce l'ordine cronologico, essenziale per calcolare i KPI di durata e capire i bottleneck.

Dove trovare

Data di modifica associata a ogni aggiornamento della cronologia.

Esempi
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
Sistema di Origine
SourceSystem
Il sistema di origine dei dati, in questo caso Azure DevOps.
Descrizione

Identifica il sistema di origine. È utile per la data governance e le integrazioni future con altri sistemi come SAP o ServiceNow.

Perché è importante

Fornisce un contesto cruciale sull'origine dei dati, importante per la data governance, la validazione e l'analisi di processi multi-sistema.

Dove trovare

Valore statico aggiunto durante l'estrazione per etichettare il dataset.

Esempi
Azure DevOps
Ultimo `Data Update`
LastDataUpdate
Il `timestamp` che indica l'ultima volta che i `data` per questo processo sono stati aggiornati dal sistema sorgente.
Descrizione

Indica l'ultimo aggiornamento dei dati. Conoscere la freschezza dei dati è critico per prendere decisioni informate e contestualizzare i risultati.

Perché è importante

Informa gli utenti sull'aggiornamento dei dati, assicurando che le analisi e le decisioni si basino su un intervallo temporale ben definito.

Dove trovare

Timestamp generato durante il processo di estrazione e caricamento dei dati (ETL).

Esempi
2024-05-20T08:00:00Z
Assegnato a
AssignedTo
L'utente o il membro del team a cui è attualmente assegnato l'elemento.
Descrizione

Identifica il responsabile in una data fase. È critico per monitorare il carico di lavoro di sviluppatori e tester e identificare eventuali membri del team sovraccarichi.

Perché è importante

Permette un'analisi basata sulle risorse, aiutando a comprendere la distribuzione del carico di lavoro, identificare i bottleneck specifici e gestire la capacità del team.

Dove trovare

Corrisponde al campo 'Assigned To' di un work item in Azure DevOps.

Esempi
jane.doe@example.comjohn.smith@example.comnon assegnato
È una Rilavorazione
IsRework
Un flag booleano che indica se un elemento di sviluppo è rientrato in una fase precedente del suo ciclo di vita.
Descrizione

Indica se un item ha subito un ciclo di rework. Permette di quantificare le inefficienze dovute a lacune comunicative o test insufficienti.

Perché è importante

Identifica e quantifica direttamente il rework (rilavorazione), aiutando a evidenziare problemi di qualità e inefficienze di processo che allungano i tempi di ciclo.

Dove trovare

Attributo calcolato analizzando la sequenza di attività nell'event log.

Esempi
truefalse
Nome del team
TeamName
Il nome del team di sviluppo responsabile del work item.
Descrizione

Identifica il team assegnatario. Consente di segmentare l'analisi per confrontare le performance tra i vari team e condividere le best practice.

Perché è importante

Abilita un'analisi comparativa tra diversi team, aiutando a identificare variazioni di performance e a condividere le best practice in tutta l'organizzazione.

Dove trovare

Spesso derivato dall'Area Path, poiché i team sono mappati su questi percorsi in Azure DevOps.

Esempi
Team PhoenixOmega SquadPlatform CoreTeam Frontend
Ora di Fine
EndTime
Il timestamp di fine attività, usato per calcolare il tempo di esecuzione.
Descrizione

Indica la conclusione di un'attività. È cruciale per calcolare il tempo di esecuzione e distinguere il lavoro attivo dai tempi morti di attesa.

Perché è importante

Permette il calcolo preciso dei tempi di esecuzione delle attività e dei tempi di inattività, fondamentali per l'analisi dei bottleneck e il miglioramento dell'efficienza.

Dove trovare

Spesso derivato dal timestamp dell'evento successivo o registrato esplicitamente se il sistema lo prevede.

Esempi
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
Priorità
Priority
Una classificazione numerica o descrittiva dell'importanza dell'elemento di sviluppo rispetto ad altri elementi.
Descrizione

La priorità indica l'importanza di pianificazione di un work item. Valori comuni sono numerici, da 1 (massima) a 4.

Questo attributo è essenziale per la dashboard Priority-Based Throughput & Cycle Time. L'analisi aiuta a capire se il sistema di prioritizzazione è efficace, ovvero se gli elementi critici procedono effettivamente più velocemente degli altri.

Perché è importante

Consente di analizzare se il processo accelera efficacemente gli elementi ad alta priorità, un fattore chiave per valutare il successo delle strategie di prioritizzazione.

Dove trovare

Corrisponde al campo 'Priority' di un work item in Azure DevOps.

Esempi
1234
Stato
State
Lo stato attuale nel workflow, come 'New', 'Active', 'Resolved' o 'Closed'.
Descrizione

Rappresenta lo stato formale dell'elemento. È utile per capire quanto tempo gli item passano in stati specifici ed è fondamentale per l'analisi dei passaggi (handoff).

Perché è importante

Indica lo stato del work item nel ciclo di vita, elemento fondamentale per comprendere il flusso del processo e calcolare il tempo trascorso nelle varie fasi.

Dove trovare

Corrisponde al campo 'State' di un work item in Azure DevOps.

Esempi
NuovoAttivoIn QARisoltoChiuso
Tempo di ciclo dello sviluppo
DevelopmentCycleTime
Il tempo totale trascorso dalla creazione dell'elemento al rilascio in produzione.
Descrizione

Il Tempo di ciclo dello sviluppo (Development Cycle Time) è un KPI che misura la durata end-to-end del processo di sviluppo per un singolo work item. Viene calcolato come differenza tra il timestamp dell'attività 'Deployed to Production' e quello di 'Work Item Created'.

Questa metrica è il KPI principale per la dashboard del tempo di ciclo end-to-end e per i trend storici. Fornisce una misura olistica della velocità e dell'efficienza del processo; il monitoraggio nel tempo mostra l'impatto delle iniziative di miglioramento.

Perché è importante

KPI critico che misura la velocità ed efficienza complessiva dello sviluppo.

Dove trovare

Calcolato sottraendo il timestamp di creazione da quello di rilascio finale.

Esempi
10 giorni 4 ore 30 minuti25 giorni 8 ore 0 minuti5 giorni 2 ore 15 minuti
Work Item Type
WorkItemType
La classificazione dell'elemento, come Bug, Feature, User Story o Task.
Descrizione

Categorizza la natura del lavoro. Permette di confrontare se i processi sono più efficienti per i Bug rispetto alle Feature e monitorare i trend dei tempi di ciclo.

Perché è importante

Consente la segmentazione dell'analisi di processo, permettendo di confrontare workflow e prestazioni per diverse categorie di lavoro, come bug e feature.

Dove trovare

Corrisponde al campo 'Work Item Type' di un work item in Azure DevOps.

Esempi
BugFeatureUser StoryTask
Gravità
Severity
Indica l'impatto di un bug o di un problema sul sistema o sugli utenti finali.
Descrizione

La gravità (Severity) classifica l'impatto di un bug. È distinta dalla priorità, che detta l'ordine del lavoro.

Questo attributo permette di verificare se si stanno risolvendo prima i bug più critici e aiuta a comprendere il profilo di rischio del lavoro in corso.

Perché è importante

Aiuta a categorizzare i work item in base al loro impatto sul business, consentendo di analizzare l'efficacia del team nel gestire i problemi ad alto impatto.

Dove trovare

Corrisponde al campo 'Severity' di un work item in Azure DevOps.

Esempi
1 - Critico2 - Alto3 - Medio4 - Basso
ID Pull Request
PullRequestId
L'identificatore di una PR collegata all'elemento di sviluppo.
Descrizione

Collega l'item a una PR specifica. Permette di analizzare i tempi di code review e la frequenza di rifiuti, indicatori della qualità del codice.

Perché è importante

Collega il lavoro di sviluppo ad attività specifiche di code review, consentendo un'analisi dettagliata dell'integrazione del codice e del processo di garanzia della qualità.

Dove trovare

Informazione presente nella sezione 'Links' o 'Development' del work item.

Esempi
452145334589
Nome progetto
ProjectName
Il nome del progetto Azure DevOps a cui appartiene l'elemento.
Descrizione

Identifica il progetto specifico in Azure DevOps. Permette di confrontare l'efficienza tra vari progetti e misurare l'impatto dei miglioramenti.

Perché è importante

Fornisce un raggruppamento di alto livello per l'analisi, consentendo il confronto delle prestazioni e l'analisi dei trend tra diversi progetti.

Dove trovare

Corrisponde al campo 'Team Project' di un work item in Azure DevOps.

Esempi
Piattaforma E-CommerceRilancio app mobileModernizzazione del Data Warehouse
Percorso iterazione
IterationPath
Lo sprint di sviluppo o l'intervallo a cui è assegnato il work item.
Descrizione

Rappresenta lo sprint. Analizzare per Iteration Path aiuta a capire le performance periodo per periodo, valutando se i tempi di ciclo migliorano nel tempo.

Perché è importante

Consente un'analisi basata sugli sprint, aiutando i team a valutare le proprie prestazioni nel tempo e a migliorare le pratiche agile.

Dove trovare

Corrisponde al campo 'Iteration Path' di un work item in Azure DevOps.

Esempi
Piattaforma E-Commerce\Sprint 12Piattaforma E-Commerce\Sprint 13Rilancio app mobile\Fase 2\Sprint 4
Tempo di attesa per l'approvazione
ApprovalWaitingTime
Il tempo trascorso in attesa di un'approvazione dopo la richiesta.
Descrizione

Misura quanto tempo un item resta in attesa di approvazione. Isolare questi ritardi permette ai team di migliorare la comunicazione e velocizzare il ciclo.

Perché è importante

Misura specificamente i ritardi causati dall'attesa di decisioni o approvazioni, evidenziando le opportunità per migliorare i processi di comunicazione e decision-making.

Dove trovare

Calcolato misurando la differenza di tempo tra l'inizio e la fine dell'approvazione (es. UAT).

Esempi
3 giorni 2 ore1 giorno 8 ore 30 minuti4 ore
Tempo di passaggio tra fasi
StageHandoffTime
La durata dell'inattività tra il completamento di una fase e l'inizio della successiva.
Descrizione

Misura il tempo di attesa tra fasi sequenziali, come tra fine sviluppo e inizio QA.

Questa metrica è fondamentale per identificare bottleneck nascosti dove il lavoro ristagna per mancanza di risorse o ritardi comunicativi.

Perché è importante

Quantifica i tempi di attesa tra le fasi del processo, esponendo direttamente bottleneck e ritardi nascosti che non fanno parte del lavoro attivo.

Dove trovare

Attributo calcolato misurando la differenza di tempo tra attività sequenziali che rappresentano un handoff.

Esempi
2 ore 15 minuti1 giorno 4 ore0 ore 30 minuti
Obbligatorio Consigliato Facoltativo

Attività dell'SDLC

Queste sono le fasi chiave del processo e le milestone da registrare nel tuo event log per un'accurata scoperta dei processi e l'identificazione dei colli di bottiglia.
7 Consigliato 8 Facoltativo
Activity Descrizione
Distribuito in produzione
Segna il rilascio riuscito del codice associato al work item nell'ambiente di produzione. È un evento esplicito catturato dai log di rilascio di Azure Pipelines.
Perché è importante

Milestone che rappresenta la consegna di valore. Serve come punto finale per il calcolo del tempo di ciclo.

Dove trovare

Acquisito dai dati della release pipeline di Azure Pipelines, specificamente dall'evento di completamento di un deployment in una fase di 'Production' collegata al work item.

Acquisisci

Acquisito da un evento di completamento del deployment della pipeline di rilascio.

Tipo di evento explicit
Pull Request completata
Rappresenta il completamento con successo della code review, con approvazione della PR e merge del codice. Evento registrato esplicitamente in Azure Repos.
Perché è importante

Segna la fine della fase di code review, un comune bottleneck. Analizzare il tempo tra la creazione e il completamento della PR rivela l'efficienza del ciclo di revisione.

Dove trovare

Acquisito dall'evento di completamento o merge di una pull request in Azure Repos collegata a un work item.

Acquisisci

Acquisito dall'evento di merge della pull request collegato a un work item.

Tipo di evento explicit
Pull Request creata
Indica che lo sviluppatore ha completato la scrittura iniziale del codice e ha inviato le modifiche per la revisione tramite una pull request. Questo evento collega il work item a una specifica modifica del codice in Azure Repos.
Perché è importante

Passaggio chiave tra sviluppo e code review. Aiuta a misurare quanto tempo richiede la scrittura del codice.

Dove trovare

Acquisito dai dati di Azure Repos collegando l'evento di creazione della pull request al relativo work item. Spesso si tratta di un collegamento esplicito creato dallo sviluppatore.

Acquisisci

Acquisito dall'evento di creazione della pull request di Azure Repos collegato a un work item.

Tipo di evento explicit
Sviluppo iniziato
Indica l'inizio del lavoro attivo sullo sviluppo. Si deduce dal cambio di stato in 'Active' o 'In Progress'.
Perché è importante

Segna l'inizio della fase di sviluppo attivo. Analizzare il tempo da 'Creato' a 'Sviluppo avviato' rivela i tempi di coda nel backlog.

Dove trovare

Dedotto dalla cronologia del work item quando il campo System.State passa da uno stato 'New' o 'Approved' a uno stato 'In Progress'.

Acquisisci

Dedotto dal cambio del campo State in 'Active' o 'In Progress'.

Tipo di evento inferred
Test QA avviati
Rappresenta l'inizio della fase di QA. Questa attività viene rilevata quando lo stato del work item passa a 'In QA', 'Testing' o simili.
Perché è importante

Segna l'inizio del ciclo QA. Analizzare la durata di questa fase è fondamentale per comprendere i bottleneck e l'efficienza dei test.

Dove trovare

Dedotto dalla cronologia del work item monitorando una modifica nel campo System.State in 'In QA' o un altro stato di test designato.

Acquisisci

Dedotto dal cambio del campo State in 'In QA' o 'Testing'.

Tipo di evento inferred
UAT approvato
Indica l'approvazione degli stakeholder post-UAT. Si deduce solitamente dal passaggio a 'UAT Approved'.
Perché è importante

Punto di approvazione critico che conferma il rispetto dei requisiti e la prontezza per il rilascio.

Dove trovare

Dedotto dalla cronologia del work item rilevando una modifica nel campo System.State da uno stato UAT a uno stato approvato o pronto per il rilascio.

Acquisisci

Dedotto dal cambio del campo State da 'In UAT' a 'Ready for Release'.

Tipo di evento inferred
Work Item creato
Segna l'inizio del ciclo di vita. Viene catturato quando si salva un nuovo record in Azure DevOps Boards.
Perché è importante

Evento di inizio primario, essenziale per misurare il tempo di ciclo totale.

Dove trovare

Evento catturato dalla 'Created Date' del work item.

Acquisisci

Acquisito dal campo 'Created Date' del work item.

Tipo di evento explicit
Build riuscita
Conferma che il codice è stato compilato e pacchettizzato con successo. Evento loggato da Azure Pipelines.
Perché è importante

Funge da quality gate critico, assicurando che il nuovo codice si integri correttamente. I fallimenti qui indicano problemi di integrazione.

Dove trovare

Acquisito dagli eventi di completamento della build di Azure Pipelines. La build deve essere collegata al work item, direttamente o tramite la pull request associata.

Acquisisci

Acquisito dall'evento di completamento della build di Azure Pipelines.

Tipo di evento explicit
Elemento di Lavoro Approvato
Rappresenta l'approvazione formale di un work item, pronto per lo sviluppo. Si deduce solitamente dal campo 'State' che passa ad 'Approved' o 'Ready for Dev'.
Perché è importante

Monitorare le approvazioni aiuta ad analizzare i ritardi tra l'idea e l'inizio dello sviluppo (planning e grooming).

Dove trovare

Dedotto dalla cronologia del work item rilevando una modifica del campo System.State in 'Approved' o uno stato personalizzato simile.

Acquisisci

Dedotto dal cambio del campo State in 'Approved'.

Tipo di evento inferred
Sviluppo completato
Indica che sviluppo e unit test sono completi e l'elemento è pronto per i test formali. Si deduce solitamente dallo stato 'Resolved' o 'Ready for Test'.
Perché è importante

Segna il passaggio dal team di sviluppo al QA. Aiuta a identificare i ritardi in questa transizione.

Dove trovare

Dedotto dalla cronologia del work item quando il campo System.State assume un valore come 'Resolved' o uno stato personalizzato che indica la prontezza per il QA.

Acquisisci

Dedotto dal cambio del campo State in 'Resolved'.

Tipo di evento inferred
Test QA completati
Segna il completamento con successo della fase di garanzia della qualità. Si deduce quando lo stato del work item passa da una fase di test a una come 'Ready for UAT' o 'QA Approved'.
Perché è importante

Quality gate che indica la prontezza per l'UAT. Ritardi dopo questo punto indicano problemi nella pianificazione dei rilasci.

Dove trovare

Dedotto dalla cronologia del work item quando il campo System.State passa da 'In QA' a uno stato successivo come 'Ready for UAT' o 'Done'.

Acquisisci

Dedotto dal cambio del campo State da 'In QA' a 'Ready for UAT'.

Tipo di evento inferred
Test QA falliti
Indica che il work item non ha superato i test di qualità e viene rimandato allo sviluppo. Questo viene acquisito da un cambiamento di stato da una fase di test a uno stato 'In Progress' o 'Active'.
Perché è importante

Attività essenziale per identificare i cicli di rework. Un'alta frequenza indica problemi di qualità o requisiti poco chiari.

Dove trovare

Dedotto dalla cronologia del work item rilevando una transizione da uno stato come 'In QA' a uno stato come 'Active' o 'In Progress'.

Acquisisci

Dedotto dal cambio del campo State da 'In QA' di nuovo ad 'Active'.

Tipo di evento inferred
UAT avviato
Rappresenta l'inizio dell'UAT, dove gli stakeholder validano le funzionalità. Si deduce dal cambio di stato in 'In UAT' o simili.
Perché è importante

Misura l'inizio della validazione finale prima del rilascio. La durata dell'UAT e i tempi di attesa per l'approvazione sono critici per l'ottimizzazione del processo.

Dove trovare

Dedotto dalla cronologia del work item quando il campo System.State viene aggiornato a uno stato personalizzato che rappresenta l'UAT, come 'In UAT'.

Acquisisci

Dedotto dal cambio del campo State in 'In UAT'.

Tipo di evento inferred
Work Item annullato
Indica che il work item è stato annullato e non sarà completato o distribuito. Questo viene acquisito da un cambiamento di stato in 'Removed', 'Cancelled' o simili.
Perché è importante

Rappresenta un esito negativo del processo. Analizzare gli item annullati rivela problemi di pianificazione o requisiti.

Dove trovare

Dedotto dalla cronologia del work item quando il campo System.State viene modificato in uno stato terminale nella categoria 'Removed'.

Acquisisci

Dedotto dal cambio del campo State in 'Removed' o 'Cancelled'.

Tipo di evento inferred
Work Item chiuso
Rappresenta la chiusura finale del work item dopo il rilascio. Viene catturato dal cambio di stato in 'Closed' o 'Done'.
Perché è importante

Segna il completamento finale con successo del processo. È il punto finale del ciclo di vita.

Dove trovare

Dedotto dalla cronologia del work item quando il campo System.State viene modificato in 'Closed' o uno stato terminale simile nella categoria 'Completed'.

Acquisisci

Dedotto dal cambio del campo State in 'Closed'.

Tipo di evento inferred
Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i dati da Azure DevOps