Uw Software Development Lifecycle Data Template

Azure DevOps
Uw Software Development Lifecycle Data Template

Uw Software Development Lifecycle Data Template

Deze template biedt een duidelijke roadmap voor het voorbereiden van uw Software Development Lifecycle data voor process mining. Het schetst de essentiële data-attributen die u moet verzamelen, de belangrijkste activiteiten die u moet volgen, en biedt praktische leidraad over hoe u deze informatie specifiek uit Azure DevOps kunt extraheren. Maak gebruik van deze resource om ervoor te zorgen dat uw data perfect gestructureerd is voor inzichtelijke analyse en procesoptimalisatie.
  • Aanbevolen attributen om vast te leggen
  • Belangrijke activiteiten om te volgen voor uw SDLC
  • Gedetailleerde extractiehandleiding voor Azure DevOps
Nieuw met event logs? Leer hoe je een process mining event log creëert.

Attributen van de Software Development Lifecycle

Dit zijn de aanbevolen data velden om op te nemen in uw event log voor uitgebreide Software Development Lifecycle analyse en optimalisatie.
5 Verplicht 8 Aanbevolen 6 Optioneel
Naam Omschrijving
Activiteitsnaam
ActivityName
De naam van de specifieke event of taak die op een bepaald moment plaatsvond binnen de ontwikkelingslifecycle voor een werkitem.
Omschrijving

De Activiteitsnaam beschrijft een specifieke stap of mijlpaal in het proces, zoals 'Ontwikkeling Gestart', 'Pull Request Aangemaakt' of 'Geïmplementeerd naar Productie'. Deze activiteiten zijn afgeleid van veranderingen in de status van het werkitem, gekoppelde events zoals builds of pull requests, of aangepaste events.

Dit attribuut is essentieel voor het construeren van de proceskaart, die de workflow visueel weergeeft. Het stelt analisten in staat de reeks events te begrijpen, gemeenschappelijke paden te identificeren, knelpunten tussen specifieke activiteiten te ontdekken en de frequentie van elke stap te analyseren.

Het belang

Het definieert de stappen in het proces, vormt de ruggengraat van de proceskaart en maakt analyse van workflow, knelpunten en afwijkingen mogelijk.

Vindplaats

Dit wordt typisch afgeleid van veranderingen in het 'Status'-veld van een werkitem, of van gekoppelde events zoals builds, commits en pull requests. De Werkitem Geschiedenis levert de ruwe data voor deze events.

Voorbeelden
Ontwikkeling GestartPull Request VoltooidQA Testing MisluktGedeployed naar ProductieWerkitem Gesloten
Development Item
DevelopmentItem
De unieke identifier voor een enkele werkeenheid, zoals een feature, bug of user story, die dient als de case identifier voor het proces.
Omschrijving

Het Ontwikkelitem vertegenwoordigt een afzonderlijk stuk werk dat wordt gevolgd binnen Azure DevOps. Elk item, geïdentificeerd door zijn unieke ID, is het centrale object waaromheen alle procesactiviteiten draaien, van aanmaak en planning tot ontwikkeling, testen en implementatie.

In process mining analyse is dit attribuut fundamenteel voor het correleren van alle gerelateerde events tot één case journey. Het maakt de reconstructie van de end-to-end lifecycle voor elk werkitem mogelijk, wat analyse van doorlooptijden, procesafwijkingen en rework loops op individuele itembasis mogelijk maakt.

Het belang

Dit is de kernidentifier die alle processtappen verbindt tot een coherente case, waardoor end-to-end analyse van de softwareontwikkelingslifecycle mogelijk wordt.

Vindplaats

Dit komt overeen met het 'ID'-veld van een Werkitem in Azure DevOps Boards. Het is toegankelijk via de Azure DevOps REST API voor Work Item Tracking.

Voorbeelden
10234102351023610237
Tijdstip Gebeurtenis
EventTime
De precieze timestamp die aangeeft wanneer een specifieke activiteit of event plaatsvond voor een ontwikkelitem.
Omschrijving

Event Time legt de datum en tijd vast van elke activiteit in de development lifecycle. Deze timestamp is het fundamentele tijdelijke element dat wordt gebruikt om events chronologisch te ordenen en de duur ertussen te berekenen.

Bij analyse is dit attribute cruciaal voor het berekenen van alle tijdgebaseerde metrics, inclusief cycle times, processing times en waiting times. Het maakt de creatie mogelijk van een tijdgeordende event log, wat de vereiste input is voor elke process mining analyse. Het wordt gebruikt om vertragingen te diagnosticeren, prestaties te meten ten opzichte van SLA's en trends over tijd te volgen.

