Uw Software Development Lifecycle Data Template
Uw Software Development Lifecycle Data Template
- Aanbevolen attributen om vast te leggen
- Belangrijkste activiteiten om te volgen
- Richtlijnen voor data-extractie
Software Development Lifecycle attributes
| Naam | Omschrijving | ||
|---|---|---|---|
|
Activiteit
ActivityName
|
De naam van een specifieke event of task die plaatsvond binnen de software development lifecycle. | ||
|
Omschrijving
De Activity Name beschrijft een enkele stap in het development proces, zoals 'Issue Created', 'Code Pushed to PR', 'Pull Request Approved', of 'Deployment Succeeded'. Deze events vormen de sequentie van stappen die het end-to-end proces voor een development item vormen.\n\nDit attribute is fundamenteel voor process mining, omdat het wordt gebruikt om de process map te construeren. Het analyseren van de sequentie, frequentie en duur van deze activities onthult de werkelijke proces flow, identificeert common paths, belicht deviations en wijst bottlenecks aan.
Het belang
Dit attribute vormt de ruggengraat van de process map, waardoor de visualisatie en analyse van de sequentie van events in de development lifecycle mogelijk is.
Vindplaats
Afgeleid van het 'action' veld van webhook event payloads (bijv. 'opened', 'closed' voor een issue) of van het event type zelf (bijv. 'PushEvent', 'PullRequestReviewEvent').
Voorbeelden
Issue AangemaaktPull Request GeopendCode Gepusht naar PRReview AangevraagdPull Request Gemerged
|
|||
|
Development Item
DevelopmentItemId
|
De unique identifier voor een enkele unit van development werk, zoals een feature, bug fix of task. Dit dient als de primaire case identifier. | ||
|
Omschrijving
De Development Item ID volgt een work item van de creatie tot de uiteindelijke deployment. Het koppelt alle geassocieerde activities, zoals branch creation, commits, pull requests, reviews en deployments, in één enkele, coherente process instance.\n\nIn analyse wordt deze ID gebruikt om de end-to-end cycle time van een development task te berekenen. Het maakt de reconstructie mogelijk van de gehele journey van een feature of bug fix, waardoor gedetailleerde analyse van bottlenecks, rework loops en procesvariaties voor individuele work items mogelijk is.
Het belang
Het is de essentiële sleutel voor process mining, die alle gerelateerde ontwikkelings-events in één enkele case verbindt om de end-to-end softwareontwikkelings-lifecycle nauwkeurig te visualiseren en te analyseren.
Vindplaats
Dit is doorgaans het Issue Number of Pull Request Number van GitHub. Het kan worden geëxtraheerd uit het 'number' veld in de payload van issue- of pull request-gerelateerde webhook events of API responses.
Voorbeelden
101PR-2345TASK-812
|
|||
|
Starttijd
EventTimestamp
|
De exacte datum en tijd waarop een specifieke development activity of event plaatsvond. | ||
|
Omschrijving
Deze timestamp markeert het begin van een activity. Het is cruciaal voor het chronologisch ordenen van events om de process flow voor elk development item te reconstrueren. De sequentie en het tijdsverschil tussen deze timestamps worden gebruikt om procesperformance te analyseren.\n\nIn analyse is dit attribute essentieel voor het berekenen van alle tijdgebaseerde metrics, inclusief cycle times, processing times en waiting times. Het maakt de identificatie van vertragingen tussen stappen mogelijk en levert de data die nodig is voor bottleneck analysis en performance monitoring dashboards.
Het belang
Deze timestamp is cruciaal voor het correct ordenen van events en het berekenen van alle performance metrics, zoals cycle times en bottleneck durations.
Vindplaats
Doorgaans te vinden als 'created_at' of 'updated_at' fields in de JSON payloads van GitHub APIs en webhooks voor verschillende objects zoals 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 specifieke development activity of event werd voltooid. | ||
|
Omschrijving
De end timestamp markeert de voltooiing van een activity. Hoewel veel events in GitHub direct zijn (bijv. 'Issue Created'), hebben sommige activities een meetbare duur (bijv. een CI check die draait). Het verschil tussen de End Time en Start Time levert de processing time voor een activity op.\n\nDit attribute wordt gebruikt om de 'ProcessingTime' metric te berekenen, wat essentieel is voor het begrijpen hoeveel actieve inspanning wordt besteed aan verschillende tasks zoals code reviews of automated checks. Het analyseren van processing times helpt inefficiënte activities te identificeren die te veel tijd in beslag nemen.
Het belang
Maakt de berekening van nauwkeurige verwerkingstijden voor activiteiten mogelijk, wat helpt onderscheid te maken tussen actieve werktijd en inactieve wachttijd.
Vindplaats
Kan worden gevonden als 'completed_at' in check run objecten of afgeleid van de timestamp van een volgende, logisch afsluitende event.
Voorbeelden
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
|
|||
|
Prioriteit
Priority
|
Het prioriteitsniveau toegewezen aan een development item, zoals 'High', 'Medium' of 'Low'. | ||
|
Omschrijving
Prioriteit geeft de urgentie of het zakelijk belang van een work item aan. In GitHub is prioriteit geen native veld en wordt het doorgaans beheerd met behulp van labels (bijv. 'P1-High', 'P2-Medium'). Een consistent labelingschema is vereist om deze informatie betrouwbaar te extraheren.\n\nDit attribute is essentieel voor 'Priority-Based Flow Analysis'. Het stelt analisten in staat om te verifiëren of high-priority items daadwerkelijk sneller worden verwerkt dan low-priority items en om de cycle time variance te meten op basis van prioriteit. Het helpt bij het evalueren van de effectiviteit van het prioriteringsproces.
Het belang
Maakt analyse mogelijk of high-priority items sneller worden verwerkt dan items met lagere prioriteit, wat de effectiviteit van de prioriteringsstrategie valideert.
Vindplaats
Afgeleid van GitHub labels die zijn toegepast op issues of pull requests. Het vereist een gestandaardiseerde conventie voor prioriteitslabels.
Voorbeelden
HoogGemiddeldLaagKritiek
|
|||
|
Repository
RepositoryName
|
De naam van de code repository waar de development activity plaatsvindt. | ||
|
Omschrijving
De repository fungeert als een project- of productidentifier, met daarin alle code, issues en pull requests voor een specifieke applicatie of component. Het biedt een manier om development processen te segmenteren en te vergelijken tussen verschillende producten of teams.\n\nIn analyse maakt dit attribute filtering en vergelijking van procesperformance over verschillende projecten mogelijk. Het helpt vragen te beantwoorden zoals 'Welk project heeft de langste cycle time?' of 'Hoe verhoudt het bug fix proces in Project A zich tot Project B?'. Het is essentieel voor het 'Throughput by Project and Type' dashboard.
Het belang
Maakt de segmentatie en vergelijking van ontwikkelingsprocessen over verschillende projecten, producten of teams mogelijk, wat een gerichtere analyse faciliteert.
Vindplaats
Beschikbaar in het 'repository' object in bijna alle GitHub webhook- en API-payloads. Het specifieke veld is meestal 'repository.full_name' of 'repository.name'.
Voorbeelden
my-org/web-appmy-org/api-servicemy-org/data-pipeline
|
|||
|
Toegewezen Gebruiker
Assignee
|
De gebruiker of developer die is toegewezen aan het development item of een specifieke task, zoals een pull request review. | ||
|
Omschrijving
Dit attribute identificeert de persoon die verantwoordelijk is voor het werk in een gegeven stage. Dit kan de assignee van een issue zijn, de author van een pull request, of de reviewer die is aangevraagd voor een code review. Het volgen van de assignee is essentieel voor het begrijpen van resource allocation en workload.\n\nDit attribute wordt gebruikt in analyse om de developer workload te monitoren, resource bottlenecks te identificeren en handoff efficiëntie tussen verschillende teamleden te analyseren. Dashboards kunnen worden gefilterd op assignee om individuele of team performance te beoordelen en een gebalanceerde distributie van werk te garanderen.
Het belang
Cruciaal voor het analyseren van de ontwikkelaarswerklast, teamprestaties en de efficiëntie van handoffs tussen verschillende teamleden.
Vindplaats
Beschikbaar in het 'assignee' of 'user' object binnen de JSON payloads voor issues, pull requests en review events van de GitHub API.
Voorbeelden
john.doejane.smithdev-team-lead
|
|||
|
Type Development Item
DevelopmentItemType
|
De classificatie van het development work item, zoals een feature, bug, task of epic. | ||
|
Omschrijving
Dit attribute categoriseert de aard van het uitgevoerde werk. Deze informatie wordt doorgaans beheerd via labels of specifieke issue templates binnen GitHub. Het begrijpen van het type werk is cruciaal voor het stellen van passende performance expectations, aangezien een bug fix een veel kortere verwachte cycle time kan hebben dan een nieuwe feature.\n\nDit attribute maakt comparative analysis tussen verschillende work types mogelijk. Het helpt te analyseren of bug fixes sneller worden verwerkt dan nieuwe features, of om de resource allocation voor technical debt versus new development te begrijpen. Het is een belangrijke dimensie in het 'Throughput by Project and Type' dashboard.
Het belang
Categoriseert werkitems, maakt prestatievergelijkingen en analyse mogelijk van hoe verschillende soorten werk (bijv. bugs versus features) door het proces stromen.
Vindplaats
Doorgaans afgeleid van GitHub labels die zijn toegepast op issues of pull requests. Vereist een consistente labeling convention (bijv. 'type:bug', 'type:feature').
Voorbeelden
BugFeatureTaskTechnical Debt
|
|||
|
Auteur
Author
|
De gebruiker die de issue, pull request of commit heeft aangemaakt. | ||
|
Omschrijving
De author is de initiator van een specifiek artifact in het development proces. Bijvoorbeeld, de author van een issue is de persoon die de bug rapporteerde of de feature aanvroeg. De author van een pull request is de developer die de code schreef.\n\nIn analyse kan de author worden gebruikt om de bronnen van werk te begrijpen. Bijvoorbeeld, het analyseren van de authors van bug reports kan patronen onthullen die verband houden met specifieke teams of features. Het kan ook worden gebruikt in combinatie met de assignee om handoff patronen te analyseren.
Het belang
Identificeert de initiator van een werkitem of codewijziging, wat nuttig kan zijn voor het analyseren van de bronnen van herwerk, bugrapporten of feature requests.
Vindplaats
Beschikbaar in het 'user' object binnen het hoofdobject van API-responses voor issues, pull requests en commits. Het veld is typisch 'user.login'.
Voorbeelden
sara.jonesmike.leeautomation-bot
|
|||
|
Beoordelaar
Reviewer
|
De gebruiker die is gevraagd om een code review uit te voeren op een pull request. | ||
|
Omschrijving
Een reviewer is een ontwikkelaar of teamlid dat is toegewezen om codewijzigingen in een pull request te inspecteren op kwaliteit, correctheid en naleving van standaarden. Een pull request kan meerdere reviewers hebben. Dit attribuut is essentieel voor het analyseren van het code review proces. Het helpt bij het identificeren van bottlenecks gerelateerd aan specifieke reviewers, het begrijpen van de verdeling van review-werklast, en het meten van de tijd die reviewers nodig hebben om te reageren op verzoeken. Het is een belangrijk onderdeel voor het berekenen van de 'Average Code Review Cycle Time' KPI.
Het belang
Identificeert de personen die betrokken zijn bij het kwaliteitsborgingsproces, wat analyse mogelijk maakt van review-werklast, vertragingen en de algehele efficiëntie van code reviews.
Vindplaats
Beschikbaar in de 'requested_reviewers' array of het 'user' object van een pull request review event van de GitHub API.
Voorbeelden
alex.chenmaria.garciasenior-dev-team
|
|||
|
Beoordelingsstatus
ReviewState
|
De uitkomst van een code review op een pull request, zoals 'Approved' of 'Changes Requested'. | ||
|
Omschrijving
Dit attribute legt de beslissing vast die door een reviewer is genomen. Veelvoorkomende statussen zijn onder andere 'APPROVED', wat aangeeft dat de code klaar is om te mergen, en 'CHANGES_REQUESTED', wat aangeeft dat rework nodig is. Andere statussen kunnen 'COMMENTED' of 'PENDING' zijn.\n\nDit is een kritiek attribute voor het analyseren van rework en quality. Een hoge frequentie van 'CHANGES_REQUESTED' events kan duiden op issues met de initiële code quality of onduidelijke requirements. Het ondersteunt direct het 'Rework and Regression Loops' dashboard door te identificeren wanneer een development item wordt teruggestuurd voor modificatie.
Het belang
Geeft direct herwerk-loops en kwaliteitspoorten binnen het code review proces aan, wat helpt bij het opsporen van bronnen van inefficiëntie en kwaliteitsproblemen.
Vindplaats
Beschikbaar als het 'state' veld binnen een pull request review object van de GitHub API. Bijvoorbeeld, in een 'PullRequestReviewEvent' payload.
Voorbeelden
APPROVEDCHANGES_REQUESTEDCOMMENTED
|
|||
|
Bewerkingstijd
ProcessingTime
|
De berekende duur van een activity, die de actieve werktijd vertegenwoordigt. | ||
|
Omschrijving
Processing Time is de verstreken tijd tussen het begin en einde van een activity. Het wordt berekend als 'EndTimestamp' min 'EventTimestamp'. Deze metric meet hoe lang het duurt om een task te voltooien, exclusief de tijd die is besteed aan het wachten tot de task begint.\n\nHet analyseren van processing time helpt om te identificeren welke activities het meest tijdrovend zijn qua actieve inspanning. Dit verschilt van cycle time, die wachttijd omvat. Een code review kan bijvoorbeeld een lange cycle time hebben, maar een korte processing time, wat aangeeft dat de reviewer bezig is en de PR in een queue wacht.
Het belang
Meet de actieve werkduur, helpt onderscheid te maken tussen de tijd besteed aan een task en de tijd besteed aan het wachten erop, wat cruciaal is voor gerichte efficiëntieverbeteringen.
Vindplaats
Berekend door de 'EventTimestamp' af te trekken van de 'EndTimestamp' voor één activiteitsrecord.
Voorbeelden
PT5M15SPT2H30MP1DT12H
|
|||
|
Branch Naam
BranchName
|
De naam van de Git branch waar de code changes voor het development item werden gemaakt. | ||
|
Omschrijving
Een branch is een onafhankelijke ontwikkelingslijn, gecreëerd om aan een nieuwe feature of bug fix te werken zonder de hoofdcodebasis te beïnvloeden. De branchename bevat vaak nuttige informatie, zoals het issue nummer of een korte beschrijving van het werk. Het analyseren van branchenames kan helpen bij het begrijpen van branching-strategieën en het naleven van ontwikkelconventies. Het helpt ook bij het koppelen van specifieke code commits aan een development item, wat een compleet beeld geeft van de codeeractiviteit.
Het belang
Biedt context over de specifieke development lijn en helpt bij het afdwingen en analyseren van branching strategies en naming conventions.
Vindplaats
Beschikbaar in het 'ref' veld voor push events, of in de 'head' en 'base' objecten binnen een pull request API-response.
Voorbeelden
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
|
|||
|
Bronsysteem
SourceSystem
|
Het systeem waaruit de development process data is geëxtraheerd. | ||
|
Omschrijving
Dit attribute identificeert de oorsprong van de event data. Voor dit proces zou de waarde consistent 'GitHub' zijn. In een complexere environment waar development activities meerdere systemen omvatten (bijv. Jira voor planning, GitHub voor code, Jenkins voor deployment), wordt dit veld gebruikt om de bron van elke event te onderscheiden.\n\nIn analyse helpt het bij het traceren van data terug naar de oorsprong voor validatie en troubleshooting. Het maakt ook het analyseren van processen mogelijk die verschillende platforms overspannen, wat een duidelijke context biedt voor elke activity.
Het belang
Identificeert de oorsprong van de data, wat essentieel is voor data validatie en voor het analyseren van processen die meerdere geïntegreerde systemen kunnen omvatten.
Vindplaats
Dit is doorgaans een static value die wordt toegevoegd tijdens het data extraction, transformation, and loading (ETL) proces om de bron van de records te labelen.
Voorbeelden
GitHubGitHub Enterprise
|
|||
|
CI Check Status
CiCheckStatus
|
De status van een geautomatiseerde Continuous Integration (CI) check, zoals 'passed' of 'failed'. | ||
|
Omschrijving
Dit attribute reflecteert de uitkomst van automated builds, tests en scans die worden uitgevoerd op code changes in een pull request. CI checks zijn een kritieke quality gate in moderne development workflows.\n\nHet analyseren van dit attribute helpt om de effectiviteit van geautomatiseerd testen te begrijpen. Een hoge failure rate kan duiden op problemen met code stability, de testing suite of de development environment. Het ondersteunt de 'CI Checks Passed' en 'CI Checks Failed' activities en helpt bij het analyseren van vertragingen veroorzaakt door broken builds.
Het belang
Geeft het succes of falen aan van geautomatiseerde kwaliteitspoorten, en biedt inzicht in codekwaliteit en de effectiviteit van de CI pipeline.
Vindplaats
Verkregen uit het 'state' of 'conclusion' veld van check run of status objects via de GitHub Checks of Statuses API.
Voorbeelden
successfailurependingerror
|
|||
|
Commit Hash
CommitHash
|
De unique identifier (SHA) voor een specifieke code commit. | ||
|
Omschrijving
Een commit hash is een 40-karakter SHA-1 hash die een commit in Git uniek identificeert. Het fungeert als een permanente ID voor een specifieke versie van de code. Commits zijn de atomaire eenheden van verandering in het ontwikkelproces. Hoewel zeer gedetailleerd, biedt de commit hash het ultieme niveau van traceerbaarheid. Het stelt analisten in staat om een proces-event direct te koppelen aan de exacte codewijziging die is aangebracht. Dit kan van onschatbare waarde zijn voor auditing, compliance, of gedetailleerde oorzaakanalyse van productie-incidenten.
Het belang
Biedt de meest granulaire link tussen een processtap en de exacte code change, wat volledige traceability voor audits en debugging mogelijk maakt.
Vindplaats
Beschikbaar in push event payloads ('head_commit.id') of via de Commits API voor een pull request of branch.
Voorbeelden
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
|
|||
|
Deployment Environment
DeploymentEnvironment
|
De target environment voor een deployment, zoals 'Staging' of 'Production'. | ||
|
Omschrijving
Dit attribute specificeert waar de code wordt gedeployed. Het volgen van deployments naar verschillende environments is essentieel voor het begrijpen van de volledige lifecycle, van development tot production release.\n\nDit attribute maakt analyse van het deployment sub-process mogelijk. Het kan worden gebruikt om de tijd te meten die nodig is om code van staging naar production te promoten en om de success rate van deployments naar verschillende environments te volgen. Het is essentieel voor het weten wanneer een development item echt 'done' is en is geleverd aan gebruikers.
Het belang
Maakt onderscheid tussen pre-productie en productiereleases, wat cruciaal is voor het meten van de werkelijke 'time-to-market' en het analyseren van deployment patronen.
Vindplaats
Deze informatie wordt opgehaald via de GitHub Deployments API, die vaak wordt getriggerd door CI/CD pipelines of andere automation.
Voorbeelden
developmentstagingproduction
|
|||
|
Handoff Wachttijd
HandoffWaitingTime
|
De berekende wachttijd die een development item doorbrengt tussen activities uitgevoerd door verschillende personen. | ||
|
Omschrijving
Deze metric meet de tijd tussen de voltooiing van de ene activity en de start van de volgende, maar alleen wanneer de verantwoordelijke persoon verandert. Bijvoorbeeld, de tijd tussen een 'Review Requested' event en een 'Changes Requested in Review' event door een andere gebruiker.\n\nDit is een kritieke metric voor het identificeren van communicatiekloven en coördinatieproblemen. Het ondersteunt het 'Critical Handoff Efficiency' dashboard en de 'Average Handoff Waiting Time' KPI. Hoge wachttijden bij handoff punten zijn vaak een teken van resource constraints of inefficiënte notification processes.
Het belang
Lokaliseert vertragingen veroorzaakt door slechte coördinatie of onbeschikbaarheid van resources tijdens handoffs tussen verschillende teams of rollen, die vaak belangrijke bronnen van inefficiëntie zijn.
Vindplaats
Berekend door sequentiële activiteiten te identificeren waarbij het attribuut 'Assignee' of 'User' verandert, en vervolgens de tijdsspanne daartussen te meten.
Voorbeelden
PT1H15MP2DT4HPT25M
|
|||
|
Is herstelwerk
IsRework
|
Een booleaanse vlag die aangeeft dat een activiteit een regressie naar een vorige procesfase betreft. | ||
|
Omschrijving
Deze flag wordt op true gezet wanneer een development item achteruitgaat in het proces, bijvoorbeeld wanneer een pull request een 'Changes Requested' review ontvangt, of wanneer een issue wordt heropend nadat deze is gesloten. Het wordt afgeleid door de sequentie van activities te analyseren.\n\nDit attribute is essentieel voor het kwantificeren van verspilling en inefficiëntie. Het ondersteunt direct het 'Rework and Regression Loops' dashboard en de 'Rework Rate' KPI. Door te filteren op 'IsRework = true', kunnen analisten de oorzaken van rework isoleren en onderzoeken.
Het belang
Vlagt expliciet activiteiten die herwerk vormen, waardoor het eenvoudig wordt om de oorzaken van procesinefficiënties te kwantificeren, visualiseren en analyseren.
Vindplaats
Dit is een derived attribute. De logica omvat het definiëren van een standaard process flow en vervolgens het markeren van elke activity die afwijkt door terug te keren naar een eerdere logische stage.
Voorbeelden
truefalse
|
|||
|
Item Status
State
|
De huidige status van een issue of pull request, zoals 'open', 'closed' of 'merged'. | ||
|
Omschrijving
Dit attribute geeft de high-level status van een development item aan. Voor issues zijn de typische statussen 'open' en 'closed'. Voor pull requests omvatten statussen 'open', 'closed' en 'merged'. Dit geeft een snapshot van de voortgang van het item.\n\nIn analyse wordt de state gebruikt om actief versus voltooid werk te identificeren. Het is essentieel voor dashboards zoals 'Active Development Progress' die doorlopend werk monitoren. Het wordt ook gebruikt om het einde van een proces te definiëren, bijvoorbeeld een state van 'merged' of 'closed' kan de voltooiing van een case betekenen.
Het belang
Geeft een duidelijke indicatie of een work item momenteel in uitvoering of voltooid is, wat fundamenteel is voor lifecycle analyse en het monitoren van actief werk.
Vindplaats
Direct beschikbaar als het 'state' veld in de JSON payloads voor issues en pull requests van de GitHub API.
Voorbeelden
openclosedmerged
|
|||
|
Laatste data-update
LastDataUpdate
|
De tijdstempel die aangeeft wanneer de gegevens voor dit record het laatst zijn ververst vanuit het bronsysteem. | ||
|
Omschrijving
Dit attribute registreert de datum en tijd van de meest recente data extractie of update. Het biedt metadata over de versheid van de geanalyseerde data. Dit is onderscheidend van de event timestamp, die vastlegt wanneer de business event plaatsvond.\n\nIn analyse is dit veld cruciaal voor het begrijpen van de actualiteit van de procesweergave. Het helpt gebruikers te weten of ze naar real-time data kijken of een snapshot van een specifiek tijdstip, wat belangrijk is voor operational dashboards en monitoring.
Het belang
Geeft de actualiteit van de data aan, wat cruciaal is om ervoor te zorgen dat analyses en dashboards gebaseerd zijn op actuele informatie.
Vindplaats
Deze
Voorbeelden
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Labels
Labels
|
Een lijst met tags of labels die zijn toegepast op een issue of pull request voor categorisatie. | ||
|
Omschrijving
Labels in GitHub zijn een flexibele manier om metadata toe te voegen aan issues en pull requests. Ze kunnen worden gebruikt om prioriteit, werktype, componenten, teams of status aan te duiden. De onbewerkte lijst met labels biedt een rijke, ongestructureerde context. Hoewel specifieke attributen zoals Priority en Type zijn afgeleid van labels, kan het behouden van de volledige lijst nuttig zijn voor ad-hoc analyse en het ontdekken van andere procespatronen. Het maakt flexibele filtering en segmentatie van cases mogelijk op basis van elke combinatie van labels.
Het belang
Biedt een flexibele, rijke bron van metadata voor het categoriseren van work items, wat diepe en gevarieerde dimensional analysis mogelijk maakt.
Vindplaats
Beschikbaar als de 'labels' array in de JSON payload voor issues en pull requests van de GitHub API. Elk item in de array is een object met een 'name' veld.
Voorbeelden
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
|
|||
|
Ontwikkelingsdoorlooptijd
DevelopmentCycleTime
|
De totale verstreken tijd vanaf de creatie van een development item tot de uiteindelijke deployment of sluiting. | ||
|
Omschrijving
Dit is een case-level metric, berekend als het tijdsverschil tussen de allereerste event (bijv. 'Issue Created') en de finale event (bijv. 'Deployment Succeeded' of 'Issue Closed') voor een enkel development item.\n\nDit is een van de belangrijkste KPIs voor het meten van de algehele efficiëntie van het development proces. Het ondersteunt direct het 'Overall Development Cycle Time' dashboard en de 'Average Development Cycle Time' KPI. Het verminderen van deze metric is vaak een primair doel van process improvement initiatieven.
Het belang
Vertegenwoordigt de end-to-end 'time-to-market' voor een development item, waardoor het een kritieke KPI is voor het meten van de algehele procesnelheid en efficiëntie.
Vindplaats
Berekend op casusniveau door de timestamp van de eerste activiteit af te trekken van de timestamp van de laatste activiteit.
Voorbeelden
P5DT6H30MP14DT12HP1DT2H
|
|||
|
Pull Request Number
PullRequestNumber
|
De unique identifier voor een pull request geassocieerd met het development item. | ||
|
Omschrijving
Een pull request (PR) is een voorstel om een reeks codewijzigingen samen te voegen tot een specifieke branch. Het Pull Request Nummer koppelt ontwikkelactiviteiten, zoals code pushes en reviews, terug aan het primaire development item of issue. Deze ID is cruciaal voor het volgen van de code-integratie en het review-subproces binnen de bredere ontwikkelingslifecycle. Het maakt gedetailleerde analyse van het code review proces mogelijk, inclusief reviewtijden, herwerk-cycli geïdentificeerd tijdens de review, en merge-percentages. Het verbindt de planningsfase (issue) met de implementatiefase (PR).
Het belang
Koppelt issues aan de specifieke codewijzigingen en reviewprocessen, wat een gedetailleerde analyse van de code review cyclus en de impact ervan op de totale levertijd mogelijk maakt.
Vindplaats
Beschikbaar als het 'number' veld binnen het 'pull_request' object in veel GitHub API-responses, of als de hoofd-identifier van de Pull Requests API.
Voorbeelden
12345678910
|
|||
Software Development Lifecycle activiteiten
| Activiteit | Omschrijving | ||
|---|---|---|---|
|
CI Checks Geslaagd
|
Vertegenwoordigt de succesvolle voltooiing van geautomatiseerde checks, zoals builds, unit tests of static analysis, uitgevoerd op de code in een pull request. Deze event wordt afgeleid uit de status van checks gerapporteerd door systemen zoals GitHub Actions. | ||
|
Het belang
Deze automated quality gate is cruciaal voor het garanderen van code stability. Failures of lange run times kunnen aanzienlijke bottlenecks zijn in de delivery pipeline.
Vindplaats
Afgeleid van de GitHub Checks API of Statuses API. Een check run of status update rapporteert een 'success' of 'completed' met een 'success' conclusie.
Vastleggen
Monitor de Checks API op een 'success' conclusie van de relevante check suites.
Gebeurtenistype
inferred
|
|||
|
Issue Aangemaakt
|
Markeert het begin van de lifecycle van een development item, wat staat voor de formele creatie van een task, bug of feature request. Deze event wordt expliciet vastgelegd wanneer een gebruiker een nieuwe issue aanmaakt in een GitHub repository. | ||
|
Het belang
Dit is de primaire start activity voor het proces, essentieel voor het meten van de totale development cycle time en het begrijpen van de initiële bronnen van werk.
Vindplaats
Dit is een expliciete event vastgelegd vanuit de GitHub Issues API event stream. De event type is doorgaans 'opened' voor een gegeven issue nummer.
Vastleggen
Luister naar de 'opened' event op een issue via webhooks of API polling.
Gebeurtenistype
explicit
|
|||
|
Probleem afgesloten
|
Het development item wordt als voltooid beschouwd en de corresponderende issue wordt formeel gesloten. Dit kan automatisch gebeuren wanneer een gelinkte pull request wordt gemerged of handmatig worden uitgevoerd door een teamlid. | ||
|
Het belang
Deze activity dient als het definitieve einde van het proces voor een development item. Het is cruciaal voor het berekenen van end-to-end cycle times.
Vindplaats
Dit is een expliciete event vastgelegd vanuit de GitHub Issues API event stream. De event type is 'closed'.
Vastleggen
Luister naar de 'closed' event op een issue via webhooks of API polling.
Gebeurtenistype
explicit
|
|||
|
Pull Request Gemerged
|
De goedgekeurde code changes van de pull request worden officieel geïntegreerd in de target branch, zoals main of develop. Dit is een expliciete, finale actie op een pull request die de nieuwe code incorporeert. | ||
|
Het belang
Dit is een kritieke milestone die de voltooiing van development en review vertegenwoordigt. Voor veel teams is dit de laatste stap voor automated deployment.
Vindplaats
Vastgelegd vanuit de GitHub Pull Request API event stream of webhooks. De event action is 'closed' en het 'merged' attribuut van de pull request payload is 'true'.
Vastleggen
Luister naar de 'closed' actie op een pull request en controleer of de 'merged' flag true is.
Gebeurtenistype
explicit
|
|||
|
Pull Request Geopend
|
Geeft aan dat een eerste blok code klaar is voor review en integratie. Een developer creëert een pull request (PR) om wijzigingen voor te stellen van hun feature branch naar een main branch. Dit is een expliciete event in GitHub. | ||
|
Het belang
Dit is een kritieke milestone die het einde van de initiële development fase en het begin van de review- en integration pipeline markeert. Het is essentieel voor het afzonderlijk analyseren van development en review cycle times.
Vindplaats
Vastgelegd vanuit de GitHub Pull Request API event stream of webhooks. De event action is 'opened'.
Vastleggen
Luister naar de 'opened' actie voor een pull request via webhooks of API polling.
Gebeurtenistype
explicit
|
|||
|
Pull Request Goedgekeurd
|
Een reviewer heeft de wijzigingen in een pull request formeel goedgekeurd, wat aangeeft dat deze voldoen aan kwaliteits- en functionele standaarden. Dit wordt vastgelegd wanneer een reviewer zijn review indient met een 'approve' status. | ||
|
Het belang
Dit is een belangrijke quality gate en een belangrijke milestone vóór merging. De tijd die nodig is om deze state te bereiken vanaf PR creation is een kritieke KPI voor review process efficiency.
Vindplaats
Vastgelegd vanuit de GitHub Pull Request API of webhooks wanneer een review wordt ingediend met de status 'APPROVED'.
Vastleggen
Filter pull request review indienings-events voor de status 'APPROVED'.
Gebeurtenistype
explicit
|
|||
|
Branch Gecreëerd
|
Vertegenwoordigt de start van actief development werk voor een issue, waarbij een developer een nieuwe branch aanmaakt vanuit de main codebase. Dit is een expliciete event die wordt vastgelegd wanneer een nieuwe branch naar de repository wordt gepusht, vaak met het issue nummer in de naam. | ||
|
Het belang
Geeft de overgang aan van planning naar actief coderen. Het meten van de tijd tussen het aanmaken van een issue en deze event helpt bij het analyseren van de 'developer pickup time' en initiële backlog-vertragingen.
Vindplaats
Vastgelegd via de GitHub Git API of webhooks die luisteren naar 'create' events van het type 'branch'. Het is vaak nodig om de branchename te koppelen aan een issue via naamgevingsconventies, zoals 'feature/issue-123'.
Vastleggen
Parseer 'create' webhook events voor nieuwe branches en koppel deze aan een issue.
Gebeurtenistype
explicit
|
|||
|
CI Checks Mislukt
|
Vertegenwoordigt het falen van een geautomatiseerde check, zoals een build error of mislukte unit test, uitgevoerd op de code in een pull request. Dit wordt afgeleid uit een failure status gerapporteerd door een systeem zoals GitHub Actions. | ||
|
Het belang
Deze activity belicht technische quality issues die developer interventie vereisen, waardoor een rework loop ontstaat. Het analyseren van de failure frequency kan verbeteringen in local testing of code quality sturen.
Vindplaats
Afgeleid van de GitHub Checks API of Statuses API. Een check run of status update rapporteert een 'failure' of 'completed' met een 'failure' conclusie.
Vastleggen
Monitor de Checks API op een 'failure' conclusie van de relevante check suites.
Gebeurtenistype
inferred
|
|||
|
Code Gepusht naar PR
|
Vertegenwoordigt een update van de code die ter review is ingediend, hetzij als onderdeel van de initiële PR of als reactie op review feedback. Deze event wordt vastgelegd telkens wanneer een nieuwe commit wordt gepusht naar de branch die geassocieerd is met een open pull request. | ||
|
Het belang
Het volgen van deze events is cruciaal voor het identificeren van rework loops. Meerdere pushes na een review geven aan dat er wijzigingen nodig waren, wat de algehele cycle time beïnvloedt.
Vindplaats
Dit is een expliciete event in de pull request timeline, vaak gelabeld als een commit die wordt toegevoegd. Het kan worden vastgelegd vanuit de 'push' webhook of door de commits te monitoren die zijn geassocieerd met een PR.
Vastleggen
Volg 'push' events op een branch die is geassocieerd met een open pull request.
Gebeurtenistype
explicit
|
|||
|
Deployment Geslaagd
|
De code changes zijn succesvol gedeployed naar een specifieke environment, zoals staging of production. Deze event wordt doorgaans vastgelegd via de GitHub Deployments API, vaak getriggerd door een GitHub Action na een merge. | ||
|
Het belang
Markeert de overgang van code van de repository naar een live omgeving. Het volgen hiervan is essentieel voor het meten van de totale lead time van idee tot productie.
Vindplaats
Vastgelegd via de Deployments API. Een externe service of GitHub Action creëert een deployment en update vervolgens de status naar 'success'.
Vastleggen
Monitor deployment status events via webhooks voor een status van 'success'.
Gebeurtenistype
inferred
|
|||
|
Issue Heropend
|
Een eerder gesloten issue wordt opnieuw geactiveerd, meestal omdat de oplossing onvoldoende was of er een regressie werd gevonden. Dit is een expliciete event die de lifecycle voor het development item opnieuw start. | ||
|
Het belang
Dit signaleert een significante rework loop, wat duidt op een potentiële 'production defect escape' of onvolledige fix. Het volgen van de frequentie ervan is een belangrijke maatstaf voor de algehele software quality.
Vindplaats
Dit is een expliciete event vastgelegd vanuit de GitHub Issues API event stream. De event type is 'reopened'.
Vastleggen
Luister naar de 'reopened' event op een issue via webhooks of API polling.
Gebeurtenistype
explicit
|
|||
|
Review Aangevraagd
|
De author van een pull request vraagt formeel specifieke teamleden of teams om hun code te reviewen. Dit is een expliciete actie binnen de GitHub UI of API die notifications triggert naar de aangevraagde reviewers. | ||
|
Het belang
Deze activity markeert de officiële start van de handoff naar het code review proces. De tijd tussen dit en een review submission helpt de responsiveness van de reviewer en potentiële bottlenecks te meten.
Vindplaats
Vastgelegd vanuit de GitHub Pull Request API event stream of webhooks. De event action is 'review_requested'.
Vastleggen
Luister naar de 'review_requested' actie voor een pull request.
Gebeurtenistype
explicit
|
|||
|
Wijzigingen Aangevraagd in Review
|
Een reviewer heeft hun code review voltooid en vastgesteld dat er aanpassingen nodig zijn voordat de pull request kan worden goedgekeurd. De reviewer dient formeel hun review in met de status 'request_changes'. | ||
|
Het belang
Deze event signaleert expliciet een rework loop. Het analyseren van de frequentie helpt bij het aanwijzen van quality issues, onduidelijke requirements of gebieden voor developer training.
Vindplaats
Vastgelegd vanuit de GitHub Pull Request API of webhooks wanneer een review wordt ingediend met de status 'CHANGES_REQUESTED'.
Vastleggen
Filter pull request review indienings-events voor de status 'CHANGES_REQUESTED'.
Gebeurtenistype
explicit
|
|||