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

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

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

Questo template offre una guida completa per la raccolta e la preparazione dei Suoi dati SDLC da GitHub. Troverà gli attributi consigliati, le attività essenziali da monitorare e consigli pratici per l'estrazione dei dati. Utilizzi questa risorsa per creare un event log accurato per un'analisi e un'ottimizzazione efficaci dei processi.
  • Attributi consigliati da raccogliere
  • Attività chiave da tracciare
  • Guida all'estrazione
È 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 nel Suo event log per un'analisi completa del ciclo di vita dello sviluppo software e la process discovery.
3 Obbligatorio 5 Consigliato 16 Facoltativo
Nome Descrizione
Activity
ActivityName
Il nome di uno specifico evento o task verificatosi all'interno del ciclo di vita dello sviluppo software.
Descrizione

Il Nome dell'attività descrive un singolo passaggio nel processo di sviluppo, come 'Issue Created', 'Code Pushed to PR', 'Pull Request Approved' o 'Deployment Succeeded'. Questi eventi formano la sequenza di fasi che costituiscono il processo end-to-end per un elemento di sviluppo.

Questo attributo è fondamentale per il process mining poiché viene utilizzato per costruire la mappa di processo. Analizzare la sequenza, la frequenza e la durata di queste attività rivela il flusso reale del processo, identifica i percorsi comuni, evidenzia le deviazioni e individua i colli di bottiglia.

Perché è importante

Questo attributo costituisce la spina dorsale della mappa di processo, consentendo la visualizzazione e l'analisi della sequenza di eventi nel ciclo di vita dello sviluppo.

Dove trovare

Derivato dal campo 'action' dei payload dei webhook (es. 'opened', 'closed' per una issue) o dal tipo di evento stesso (es. 'PushEvent', 'PullRequestReviewEvent').

Esempi
Problema CreatoPull Request apertaCodice inviato alla PRRevisione richiestaPull Request unita (merged)
Elemento di sviluppo
DevelopmentItemId
L'identificatore univoco per una singola unità di lavoro di sviluppo, come una funzionalità, una correzione bug o un task. Questo funge da identificatore principale del caso.
Descrizione

L'ID dell'elemento di sviluppo traccia un elemento di lavoro dalla sua creazione al deployment finale. Collega tutte le attività associate, come creazione di branch, commit, pull request, revisioni e deployment, in un'unica istanza di processo coesa.

In fase di analisi, questo ID viene utilizzato per calcolare il tempo di ciclo end-to-end di un task di sviluppo. Consente di ricostruire l'intero percorso di una funzionalità o di una correzione bug, permettendo un'analisi dettagliata di colli di bottiglia, cicli di rilavorazione e variazioni di processo per i singoli elementi di lavoro.

Perché è importante

È la chiave essenziale per il Process Mining: collega tutti gli eventi di sviluppo correlati in un unico caso per visualizzare e analizzare accuratamente l'intero ciclo di vita dello sviluppo.

Dove trovare

Solitamente si tratta del numero della issue o del numero della pull request di GitHub. Può essere estratto dal campo 'number' nel payload degli eventi webhook o dalle risposte API relative a issue o pull request.

Esempi
101PR-2345TASK-812
Ora di Inizio
EventTimestamp
La data e l'ora esatte in cui si è verificata una specifica attività o un evento di sviluppo.
Descrizione

Questo timestamp segna l'inizio di un'attività. È fondamentale per ordinare cronologicamente gli eventi e ricostruire il flusso di processo per ogni elemento di sviluppo. La sequenza e la differenza temporale tra questi timestamp vengono utilizzate per analizzare le prestazioni del processo.

In fase di analisi, questo attributo è essenziale per calcolare tutte le metriche basate sul tempo, inclusi i tempi di ciclo, i tempi di lavorazione e i tempi di attesa. Consente di identificare i ritardi tra le fasi e fornisce i dati necessari per l'analisi dei colli di bottiglia e per le dashboard di monitoraggio delle prestazioni.

Perché è importante

Questo timestamp è fondamentale per ordinare correttamente gli eventi e calcolare tutte le metriche di performance, come i tempi di ciclo e la durata dei colli di bottiglia.

Dove trovare

Tipicamente presenti come campi 'created_at' o 'updated_at' nei payload JSON delle API e dei webhook di GitHub per vari oggetti come issue, pull request e commit.

Esempi
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Ora di Fine
EndTimestamp
La data e l'ora esatte in cui è stata completata una specifica attività o un evento di sviluppo.
Descrizione

Il timestamp di fine segna il completamento di un'attività. Mentre molti eventi in GitHub sono istantanei (es. 'Issue Created'), alcune attività hanno una durata misurabile (es. l'esecuzione di un controllo CI). La differenza tra l'Ora di fine e l'Ora di inizio fornisce il tempo di lavorazione di un'attività.

