> Miglioramento continuo dei processi > Ciclo di vita dello sviluppo software > Azure DevOps > Template dei dati

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

Azure DevOps

Attributi del ciclo di vita dello sviluppo software (18) Attività del ciclo di vita dello sviluppo software (15) Guide all’estrazione (4)

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

Questo template offre indicazioni chiare per preparare i dati del ciclo di vita dello sviluppo software all’analisi di Process Mining. Descrive gli attributi essenziali da raccogliere, le attività principali da monitorare e fornisce istruzioni pratiche per estrarre queste informazioni da Azure DevOps. Utilizzi questa risorsa per strutturare correttamente i dati e ottenere analisi utili a migliorare il processo.

Attributi consigliati da raccogliere
Attività principali da monitorare nel ciclo di vita dello sviluppo software
Istruzioni dettagliate per l’estrazione da Azure DevOps

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il template

Attributi del ciclo di vita dello sviluppo software

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare e migliorare in modo completo il ciclo di vita dello sviluppo software.

5 Obbligatorio 7 Consigliato 6 Facoltativo

	Nome	Descrizione
	Elemento di sviluppo DevelopmentItem	Identificativo univoco di una singola unità di lavoro, ad esempio una funzionalità, un bug o una User Story, utilizzato come identificativo del caso nel processo.
Descrizione L’elemento di sviluppo rappresenta una singola unità di lavoro monitorata in Azure DevOps. Ogni elemento, identificato da un ID univoco, è l’oggetto centrale a cui fanno riferimento tutte le attività del processo, dalla creazione e pianificazione fino allo sviluppo, ai test e alla distribuzione. Nell’analisi di Process Mining, questo attributo è fondamentale per associare tutti gli eventi correlati a un unico caso. Consente di ricostruire il ciclo di vita completo di ogni elemento di lavoro e di analizzare, per ciascuno, i tempi di ciclo, gli scostamenti dal processo e i cicli di rilavorazione. Perché è importante È l’identificativo principale che collega tutte le fasi del processo in un unico caso coerente e rende possibile l’analisi completa del ciclo di vita dello sviluppo software. Dove reperirli Corrisponde al campo ID di un elemento di lavoro in Azure DevOps Boards. È accessibile tramite l’API REST di Azure DevOps per il monitoraggio degli elementi di lavoro. Esempi 10234102351023610237
	Nome dell’attività ActivityName	Nome dell’evento o del Task specifico che si è verificato in un determinato momento del ciclo di sviluppo di un elemento di lavoro.
Descrizione Il nome dell’attività descrive una fase o una tappa specifica del processo, ad esempio Development Started, Pull Request Created o Deployed to Production. Le attività derivano dalle modifiche di stato dell’elemento di lavoro, da eventi collegati come build o pull request oppure da eventi personalizzati. Questo attributo è essenziale per creare la mappa del processo, che ne rappresenta visivamente il flusso di lavoro. Consente agli analisti di comprendere la sequenza degli eventi, individuare i percorsi più comuni, rilevare i colli di bottiglia tra attività specifiche e analizzare la frequenza di ogni fase. Perché è importante Definisce le fasi del processo, ne costituisce la struttura portante e consente di analizzare il flusso di lavoro, i colli di bottiglia e gli scostamenti. Dove reperirli In genere deriva dalle modifiche del campo State di un elemento di lavoro o da eventi collegati, come build, commit e pull request. La cronologia dell’elemento di lavoro fornisce i dati grezzi relativi a questi eventi. Esempi Sviluppo avviatoPull Request completataTest QA non superatiDistribuito in produzioneElemento di lavoro chiuso
	Ora dell’evento EventTime	Data e ora precise in cui si è verificata una determinata attività o un evento relativo a un elemento di sviluppo.
Descrizione L’ora dell’evento registra la data e l’ora di ogni attività nel ciclo di sviluppo. Questo riferimento temporale fondamentale permette di ordinare gli eventi cronologicamente e calcolare gli intervalli tra loro. Nell’analisi, questo attributo è essenziale per calcolare tutte le metriche temporali, compresi i tempi di ciclo, i tempi di elaborazione e i tempi di attesa. Consente di creare un Event Log ordinato cronologicamente, necessario per qualsiasi analisi di Process Mining. Serve inoltre a individuare i ritardi, misurare le prestazioni rispetto agli SLA e monitorare gli andamenti nel tempo. Perché è importante Fornisce l’ordine cronologico degli eventi, indispensabile per calcolare tutti i KPI basati sulla durata e comprendere il flusso del processo e i colli di bottiglia. Dove reperirli Corrisponde alla data di modifica associata a ogni aggiornamento nella cronologia di un elemento di lavoro. Per gli eventi esterni, come build o distribuzioni, corrisponde all’ora di completamento dell’evento. Esempi 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
	Sistema di origine SourceSystem	Il sistema da cui sono stati estratti i dati del processo, in questo caso Azure DevOps.
Descrizione Questo attributo identifica il sistema da cui provengono i dati. È particolarmente utile quando si combinano dati provenienti da più sistemi per ottenere una visione più ampia del processo. In questo modello specifico, il valore è sempre Azure DevOps. Anche se in un’analisi basata su un solo sistema può sembrare un dato statico, fornisce informazioni essenziali sull’origine dei dati, utili per la governance, la risoluzione dei problemi e le future integrazioni con sistemi come ServiceNow o SAP. Perché è importante Fornisce informazioni essenziali sull’origine dei dati, importanti per la governance, la convalida e l’analisi dei processi che coinvolgono più sistemi. Dove reperirli È un valore statico da aggiungere durante l’estrazione e la trasformazione dei dati per identificare il set di dati. Esempi Azure DevOps
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora dell’ultimo aggiornamento dei dati del processo dal sistema di origine.
Descrizione Questo attributo registra quando il set di dati è stato estratto e aggiornato l’ultima volta da Azure DevOps. Indica chiaramente quanto sono aggiornati i dati e quale periodo è coperto dall’analisi. In ogni analisi di processo, conoscere l’attualità dei dati è fondamentale per prendere decisioni informate. Questo riferimento temporale aiuta a capire se si stanno consultando informazioni in tempo reale o una fotografia storica, un aspetto che incide sulla rilevanza dei risultati. Perché è importante Indica quanto sono aggiornati i dati, così che analisi e decisioni si riferiscano a un periodo noto. Dove reperirli È un riferimento temporale di metadati generato e memorizzato durante il processo di estrazione, trasformazione 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 di sviluppo.
Descrizione Questo attributo identifica la persona responsabile dell’elemento di lavoro in una determinata fase del processo. L’assegnatario può cambiare più volte durante il ciclo di vita dell’elemento, ad esempio passando da uno sviluppatore a un tester e poi a un responsabile del rilascio. L’analisi per assegnatario è fondamentale per la Dashboard Developer and Tester Workload Overview. Aiuta a comprendere l’allocazione delle risorse, individuare i membri del team sovraccarichi e confrontare le prestazioni di singole persone o team. Perché è importante Consente di analizzare il processo in base alle risorse, comprendere la distribuzione del carico di lavoro, individuare i colli di bottiglia legati a risorse specifiche e gestire la capacità del team. Dove reperirli Corrisponde al campo Assigned To di un elemento di lavoro in Azure DevOps. Il valore viene rilevato dalla cronologia dell’elemento per ogni evento. Esempi jane.doe@example.comjohn.smith@example.comnon assegnato
	È una rilavorazione IsRework	Indicatore booleano che segnala se un elemento di sviluppo è tornato a una fase precedente del proprio ciclo di vita.
Descrizione Questo indicatore assume il valore true se un elemento di lavoro presenta un ciclo di rilavorazione, ad esempio se passa da «Test QA completato» a «Sviluppo avviato». Il valore viene calcolato analizzando la sequenza delle attività di un caso e rilevando gli avanzamenti non lineari. Questo attributo è essenziale per la Dashboard Frequenza di rilavorazioni e nuovi test e per il KPI Frequenza dei cicli di rilavorazione. Consente di filtrare e quantificare facilmente le rilavorazioni, aiutando a individuare problemi di qualità, lacune nella comunicazione o test insufficienti che causano inefficienze. Perché è importante Individua e quantifica direttamente le rilavorazioni, mettendo in evidenza i problemi di qualità e le inefficienze del processo che allungano i tempi di ciclo. Dove reperirli È un attributo calcolato, ricavato dall’analisi della sequenza delle attività nell’Event Log di ciascun caso. Esempi truefalse
	Nome del team TeamName	Il nome del team di sviluppo responsabile dell’elemento di lavoro.
Descrizione Il nome del team identifica il gruppo specifico a cui è assegnato un elemento di lavoro. In Azure DevOps, il lavoro è spesso organizzato in team che possono costituire sottoinsiemi di un progetto più ampio. Questo attributo consente di segmentare l’analisi del processo per team. È utile per confrontare i processi e i risultati dei diversi team, individuare le buone pratiche dei gruppi più efficienti e capire dove alcuni team potrebbero aver bisogno di supporto o di miglioramenti al processo. Perché è importante Consente di confrontare i diversi team, individuare le differenze nei risultati e condividere le buone pratiche all’interno dell’organizzazione. Dove reperirli Spesso deriva dal campo «Area Path» di un elemento di lavoro, poiché in Azure DevOps i team sono generalmente associati a percorsi area specifici. Esempi Team PhoenixSquadra OmegaNucleo della piattaformaTeam frontend
	Ora di fine EndTime	Data e ora in cui un’attività è stata completata. Si utilizza per calcolarne il tempo di elaborazione.
Descrizione L’ora di fine indica quando termina un’attività. In molti Event Log, l’ora di inizio dell’attività successiva viene usata come ora di fine di quella precedente. Disporre di un’ora di fine distinta, tuttavia, consente di calcolare con maggiore precisione sia il tempo di elaborazione dell’attività sia il tempo di inattività tra un’attività e l’altra. Questo attributo è essenziale per calcolare il KPI ProcessingTime e svolgere un’analisi dettagliata dei colli di bottiglia. Aiuta a distinguere il tempo dedicato al lavoro effettivo su un Task da quello trascorso in attesa della fase successiva, un aspetto fondamentale per la Dashboard Stage Handoff Analysis. Perché è importante Consente di calcolare con precisione i tempi di elaborazione delle attività e i tempi di inattività, elementi fondamentali per analizzare i colli di bottiglia e migliorare l’efficienza. Dove reperirli Spesso viene ricavata dai dati: può corrispondere all’ora di inizio dell’evento successivo per lo stesso caso oppure essere registrata esplicitamente, se il sistema di origine rileva sia l’ora di inizio sia quella di fine dei Task. Esempi 2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
	Priorità Priority	Classificazione numerica o descrittiva dell’importanza dell’elemento di sviluppo rispetto agli altri elementi.
