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

GitHub
Il Template dei dati per il ciclo di vita dello sviluppo software

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

Questo template offre indicazioni complete per raccogliere e preparare i dati del ciclo di vita dello sviluppo software da GitHub. Include gli attributi consigliati, le attività essenziali da monitorare e indicazioni pratiche per estrarre i dati. Utilizzi questa risorsa per creare un Event Log accurato e analizzare e ottimizzare i processi in modo efficace.
  • Attributi consigliati da raccogliere
  • Attività principali da monitorare
  • Indicazioni per l’estrazione
Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Attributi del ciclo di vita dello sviluppo software

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo il ciclo di vita dello sviluppo software e individuare i processi.
3 Obbligatorio 5 Consigliato 15 Facoltativo
Nome Descrizione
Attività
ActivityName
Nome di un evento o di un’attività specifica che si è verificata nel ciclo di vita dello sviluppo software.
Descrizione

Il nome dell’attività descrive un singolo passaggio del processo di sviluppo, ad esempio 'Issue creata', 'Codice inviato alla PR', 'Pull request approvata' o 'Distribuzione riuscita'. Questi eventi formano la sequenza di passaggi che costituisce il processo completo relativo a un elemento di sviluppo.

Questo attributo è fondamentale per il Process Mining, perché viene utilizzato per costruire la mappa del processo. Analizzando la sequenza, la frequenza e la durata delle attività è possibile ricostruire il flusso effettivo, individuare i percorsi più comuni e gli scostamenti e identificare i colli di bottiglia.

Perché è importante

Questo attributo è alla base della mappa del processo e consente di visualizzare e analizzare la sequenza degli eventi nel ciclo di vita dello sviluppo.

Dove reperirli

Deriva dal campo 'action' del contenuto degli eventi webhook, ad esempio 'opened' o 'closed' per un’issue, oppure dal tipo di evento stesso, ad esempio 'PushEvent' o 'PullRequestReviewEvent'.

Esempi
Issue creataPull request apertaCodice inviato alla PRRevisione richiestaPull request unita
Elemento di sviluppo
DevelopmentItemId
Identificativo univoco di una singola unità di lavoro di sviluppo, ad esempio una funzionalità, la correzione di un bug o un’attività. Funge da identificativo principale del caso.
Descrizione

L’ID dell’elemento di sviluppo segue un’attività dalla creazione fino alla distribuzione finale. Collega in un’unica istanza di processo tutte le attività associate, come la creazione di branch, i commit, le pull request, le revisioni e le distribuzioni.

Nell’analisi, questo ID viene utilizzato per calcolare il tempo di ciclo complessivo di un’attività di sviluppo. Consente di ricostruire l’intero percorso di una funzionalità o della correzione di un bug e di analizzare nel dettaglio i colli di bottiglia, i cicli di rilavorazione e le variazioni del processo per ogni singolo elemento di lavoro.

Perché è importante

È la chiave essenziale per il Process Mining: collega tutti gli eventi di sviluppo correlati in un unico caso, così da visualizzare e analizzare con precisione l’intero ciclo di vita dello sviluppo software.

Dove reperirli

In genere corrisponde al numero dell’issue o della pull request in GitHub. Può essere estratto dal campo 'number' nel contenuto degli eventi webhook o nelle risposte API relativi a issue o pull request.

Esempi
101PR-2345TASK-812
Ora di inizio
EventTimestamp
Data e 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 del processo per ogni elemento di sviluppo. La sequenza e gli intervalli tra questi timestamp vengono utilizzati per analizzare le prestazioni del processo.

Nell’analisi, questo attributo è essenziale per calcolare tutte le metriche temporali, inclusi i tempi di ciclo, i tempi di elaborazione e i tempi di attesa. Consente di individuare i ritardi tra i passaggi e fornisce i dati necessari per l’analisi dei colli di bottiglia e il monitoraggio delle prestazioni tramite le Dashboard.

Perché è importante

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

Dove reperirli

Si trova in genere nei campi 'created_at' o 'updated_at' dei contenuti JSON restituiti dalle API e dai webhook di GitHub per oggetti quali issue, pull request e commit.

Esempi
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Ora di fine
EndTimestamp
Data e 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à. Molti eventi in GitHub sono istantanei, ad esempio 'Issue creata', mentre alcune attività hanno una durata misurabile, come l’esecuzione di un controllo CI. La differenza tra l’ora di fine e l’ora di inizio corrisponde al tempo di elaborazione dell’attività.