Het belang

Deze timestamp biedt de chronologische volgorde van events, wat essentieel is voor het berekenen van alle op duur gebaseerde KPI's en het begrijpen van de procesflow en knelpunten.

Vindplaats

Dit is de 'Gewijzigd Datum' gekoppeld aan elke update in de geschiedenis van een werkitem. Voor externe events zoals builds of implementaties, is het de voltooiing timestamp van die event.

Voorbeelden
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
Bronsysteem
SourceSystem
Het systeem waaruit de procesdata werd geëxtraheerd, wat in dit geval Azure DevOps is.
Omschrijving

Dit attribuut identificeert het bronsysteem voor de data. Het is bijzonder nuttig in omgevingen waar data uit meerdere systemen wordt gecombineerd voor een bredere procesweergave. Voor dit specifieke model is de waarde consistent Azure DevOps.

Hoewel het statisch kan lijken in een single-system analyse, biedt het essentiële context over de herkomst van de data, wat cruciaal is voor datagovernance, troubleshooting en toekomstige integraties met andere systemen zoals ServiceNow of SAP.

Het belang

Het biedt cruciale context over de herkomst van de data, wat belangrijk is voor datagovernance, validatie en multi-systeem procesanalyse.

Vindplaats

Dit is een statische waarde die moet worden toegevoegd tijdens het data extractie- en transformatieproces om de dataset te labelen.

Voorbeelden
Azure DevOps
Laatste data-update
LastDataUpdate
De `timestamp` die aangeeft wanneer de `data` voor dit proces voor het laatst is ververst vanuit het bronsysteem.
Omschrijving

Dit attribuut registreert wanneer de dataset voor het laatst is geëxtraheerd en bijgewerkt vanuit Azure DevOps. Het geeft een duidelijke indicatie van de actualiteit van de data en het tijdsbestek dat door de analyse wordt bestreken.

Bij elke procesanalyse is het kennen van de recentheid van de data cruciaal voor het nemen van weloverwogen beslissingen. Deze timestamp helpt gebruikers te begrijpen of ze naar real-time informatie kijken of een historische snapshot, wat de relevantie van de bevindingen beïnvloedt.

Het belang

Het informeert gebruikers over de actualiteit van de data, zodat analyses en beslissingen worden gebaseerd op een begrepen tijdsbestek.

Vindplaats

Dit is een metadata timestamp die wordt gegenereerd en opgeslagen tijdens het data extractie-, transformatie- en laadproces (ETL).

Voorbeelden
2024-05-20T08:00:00Z
Development Cycle Time
DevelopmentCycleTime
De totale verstreken tijd vanaf de aanmaak van een ontwikkelitem tot de implementatie ervan in productie.
Omschrijving

Development Cycle Time is een key performance indicator die de end-to-end duur van het ontwikkelproces voor een enkel work item meet. Het wordt berekend als het verschil tussen de timestamp van de activiteit 'Deployed to Production' en de activiteit 'Work Item Created'.

Deze berekende metric is de primaire KPI voor het End-to-End Development Cycle Time dashboard en de Historical Cycle Time Trends. Het biedt een holistische maatstaf voor proces snelheid en efficiëntie, en het volgen ervan over tijd toont de impact van procesverbeteringsinitiatieven.

Het belang

Dit is een kritieke KPI die de algehele snelheid en efficiëntie van het ontwikkelproces van begin tot eind meet.

Vindplaats

Dit wordt berekend door de timestamp van de uiteindelijke implementatie event te nemen en de timestamp van de aanmaak event voor elke case af te trekken.

Voorbeelden
10 dagen 4 uur 30 minuten25 dagen 8 uur 0 minuten5 dagen 2 uur 15 minuten
Eindtijd
EndTime
De timestamp die aangeeft wanneer een activiteit is voltooid. Het wordt gebruikt om de verwerkingstijd van een activiteit te berekenen.
Omschrijving

De Eindtijd markeert de conclusie van een activiteit. In veel event logs dient de starttijd van de volgende activiteit als de eindtijd van de vorige. Het hebben van een aparte eindtijd maakt echter een nauwkeurigere berekening mogelijk van zowel de verwerkingstijd van de activiteit als de wachttijd tussen activiteiten.

