Uw Software Development Lifecycle Data Template
Uw Software Development Lifecycle Data Template
- Aanbevolen attributen om vast te leggen
- Belangrijke activiteiten om te volgen voor uw SDLC
- Gedetailleerde extractiehandleiding voor Azure DevOps
Attributen van de Software Development Lifecycle
| 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
|
|||
Activiteiten in de Software Development Lifecycle
| 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
|
|||