Questo attributo viene utilizzato per calcolare la metrica 'ProcessingTime', essenziale per capire quanto lavoro effettivo viene dedicato ad attività diverse, come le revisioni del codice o i controlli automatizzati. Analizzare i tempi di elaborazione aiuta a individuare le attività inefficienti che richiedono troppo tempo.

Perché è importante

Consente di calcolare con precisione i tempi di elaborazione delle attività e di distinguere il tempo di lavoro effettivo dai tempi di attesa.

Dove reperirli

Può essere presente come 'completed_at' negli oggetti relativi alle esecuzioni dei controlli oppure essere ricavato dal timestamp di un evento successivo che conclude logicamente l’attività.

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, ad esempio «Alta», «Media» o «Bassa».
Descrizione

La priorità indica l’urgenza o l’importanza aziendale di un elemento di lavoro. In GitHub non è un campo nativo e viene in genere gestita tramite etichette, ad esempio «P1-High» e «P2-Medium». Per estrarre queste informazioni in modo affidabile è necessario adottare uno schema di etichettatura coerente.

Questo attributo è essenziale per l’analisi del flusso basata sulla priorità. Consente agli analisti di verificare se gli elementi ad alta priorità vengono effettivamente elaborati più rapidamente di quelli a bassa priorità e di misurare le variazioni del tempo di ciclo in base alla priorità. Aiuta inoltre a valutare l’efficacia del processo di definizione delle priorità.

Perché è importante

Consente di verificare se gli elementi ad alta priorità vengono elaborati più rapidamente di quelli a priorità inferiore e di valutare l’efficacia della strategia di definizione delle priorità.

Dove reperirli

Deriva dalle etichette GitHub applicate a issue o pull request. È necessario adottare una convenzione standardizzata per le etichette di priorità.

Esempi
AltaMediaBassaCritico
Repository
RepositoryName
Nome del repository di codice in cui si svolge l’attività di sviluppo.
Descrizione

Il repository funge da identificativo del progetto o del prodotto e contiene tutto il codice, le issue e le pull request relativi a una specifica applicazione o componente. Consente di suddividere e confrontare i processi di sviluppo tra prodotti o team diversi.

Nell’analisi, questo attributo permette di filtrare e confrontare le prestazioni dei processi tra progetti diversi. Aiuta a rispondere a domande come: «Quale progetto ha il tempo di ciclo più lungo?» oppure «Come si confronta il processo di correzione dei bug del Progetto A con quello del Progetto B?». È essenziale per la Dashboard 'Throughput by Project and Type'.

Perché è importante

Consente di suddividere e confrontare i processi di sviluppo tra progetti, prodotti o team diversi, rendendo possibile un’analisi più mirata.

Dove reperirli

È disponibile nell’oggetto 'repository' in quasi tutti i contenuti di webhook e API di GitHub. Il campo specifico è in genere 'repository.full_name' o 'repository.name'.

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

Questo attributo classifica la natura del lavoro svolto. In genere, queste informazioni vengono gestite tramite etichette o template specifici per le issue in GitHub. Conoscere il tipo di lavoro è fondamentale per definire aspettative adeguate sulle prestazioni: il tempo di ciclo previsto per la correzione di un bug, ad esempio, può essere molto più breve di quello di una nuova funzionalità.

Questo attributo consente di confrontare diversi tipi di lavoro. Aiuta a capire se i bug vengono corretti più rapidamente delle nuove funzionalità e come vengono allocate le risorse tra il debito tecnico e il nuovo sviluppo. È una dimensione chiave della Dashboard 'Throughput by Project and Type'.

Perché è importante

Classifica gli elementi di lavoro e consente di confrontare le prestazioni e analizzare come i diversi tipi di attività, ad esempio bug e funzionalità, attraversano il processo.

Dove reperirli

In genere deriva dalle etichette applicate alle issue o alle pull request in GitHub. Richiede una convenzione di etichettatura coerente, ad esempio 'type:bug' e 'type:feature'.

Esempi
BugFunzionalitàAttivitàDebito tecnico
Utente assegnato
Assignee
Utente o sviluppatore incaricato di gestire l’elemento di sviluppo o un’attività specifica, come la revisione di una pull request.
Descrizione

Questo attributo identifica la persona responsabile del lavoro in una determinata fase. Può trattarsi dell’assegnatario di un’issue, dell’autore di una pull request o del revisore richiesto per una revisione del codice. Tenere traccia dell’assegnatario è fondamentale per comprendere l’allocazione delle risorse e il carico di lavoro.

