Il Suo Modello di Dati per il Ciclo di Vita dello Sviluppo Software
Il Suo Modello di Dati per il Ciclo di Vita dello Sviluppo Software
- Attributi consigliati da raccogliere
- Attività chiave da tracciare
- Guida all'estrazione
Attributi del ciclo di vita dello sviluppo software
| 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
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
|
|||
Attività del ciclo di vita dello sviluppo software
| 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
|
|||