Dit attribuut is cruciaal voor het berekenen van de ProcessingTime KPI en voor het uitvoeren van gedetailleerde knelpuntanalyse. Het helpt onderscheid te maken tussen de tijd die actief aan een taak wordt gewerkt en de tijd die wordt gewacht op de volgende stap, wat essentieel is voor het Stage Handoff Analysis dashboard.

Het belang

Het maakt de precieze berekening van de verwerkingstijden en wachttijden van activiteiten mogelijk, wat fundamenteel is voor knelpuntanalyse en efficiëntieverbeteringen.

Vindplaats

Dit is vaak afgeleid. Het kan de starttijd zijn van de volgende event voor dezelfde case, of het kan expliciet worden vastgelegd als het bronsysteem zowel start- als eindtijden voor taken vastlegt.

Voorbeelden
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
Is herstelwerk
IsRework
Een boolean flag die aangeeft of een development item een eerdere fase in zijn lifecycle opnieuw is ingegaan.
Omschrijving

Deze flag is ingesteld op true als een werkitem een rework loop vertoont, bijvoorbeeld door te bewegen van 'QA Testing Voltooid' terug naar 'Ontwikkeling Gestart'. Het wordt berekend door de reeks activiteiten voor een case te analyseren en niet-lineaire progressies te detecteren.

Dit attribuut is essentieel voor het Rework en Retesting Frequentie dashboard en de Rework Loop Frequentie KPI. Het maakt eenvoudig filteren en kwantificeren van rework mogelijk, wat helpt bij het pinpointen van kwaliteitsproblemen, communicatiekloven of onvoldoende testen die leiden tot inefficiënties.

Het belang

Het identificeert en kwantificeert direct rework, wat helpt bij het blootleggen van kwaliteitsproblemen en procesinefficiënties die de doorlooptijden verlengen.

Vindplaats

Dit is een berekend attribuut, afgeleid door de reeks activiteiten in de event log voor elke case te analyseren.

Voorbeelden
truefalse
Prioriteit
Priority
Een numerieke of beschrijvende rangschikking van het belang van het development item ten opzichte van andere items.
Omschrijving

Prioriteit geeft de planningsrelevantie van een werkitem aan. Een hogere prioriteit suggereert dat een item sneller moet worden afgehandeld dan items met een lagere prioriteit. Gangbare waarden zijn numeriek, zoals 1, 2, 3, 4, waarbij 1 de hoogste is.

Dit attribuut is essentieel voor het Priority-Based Throughput & Cycle Time dashboard. Het analyseren van data met dit attribuut helpt bepalen of het prioriteringssysteem effectief is, wat betekent dat items met hoge prioriteit daadwerkelijk sneller door het proces bewegen dan items met lage prioriteit.

Het belang

Dit maakt analyse mogelijk van de effectiviteit waarmee het proces items met hoge prioriteit versnelt, wat cruciaal is voor het evalueren van het succes van prioriteringsstrategieën.

Vindplaats

Dit komt overeen met het 'Prioriteit'-veld op een Werkitem in Azure DevOps.

Voorbeelden
1234
Status
State
De huidige status van het ontwikkelitem binnen zijn workflow, zoals 'Nieuw', 'Actief', 'Opgelost' of 'Gesloten'.
Omschrijving

Het Status attribuut vertegenwoordigt de formele status van een werkitem op elk moment, zoals gedefinieerd door de proces template van het project. Transities tussen deze statussen zijn de primaire bron voor het genereren van de activiteiten in de event log.

Hoewel het 'Activiteit' attribuut vaak een meer beschrijvende versie is van een statuswijziging, is het ruwe 'Status' attribuut nuttig voor filtering en analyse. Het helpt bij het begrijpen hoeveel tijd items in specifieke statussen doorbrengen en is fundamenteel voor het bouwen van het Stage Duration dashboard en het analyseren van handoffs.

Het belang

Het geeft de status van het werkitem in de lifecycle aan, wat fundamenteel is voor het begrijpen van de processtroom en het berekenen van de tijd die in verschillende fasen wordt doorgebracht.

Vindplaats

Dit komt overeen met het 'Status'-veld op een Werkitem in Azure DevOps.

Voorbeelden
NieuwActiefIn QAResolvedGesloten
Teamnaam
TeamName
De naam van het ontwikkelteam dat verantwoordelijk is voor het werkitem.
Omschrijving

De Teamnaam identificeert het specifieke team waaraan een werkitem is toegewezen. In Azure DevOps wordt werk vaak georganiseerd door teams, die deelverzamelingen kunnen zijn van een groter project.

