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

ServiceNow 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 guida alla raccolta dei dati per ottimizzare l'SDLC. Elenca gli attributi essenziali e le attività da tracciare, offrendo consigli pratici sull'estrazione da ServiceNow DevOps. Lo usi per costruire un event log robusto e ottenere analisi approfondite.
  • Attributi consigliati da raccogliere
  • Attività chiave da tracciare
  • Guida all'estrazione per ServiceNow DevOps
È nuovo agli event log? Impari come creare un event log di Process Mining.

Attributi del ciclo di vita dello sviluppo software

Questi sono i campi dati consigliati da includere nell'event log per un'analisi completa del Suo ciclo di vita dello sviluppo software.
5 Obbligatorio 8 Consigliato 5 Facoltativo
Nome Descrizione
Elemento di sviluppo
DevelopmentItem
L'identificatore univoco per una singola unità di lavoro (feature, bug o task) che attraversa il ciclo di vita dello sviluppo.
Descrizione

L'elemento di sviluppo funge da identificatore principale (Case ID), rappresentando l'unità di lavoro tracciata. Collega tutte le attività, dall'ideazione iniziale al deployment finale per quell'elemento specifico.

Nell'analisi di process mining, questo attributo è fondamentale per ricostruire il percorso end-to-end di ogni elemento. Consente la visualizzazione dei flussi, il calcolo dei tempi di ciclo totali e l'identificazione delle varianti di processo per feature o bug fix. Ogni evento deve essere associato a un elemento di sviluppo per costruire una mappa coerente.

Perché è importante

Identificatore principale che connette tutte le attività di sviluppo in un'unica istanza di processo per analizzare il ciclo completo.

Dove trovare

Identificatore che solitamente corrisponde alla primary key delle tabelle story, bug o task in ServiceNow.

Esempi
STRY0010015BUG0034092TASK0050118
Nome attività
ActivityName
Il nome dello specifico evento del ciclo di vita dello sviluppo, come 'Inizio sviluppo' o 'Code review eseguita'.
Descrizione

Registra il nome di ogni milestone o task completato. Queste attività formano i passaggi sequenziali del processo.

Analizzare la sequenza e la frequenza di queste attività è il cuore del process mining. Permette di costruire la mappa dei processi, identificare colli di bottiglia e varianti inefficienti. Include fasi chiave come design, sviluppo, test e deployment.

Perché è importante

Definisce le fasi nella mappa dei processi, consentendo l'analisi del flusso, l'identificazione dei colli di bottiglia e l'individuazione di deviazioni dallo standard SDLC.

Dove trovare

In genere si ottiene mappando i cambi di stato o l'audit trail a nomi di attività standard. Esempio: stato 'In corso' diventa 'Inizio sviluppo'.

Esempi
Sviluppo iniziatoCodice committatoTest QA completatiRilasciato in produzione
Ora di Inizio
EventTime
Il timestamp esatto che indica quando si è verificata una specifica attività o evento.
Descrizione

Fornisce data e ora di inizio di ogni attività. È essenziale per l'ordine cronologico e le analisi temporali.

Nel process mining, serve a calcolare le durate tra le fasi, i tempi di attesa e il tempo di ciclo totale. È un componente critico per le dashboard di performance (Analisi ciclo di vita end-to-end) e per calcolare KPI come il Lead Time della code review.

Perché è importante

Timestamp essenziale per l'ordinamento degli eventi e il calcolo delle performance: tempi di ciclo, durate e attese.

Dove trovare

Solitamente reperibile nei campi timestamp di sistema come 'sys_updated_on' o 'sys_created_on'.

Esempi
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:15:00Z
Sistema di Origine
SourceSystem
Identifica il sistema da cui sono stati estratti i dati, che in questo caso è ServiceNow DevOps.
Descrizione

Specifica il sistema di origine dei dati, che per questo processo sarà 'ServiceNow DevOps'.

Anche se costante, includerlo è cruciale per la data governance in ambienti che uniscono dati da più sistemi (es. Jira o Azure DevOps). Garantisce chiarezza sulla provenienza dei dati e aiuta a diagnosticare problemi di qualità o estrazione.

Perché è importante

Garantisce la tracciabilità dei dati ed è essenziale per mantenere l'integrità delle informazioni, specialmente quando si integrano dati da più strumenti di sviluppo.

Dove trovare