Questo attributo viene utilizzato per calcolare la metrica 'ProcessingTime', fondamentale per capire quanto impegno attivo viene dedicato a diversi task come code review o controlli automatizzati. L'analisi dei tempi di lavorazione aiuta a identificare le attività inefficienti che richiedono troppo tempo.

Perché è importante

Permette il calcolo preciso dei tempi di elaborazione delle attività, aiutando a distinguere tra il tempo di lavoro attivo e il tempo di attesa inattivo.

Dove trovare

Disponibile come 'completed_at' negli oggetti check run o derivato dal timestamp di un evento successivo conclusivo.

Esempi
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Priorità
Priority
Il livello di priorità assegnato a un elemento di sviluppo, come 'Alto', 'Medio' o 'Basso'.
Descrizione

La priorità indica l'urgenza o l'importanza aziendale di un elemento di lavoro. In GitHub, la priorità non è un campo nativo e viene tipicamente gestita tramite etichette (es. 'P1-High', 'P2-Medium'). Per estrarre queste informazioni in modo affidabile è necessario uno schema di etichettatura coerente.

Questo attributo è fondamentale per l'Analisi del flusso basata sulla priorità. Consente agli analisti di verificare se gli elementi ad alta priorità vengano effettivamente elaborati più velocemente di quelli a bassa priorità e di misurare la variazione del tempo di ciclo in base alla priorità, aiutando a valutare l'efficacia del processo di prioritizzazione.

Perché è importante

Consente di analizzare se gli elementi ad alta priorità sono elaborati più velocemente rispetto a quelli a bassa priorità, convalidando l'efficacia della strategia di prioritizzazione.

Dove trovare

Derivato dalle etichette GitHub applicate a issue o pull request. Richiede una convenzione standard per le etichette di priorità.

Esempi
ElevatoMedioBassoCritico
Repository
RepositoryName
Il nome del repository del codice in cui si sta svolgendo l'attività di sviluppo.
Descrizione

Il repository funge da identificatore di progetto o prodotto, contenendo tutto il codice, le issue e le pull request per una specifica applicazione o componente. Fornisce un modo per segmentare e confrontare i processi di sviluppo tra diversi prodotti o team.

In fase di analisi, questo attributo consente di filtrare e confrontare le prestazioni del processo tra diversi progetti. Aiuta a rispondere a domande come: 'Quale progetto ha il tempo di ciclo più lungo?' o 'Come si confronta il processo di correzione bug nel Progetto A rispetto al Progetto B?'. È essenziale per la dashboard 'Throughput per progetto e tipologia'.

Perché è importante

Consente di segmentare e confrontare i processi di sviluppo tra diversi progetti, prodotti o team, permettendo analisi più mirate.

Dove trovare

Disponibile nell'oggetto 'repository' in quasi tutti i payload di webhook e API di GitHub. Il campo specifico è solitamente 'repository.full_name' o 'repository.name'.

Esempi
my-org/web-appmy-org/api-servicemy-org/data-pipeline
Tipo elemento di sviluppo
DevelopmentItemType
La classificazione dell'elemento di lavoro di sviluppo, ad esempio funzionalità, bug, task o epic.
Descrizione

Questo attributo categorizza la natura del lavoro in corso. Queste informazioni sono solitamente gestite tramite etichette o modelli specifici di issue in GitHub. Comprendere il tipo di lavoro è fondamentale per impostare aspettative di performance adeguate, poiché un bug fix potrebbe avere un tempo di ciclo previsto molto più breve rispetto a una nuova funzionalità.

Questo attributo consente un'analisi comparativa tra diversi tipi di lavoro. Aiuta a verificare se i bug fix vengano elaborati più velocemente delle nuove funzionalità o a comprendere l'allocazione delle risorse tra debito tecnico e nuovo sviluppo. È una dimensione chiave nella dashboard 'Throughput per progetto e tipologia'.

Perché è importante

Categorizza gli elementi di lavoro, permettendo confronti di performance e analisi su come diverse tipologie di task (es. bug vs funzionalità) fluiscono nel processo.

Dove trovare

Tipicamente derivato dalle etichette GitHub applicate a issue o pull request. Richiede una convenzione di etichettatura coerente (es. 'type:bug', 'type:feature').

Esempi
BugFunzionalitàTaskDebito tecnico
Utente Assegnato
Assignee
L'utente o lo sviluppatore assegnato alla gestione dell'elemento di sviluppo o di un task specifico, come la revisione di una pull request.
Descrizione