Dit attribuut maakt procesanalyse mogelijk om te worden gesegmenteerd per team. Het is van onschatbare waarde voor het vergelijken van processen en prestaties tussen verschillende teams, het identificeren van best practices in goed presterende teams, en het vinden van gebieden waar specifieke teams ondersteuning of procesverbeteringen nodig hebben.

Het belang

Het maakt vergelijkende analyse tussen verschillende teams mogelijk, wat helpt bij het identificeren van prestatieverschillen en het delen van best practices binnen de organisatie.

Vindplaats

Dit is vaak afgeleid van het 'Area Path' van een werkitem, aangezien teams typisch zijn toegewezen aan specifieke area paths in Azure DevOps.

Voorbeelden
Team PhoenixOmega SquadPlatform CoreFrontend Team
Toegewezen aan
AssignedTo
De gebruiker of het teamlid aan wie het ontwikkelitem momenteel is toegewezen.
Omschrijving

Dit attribuut identificeert de individuele verantwoordelijke voor het werkitem in een bepaalde fase van het proces. De toewijzing kan meerdere keren veranderen gedurende de lifecycle van het item, bijvoorbeeld van een ontwikkelaar naar een tester en vervolgens naar een release manager.

Analyseren op 'Toegewezen aan' is cruciaal voor het Dashboard 'Ontwikkelaars- en Tester Werkbelasting Overzicht'. Het helpt bij het begrijpen van resource-allocatie, het identificeren van overbelaste teamleden, en het analyseren van prestatieverschillen tussen individuen of teams.

Het belang

Het maakt resourcegebaseerde analyse mogelijk, wat helpt bij het begrijpen van de werkverdeling, het identificeren van resourcespecifieke knelpunten en het beheren van teamcapaciteit.

Vindplaats

Dit komt overeen met het 'Toegewezen aan'-veld op een Werkitem in Azure DevOps. De waarde wordt vastgelegd vanuit de werkitemgeschiedenis voor elke event.

Voorbeelden
jane.doe@example.comjohn.smith@example.comniet toegewezen
Werkitem Type
WorkItemType
De classificatie van het ontwikkelitem, zoals Bug, Feature, User Story of Taak.
Omschrijving

Het Werkitem Type categoriseert de aard van het uitgevoerde werk. Verschillende typen werkitems volgen vaak verschillende procespaden en hebben verschillende prestatieverwachtingen of SLA's. Zo kan een 'Bug' een versneld pad volgen vergeleken met een 'Feature'.

Dit attribuut is essentieel voor vergelijkende analyse. Het stelt u in staat de proceskaart of KPI's te filteren op het type werk om te begrijpen of bepaalde processen efficiënter zijn voor bugs versus features, of om historische doorlooptijd trends te volgen voor verschillende werkcategorieën.

Het belang

Het maakt segmentatie van de procesanalyse mogelijk, waardoor workflows en prestaties kunnen worden vergeleken voor verschillende werkcategorieën, zoals bugs en features.

Vindplaats

Dit komt overeen met het 'Werkitem Type'-veld op een Werkitem in Azure DevOps.

Voorbeelden
BugFeatureUser StoryTask
Ernst
Severity
Geeft de impact aan van een bug of issue op het systeem of eindgebruikers.
Omschrijving

Severity wordt gebruikt om de impact van een bug te classificeren, van kritieke systeemfouten tot kleine cosmetische problemen. Dit is anders dan prioriteit, die de werkvolgorde bepaalt. Een bug met hoge severity kan een lage prioriteit hebben als er een direct beschikbare workaround is.

Dit attribuut biedt een extra dimensie voor analyse, met name voor het Priority-Based Throughput & Cycle Time dashboard. Het maakt het mogelijk om vragen te onderzoeken zoals: 'Pakken we eerst de meest kritieke bugs aan?' en helpt bij het begrijpen van het risicoprofiel van het werk dat wordt verwerkt.

Het belang

Het helpt werkitems te categoriseren op basis van hun zakelijke impact, waardoor analyse mogelijk is van hoe effectief het team problemen met hoge impact aanpakt.

Vindplaats

Dit komt overeen met het 'Severity'-veld op een Werkitem, typisch voor bugs, in Azure DevOps.

Voorbeelden
1 - Kritiek2 - Hoog3 - Gemiddeld4 - Laag
Fase Overdrachtstijd
StageHandoffTime
De duur van de wachttijd tussen de voltooiing van de ene belangrijke fase en de start van de volgende.
Omschrijving