Questo è un valore statico che dovrebbe essere aggiunto durante il processo di estrazione e trasformazione dei dati.

Esempi
ServiceNow DevOps
Ultimo `Data Update`
LastDataUpdate
Timestamp dell'ultimo aggiornamento dei dati dell'event log dal sistema sorgente.
Descrizione

Indica l'ultima estrazione o aggiornamento del dataset da ServiceNow DevOps.

È vitale per capire quanto siano attuali gli insight. Informa gli utenti sulla freschezza dei dati e aiuta a pianificare i refresh. Mostrare questo timestamp nelle dashboard garantisce che le decisioni siano basate su informazioni tempestive.

Perché è importante

Fornisce un contesto cruciale sulla tempestività dei dati, garantendo che gli utenti sappiano quanto sia aggiornata l'analisi del processo.

Dove trovare

Generato durante l'estrazione dati, registra il momento esatto dell'esecuzione.

Esempi
2023-11-15T08:00:00Z
È una Rilavorazione
IsRework
Un flag booleano impostato su vero se l'attività fa parte di un loop di rework, come il ritorno allo sviluppo dopo la fase di test.
Descrizione

Attributo derivato che identifica attività avvenute dopo un loop all'indietro. Se 'Inizio Sviluppo' avviene dopo 'QA Completata', viene segnato come rework.

È essenziale per quantificare il rework. Supporta la dashboard 'Analisi flussi di scarto e rework' e calcola il KPI 'Tasso di rework post-test'. Permette di filtrare e analizzare frequenza e cause del lavoro ripetuto sul tempo totale.

Perché è importante

Questo flag semplifica la quantificazione del rework, aiutando a misurare la qualità del processo e a trovare le cause dei lavori ripetuti.

Dove trovare

Attributo calcolato dallo strumento di process mining analizzando la sequenza di attività per rilevare movimenti retrogradi nel flusso (loop).

Esempi
truefalse
Gruppo di Assegnazione
AssignmentGroup
Il team o il gruppo responsabile dell'elemento al momento dell'attività.
Descrizione

Identifica il team assegnato (es. 'Frontend', 'QA'). Il tracciamento dell'assignment group è essenziale per comprendere la collaborazione interfunzionale e i passaggi di consegna.

Aiuta a individuare i ritardi sistemici che avvengono quando il lavoro passa da un team all'altro, supportando l'analisi delle performance di squadra e identificando quali team rappresentano un collo di bottiglia nel flusso globale.

Perché è importante

Traccia il team responsabile, permettendo l'analisi delle performance, del bilanciamento dei carichi e dell'efficienza dei passaggi di consegna.

Dove trovare

Informazione memorizzata nel campo 'assignment_group', standard nelle tabelle task di ServiceNow.

Esempi
Platform EngineeringTeam Mobile AppAssicurazione QualitàDevOps
Modulo/Componente interessato
ModuleComponentAffected
Lo specifico modulo, applicazione o componente software a cui si riferisce l'elemento di sviluppo.
Descrizione

Questo attributo categorizza il lavoro in base alla parte di sistema interessata (microservizio, componente UI o backend).

Segmentare il processo per modulo è cruciale per identificare colli di bottiglia localizzati. La dashboard 'Insight colli di bottiglia per componente' e il KPI 'Durata media fase per componente' usano questo dato per capire se certe aree del codice hanno cicli più lunghi o più errori, permettendo di concentrare i miglioramenti dove serve davvero.

Perché è importante

Consente di segmentare l'analisi per applicazione o componente, aiutando a isolare bottleneck o problemi di qualità specifici di determinate parti del sistema.

Dove trovare

Spesso è un campo personalizzato o un riferimento al CMDB ('cmdb_ci'). Consulti la documentazione di ServiceNow DevOps.

Esempi
Servizio di fatturazioneUI Autenticazione UtenteDatabase per la reportisticaAPI Gateway
Priorità
DevelopmentItemPriority
Il livello di priorità assegnato all'elemento, come 'Alta', 'Media' o 'Bassa'.
Descrizione

Questo attributo categorizza gli elementi in base all'urgenza aziendale. I livelli di priorità aiutano i team a concentrarsi sui task critici e sono usati per gestire SLA e aspettative.