Questo attributo identifica la persona responsabile del lavoro in una determinata fase. Può essere l'assegnatario di una issue, l'autore di una pull request o il revisore incaricato per una code review. Tracciare l'assegnatario è fondamentale per comprendere l'allocazione delle risorse e il carico di lavoro.

Questo attributo viene utilizzato nell'analisi per monitorare il carico di lavoro degli sviluppatori, identificare colli di bottiglia nelle risorse e analizzare l'efficienza dei passaggi di consegna tra i diversi membri del team. Le dashboard possono essere filtrate per assegnatario per valutare le prestazioni individuali o del team e garantire una distribuzione equilibrata del lavoro.

Perché è importante

Fondamentale per analizzare il carico di lavoro degli sviluppatori, le performance dei team e l'efficienza dei passaggi di consegne (handoff) tra i membri del team.

Dove trovare

Disponibile nell'oggetto 'assignee' o 'user' all'interno dei payload JSON per issue, pull request ed eventi di revisione delle API GitHub.

Esempi
john.doejane.smithdev-team-lead
Ambiente di deployment
DeploymentEnvironment
L'ambiente di destinazione per un deployment, come 'Staging' o 'Produzione'.
Descrizione

Questo attributo specifica dove viene distribuito il codice. Tracciare i deployment in diversi ambienti è fondamentale per comprendere l'intero ciclo di vita, dallo sviluppo al rilascio in produzione.

Questo attributo consente di analizzare il sottoprocesso di deployment. Può essere utilizzato per misurare il tempo necessario per promuovere il codice da staging a produzione e per monitorare il tasso di successo dei deployment nei diversi ambienti. È essenziale per sapere quando un elemento di sviluppo è veramente 'concluso' e consegnato agli utenti.

Perché è importante

Distingue tra rilasci in pre-produzione e in produzione, dato essenziale per misurare il reale 'time-to-market' e analizzare i pattern di deployment.

Dove trovare

Queste informazioni vengono recuperate dalle API GitHub Deployments, spesso attivate dalle pipeline CI/CD o da altre automazioni.

Esempi
developmentstagingproduction
Autore
Author
L'utente che ha creato la issue, la pull request o il commit.
Descrizione

L'autore è colui che ha dato origine a un artefatto specifico nel processo di sviluppo. Ad esempio, l'autore di una issue è la persona che ha segnalato il bug o richiesto la funzionalità; l'autore di una pull request è lo sviluppatore che ha scritto il codice.

Nell'analisi, l'autore può essere utilizzato per comprendere le origini del lavoro. Ad esempio, analizzare gli autori dei bug report potrebbe rivelare schemi relativi a specifici team o funzionalità. Può anche essere usato insieme all'assegnatario per analizzare i modelli dei passaggi di consegna.

Perché è importante

Identifica l'autore di un elemento di lavoro o di una modifica al codice, utile per analizzare le fonti di rifacimenti, bug report o richieste di funzionalità.

Dove trovare

Disponibile nell'oggetto 'user' all'interno dell'oggetto principale delle risposte API per issue, pull request e commit. Il campo è solitamente 'user.login'.

Esempi
sara.jonesmike.leeautomation-bot
È una Rilavorazione
IsRework
Un flag booleano impostato su true se l'attività rappresenta un ritorno (regressione) a una fase precedente del processo.
Descrizione

Questo flag è impostato su true quando un elemento di sviluppo torna indietro nel processo, ad esempio quando una pull request riceve una revisione con 'Changes Requested' o quando una issue viene riaperta dopo essere stata chiusa. Viene derivato analizzando la sequenza delle attività.

Questo attributo è essenziale per quantificare sprechi e inefficienze. Supporta direttamente la dashboard 'Cicli di rilavorazione e regressioni' e il KPI 'Tasso di rilavorazione'. Filtrando per 'IsRework = true', gli analisti possono isolare e indagare le cause delle rilavorazioni.

Perché è importante

Contrassegna esplicitamente le attività che costituiscono un rifacimento (rework), rendendo facile quantificare, visualizzare e analizzare le cause delle inefficienze di processo.

Dove trovare

Questo è un attributo derivato. La logica prevede la definizione di un flusso di processo standard e la successiva segnalazione di qualsiasi attività che devii tornando a una fase logica precedente.

Esempi
truefalse
Etichette (Labels)
Labels
Un elenco di tag o etichette applicate a una issue o pull request per la categorizzazione.
Descrizione

Le etichette in GitHub sono un modo flessibile per aggiungere metadati a issue e pull request. Possono indicare priorità, tipo di lavoro, componenti o team. L'elenco grezzo delle etichette fornisce un contesto ricco e non strutturato.

Sebbene attributi come Priorità e Tipo derivino dalle etichette, conservare l'elenco completo è utile per analisi ad-hoc. Consente di filtrare e segmentare i casi in modo flessibile in base a qualsiasi combinazione di etichette.