Fase Overdrachtstijd meet de wachttijd tussen opeenvolgende procesfasen, bijvoorbeeld de tijd tussen 'Ontwikkeling Voltooid' en 'QA Testing Gestart'. Het wordt berekend door deze belangrijke overgangen te identificeren en het tijdsverschil te meten tussen het einde van de eerste activiteit en het begin van de tweede.

Deze metric is de focus van het Stage Duration en Handoff Analysis dashboard. Het isoleren en meten van overdrachtstijd is cruciaal voor het identificeren van verborgen knelpunten waar werk stilstaat, vaak als gevolg van onbeschikbaarheid van resources, communicatievertragingen of inefficiënte processen.

Het belang

Het kwantificeert wachttijden tussen procesfasen, waardoor verborgen knelpunten en vertragingen die geen deel uitmaken van actief werk direct worden blootgelegd.

Vindplaats

Dit is een berekend attribuut. Het vereist het identificeren van paren van sequentiële activiteiten die een overdracht (handoff) vertegenwoordigen en vervolgens het berekenen van het tijdsverschil ertussen.

Voorbeelden
2 uur 15 minuten1 dag 4 uur0 uur 30 minuten
Iteratiepad
IterationPath
De ontwikkelingssprint of timebox waaraan het werkitem is toegewezen.
Omschrijving

Het Iteratiepad, of sprint, vertegenwoordigt een specifieke, tijdgebonden ontwikkelingsperiode. Werkitems worden toegewezen aan een iteratie om binnen dat tijdsbestek te worden voltooid.

Analyseren op Iteratiepad helpt bij het begrijpen van procesprestaties op een sprint-voor-sprint basis. Het kan worden gebruikt om te volgen of doorlooptijden verbeteren over opeenvolgende sprints, om carry-over werk te analyseren, en om de voorspelbaarheid van sprintplanning te evalueren.

Het belang

Het maakt sprintgebaseerde analyse mogelijk, waardoor teams hun prestaties over tijd kunnen evalueren en hun agile werkwijzen kunnen verbeteren.

Vindplaats

Dit komt overeen met het 'Iteratiepad'-veld op een Werkitem in Azure DevOps.

Voorbeelden
E-Commerce Platform\Sprint 12E-Commerce Platform\Sprint 13Relaunch Mobiele App\Fase 2\Sprint 4
Projectnaam
ProjectName
De naam van het Azure DevOps project waartoe het ontwikkelitem behoort.
Omschrijving

Dit attribuut identificeert het specifieke project binnen de Azure DevOps organisatie waar het werkitem zich bevindt. Het biedt context op hoog niveau, vooral in organisaties met veel projecten.

Projectnaam is een kritische dimensie voor filtering en vergelijking. Het ondersteunt het Historische Doorlooptijd Trends dashboard door analyse per project mogelijk te maken, wat onthult of bepaalde projecten meer of minder efficiënt zijn dan andere, of dat procesverbeteringen in één project een positieve impact hebben gehad.

Het belang

Het biedt een groepering op hoog niveau voor analyse, wat prestatievergelijking en trendanalyse over verschillende projecten mogelijk maakt.

Vindplaats

Dit komt overeen met het 'Team Project'-veld op een Werkitem in Azure DevOps.

Voorbeelden
E-Commerce PlatformRelaunch Mobiele AppData Warehouse Modernisering
Pull Request ID
PullRequestId
De identifier van een pull request gekoppeld aan het ontwikkelitem.
Omschrijving

Dit attribuut koppelt een werkitem aan een specifiek pull request, wat het mechanisme is voor het indienen en reviewen van codewijzigingen. Een enkel werkitem kan gekoppeld zijn aan meerdere pull requests.

Het hebben van de Pull Request ID maakt een meer granulaire analyse mogelijk van het code review- en integratiedeel van de lifecycle. Het kan worden gebruikt om de tijd van pull request aanmaak tot voltooiing te meten, en om te analyseren hoe vaak pull requests worden afgewezen of aanzienlijke wijzigingen vereisen, wat een indicator kan zijn voor codekwaliteit of onduidelijke vereisten.

Het belang

Het koppelt ontwikkelwerk aan specifieke code review-activiteiten, wat een gedetailleerde analyse van het code-integratie- en kwaliteitsborgingsproces mogelijk maakt.

Vindplaats