Nel process mining, la priorità è fondamentale per l'analisi comparativa. Permette di filtrare la mappa dei processi per verificare se gli elementi critici seguono percorsi più rapidi. È essenziale per la dashboard 'Tempo di consegna feature ad alta priorità', validando l'effettiva accelerazione dei task urgenti.

Perché è importante

Consente di filtrare e confrontare i processi per diversi livelli di priorità, aiutando a verificare se gli elementi urgenti siano gestiti in modo più rapido ed efficiente.

Dove trovare

Campo standard, solitamente denominato 'priority', sulle tabelle task di ServiceNow.

Esempi
1 - Critico2 - Alto3 - Moderate4 - Basso
Stato dell'elemento di sviluppo
DevelopmentItemState
Lo stato dell'elemento di sviluppo al momento dell'evento, come 'Aperto', 'In corso' o 'Chiuso'.
Descrizione

Riflette lo stato ufficiale dell'elemento in ServiceNow. Mentre le attività sono passaggi derivati, lo 'State' rappresenta la fase formale nel workflow del sistema.

Spesso è la fonte da cui si ricavano le attività. Può essere usato per validare i dati o creare viste di alto livello. Analizzare il tempo trascorso in ogni stato può offrire una prospettiva diversa sui colli di bottiglia rispetto al tempo tra le attività, ed è utile per identificare task bloccati.

Perché è importante

Fornisce lo stato ufficiale di sistema di un elemento di lavoro, che è spesso la fonte per ricavare le attività e può essere utilizzato per la validazione e l'analisi di stato ad alto livello.

Dove trovare

Campo standard, solitamente 'state' o 'stage', sulle tabelle task di ServiceNow.

Esempi
In SospesoLavoro in corsoPronto per il testChiuso Completato
Sviluppatore assegnato
AssignedDeveloper
Il nome o l'ID dello sviluppatore o dell'utente assegnato all'elemento al momento dell'attività.
Descrizione

Identifica la persona responsabile di un task. È un dato dinamico che cambia con il progredire dell'elemento tra team e fasi.

È fondamentale per analizzare l'allocazione delle risorse e il carico di lavoro. Supporta la dashboard 'Carico di lavoro e passaggi di consegna' e il KPI 'Volume attività per sviluppatore'. Tracciare questo campo permette di misurare i tempi di consegna e individuare colli di bottiglia nella collaborazione tra developer o tra sviluppo e QA.

Perché è importante

Essenziale per l'analisi basata sulle risorse, inclusa la distribuzione del carico e l'efficienza dei passaggi tra team.

Dove trovare

Dato solitamente memorizzato nel campo 'assigned_to' nelle tabelle task di ServiceNow.

Esempi
David MillerAnna WilliamsJames Brown
Tempo di ciclo dell'elemento di sviluppo
DevelopmentItemCycleTime
Il tempo totale trascorso dalla creazione dell'elemento alla sua chiusura finale o al deployment.
Descrizione

Metrica calcolata che rappresenta la durata end-to-end di un elemento, misurando la differenza tra il timestamp della prima e dell'ultima attività.

È il KPI principale dell'intero processo SDLC (Tempo di ciclo medio), fornendo una misura della velocità e dell'efficienza. Analizzare questa metrica nel tempo e per dimensioni (priorità, team) permette di monitorare l'impatto reale delle iniziative di miglioramento.

Perché è importante

Rappresenta la durata totale end-to-end di un elemento di lavoro, una metrica chiave per misurare l'efficienza e la velocità complessiva del processo.

Dove trovare

Non è un campo del sistema sorgente. È calcolato sottraendo lo StartTime minimo dal massimo per ogni CaseId.

Esempi
15 giorni 4 ore3 giorni e 12 ore32 giorni 8 ore
Tipo elemento di sviluppo
DevelopmentItemType
La classificazione dell'elemento di lavoro, come 'Feature', 'Bug', 'Debito tecnico' o 'Task'.
Descrizione

Questo attributo distingue le diverse tipologie di lavoro nell'SDLC. Ad esempio, risolvere un bug critico può seguire un iter diverso e più rapido rispetto allo sviluppo di una feature.

L'analisi per tipo di elemento offre una comprensione più sfumata delle performance. Aiuta a capire se i bug hanno tassi di rework più alti delle feature o se il tempo di ciclo per la riduzione del debito tecnico è accettabile, fornendo insight molto più granulari di una visione generica.

Perché è importante