Perché è importante

Costituisce una fonte di metadati flessibile e ricca per categorizzare gli elementi di lavoro, consentendo analisi dimensionali approfondite e variegate.

Dove trovare

Disponibile come array 'labels' nel payload JSON per le issue e le pull request delle API GitHub. Ogni elemento dell'array è un oggetto con un campo 'name'.

Esempi
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
Hash del commit
CommitHash
L'identificatore univoco (SHA) per uno specifico commit del codice.
Descrizione

Un hash di commit è un codice SHA-1 di 40 caratteri che identifica univocamente un commit in Git. Funge da ID permanente per una specifica versione del codice. I commit sono le unità atomiche di modifica nel processo di sviluppo.

Sebbene estremamente granulare, l'hash del commit offre il massimo livello di tracciabilità. Consente agli analisti di collegare un evento del processo direttamente alla modifica esatta apportata al codice. Questo è fondamentale per attività di audit, conformità o analisi dettagliata delle cause radice in caso di incidenti in produzione.

Perché è importante

Fornisce il collegamento più granulare tra una fase del processo e la modifica esatta del codice, consentendo una tracciabilità completa per audit e debugging.

Dove trovare

Disponibile nei payload degli eventi push ('head_commit.id') o tramite le API Commits per una pull request o un branch.

Esempi
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Nome del branch
BranchName
Il nome del branch Git in cui sono state apportate le modifiche al codice per l'elemento di sviluppo.
Descrizione

Un branch è una linea di sviluppo indipendente, creata per lavorare su una nuova funzionalità o sulla risoluzione di un bug senza influenzare la codebase principale. Spesso il nome del branch contiene informazioni utili, come il numero della issue o una breve descrizione del lavoro.

L'analisi dei nomi dei branch aiuta a comprendere le strategie di branching e l'adesione alle convenzioni di sviluppo. Inoltre, facilita il collegamento di specifici commit a un elemento di sviluppo, offrendo una visione completa dell'attività di programmazione.

Perché è importante

Fornisce il contesto sulla specifica linea di sviluppo e aiuta ad applicare e analizzare le strategie di branching e le convenzioni di denominazione.

Dove trovare

Disponibile nel campo 'ref' per gli eventi push, o negli oggetti 'head' e 'base' all'interno di una risposta API delle pull request.

Esempi
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
Numero della Pull Request
PullRequestNumber
L'identificatore univoco per una pull request associata all'elemento di sviluppo.
Descrizione

Una pull request (PR) è una proposta per unire un set di modifiche al codice in un branch specifico. Il numero della pull request collega le attività di sviluppo (come push e revisioni) all'elemento di sviluppo primario o alla issue.

Questo ID è fondamentale per tracciare il sottoprocesso di integrazione e revisione del codice all'interno del ciclo di vita dello sviluppo. Consente un'analisi dettagliata del processo di review, inclusi i tempi di revisione, i cicli di rifacimento e i tassi di merge. Collega la fase di pianificazione (issue) alla fase di implementazione (PR).

Perché è importante

Collega le issue alle modifiche del codice e ai processi di revisione, permettendo un'analisi dettagliata del ciclo di review e del suo impatto sui tempi di consegna totali.

Dove trovare

Disponibile nel campo 'number' all'interno dell'oggetto 'pull_request' in molte risposte API di GitHub, o come identificatore principale delle API Pull Requests.

Esempi
12345678910
Revisore
Reviewer
L'utente a cui è stato chiesto di eseguire una code review su una pull request.
Descrizione

Un revisore (reviewer) è un membro del team incaricato di ispezionare le modifiche al codice in una pull request. Una pull request può avere più revisori.

Questo attributo è essenziale per analizzare il processo di revisione del codice. Aiuta a identificare colli di bottiglia legati a specifici revisori, a comprendere la distribuzione del carico di lavoro e a misurare i tempi di risposta. È un elemento chiave per calcolare il KPI 'Tempo medio del ciclo di revisione del codice'.

Perché è importante

Identifica le persone coinvolte nel processo di QA, permettendo l'analisi dei carichi di lavoro di revisione, dei ritardi e dell'efficienza complessiva delle code review.

Dove trovare

Disponibile nell'array 'requested_reviewers' o nell'oggetto 'user' di un evento di revisione pull request delle API GitHub.

Esempi
alex.chenmaria.garciasenior-dev-team
Sistema di Origine
SourceSystem
Il sistema da cui sono stati estratti i dati del processo di sviluppo.
Descrizione