Deze informatie is te vinden in de 'Links' of 'Ontwikkeling' sectie van een werkitem in Azure DevOps.

Voorbeelden
452145334589
Wachttijd voor Goedkeuring
ApprovalWaitingTime
De tijd die een ontwikkelitem wacht op een goedkeuring nadat een verzoek is ingediend.
Omschrijving

Deze metric meet de duur van specifieke wachttijden waarin een werkitem wacht op een goedkeuring. Een uitstekend voorbeeld is de tijd tussen 'UAT Gestart' en 'UAT Goedgekeurd'. Het wordt berekend door de tijd tussen deze twee specifieke activiteiten voor een gegeven case te meten.

Dit berekende attribuut ondersteunt direct het Goedkeuringswachttijd Analyse dashboard en de bijbehorende KPI. Door deze specifieke vertragingen te isoleren, kunnen teams communicatie- en besluitvormingsprocessen richten om wachttijd te verminderen en de algehele lifecycle te versnellen.

Het belang

Het meet specifiek vertragingen veroorzaakt door het wachten op beslissingen of goedkeuringen, wat kansen voor verbetering van communicatie en besluitvormingsprocessen benadrukt.

Vindplaats

Dit wordt berekend door specifieke start- en eind goedkeuringsactiviteiten te vinden in de event log (bijv. 'UAT Gestart' en 'UAT Goedgekeurd') en het tijdsverschil te berekenen.

Voorbeelden
3 dagen 2 uur1 dag 8 uur 30 minuten4 uur
Verplicht Aanbevolen Optioneel

Activiteiten in de Software Development Lifecycle

Dit zijn de belangrijkste stappen en mijlpalen die je in je event log vastlegt voor een goede process discovery en het opsporen van knelpunten.
7 Aanbevolen 8 Optioneel
Activiteit Omschrijving
Gedeployed naar Productie
Markeert de succesvolle implementatie van de gekoppelde code van het werkitem naar de productieomgeving. Dit is een expliciete event die wordt vastgelegd vanuit de Azure Pipelines release logs.
Het belang

Dit is een kritieke mijlpaal die de levering van waarde vertegenwoordigt. Het dient als het eindpunt voor het berekenen van lead time en cycle time.

Vindplaats

Vastgelegd vanuit Azure Pipelines release pipeline data, specifiek het completion event van een deployment naar een 'Production' stage die is gekoppeld aan het work item.

Vastleggen

Vastgelegd vanuit een release pipeline deployment completion event.

Gebeurtenistype explicit
Ontwikkeling Gestart
Deze activiteit betekent dat een ontwikkelaar actief aan het item is begonnen. Het wordt vastgelegd door een verandering in de status van het werkitem af te leiden naar 'Actief', 'In uitvoering' of 'Committed'.
Het belang

Markeert het begin van de actieve ontwikkelingsfase. Het analyseren van de tijd van 'Gemaakt' tot 'Ontwikkeling Gestart' onthult wachttijden in de backlog.

Vindplaats

Afgeleid uit de work item history wanneer het System.State-veld verandert van een 'New' of 'Approved' status naar een 'In Progress' status.

Vastleggen

Afgeleid uit het State-veld dat verandert naar 'Active' of 'In Progress'.

Gebeurtenistype inferred
Pull Request Aangemaakt
Geeft aan dat de ontwikkelaar de initiële codering heeft voltooid en de wijzigingen ter review heeft ingediend via een pull request. Dit event koppelt het work item aan een specifieke codewijziging in Azure Repos.
Het belang

Dit is een belangrijke overdracht (handoff) van ontwikkeling naar code review. Het volgen hiervan helpt de duur van het coderen te meten en identificeert wanneer code klaar is voor peer review.

Vindplaats

Vastgelegd vanuit Azure Repos data door het pull request creation event te koppelen aan het bijbehorende work item. Dit is vaak een expliciete koppeling gemaakt door de ontwikkelaar.

Vastleggen

Vastgelegd vanuit een Azure Repos pull request creation event gekoppeld aan een work item.

Gebeurtenistype explicit
Pull Request Voltooid
Vertegenwoordigt de succesvolle voltooiing van een code review, waarbij het pull request wordt goedgekeurd en de code wordt samengevoegd in de doelbranch. Deze event wordt expliciet gelogd in Azure Repos.
Het belang

Markeert het einde van de code review-fase, een veelvoorkomend knelpunt. Het analyseren van de tijd tussen de aanmaak en voltooiing van een pull request (PR) onthult de efficiëntie van de reviewcyclus.