Distingue tra diversi tipi di lavoro, come feature e bug, che potrebbero seguire percorsi di processo, priorità e durate previste differenti.

Dove trovare

Può essere determinato dalla tabella di origine (es. 'rm_story' vs 'rm_bug') o da un campo 'type' su una tabella task generica.

Esempi
FunzionalitàBugTaskSpike
ID Commit
CommitId
L'identificatore univoco del commit del codice sorgente associato al lavoro di sviluppo.
Descrizione

Fornisce un link diretto tra l'elemento e la modifica nel repository (es. Git). Viene acquisito durante il commit.

Il Commit ID arricchisce l'analisi collegando i dati di processo a quelli di engineering. Permette di risalire dal deployment problematico alla riga di codice esatta o di correlare la complessità del codice ai tempi di sviluppo, offrendo un livello tecnico molto più profondo nell'analisi delle cause.

Perché è importante

Collega l'evento del processo a una specifica modifica del codice, consentendo un'analisi delle cause profonde più accurata grazie alla correlazione tra metriche di processo e dettagli a livello di codice.

Dove trovare

Dato acquisito tramite le integrazioni DevOps con SCM come Git o SVN. I dati si trovano nelle tabelle collegate all'elemento di sviluppo.

Esempi
a1b2c3d4e5f6f0e9d8c7b6a59a8b7c6d5e4f
Motivo Rilavorazione
ReworkReason
Una classificazione o descrizione del motivo per cui un elemento di sviluppo ha richiesto un rework dopo i test.
Descrizione

Se un elemento fallisce QA o UAT, cattura il motivo dell'errore (bug, requisiti poco chiari, problemi di ambiente).

Questo dato è cruciale per la dashboard 'Analisi flussi di scarto e rework'. Permette di capire il perché del rework e intervenire in modo mirato (es. test più stabili o requisiti migliori) per ridurre il tasso complessivo di rilavorazione.

Perché è importante

Fornisce insight qualitativi sul motivo per cui si verifica il rework, consentendo miglioramenti mirati del processo per aumentare la qualità e ridurre i cicli di rilavorazione.

Dove trovare

Può trovarsi nei 'close_notes' o in un campo 'rework_reason'. Consulti la documentazione ServiceNow DevOps.

Esempi
Requisito fraintesoBug di regressioneTest delle prestazioni fallitoProblema UI/UX
Ora di Fine
EventEndTime
Il timestamp esatto del completamento di un'attività. Per gli eventi istantanei, coincide con l'ora di inizio.
Descrizione

Fornisce data e ora di fine di ogni attività. È utile per fasi con durata misurabile come 'Code review' o 'QA'.

Avere sia l'inizio che la fine permette di calcolare i tempi di elaborazione netti, distinguendoli dai tempi di attesa. Questo aiuta a capire se i ritardi sono dovuti a task complessi o a tempi morti in attesa di risorse. Per eventi istantanei (es. build avviata), i due timestamp coincidono.

Perché è importante

Consente il calcolo preciso del tempo di elaborazione dell'attività, aiutando a distinguere tra il tempo di lavoro effettivo e il tempo di attesa.

Dove trovare

Potrebbe essere derivato dal timestamp dell'inizio dell'attività successiva o da un campo 'end date' nel sistema sorgente.

Esempi
2023-10-26T18:05:00Z2023-10-28T11:20:15Z2023-11-02T10:00:00Z
Stato del rilascio
DeploymentStatus
Indica l'esito di un'attività di rilascio, solitamente 'Success' (successo) o 'Failure' (fallimento).
Descrizione

Registra l'esito del deployment. È fondamentale per valutare l'affidabilità del processo di rilascio.

Supporta la dashboard 'Trend successi e fallimenti deployment' e il KPI 'Tasso di errore deployment'. Analizzando questi trend, le aziende individuano problemi nei test, nell'infrastruttura o nel coordinamento, migliorando la stabilità della consegna software.

Perché è importante

Misura direttamente il successo delle attività di rilascio, il che è fondamentale per calcolare il tasso di errore dei rilasci e analizzare la stabilità delle release.

Dove trovare

Stato solitamente registrato nei task di deployment o nei record di esecuzione della pipeline integrata.

Esempi
SuccessoFallimentoCompletato con avvisi
Versione di rilascio pianificata
PlannedReleaseVersion
La release o versione software di destinazione prevista per la consegna dell'elemento.
Descrizione