Questo attributo identifica l'origine dei dati dell'evento. Per questo processo, il valore sarà costantemente 'GitHub'. In un ambiente più complesso dove le attività di sviluppo coprono più sistemi (es. Jira per la pianificazione, GitHub per il codice, Jenkins per il deployment), questo campo serve a distinguere la fonte di ogni evento.

In fase di analisi, aiuta a risalire all'origine dei dati per validazione e risoluzione dei problemi. Consente inoltre di analizzare processi che attraversano diverse piattaforme, fornendo un contesto chiaro per ogni attività.

Perché è importante

Identifica l'origine dei dati, essenziale per la validazione e per l'analisi di processi che possono coinvolgere più sistemi integrati.

Dove trovare

Solitamente si tratta di un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL) per etichettare l'origine dei record.

Esempi
GitHubGitHub Enterprise
Stato controllo CI
CiCheckStatus
Lo stato di un controllo automatizzato di Continuous Integration (CI), come 'passato' o 'fallito'.
Descrizione

Questo attributo riflette l'esito di build, test e scansioni automatizzate eseguite sulle modifiche al codice in una pull request. I controlli CI sono un passaggio di qualità critico nei moderni workflow di sviluppo.

Analizzare questo attributo aiuta a capire l'efficacia dei test automatizzati. Un alto tasso di fallimento potrebbe indicare problemi con la stabilità del codice, la suite di test o l'ambiente di sviluppo. Supporta le attività 'CI Checks Passed' e 'CI Checks Failed' e aiuta ad analizzare i ritardi causati da build interrotte.

Perché è importante

Indica il successo o il fallimento dei quality gate automatizzati, offrendo insight sulla qualità del codice e sull'efficacia della pipeline di CI.

Dove trovare

Ottenuto dal campo 'state' o 'conclusion' degli oggetti di controllo o di stato tramite le API GitHub Checks o Statuses.

Esempi
successfailurein sospesoerror
Stato di Revisione
ReviewState
L'esito di una code review su una pull request, ad esempio 'Approved' o 'Changes Requested'.
Descrizione

Questo attributo acquisisce la decisione presa da un revisore. Gli stati comuni includono 'APPROVED', che indica che il codice è pronto per il merge, e 'CHANGES_REQUESTED', che indica la necessità di rilavorazione. Altri stati possono includere 'COMMENTED' o 'PENDING'.

Si tratta di un attributo critico per analizzare la qualità e le rilavorazioni. Un'alta frequenza di eventi 'CHANGES_REQUESTED' può indicare problemi con la qualità iniziale del codice o requisiti poco chiari. Supporta direttamente la dashboard 'Cicli di rilavorazione e regressioni' identificando quando un elemento di sviluppo viene rimandato indietro per modifiche.

Perché è importante

Indica direttamente i cicli di rifacimento e i quality gate nel processo di revisione del codice, aiutando a individuare le fonti di inefficienza e i problemi di qualità.

Dove trovare

Disponibile nel campo 'state' all'interno di un oggetto pull request review delle API GitHub. Ad esempio, in un payload 'PullRequestReviewEvent'.

Esempi
APPROVEDCHANGES_REQUESTEDCOMMENTED
Stato elemento
State
Lo stato attuale di una issue o di una pull request, ad esempio 'open', 'closed' o 'merged'.
Descrizione

Questo attributo indica lo stato di alto livello di un elemento di sviluppo. Per le issue, gli stati tipici sono 'open' e 'closed'. Per le pull request, gli stati includono 'open', 'closed' e 'merged'. Ciò fornisce un'istantanea dell'avanzamento dell'elemento.

Nell'analisi, lo stato viene utilizzato per distinguere il lavoro attivo da quello completato. È essenziale per dashboard come 'Avanzamento sviluppo attivo' che monitorano il lavoro in corso. Viene anche usato per definire la fine di un processo; ad esempio, lo stato 'merged' o 'closed' potrebbe indicare il completamento di un caso.

Perché è importante

Fornisce un'indicazione chiara se un elemento di lavoro è in corso o completato, dato fondamentale per l'analisi del ciclo di vita e il monitoraggio del lavoro attivo.

Dove trovare

Disponibile direttamente nel campo 'state' dei payload JSON per le issue e le pull request delle API GitHub.

Esempi
apertoclosedmerged
Tempo del ciclo di sviluppo
DevelopmentCycleTime
Il tempo totale trascorso dalla creazione di un elemento di sviluppo al suo deployment finale o alla sua chiusura.
Descrizione

Questa è una metrica a livello di caso calcolata come la differenza temporale tra il primo evento in assoluto (es. 'Issue Created') e l'evento finale (es. 'Deployment Succeeded' o 'Issue Closed') per un singolo elemento di sviluppo.