Descrizione La priorità indica l’importanza di un elemento di lavoro ai fini della pianificazione. Una priorità più alta suggerisce che l’elemento debba essere gestito prima di quelli con priorità inferiore. I valori sono spesso numerici, ad esempio 1, 2, 3 e 4, dove 1 indica la priorità massima. Questo attributo è essenziale per la Dashboard Produttività e tempo di ciclo in base alla priorità. Analizzare i dati con questo attributo consente di capire se il sistema di assegnazione delle priorità è efficace, ovvero se gli elementi con priorità alta attraversano effettivamente il processo più rapidamente di quelli con priorità bassa. Perché è importante Consente di verificare se il processo dà effettivamente precedenza agli elementi con priorità alta, un aspetto fondamentale per valutare l’efficacia delle strategie di assegnazione delle priorità. Dove reperirli Corrisponde al campo «Priority» di un elemento di lavoro in Azure DevOps. Esempi 1234
	Stato State	Lo stato corrente dell’elemento di sviluppo nel flusso di lavoro, ad esempio «Nuovo», «Attivo», «Risolto» o «Chiuso».
Descrizione L’attributo Stato rappresenta lo stato formale di un elemento di lavoro in un determinato momento, secondo quanto definito dal template di processo del progetto. Le transizioni tra questi stati sono la principale fonte per generare le attività nell’Event Log. L’attributo «Attività» offre spesso una descrizione più dettagliata del cambiamento di stato, mentre il dato grezzo dell’attributo «Stato» è utile per applicare filtri e svolgere analisi. Consente di capire quanto tempo gli elementi trascorrono nei singoli stati ed è fondamentale per creare la Dashboard Durata delle fasi e analizzare i passaggi di consegne. Perché è importante Indica lo stato dell’elemento di lavoro nel suo ciclo di vita, un dato fondamentale per comprendere il flusso del processo e calcolare il tempo trascorso nelle varie fasi. Dove reperirli Corrisponde al campo «State» di un elemento di lavoro in Azure DevOps. Esempi NuovoAttivoIn fase di test QARisoltoChiuso
	Tipo di elemento di lavoro WorkItemType	Classificazione dell’elemento di sviluppo, ad esempio Bug, Feature, User Story o Task.
Descrizione Il tipo di elemento di lavoro classifica la natura del lavoro svolto. Tipi diversi seguono spesso percorsi di processo differenti e sono soggetti ad aspettative di prestazione o SLA diversi. Ad esempio, un Bug può seguire un percorso accelerato rispetto a una Feature. Questo attributo è essenziale per l’analisi comparativa. Consente di filtrare la mappa del processo o i KPI in base al tipo di lavoro, per capire se i processi sono più efficienti per i Bug o per le Feature e monitorare nel tempo i tempi di ciclo delle diverse categorie. Perché è importante Consente di segmentare l’analisi del processo e confrontare i flussi di lavoro e le prestazioni delle diverse categorie, come Bug e Feature. Dove reperirli Corrisponde al campo Work Item Type di un elemento di lavoro in Azure DevOps. Esempi BugFunzionalitàUser StoryTask
	Gravità Severity	Indica l’impatto di un bug o di un problema sul sistema o sugli utenti finali.
Descrizione La gravità classifica l’impatto di un bug, dai guasti critici del sistema ai problemi estetici di lieve entità. È diversa dalla priorità, che determina l’ordine degli interventi. Un bug grave può avere una priorità bassa se è disponibile una soluzione alternativa semplice. Questo attributo aggiunge un’ulteriore dimensione all’analisi, in particolare per la Dashboard Produttività e tempo di ciclo in base alla priorità. Permette di rispondere a domande come «Stiamo correggendo prima i bug più critici?» e aiuta a comprendere il profilo di rischio del lavoro in corso. Perché è importante Aiuta a classificare gli elementi di lavoro in base al loro impatto sull’attività aziendale e consente di analizzare l’efficacia con cui il team gestisce i problemi più rilevanti. Dove reperirli Corrisponde al campo «Severity» di un elemento di lavoro, in genere per i bug, in Azure DevOps. Esempi 1 - Critico2 - Alto3 - Medio4 - Basso
	ID della pull request PullRequestId	L’identificativo di una pull request collegata all’elemento di sviluppo.
Descrizione Questo attributo collega un elemento di lavoro a una pull request specifica, utilizzata per inviare e rivedere le modifiche al codice. A un singolo elemento di lavoro possono essere associate più pull request. L’ID della pull request permette di analizzare in modo più dettagliato la revisione e l’integrazione del codice. Può essere utilizzato per misurare il tempo che intercorre tra la creazione e il completamento della pull request e per analizzare la frequenza con cui le pull request vengono rifiutate o richiedono modifiche sostanziali, possibili indicatori della qualità del codice o della chiarezza dei requisiti. Perché è importante Collega il lavoro di sviluppo alle specifiche attività di revisione del codice, consentendo un’analisi dettagliata dell’integrazione del codice e del processo di controllo della qualità. Dove reperirli Queste informazioni si trovano nella sezione «Links» o «Development» di un elemento di lavoro in Azure DevOps. Esempi 452145334589
	Nome del progetto ProjectName	Il nome del progetto Azure DevOps a cui appartiene l’elemento di sviluppo.
Descrizione Questo attributo identifica il progetto specifico dell’organizzazione Azure DevOps in cui si trova l’elemento di lavoro. Fornisce un contesto generale, soprattutto nelle organizzazioni che gestiscono molti progetti. Il nome del progetto è una dimensione importante per applicare filtri e fare confronti. La Dashboard Andamento storico del tempo di ciclo consente di segmentare l’analisi per progetto, così da capire se alcuni progetti sono più o meno efficienti degli altri o se i miglioramenti introdotti in un progetto hanno prodotto effetti positivi. Perché è importante Fornisce un raggruppamento generale per l’analisi e permette di confrontare i risultati e l’andamento dei diversi progetti. Dove reperirli Corrisponde al campo «Team Project» di un elemento di lavoro in Azure DevOps. Esempi Piattaforma di commercio elettronicoRilancio dell’app mobileModernizzazione del data warehouse
	Percorso di iterazione IterationPath	Lo sprint di sviluppo o il periodo di lavoro a tempo definito a cui è assegnato l’elemento.
Descrizione Il percorso di iterazione, o sprint, rappresenta un periodo di sviluppo con una durata definita. Gli elementi di lavoro vengono assegnati a un’iterazione e devono essere completati entro tale periodo. L’analisi per percorso di iterazione consente di valutare l’andamento del processo sprint per sprint. Può servire a verificare se i tempi di ciclo migliorano nel corso degli sprint, analizzare il lavoro rimandato agli sprint successivi e valutare quanto sia prevedibile la pianificazione degli sprint. Perché è importante Consente di analizzare il lavoro in base agli sprint, aiutando i team a valutare i propri risultati nel tempo e a migliorare le pratiche agili. Dove reperirli Corrisponde al campo «Iteration Path» di un elemento di lavoro in Azure DevOps. Esempi Piattaforma di commercio elettronico\Sprint 12Piattaforma di commercio elettronico\Sprint 13Rilancio dell’app mobile\Fase 2\Sprint 4
	Tempo di attesa per l’approvazione ApprovalWaitingTime	Il tempo durante il quale un elemento di sviluppo resta in attesa di approvazione dopo l’invio della richiesta.
Descrizione Questa metrica misura la durata di specifici periodi di attesa durante i quali un elemento di lavoro è in attesa di approvazione. Un esempio tipico è l’intervallo tra «Test di accettazione utente avviato» e «Test di accettazione utente approvato». Per calcolarlo, si misura il tempo che intercorre tra queste due attività per un determinato caso. Questo attributo calcolato supporta direttamente la Dashboard Analisi dei tempi di attesa per l’approvazione e il relativo KPI. Isolando questi ritardi, i team possono intervenire sui processi di comunicazione e decisionali per ridurre i tempi di inattività e accelerare l’intero ciclo di vita. Perché è importante Misura in modo specifico i ritardi dovuti all’attesa di decisioni o approvazioni, evidenziando le opportunità per migliorare la comunicazione e i processi decisionali. Dove reperirli Si calcola individuando nell’Event Log le specifiche attività iniziali e finali relative all’approvazione, ad esempio «Test di accettazione utente avviato» e «Test di accettazione utente approvato», e misurando l’intervallo di tempo tra le due. Esempi 3 giorni e 2 ore1 giorno, 8 ore e 30 minuti4 ore
	Tempo di passaggio tra le fasi StageHandoffTime	Il tempo di inattività tra il completamento di una fase principale e l’inizio della successiva.
Descrizione Il tempo di passaggio tra le fasi misura l’attesa tra due fasi consecutive del processo, ad esempio il tempo che intercorre tra «Sviluppo completato» e «Test QA avviato». Si calcola individuando queste transizioni e misurando l’intervallo tra la fine della prima attività e l’inizio della seconda. Questa metrica è al centro della Dashboard Durata delle fasi e analisi dei passaggi di consegne. Isolare e misurare i tempi di passaggio è fondamentale per individuare i colli di bottiglia nascosti, in cui il lavoro resta fermo, spesso per indisponibilità delle risorse, ritardi nella comunicazione o processi inefficienti. Perché è importante Quantifica i tempi di attesa tra le fasi del processo e mette direttamente in evidenza i colli di bottiglia nascosti e i ritardi che non fanno parte del lavoro effettivo. Dove reperirli È un attributo calcolato. Occorre individuare coppie di attività consecutive che rappresentano un passaggio di consegne e calcolare l’intervallo di tempo che le separa. Esempi 2 ore e 15 minuti1 giorno e 4 ore30 minuti

Obbligatorio Consigliato Facoltativo

Attività del ciclo di vita dello sviluppo software

Questi sono i passaggi e i traguardi principali da registrare nell’Event Log per individuare correttamente il processo e i colli di bottiglia.

7 Consigliato 8 Facoltativo

	Attività	Descrizione
	Distribuito in produzione	Segna la distribuzione in produzione, completata con esito positivo, del codice associato all’elemento di lavoro. L’evento viene rilevato esplicitamente dai registri delle release di Azure Pipelines.
Perché è importante È una tappa fondamentale, che rappresenta la consegna del valore. Costituisce il punto finale per calcolare il tempo di attraversamento e il tempo di ciclo. Dove reperirli Rilevato dai dati della pipeline di release di Azure Pipelines, in particolare dall’evento di completamento della distribuzione in una fase Production collegata all’elemento di lavoro. Acquisizione Rilevato dall’evento di completamento della distribuzione nella pipeline di release. Tipo di evento explicit
	Elemento di lavoro creato	Questa attività segna l’inizio del ciclo di sviluppo e corrisponde alla creazione di un nuovo elemento di lavoro, ad esempio una User Story, un Bug o un Task. Viene registrata esplicitamente quando si salva un nuovo record in Azure DevOps Boards.
Perché è importante È l’evento di inizio principale del processo, indispensabile per misurare il tempo di ciclo complessivo dello sviluppo e comprendere da dove proviene il lavoro. Dove reperirli L’evento viene rilevato dalla data di creazione dell’elemento di lavoro. Anche la tabella della cronologia dell’elemento registra questa transizione iniziale di stato. Acquisizione Rilevato dal campo della data di creazione dell’elemento di lavoro. Tipo di evento explicit
	Pull Request completata	Indica che la revisione del codice si è conclusa con esito positivo: la pull request è stata approvata e il codice è stato integrato nel ramo di destinazione. L’evento viene registrato esplicitamente in Azure Repos.