Vindplaats

Vastgelegd vanuit de completion of merge event van een pull request in Azure Repos dat is gekoppeld aan een work item.

Vastleggen

Vastgelegd vanuit het pull request merge event gekoppeld aan een work item.

Gebeurtenistype explicit
QA Testing Gestart
Vertegenwoordigt het begin van de formele kwaliteitsborgingstestfase. Deze activiteit wordt afgeleid wanneer de status van een werkitem wordt gewijzigd naar 'In QA', 'Testen' of een vergelijkbare waarde.
Het belang

Markeert het begin van de QA-cyclus. Het analyseren van de duur van deze fase is cruciaal voor het begrijpen van testknelpunten en -efficiëntie.

Vindplaats

Afgeleid uit de work item history door een wijziging in het System.State-veld naar 'In QA' of een andere aangewezen teststatus te volgen.

Vastleggen

Afgeleid uit het State-veld dat verandert naar 'In QA' of 'Testing'.

Gebeurtenistype inferred
UAT Goedgekeurd
Deze activiteit betekent dat business stakeholders de wijzigingen hebben goedgekeurd na User Acceptance Testing. Het wordt typisch afgeleid uit een statuswijziging van 'In UAT' naar 'UAT Goedgekeurd' of 'Klaar voor Release'.
Het belang

Dit is een kritieke goedkeuringsmijlpaal die bevestigt dat het werkitem voldoet aan de bedrijfsvereisten en klaar is voor productie-implementatie.

Vindplaats

Afgeleid uit de work item history door een wijziging in het System.State-veld te detecteren van een UAT-status naar een goedgekeurde of release-ready status.

Vastleggen

Afgeleid uit het State-veld dat verandert van 'In UAT' naar 'Ready for Release'.

Gebeurtenistype inferred
Werkitem Aangemaakt
Deze activiteit markeert het begin van de ontwikkelingslifecycle, en vertegenwoordigt de aanmaak van een nieuw werkitem zoals een User Story, Bug of Taak. Het wordt expliciet vastgelegd wanneer een nieuwe record wordt opgeslagen in Azure DevOps Boards.
Het belang

Dit is de primaire start event voor het proces. Het is essentieel voor het meten van de end-to-end ontwikkelingsdoorlooptijd en het begrijpen van de initiële bronnen van werk.

Vindplaats

Deze event wordt vastgelegd vanuit de 'Aanmaakdatum' op het werkitem zelf. De werkitemgeschiedenis tabel registreert ook deze initiële statusovergang.

Vastleggen

Vastgelegd vanuit het 'Created Date'-veld van het work item.

Gebeurtenistype explicit
Build Succesvol
Deze activiteit bevestigt dat de broncode, inclusief de nieuwe wijzigingen, succesvol is gecompileerd en verpakt door een build pipeline. Dit is een expliciete event die wordt gelogd door Azure Pipelines.
Het belang

Dient als een cruciale quality gate, wat ervoor zorgt dat nieuwe code correct integreert zonder de build te breken. Falen in deze fase kan duiden op integratieproblemen.

Vindplaats

Vastgelegd vanuit Azure Pipelines build completion events. De build moet gekoppeld zijn aan het work item, direct of via de geassocieerde pull request.

Vastleggen

Vastgelegd vanuit een Azure Pipelines build completion event.

Gebeurtenistype explicit
Ontwikkeling Voltooid
Duidt aan dat alle ontwikkelings- en unit testing activiteiten zijn voltooid, en het item klaar is voor formele testen. Dit wordt typisch afgeleid uit een werkitemstatusverandering naar 'Opgelost' of 'Klaar voor Test'.
Het belang

Dit markeert een belangrijke overdracht (handoff) van het ontwikkelteam naar het QA-team. Het meten van de tijd tot 'QA Testing Gestart' helpt overdrachtsvertragingen te identificeren.

Vindplaats

Afgeleid uit de work item history wanneer het System.State-veld verandert naar een waarde zoals 'Resolved' of een custom state die gereedheid voor QA aangeeft.

Vastleggen

Afgeleid uit het State-veld dat verandert naar 'Resolved'.

Gebeurtenistype inferred
QA Testing Mislukt
Geeft aan dat het work item niet geslaagd is voor kwaliteitstesten en wordt teruggestuurd naar development. Dit wordt vastgelegd door een staatswijziging van een teststatus terug naar een 'In Progress' of 'Active' status.
Het belang