Si tratta di uno dei KPI più importanti per misurare l'efficienza complessiva del processo di sviluppo. Supporta direttamente la dashboard 'Tempo di ciclo di sviluppo complessivo' e il KPI 'Tempo medio del ciclo di sviluppo'. Ridurre questa metrica è spesso l'obiettivo primario delle iniziative di miglioramento dei processi.

Perché è importante

Rappresenta il 'time-to-market' end-to-end per un elemento di sviluppo, rendendolo un KPI critico per misurare la velocità e l'efficienza complessiva del processo.

Dove trovare

Calcolato a livello di caso sottraendo il timestamp della prima attività da quello dell'ultima.

Esempi
P5DT6H30MP14DT12HP1DT2H
Tempo di attesa nel passaggio di consegne
HandoffWaitingTime
Il tempo di inattività calcolato che un elemento di sviluppo trascorre in attesa tra le attività eseguite da persone diverse.
Descrizione

Questa metrica misura il tempo tra il completamento di un'attività e l'inizio della successiva, ma solo quando la persona responsabile cambia. Ad esempio, il tempo tra un evento 'Review Requested' e un evento 'Changes Requested in Review' effettuato da un utente diverso.

È una metrica fondamentale per identificare lacune comunicative e problemi di coordinamento. Supporta la dashboard 'Efficienza dei passaggi di consegna critici' e il KPI 'Tempo medio di attesa al passaggio di consegna'. Lunghi tempi di attesa nei punti di passaggio sono spesso segno di carenza di risorse o processi di notifica inefficienti.

Perché è importante

Identifica i ritardi causati da scarsa coordinazione o indisponibilità di risorse durante i passaggi di consegna tra team o ruoli diversi, che spesso rappresentano le principali fonti di inefficienza.

Dove trovare

Calcolato identificando attività sequenziali in cui l'attributo 'Assignee' o 'User' cambia, misurando poi l'intervallo di tempo tra di esse.

Esempi
PT1H15MP2DT4HPT25M
Tempo di Elaborazione
ProcessingTime
La durata calcolata di un'attività, che rappresenta il tempo di lavoro attivo.
Descrizione

Il tempo di lavorazione (Processing Time) è il tempo trascorso tra l'inizio e la fine di un'attività. Si calcola sottraendo 'EventTimestamp' da 'EndTimestamp'. Questa metrica misura quanto tempo occorre per completare un task, escludendo il tempo trascorso in attesa del suo inizio.

Analizzare il tempo di lavorazione aiuta a individuare quali attività richiedono più impegno attivo. Si differenzia dal tempo di ciclo (cycle time), che include i tempi di attesa. Ad esempio, una code review potrebbe avere un tempo di ciclo lungo ma un tempo di lavorazione breve, indicando che il revisore è occupato e la PR è ferma in coda.

Perché è importante

Misura la durata del lavoro attivo, aiutando a distinguere tra il tempo speso lavorando effettivamente su un task e il tempo di attesa; un dato fondamentale per migliorare l'efficienza in modo mirato.

Dove trovare

Calcolato sottraendo 'EventTimestamp' da 'EndTimestamp' per un singolo record di attività.

Esempi
PT5M15SPT2H30MP1DT12H
Ultimo `Data Update`
LastDataUpdate
Il timestamp che indica l'ultimo aggiornamento dei dati per questo record dal sistema sorgente.
Descrizione

Questo attributo registra la data e l'ora dell'estrazione o dell'aggiornamento dei dati più recenti. Fornisce metadati sulla freschezza dei dati analizzati. Si distingue dall'event timestamp, che registra quando è avvenuto l'evento aziendale.

Nell'analisi, questo campo è fondamentale per comprendere quanto sia aggiornata la vista del processo. Aiuta gli utenti a capire se stanno guardando dati in tempo reale o un'istantanea di un momento specifico, aspetto importante per le dashboard operative e il monitoraggio.

Perché è importante

Indica l'attualità dei dati, il che è fondamentale per garantire che le analisi e le dashboard siano basate su informazioni aggiornate.

Dove trovare

Questo timestamp viene generato e aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL).

Esempi
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Obbligatorio Consigliato Facoltativo

Attività del ciclo di vita dello sviluppo software

Queste sono le fasi chiave del processo e le milestone da registrare nel tuo event log per un'accurata scoperta dei processi e l'identificazione dei colli di bottiglia.
6 Consigliato 7 Facoltativo
Activity Descrizione
Controlli CI superati
Rappresenta il completamento con successo di controlli automatizzati, come build, unit test o analisi statica, eseguiti sul codice in una pull request. Questo evento viene dedotto dallo stato dei controlli segnalati da sistemi come GitHub Actions.
Perché è importante

Questo controllo qualità automatizzato è fondamentale per garantire la stabilità del codice. I fallimenti o i lunghi tempi di esecuzione possono rappresentare colli di bottiglia significativi nella pipeline di rilascio.