Perché è importante Segna la fine della fase di revisione del codice, che spesso rappresenta un collo di bottiglia. Analizzare il tempo tra la creazione e il completamento della PR permette di valutare l’efficienza del ciclo di revisione. Dove reperirli Rilevato dall’evento di completamento o integrazione di una pull request in Azure Repos collegata a un elemento di lavoro. Acquisizione Rilevato dall’evento di integrazione della pull request collegata a un elemento di lavoro. Tipo di evento explicit
	Pull Request creata	Indica che lo sviluppatore ha completato la prima fase di codifica e ha inviato le modifiche per la revisione tramite una pull request. L’evento collega l’elemento di lavoro a una modifica specifica del codice in Azure Repos.
Perché è importante È un passaggio di consegne importante dallo sviluppo alla revisione del codice. Monitorarlo aiuta a misurare la durata della codifica e a capire quando il codice è pronto per la revisione tra pari. Dove reperirli Rilevato dai dati di Azure Repos collegando l’evento di creazione della pull request al relativo elemento di lavoro. Spesso il collegamento viene creato esplicitamente dallo sviluppatore. Acquisizione Rilevato dall’evento di creazione della pull request in Azure Repos collegato a un elemento di lavoro. Tipo di evento explicit
	Sviluppo avviato	Indica che uno sviluppatore ha iniziato a lavorare attivamente sull’elemento. Si deduce dalla modifica dello stato dell’elemento di lavoro a Active, In Progress o Committed.
Perché è importante Segna l’inizio della fase di sviluppo attivo. Analizzare il tempo che intercorre tra Created e Development Started permette di misurare i tempi di attesa nel backlog. Dove reperirli Si deduce dalla cronologia dell’elemento di lavoro quando il campo System.State passa da New o Approved a In Progress. Acquisizione Si deduce dalla modifica del campo State a Active o In Progress. Tipo di evento inferred
	Test QA avviati	Indica l’inizio della fase formale di controllo qualità. Si deduce quando lo stato dell’elemento di lavoro passa a In QA, Testing o a un valore equivalente.
Perché è importante Segna l’inizio del ciclo QA. Analizzare la durata di questa fase è essenziale per comprendere i colli di bottiglia e l’efficienza dei test. Dove reperirli Si deduce dalla cronologia dell’elemento di lavoro rilevando la modifica del campo System.State a In QA o a un altro stato designato per i test. Acquisizione Si deduce dalla modifica del campo State a In QA o Testing. Tipo di evento inferred
	UAT approvato	Indica che le parti interessate dell’azienda hanno approvato le modifiche dopo i test di accettazione da parte degli utenti. In genere si deduce dal passaggio dello stato da In UAT a UAT Approved o Ready for Release.
Perché è importante È una tappa fondamentale dell’approvazione: conferma che l’elemento di lavoro soddisfa i requisiti aziendali ed è pronto per la distribuzione in produzione. Dove reperirli Si deduce dalla cronologia dell’elemento di lavoro rilevando il passaggio del campo System.State da uno stato UAT a uno stato di approvazione o di preparazione al rilascio. Acquisizione Si deduce dalla modifica del campo State da In UAT a Ready for Release. Tipo di evento inferred
	Build completata con esito positivo	Questa attività conferma che il codice sorgente, comprese le nuove modifiche, è stato compilato e preparato correttamente da una pipeline di build. Azure Pipelines registra esplicitamente l’evento.
Perché è importante È un controllo di qualità fondamentale, che verifica che il nuovo codice si integri correttamente senza compromettere la build. Un errore in questa fase può indicare problemi di integrazione. Dove reperirli Rilevato dagli eventi di completamento della build in Azure Pipelines. La build deve essere collegata all’elemento di lavoro, direttamente o tramite la pull request associata. Acquisizione Rilevato dall’evento di completamento della build in Azure Pipelines. Tipo di evento explicit
	Elemento di lavoro annullato	Indica che l’elemento di lavoro è stato annullato e non verrà completato né distribuito. Si rileva quando lo stato passa a Removed, Cancelled o a uno stato equivalente.
Perché è importante Rappresenta una conclusione alternativa del processo, senza esito positivo. Analizzare gli elementi annullati può far emergere problemi di pianificazione, definizione delle priorità o dei requisiti. Dove reperirli Si deduce dalla cronologia dell’elemento di lavoro quando il campo System.State passa a uno stato terminale della categoria Removed. Acquisizione Si deduce dalla modifica del campo State a Removed o Cancelled. Tipo di evento inferred
	Elemento di lavoro approvato	Indica l’approvazione formale di un elemento di lavoro, che ne conferma la definizione e la disponibilità per lo sviluppo. In genere si deduce dalla modifica del campo State a un valore come Approved o Ready for Dev.
Perché è importante Monitorare le approvazioni aiuta ad analizzare il tempo che intercorre tra la presentazione di un’idea e l’impegno a svilupparla. Permette inoltre di individuare possibili ritardi nella pianificazione e nella revisione del backlog. Dove reperirli Si deduce dalla cronologia dell’elemento di lavoro rilevando una modifica del campo System.State a Approved o a uno stato personalizzato equivalente. Acquisizione Si deduce dalla modifica del campo State a Approved. Tipo di evento inferred
	Elemento di lavoro chiuso	Indica la chiusura definitiva dell’elemento di lavoro dopo la distribuzione e le eventuali verifiche successive. Si rileva quando lo stato passa a Closed o Done.
Perché è importante Questa attività segna il completamento definitivo dell’intero processo relativo a un elemento di lavoro. È il punto finale del ciclo di vita. Dove reperirli Si deduce dalla cronologia dell’elemento di lavoro quando il campo System.State passa a Closed o a uno stato terminale equivalente nella categoria Completed. Acquisizione Si deduce dalla modifica del campo State a Closed. Tipo di evento inferred
	Sviluppo completato	Indica che tutte le attività di sviluppo e i test unitari sono terminati e che l’elemento è pronto per i test formali. In genere si deduce dalla modifica dello stato dell’elemento di lavoro a Resolved o Ready for Test.
Perché è importante Segna un importante passaggio di consegne dal team di sviluppo al team QA. Misurare il tempo che precede l’avvio dei test QA aiuta a individuare i ritardi nel passaggio. Dove reperirli Si deduce dalla cronologia dell’elemento di lavoro quando il campo System.State passa a un valore come Resolved o a uno stato personalizzato che indica la disponibilità per il QA. Acquisizione Si deduce dalla modifica del campo State a Resolved. Tipo di evento inferred
	Test QA completati	Segna il completamento con esito positivo della fase di controllo qualità. Si deduce quando lo stato dell’elemento di lavoro passa da uno stato di test a Ready for UAT, QA Approved o a uno stato equivalente.
Perché è importante È un controllo di qualità importante, che indica che l’elemento è pronto per i test di accettazione da parte degli utenti o per il rilascio. Eventuali ritardi successivi possono segnalare colli di bottiglia nei test UAT o nella pianificazione del rilascio. Dove reperirli Si deduce dalla cronologia dell’elemento di lavoro quando il campo System.State passa da In QA a uno stato successivo, come Ready for UAT o Done. Acquisizione Si deduce dalla modifica del campo State da In QA a Ready for UAT. Tipo di evento inferred
	Test QA non superati	Indica che l’elemento di lavoro non ha superato i test di controllo qualità e viene rimandato allo sviluppo. Si rileva quando lo stato passa da uno stato di test a In Progress o Active.
Perché è importante Questa attività è essenziale per individuare i cicli di rilavorazione. Se si verifica spesso, può segnalare problemi nella qualità del codice, nei requisiti o nei processi di test. Dove reperirli Si deduce dalla cronologia dell’elemento di lavoro rilevando una transizione da uno stato come In QA a uno stato come Active o In Progress. Acquisizione Si deduce dalla modifica del campo State da In QA ad Active. Tipo di evento inferred
	Test UAT avviati	Indica l’inizio dei test di accettazione da parte degli utenti (UAT), durante i quali le parti interessate dell’azienda convalidano le funzionalità. In genere si deduce dalla modifica dello stato a In UAT o a uno stato equivalente.
Perché è importante Misura l’inizio della convalida finale prima del rilascio. Per ottimizzare il processo è importante analizzare la durata dei test UAT e i tempi di attesa per l’approvazione. Dove reperirli Si deduce dalla cronologia dell’elemento di lavoro quando il campo System.State viene aggiornato a uno stato personalizzato che rappresenta i test UAT, ad esempio In UAT. Acquisizione Si deduce dalla modifica del campo State a In UAT. Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Azure DevOps

Passaggi

Acceda alle visualizzazioni di analisi in Azure DevOps: nel progetto Azure DevOps, apra Boards e selezioni Analytics views.
Crei una nuova visualizzazione di analisi: faccia clic sul pulsante New View per avviare la procedura di configurazione. Assegni alla visualizzazione un nome descrittivo, ad esempio «ProcessMining_WorkItemLog».
Configuri i filtri degli elementi di lavoro: nella scheda Work Items, applichi i filtri per selezionare i team, i backlog e i tipi di elemento di lavoro pertinenti al processo di sviluppo software, ad esempio User Story, Bug e Feature. È fondamentale includere tutti gli stati che rappresentano le attività da monitorare.
Selezioni i campi dati: nella scheda Fields, aggiunga tutti i campi necessari. Come minimo, includa: ID elemento di lavoro, tipo di elemento di lavoro, stato, data di creazione, data di modifica, assegnatario e priorità. Questi campi diventeranno attributi nell’Event Log.
Configuri i dati storici: apra la scheda History. Questo è il passaggio più importante per il Process Mining. Selezioni un periodo mobile per i dati, ad esempio 365 giorni. Imposti obbligatoriamente la Granularity su Giornaliero. In questo modo verrà creata un’istantanea giornaliera della cronologia degli elementi di lavoro, che consentirà di monitorare nel tempo le transizioni di stato. Salvi la visualizzazione.
Si colleghi da Power BI Desktop: apra Power BI Desktop e selezioni Get Data. Cerchi e selezioni Azure DevOps (Boards only), quindi faccia clic su Connect.
Inserisca i dettagli di connessione: indichi i nomi dell’Organizzazione Azure DevOps e del Team project. Acceda quando richiesto.
Selezioni la visualizzazione di analisi: nella finestra Navigator, individui e selezioni la visualizzazione di analisi creata nei passaggi precedenti. Faccia clic su Transform Data per aprire l’Editor di Power Query.
Applichi la logica di trasformazione: i dati verranno caricati come tabella piatta di istantanee giornaliere degli elementi di lavoro. Copi lo script Power Query M completo dalla sezione query di questo documento e lo incolli nell’Advanced Editor della query, sostituendo il contenuto esistente. Lo script trasformerà le istantanee in un Event Log nel formato corretto.
Personalizzi la mappatura degli stati: lo script fornito utilizza nomi di stato comuni. Riveda e modifichi il codice M in modo che corrisponda esattamente ai nomi di stato utilizzati nel template di processo del progetto, ad esempio se lo stato «In Progress» è denominato «Active» o «Dev In Progress».
Carichi ed esporti i dati: dopo aver applicato e personalizzato lo script, faccia clic su Close & Apply nell’Editor di Power Query. Una volta caricati i dati nel modello Power BI, apra la visualizzazione Dati, selezioni la tabella della query finale, faccia clic con il pulsante destro del mouse e scelga Copy table. Potrà quindi incollare i dati in un file CSV o Excel da caricare.