Nell’analisi, questo attributo viene utilizzato per monitorare il carico di lavoro degli sviluppatori, individuare colli di bottiglia legati alle risorse e valutare l’efficienza dei passaggi di consegne tra i membri del team. Le Dashboard possono essere filtrate per assegnatario, così da 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 prestazioni del team e l’efficienza dei passaggi di consegne tra i membri.

Dove reperirli

È disponibile nell’oggetto 'assignee' o 'user' dei contenuti JSON relativi a issue, pull request ed eventi di revisione restituiti dall’API GitHub.

Esempi
john.doejane.smithdev-team-lead
Ambiente di distribuzione
DeploymentEnvironment
L’ambiente di destinazione di una distribuzione, ad esempio «Preproduzione» o «Produzione».
Descrizione

Questo attributo specifica l’ambiente in cui viene distribuito il codice. Monitorare le distribuzioni nei diversi ambienti è fondamentale per comprendere l’intero ciclo di vita, dallo sviluppo al rilascio in produzione.

L’attributo consente di analizzare il sottoprocesso di distribuzione. Può essere usato per misurare il tempo necessario a promuovere il codice dall’ambiente di preproduzione a quello di produzione e per monitorare la percentuale di successo delle distribuzioni nei diversi ambienti. È essenziale per stabilire quando un elemento di sviluppo è davvero «completato» e consegnato agli utenti.

Perché è importante

Distingue i rilasci in preproduzione da quelli in produzione, un aspetto fondamentale per misurare il vero tempo di commercializzazione e analizzare gli schemi di distribuzione.

Dove reperirli

Queste informazioni provengono dall’API GitHub Deployments, spesso attivata dalle pipeline CI/CD o da altri processi automatizzati.

Esempi
sviluppopreproduzioneproduzione
Autore
Author
L’utente che ha creato l’issue, la pull request o il commit.
Descrizione

L’autore è la persona che ha originato uno specifico artefatto nel processo di sviluppo. Per esempio, l’autore di un’issue è la persona che ha segnalato il bug o richiesto una funzionalità; l’autore di una pull request è lo sviluppatore che ha scritto il codice.

In fase di analisi, l’autore può aiutare a capire da dove proviene il lavoro. L’analisi degli autori delle segnalazioni di bug, ad esempio, può rivelare schemi ricorrenti legati a determinati team o funzionalità. L’autore può inoltre essere analizzato insieme all’assegnatario per individuare i passaggi di consegne.

Perché è importante

Identifica chi ha originato un elemento di lavoro o una modifica al codice e può essere utile per analizzare le fonti di rilavorazione, le segnalazioni di bug o le richieste di nuove funzionalità.

Dove reperirli

Disponibile nell’oggetto «user» all’interno dell’oggetto principale delle risposte API relative a issue, pull request e commit. Il campo è in genere «user.login».

Esempi
sara.jonesmike.leeautomation-bot
È una rilavorazione
IsRework
Indicatore booleano che vale true se un’attività rappresenta un ritorno a una fase precedente del processo.
Descrizione

Questo indicatore viene impostato su true quando un elemento di sviluppo torna indietro nel processo, ad esempio quando una pull request riceve una revisione con «Modifiche richieste» o quando un’issue viene riaperta dopo essere stata chiusa. Il valore deriva dall’analisi della sequenza delle attività.

Questo attributo è essenziale per quantificare gli sprechi e le inefficienze. Supporta direttamente la Dashboard «Cicli di rilavorazione e regressione» e il KPI «Tasso di rilavorazione». Filtrando per «IsRework = true», gli analisti possono isolare e approfondire le cause della rilavorazione.

Perché è importante

Segnala esplicitamente le attività che costituiscono una rilavorazione, rendendo semplice quantificare, visualizzare e analizzare le cause di inefficienza del processo.

Dove reperirli

È un attributo derivato. La logica prevede la definizione di un flusso di processo standard e la segnalazione di ogni attività che se ne discosta tornando a una fase logica precedente.

Esempi
truefalse
Esito della revisione
ReviewState
L’esito della revisione del codice di una pull request, ad esempio «Approvata» o «Modifiche richieste».
Descrizione

Questo attributo registra la decisione presa da un revisore. Gli stati più comuni includono «APPROVED», che indica che il codice è pronto per essere unito, e «CHANGES_REQUESTED», che segnala la necessità di una rilavorazione. Altri stati possibili sono «COMMENTED» e «PENDING».

È un attributo fondamentale per analizzare la rilavorazione e la qualità. Una frequenza elevata di eventi «CHANGES_REQUESTED» può indicare problemi nella qualità iniziale del codice o requisiti poco chiari. Supporta direttamente la Dashboard «Cicli di rilavorazione e regressione», indicando quando un elemento di sviluppo viene rimandato per essere modificato.