Dove trovare

Dedotto dalle API GitHub Checks o Statuses. Un controllo riporta 'success' o si completa con esito 'success'.

Acquisisci

Monitora le Checks API per individuare un esito di 'success' nelle relative suite di controllo.

Tipo di evento inferred
Problema chiuso
L'elemento di sviluppo è considerato completo e la issue corrispondente viene formalmente chiusa. Ciò può avvenire automaticamente quando una pull request collegata viene unita, oppure può essere eseguito manualmente da un membro del team.
Perché è importante

Questa attività funge da conclusione definitiva del processo per un elemento di sviluppo ed è fondamentale per calcolare i tempi di ciclo end-to-end.

Dove trovare

Questo è un evento esplicito acquisito dal flusso di eventi delle API GitHub Issues. Il tipo di evento è 'closed'.

Acquisisci

Monitora l'evento 'closed' su una issue tramite webhook o polling delle API.

Tipo di evento explicit
Problema Creato
Segna l'inizio del ciclo di vita di un elemento di sviluppo, rappresentando la creazione formale di un task, di un bug o di una richiesta di funzionalità. Questo evento viene acquisito esplicitamente quando un utente crea una nuova issue in un repository GitHub.
Perché è importante

Questa è l'attività di avvio principale del processo, essenziale per misurare il tempo di ciclo di sviluppo totale e comprendere le fonti iniziali di lavoro.

Dove trovare

Questo è un evento esplicito acquisito dal flusso di eventi delle API GitHub Issues. Il tipo di evento è solitamente 'opened' per un determinato numero di issue.

Acquisisci

Monitora l'evento 'opened' su una issue tramite webhook o polling delle API.

Tipo di evento explicit
Pull Request aperta
Indica che un blocco iniziale di codice è pronto per la revisione e l'integrazione. Uno sviluppatore crea una pull request (PR) per proporre modifiche dal proprio feature branch a un branch principale. Questo è un evento esplicito in GitHub.
Perché è importante

Si tratta di un traguardo critico che segna la fine della fase di sviluppo iniziale e l'inizio della pipeline di revisione e integrazione. È fondamentale per analizzare separatamente i tempi del ciclo di sviluppo e quelli di revisione.

Dove trovare

Acquisito dal flusso di eventi delle API Pull Request o dai webhook. L'azione dell'evento è 'opened'.

Acquisisci

Monitora l'azione 'opened' per una pull request tramite webhook o polling delle API.

Tipo di evento explicit
Pull Request approvata
Un revisore ha approvato formalmente le modifiche di una pull request, indicando che soddisfa gli standard qualitativi e funzionali. L'evento viene registrato quando la revisione è inviata con stato 'approve'.
Perché è importante

Questo è un controllo di qualità fondamentale e un traguardo importante prima del merge. Il tempo impiegato per raggiungere questo stato dalla creazione della PR è un KPI critico per l'efficienza del processo di revisione.

Dove trovare

Acquisito dalle API Pull Request o dai webhook quando una revisione viene inviata con stato 'APPROVED'.

Acquisisci

Filtra gli eventi di invio revisione pull request per lo stato 'APPROVED'.

Tipo di evento explicit
Pull Request unita (merged)
Le modifiche al codice approvate dalla pull request vengono integrate ufficialmente nel branch di destinazione, come main o develop. Si tratta di un'azione finale esplicita su una pull request che incorpora il nuovo codice.
Perché è importante

Si tratta di una pietra miliare fondamentale che rappresenta il completamento dello sviluppo e della revisione. Per molti team, questo è l'ultimo passaggio prima del deployment automatizzato.

Dove trovare

Acquisito dal flusso di eventi delle API Pull Request o dai webhook. L'azione dell'evento è 'closed' e l'attributo 'merged' del payload è true.

Acquisisci

Monitora l'azione 'closed' su una pull request e verifica se il flag 'merged' è impostato su true.

Tipo di evento explicit
Branch creato
Rappresenta l'inizio del lavoro di sviluppo attivo per una issue, in cui uno sviluppatore crea un nuovo branch dal codice principale. È un evento esplicito acquisito quando un nuovo branch viene pushato nel repository, spesso contenente il numero della issue nel nome.
Perché è importante

Indica il passaggio dalla pianificazione alla programmazione attiva. Misurare il tempo tra la creazione della issue e questo evento aiuta ad analizzare i tempi di presa in carico e i ritardi nel backlog.

Dove trovare

Acquisito tramite le API Git di GitHub o webhook in ascolto per eventi 'create' di tipo 'branch'. Spesso è necessario collegare il nome del branch a una issue tramite convenzioni di nomenclatura, come 'feature/issue-123'.