Collega l'elemento a una release pianificata (es. 'Versione 2.3'). È un elemento chiave per il project management.

Nel process mining, è fondamentale per la dashboard 'Monitoraggio aderenza piano di rilascio'. Confrontando le date di completamento reali con quelle pianificate, i team misurano il rispetto delle scadenze e analizzano le cause dei ritardi, collegando i dettagli tecnici agli obiettivi di business.

Perché è importante

Collega il lavoro di sviluppo a release specifiche, consentendo l'analisi del rispetto della pianificazione e dell'impatto dei ritardi del processo sulle tempistiche di rilascio.

Dove trovare

Dato solitamente memorizzato nei campi 'release' o 'planned_release', che puntano alla gestione release di ServiceNow. Consulti la documentazione specifica.

Esempi
v3.4.1Rilascio Q1 2024Go-Live Progetto Phoenix
Obbligatorio Consigliato Facoltativo

Attività del ciclo di vita dello sviluppo software

Questi sono i passaggi chiave del processo e le tappe fondamentali da acquisire nel suo event log per un'accurata scoperta e ottimizzazione del processo.
7 Consigliato 9 Facoltativo
Activity Descrizione
Code Review eseguita
Questa attività indica il completamento di una peer review, solitamente associata a una pull o merge request. L'evento può essere acquisito tramite integrazioni DevOps o ricavato dai cambi di stato.
Perché è importante

Rappresenta un quality gate fondamentale. Analizzarne la durata aiuta a trovare blocchi nel processo di revisione, causa comune di ritardi nell'SDLC.

Dove trovare

Può essere acquisito dall'evento 'Merged' o 'Completed' di un record di Pull Request nell'integrazione Git di ServiceNow, oppure dedotto da un cambio di stato dell'elemento di sviluppo in 'Revisione codice completata'.

Acquisisci

Registrato quando viene eseguito il merge di una Pull Request collegata all'elemento di lavoro.

Tipo di evento explicit
Elemento di sviluppo creato
Questa attività segna la creazione di un nuovo elemento (story, bug o epic) in ServiceNow. L'evento viene solitamente acquisito quando un nuovo record viene inserito nella tabella Story [rm_story].
Perché è importante

Evento di inizio principale dell'SDLC. Permette di misurare il tempo di ciclo totale e tracciare l'ingresso iniziale delle richieste.

Dove trovare

Registrato nelle tabelle sys_audit o sys_history_line alla creazione di un record in una tabella relativa allo sviluppo, come Story [rm_story], Epic [rm_epic] o Defect [rm_defect]. Il timestamp di creazione si trova solitamente sul record stesso.

Acquisisci

Acquisito dal timestamp di creazione del record dell'elemento di sviluppo.

Tipo di evento explicit
Rilasciato in produzione
Segna il completamento con successo del deployment in produzione. Viene acquisito esplicitamente quando lo strumento CI/CD conferma la riuscita della pipeline.
Perché è importante

Punto finale di successo del processo SDLC. Completa il flusso di valore ed è fondamentale per il calcolo del tempo di ciclo totale.

Dove trovare

Acquisito dal campo 'completion_status' di un record Pipeline Execution [sn_devops_pipeline_execution] o della relativa esecuzione della fase (Stage Execution Run). Uno stato 'Success' al termine dell'operazione contrassegna questo evento.

Acquisisci

Registrato al completamento con successo della pipeline di deployment in produzione.

Tipo di evento explicit
Rilascio fallito
Indica che il tentativo di rilascio dell'elemento di sviluppo in produzione non è andato a buon fine. Questo dato viene acquisito esplicitamente da ServiceNow DevOps quando la pipeline CI/CD segnala un errore.
Perché è importante

Questo è un punto finale di errore critico. Analizzarne frequenza e cause è la chiave per migliorare la stabilità dei rilasci e ridurre i fallimenti.

Dove trovare

Acquisito dal campo 'completion_status' di un record Pipeline Execution [sn_devops_pipeline_execution]. Uno stato 'Failed' al termine dell'operazione contrassegna questo evento.

Acquisisci

Registrato quando la pipeline di deployment in produzione segnala uno stato di errore.

Tipo di evento explicit
Sviluppo iniziato
Questa attività indica quando uno sviluppatore inizia effettivamente a programmare o implementare l'elemento. In genere viene ricavata dal cambio di stato in 'In corso' o 'Sviluppo'.
Perché è importante