Perché è importante

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

Dove reperirli

Disponibile come campo «state» nell’oggetto di revisione di una pull request restituito dall’API GitHub, ad esempio nel payload di un «PullRequestReviewEvent».

Esempi
APPROVEDCHANGES_REQUESTEDCOMMENTED
Etichette
Labels
Un elenco di tag o etichette applicati a un’issue o a una pull request per classificarla.
Descrizione

In GitHub, le etichette offrono un modo flessibile per aggiungere metadati a issue e pull request. Possono indicare priorità, tipo di lavoro, componenti, team o stato. L’elenco completo delle etichette fornisce un contesto ricco e non strutturato.

Sebbene attributi specifici come la priorità e il tipo derivino dalle etichette, conservare l’elenco completo può essere utile per analisi ad hoc e per individuare altri schemi di processo. Consente di filtrare e segmentare i casi in modo flessibile, in base a qualsiasi combinazione di etichette.

Perché è importante

Fornisce una fonte flessibile e ricca di metadati per classificare gli elementi di lavoro e consente analisi dimensionali approfondite e diversificate.

Dove reperirli

Disponibile come array «labels» nel payload JSON di issue e pull request restituito dall’API GitHub. Ogni elemento dell’array è un oggetto con un campo «name».

Esempi
bug, interfaccia utente, alta prioritàfunzionalità, backend, documentazione necessariadebito tecnico, refactoring
Hash del commit
CommitHash
L’identificativo univoco (SHA) di uno specifico commit di codice.
Descrizione

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

Pur essendo molto dettagliato, l’hash del commit offre il massimo livello di tracciabilità. Consente agli analisti di collegare direttamente un evento di processo alla modifica esatta del codice. Può rivelarsi prezioso per gli audit, la conformità o l’analisi approfondita delle cause di incidenti in produzione.

Perché è importante

Collega un passaggio del processo alla modifica esatta del codice con il massimo livello di dettaglio, garantendo la tracciabilità completa per gli audit e il debug.

Dove reperirli

Disponibile nei payload degli eventi push («head_commit.id») o tramite l’API Commits per una pull request o un ramo.

Esempi
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Nome del ramo
BranchName
Il nome del ramo Git in cui sono state apportate le modifiche al codice relative all’elemento di sviluppo.
Descrizione

Un ramo è una linea di sviluppo indipendente, creata per lavorare a una nuova funzionalità o correggere un bug senza modificare la base di codice principale. Il nome del ramo spesso contiene informazioni utili, come il numero dell’issue o una breve descrizione del lavoro.

L’analisi dei nomi dei rami aiuta a comprendere le strategie di branching e il rispetto delle convenzioni di sviluppo. Consente inoltre di collegare specifici commit a un elemento di sviluppo, offrendo un quadro completo delle attività di programmazione.

Perché è importante

Fornisce informazioni sulla specifica linea di sviluppo e aiuta a definire e analizzare le strategie di branching e le convenzioni di denominazione.

Dove reperirli

Disponibile nel campo «ref» per gli eventi push oppure negli oggetti «head» e «base» all’interno della risposta API di una pull request.

Esempi
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
Numero della pull request
PullRequestNumber
L’identificativo univoco della pull request associata all’elemento di sviluppo.
Descrizione

Una pull request (PR) è una proposta per unire una serie di modifiche al codice in un ramo specifico. Il numero della pull request collega le attività di sviluppo, come l’invio di codice e le revisioni, all’elemento di sviluppo principale o all’issue.

Questo ID è fondamentale per monitorare l’integrazione del codice e il sottoprocesso di revisione all’interno del ciclo di vita complessivo dello sviluppo. Consente di analizzare nel dettaglio il processo di revisione del codice, inclusi i tempi di revisione, i cicli di rilavorazione individuati durante la revisione e le percentuali di unione. Collega la fase di pianificazione (issue) alla fase di implementazione (PR).

Perché è importante

Collega le issue alle modifiche specifiche del codice e ai relativi processi di revisione, consentendo di analizzare nel dettaglio il ciclo di revisione del codice e il suo impatto sui tempi complessivi di consegna.

Dove reperirli

Disponibile come campo «number» nell’oggetto «pull_request» in molte risposte API di GitHub oppure come identificativo principale nell’API Pull Requests.

Esempi
12345678910
Revisore
Reviewer
L’utente a cui è stato chiesto di eseguire la revisione del codice di una pull request.
Descrizione