Acquisisci

Analizza gli eventi webhook 'create' per i nuovi branch e associali a una issue.

Tipo di evento explicit
Codice inviato alla PR
Rappresenta un aggiornamento del codice inviato per la revisione, sia come parte della PR iniziale, sia in risposta ai feedback della revisione. Questo evento viene acquisito ogni volta che viene effettuato il push di un nuovo commit nel branch associato a una pull request aperta.
Perché è importante

Tracciare questi eventi è fondamentale per identificare i cicli di rilavorazione. Più push dopo una revisione indicano che sono state richieste modifiche, influenzando il tempo di ciclo complessivo.

Dove trovare

Questo è un evento esplicito nella timeline della pull request, spesso etichettato come l'aggiunta di un commit. Può essere acquisito dal webhook 'push' o monitorando i commit associati a una PR.

Acquisisci

Monitora gli eventi 'push' su un branch associato a una pull request aperta.

Tipo di evento explicit
Controlli CI falliti
Rappresenta il fallimento di un controllo automatizzato, come un errore di build o un unit test fallito, eseguito sul codice di una pull request. Viene dedotto da uno stato di errore segnalato da un sistema come GitHub Actions.
Perché è importante

Questa attività evidenzia problemi di qualità tecnica che richiedono l'intervento dello sviluppatore, creando un ciclo di rilavorazione. Analizzare la frequenza dei fallimenti può guidare i miglioramenti nei test locali o nella qualità del codice.

Dove trovare

Dedotto dalle API GitHub Checks o Statuses. Un controllo riporta 'failure' o si completa con esito 'failure'.

Acquisisci

Monitora le Checks API per individuare un esito di 'failure' nelle relative suite di controllo.

Tipo di evento inferred
Deployment riuscito
Le modifiche al codice sono state distribuite con successo in un ambiente specifico, come staging o produzione. Questo evento viene solitamente acquisito tramite le API GitHub Deployments, spesso attivato da una GitHub Action dopo un merge.
Perché è importante

Segna il passaggio del codice dal repository all'ambiente di produzione. Monitorare questo passaggio è essenziale per misurare l'intero lead time, dall'idea alla messa in produzione.

Dove trovare

Acquisito tramite le API Deployments. Un servizio esterno o una GitHub Action crea un deployment e ne aggiorna lo stato in 'success'.

Acquisisci

Monitora gli eventi di stato del deployment tramite webhook per individuare lo stato di 'success'.

Tipo di evento inferred
Issue riaperta
Una issue precedentemente chiusa viene riaperta, solitamente perché la soluzione era insufficiente o è stata trovata una regressione. È un evento esplicito che riavvia il ciclo di vita dell'attività.
Perché è importante

Questo segnale indica un importante ciclo di rilavorazione, suggerendo un potenziale difetto sfuggito in produzione o una correzione incompleta. Tracciarne la frequenza è una misura chiave della qualità complessiva del software.

Dove trovare

Questo è un evento esplicito acquisito dal flusso di eventi delle API GitHub Issues. Il tipo di evento è 'reopened'.

Acquisisci

Monitora l'evento 'reopened' su una issue tramite webhook o polling delle API.

Tipo di evento explicit
Revisione richiesta
L'autore di una pull request chiede formalmente a specifici membri o team di revisionare il proprio codice. Questa è un'azione esplicita all'interno dell'interfaccia o delle API di GitHub che attiva le notifiche ai revisori incaricati.
Perché è importante

Questa attività segna l'inizio ufficiale del passaggio di consegna al processo di code review. Il tempo intercorso tra questo evento e l'invio della revisione aiuta a misurare la reattività del revisore e i potenziali colli di bottiglia.

Dove trovare

Acquisito dal flusso di eventi delle API Pull Request o dai webhook. L'azione dell'evento è 'review_requested'.

Acquisisci

Monitora l'azione 'review_requested' per una pull request.

Tipo di evento explicit
Richieste modifiche in fase di revisione
Un revisore ha completato l'analisi del codice e stabilito che sono necessarie modifiche prima dell'approvazione della pull request. Il revisore invia formalmente la revisione con lo stato 'request_changes'.
Perché è importante

Questo evento segnala esplicitamente un ciclo di rilavorazione. Analizzarne la frequenza aiuta a individuare problemi di qualità, requisiti poco chiari o aree in cui è necessaria formazione per gli sviluppatori.

Dove trovare

Acquisito dalle API Pull Request o dai webhook quando una revisione viene inviata con stato 'CHANGES_REQUESTED'.

Acquisisci

Filtra gli eventi di invio revisione pull request per lo stato 'CHANGES_REQUESTED'.

Tipo di evento explicit
Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i dati da GitHub