Configurazione

Tipo di visualizzazione di analisi: è necessario creare una visualizzazione personalizzata. Non utilizzi quelle predefinite, perché potrebbero non contenere i dati storici necessari.
Granularità della cronologia: nella scheda History è obbligatorio impostare la granularità su «Giornaliero». In questo modo si ottengono le istantanee giorno per giorno necessarie per ricostruire il flusso del processo e individuare i cambiamenti di stato.
Intervallo di date: si consiglia un periodo mobile da 180 a 365 giorni, sufficiente per l’analisi senza causare tempi di caricamento eccessivi. Tenga presente che questa impostazione limita l’intervallo storico disponibile per l’estrazione.
Selezione dei campi: aggiunga esplicitamente campi come «State», «Assigned To», «Work Item Type», «Priority», «Created Date» e «State Change Date». Se questi campi non sono inclusi nella visualizzazione, non sarà possibile estrarli.
Filtri degli elementi di lavoro: per garantire prestazioni e pertinenza, imposti i filtri della visualizzazione in modo da includere solo i team e i tipi di elemento di lavoro specifici che fanno parte del processo da analizzare.
Prerequisiti: l’utente che esegue l’estrazione deve disporre almeno dell’accesso «Reader» al progetto Azure DevOps e delle autorizzazioni «View analytics». Per connettersi alla visualizzazione ed eseguire le trasformazioni è necessario Power BI Desktop.

a Query di esempio sql

let
    Source = AzureDevOps.Views("[Your Organization Name]", "[Your Project Name]", [ApiVersion = 2]),
    View_Table = Source{[Id="[Your Analytics View ID]",Name="[Your Analytics View Name]"],Kind="View"}[Data],

    // Add a unique key for each daily snapshot
    AddSnapshotKey = Table.AddColumn(View_Table, "SnapshotKey", each Text.Combine({Text.From([Work Item Id], "en-US"), Text.From([Date], "en-US")}), type text),
    
    // Lag the state column to detect changes
    AddPreviousState = Table.Buffer(Table.Sort(AddSnapshotKey,{{"Work Item Id", Order.Ascending}, {"Date", Order.Ascending}})),
    ShiftedList = {null} & List.RemoveLastN(AddPreviousState[State],1),
    AddLagColumn = Table.ToColumns(AddPreviousState) & {ShiftedList},
    FinalTable = Table.FromColumns(AddLagColumn, Table.ColumnNames(AddPreviousState) & {"PreviousState"}),
    
    // Filter to rows where the state actually changed or it's the creation event
    FilterStateChanges = Table.SelectRows(FinalTable, each [State] <> [PreviousState] or [PreviousState] = null),

    // --- Event 1: Work Item Created ---
    WorkItemCreated = Table.SelectRows(FilterStateChanges, each [PreviousState] = null),
    AddActivity_Created = Table.AddColumn(WorkItemCreated, "ActivityName", each "Work Item Created"),
    SelectCols_Created = Table.SelectColumns(AddActivity_Created, {"Work Item Id", "ActivityName", "Created Date", "Work Item Type", "State", "Priority", "Assigned To", "Area Path"}),
    RenameCols_Created = Table.RenameColumns(SelectCols_Created,{{"Created Date", "EventTime"}, {"Area Path", "TeamName"}}),

    // --- Infer events from State Changes ---
    StateChangeEvents = Table.SelectRows(FilterStateChanges, each [PreviousState] <> null),
    AddActivity_StateChange = Table.AddColumn(StateChangeEvents, "ActivityName", each 
        if [State] = "Approved" then "Work Item Approved"
        else if [State] = "Committed" or [State] = "Active" or [State] = "In Progress" and [PreviousState] <> "In QA" then "Development Started"
        else if [State] = "Resolved" then "Development Completed"
        else if [State] = "In QA" or [State] = "Testing" then "QA Testing Started"
        else if [State] = "In Progress" and [PreviousState] = "In QA" then "QA Testing Failed"
        else if [State] = "QA Approved" then "QA Testing Completed"
        else if [State] = "In UAT" then "UAT Started"
        else if [State] = "UAT Approved" then "UAT Approved"
        else if [State] = "Deployed" then "Deployed to Production" // Assuming a state reflects deployment
        else if [State] = "Closed" then "Work Item Closed"
        else if [State] = "Done" then "Work Item Closed"
        else if [State] = "Removed" or [State] = "Cancelled" then "Work Item Cancelled"
        else null),
    FilterNullActivities = Table.SelectRows(AddActivity_StateChange, each ([ActivityName] <> null)),
    SelectCols_StateChange = Table.SelectColumns(FilterNullActivities, {"Work Item Id", "ActivityName", "Date", "Work Item Type", "State", "Priority", "Assigned To", "Area Path"}),
    RenameCols_StateChange = Table.RenameColumns(SelectCols_StateChange,{{"Date", "EventTime"}, {"Area Path", "TeamName"}}),

    // --- Combine all event tables ---
    CombinedEvents = Table.Combine({RenameCols_Created, RenameCols_StateChange}),
    
    // --- Placeholder Events Not Captured by State Changes ---
    // These activities require different data sources (OData/API) and are not reliably captured via Work Item history alone.
    // Placeholder logic is omitted as it would be speculative.

    // --- Final Formatting ---
    RenameCaseID = Table.RenameColumns(CombinedEvents,{{"Work Item Id", "DevelopmentItem"}}),
    AddSourceSystem = Table.AddColumn(RenameCaseID, "SourceSystem", each "Azure DevOps"),
    AddLastUpdate = Table.AddColumn(AddSourceSystem, "LastDataUpdate", each DateTime.LocalNow()),
    ChangeTypes = Table.TransformColumnTypes(AddLastUpdate,{{"DevelopmentItem", type text}, {"EventTime", type datetime}, {"LastDataUpdate", type datetime}}),

    // Final column selection and ordering
    SelectFinalColumns = Table.SelectColumns(ChangeTypes, {"DevelopmentItem", "ActivityName", "EventTime", "SourceSystem", "LastDataUpdate", "Assigned To", "Work Item Type", "State", "Priority", "TeamName"})

in
    SelectFinalColumns

Passaggi

Generi un token di accesso personale (PAT): in Azure DevOps, apra Impostazioni utente > Token di accesso personale. Crei un nuovo token con un nome descrittivo e gli assegni le seguenti autorizzazioni di lettura: «Work Items», «Code», «Build» e «Release». Copi il token generato e lo conservi in un luogo sicuro, perché non sarà più possibile visualizzarlo.
Configuri lo script PowerShell: salvi lo script PowerShell fornito in un file, ad esempio extract_ado_log.ps1. Apra il file in un editor di testo e modifichi le variabili di configurazione all’inizio. Dovrà indicare l’URL dell’organizzazione, il nome del progetto, il PAT generato, le date di inizio e fine dell’estrazione e il percorso del file di output desiderato.
Comprenda la logica dello script: per prima cosa, lo script utilizza una query WIQL (Work Item Query Language) per individuare tutti gli elementi di lavoro creati o modificati nell’intervallo di date specificato. In questo modo crea l’elenco completo dei casi da analizzare.
Recuperi la cronologia degli elementi di lavoro: per ogni elemento individuato, lo script effettua un’altra chiamata API per recuperare l’intera cronologia delle revisioni. La cronologia contiene tutte le modifiche apportate all’elemento di lavoro, comprese le transizioni di stato, le assegnazioni e i collegamenti ad altri artefatti.
Elabori le attività basate sullo stato: lo script esamina in ordine cronologico le revisioni di ciascun elemento di lavoro e confronta il campo «System.State» di ogni revisione con quello della revisione precedente. Quando rileva una modifica corrispondente a una fase del processo predefinita, ad esempio il passaggio da «Approved» ad «Active», genera la riga di evento corrispondente, ad esempio «Sviluppo avviato».
Elabori le attività basate sugli artefatti: per eventi come «Pull Request creata» o «Distribuito in produzione», lo script controlla i dati «relations» associati all’elemento di lavoro. Quando rileva un nuovo collegamento a un artefatto, come una pull request o una build, effettua ulteriori chiamate API ai servizi specifici per recuperare informazioni dettagliate, ad esempio la data e l’ora esatte di creazione o completamento, e crea la riga di evento corrispondente.
Crei l’Event Log: man mano che individua le attività, lo script crea un record strutturato con tutti gli attributi obbligatori e consigliati, come DevelopmentItem, ActivityName, EventTime, AssignedTo e WorkItemType. Il record viene aggiunto all’elenco principale dell’Event Log.
Calcoli gli attributi derivati: dopo aver elaborato tutte le revisioni di un elemento di lavoro, lo script esegue alcuni calcoli. Segnala le rilavorazioni verificando se uno stato viene raggiunto più di una volta. Prova inoltre a calcolare EndTime per ogni attività, utilizzando la data e l’ora dell’attività successiva dello stesso caso.
Esegua lo script: apra un terminale PowerShell, si sposti nella cartella in cui ha salvato lo script ed esegua il comando .\extract_ado_log.ps1. Durante l’elaborazione degli elementi di lavoro, lo script mostrerà gli aggiornamenti sullo stato di avanzamento.
Esporti e carichi i dati: al termine dell’esecuzione, verrà creato un file CSV nel percorso specificato nella variabile $outputCsvPath. Ne verifichi la correttezza e controlli che le intestazioni delle colonne e i formati dei dati siano quelli previsti prima di caricarlo nell’applicazione ProcessMind.

Configurazione

$organizationUrl: l’URL di base dell’organizzazione Azure DevOps, ad esempio https://dev.azure.com/your-org-name.
$projectName: il nome del progetto Azure DevOps specifico da cui estrarre i dati.
$personalAccessToken: il token di accesso personale (PAT) utilizzato per l’autenticazione. Deve disporre delle autorizzazioni di lettura per Work Items, Code, Build e Releases.
$startDate / $endDate: l’intervallo di date dell’estrazione, nel formato «yyyy-MM-dd». Si consiglia di iniziare con un intervallo da 3 a 6 mesi per ottenere informazioni utili sul processo senza creare un file eccessivamente grande. Lo script filtra gli elementi di lavoro in base alla data dell’ultima modifica.
$outputCsvPath: il percorso locale completo in cui lo script salverà l’Event Log finale in formato CSV, ad esempio C:\temp\ado_event_log.csv.
Mappatura delle transizioni di stato: lo script contiene una logica predefinita per individuare le attività in base ai cambiamenti di stato degli elementi di lavoro, ad esempio il passaggio da «Resolved» a «In QA» genera l’attività «Test QA avviato». Nella struttura switch dello script, aggiorni i nomi degli stati in modo che corrispondano al template di processo specifico utilizzato nel progetto, ad esempio Agile, Scrum, CMMI o un template personalizzato.