Il revisore è uno sviluppatore o un membro del team incaricato di controllare le modifiche al codice di una pull request, verificandone la qualità, la correttezza e la conformità agli standard. Una pull request può avere più revisori.

Questo attributo è essenziale per analizzare il processo di revisione del codice. Aiuta a individuare i colli di bottiglia legati a specifici revisori, a comprendere come è distribuito il carico di lavoro delle revisioni e a misurare i tempi di risposta alle richieste. È un elemento chiave per calcolare il KPI «Tempo medio del ciclo di revisione del codice».

Perché è importante

Identifica le persone coinvolte nel processo di controllo della qualità e consente di analizzare il carico di lavoro delle revisioni, i ritardi e l’efficienza complessiva delle revisioni del codice.

Dove reperirli

Disponibile nell’array «requested_reviewers» o nell’oggetto «user» di un evento di revisione di una pull request restituito dall’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 degli eventi. Per questo processo, il valore sarà sempre 'GitHub'. In un ambiente più complesso, in cui le attività di sviluppo coinvolgono più sistemi, ad esempio Jira per la pianificazione, GitHub per il codice e Jenkins per la distribuzione, questo campo consente di distinguere l’origine di ogni evento.

Nell’analisi, aiuta a risalire all’origine dei dati per convalidarli e risolvere eventuali problemi. Consente inoltre di analizzare processi che coinvolgono piattaforme diverse, fornendo un contesto chiaro per ogni attività.

Perché è importante

Identifica l’origine dei dati, un’informazione essenziale per convalidarli e analizzare processi che possono coinvolgere più sistemi integrati.

Dove reperirli

In genere è un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento dei dati (ETL) per indicare l’origine dei record.

Esempi
GitHubGitHub Enterprise
Stato dei controlli CI
CiCheckStatus
Lo stato di un controllo automatizzato di integrazione continua (CI), ad esempio «superato» o «non superato».
Descrizione

Questo attributo indica l’esito delle compilazioni, dei test e delle scansioni automatizzati eseguiti sulle modifiche al codice di una pull request. Nei flussi di lavoro di sviluppo moderni, i controlli CI rappresentano un passaggio fondamentale per la qualità.

L’analisi di questo attributo aiuta a valutare l’efficacia dei test automatizzati. Un’elevata percentuale di errori può indicare problemi di stabilità del codice, della suite di test o dell’ambiente di sviluppo. Supporta le attività «Controlli CI superati» e «Controlli CI non superati» e consente di analizzare i ritardi causati da compilazioni non riuscite.

Perché è importante

Indica se i controlli automatizzati di qualità sono stati superati o meno, offrendo informazioni sulla qualità del codice e sull’efficacia della pipeline CI.

Dove reperirli

Si ottiene dal campo «state» o «conclusion» degli oggetti check run o status tramite le API GitHub Checks o Statuses.

Esempi
successfailurependingerror
Stato dell’elemento
State
Stato corrente di un’issue o di una pull request, ad esempio 'open', 'closed' o 'merged'.
Descrizione

Questo attributo indica lo stato generale di un elemento di sviluppo. Per le issue, gli stati tipici sono 'open' e 'closed'; per le pull request, sono 'open', 'closed' e 'merged'. Fornisce un quadro sintetico dell’avanzamento dell’elemento.

Nell’analisi, lo stato consente di distinguere il lavoro in corso da quello completato. È essenziale per Dashboard come 'Active Development Progress', che monitorano le attività in corso. Viene inoltre utilizzato per definire la fine di un processo: ad esempio, lo stato 'merged' o 'closed' può indicare il completamento di un caso.

Perché è importante

Indica chiaramente se un elemento di lavoro è in corso o completato, un’informazione fondamentale per analizzare il ciclo di vita e monitorare le attività in corso.

Dove reperirli

È disponibile direttamente nel campo 'state' dei contenuti JSON relativi a issue e pull request restituiti dall’API GitHub.

Esempi
openclosedmerged
Tempo di attesa nei passaggi di consegne
HandoffWaitingTime
Il tempo di inattività calcolato durante il quale un elemento di sviluppo resta in attesa tra attività svolte da persone diverse.
Descrizione

Questa metrica misura il tempo che intercorre tra il completamento di un’attività e l’inizio della successiva, ma solo quando cambia la persona responsabile. Per esempio, il tempo tra un evento «Revisione richiesta» e un evento «Modifiche richieste in revisione» eseguito da un altro utente.

