Datatemplate voor de softwareontwikkelingscyclus
Datatemplate voor de softwareontwikkelingscyclus
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om bij te houden
- Aanwijzingen voor data-extractie
Attributen voor de softwareontwikkelingscyclus
| Naam | Beschrijving | ||
|---|---|---|---|
|
Activiteit
ActivityName
|
De naam van een specifiek event of een specifieke taak binnen de levenscyclus van softwareontwikkeling. | ||
|
Beschrijving
De activiteitsnaam beschrijft één stap in het ontwikkelproces, zoals 'Issue aangemaakt', 'Code naar PR gepusht', 'Pull request goedgekeurd' of 'Implementatie geslaagd'. Deze events vormen samen de reeks stappen van het volledige proces voor een ontwikkelitem. Dit attribuut is essentieel voor process mining, omdat je ermee de proceskaart opbouwt. Analyse van de volgorde, frequentie en duur van activiteiten laat zien hoe het proces daadwerkelijk verloopt, welke routes vaak voorkomen en waar afwijkingen en bottlenecks zitten.
Waarom dit belangrijk is
Dit attribuut vormt de basis van de proceskaart en maakt het mogelijk de volgorde van events in de ontwikkelcyclus te visualiseren en analyseren.
Waar vind je dit?
Afgeleid van het veld 'action' in webhook-eventpayloads, bijvoorbeeld 'opened' of 'closed' voor een issue, of van het eventtype zelf, zoals 'PushEvent' of 'PullRequestReviewEvent'.
Voorbeelden
Issue aangemaaktPull request geopendCode naar PR gepushtBeoordeling aangevraagdPull request samengevoegd
|
|||
|
Ontwikkelitem
DevelopmentItemId
|
De unieke identificatiecode van één eenheid ontwikkelwerk, zoals een functie, bugfix of taak. Dit is de primaire case-ID. | ||
|
Beschrijving
De ID van het ontwikkelitem volgt een werkitem vanaf het aanmaken tot en met de uiteindelijke implementatie. De ID koppelt alle bijbehorende activiteiten, zoals het aanmaken van branches, commits, pull requests, beoordelingen en implementaties, aan één procesinstantie. Bij analyses gebruik je deze ID om de totale doorlooptijd van een ontwikkeltaak te berekenen. Zo kun je het volledige verloop van een functie of bugfix reconstrueren en bottlenecks, herstelwerklussen en procesvariaties per werkitem analyseren.
Waarom dit belangrijk is
Dit is de sleutel voor process mining: de ID koppelt alle gerelateerde ontwikkel-events aan één case, zodat je de volledige levenscyclus van softwareontwikkeling nauwkeurig kunt visualiseren en analyseren.
Waar vind je dit?
Dit is doorgaans het issuenummer of het nummer van de pull request in GitHub. Je kunt het ophalen uit het veld 'number' in de payload van webhook-events of API-antwoorden over issues en pull requests.
Voorbeelden
101PR-2345TASK-812
|
|||
|
Starttijd
EventTimestamp
|
De exacte datum en tijd waarop een ontwikkelactiviteit of event plaatsvond. | ||
|
Beschrijving
Deze timestamp markeert het begin van een activiteit. Je hebt deze nodig om events chronologisch te ordenen en het procesverloop van elk ontwikkelitem te reconstrueren. De volgorde en tijd tussen deze timestamps helpen de procesprestaties te analyseren. Bij analyses gebruik je dit attribuut voor alle tijdsgebonden metrieken, waaronder doorlooptijden, verwerkingstijden en wachttijden. Het helpt vertragingen tussen stappen op te sporen en levert data voor bottleneckanalyses en dashboards voor prestatiemonitoring.
Waarom dit belangrijk is
Deze timestamp is nodig om events in de juiste volgorde te zetten en prestatiemetrieken te berekenen, zoals doorlooptijden en de duur van bottlenecks.
Waar vind je dit?
Deze waarde staat doorgaans in de velden 'created_at' of 'updated_at' van JSON-payloads uit GitHub-API's en webhooks voor onder meer issues, pull requests en commits.
Voorbeelden
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
|
|||
|
Eindtijd
EndTimestamp
|
De exacte datum en tijd waarop een ontwikkelactiviteit of event is afgerond. | ||
|
Beschrijving
De eindtimestamp markeert het einde van een activiteit. Veel events in GitHub zijn momentopnamen, zoals 'Issue aangemaakt', maar sommige activiteiten hebben een meetbare duur, zoals een lopende CI-controle. Het verschil tussen de eindtijd en starttijd is de verwerkingstijd van een activiteit. Met dit attribuut bereken je de metriek 'ProcessingTime'. Die laat zien hoeveel actieve tijd verschillende taken kosten, zoals codebeoordelingen of geautomatiseerde controles. Door verwerkingstijden te analyseren, kun je activiteiten opsporen die onnodig veel tijd kosten.
Waarom dit belangrijk is
Hiermee bereken je nauwkeurig hoelang activiteiten worden verwerkt en maak je onderscheid tussen actieve werktijd en wachttijd.
Waar vind je dit?
Deze waarde staat mogelijk als 'completed_at' in check run-objecten. Je kunt de eindtijd ook afleiden van de timestamp van een daaropvolgend event dat de activiteit logisch afsluit.
Voorbeelden
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
|
|||
|
Prioriteit
Priority
|
Het prioriteitsniveau van een ontwikkelitem, bijvoorbeeld ‘Hoog’, ‘Gemiddeld’ of ‘Laag’. | ||
|
Beschrijving
Prioriteit geeft aan hoe urgent of belangrijk een werkitem is voor de organisatie. GitHub heeft geen standaardveld voor prioriteit. Meestal wordt deze vastgelegd met labels, zoals ‘P1-Hoog’ en ‘P2-Gemiddeld’. Om de informatie betrouwbaar uit te lezen, is een vaste labelconventie nodig. Dit attribuut is essentieel voor ‘Flowanalyse op basis van prioriteit’. Analisten kunnen ermee nagaan of items met hoge prioriteit daadwerkelijk sneller worden verwerkt dan items met lage prioriteit. Ook kunnen ze verschillen in doorlooptijd per prioriteit meten. Zo wordt duidelijk hoe goed het prioriteringsproces werkt.
Waarom dit belangrijk is
Hiermee kun je nagaan of items met hoge prioriteit sneller worden verwerkt dan items met lagere prioriteit. Zo zie je of de prioriteringsstrategie werkt.
Waar vind je dit?
Afgeleid van GitHub-labels op issues of pull requests. Hiervoor is een vaste conventie voor prioriteitslabels nodig.
Voorbeelden
HoogGemiddeldLaagKritiek
|
|||
|
Repository
RepositoryName
|
De naam van de coderepository waarin de ontwikkelactiviteit plaatsvindt. | ||
|
Beschrijving
De repository fungeert als identificatie voor een project of product en bevat alle code, issues en pull requests voor een specifieke applicatie of component. Zo kun je ontwikkelprocessen van verschillende producten of teams apart bekijken en vergelijken. Bij analyses kun je met dit attribuut de procesprestaties van verschillende projecten filteren en vergelijken. Het helpt vragen te beantwoorden als: 'Welk project heeft de langste doorlooptijd?' of 'Hoe verhoudt het bugfixproces in Project A zich tot dat in Project B?' Het is essentieel voor het dashboard 'Doorvoer per project en type'.
Waarom dit belangrijk is
Hiermee kun je ontwikkelprocessen van verschillende projecten, producten of teams apart bekijken en vergelijken, voor een gerichtere analyse.
Waar vind je dit?
Deze waarde staat in het object 'repository' in vrijwel alle GitHub-webhook- en API-payloads. Het specifieke veld is doorgaans 'repository.full_name' of 'repository.name'.
Voorbeelden
my-org/web-appmy-org/api-servicemy-org/data-pipeline
|
|||
|
Toegewezen gebruiker
Assignee
|
De gebruiker of ontwikkelaar die verantwoordelijk is voor een ontwikkelitem of een specifieke taak, zoals de beoordeling van een pull request. | ||
|
Beschrijving
Dit attribuut geeft aan wie in een bepaalde fase verantwoordelijk is voor het werk. Dat kan de toegewezen persoon van een issue zijn, de auteur van een pull request of de reviewer die voor een codebeoordeling is gevraagd. Door de toegewezen persoon bij te houden, krijg je zicht op de verdeling van werk en capaciteit. Bij analyses gebruik je dit attribuut om de werkdruk van ontwikkelaars te volgen, bottlenecks in de inzet van mensen te vinden en overdrachten tussen teamleden te analyseren. Je kunt dashboards filteren op toegewezen persoon om de prestaties van een individu of team te beoordelen en het werk evenwichtig te verdelen.
Waarom dit belangrijk is
Dit attribuut is belangrijk voor analyses van de werkdruk van ontwikkelaars, teamprestaties en de efficiëntie van overdrachten tussen teamleden.
Waar vind je dit?
Deze waarde staat in het object 'assignee' of 'user' in JSON-payloads voor issues, pull requests en beoordelings-events uit de GitHub API.
Voorbeelden
john.doejane.smithdev-team-lead
|
|||
|
Type ontwikkelitem
DevelopmentItemType
|
De classificatie van het ontwikkelwerkitem, zoals een functie, bug, taak of epic. | ||
|
Beschrijving
Dit attribuut geeft aan wat voor werk er wordt gedaan. Deze informatie wordt doorgaans beheerd met labels of specifieke issuetemplates in GitHub. Het type werk is belangrijk om passende prestatieverwachtingen vast te stellen: een bugfix heeft bijvoorbeeld vaak een veel kortere verwachte doorlooptijd dan een nieuwe functie. Met dit attribuut kun je verschillende soorten werk vergelijken. Je kunt nagaan of bugfixes sneller worden verwerkt dan nieuwe functies en hoe de capaciteit wordt verdeeld tussen technische schuld en nieuwe ontwikkeling. Het is een belangrijke dimensie in het dashboard 'Doorvoer per project en type'.
Waarom dit belangrijk is
Dit attribuut classificeert werkitems, zodat je prestaties kunt vergelijken en kunt analyseren hoe verschillende soorten werk, zoals bugs en functies, door het proces lopen.
Waar vind je dit?
Doorgaans afgeleid van GitHub-labels op issues of pull requests. Hiervoor is een vaste labelconventie nodig, zoals 'type:bug' en 'type:feature'.
Voorbeelden
BugFunctieTaakTechnische schuld
|
|||
|
Auteur
Author
|
De gebruiker die de issue, pull request of commit heeft aangemaakt. | ||
|
Beschrijving
De auteur is degene die een specifiek onderdeel van het ontwikkelproces heeft aangemaakt. De auteur van een issue is bijvoorbeeld degene die de bug heeft gemeld of de functie heeft aangevraagd. De auteur van een pull request is de ontwikkelaar die de code heeft geschreven. In analyses kun je de auteur gebruiken om te achterhalen waar het werk vandaan komt. Een analyse van auteurs van bugmeldingen kan bijvoorbeeld patronen bij bepaalde teams of functies aan het licht brengen. In combinatie met de toegewezene kun je ook overdrachten analyseren.
Waarom dit belangrijk is
Geeft aan wie een werkitem of codewijziging heeft aangemaakt. Dit kan helpen bij het analyseren van bronnen van herstelwerk, bugmeldingen en functieaanvragen.
Waar vind je dit?
Beschikbaar in het object ‘user’ binnen het hoofdobject van API-antwoorden voor issues, pull requests en commits. Het veld heet meestal ‘user.login’.
Voorbeelden
sara.jonesmike.leeautomation-bot
|
|||
|
Branchnaam
BranchName
|
De naam van de Git-branch waarin de codewijzigingen voor het ontwikkelitem zijn aangebracht. | ||
|
Beschrijving
Een branch is een zelfstandige ontwikkellijn. Je maakt er een aan om aan een nieuwe functie of bugfix te werken zonder de hoofdcodebase te wijzigen. De branchnaam bevat vaak nuttige informatie, zoals het issuenummer of een korte omschrijving van het werk. Door branchnamen te analyseren, krijg je inzicht in de gebruikte branchingstrategieën en de naleving van ontwikkelconventies. Je kunt er ook specifieke codecommits mee koppelen aan een ontwikkelitem, zodat je een compleet beeld krijgt van de codeeractiviteiten.
Waarom dit belangrijk is
Geeft context over de specifieke ontwikkellijn en helpt bij het toepassen en analyseren van branchingstrategieën en naamgevingsconventies.
Waar vind je dit?
Beschikbaar in het veld ‘ref’ voor push-events, of in de objecten ‘head’ en ‘base’ in een API-antwoord voor een pull request.
Voorbeelden
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
|
|||
|
Bronsysteem
SourceSystem
|
Het systeem waaruit de data over het ontwikkelproces is gehaald. | ||
|
Beschrijving
Dit attribuut geeft aan waar de eventdata vandaan komt. Voor dit proces is de waarde steeds 'GitHub'. In een complexere omgeving waarin ontwikkelactiviteiten over meerdere systemen lopen, bijvoorbeeld Jira voor planning, GitHub voor code en Jenkins voor implementatie, maakt dit veld duidelijk uit welk systeem elk event komt. Bij analyses helpt het om data naar de bron terug te leiden voor validatie en probleemoplossing. Ook kun je er processen mee analyseren die meerdere platforms omvatten, met een duidelijke context voor elke activiteit.
Waarom dit belangrijk is
Dit attribuut geeft de herkomst van de data aan. Dat is nodig om data te valideren en processen te analyseren die over meerdere gekoppelde systemen lopen.
Waar vind je dit?
Dit is doorgaans een vaste waarde die tijdens het ETL-proces (extractie, transformatie en laden) wordt toegevoegd om de bron van de records aan te geven.
Voorbeelden
GitHubGitHub Enterprise
|
|||
|
CI-checkstatus
CiCheckStatus
|
De status van een geautomatiseerde Continuous Integration-check (CI), bijvoorbeeld ‘geslaagd’ of ‘mislukt’. | ||
|
Beschrijving
Dit attribuut geeft de uitkomst weer van geautomatiseerde builds, tests en scans op codewijzigingen in een pull request. CI-checks zijn een belangrijke kwaliteitscontrole in moderne ontwikkelworkflows. Met dit attribuut kun je de effectiviteit van geautomatiseerd testen beoordelen. Een hoog percentage mislukte checks kan wijzen op problemen met de stabiliteit van de code, de testsuite of de ontwikkelomgeving. Het ondersteunt de activiteiten ‘CI-checks geslaagd’ en ‘CI-checks mislukt’ en helpt vertragingen door mislukte builds te analyseren.
Waarom dit belangrijk is
Geeft aan of geautomatiseerde kwaliteitscontroles slagen of mislukken. Zo krijg je inzicht in de codekwaliteit en de effectiviteit van de CI-pipeline.
Waar vind je dit?
Opgehaald uit het veld ‘state’ of ‘conclusion’ van check-run- of statusobjecten via de GitHub Checks API of Statuses API.
Voorbeelden
successfailurependingerror
|
|||
|
Commit-hash
CommitHash
|
De unieke identificatiecode (SHA) van een specifieke codecommit. | ||
|
Beschrijving
Een commit-hash is een SHA-1-hash van 40 tekens die een commit in Git uniek identificeert. De hash is een vaste ID voor een specifieke codeversie. Commits zijn de kleinste afzonderlijke wijzigingen in het ontwikkelproces. De commit-hash biedt zeer gedetailleerde traceerbaarheid. Analisten kunnen een procesgebeurtenis ermee rechtstreeks koppelen aan de exacte codewijziging. Dat is waardevol voor audits, compliance en een gedetailleerde oorzaakanalyse van productie-incidenten.
Waarom dit belangrijk is
Legt de meest gedetailleerde koppeling tussen een processtap en de exacte codewijziging. Zo zijn wijzigingen volledig traceerbaar voor audits en foutopsporing.
Waar vind je dit?
Beschikbaar in payloads van push-events (‘head_commit.id’) of via de Commits API voor een pull request of branch.
Voorbeelden
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
|
|||
|
Doorlooptijd ontwikkelcyclus
DevelopmentCycleTime
|
De totale tijd vanaf het aanmaken van een ontwikkelitem tot de uiteindelijke implementatie of afsluiting. | ||
|
Beschrijving
Dit is een metriek op caseniveau. De waarde is het tijdsverschil tussen de eerste gebeurtenis, bijvoorbeeld ‘Issue aangemaakt’, en de laatste gebeurtenis, zoals ‘Implementatie geslaagd’ of ‘Issue gesloten’, voor één ontwikkelitem. Dit is een van de belangrijkste KPI’s om de algehele efficiëntie van het ontwikkelproces te meten. De metriek ondersteunt het dashboard ‘Totale doorlooptijd ontwikkelcyclus’ en de KPI ‘Gemiddelde doorlooptijd ontwikkelcyclus’. Het verkorten van deze doorlooptijd is vaak een belangrijk doel van procesverbetering.
Waarom dit belangrijk is
Geeft de end-to-end time-to-market van een ontwikkelitem weer. Daarmee is het een belangrijke KPI voor het meten van de snelheid en efficiëntie van het hele proces.
Waar vind je dit?
Berekend op caseniveau door de timestamp van de eerste activiteit af te trekken van die van de laatste activiteit.
Voorbeelden
P5DT6H30MP14DT12HP1DT2H
|
|||
|
Implementatieomgeving
DeploymentEnvironment
|
De doelomgeving voor een implementatie, bijvoorbeeld ‘Staging’ of ‘Production’. | ||
|
Beschrijving
Dit attribuut geeft aan waar de code wordt geïmplementeerd. Door implementaties in verschillende omgevingen te volgen, krijg je zicht op de volledige levenscyclus, van ontwikkeling tot productie. Je kunt dit attribuut gebruiken om het implementatiesubproces te analyseren. Meet bijvoorbeeld hoe lang het duurt om code van staging naar productie te brengen en houd bij hoe vaak implementaties in verschillende omgevingen slagen. Zo zie je wanneer een ontwikkelitem echt ‘klaar’ is en bij gebruikers is afgeleverd.
Waarom dit belangrijk is
Maakt onderscheid tussen releases vóór productie en releases naar productie. Dat is belangrijk om de werkelijke time-to-market te meten en implementatiepatronen te analyseren.
Waar vind je dit?
Deze informatie komt uit de GitHub Deployments API. Die wordt vaak aangeroepen door CI/CD-pipelines of andere automatisering.
Voorbeelden
developmentstagingproduction
|
|||
|
Is herstelwerk
IsRework
|
Een booleaanse vlag die waar is als een activiteit een terugkeer naar een eerdere procesfase aangeeft. | ||
|
Beschrijving
Deze vlag krijgt de waarde true wanneer een ontwikkelitem teruggaat in het proces. Dat gebeurt bijvoorbeeld als een pull request de reviewstatus ‘Wijzigingen gevraagd’ krijgt of als een gesloten issue opnieuw wordt geopend. De vlag wordt afgeleid uit de volgorde van activiteiten. Dit attribuut is essentieel om verspilling en inefficiëntie te meten. Het ondersteunt het dashboard ‘Herstelwerk en regressielussen’ en de KPI ‘Percentage herstelwerk’. Door te filteren op ‘IsRework = true’ kunnen analisten herstelwerk apart bekijken en de oorzaken ervan onderzoeken.
Waarom dit belangrijk is
Markeert activiteiten die herstelwerk vormen. Zo kun je de omvang ervan meten, zichtbaar maken en de oorzaken van inefficiëntie analyseren.
Waar vind je dit?
Dit is een afgeleid attribuut. Eerst definieer je een standaardprocesverloop. Daarna markeer je activiteiten die daarvan afwijken doordat ze teruggaan naar een eerdere logische fase.
Voorbeelden
truefalse
|
|||
|
Laatste data-update
LastDataUpdate
|
De timestamp die aangeeft wanneer de data voor dit record voor het laatst uit het bronsysteem is bijgewerkt. | ||
|
Beschrijving
Dit attribuut bevat de datum en tijd van de meest recente data-extractie of update. Het geeft aan hoe actueel de geanalyseerde data is. Dit is iets anders dan de eventtimestamp, die vastlegt wanneer de bedrijfsgebeurtenis plaatsvond. Bij analyses laat dit veld zien hoe actueel het procesbeeld is. Je ziet of je naar realtime data kijkt of naar een momentopname. Dat is belangrijk voor operationele dashboards en monitoring.
Waarom dit belangrijk is
Dit geeft aan hoe actueel de data is. Zo kun je controleren of analyses en dashboards op recente informatie zijn gebaseerd.
Waar vind je dit?
Deze timestamp wordt gegenereerd en toegevoegd tijdens het ETL-proces (extractie, transformatie en laden).
Voorbeelden
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Pull requestnummer
PullRequestNumber
|
De unieke identificatiecode van een pull request dat bij het ontwikkelitem hoort. | ||
|
Beschrijving
Een pull request (PR) is een voorstel om een reeks codewijzigingen samen te voegen met een specifieke branch. Het pull requestnummer koppelt ontwikkelactiviteiten, zoals codepushes en reviews, aan het bijbehorende ontwikkelitem of de issue. Deze ID is belangrijk om de code-integratie en de review-subprocessen binnen de bredere ontwikkelcyclus te volgen. Je kunt er het code-reviewproces mee analyseren, bijvoorbeeld de reviewtijden, herstelwerk tijdens reviews en het percentage samengevoegde pull requests. Zo wordt de verbinding zichtbaar tussen de planningsfase (issue) en de implementatiefase (PR).
Waarom dit belangrijk is
Koppelt issues aan specifieke codewijzigingen en reviews. Zo kun je de code-reviewcyclus en het effect ervan op de totale levertijd gedetailleerd analyseren.
Waar vind je dit?
Beschikbaar als het veld ‘number’ in het object ‘pull_request’ in veel GitHub API-antwoorden, of als de belangrijkste identificatiecode in de Pull Requests API.
Voorbeelden
12345678910
|
|||
|
Reviewer
Reviewer
|
De gebruiker die is gevraagd een code-review uit te voeren op een pull request. | ||
|
Beschrijving
Een reviewer is een ontwikkelaar of teamlid dat is aangewezen om codewijzigingen in een pull request te controleren op kwaliteit, juistheid en naleving van standaarden. Een pull request kan meerdere reviewers hebben. Dit attribuut is essentieel voor de analyse van het code-reviewproces. Je kunt ermee bottlenecks bij specifieke reviewers opsporen, de verdeling van de reviewwerkdruk bekijken en meten hoe lang reviewers nodig hebben om op verzoeken te reageren. Het is een belangrijk onderdeel van de KPI ‘Gemiddelde doorlooptijd van code-review’.
Waarom dit belangrijk is
Geeft aan wie betrokken is bij de kwaliteitscontrole. Zo kun je de reviewwerkdruk, vertragingen en de algehele efficiëntie van code-reviews analyseren.
Waar vind je dit?
Beschikbaar in de array ‘requested_reviewers’ of het object ‘user’ van een pull request-reviewevent uit de GitHub API.
Voorbeelden
alex.chenmaria.garciasenior-dev-team
|
|||
|
Reviewstatus
ReviewState
|
De uitkomst van een code-review op een pull request, bijvoorbeeld ‘Goedgekeurd’ of ‘Wijzigingen gevraagd’. | ||
|
Beschrijving
Dit attribuut legt de beslissing van een reviewer vast. Veelvoorkomende statussen zijn ‘APPROVED’, wat betekent dat de code klaar is om te worden samengevoegd, en ‘CHANGES_REQUESTED’, wat aangeeft dat herstelwerk nodig is. Andere statussen zijn bijvoorbeeld ‘COMMENTED’ en ‘PENDING’. Dit attribuut is belangrijk voor de analyse van herstelwerk en kwaliteit. Een hoog aantal ‘CHANGES_REQUESTED’-events kan wijzen op problemen met de oorspronkelijke codekwaliteit of onduidelijke vereisten. Het ondersteunt het dashboard ‘Herstelwerk en regressielussen’ door te laten zien wanneer een ontwikkelitem wordt teruggestuurd voor aanpassingen.
Waarom dit belangrijk is
Maakt herstelwerklussen en kwaliteitscontroles in het code-reviewproces zichtbaar. Zo kun je bronnen van inefficiëntie en kwaliteitsproblemen opsporen.
Waar vind je dit?
Beschikbaar als het veld ‘state’ in een pull request-reviewobject uit de GitHub API, bijvoorbeeld in een ‘PullRequestReviewEvent’-payload.
Voorbeelden
APPROVEDCHANGES_REQUESTEDCOMMENTED
|
|||
|
Status van item
State
|
De huidige status van een issue of pull request, zoals 'open', 'closed' of 'merged'. | ||
|
Beschrijving
Dit attribuut geeft de algemene status van een ontwikkelitem aan. Voor issues zijn de gebruikelijke statussen 'open' en 'closed'. Voor pull requests zijn dat 'open', 'closed' en 'merged'. Zo zie je in één oogopslag hoe ver het item is. Bij analyses gebruik je de status om actief werk van afgerond werk te onderscheiden. Dit is belangrijk voor dashboards zoals 'Voortgang van actieve ontwikkeling', die lopend werk volgen. Je kunt de status ook gebruiken om het einde van een proces te bepalen. De status 'merged' of 'closed' kan bijvoorbeeld aangeven dat een case is afgerond.
Waarom dit belangrijk is
Dit maakt duidelijk of een werkitem nog loopt of is afgerond. Dat is belangrijk voor analyses van de levenscyclus en voor het volgen van actief werk.
Waar vind je dit?
Deze waarde staat rechtstreeks in het veld 'state' van JSON-payloads voor issues en pull requests uit de GitHub API.
Voorbeelden
openclosedmerged
|
|||
|
Tags
Labels
|
Een lijst met tags of labels voor de categorisering van een issue of pull request. | ||
|
Beschrijving
Labels in GitHub bieden een flexibele manier om metadata aan issues en pull requests toe te voegen. Je kunt ze gebruiken voor prioriteit, werksoort, onderdelen, teams of status. De volledige lijst met labels geeft veel context, maar heeft geen vaste structuur. Specifieke attributen zoals prioriteit en type worden uit labels afgeleid. Toch kan het handig zijn om de volledige lijst te bewaren voor ad-hocanalyses en om andere procespatronen te ontdekken. Je kunt cases flexibel filteren en indelen op basis van elke combinatie van labels.
Waarom dit belangrijk is
Biedt een flexibele, rijke bron van metadata om werkitems te categoriseren en vanuit verschillende invalshoeken te analyseren.
Waar vind je dit?
Beschikbaar als de array ‘labels’ in de JSON-payload voor issues en pull requests uit de GitHub API. Elk item in de array is een object met een veld ‘name’.
Voorbeelden
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
|
|||
|
Wachttijd bij overdracht
HandoffWaitingTime
|
De berekende wachttijd van een ontwikkelitem tussen activiteiten die door verschillende mensen worden uitgevoerd. | ||
|
Beschrijving
Deze metriek meet de tijd tussen het einde van een activiteit en het begin van de volgende, maar alleen als de verantwoordelijke persoon verandert. Bijvoorbeeld de tijd tussen een event ‘Review aangevraagd’ en een event ‘Wijzigingen gevraagd in review’ van een andere gebruiker. Deze metriek is belangrijk om communicatieproblemen en coördinatieproblemen op te sporen. Ze ondersteunt het dashboard ‘Efficiëntie van kritieke overdrachten’ en de KPI ‘Gemiddelde wachttijd bij overdracht’. Lange wachttijden bij overdrachten wijzen vaak op beperkte capaciteit of inefficiënte meldingsprocessen.
Waarom dit belangrijk is
Brengt vertragingen door gebrekkige coördinatie of beperkte beschikbaarheid van mensen bij overdrachten tussen teams of rollen aan het licht. Dit zijn vaak belangrijke bronnen van inefficiëntie.
Waar vind je dit?
Berekend door opeenvolgende activiteiten te vinden waarbij het attribuut ‘Assignee’ of ‘User’ verandert. Vervolgens wordt het tijdsverschil ertussen gemeten.
Voorbeelden
PT1H15MP2DT4HPT25M
|
|||
Activiteiten in de softwareontwikkelingscyclus
| Activiteit | Beschrijving | ||
|---|---|---|---|
|
CI-controles geslaagd
|
Dit betekent dat geautomatiseerde controles, zoals builds, unittests of statische analyses, op de code in een pull request succesvol zijn afgerond. Dit event wordt afgeleid uit de status van controles die systemen zoals GitHub Actions rapporteren. | ||
|
Waarom dit belangrijk is
Deze geautomatiseerde kwaliteitscontrole is belangrijk voor stabiele code. Mislukte controles of lange uitvoeringstijden kunnen bottlenecks in de opleveringspijplijn veroorzaken.
Waar vind je dit?
Dit wordt afgeleid uit de GitHub Checks API of Statuses API. Een check run of statusupdate meldt 'success' of 'completed' met de conclusie 'success'.
Vastleggen
Controleer de Checks API op de conclusie 'success' voor de relevante checksuites.
Gebeurtenistype
inferred
|
|||
|
Issue aangemaakt
|
Dit markeert het begin van de levenscyclus van een ontwikkelitem: een taak, bug of functieverzoek wordt formeel aangemaakt. Dit event wordt vastgelegd wanneer een gebruiker een nieuwe issue aanmaakt in een GitHub-repository. | ||
|
Waarom dit belangrijk is
Dit is de eerste activiteit in het proces. Je hebt deze nodig om de totale doorlooptijd van de ontwikkeling te meten en te zien waar het werk vandaan komt.
Waar vind je dit?
Dit is een expliciet event uit de eventstream van de GitHub Issues API. Het eventtype is voor een issue doorgaans 'opened'.
Vastleggen
Luister via webhooks of API-polling naar het event 'opened' van een issue.
Gebeurtenistype
explicit
|
|||
|
Issue gesloten
|
Het ontwikkelitem is afgerond en de bijbehorende issue wordt formeel gesloten. Dit kan automatisch gebeuren wanneer een gekoppelde pull request wordt samengevoegd, of handmatig door een teamlid. | ||
|
Waarom dit belangrijk is
Deze activiteit markeert het definitieve einde van het proces voor een ontwikkelitem. Je hebt dit event nodig om de totale doorlooptijd te berekenen.
Waar vind je dit?
Dit is een expliciet event uit de eventstream van de GitHub Issues API. Het eventtype is 'closed'.
Vastleggen
Luister via webhooks of API-polling naar het event 'closed' van een issue.
Gebeurtenistype
explicit
|
|||
|
Pull request geopend
|
Dit betekent dat de eerste code klaar is voor beoordeling en integratie. Een ontwikkelaar maakt een pull request (PR) aan om wijzigingen vanuit een feature-branch voor te stellen voor een hoofdbranch. Dit is een expliciet event in GitHub. | ||
|
Waarom dit belangrijk is
Dit is een belangrijke mijlpaal: de eerste ontwikkelfase is afgerond en de beoordeling en integratie beginnen. Doorlooptijden voor ontwikkeling en beoordeling kun je hiermee afzonderlijk analyseren.
Waar vind je dit?
Dit event wordt vastgelegd via de eventstream van de GitHub Pull Request API of via webhooks. De eventactie is 'opened'.
Vastleggen
Luister via webhooks of API-polling naar de actie 'opened' van een pull request.
Gebeurtenistype
explicit
|
|||
|
Pull request goedgekeurd
|
Een reviewer heeft de wijzigingen in een pull request formeel goedgekeurd. Dat betekent dat ze voldoen aan de kwaliteits- en functionele eisen. Dit wordt vastgelegd wanneer een reviewer de beoordeling indient met de status 'approve'. | ||
|
Waarom dit belangrijk is
Dit is een belangrijke kwaliteitscontrole en een grote mijlpaal vóór het samenvoegen. De tijd vanaf het aanmaken van de PR tot deze status is een belangrijke KPI voor de efficiëntie van het beoordelingsproces.
Waar vind je dit?
Dit event wordt vastgelegd via de GitHub Pull Request API of webhooks wanneer een beoordeling wordt ingediend met de status 'APPROVED'.
Vastleggen
Filter ingediende beoordelingen van pull requests op de status 'APPROVED'.
Gebeurtenistype
explicit
|
|||
|
Pull request samengevoegd
|
De goedgekeurde codewijzigingen uit de pull request zijn officieel opgenomen in de doelbranch, zoals main of develop. Dit is de expliciete laatste actie van een pull request waarmee de nieuwe code wordt toegevoegd. | ||
|
Waarom dit belangrijk is
Dit is een belangrijke mijlpaal die de afronding van de ontwikkeling en beoordeling markeert. Voor veel teams is dit de laatste stap vóór een geautomatiseerde implementatie.
Waar vind je dit?
Dit event wordt vastgelegd via de eventstream van de GitHub Pull Request API of via webhooks. De eventactie is 'closed' en het attribuut 'merged' in de payload van de pull request is true.
Vastleggen
Luister naar de actie 'closed' van een pull request en controleer of de vlag 'merged' op true staat.
Gebeurtenistype
explicit
|
|||
|
Beoordeling aangevraagd
|
De auteur van een pull request vraagt formeel aan specifieke teamleden of teams om de code te beoordelen. Deze actie in de GitHub-interface of API verstuurt meldingen naar de aangewezen reviewers. | ||
|
Waarom dit belangrijk is
Deze activiteit markeert de officiële overdracht aan het codebeoordelingsproces. De tijd tot een beoordeling wordt ingediend, laat zien hoe snel reviewers reageren en waar mogelijke bottlenecks zitten.
Waar vind je dit?
Dit event wordt vastgelegd via de eventstream van de GitHub Pull Request API of via webhooks. De eventactie is 'review_requested'.
Vastleggen
Luister naar de actie 'review_requested' van een pull request.
Gebeurtenistype
explicit
|
|||
|
Branch aangemaakt
|
Dit markeert het begin van actief ontwikkelwerk aan een issue. Een ontwikkelaar maakt hiervoor een nieuwe branch aan op basis van de hoofdcodebase. Dit expliciete event wordt vastgelegd wanneer een nieuwe branch naar de repository wordt gepusht. De naam bevat vaak het issuenummer. | ||
|
Waarom dit belangrijk is
Dit markeert de overgang van plannen naar actief programmeren. Door de tijd tussen het aanmaken van de issue en dit event te meten, zie je hoelang het duurt voordat een ontwikkelaar ermee aan de slag gaat en of er vertraging ontstaat in de backlog.
Waar vind je dit?
Dit event wordt vastgelegd via de GitHub Git API of webhooks die luisteren naar 'create'-events van het type 'branch'. Vaak moet je de branchnaam op basis van naamgevingsconventies, zoals 'feature/issue-123', aan een issue koppelen.
Vastleggen
Verwerk webhook-events van het type 'create' voor nieuwe branches en koppel ze aan een issue.
Gebeurtenistype
explicit
|
|||
|
CI-controles mislukt
|
Dit betekent dat een geautomatiseerde controle, zoals een build of unittest, op de code in een pull request is mislukt. Dit wordt afgeleid uit een foutstatus die een systeem zoals GitHub Actions rapporteert. | ||
|
Waarom dit belangrijk is
Deze activiteit wijst op technische kwaliteitsproblemen waarvoor een ontwikkelaar moet ingrijpen en die herstelwerk veroorzaken. Analyse van hoe vaak controles mislukken, kan helpen om lokaal testen of de codekwaliteit te verbeteren.
Waar vind je dit?
Dit wordt afgeleid uit de GitHub Checks API of Statuses API. Een check run of statusupdate meldt 'failure' of 'completed' met de conclusie 'failure'.
Vastleggen
Controleer de Checks API op de conclusie 'failure' voor de relevante checksuites.
Gebeurtenistype
inferred
|
|||
|
Code naar PR gepusht
|
Dit is een update van code die ter beoordeling is ingediend, als onderdeel van de eerste PR of naar aanleiding van feedback. Dit event wordt vastgelegd telkens wanneer een nieuwe commit naar de branch van een open pull request wordt gepusht. | ||
|
Waarom dit belangrijk is
Door deze events bij te houden, kun je herstelwerklussen herkennen. Meerdere pushes na een beoordeling wijzen erop dat wijzigingen nodig waren en beïnvloeden de totale doorlooptijd.
Waar vind je dit?
Dit is een expliciet event in de tijdlijn van de pull request, vaak aangeduid als een toegevoegde commit. Je kunt het vastleggen via de webhook 'push' of door de commits bij een PR te volgen.
Vastleggen
Volg 'push'-events op een branch die bij een open pull request hoort.
Gebeurtenistype
explicit
|
|||
|
Implementatie geslaagd
|
De codewijzigingen zijn succesvol geïmplementeerd in een specifieke omgeving, zoals staging of productie. Dit event wordt doorgaans vastgelegd via de GitHub Deployments API, vaak nadat een GitHub Action na een samenvoeging is gestart. | ||
|
Waarom dit belangrijk is
Dit markeert de overgang van code in de repository naar een liveomgeving. Door dit bij te houden, kun je de totale doorlooptijd van idee tot productie meten.
Waar vind je dit?
Dit event wordt vastgelegd via de Deployments API. Een externe service of GitHub Action maakt een implementatie aan en werkt de status daarna bij naar 'success'.
Vastleggen
Volg via webhooks status-events van implementaties met de status 'success'.
Gebeurtenistype
inferred
|
|||
|
Issue heropend
|
Een eerder gesloten issue wordt opnieuw actief, meestal omdat de oplossing niet voldeed of er een regressie is gevonden. Dit expliciete event start de levenscyclus van het ontwikkelitem opnieuw. | ||
|
Waarom dit belangrijk is
Dit wijst op een aanzienlijke herstelwerklus, bijvoorbeeld doordat een defect in productie is terechtgekomen of de oplossing niet volledig was. Hoe vaak dit gebeurt, is een belangrijke maatstaf voor de algehele softwarekwaliteit.
Waar vind je dit?
Dit is een expliciet event uit de eventstream van de GitHub Issues API. Het eventtype is 'reopened'.
Vastleggen
Luister via webhooks of API-polling naar het event 'reopened' van een issue.
Gebeurtenistype
explicit
|
|||
|
Wijzigingen gevraagd bij beoordeling
|
Een reviewer heeft de code beoordeeld en vastgesteld dat er wijzigingen nodig zijn voordat de pull request kan worden goedgekeurd. De reviewer dient de beoordeling formeel in met de status 'request_changes'. | ||
|
Waarom dit belangrijk is
Dit event markeert expliciet een herstelwerklus. Door te analyseren hoe vaak dit gebeurt, kun je kwaliteitsproblemen, onduidelijke vereisten of behoefte aan training voor ontwikkelaars opsporen.
Waar vind je dit?
Dit event wordt vastgelegd via de GitHub Pull Request API of webhooks wanneer een beoordeling wordt ingediend met de status 'CHANGES_REQUESTED'.
Vastleggen
Filter ingediende beoordelingen van pull requests op de status 'CHANGES_REQUESTED'.
Gebeurtenistype
explicit
|
|||
Extractiegidsen
Klaar om aan de slag te gaan?
Gebruik deze template om je data voor te bereiden en de softwareontwikkelingscyclus te verbeteren. Spoor inefficiënties op en werk aan snellere, soepelere releases.
Verbeter je SDLC: spoor inefficiënties meteen op
Verkort de doorlooptijd met 30% en maak het ontwikkelproces in GitHub efficiënter.
Geen creditcard nodig. Binnen enkele minuten ingesteld.