Milestone cruciale che segna l'inizio della fase di costruzione. Essenziale per misurare il lead time degli sviluppatori e i cicli di code review.

Dove trovare

Dedotto dal timestamp in cui il campo 'State' nel record dell'elemento di sviluppo (ad es. Story [rm_story]) viene aggiornato a uno stato 'In corso' o equivalente.

Acquisisci

Basato sul timestamp di un cambio di stato in 'In corso' o un valore simile.

Tipo di evento inferred
Test QA completati
Indica che il team di QA ha completato con successo i test. Solitamente viene ricavato quando lo stato dell'elemento passa dalla fase di test a uno stato come 'Pronto per UAT' o 'Completato'.
Perché è importante

Milestone che segna il superamento di un quality gate. È prerequisito per UAT o preparazione del rilascio.

Dove trovare

Dedotto dal timestamp di un cambio di stato da uno stato di test (ad es. 'In QA') a uno stato post-test (ad es. 'Pronto per UAT' o 'Risolto').

Acquisisci

Basato sul timestamp di un cambio di stato da 'Testing' a uno stato successivo.

Tipo di evento inferred
UAT Approvato
Indica che gli stakeholder aziendali hanno approvato formalmente l'elemento di sviluppo dopo lo User Acceptance Testing (UAT). Si tratta di una pietra miliare chiave dedotta da un cambio di stato, come il passaggio da 'In UAT' a 'Pronto per il rilascio' o 'Approvato'.
Perché è importante

Approvazione aziendale finale prima della produzione. Rappresenta un checkpoint critico per qualità e governance.

Dove trovare

Dedotto da una transizione di stato nel record dell'elemento di sviluppo che indica il completamento con successo dell'UAT. Questo dato viene registrato nella cronologia delle attività dell'elemento.

Acquisisci

Dedotto da un cambio di stato da 'UAT' a uno stato di approvazione o di prontezza al rilascio.

Tipo di evento inferred
Build avviata
Indica l'avvio della build in una pipeline CI/CD, spesso attivata da un commit. ServiceNow DevOps registra l'evento come esecuzione della pipeline, collegandolo agli elementi di sviluppo.
Perché è importante

Questa attività fa da ponte tra lo sviluppo e il test o deployment automatizzato. Analizzare il tempo tra commit e avvio della build può rivelare ritardi nel processo CI/CD.

Dove trovare

Registrato esplicitamente nella tabella Pipeline Execution [sn_devops_pipeline_execution] quando viene avviata una build nello strumento CI/CD integrato (es. Jenkins, Azure DevOps).

Acquisisci

Acquisito dall'ora di inizio di un record nella tabella Pipeline Execution.

Tipo di evento explicit
Codice committato
Rappresenta un commit di codice da parte di uno sviluppatore in un repository SCM collegato all'elemento di sviluppo. ServiceNow DevOps acquisisce esplicitamente questi eventi da strumenti integrati come Git o GitHub.
Perché è importante

Il tracciamento dei commit offre visibilità granulare sui progressi e permette di correlare le modifiche al codice all'elemento di sviluppo padre.

Dove trovare

Acquisito come evento esplicito nella tabella ServiceNow DevOps Commits [sn_devops_commit], popolata tramite webhook dal sistema di gestione del codice sorgente integrato.

Acquisisci

Registrato quando viene ricevuto un webhook di commit dallo strumento SCM.

Tipo di evento explicit
Design iniziato
Rappresenta la fase in cui viene creato il design tecnico o l'architettura della soluzione. Solitamente viene ricavata dal cambio di stato del record dell'elemento di sviluppo in valori come 'Design' o 'Solutioning'.
Perché è importante

Analizzare la durata della fase di design aiuta a identificare i bottleneck nella traduzione dei requisiti e nella pianificazione della soluzione prima dell'inizio del lavoro di sviluppo.

Dove trovare

Dedotto dalle transizioni di stato nel record dell'elemento di sviluppo (ad es. Story [rm_story]). Si cercano modifiche al campo 'State' o a un campo personalizzato 'Stage' verso un valore relativo al design.

Acquisisci

Dedotto da un cambio di stato in 'Design' o uno stato simile.

