Il Template dei dati per il ciclo di vita dello sviluppo software
Il Template dei dati per il ciclo di vita dello sviluppo software
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l’estrazione
Attributi del ciclo di vita dello sviluppo software
| 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
|
|||
Attività del ciclo di vita dello sviluppo software
| 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
|
|||
Guide all’estrazione
È 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.
Non è richiesta la carta di credito. La configurazione richiede pochi minuti.