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
- Attributi consigliati da raccogliere
- Attività chiave da monitorare per il Suo SDLC
- Guida dettagliata all'estrazione per Azure DevOps
Attributi dell'SDLC
| Nome | Descrizione | ||
|---|---|---|---|
|
Elemento di sviluppo
DevelopmentItem
|
L'ID univoco dell'unità di lavoro, che funge da identificatore del caso per il processo. | ||
|
Descrizione
Rappresenta l'unità di lavoro in Azure DevOps. In ambito process mining, è fondamentale per correlare gli eventi in un unico percorso (case journey), permettendo l'analisi di tempi di ciclo e rework.
Perché è importante
Identificatore principale che connette i passaggi in un caso coerente per l'analisi end-to-end.
Dove trovare
Corrisponde al campo 'ID' di un work item in Azure DevOps Boards.
Esempi
10234102351023610237
|
|||
|
Nome attività
ActivityName
|
Il nome dell'evento o task specifico verificatosi nel ciclo di vita. | ||
|
Descrizione
Descrive una fase specifica, come 'Sviluppo avviato'. Questo attributo è essenziale per costruire la mappa di processo e identificare percorsi comuni e bottleneck tra le attività.
Perché è importante
Definisce le fasi del processo, costituendo l'ossatura della mappa di processo e permettendo l'analisi di workflow, bottleneck e deviazioni.
Dove trovare
Derivato solitamente dai cambi di stato o da eventi collegati come commit e PR.
Esempi
Sviluppo iniziatoPull Request completataTest QA fallitiDistribuito in produzioneWork Item chiuso
|
|||
|
Timestamp Evento
EventTime
|
Il timestamp preciso di quando si è verificata l'attività. | ||
|
Descrizione
L'Event Time acquisisce la data e l'ora di ogni attività nel ciclo di vita dello sviluppo. Questo timestamp è l'elemento temporale fondamentale utilizzato per ordinare gli eventi cronologicamente e calcolare le durate tra di essi. Nell'analisi, questo attributo è fondamentale per calcolare tutte le metriche basate sul tempo, inclusi tempi di ciclo, tempi di elaborazione e tempi di attesa. Consente la creazione di un event log ordinato temporalmente, input necessario per qualsiasi analisi di Process Mining. Viene utilizzato per diagnosticare ritardi, misurare le prestazioni rispetto agli SLA e monitorare i trend nel tempo.
Perché è importante
Fornisce l'ordine cronologico, essenziale per calcolare i KPI di durata e capire i bottleneck.
Dove trovare
Data di modifica associata a ogni aggiornamento della cronologia.
Esempi
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
|
|||
|
Sistema di Origine
SourceSystem
|
Il sistema di origine dei dati, in questo caso Azure DevOps. | ||
|
Descrizione
Identifica il sistema di origine. È utile per la data governance e le integrazioni future con altri sistemi come SAP o ServiceNow.
Perché è importante
Fornisce un contesto cruciale sull'origine dei dati, importante per la data governance, la validazione e l'analisi di processi multi-sistema.
Dove trovare
Valore statico aggiunto durante l'estrazione per etichettare il dataset.
Esempi
Azure DevOps
|
|||
|
Ultimo `Data Update`
LastDataUpdate
|
Il `timestamp` che indica l'ultima volta che i `data` per questo processo sono stati aggiornati dal sistema sorgente. | ||
|
Descrizione
Indica l'ultimo aggiornamento dei dati. Conoscere la freschezza dei dati è critico per prendere decisioni informate e contestualizzare i risultati.
Perché è importante
Informa gli utenti sull'aggiornamento dei dati, assicurando che le analisi e le decisioni si basino su un intervallo temporale ben definito.
Dove trovare
Timestamp generato durante il processo di estrazione e caricamento dei dati (ETL).
Esempi
2024-05-20T08:00:00Z
|
|||
|
Assegnato a
AssignedTo
|
L'utente o il membro del team a cui è attualmente assegnato l'elemento. | ||
|
Descrizione
Identifica il responsabile in una data fase. È critico per monitorare il carico di lavoro di sviluppatori e tester e identificare eventuali membri del team sovraccarichi.
Perché è importante
Permette un'analisi basata sulle risorse, aiutando a comprendere la distribuzione del carico di lavoro, identificare i bottleneck specifici e gestire la capacità del team.
Dove trovare
Corrisponde al campo 'Assigned To' di un work item in Azure DevOps.
Esempi
jane.doe@example.comjohn.smith@example.comnon assegnato
|
|||
|
È una Rilavorazione
IsRework
|
Un flag booleano che indica se un elemento di sviluppo è rientrato in una fase precedente del suo ciclo di vita. | ||
|
Descrizione
Indica se un item ha subito un ciclo di rework. Permette di quantificare le inefficienze dovute a lacune comunicative o test insufficienti.
Perché è importante
Identifica e quantifica direttamente il rework (rilavorazione), aiutando a evidenziare problemi di qualità e inefficienze di processo che allungano i tempi di ciclo.
Dove trovare
Attributo calcolato analizzando la sequenza di attività nell'event log.
Esempi
truefalse
|
|||
|
Nome del team
TeamName
|
Il nome del team di sviluppo responsabile del work item. | ||
|
Descrizione
Identifica il team assegnatario. Consente di segmentare l'analisi per confrontare le performance tra i vari team e condividere le best practice.
Perché è importante
Abilita un'analisi comparativa tra diversi team, aiutando a identificare variazioni di performance e a condividere le best practice in tutta l'organizzazione.
Dove trovare
Spesso derivato dall'Area Path, poiché i team sono mappati su questi percorsi in Azure DevOps.
Esempi
Team PhoenixOmega SquadPlatform CoreTeam Frontend
|
|||
|
Ora di Fine
EndTime
|
Il timestamp di fine attività, usato per calcolare il tempo di esecuzione. | ||
|
Descrizione
Indica la conclusione di un'attività. È cruciale per calcolare il tempo di esecuzione e distinguere il lavoro attivo dai tempi morti di attesa.
Perché è importante
Permette il calcolo preciso dei tempi di esecuzione delle attività e dei tempi di inattività, fondamentali per l'analisi dei bottleneck e il miglioramento dell'efficienza.
Dove trovare
Spesso derivato dal timestamp dell'evento successivo o registrato esplicitamente se il sistema lo prevede.
Esempi
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
|
|||
|
Priorità
Priority
|
Una classificazione numerica o descrittiva dell'importanza dell'elemento di sviluppo rispetto ad altri elementi. | ||
|
Descrizione
La priorità indica l'importanza di pianificazione di un work item. Valori comuni sono numerici, da 1 (massima) a 4. Questo attributo è essenziale per la dashboard Priority-Based Throughput & Cycle Time. L'analisi aiuta a capire se il sistema di prioritizzazione è efficace, ovvero se gli elementi critici procedono effettivamente più velocemente degli altri.
Perché è importante
Consente di analizzare se il processo accelera efficacemente gli elementi ad alta priorità, un fattore chiave per valutare il successo delle strategie di prioritizzazione.
Dove trovare
Corrisponde al campo 'Priority' di un work item in Azure DevOps.
Esempi
1234
|
|||
|
Stato
State
|
Lo stato attuale nel workflow, come 'New', 'Active', 'Resolved' o 'Closed'. | ||
|
Descrizione
Rappresenta lo stato formale dell'elemento. È utile per capire quanto tempo gli item passano in stati specifici ed è fondamentale per l'analisi dei passaggi (handoff).
Perché è importante
Indica lo stato del work item nel ciclo di vita, elemento fondamentale per comprendere il flusso del processo e calcolare il tempo trascorso nelle varie fasi.
Dove trovare
Corrisponde al campo 'State' di un work item in Azure DevOps.
Esempi
NuovoAttivoIn QARisoltoChiuso
|
|||
|
Tempo di ciclo dello sviluppo
DevelopmentCycleTime
|
Il tempo totale trascorso dalla creazione dell'elemento al rilascio in produzione. | ||
|
Descrizione
Il Tempo di ciclo dello sviluppo (Development Cycle Time) è un KPI che misura la durata end-to-end del processo di sviluppo per un singolo work item. Viene calcolato come differenza tra il timestamp dell'attività 'Deployed to Production' e quello di 'Work Item Created'. Questa metrica è il KPI principale per la dashboard del tempo di ciclo end-to-end e per i trend storici. Fornisce una misura olistica della velocità e dell'efficienza del processo; il monitoraggio nel tempo mostra l'impatto delle iniziative di miglioramento.
Perché è importante
KPI critico che misura la velocità ed efficienza complessiva dello sviluppo.
Dove trovare
Calcolato sottraendo il timestamp di creazione da quello di rilascio finale.
Esempi
10 giorni 4 ore 30 minuti25 giorni 8 ore 0 minuti5 giorni 2 ore 15 minuti
|
|||
|
Work Item Type
WorkItemType
|
La classificazione dell'elemento, come Bug, Feature, User Story o Task. | ||
|
Descrizione
Categorizza la natura del lavoro. Permette di confrontare se i processi sono più efficienti per i Bug rispetto alle Feature e monitorare i trend dei tempi di ciclo.
Perché è importante
Consente la segmentazione dell'analisi di processo, permettendo di confrontare workflow e prestazioni per diverse categorie di lavoro, come bug e feature.
Dove trovare
Corrisponde al campo 'Work Item Type' di un work item in Azure DevOps.
Esempi
BugFeatureUser StoryTask
|
|||
|
Gravità
Severity
|
Indica l'impatto di un bug o di un problema sul sistema o sugli utenti finali. | ||
|
Descrizione
La gravità (Severity) classifica l'impatto di un bug. È distinta dalla priorità, che detta l'ordine del lavoro. Questo attributo permette di verificare se si stanno risolvendo prima i bug più critici e aiuta a comprendere il profilo di rischio del lavoro in corso.
Perché è importante
Aiuta a categorizzare i work item in base al loro impatto sul business, consentendo di analizzare l'efficacia del team nel gestire i problemi ad alto impatto.
Dove trovare
Corrisponde al campo 'Severity' di un work item in Azure DevOps.
Esempi
1 - Critico2 - Alto3 - Medio4 - Basso
|
|||
|
ID Pull Request
PullRequestId
|
L'identificatore di una PR collegata all'elemento di sviluppo. | ||
|
Descrizione
Collega l'item a una PR specifica. Permette di analizzare i tempi di code review e la frequenza di rifiuti, indicatori della qualità del codice.
Perché è importante
Collega il lavoro di sviluppo ad attività specifiche di code review, consentendo un'analisi dettagliata dell'integrazione del codice e del processo di garanzia della qualità.
Dove trovare
Informazione presente nella sezione 'Links' o 'Development' del work item.
Esempi
452145334589
|
|||
|
Nome progetto
ProjectName
|
Il nome del progetto Azure DevOps a cui appartiene l'elemento. | ||
|
Descrizione
Identifica il progetto specifico in Azure DevOps. Permette di confrontare l'efficienza tra vari progetti e misurare l'impatto dei miglioramenti.
Perché è importante
Fornisce un raggruppamento di alto livello per l'analisi, consentendo il confronto delle prestazioni e l'analisi dei trend tra diversi progetti.
Dove trovare
Corrisponde al campo 'Team Project' di un work item in Azure DevOps.
Esempi
Piattaforma E-CommerceRilancio app mobileModernizzazione del Data Warehouse
|
|||
|
Percorso iterazione
IterationPath
|
Lo sprint di sviluppo o l'intervallo a cui è assegnato il work item. | ||
|
Descrizione
Rappresenta lo sprint. Analizzare per Iteration Path aiuta a capire le performance periodo per periodo, valutando se i tempi di ciclo migliorano nel tempo.
Perché è importante
Consente un'analisi basata sugli sprint, aiutando i team a valutare le proprie prestazioni nel tempo e a migliorare le pratiche agile.
Dove trovare
Corrisponde al campo 'Iteration Path' di un work item in Azure DevOps.
Esempi
Piattaforma E-Commerce\Sprint 12Piattaforma E-Commerce\Sprint 13Rilancio app mobile\Fase 2\Sprint 4
|
|||
|
Tempo di attesa per l'approvazione
ApprovalWaitingTime
|
Il tempo trascorso in attesa di un'approvazione dopo la richiesta. | ||
|
Descrizione
Misura quanto tempo un item resta in attesa di approvazione. Isolare questi ritardi permette ai team di migliorare la comunicazione e velocizzare il ciclo.
Perché è importante
Misura specificamente i ritardi causati dall'attesa di decisioni o approvazioni, evidenziando le opportunità per migliorare i processi di comunicazione e decision-making.
Dove trovare
Calcolato misurando la differenza di tempo tra l'inizio e la fine dell'approvazione (es. UAT).
Esempi
3 giorni 2 ore1 giorno 8 ore 30 minuti4 ore
|
|||
|
Tempo di passaggio tra fasi
StageHandoffTime
|
La durata dell'inattività tra il completamento di una fase e l'inizio della successiva. | ||
|
Descrizione
Misura il tempo di attesa tra fasi sequenziali, come tra fine sviluppo e inizio QA. Questa metrica è fondamentale per identificare bottleneck nascosti dove il lavoro ristagna per mancanza di risorse o ritardi comunicativi.
Perché è importante
Quantifica i tempi di attesa tra le fasi del processo, esponendo direttamente bottleneck e ritardi nascosti che non fanno parte del lavoro attivo.
Dove trovare
Attributo calcolato misurando la differenza di tempo tra attività sequenziali che rappresentano un handoff.
Esempi
2 ore 15 minuti1 giorno 4 ore0 ore 30 minuti
|
|||
Attività dell'SDLC
| Activity | Descrizione | ||
|---|---|---|---|
|
Distribuito in produzione
|
Segna il rilascio riuscito del codice associato al work item nell'ambiente di produzione. È un evento esplicito catturato dai log di rilascio di Azure Pipelines. | ||
|
Perché è importante
Milestone che rappresenta la consegna di valore. Serve come punto finale per il calcolo del tempo di ciclo.
Dove trovare
Acquisito dai dati della release pipeline di Azure Pipelines, specificamente dall'evento di completamento di un deployment in una fase di 'Production' collegata al work item.
Acquisisci
Acquisito da un evento di completamento del deployment della pipeline di rilascio.
Tipo di evento
explicit
|
|||
|
Pull Request completata
|
Rappresenta il completamento con successo della code review, con approvazione della PR e merge del codice. Evento registrato esplicitamente in Azure Repos. | ||
|
Perché è importante
Segna la fine della fase di code review, un comune bottleneck. Analizzare il tempo tra la creazione e il completamento della PR rivela l'efficienza del ciclo di revisione.
Dove trovare
Acquisito dall'evento di completamento o merge di una pull request in Azure Repos collegata a un work item.
Acquisisci
Acquisito dall'evento di merge della pull request collegato a un work item.
Tipo di evento
explicit
|
|||
|
Pull Request creata
|
Indica che lo sviluppatore ha completato la scrittura iniziale del codice e ha inviato le modifiche per la revisione tramite una pull request. Questo evento collega il work item a una specifica modifica del codice in Azure Repos. | ||
|
Perché è importante
Passaggio chiave tra sviluppo e code review. Aiuta a misurare quanto tempo richiede la scrittura del codice.
Dove trovare
Acquisito dai dati di Azure Repos collegando l'evento di creazione della pull request al relativo work item. Spesso si tratta di un collegamento esplicito creato dallo sviluppatore.
Acquisisci
Acquisito dall'evento di creazione della pull request di Azure Repos collegato a un work item.
Tipo di evento
explicit
|
|||
|
Sviluppo iniziato
|
Indica l'inizio del lavoro attivo sullo sviluppo. Si deduce dal cambio di stato in 'Active' o 'In Progress'. | ||
|
Perché è importante
Segna l'inizio della fase di sviluppo attivo. Analizzare il tempo da 'Creato' a 'Sviluppo avviato' rivela i tempi di coda nel backlog.
Dove trovare
Dedotto dalla cronologia del work item quando il campo System.State passa da uno stato 'New' o 'Approved' a uno stato 'In Progress'.
Acquisisci
Dedotto dal cambio del campo State in 'Active' o 'In Progress'.
Tipo di evento
inferred
|
|||
|
Test QA avviati
|
Rappresenta l'inizio della fase di QA. Questa attività viene rilevata quando lo stato del work item passa a 'In QA', 'Testing' o simili. | ||
|
Perché è importante
Segna l'inizio del ciclo QA. Analizzare la durata di questa fase è fondamentale per comprendere i bottleneck e l'efficienza dei test.
Dove trovare
Dedotto dalla cronologia del work item monitorando una modifica nel campo System.State in 'In QA' o un altro stato di test designato.
Acquisisci
Dedotto dal cambio del campo State in 'In QA' o 'Testing'.
Tipo di evento
inferred
|
|||
|
UAT approvato
|
Indica l'approvazione degli stakeholder post-UAT. Si deduce solitamente dal passaggio a 'UAT Approved'. | ||
|
Perché è importante
Punto di approvazione critico che conferma il rispetto dei requisiti e la prontezza per il rilascio.
Dove trovare
Dedotto dalla cronologia del work item rilevando una modifica nel campo System.State da uno stato UAT a uno stato approvato o pronto per il rilascio.
Acquisisci
Dedotto dal cambio del campo State da 'In UAT' a 'Ready for Release'.
Tipo di evento
inferred
|
|||
|
Work Item creato
|
Segna l'inizio del ciclo di vita. Viene catturato quando si salva un nuovo record in Azure DevOps Boards. | ||
|
Perché è importante
Evento di inizio primario, essenziale per misurare il tempo di ciclo totale.
Dove trovare
Evento catturato dalla 'Created Date' del work item.
Acquisisci
Acquisito dal campo 'Created Date' del work item.
Tipo di evento
explicit
|
|||
|
Build riuscita
|
Conferma che il codice è stato compilato e pacchettizzato con successo. Evento loggato da Azure Pipelines. | ||
|
Perché è importante
Funge da quality gate critico, assicurando che il nuovo codice si integri correttamente. I fallimenti qui indicano problemi di integrazione.
Dove trovare
Acquisito dagli eventi di completamento della build di Azure Pipelines. La build deve essere collegata al work item, direttamente o tramite la pull request associata.
Acquisisci
Acquisito dall'evento di completamento della build di Azure Pipelines.
Tipo di evento
explicit
|
|||
|
Elemento di Lavoro Approvato
|
Rappresenta l'approvazione formale di un work item, pronto per lo sviluppo. Si deduce solitamente dal campo 'State' che passa ad 'Approved' o 'Ready for Dev'. | ||
|
Perché è importante
Monitorare le approvazioni aiuta ad analizzare i ritardi tra l'idea e l'inizio dello sviluppo (planning e grooming).
Dove trovare
Dedotto dalla cronologia del work item rilevando una modifica del campo System.State in 'Approved' o uno stato personalizzato simile.
Acquisisci
Dedotto dal cambio del campo State in 'Approved'.
Tipo di evento
inferred
|
|||
|
Sviluppo completato
|
Indica che sviluppo e unit test sono completi e l'elemento è pronto per i test formali. Si deduce solitamente dallo stato 'Resolved' o 'Ready for Test'. | ||
|
Perché è importante
Segna il passaggio dal team di sviluppo al QA. Aiuta a identificare i ritardi in questa transizione.
Dove trovare
Dedotto dalla cronologia del work item quando il campo System.State assume un valore come 'Resolved' o uno stato personalizzato che indica la prontezza per il QA.
Acquisisci
Dedotto dal cambio del campo State in 'Resolved'.
Tipo di evento
inferred
|
|||
|
Test QA completati
|
Segna il completamento con successo della fase di garanzia della qualità. Si deduce quando lo stato del work item passa da una fase di test a una come 'Ready for UAT' o 'QA Approved'. | ||
|
Perché è importante
Quality gate che indica la prontezza per l'UAT. Ritardi dopo questo punto indicano problemi nella pianificazione dei rilasci.
Dove trovare
Dedotto dalla cronologia del work item quando il campo System.State passa da 'In QA' a uno stato successivo come 'Ready for UAT' o 'Done'.
Acquisisci
Dedotto dal cambio del campo State da 'In QA' a 'Ready for UAT'.
Tipo di evento
inferred
|
|||
|
Test QA falliti
|
Indica che il work item non ha superato i test di qualità e viene rimandato allo sviluppo. Questo viene acquisito da un cambiamento di stato da una fase di test a uno stato 'In Progress' o 'Active'. | ||
|
Perché è importante
Attività essenziale per identificare i cicli di rework. Un'alta frequenza indica problemi di qualità o requisiti poco chiari.
Dove trovare
Dedotto dalla cronologia del work item rilevando una transizione da uno stato come 'In QA' a uno stato come 'Active' o 'In Progress'.
Acquisisci
Dedotto dal cambio del campo State da 'In QA' di nuovo ad 'Active'.
Tipo di evento
inferred
|
|||
|
UAT avviato
|
Rappresenta l'inizio dell'UAT, dove gli stakeholder validano le funzionalità. Si deduce dal cambio di stato in 'In UAT' o simili. | ||
|
Perché è importante
Misura l'inizio della validazione finale prima del rilascio. La durata dell'UAT e i tempi di attesa per l'approvazione sono critici per l'ottimizzazione del processo.
Dove trovare
Dedotto dalla cronologia del work item quando il campo System.State viene aggiornato a uno stato personalizzato che rappresenta l'UAT, come 'In UAT'.
Acquisisci
Dedotto dal cambio del campo State in 'In UAT'.
Tipo di evento
inferred
|
|||
|
Work Item annullato
|
Indica che il work item è stato annullato e non sarà completato o distribuito. Questo viene acquisito da un cambiamento di stato in 'Removed', 'Cancelled' o simili. | ||
|
Perché è importante
Rappresenta un esito negativo del processo. Analizzare gli item annullati rivela problemi di pianificazione o requisiti.
Dove trovare
Dedotto dalla cronologia del work item quando il campo System.State viene modificato in uno stato terminale nella categoria 'Removed'.
Acquisisci
Dedotto dal cambio del campo State in 'Removed' o 'Cancelled'.
Tipo di evento
inferred
|
|||
|
Work Item chiuso
|
Rappresenta la chiusura finale del work item dopo il rilascio. Viene catturato dal cambio di stato in 'Closed' o 'Done'. | ||
|
Perché è importante
Segna il completamento finale con successo del processo. È il punto finale del ciclo di vita.
Dove trovare
Dedotto dalla cronologia del work item quando il campo System.State viene modificato in 'Closed' o uno stato terminale simile nella categoria 'Completed'.
Acquisisci
Dedotto dal cambio del campo State in 'Closed'.
Tipo di evento
inferred
|
|||