a Query di esempio powershell

# =============================================================================
# Configuration Variables
# =============================================================================
$organizationUrl = "https://dev.azure.com/[Your-Organization-Name]"
$projectName = "[Your-Project-Name]"
$personalAccessToken = "[Your-Personal-Access-Token]"
$startDate = "2023-01-01"
$endDate = "2023-06-30"
$outputCsvPath = "C:\temp\ado_process_mining_log.csv"

# =============================================================================
# Script Body
# =============================================================================

# --- Helper function to create a standardized event object ---
function New-EventLogEntry {
    param (
        $DevelopmentItem, $ActivityName, $EventTime, $SourceSystem, $LastDataUpdate,
        $EndTime, $AssignedTo, $WorkItemType, $State, $Priority, $TeamName, $DevelopmentCycleTime, $IsRework
    )
    return [PSCustomObject]@{ 
        DevelopmentItem = $DevelopmentItem; ActivityName = $ActivityName; EventTime = $EventTime; SourceSystem = $SourceSystem; 
        LastDataUpdate = $LastDataUpdate; EndTime = $EndTime; AssignedTo = $AssignedTo; WorkItemType = $WorkItemType; State = $State; 
        Priority = $Priority; TeamName = $TeamName; DevelopmentCycleTime = $DevelopmentCycleTime; IsRework = $IsRework 
    }
}

# --- Main script execution ---
try {
    $startTime = Get-Date
    Write-Host "Starting Azure DevOps data extraction at $startTime"

    # Base64 encode the PAT for the authorization header
    $base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes((":{0}" -f $personalAccessToken)))
    $headers = @{Authorization = ("Basic {0}" -f $base64AuthInfo)}

    # Timestamp for the extraction run
    $lastDataUpdate = Get-Date -Format 'yyyy-MM-ddTHH:mm:ssZ'
    
    # Initialize list to hold all event log entries
    $eventLog = [System.Collections.Generic.List[object]]::new()

    # Step 1: Query for all work item IDs in the specified date range using WIQL
    Write-Host "Querying for work items between $startDate and $endDate..."
    $wiqlQuery = @{
        query = "SELECT [System.Id] FROM workitems WHERE [System.TeamProject] = '$projectName' AND [System.ChangedDate] >= '$startDate' AND [System.ChangedDate] <= '$endDate'"
    }
    $wiqlUrl = "$organizationUrl/$projectName/_apis/wit/wiql?api-version=6.0"
    $wiqlResponse = Invoke-RestMethod -Uri $wiqlUrl -Method Post -Body (ConvertTo-Json $wiqlQuery) -ContentType "application/json" -Headers $headers
    $workItemIds = $wiqlResponse.workItems.id
    Write-Host ("Found {0} work items to process." -f $workItemIds.Count)

    # Step 2: Iterate through each work item and get its full revision history
    $processedCount = 0
    foreach ($id in $workItemIds) {
        $processedCount++
        Write-Host ("Processing Work Item {0} ({1}/{2})..." -f $id, $processedCount, $workItemIds.Count)

        $revisionsUrl = "$organizationUrl/_apis/wit/workitems/$id/revisions?`$expand=relations&api-version=6.0"
        $revisionsResponse = Invoke-RestMethod -Uri $revisionsUrl -Method Get -Headers $headers
        
        $previousRevision = $null
        $stateHistory = [System.Collections.Generic.List[string]]::new()

        # Loop through each revision to generate events
        foreach ($revision in $revisionsResponse.value) {
            $currentFields = $revision.fields
            $previousFields = $previousRevision.fields
            $eventTime = [datetime]$currentFields.'System.ChangedDate'
            $currentState = $currentFields.'System.State'

            # Common attributes for this revision
            $commonAttribs = @{
                DevelopmentItem = $id
                EventTime = $eventTime.ToString('yyyy-MM-ddTHH:mm:ssZ')
                SourceSystem = 'Azure DevOps'
                LastDataUpdate = $lastDataUpdate
                AssignedTo = $currentFields.'System.AssignedTo'.displayName
                WorkItemType = $currentFields.'System.WorkItemType'
                State = $currentState
                Priority = $currentFields.'Microsoft.VSTS.Common.Priority'
                TeamName = $currentFields.'System.TeamProject'
            }
            
            # --- Activity Detection Logic ---

            # Work Item Created (always the first revision)
            if ($revision.rev -eq 1) {
                $isRework = $false
                $eventLog.Add((New-EventLogEntry @commonAttribs -ActivityName 'Work Item Created' -IsRework $isRework))
                $stateHistory.Add($currentState)
            } else {
                $previousState = $previousFields.'System.State'
                
                # Detect rework if we re-enter a state
                $isRework = $stateHistory.Contains($currentState)

                # State Change Activities
                if ($currentState -ne $previousState) {
                    $transition = "$previousState -> $currentState"
                    $activityName = switch ($transition) {
                        'New -> Approved' { 'Work Item Approved' }
                        'Approved -> Active' { 'Development Started' }
                        'Approved -> In Progress' { 'Development Started' }
                        'Active -> Resolved' { 'Development Completed' }
                        'In Progress -> Resolved' { 'Development Completed' }
                        'Resolved -> In QA' { 'QA Testing Started' }
                        'Resolved -> Testing' { 'QA Testing Started' }
                        'In QA -> Active' { 'QA Testing Failed' }
                        'Testing -> In Progress' { 'QA Testing Failed' }
                        'In QA -> Ready for UAT' { 'QA Testing Completed' }
                        'Testing -> UAT Approved' { 'QA Testing Completed' }
                        'Ready for UAT -> In UAT' { 'UAT Started' }
                        'In UAT -> UAT Approved' { 'UAT Approved' }
                        # Handle final states
                        default {
                           if ($currentState -eq 'Closed' -or $currentState -eq 'Done') { 'Work Item Closed' }
                           elseif ($currentState -eq 'Removed' -or $currentState -eq 'Cancelled') { 'Work Item Cancelled' }
                        }
                    }
                    if ($activityName) {
                        $eventLog.Add((New-EventLogEntry @commonAttribs -ActivityName $activityName -IsRework $isRework))
                    }
                    $stateHistory.Add($currentState)
                }
            }

            # Artifact Relation Activities (Pull Requests, Builds, Deployments)
            # This checks for newly added relations compared to the previous revision
            $currentRelations = $revision.relations
            $previousRelations = $previousRevision.relations
            if ($currentRelations) {
                $newRelations = Compare-Object -ReferenceObject $previousRelations -DifferenceObject $currentRelations -Property url -PassThru | Where-Object { $_.SideIndicator -eq '=>' }
                foreach ($rel in $newRelations) {
                    # Pull Request Created/Completed
                    if ($rel.rel -eq 'ArtifactLink' -and $rel.attributes.name -eq 'Pull Request') {
                        # Note: A more robust check would query the PR URL for its actual creation/completion date
                        $eventLog.Add((New-EventLogEntry @commonAttribs -ActivityName 'Pull Request Created' -IsRework $false))
                        # Placeholder for completion, real logic would track PR status over time
                        # For simplicity, we assume another event represents completion.
                    }
                    # Build Succeeded
                    if ($rel.rel -eq 'ArtifactLink' -and $rel.attributes.name -eq 'Build') {
                         $eventLog.Add((New-EventLogEntry @commonAttribs -ActivityName 'Build Succeeded' -IsRework $false))
                    }
                    # Deployed to Production
                     if ($rel.rel -eq 'ArtifactLink' -and $rel.attributes.name -eq 'Integrated in release environment') {
                         if ($rel.url -like '*Production*') { # Simple check for production deployment
                            $eventLog.Add((New-EventLogEntry @commonattribs -ActivityName 'Deployed to Production' -IsRework $false))
                         }
                    }
                }
            }

            $previousRevision = $revision
        }
    }

    # Step 3: Post-processing to sort events and calculate EndTime/CycleTime
    Write-Host "Sorting event log and calculating derived attributes..."
    $sortedEvents = $eventLog | Sort-Object DevelopmentItem, EventTime
    
    $finalLog = for ($i = 0; $i -lt $sortedEvents.Count; $i++) {
        $currentEvent = $sortedEvents[$i]
        $nextEvent = if ($i + 1 -lt $sortedEvents.Count) { $sortedEvents[$i + 1] } else { $null }
        
        # Calculate EndTime
        if ($nextEvent -and $currentEvent.DevelopmentItem -eq $nextEvent.DevelopmentItem) {
            $currentEvent.EndTime = $nextEvent.EventTime
        } else {
            $currentEvent.EndTime = $null
        }
        $currentEvent # Output to the final log
    }

    # Step 4: Export to CSV
    Write-Host ("Exporting {0} events to {1}..." -f $finalLog.Count, $outputCsvPath)
    $finalLog | Export-Csv -Path $outputCsvPath -NoTypeInformation -Encoding UTF8

    $endTime = Get-Date
    Write-Host "Extraction completed successfully at $endTime"
    Write-Host ("Total execution time: {0}" -f ($endTime - $startTime))
}
catch {
    Write-Error "An error occurred during extraction: $_"
    exit 1
}

Passaggi

Prepari l’ambiente: installi Python 3.8 o una versione successiva sul computer. Installi quindi le librerie Python necessarie eseguendo questo comando nel terminale: pip install pandas azure-devops.
Generi un token di accesso personale (PAT): acceda ad Azure DevOps e apra Impostazioni utente -> Token di accesso personale. Crei un nuovo token con almeno le seguenti autorizzazioni: Work Items (Read), Code (Read), Build (Read) e Release (Read). Copi il token generato e lo conservi in un luogo sicuro.
Configuri lo script Python: apra lo script Python fornito in un editor. Sostituisca i valori segnaposto di ORGANIZATION_URL, PROJECT_NAME e PERSONAL_ACCESS_TOKEN con i dati specifici di Azure DevOps e il PAT generato.
Definisca i parametri di estrazione: modifichi le variabili START_DATE e END_DATE per definire l’intervallo temporale dell’estrazione. Aggiorni l’elenco WORK_ITEM_TYPES includendo i tipi specifici da analizzare, ad esempio «User Story», «Bug» o «Feature».
Personalizzi la mappatura degli stati: lo script utilizza un dizionario STATE_MAP per convertire gli stati specifici del flusso di lavoro del progetto in nomi di attività standard. Riveda e aggiorni attentamente il dizionario in modo che corrisponda al processo del team. Ad esempio, associ lo stato «In Development» all’attività «Sviluppo avviato». Questo passaggio è fondamentale per ottenere risultati accurati.
Esegua lo script: lo avvii dal terminale con il comando python your_script_name.py. Lo script si collegherà all’API di Azure DevOps, recupererà i dati degli elementi di lavoro, ne elaborerà la cronologia e genererà un Event Log.
Controlli il risultato: se l’esecuzione va a buon fine, nella stessa cartella verrà creato un file CSV denominato azure_devops_event_log.csv, contenente l’Event Log estratto.
Prepari i dati per il caricamento: apra il file CSV generato con un programma per fogli di calcolo e verifichi che i dati siano strutturati correttamente. Controlli che le colonne DevelopmentItem, ActivityName e EventTime siano presenti e compilate. Il file è quindi pronto per essere caricato in uno strumento di Process Mining.