È una metrica fondamentale per individuare lacune nella comunicazione e problemi di coordinamento. Supporta la Dashboard «Efficienza dei passaggi di consegne critici» e il KPI «Tempo medio di attesa nei passaggi di consegne». Tempi di attesa elevati in questi punti spesso indicano vincoli di capacità o processi di notifica inefficienti.

Perché è importante

Individua i ritardi dovuti a un coordinamento carente o alla mancanza di risorse nei passaggi di consegne tra team o ruoli diversi, spesso tra le principali fonti di inefficienza.

Dove reperirli

Si calcola individuando le attività consecutive in cui cambia l’attributo «Assignee» o «User» e misurando quindi l’intervallo di tempo tra le due attività.

Esempi
PT1H15MP2DT4HPT25M
Tempo di ciclo dello sviluppo
DevelopmentCycleTime
Il tempo totale trascorso dalla creazione di un elemento di sviluppo fino alla sua distribuzione finale o chiusura.
Descrizione

È una metrica a livello di caso, calcolata come differenza tra il primo evento, ad esempio «Issue creata», e l’evento finale, ad esempio «Distribuzione riuscita» o «Issue chiusa», per un singolo elemento di sviluppo.

È uno dei KPI più importanti per misurare l’efficienza complessiva del processo di sviluppo. Supporta direttamente la Dashboard «Tempo complessivo del ciclo di sviluppo» e il KPI «Tempo medio del ciclo di sviluppo». Ridurre questa metrica è spesso uno degli obiettivi principali delle iniziative di miglioramento dei processi.

Perché è importante

Rappresenta il tempo di commercializzazione complessivo di un elemento di sviluppo ed è quindi un KPI fondamentale per misurare la velocità e l’efficienza complessive del processo.

Dove reperirli

Si calcola a livello di caso sottraendo il timestamp della prima attività da quello dell’ultima.

Esempi
P5DT6H30MP14DT12HP1DT2H
Ultimo aggiornamento dei dati
LastDataUpdate
Timestamp che indica quando i dati di questo record sono stati aggiornati per l’ultima volta dal sistema di origine.
Descrizione

Questo attributo registra la data e l’ora dell’estrazione o dell’aggiornamento più recente dei dati. Fornisce metadati sul loro grado di aggiornamento. È distinto dal timestamp dell’evento, che indica quando si è verificato l’evento aziendale.

Nell’analisi, questo campo è fondamentale per capire quanto siano aggiornate le informazioni sul processo. Consente di sapere se si stanno consultando dati in tempo reale o un’istantanea riferita a un momento specifico, aspetto importante per le Dashboard operative e il monitoraggio.

Perché è importante

Indica quanto sono aggiornati i dati, un aspetto fondamentale per garantire che le analisi e le Dashboard si basino su informazioni recenti.

Dove reperirli