Tipo di evento inferred
Elemento di sviluppo annullato
Rappresenta l'interruzione di un elemento di sviluppo prima del completamento. È uno stato finale alternativo, solitamente ricavato quando lo stato dell'elemento è 'Annullato' o 'Chiuso incompleto'.
Perché è importante

Tracciare gli annullamenti aiuta a individuare gli sforzi sprecati e a capire i motivi dei cambi di scope o priorità, offrendo un quadro completo del processo.

Dove trovare

Ricavato dal timestamp relativo all'aggiornamento del campo 'Stato' del record dell'elemento di sviluppo verso uno stato finale non completato, come 'Annullato'.

Acquisisci

Dedotto da un cambio di stato in 'Annullato' o uno stato terminale equivalente.

Tipo di evento inferred
Inizio rilascio in produzione
Questa attività segna l'avvio della pipeline di deployment in produzione. ServiceNow DevOps la acquisisce come evento esplicito all'inizio dell'esecuzione della fase di produzione.
Perché è importante

Segna l'inizio dell'ultima fase, spesso la più critica. Tracciarla aiuta ad analizzare la durata del deployment e a trovare opportunità di automazione.

Dove trovare

Registrato esplicitamente nella tabella Stage Execution Run [sn_devops_stage_execution], filtrata per le fasi relative all'ambiente di produzione.

Acquisisci

Acquisito dall'ora di inizio di una fase di rilascio in produzione in una Pipeline Execution.

Tipo di evento explicit
Pronto per il rilascio
Questa attività indica che l'elemento ha superato tutti i quality gate ed è incluso in una release. Si ricava dall'associazione a un record di Release o dal cambio di stato in 'Pronto per il deployment'.
Perché è importante

Indica che l'elemento è completo. Il tempo passato in questo stato rappresenta spesso la coda prima della finestra di deployment programmata.

Dove trovare

Dedotto dal cambio del campo 'State' in 'Pronto per il rilascio' o tracciando quando il campo 'Release' nel record dell'elemento di sviluppo viene popolato o aggiornato.

Acquisisci

Dedotto da un cambio di stato o dall'associazione con un record di release.

Tipo di evento inferred
Rework identificato
Indica che è stato riscontrato un problema durante i test, rendendo necessario il rinvio dell'elemento allo sviluppo. Questo evento viene dedotto osservando un movimento a ritroso nel flusso del processo, come un cambio di stato da 'In QA' di nuovo a 'In corso'.
Perché è importante

Tracciare il rework è vitale per capire problemi di qualità e inefficienze. Un'alta frequenza indica criticità nello sviluppo o poca chiarezza nei requisiti.

Dove trovare

Dedotto analizzando la cronologia del campo 'State' nelle tabelle sys_audit o sys_history_line. Un passaggio da uno stato di fase avanzata (ad es. 'Testing') a uno precedente (ad es. 'In corso') indica un rework.

Acquisisci

Dedotto da una transizione di stato all'indietro, ad es. 'Testing' -> 'In corso'.

Tipo di evento inferred
Test QA iniziati
Segna l'inizio della fase formale di Quality Assurance. Questo dato viene quasi sempre ricavato dal cambio di stato dell'elemento di sviluppo in valori come 'In QA', 'Testing' o 'Ready for Test'.
Perché è importante

Questa attività segnala il passaggio dallo sviluppo al team di QA. Permette di misurare la durata della fase di test e identificare eventuali limiti di capacità.

Dove trovare

Dedotto dal timestamp in cui il campo 'State' nel record dell'elemento di sviluppo (ad es. Story, Defect) viene aggiornato a uno stato specifico per la QA.

Acquisisci

Basato sul timestamp di un cambio di stato in 'Testing' o equivalente.

Tipo di evento inferred
UAT Avviato
Rappresenta l'inizio dell'UAT, dove gli stakeholder aziendali validano la funzionalità. L'evento viene acquisito tramite il cambio di stato in 'UAT' o 'User Acceptance Testing'.
Perché è importante

Fase critica per garantire che la feature soddisfi i requisiti. Analizzarne la durata rivela problemi di engagement o incongruenze nei requisiti.

Dove trovare

Dedotto da una transizione di stato nel record dell'elemento di sviluppo. Questo dipende dal modello degli stati del cliente, che deve includere uno stato distinto per l'UAT.

Acquisisci

Dedotto da un cambio di stato verso uno stato di 'UAT'.

Tipo di evento inferred
Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i dati da ServiceNow DevOps