Configurazione

Dettagli di connessione: dovrà indicare ORGANIZATION_URL, ad esempio https://dev.azure.com/your-org, PROJECT_NAME e PERSONAL_ACCESS_TOKEN per l’autenticazione.
Filtri degli elementi di lavoro: l’elenco WORK_ITEM_TYPES nello script consente di specificare i tipi di elemento di lavoro da estrarre, ad esempio «Bug», «User Story» o «Task». È un passaggio essenziale per concentrare l’analisi su uno specifico processo di sviluppo.
Intervallo di date: le variabili START_DATE e END_DATE definiscono il periodo dell’estrazione in base alla data di creazione degli elementi di lavoro. Per l’analisi iniziale si consiglia un intervallo da 3 a 6 mesi, così da bilanciare il volume dei dati e le informazioni ottenute.
Mappatura degli stati (STATE_MAP): questo dizionario è l’impostazione più importante. Dovrà associare gli stati personalizzati degli elementi di lavoro del progetto, ad esempio «Ready for Dev», «In Progress» e «In Test», ai nomi standard delle attività richiesti dall’Event Log. Una mappatura errata produrrà un modello di processo impreciso.
Prerequisiti: lo script richiede un ambiente Python e le librerie azure-devops e pandas. Per acquisire tutti i tipi di evento, l’utente che esegue lo script deve disporre di un PAT Azure DevOps con autorizzazioni di lettura per i servizi Work Items, Code, Build e Release.

a Query di esempio python

import os
import pandas as pd
from datetime import datetime, timezone
from azure.devops.connection import Connection
from msrest.authentication import BasicAuthentication

class=class="hl-string">"hl-comment"># --- Configuration: Replace with your values ---
ORGANIZATION_URL = class="hl-string">'https://dev.azure.com/[Your Organization]'
PROJECT_NAME = class="hl-string">'[Your Project Name]'
PERSONAL_ACCESS_TOKEN = class="hl-string">'[Your Personal Access Token]'

class=class="hl-string">"hl-comment"># --- Extraction Parameters ---
class=class="hl-string">"hl-comment"># Date range for work items to fetch (based on creation date)
START_DATE = class="hl-string">'2023-01-01'
END_DATE = class="hl-string">'2023-12-31'

class=class="hl-string">"hl-comment"># Work item types to include in the extraction
WORK_ITEM_TYPES = [class="hl-string">'User Story', class="hl-string">'Bug', class="hl-string">'Feature']