Deze activiteit is essentieel voor het identificeren van rework loops. Een hoge frequentie van deze event duidt op problemen met codekwaliteit, vereisten of testprocessen.

Vindplaats

Afgeleid uit de work item history door een transitie te detecteren van een status zoals 'In QA' terug naar een status zoals 'Active' of 'In Progress'.

Vastleggen

Afgeleid uit het State-veld dat verandert van 'In QA' terug naar 'Active'.

Gebeurtenistype inferred
QA Testing Voltooid
Markeert de succesvolle voltooiing van de kwaliteitsborgingsfase. Dit wordt afgeleid wanneer de status van het werkitem verandert van een teststatus naar bijvoorbeeld 'Klaar voor UAT' of 'QA Goedgekeurd'.
Het belang

Dit is een belangrijke quality gate die aangeeft dat het item klaar is voor user acceptance testing of release. Vertragingen na dit punt kunnen duiden op UAT- of release planning knelpunten.

Vindplaats

Afgeleid uit de work item history wanneer het System.State-veld verandert van 'In QA' naar een volgende status zoals 'Ready for UAT' of 'Done'.

Vastleggen

Afgeleid uit het State-veld dat verandert van 'In QA' naar 'Ready for UAT'.

Gebeurtenistype inferred
UAT Gestart
Vertegenwoordigt het begin van User Acceptance Testing (UAT), waarbij business stakeholders de functionaliteit valideren. Dit wordt typisch afgeleid uit een statusverandering naar 'In UAT' of een vergelijkbare status.
Het belang

Meet het begin van de laatste validatie vóór release. De duur van UAT en de wachttijden voor goedkeuring zijn cruciaal om te analyseren voor procesoptimalisatie.

Vindplaats

Afgeleid uit de work item history wanneer het System.State-veld wordt bijgewerkt naar een custom state die UAT vertegenwoordigt, zoals 'In UAT'.

Vastleggen

Afgeleid uit het State-veld dat verandert naar 'In UAT'.

Gebeurtenistype inferred
Werkitem Geannuleerd
Geeft aan dat het work item is geannuleerd en niet zal worden voltooid of gedeployed. Dit wordt vastgelegd door een staatswijziging naar 'Removed', 'Cancelled' of een vergelijkbare staat.
Het belang

Dit vertegenwoordigt een alternatief, onsuccesvol proceseinde. Het analyseren van geannuleerde items kan problemen onthullen met planning, prioritering of vereistenbepaling.

Vindplaats

Afgeleid uit de work item history wanneer het System.State-veld wordt gewijzigd naar een terminale status in de categorie 'Removed'.

Vastleggen

Afgeleid uit het State-veld dat verandert naar 'Removed' of 'Cancelled'.

Gebeurtenistype inferred
Werkitem Gesloten
Vertegenwoordigt de definitieve afsluiting van het werkitem na implementatie en eventuele validatie na implementatie. Het wordt vastgelegd door een statusverandering naar 'Gesloten' of 'Klaar'.
Het belang

Deze activiteit markeert de uiteindelijke, succesvolle voltooiing van het gehele proces voor een werkitem. Het is het definitieve eindpunt van de lifecycle.

Vindplaats

Afgeleid uit de work item history wanneer het System.State-veld wordt gewijzigd naar 'Closed' of een vergelijkbare terminale status in de categorie 'Completed'.

Vastleggen

Afgeleid uit het State-veld dat verandert naar 'Closed'.

Gebeurtenistype inferred
Werkitem goedgekeurd
Vertegenwoordigt de formele goedkeuring van een werkitem, bevestigend dat het goed gedefinieerd en klaar is voor ontwikkeling. Dit wordt typisch afgeleid uit een verandering in het 'Status'-veld naar een waarde als 'Goedgekeurd' of 'Klaar voor Ontwikkeling'.
Het belang

Het volgen van goedkeuringen helpt bij het analyseren van de tijd tussen idee-indiening en ontwikkelingscommitment. Het belicht potentiële vertragingen in de plannings- en backlog grooming fasen.

Vindplaats

Afgeleid uit de work item history door een wijziging van het System.State-veld te detecteren naar 'Approved' of een vergelijkbare custom state.

Vastleggen

Afgeleid uit het State-veld dat verandert naar 'Approved'.

Gebeurtenistype inferred
Aanbevolen Optioneel

Extractie Guides

Hoe u uw data uit Azure DevOps haalt