Questo timestamp viene generato e aggiunto durante il processo di estrazione, trasformazione e caricamento dei dati (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 e le tappe principali da registrare nell’Event Log per individuare con precisione i processi e i colli di bottiglia.
6 Consigliato 7 Facoltativo
Attività Descrizione
Controlli CI superati
Indica il completamento corretto dei controlli automatizzati, come compilazioni, test unitari o analisi statica, eseguiti sul codice di una pull request. L’evento viene dedotto dallo stato dei controlli segnalato da sistemi come GitHub Actions.
Perché è importante

Questo controllo automatizzato è essenziale per garantire la stabilità del codice. Gli errori o i tempi di esecuzione lunghi possono diventare colli di bottiglia significativi nel flusso di consegna.

Dove reperirli

L’evento viene dedotto dall’API GitHub Checks o dall’API Statuses. Un’esecuzione di controllo o un aggiornamento di stato segnala 'success' oppure 'completed' con esito 'success'.

Acquisizione

Monitori l’API Checks per rilevare un esito 'success' nelle suite di controlli pertinenti.

Tipo di evento inferred
Issue chiusa
L’elemento di sviluppo è considerato completato e la relativa issue viene chiusa formalmente. La chiusura può avvenire automaticamente quando viene unita una pull request collegata oppure manualmente da un membro del team.
Perché è importante

Questa attività segna la fine definitiva del processo relativo a un elemento di sviluppo. È essenziale per calcolare i tempi di ciclo complessivi.

Dove reperirli

È un evento esplicito registrato nel flusso di eventi dell’API GitHub Issues. Il tipo di evento è 'closed'.

Acquisizione

Rilevi l’evento 'closed' di un’issue tramite webhook o interrogazioni periodiche dell’API.

Tipo di evento explicit
Issue creata
Segna l’inizio del ciclo di vita di un elemento di sviluppo e corrisponde alla creazione formale di un’attività, di un bug o di una richiesta di funzionalità. L’evento viene registrato esplicitamente quando un utente crea una nuova issue in un repository GitHub.
Perché è importante

È la principale attività iniziale del processo, indispensabile per misurare il tempo di ciclo complessivo dello sviluppo e comprendere da dove proviene il lavoro.

Dove reperirli

È un evento esplicito registrato nel flusso di eventi dell’API GitHub Issues. Per una determinata issue, il tipo di evento è in genere 'opened'.

Acquisizione

Rilevi l’evento 'opened' di un’issue tramite webhook o interrogazioni periodiche dell’API.

Tipo di evento explicit
Pull request aperta
Indica che una prima parte del codice è pronta per la revisione e l’integrazione. Uno sviluppatore crea una pull request (PR) per proporre le modifiche dal proprio branch di funzionalità a un branch principale. In GitHub, questo evento viene registrato esplicitamente.
Perché è importante

È una tappa fondamentale: segna la fine della fase iniziale di sviluppo e l’inizio del flusso di revisione e integrazione. Consente di analizzare separatamente i tempi di sviluppo e quelli di revisione.

Dove reperirli

L’evento viene acquisito dal flusso di eventi dell’API GitHub Pull Request o tramite webhook. L’azione dell’evento è 'opened'.

Acquisizione

Rilevi tramite webhook o interrogazioni periodiche dell’API l’azione 'opened' relativa a una pull request.

Tipo di evento explicit
Pull request approvata
Un revisore ha approvato formalmente le modifiche di una pull request, confermando che rispettano gli standard di qualità e funzionalità. L’evento viene registrato quando il revisore invia la propria valutazione con lo stato 'approve'.
Perché è importante

È un passaggio essenziale per la qualità e una tappa importante prima dell’unione dei branch. Il tempo necessario per raggiungere questo stato dalla creazione della PR è un indicatore chiave dell’efficienza del processo di revisione.

Dove reperirli

L’evento viene acquisito dall’API GitHub Pull Request o tramite webhook quando una revisione viene inviata con lo stato 'APPROVED'.

Acquisizione

Filtri gli eventi di invio delle revisioni delle pull request in base allo stato 'APPROVED'.

Tipo di evento explicit
Pull request unita
Le modifiche approvate nella pull request vengono integrate ufficialmente nel branch di destinazione, ad esempio main o develop. È un’azione finale esplicita sulla pull request, che incorpora il nuovo codice.
Perché è importante

È una tappa fondamentale che segna il completamento dello sviluppo e della revisione. Per molti team, è l’ultimo passaggio prima della distribuzione automatizzata.

Dove reperirli

L’evento viene acquisito dal flusso di eventi dell’API GitHub Pull Request o tramite webhook. L’azione dell’evento è 'closed' e l’attributo 'merged' del contenuto della pull request è true.

Acquisizione

Rilevi l’azione 'closed' di una pull request e verifichi se il flag 'merged' è true.

Tipo di evento explicit
Branch creato
Indica l’inizio del lavoro attivo su un’issue, quando uno sviluppatore crea un nuovo branch a partire dal codice principale. L’evento viene registrato esplicitamente quando un nuovo branch viene inviato al repository; spesso il nome include il numero dell’issue.
Perché è importante

Segna il passaggio dalla pianificazione alla scrittura attiva del codice. Misurare il tempo tra la creazione dell’issue e questo evento aiuta ad analizzare quanto tempo passa prima che uno sviluppatore inizi a lavorarci e a individuare i ritardi iniziali nel backlog.

Dove reperirli

L’evento viene acquisito tramite l’API Git di GitHub o webhook che rilevano gli eventi 'create' di tipo 'branch'. Spesso è necessario associare il nome del branch a un’issue in base a convenzioni di denominazione, ad esempio 'feature/issue-123'.

Acquisizione

Analizzi gli eventi webhook 'create' relativi ai nuovi branch e li associ a un’issue.

Tipo di evento explicit
Codice inviato alla PR
Indica un aggiornamento del codice sottoposto a revisione, sia come parte della PR iniziale sia in risposta ai commenti ricevuti. L’evento viene registrato ogni volta che un nuovo commit viene inviato al branch associato a una pull request aperta.
Perché è importante

Tenere traccia di questi eventi è fondamentale per individuare i cicli di rilavorazione. Più invii dopo una revisione indicano che sono state richieste modifiche, con conseguenze sul tempo di ciclo complessivo.

Dove reperirli

È un evento esplicito nella cronologia della pull request, spesso indicato come aggiunta di un commit. Può essere acquisito dal webhook 'push' o monitorando i commit associati a una PR.

Acquisizione

Tenga traccia degli eventi 'push' su un branch associato a una pull request aperta.

Tipo di evento explicit
Controlli CI non superati
Indica il mancato superamento di un controllo automatizzato, ad esempio un errore di compilazione o un test unitario non riuscito, eseguito sul codice di una pull request. L’evento viene dedotto da uno stato di errore segnalato da un sistema come GitHub Actions.
Perché è importante

Questa attività mette in evidenza problemi tecnici di qualità che richiedono l’intervento degli sviluppatori e generano un ciclo di rilavorazione. Analizzare la frequenza degli errori può orientare i miglioramenti nei test locali o nella qualità del codice.

Dove reperirli

L’evento viene dedotto dall’API GitHub Checks o dall’API Statuses. Un’esecuzione di controllo o un aggiornamento di stato segnala 'failure' oppure 'completed' con esito 'failure'.

Acquisizione

Monitori l’API Checks per rilevare un esito 'failure' nelle suite di controlli pertinenti.

Tipo di evento inferred
Distribuzione riuscita
Le modifiche al codice sono state distribuite correttamente in un ambiente specifico, ad esempio di collaudo o di produzione. In genere, l’evento viene acquisito tramite l’API GitHub Deployments, spesso dopo l’attivazione di una GitHub Action in seguito a un’unione.
Perché è importante

Segna il passaggio del codice dal repository a un ambiente operativo. Tenerne traccia è essenziale per misurare il tempo di attraversamento complessivo, dall’idea alla produzione.

Dove reperirli

L’evento viene acquisito tramite l’API Deployments. Un servizio esterno o una GitHub Action crea una distribuzione e ne aggiorna lo stato a 'success'.

Acquisizione

Monitori tramite webhook gli eventi di stato della distribuzione per rilevare lo stato 'success'.

Tipo di evento inferred
Issue riaperta
Un’issue precedentemente chiusa viene riattivata, in genere perché la correzione non era sufficiente o è stata rilevata una regressione. È un evento esplicito che riavvia il ciclo di vita dell’elemento di sviluppo.
Perché è importante

Segnala un ciclo di rilavorazione significativo e può indicare un difetto sfuggito ai controlli in produzione o una correzione incompleta. Monitorarne la frequenza è un indicatore importante della qualità complessiva del software.

Dove reperirli

È un evento esplicito registrato nel flusso di eventi dell’API GitHub Issues. Il tipo di evento è 'reopened'.

Acquisizione

Rilevi l’evento 'reopened' di un’issue tramite webhook o interrogazioni periodiche dell’API.

Tipo di evento explicit
Modifiche richieste in revisione
Un revisore ha completato la revisione del codice e stabilito che sono necessarie modifiche prima di poter approvare la pull request. Il revisore invia formalmente la propria valutazione 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 una formazione degli sviluppatori.

Dove reperirli

L’evento viene acquisito dall’API GitHub Pull Request o tramite webhook quando una revisione viene inviata con lo stato 'CHANGES_REQUESTED'.

Acquisizione

Filtri gli eventi di invio delle revisioni delle pull request in base allo stato 'CHANGES_REQUESTED'.

Tipo di evento explicit
Revisione richiesta
L’autore di una pull request chiede formalmente a specifici membri del team o a interi team di rivedere il codice. Questa azione esplicita nell’interfaccia o nell’API di GitHub invia notifiche ai revisori selezionati.
Perché è importante

Questa attività segna l’inizio ufficiale del passaggio al processo di revisione del codice. Il tempo che intercorre tra questo evento e l’invio di una revisione aiuta a misurare la tempestività dei revisori e a individuare eventuali colli di bottiglia.

Dove reperirli

L’evento viene acquisito dal flusso di eventi dell’API GitHub Pull Request o tramite webhook. L’azione dell’evento è 'review_requested'.

Acquisizione

Rilevi l’azione 'review_requested' relativa a una pull request.

Tipo di evento explicit
Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da GitHub

È pronto a iniziare?

Utilizzi questo template per preparare i dati e iniziare a ottimizzare il ciclo di vita dello sviluppo software. Individui le inefficienze e favorisca rilasci più rapidi e fluidi, fin da subito.

Migliori il ciclo di vita dello sviluppo software: individui subito le inefficienze

Riduca del 30% il tempo di ciclo e semplifichi il processo di sviluppo su GitHub.

Inizi la prova gratuita

Non è richiesta la carta di credito. La configurazione richiede pochi minuti.