class=class="hl-string">"hl-comment"># --- State Mapping: Customize this to match your project's workflow ---
class=class="hl-string">"hl-comment"># Maps a work itemclass="hl-string">'s 'State' field to a standardized Activity Name
STATE_MAP = {
    class="hl-string">'New': class="hl-string">'Work Item Created',
    class="hl-string">'Approved': class="hl-string">'Work Item Approved',
    class="hl-string">'Committed': class="hl-string">'Development Started',
    class="hl-string">'Active': class="hl-string">'Development Started',
    class="hl-string">'In Progress': class="hl-string">'Development Started',
    class="hl-string">'Resolved': class="hl-string">'Development Completed',
    class="hl-string">'Ready for Test': class="hl-string">'Development Completed',
    class="hl-string">'In QA': class="hl-string">'QA Testing Started',
    class="hl-string">'Testing': class="hl-string">'QA Testing Started',
    class="hl-string">'QA Approved': class="hl-string">'QA Testing Completed',
    class="hl-string">'Ready for UAT': class="hl-string">'QA Testing Completed',
    class="hl-string">'In UAT': class="hl-string">'UAT Started',
    class="hl-string">'UAT Approved': class="hl-string">'UAT Approved',
    class="hl-string">'Ready for Release': class="hl-string">'UAT Approved',
    class="hl-string">'Done': class="hl-string">'Work Item Closed',
    class="hl-string">'Closed': class="hl-string">'Work Item Closed',
    class="hl-string">'Removed': class="hl-string">'Work Item Cancelled',
    class="hl-string">'Cancelled': class="hl-string">'Work Item Cancelled'
}

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def main():
    print(class="hl-string">"Connecting to Azure DevOps...")
    credentials = BasicAuthentication(class="hl-string">'', PERSONAL_ACCESS_TOKEN)
    connection = Connection(base_url=ORGANIZATION_URL, creds=credentials)
    wit_client = connection.clients.get_work_item_tracking_client()
    git_client = connection.clients.get_git_client()
    build_client = connection.clients.get_build_client()

    print(fclass="hl-string">"Fetching work items from {START_DATE} to {END_DATE}...")
    wiql_query = fclass="hl-string">"""
        SELECT [System.Id]
        FROM workitems
        WHERE [System.TeamProject] = '{PROJECT_NAME}'
        AND [System.WorkItemType] IN ({', '.join([f"'{t}'" for t in WORK_ITEM_TYPES])})
        AND [System.CreatedDate] >= '{START_DATE}'
        AND [System.CreatedDate] <= '{END_DATE}'
        ORDER BY [System.Id]
    """

    wiql_results = wit_client.query_by_wiql({class="hl-string">'query': wiql_query}).work_items
    if not wiql_results:
        print(class="hl-string">"No work items found for the specified criteria.")
        return

    work_item_ids = [item.id for item in wiql_results]
    print(fclass="hl-string">"Found {len(work_item_ids)} work items. Fetching details and history...")

    all_events = []
    last_data_update = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># Process work items in batches to avoid API limits
    batch_size = 200
    for i in range(0, len(work_item_ids), batch_size):
        batch_ids = work_item_ids[i:i + batch_size]
        work_items = wit_client.get_work_items(ids=batch_ids, expand=class="hl-string">'All')
        
        for item in work_items:
            events = process_work_item(item, wit_client, git_client, build_client, last_data_update)
            all_events.extend(events)
        print(fclass="hl-string">"Processed batch {i // batch_size + 1}...")

    if not all_events:
        print(class="hl-string">"No events were generated. Check your state mappings and data.")
        return

    print(class="hl-string">"Creating event log DataFrame...")
    df = pd.DataFrame(all_events)
    df = df.sort_values(by=[class="hl-string">'DevelopmentItem', class="hl-string">'EventTime'])
    
    class=class="hl-string">"hl-comment"># Calculate EndTime (start of next event for the same case)
    df[class="hl-string">'EndTime'] = df.groupby(class="hl-string">'DevelopmentItem')[class="hl-string">'EventTime'].shift(-1)
    
    class=class="hl-string">"hl-comment"># Final column selection and ordering
    df[class="hl-string">'SourceSystem'] = class="hl-string">'Azure DevOps'
    df = df[[class="hl-string">'DevelopmentItem', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'EndTime', class="hl-string">'AssignedTo', class="hl-string">'WorkItemType', 
             class="hl-string">'State', class="hl-string">'Priority', class="hl-string">'TeamName', class="hl-string">'IsRework', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate']]

    output_filename = class="hl-string">'azure_devops_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"\nExtraction complete. Event log saved to {output_filename}")

def process_work_item(item, wit_client, git_client, build_client, last_data_update):
    events = []
    case_id = item.id
    work_item_type = item.fields.get(class="hl-string">'System.WorkItemType')
    team_name = item.fields.get(class="hl-string">'System.AreaPath')
    priority = item.fields.get(class="hl-string">'Microsoft.VSTS.Common.Priority')

    revisions = wit_client.get_revisions(work_item_id=case_id, expand=class="hl-string">'Fields')
    
    class=class="hl-string">"hl-comment"># Track states to detect rework
    seen_states = set()
    
    class=class="hl-string">"hl-comment"># Revision 0 / Initial Creation
    rev0 = revisions[0]
    initial_state = rev0.fields.get(class="hl-string">'System.State')
    events.append({
        class="hl-string">'DevelopmentItem': case_id,
        class="hl-string">'ActivityName': class="hl-string">'Work Item Created',
        class="hl-string">'EventTime': rev0.fields.get(class="hl-string">'System.CreatedDate').isoformat(),
        class="hl-string">'AssignedTo': rev0.fields.get(class="hl-string">'System.AssignedTo', {}).get(class="hl-string">'displayName'),
        class="hl-string">'WorkItemType': work_item_type,
        class="hl-string">'State': initial_state,
        class="hl-string">'Priority': priority,
        class="hl-string">'TeamName': team_name,
        class="hl-string">'IsRework': False,
        class="hl-string">'LastDataUpdate': last_data_update
    })
    seen_states.add(initial_state)
    
    class=class="hl-string">"hl-comment"># Process state changes and other updates
    for i in range(1, len(revisions)):
        prev_rev = revisions[i-1]
        curr_rev = revisions[i]

        prev_state = prev_rev.fields.get(class="hl-string">'System.State')
        curr_state = curr_rev.fields.get(class="hl-string">'System.State')
        event_time = curr_rev.fields.get(class="hl-string">'System.ChangedDate').isoformat()
        assigned_to = curr_rev.fields.get(class="hl-string">'System.AssignedTo', {}).get(class="hl-string">'displayName')

        class=class="hl-string">"hl-comment"># State Change Event
        if prev_state != curr_state and curr_state in STATE_MAP:
            activity = STATE_MAP[curr_state]
            is_rework = curr_state in seen_states
            
            class=class="hl-string">"hl-comment"># Specific logic for QA failure (rework)
            if (prev_state in [class="hl-string">'In QA', class="hl-string">'Testing', class="hl-string">'In UAT'] and 
                curr_state in [class="hl-string">'Active', class="hl-string">'In Progress', class="hl-string">'Committed']):
                activity = class="hl-string">'QA Testing Failed'
                is_rework = True
            
            events.append({
                class="hl-string">'DevelopmentItem': case_id,
                class="hl-string">'ActivityName': activity,
                class="hl-string">'EventTime': event_time,
                class="hl-string">'AssignedTo': assigned_to,
                class="hl-string">'WorkItemType': work_item_type,
                class="hl-string">'State': curr_state,
                class="hl-string">'Priority': priority,
                class="hl-string">'TeamName': team_name,
                class="hl-string">'IsRework': is_rework,
                class="hl-string">'LastDataUpdate': last_data_update
            })
            seen_states.add(curr_state)

    class=class="hl-string">"hl-comment"># Process linked artifacts like Pull Requests from the final item state
    if item.relations:
        for rel in item.relations:
            if rel.attributes.get(class="hl-string">'name') == class="hl-string">'Pull Request':
                try:
                    pr_id = int(rel.url.split(class="hl-string">'/')[-1])
                    pr = git_client.get_pull_request_by_id(pr_id, PROJECT_NAME)
                    events.append({
                        class="hl-string">'DevelopmentItem': case_id, class="hl-string">'ActivityName': class="hl-string">'Pull Request Created',
                        class="hl-string">'EventTime': pr.creation_date.isoformat(), class="hl-string">'AssignedTo': pr.created_by.display_name,
                        class="hl-string">'WorkItemType': work_item_type, class="hl-string">'State': item.fields.get(class="hl-string">'System.State'), class="hl-string">'Priority': priority, 
                        class="hl-string">'TeamName': team_name, class="hl-string">'IsRework': False, class="hl-string">'LastDataUpdate': last_data_update
                    })
                    if pr.status == class="hl-string">'completed' and pr.last_merge_commit is not None:
                        merge_commit = git_client.get_commit(pr.last_merge_commit.commit_id, PROJECT_NAME, pr.repository.id)
                        events.append({
                            class="hl-string">'DevelopmentItem': case_id, class="hl-string">'ActivityName': class="hl-string">'Pull Request Completed',
                            class="hl-string">'EventTime': merge_commit.committer.date.isoformat(), class="hl-string">'AssignedTo': merge_commit.committer.name,
                            class="hl-string">'WorkItemType': work_item_type, class="hl-string">'State': item.fields.get(class="hl-string">'System.State'), class="hl-string">'Priority': priority, 
                            class="hl-string">'TeamName': team_name, class="hl-string">'IsRework': False, class="hl-string">'LastDataUpdate': last_data_update
                        })
                except Exception as e:
                    print(fclass="hl-string">"Warning: Could not process PR link for WI {case_id}: {e}")

            if rel.attributes.get(class="hl-string">'name') == class="hl-string">'Build':
                try:
                    build_id = int(rel.url.split(class="hl-string">'/')[-1])
                    build = build_client.get_build(PROJECT_NAME, build_id)
                    if build.status == class="hl-string">'completed' and build.result == class="hl-string">'succeeded':
                         events.append({
                            class="hl-string">'DevelopmentItem': case_id, class="hl-string">'ActivityName': class="hl-string">'Build Succeeded',
                            class="hl-string">'EventTime': build.finish_time.isoformat(), class="hl-string">'AssignedTo': None,
                            class="hl-string">'WorkItemType': work_item_type, class="hl-string">'State': item.fields.get(class="hl-string">'System.State'), class="hl-string">'Priority': priority,
                            class="hl-string">'TeamName': team_name, class="hl-string">'IsRework': False, class="hl-string">'LastDataUpdate': last_data_update
                        })
                except Exception as e:
                    print(fclass="hl-string">"Warning: Could not process Build link for WI {case_id}: {e}")

    class=class="hl-string">"hl-comment"># Note: class="hl-string">'Deployed to Production' is highly specific to release pipeline setup.
    class=class="hl-string">"hl-comment"># This part requires custom logic to check release pipeline logs linked to the work item.
    class=class="hl-string">"hl-comment"># A placeholder is added here; you would need to implement get_deployment_events.
    class=class="hl-string">"hl-comment"># deployment_events = get_deployment_events(case_id, item)
    class=class="hl-string">"hl-comment"># events.extend(deployment_events)

    return events

if __name__ == class="hl-string">'__main__':
    main()

Passaggi

In Azure Data Factory, crei o apra la data factory di destinazione e verifichi che il connettore Azure DevOps sia disponibile nella configurazione del servizio collegato. Crei un servizio collegato nativo per Azure DevOps e configuri l’autenticazione, l’organizzazione, il progetto e le eventuali proprietà di connessione richieste in base all’ambiente Azure DevOps in uso.
Crei un dataset di origine o una configurazione di origine per la query degli elementi di lavoro di Azure DevOps. Utilizzi una query che restituisca gli identificativi degli elementi di lavoro, il tipo di elemento, lo stato, l’utente assegnato, la priorità, il team, i timestamp degli eventi e tutti i campi necessari per identificare le transizioni di stato, le pull request, le build, le distribuzioni e le cancellazioni. Sostituisca ogni segnaposto tra parentesi quadre con i valori del Suo ambiente.
Crei un dataset di destinazione in Azure Blob Storage o in un altro archivio dati di destinazione supportato. Utilizzi un formato tabellare, ad esempio testo delimitato o Parquet, e definisca le colonne di output obbligatorie DevelopmentItem, ActivityName, EventTime, SourceSystem e LastDataUpdate. Aggiunga le colonne consigliate EndTime, AssignedTo, WorkItemType, State, Priority, TeamName e IsRework quando sono disponibili nell’origine.
Crei un’attività Copy nella pipeline. Configuri il servizio collegato Azure DevOps e la query di origine, quindi associ i campi di origine allo schema di destinazione. Mantenga i timestamp e gli identificativi originali senza convertirli in testo destinato alla sola visualizzazione. Imposti SourceSystem su Azure DevOps e LastDataUpdate sul timestamp di aggiornamento della pipeline per ogni riga di output.
Riorganizzi i dati estratti dall’origine in un event log. Ogni attività deve essere registrata in una riga distinta, con DevelopmentItem come identificativo del caso, ActivityName uguale a uno dei 15 nomi di attività obbligatori ed EventTime uguale al timestamp dell’attività. Non faccia affidamento su ProcessMind per dedurre gli eventi dalla cronologia degli stati. La logica di estrazione può utilizzare le transizioni di stato per creare righe esplicite, ma tutte le attività risultanti devono essere presenti nel file esportato.
Applichi esplicitamente le regole per le attività. Crei Work Item Created a partire dal timestamp di creazione; Work Item Approved da una transizione allo stato approvato o pronto per lo sviluppo; Development Started da una transizione allo stato attivo, in corso o confermato; Pull Request Created dall’evento di creazione di una pull request collegata; Pull Request Completed dall’evento di completamento di una pull request; Build Succeeded da un evento di build riuscita; Development Completed da una transizione allo stato risolto o pronto per i test; QA Testing Started da una transizione allo stato in QA o in test; QA Testing Failed da una transizione dallo stato di test ad attivo o in corso; QA Testing Completed da una transizione allo stato pronto per UAT o approvato dalla QA; UAT Started da una transizione allo stato in UAT; UAT Approved da una transizione allo stato approvato per UAT o pronto per il rilascio; Deployed to Production da un evento di distribuzione in produzione riuscita; Work Item Closed da una transizione allo stato chiuso o completato; Work Item Cancelled da una transizione allo stato rimosso o annullato.
Configuri l’estrazione incrementale utilizzando un watermark basato sul timestamp dell’evento di origine o sull’ultima esecuzione riuscita della pipeline. Includa una finestra di recupero per rielaborare gli aggiornamenti arrivati in ritardo e i timestamp corretti. Elimini i duplicati utilizzando DevelopmentItem, ActivityName, EventTime e, quando disponibile, l’identificativo dell’evento di origine.
Aggiunga attività di convalida o un passaggio successivo di controllo della qualità dei dati per verificare le colonne obbligatorie, i nomi delle attività validi, gli identificativi dei casi non nulli, l’ordine cronologico, le righe duplicate e la validità dei timestamp. Salvi l’output in una posizione stabile e conservi l’identificativo dell’esecuzione della pipeline e il timestamp di aggiornamento per garantire la tracciabilità ai fini di audit.
Esegua la pipeline per un intervallo di date controllato, esamini il file generato e confronti il numero di eventi con i record di elementi di lavoro, pull request, build e distribuzioni di Azure DevOps. Corregga le associazioni o i filtri prima di pianificare l’esecuzione della pipeline.
Esporti o renda disponibile il file finale come event log compatibile con ProcessMind. Verifichi che il file contenga una riga per ogni evento esplicito, utilizzi un formato coerente per i timestamp, includa DevelopmentItem, ActivityName, EventTime, SourceSystem e LastDataUpdate e contenga gli attributi consigliati quando disponibili. Carichi il file risultante oppure colleghi ProcessMind all’archivio dati di destinazione.

Configurazione

Connessione: utilizzi il servizio collegato nativo Azure DevOps in Azure Data Factory. Configuri l’organizzazione, il progetto, il metodo di autenticazione e le autorizzazioni in base al Suo ambiente. Sostituisca i dettagli di connessione con i valori del Suo sistema.
Ambito dell’origine: includa i record degli elementi di lavoro e le relative origini di eventi necessarie per le pull request, le build e le distribuzioni in produzione. La configurazione del connettore Azure DevOps e le entità disponibili possono variare in base alla versione del servizio e all’ambito delle autorizzazioni.
Intervallo di date: inizi con uno storico da 3 a 6 mesi. Estenda l’intervallo solo dopo aver verificato il volume, la completezza degli eventi e la durata della pipeline.
Caricamento incrementale: utilizzi un watermark e un periodo di recupero per acquisire gli aggiornamenti tardivi. Rielabori una finestra di sovrapposizione adeguata ed elimini gli eventi duplicati prima di scrivere il file di destinazione.
Filtri: applichi filtri per progetto, team, tipo di elemento di lavoro, stato, percorso dell’area, percorso dell’iterazione e data solo quando corrispondono all’ambito previsto del processo. Non applichi filtri Company Code o Document Type, poiché non sono attributi standard degli elementi di lavoro di Azure DevOps.
Granularità degli eventi: registri una riga per ogni attività obbligatoria. Una modifica dello stato di un elemento di lavoro, un evento di pull request, l’esito di una build o quello di una distribuzione non deve rimanere soltanto come attributo di un’altra riga.
Gestione dei timestamp: mantenga i timestamp di origine con le informazioni sul fuso orario, quando disponibili. Utilizzi un fuso orario coerente nella destinazione e documenti ogni conversione.
Attributi obbligatori: DevelopmentItem, ActivityName, EventTime, SourceSystem e LastDataUpdate devono essere valorizzati per ogni riga.
Attributi consigliati: EndTime, AssignedTo, WorkItemType, State, Priority, TeamName e IsRework dovrebbero essere valorizzati quando disponibili. Utilizzi valori null quando l’origine non fornisce un valore attendibile.
Prestazioni: limiti l’estrazione iniziale per data e progetto, suddivida gli output di grandi dimensioni per data di aggiornamento o progetto, eviti di recuperare ripetutamente dati storici invariati e utilizzi caricamenti incrementali per le esecuzioni pianificate.
Autorizzazioni: l’entità servizio o l’identità gestita deve essere autorizzata a leggere i progetti Azure DevOps selezionati, gli elementi di lavoro, i repository, le pull request, le build e i record di rilascio o distribuzione. I nomi esatti delle autorizzazioni dipendono dalla configurazione di Azure DevOps.
Licenze e disponibilità: verifichi che Azure Data Factory, il connettore Azure DevOps, il runtime di integrazione selezionato e il servizio di archiviazione di destinazione siano disponibili nella sottoscrizione e nell’area geografica. Le funzionalità del connettore possono variare in base alla distribuzione e alla versione.
Stabilità dello schema: convalidi le associazioni dei campi dopo eventuali personalizzazioni del processo Azure DevOps o modifiche al connettore. Gli stati e i campi personalizzati richiedono regole di associazione esplicite.

a Query di esempio sql

WITH source_events AS (
    SELECT
        [DevelopmentItem],
        [WorkItemType],
        [AssignedTo],
        [Priority],
        [TeamName],
        [State],
        [PreviousState],
        [EventType],
        [EventTime],
        [EndTime],
        [SourceEventId],
        [LastDataUpdate],
        [PullRequestId],
        [PullRequestStatus],
        [BuildResult],
        [DeploymentEnvironment],
        [DeploymentResult]
    FROM [Your source event table]
    WHERE [EventTime] >= '[Your start date parameter]'
      AND [EventTime] < '[Your end date parameter]'
      AND [ProjectName] = '[Your project filter]'
),
activity_events AS (
    SELECT [DevelopmentItem], 'Work Item Created' AS [ActivityName], [EventTime], [EndTime], [AssignedTo], [WorkItemType], [State], [Priority], [TeamName], CAST(0 AS bit) AS [IsRework], [LastDataUpdate], [SourceEventId]
    FROM source_events
    WHERE [EventType] = 'WorkItemCreated'

    UNION ALL
    SELECT [DevelopmentItem], 'Work Item Approved', [EventTime], [EndTime], [AssignedTo], [WorkItemType], [State], [Priority], [TeamName], CAST(0 AS bit), [LastDataUpdate], [SourceEventId]
    FROM source_events
    WHERE [EventType] = 'StateChanged'
      AND LOWER(COALESCE([State], '')) IN ('approved', 'ready for dev', 'ready for development')

    UNION ALL
    SELECT [DevelopmentItem], 'Development Started', [EventTime], [EndTime], [AssignedTo], [WorkItemType], [State], [Priority], [TeamName], CAST(CASE WHEN LOWER(COALESCE([PreviousState], '')) IN ('resolved', 'ready for test', 'in qa', 'testing') THEN 1 ELSE 0 END AS bit), [LastDataUpdate], [SourceEventId]
    FROM source_events
    WHERE [EventType] = 'StateChanged'
      AND LOWER(COALESCE([State], '')) IN ('active', 'in progress', 'committed')

    UNION ALL
    SELECT [DevelopmentItem], 'Pull Request Created', [EventTime], [EndTime], [AssignedTo], [WorkItemType], [State], [Priority], [TeamName], CAST(0 AS bit), [LastDataUpdate], [SourceEventId]
    FROM source_events
    WHERE [EventType] = 'PullRequestCreated'
       OR ([PullRequestId] IS NOT NULL AND LOWER(COALESCE([PullRequestStatus], '')) IN ('created', 'active'))

    UNION ALL
    SELECT [DevelopmentItem], 'Pull Request Completed', [EventTime], [EndTime], [AssignedTo], [WorkItemType], [State], [Priority], [TeamName], CAST(0 AS bit), [LastDataUpdate], [SourceEventId]
    FROM source_events
    WHERE [EventType] = 'PullRequestCompleted'
       OR ([PullRequestId] IS NOT NULL AND LOWER(COALESCE([PullRequestStatus], '')) IN ('completed', 'merged'))

    UNION ALL
    SELECT [DevelopmentItem], 'Build Succeeded', [EventTime], [EndTime], [AssignedTo], [WorkItemType], [State], [Priority], [TeamName], CAST(0 AS bit), [LastDataUpdate], [SourceEventId]
    FROM source_events
    WHERE [EventType] = 'BuildCompleted'
      AND LOWER(COALESCE([BuildResult], '')) IN ('succeeded', 'success', 'successful')

    UNION ALL
    SELECT [DevelopmentItem], 'Development Completed', [EventTime], [EndTime], [AssignedTo], [WorkItemType], [State], [Priority], [TeamName], CAST(0 AS bit), [LastDataUpdate], [SourceEventId]
    FROM source_events
    WHERE [EventType] = 'StateChanged'
      AND LOWER(COALESCE([State], '')) IN ('resolved', 'ready for test')

    UNION ALL
    SELECT [DevelopmentItem], 'QA Testing Started', [EventTime], [EndTime], [AssignedTo], [WorkItemType], [State], [Priority], [TeamName], CAST(0 AS bit), [LastDataUpdate], [SourceEventId]
    FROM source_events
    WHERE [EventType] = 'StateChanged'
      AND LOWER(COALESCE([State], '')) IN ('in qa', 'testing', 'qa testing')

    UNION ALL
    SELECT [DevelopmentItem], 'QA Testing Failed', [EventTime], [EndTime], [AssignedTo], [WorkItemType], [State], [Priority], [TeamName], CAST(1 AS bit), [LastDataUpdate], [SourceEventId]
    FROM source_events
    WHERE [EventType] = 'StateChanged'
      AND LOWER(COALESCE([PreviousState], '')) IN ('in qa', 'testing', 'qa testing')
      AND LOWER(COALESCE([State], '')) IN ('active', 'in progress')

    UNION ALL
    SELECT [DevelopmentItem], 'QA Testing Completed', [EventTime], [EndTime], [AssignedTo], [WorkItemType], [State], [Priority], [TeamName], CAST(0 AS bit), [LastDataUpdate], [SourceEventId]
    FROM source_events
    WHERE [EventType] = 'StateChanged'
      AND LOWER(COALESCE([State], '')) IN ('ready for uat', 'qa approved')

    UNION ALL
    SELECT [DevelopmentItem], 'UAT Started', [EventTime], [EndTime], [AssignedTo], [WorkItemType], [State], [Priority], [TeamName], CAST(0 AS bit), [LastDataUpdate], [SourceEventId]
    FROM source_events
    WHERE [EventType] = 'StateChanged'
      AND LOWER(COALESCE([State], '')) IN ('in uat', 'uat testing')

    UNION ALL
    SELECT [DevelopmentItem], 'UAT Approved', [EventTime], [EndTime], [AssignedTo], [WorkItemType], [State], [Priority], [TeamName], CAST(0 AS bit), [LastDataUpdate], [SourceEventId]
    FROM source_events
    WHERE [EventType] = 'StateChanged'
      AND LOWER(COALESCE([PreviousState], '')) IN ('in uat', 'uat testing')
      AND LOWER(COALESCE([State], '')) IN ('uat approved', 'ready for release')

    UNION ALL
    SELECT [DevelopmentItem], 'Deployed to Production', [EventTime], [EndTime], [AssignedTo], [WorkItemType], [State], [Priority], [TeamName], CAST(0 AS bit), [LastDataUpdate], [SourceEventId]
    FROM source_events
    WHERE [EventType] IN ('DeploymentCompleted', 'ReleaseCompleted')
      AND LOWER(COALESCE([DeploymentEnvironment], '')) IN ('production', 'prod')
      AND LOWER(COALESCE([DeploymentResult], '')) IN ('succeeded', 'success', 'successful')

    UNION ALL
    SELECT [DevelopmentItem], 'Work Item Closed', [EventTime], [EndTime], [AssignedTo], [WorkItemType], [State], [Priority], [TeamName], CAST(0 AS bit), [LastDataUpdate], [SourceEventId]
    FROM source_events
    WHERE [EventType] = 'StateChanged'
      AND LOWER(COALESCE([State], '')) IN ('closed', 'done')

    UNION ALL
    SELECT [DevelopmentItem], 'Work Item Cancelled', [EventTime], [EndTime], [AssignedTo], [WorkItemType], [State], [Priority], [TeamName], CAST(0 AS bit), [LastDataUpdate], [SourceEventId]
    FROM source_events
    WHERE [EventType] = 'StateChanged'
      AND LOWER(COALESCE([State], '')) IN ('removed', 'cancelled', 'canceled')
),
deduplicated_events AS (
    SELECT
        [DevelopmentItem],
        [ActivityName],
        [EventTime],
        [EndTime],
        [AssignedTo],
        [WorkItemType],
        [State],
        [Priority],
        [TeamName],
        [IsRework],
        'Azure DevOps' AS [SourceSystem],
        [LastDataUpdate],
        ROW_NUMBER() OVER (
            PARTITION BY [DevelopmentItem], [ActivityName], [EventTime], COALESCE([SourceEventId], '')
            ORDER BY [LastDataUpdate] DESC
        ) AS [RowNumber]
    FROM activity_events
)
SELECT
    [DevelopmentItem],
    [ActivityName],
    [EventTime],
    [EndTime],
    [SourceSystem],
    [LastDataUpdate],
    [AssignedTo],
    [WorkItemType],
    [State],
    [Priority],
    [TeamName],
    [IsRework]
FROM deduplicated_events
WHERE [RowNumber] = 1
  AND [DevelopmentItem] IS NOT NULL
  AND [ActivityName] IN (
      'Work Item Created',
      'Work Item Approved',
      'Development Started',
      'Pull Request Created',
      'Pull Request Completed',
      'Build Succeeded',
      'Development Completed',
      'QA Testing Started',
      'QA Testing Failed',
      'QA Testing Completed',
      'UAT Started',
      'UAT Approved',
      'Deployed to Production',
      'Work Item Closed',
      'Work Item Cancelled'
  )
ORDER BY [DevelopmentItem], [EventTime], [ActivityName];

È pronto a iniziare?

Inizi oggi a migliorare il ciclo di vita dello sviluppo software. Questo template è il primo passo per ottenere informazioni utili sul processo.

Torna alla guida al miglioramento Scarica il template

Ottimizzi oggi il ciclo di vita dello sviluppo software in Azure DevOps!

Riduca del 30% il tempo di ciclo ed elimini i colli di bottiglia nel flusso di lavoro del ciclo di vita dello sviluppo software.

Inizi la prova gratuita

Non è richiesta la carta di credito. Può iniziare in pochi minuti.

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

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

Attributi del ciclo di vita dello sviluppo software

Attività del ciclo di vita dello sviluppo software

Guide all’estrazione

Esportazione delle visualizzazioni di analisi di Azure DevOps in Power BI

Passaggi

Configurazione

a Query di esempio sql

Script PowerShell per l’interrogazione dell’API REST di Azure DevOps

Passaggi

Configurazione

a Query di esempio powershell

Estrazione con script Python tramite la libreria client di Azure DevOps

Passaggi

Configurazione

a Query di esempio python

Pipeline Azure Data Factory con connettore DevOps

Passaggi

Configurazione

a Query di esempio sql

È pronto a iniziare?

Ottimizzi oggi il ciclo di vita dello sviluppo software in Azure DevOps!

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

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

Attributi del ciclo di vita dello sviluppo software

Attività del ciclo di vita dello sviluppo software

Guide all’estrazione

Esportazione delle visualizzazioni di analisi di Azure DevOps in Power BI

Passaggi

Configurazione

a Query di esempio sql

Script PowerShell per l’interrogazione dell’API REST di Azure DevOps

Passaggi

Configurazione

a Query di esempio powershell

Estrazione con script Python tramite la libreria client di Azure DevOps

Passaggi

Configurazione

a Query di esempio python

Pipeline Azure Data Factory con connettore DevOps

Passaggi

Configurazione

a Query di esempio sql

È pronto a iniziare?

Ottimizzi oggi il ciclo di vita dello sviluppo software in Azure DevOps!

La Sua privacy è importante