Datatemplate voor de softwareontwikkelingscyclus
Datatemplate voor de softwareontwikkelingscyclus
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om in de softwareontwikkelingscyclus te volgen
- Stapsgewijze instructies voor data-extractie uit Azure DevOps
Attributen voor de softwareontwikkelingscyclus
| Naam | Beschrijving | ||
|---|---|---|---|
|
Activiteitsnaam
ActivityName
|
De naam van de specifieke gebeurtenis of Task die op een bepaald moment in de ontwikkelcyclus van een work item plaatsvond. | ||
|
Beschrijving
De activiteitsnaam beschrijft een specifieke stap of mijlpaal in het proces, zoals 'Development Started', 'Pull Request Created' of 'Deployed to Production'. Deze activiteiten worden afgeleid uit statuswijzigingen van het work item, gekoppelde gebeurtenissen zoals builds of pull requests, of aangepaste gebeurtenissen. Dit attribuut is nodig om de proceskaart op te bouwen, die de workflow visueel weergeeft. Analisten kunnen hiermee de volgorde van gebeurtenissen begrijpen, veelvoorkomende routes herkennen, bottlenecks tussen activiteiten opsporen en zien hoe vaak elke stap voorkomt.
Waarom dit belangrijk is
Dit attribuut bepaalt de processtappen en vormt de basis van de proceskaart. Zo kun je de workflow, bottlenecks en afwijkingen analyseren.
Waar vind je dit?
Meestal afgeleid uit wijzigingen in het veld 'State' van een work item of uit gekoppelde gebeurtenissen, zoals builds, commits en pull requests. De historie van het work item bevat de ruwe data voor deze gebeurtenissen.
Voorbeelden
Ontwikkeling gestartPull request afgerondQA-test misluktUitgerold naar productieWork item gesloten
|
|||
|
Ontwikkelitem
DevelopmentItem
|
De unieke identificatiecode van één werkeenheid, zoals een functie, bug of user story. Deze code dient als case-ID voor het proces. | ||
|
Beschrijving
Een ontwikkelitem is een afzonderlijk stuk werk dat in Azure DevOps wordt bijgehouden. Elk item heeft een unieke ID en vormt het centrale object waar alle procesactiviteiten om draaien, van aanmaken en plannen tot ontwikkelen, testen en uitrollen. Bij process mining gebruik je dit attribuut om alle bijbehorende gebeurtenissen aan één case te koppelen. Zo kun je de volledige levenscyclus van elk work item reconstrueren en per item doorlooptijden, procesafwijkingen en herstelwerk analyseren.
Waarom dit belangrijk is
Dit is de belangrijkste identificatiecode die alle processtappen aan één samenhangende case koppelt. Zo wordt een analyse van de volledige softwareontwikkelingscyclus mogelijk.
Waar vind je dit?
Dit komt overeen met het veld 'ID' van een work item in Azure DevOps Boards. Je kunt het ophalen via de Azure DevOps REST API voor Work Item Tracking.
Voorbeelden
10234102351023610237
|
|||
|
Tijdstip van gebeurtenis
EventTime
|
De exacte timestamp waarop een activiteit of gebeurtenis voor een ontwikkelitem plaatsvond. | ||
|
Beschrijving
Het tijdstip van de gebeurtenis legt de datum en tijd van elke activiteit in de ontwikkelcyclus vast. Met deze timestamp kun je gebeurtenissen chronologisch ordenen en de tijd ertussen berekenen. Bij analyses gebruik je dit attribuut om alle tijdsgebonden metrieken te berekenen, waaronder doorlooptijden, verwerkingstijden en wachttijden. Het maakt een chronologisch geordend event log mogelijk, de benodigde invoer voor elke process mining-analyse. Je gebruikt het om vertragingen op te sporen, prestaties af te zetten tegen SLA’s en trends in de tijd te volgen.
Waarom dit belangrijk is
Deze timestamp bepaalt de chronologische volgorde van gebeurtenissen. Dat is nodig om KPI’s op basis van tijdsduur te berekenen en de procesgang en bottlenecks te begrijpen.
Waar vind je dit?
Dit is de 'Changed Date' van elke wijziging in de historie van een work item. Voor externe gebeurtenissen, zoals builds of uitrollen, is dit de timestamp waarop de gebeurtenis is afgerond.
Voorbeelden
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
|
|||
|
Bronsysteem
SourceSystem
|
Het systeem waaruit de procesdata is opgehaald, in dit geval Azure DevOps. | ||
|
Beschrijving
Dit attribuut geeft aan uit welk systeem de data afkomstig is. Dat is vooral handig wanneer je data uit meerdere systemen combineert voor een breder beeld van het proces. In dit model is de waarde altijd Azure DevOps. Bij een analyse van één systeem lijkt dit attribuut misschien onveranderlijk. Toch geeft het belangrijke context over de herkomst van de data, wat van belang is voor datagovernance, probleemoplossing en toekomstige koppelingen met systemen zoals ServiceNow of SAP.
Waarom dit belangrijk is
Dit geeft belangrijke context over de herkomst van de data. Dat is van belang voor datagovernance, validatie en procesanalyse over meerdere systemen.
Waar vind je dit?
Dit is een vaste waarde die je tijdens het ophalen en omzetten van de data toevoegt om de dataset te labelen.
Voorbeelden
Azure DevOps
|
|||
|
Laatste data-update
LastDataUpdate
|
De timestamp waarop de data voor dit proces voor het laatst vanuit het bronsysteem is vernieuwd. | ||
|
Beschrijving
Dit attribuut registreert wanneer de dataset voor het laatst uit Azure DevOps is opgehaald en bijgewerkt. Zo zie je hoe actueel de data is en welke periode de analyse beslaat. Bij elke procesanalyse is het belangrijk te weten hoe recent de data is, zodat je beslissingen kunt nemen op basis van de juiste context. Deze timestamp laat zien of je naar realtime informatie of een historische momentopname kijkt. Dat bepaalt hoe relevant de bevindingen zijn.
Waarom dit belangrijk is
Dit laat zien hoe actueel de data is, zodat duidelijk is op welke periode analyses en beslissingen betrekking hebben.
Waar vind je dit?
Dit is een metadatatimestamp die wordt aangemaakt en opgeslagen tijdens het ophalen, omzetten en laden van de data (ETL-proces).
Voorbeelden
2024-05-20T08:00:00Z
|
|||
|
Eindtijd
EndTime
|
De timestamp waarop een activiteit is afgerond. Je gebruikt deze om de verwerkingstijd van een activiteit te berekenen. | ||
|
Beschrijving
De eindtijd markeert het einde van een activiteit. In veel event logs geldt de starttijd van de volgende activiteit als eindtijd van de vorige. Met een afzonderlijke eindtijd kun je zowel de verwerkingstijd van activiteiten als de wachttijd ertussen nauwkeuriger berekenen. Dit attribuut is nodig om de KPI ProcessingTime te berekenen en bottlenecks gedetailleerd te analyseren. Het maakt onderscheid tussen de tijd waarin iemand actief aan een Task werkt en de tijd waarin op de volgende stap wordt gewacht. Dat is belangrijk voor het dashboard Stage Handoff Analysis.
Waarom dit belangrijk is
Hiermee bereken je de verwerkingstijd van activiteiten en de wachttijd nauwkeurig. Dat vormt de basis voor bottleneckanalyse en efficiëntieverbeteringen.
Waar vind je dit?
Deze waarde wordt vaak afgeleid. Het kan de starttijd zijn van de volgende gebeurtenis voor dezelfde case, of een expliciet vastgelegde tijd als het bronsysteem zowel begin- als eindtijden van taken registreert.
Voorbeelden
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
|
|||
|
Is herstelwerk
IsRework
|
Een booleaanse vlag die aangeeft of een ontwikkelitem in de levenscyclus terugkeert naar een eerdere fase. | ||
|
Beschrijving
Deze vlag krijgt de waarde true als een werkitem een herstelwerkcyclus doorloopt, bijvoorbeeld wanneer het van ‘QA Testing Completed’ teruggaat naar ‘Development Started’. De waarde wordt berekend door de activiteitenvolgorde van een case te analyseren en niet-lineaire voortgang te herkennen. Dit attribuut is nodig voor het dashboard Frequentie van herstelwerk en hertesten en de KPI Frequentie van herstelwerkcycli. Je kunt herstelwerk eenvoudig filteren en tellen. Zo spoor je kwaliteitsproblemen, communicatieproblemen of onvoldoende tests op die tot vertraging leiden.
Waarom dit belangrijk is
Het maakt herstelwerk zichtbaar en meetbaar, zodat je kwaliteitsproblemen en inefficiënties kunt opsporen die de doorlooptijd verlengen.
Waar vind je dit?
Dit is een berekend attribuut, afgeleid uit de volgorde van activiteiten in het event log van elke case.
Voorbeelden
truefalse
|
|||
|
Prioriteit
Priority
|
Een numerieke of beschrijvende rangschikking van het belang van een ontwikkelitem ten opzichte van andere items. | ||
|
Beschrijving
Prioriteit geeft aan hoe belangrijk een werkitem is voor de planning. Een hogere prioriteit betekent dat het item eerder aan de beurt moet komen dan items met een lagere prioriteit. Vaak wordt een numerieke schaal gebruikt, bijvoorbeeld 1, 2, 3 en 4, waarbij 1 de hoogste prioriteit is. Dit attribuut is nodig voor het dashboard Doorvoer en doorlooptijd op basis van prioriteit. Met deze data kun je nagaan of het prioriteitssysteem werkt: gaan items met een hoge prioriteit daadwerkelijk sneller door het proces dan items met een lage prioriteit?
Waarom dit belangrijk is
Je kunt ermee nagaan of items met een hoge prioriteit sneller worden opgepakt. Dat is belangrijk om te beoordelen of de prioritering werkt.
Waar vind je dit?
Dit komt overeen met het veld ‘Priority’ van een werkitem in Azure DevOps.
Voorbeelden
1234
|
|||
|
Status
State
|
De huidige status van het ontwikkelitem in de workflow, zoals ‘Nieuw’, ‘Actief’, ‘Opgelost’ of ‘Gesloten’. | ||
|
Beschrijving
Het attribuut State geeft op elk moment de formele status van een werkitem weer, zoals vastgelegd in de proces-template van het project. Overgangen tussen deze statussen vormen de belangrijkste bron voor de activiteiten in het event log. Het attribuut Activity beschrijft een statuswijziging vaak specifieker, maar het oorspronkelijke attribuut State is handig voor filters en analyses. Je ziet ermee hoeveel tijd werkitems in bepaalde statussen doorbrengen. Het is ook nodig voor het dashboard Doorlooptijd per fase en voor analyses van overdrachten.
Waarom dit belangrijk is
Dit attribuut geeft de status van het werkitem in de levenscyclus aan. Daarmee kun je de processtroom begrijpen en berekenen hoeveel tijd items in verschillende fasen doorbrengen.
Waar vind je dit?
Dit komt overeen met het veld ‘State’ van een werkitem in Azure DevOps.
Voorbeelden
NieuwActiefIn QAOpgelostGesloten
|
|||
|
Teamnaam
TeamName
|
De naam van het ontwikkelteam dat verantwoordelijk is voor het werkitem. | ||
|
Beschrijving
De teamnaam geeft aan aan welk team een werkitem is toegewezen. In Azure DevOps wordt het werk vaak verdeeld over teams die deel uitmaken van een groter project. Met dit attribuut kun je het proces per team analyseren. Vergelijk de werkwijze en prestaties van teams, ontdek wat goed presterende teams anders doen en zie waar een team ondersteuning of procesverbeteringen nodig heeft.
Waarom dit belangrijk is
Je kunt teams met elkaar vergelijken, verschillen in prestaties opsporen en goede werkwijzen binnen de organisatie delen.
Waar vind je dit?
Dit wordt vaak afgeleid van het veld ‘Area Path’ van een werkitem, omdat teams in Azure DevOps doorgaans aan specifieke area paths zijn gekoppeld.
Voorbeelden
Team PhoenixOmega SquadPlatform CoreFrontend Crew
|
|||
|
Toegewezen aan
AssignedTo
|
De gebruiker of het teamlid aan wie het ontwikkelitem momenteel is toegewezen. | ||
|
Beschrijving
Dit attribuut geeft aan wie in een bepaalde fase van het proces verantwoordelijk is voor het work item. De toewijzing kan tijdens de levenscyclus meerdere keren veranderen, bijvoorbeeld van een ontwikkelaar naar een tester en daarna naar een releasemanager. Analyse op basis van 'Assigned To' is belangrijk voor het dashboard Developer and Tester Workload Overview. Je ziet hiermee hoe het werk is verdeeld, welke teamleden overbelast zijn en hoe de prestaties tussen personen of teams verschillen.
Waarom dit belangrijk is
Hiermee kun je de werkverdeling analyseren, bottlenecks rond specifieke medewerkers opsporen en de capaciteit van teams beheren.
Waar vind je dit?
Dit komt overeen met het veld 'Assigned To' van een work item in Azure DevOps. De waarde wordt voor elke gebeurtenis uit de historie van het work item gehaald.
Voorbeelden
jane.doe@example.comjohn.smith@example.comniet toegewezen
|
|||
|
Type work item
WorkItemType
|
De classificatie van het ontwikkelitem, zoals Bug, Feature, User Story of Task. | ||
|
Beschrijving
Het type work item geeft aan wat voor werk wordt uitgevoerd. Verschillende typen work items volgen vaak andere procesroutes en hebben andere prestatieverwachtingen of SLA’s. Een 'Bug' kan bijvoorbeeld een snellere route volgen dan een 'Feature'. Dit attribuut is nodig voor vergelijkende analyses. Je kunt de proceskaart of KPI’s filteren op type werk om te zien of bugs efficiënter worden afgehandeld dan functies. Ook kun je historische trends in doorlooptijden per werkcategorie volgen.
Waarom dit belangrijk is
Hiermee kun je de procesanalyse opdelen en workflows en prestaties vergelijken voor verschillende soorten werk, zoals bugs en functies.
Waar vind je dit?
Dit komt overeen met het veld 'Work Item Type' van een work item in Azure DevOps.
Voorbeelden
BugFunctieUser StoryTask
|
|||
|
Ernst
Severity
|
Geeft aan welke impact een bug of probleem heeft op het systeem of de eindgebruikers. | ||
|
Beschrijving
Ernst geeft aan hoe groot de impact van een bug is, van een kritieke systeemstoring tot een klein cosmetisch probleem. Dit is iets anders dan prioriteit, die de volgorde van het werk bepaalt. Een bug met een hoge ernst kan toch een lage prioriteit hebben als er een eenvoudige tijdelijke oplossing is. Dit attribuut voegt een extra dimensie toe aan analyses, bijvoorbeeld voor het dashboard Doorvoer en doorlooptijd op basis van prioriteit. Je kunt ermee onderzoeken of de ernstigste bugs als eerste worden opgelost en inzicht krijgen in de risico’s van het werk dat wordt verwerkt.
Waarom dit belangrijk is
Je kunt werkitems indelen op basis van hun bedrijfsimpact en nagaan hoe goed het team problemen met een grote impact aanpakt.
Waar vind je dit?
Dit komt in Azure DevOps overeen met het veld ‘Severity’ van een werkitem, meestal een bug.
Voorbeelden
1 - Kritiek2 - Hoog3 - Gemiddeld4 - Laag
|
|||
|
Iteratiepad
IterationPath
|
De ontwikkelsprint of periode waaraan het werkitem is toegewezen. | ||
|
Beschrijving
Het iteratiepad, oftewel de sprint, is een afgebakende periode voor ontwikkeling. Werkitems worden aan een iteratie toegewezen en moeten binnen die periode worden afgerond. Met analyses per iteratiepad kun je de prestaties van het proces per sprint volgen. Je ziet bijvoorbeeld of doorlooptijden in opeenvolgende sprints verbeteren, hoeveel werk wordt doorgeschoven en hoe voorspelbaar de sprintplanning is.
Waarom dit belangrijk is
Je kunt de prestaties per sprint analyseren en teams helpen hun werkwijze en agile aanpak in de loop van de tijd te verbeteren.
Waar vind je dit?
Dit komt overeen met het veld ‘Iteration Path’ van een werkitem in Azure DevOps.
Voorbeelden
E-commerceplatform\Sprint 12E-commerceplatform\Sprint 13Herstart mobiele app\Fase 2\Sprint 4
|
|||
|
Overdrachtstijd tussen fasen
StageHandoffTime
|
De wachttijd tussen het afronden van een belangrijke fase en het begin van de volgende. | ||
|
Beschrijving
De overdrachtstijd tussen fasen meet de wachttijd tussen opeenvolgende procesfasen, bijvoorbeeld tussen ‘Development Completed’ en ‘QA Testing Started’. Je berekent deze tijd door de relevante overgangen te vinden en het tijdsverschil tussen het einde van de eerste activiteit en het begin van de tweede te meten. Deze metriek staat centraal in het dashboard Duur van fasen en overdrachtsanalyse. Door de overdrachtstijd apart te meten, vind je verborgen bottlenecks waar werk stilligt, bijvoorbeeld door gebrek aan beschikbare mensen, communicatievertraging of een inefficiënt proces.
Waarom dit belangrijk is
Je meet hiermee de wachttijd tussen procesfasen en maakt verborgen bottlenecks en vertragingen buiten het actieve werk zichtbaar.
Waar vind je dit?
Dit is een berekend attribuut. Je moet eerst opeenvolgende activiteiten vinden die een overdracht vormen en daarna het tijdsverschil ertussen berekenen.
Voorbeelden
2 uur 15 minuten1 dag 4 uur0 uur 30 minuten
|
|||
|
Projectnaam
ProjectName
|
De naam van het Azure DevOps-project waartoe het ontwikkelitem behoort. | ||
|
Beschrijving
Dit attribuut geeft aan in welk project binnen de Azure DevOps-organisatie het werkitem staat. Het biedt context op hoofdlijnen, vooral in organisaties met veel projecten. De projectnaam is een belangrijke dimensie om data te filteren en te vergelijken. In het dashboard Historische trends in doorlooptijd kun je analyses per project uitvoeren. Zo zie je of bepaalde projecten efficiënter werken en of procesverbeteringen in een project effect hebben gehad.
Waarom dit belangrijk is
Je kunt hiermee data op hoofdlijnen groeperen en prestaties en trends tussen projecten vergelijken.
Waar vind je dit?
Dit komt overeen met het veld ‘Team Project’ van een werkitem in Azure DevOps.
Voorbeelden
E-commerceplatformHerstart mobiele appModernisering datawarehouse
|
|||
|
Pull Request-ID
PullRequestId
|
De identificatiecode van een pull request dat aan het ontwikkelitem is gekoppeld. | ||
|
Beschrijving
Met dit attribuut koppel je een werkitem aan een specifieke pull request, waarmee codewijzigingen worden ingediend en beoordeeld. Eén werkitem kan aan meerdere pull requests zijn gekoppeld. Met de pull request-ID kun je het deel van de levenscyclus rond codebeoordeling en integratie gedetailleerder analyseren. Je kunt de tijd meten tussen het aanmaken en afronden van een pull request en nagaan hoe vaak pull requests worden afgewezen of grote wijzigingen nodig hebben. Dat kan wijzen op problemen met de codekwaliteit of onduidelijke vereisten.
Waarom dit belangrijk is
Het koppelt ontwikkelwerk aan specifieke codebeoordelingen. Zo kun je de code-integratie en kwaliteitscontrole gedetailleerd analyseren.
Waar vind je dit?
Deze informatie staat in Azure DevOps in het gedeelte ‘Links’ of ‘Development’ van een werkitem.
Voorbeelden
452145334589
|
|||
|
Wachttijd op goedkeuring
ApprovalWaitingTime
|
De tijd die een ontwikkelitem wacht op goedkeuring nadat die is aangevraagd. | ||
|
Beschrijving
Deze metriek meet hoe lang een werkitem op goedkeuring wacht. Een voorbeeld is de tijd tussen ‘UAT Started’ en ‘UAT Approved’. Je berekent de wachttijd voor een case door het tijdsverschil tussen deze twee activiteiten te meten. Dit berekende attribuut ondersteunt het dashboard Analyse van wachttijd op goedkeuring en de bijbehorende KPI. Door deze vertragingen apart te meten, kunnen teams de communicatie en besluitvorming verbeteren, wachttijd verminderen en de totale levenscyclus verkorten.
Waarom dit belangrijk is
Je meet hiermee vertraging door besluiten of goedkeuringen en ziet waar betere communicatie en besluitvorming de wachttijd kunnen verkorten.
Waar vind je dit?
Je berekent dit door de specifieke begin- en eindactiviteiten voor goedkeuring in het event log te vinden, bijvoorbeeld ‘UAT Started’ en ‘UAT Approved’, en het tijdsverschil ertussen te bepalen.
Voorbeelden
3 dagen 2 uur1 dag 8 uur 30 minuten4 uur
|
|||
Activiteiten in de softwareontwikkelingscyclus
| Activiteit | Beschrijving | ||
|---|---|---|---|
|
Ontwikkeling gestart
|
Deze activiteit geeft aan dat een ontwikkelaar actief aan het item is gaan werken. We leiden dit af uit een statuswijziging van het work item naar 'Active', 'In Progress' of 'Committed'. | ||
|
Waarom dit belangrijk is
Dit markeert het begin van de actieve ontwikkelfase. De tijd tussen 'Created' en 'Development Started' laat zien hoe lang items in de backlog wachten.
Waar vind je dit?
Afgeleid uit de historie van het work item wanneer het veld System.State verandert van 'New' of 'Approved' naar 'In Progress'.
Vastleggen
Afgeleid uit een wijziging van het veld State naar 'Active' of 'In Progress'.
Gebeurtenistype
inferred
|
|||
|
Pull request aangemaakt
|
Dit geeft aan dat de ontwikkelaar de eerste versie van de code heeft afgerond en de wijzigingen ter beoordeling heeft ingediend via een pull request. Deze gebeurtenis koppelt het work item aan een specifieke codewijziging in Azure Repos. | ||
|
Waarom dit belangrijk is
Dit is een belangrijke overdracht van ontwikkeling naar codebeoordeling. Door dit moment te volgen, kun je de codeertijd meten en zien wanneer code klaar is voor beoordeling door collega’s.
Waar vind je dit?
Afkomstig uit Azure Repos-data, door de gebeurtenis voor het aanmaken van het pull request te koppelen aan het bijbehorende work item. Vaak legt de ontwikkelaar deze koppeling expliciet vast.
Vastleggen
Afkomstig uit de gebeurtenis voor het aanmaken van een pull request in Azure Repos, gekoppeld aan een work item.
Gebeurtenistype
explicit
|
|||
|
Pull request afgerond
|
Dit markeert de succesvolle afronding van een codebeoordeling: het pull request is goedgekeurd en de code is samengevoegd met de doelbranch. Azure Repos registreert deze gebeurtenis expliciet. | ||
|
Waarom dit belangrijk is
Dit markeert het einde van de codebeoordeling, een veelvoorkomende bottleneck. De tijd tussen het aanmaken en afronden van een PR laat zien hoe efficiënt de beoordelingscyclus verloopt.
Waar vind je dit?
Afkomstig uit de gebeurtenis voor het afronden of samenvoegen van een pull request in Azure Repos dat aan een work item is gekoppeld.
Vastleggen
Afkomstig uit de gebeurtenis voor het samenvoegen van een pull request dat aan een work item is gekoppeld.
Gebeurtenistype
explicit
|
|||
|
QA-test gestart
|
Dit markeert het begin van de formele kwaliteitscontrole. We leiden deze activiteit af wanneer de status van een work item verandert naar 'In QA', 'Testing' of een vergelijkbare waarde. | ||
|
Waarom dit belangrijk is
Dit markeert het begin van de QA-cyclus. De duur van deze fase analyseren is belangrijk om bottlenecks en efficiëntieproblemen bij het testen te begrijpen.
Waar vind je dit?
Afgeleid uit de historie van het work item door een wijziging van het veld System.State naar 'In QA' of een andere aangewezen teststatus te volgen.
Vastleggen
Afgeleid uit een wijziging van het veld State naar 'In QA' of 'Testing'.
Gebeurtenistype
inferred
|
|||
|
UAT goedgekeurd
|
Deze activiteit geeft aan dat zakelijke stakeholders de wijzigingen na User Acceptance Testing hebben goedgekeurd. Meestal leiden we dit af uit een statuswijziging van 'In UAT' naar 'UAT Approved' of 'Ready for Release'. | ||
|
Waarom dit belangrijk is
Dit is een belangrijke goedkeuringsmijlpaal. Het bevestigt dat het work item aan de zakelijke eisen voldoet en klaar is voor uitrol naar productie.
Waar vind je dit?
Afgeleid uit de historie van het work item door een wijziging van het veld System.State van een UAT-status naar een goedgekeurde status of een status die aangeeft dat het item klaar is voor release.
Vastleggen
Afgeleid uit een wijziging van het veld State van 'In UAT' naar 'Ready for Release'.
Gebeurtenistype
inferred
|
|||
|
Uitgerold naar productie
|
Dit markeert de succesvolle uitrol van de code die bij het work item hoort naar de productieomgeving. Azure Pipelines haalt deze gebeurtenis expliciet uit de releaselogboeken. | ||
|
Waarom dit belangrijk is
Dit is een belangrijke mijlpaal: de waarde is geleverd. Dit is het eindpunt voor het berekenen van de totale doorlooptijd en de doorlooptijd van de ontwikkelcyclus.
Waar vind je dit?
Afkomstig uit de releasepipelinegegevens van Azure Pipelines, specifiek uit de gebeurtenis voor het voltooien van een uitrol naar een fase 'Production' die aan het work item is gekoppeld.
Vastleggen
Afkomstig uit de gebeurtenis voor het voltooien van een uitrol via een releasepipeline.
Gebeurtenistype
explicit
|
|||
|
Work item aangemaakt
|
Deze activiteit markeert het begin van de ontwikkelcyclus: er wordt een nieuw work item aangemaakt, zoals een User Story, Bug of Task. Azure DevOps Boards registreert dit wanneer een nieuw record wordt opgeslagen. | ||
|
Waarom dit belangrijk is
Dit is de belangrijkste startgebeurtenis van het proces. Deze is nodig om de totale ontwikkeldoorlooptijd te meten en te begrijpen waar het werk vandaan komt.
Waar vind je dit?
Deze gebeurtenis wordt vastgelegd via het veld 'Created Date' van het work item. De historietabel van het work item registreert ook deze eerste statusovergang.
Vastleggen
Afkomstig uit het veld 'Created Date' van het work item.
Gebeurtenistype
explicit
|
|||
|
Build geslaagd
|
Deze activiteit bevestigt dat de broncode, inclusief de nieuwe wijzigingen, succesvol is gecompileerd en verpakt door een buildpipeline. Azure Pipelines registreert deze gebeurtenis expliciet. | ||
|
Waarom dit belangrijk is
Dit is een belangrijke kwaliteitscontrole: nieuwe code wordt correct geïntegreerd zonder de build te breken. Mislukkingen in deze fase kunnen wijzen op integratieproblemen.
Waar vind je dit?
Afkomstig uit de buildvoltooiingsgebeurtenissen van Azure Pipelines. De build moet aan het work item zijn gekoppeld, rechtstreeks of via het bijbehorende pull request.
Vastleggen
Afkomstig uit de gebeurtenis voor het voltooien van een build in Azure Pipelines.
Gebeurtenistype
explicit
|
|||
|
Ontwikkeling afgerond
|
Dit betekent dat alle ontwikkelactiviteiten en unittests zijn afgerond en het item klaar is voor formeel testen. Meestal leiden we dit af uit een statuswijziging van het work item naar 'Resolved' of 'Ready for Test'. | ||
|
Waarom dit belangrijk is
Dit markeert een belangrijke overdracht van het ontwikkelteam naar het QA-team. Door de tijd tot 'QA Testing Started' te meten, kun je vertragingen bij de overdracht opsporen.
Waar vind je dit?
Afgeleid uit de historie van het work item wanneer het veld System.State verandert naar bijvoorbeeld 'Resolved' of een aangepaste status die aangeeft dat het item klaar is voor QA.
Vastleggen
Afgeleid uit een wijziging van het veld State naar 'Resolved'.
Gebeurtenistype
inferred
|
|||
|
QA-test afgerond
|
Dit markeert de succesvolle afronding van de kwaliteitscontrole. We leiden dit af wanneer de status van het work item verandert van een teststatus naar bijvoorbeeld 'Ready for UAT' of 'QA Approved'. | ||
|
Waarom dit belangrijk is
Dit is een belangrijke kwaliteitscontrole die aangeeft dat het item klaar is voor acceptatietests door gebruikers of voor release. Vertragingen hierna kunnen wijzen op bottlenecks bij UAT of de releaseplanning.
Waar vind je dit?
Afgeleid uit de historie van het work item wanneer het veld System.State verandert van 'In QA' naar een volgende status, zoals 'Ready for UAT' of 'Done'.
Vastleggen
Afgeleid uit een wijziging van het veld State van 'In QA' naar 'Ready for UAT'.
Gebeurtenistype
inferred
|
|||
|
QA-test mislukt
|
Dit geeft aan dat het work item niet door de kwaliteitscontrole is gekomen en teruggaat naar ontwikkeling. We leiden dit af uit een statuswijziging van een teststatus terug naar 'In Progress' of 'Active'. | ||
|
Waarom dit belangrijk is
Deze activiteit helpt herstelwerk in kaart te brengen. Als dit vaak gebeurt, kan dat wijzen op problemen met de codekwaliteit, requirements of testprocessen.
Waar vind je dit?
Afgeleid uit de historie van het work item door een overgang van bijvoorbeeld 'In QA' terug naar 'Active' of 'In Progress' te herkennen.
Vastleggen
Afgeleid uit een wijziging van het veld State van 'In QA' terug naar 'Active'.
Gebeurtenistype
inferred
|
|||
|
UAT gestart
|
Dit markeert het begin van User Acceptance Testing, waarin zakelijke stakeholders de functionaliteit beoordelen. Meestal leiden we dit af uit een statuswijziging naar 'In UAT' of een vergelijkbare status. | ||
|
Waarom dit belangrijk is
Dit meet het begin van de laatste controle vóór de release. Het is belangrijk om de duur van UAT en de wachttijd op goedkeuring te analyseren om het proces te verbeteren.
Waar vind je dit?
Afgeleid uit de historie van het work item wanneer het veld System.State wordt bijgewerkt naar een aangepaste UAT-status, zoals 'In UAT'.
Vastleggen
Afgeleid uit een wijziging van het veld State naar 'In UAT'.
Gebeurtenistype
inferred
|
|||
|
Work item geannuleerd
|
Dit geeft aan dat het work item is geannuleerd en niet wordt afgerond of uitgerold. We leiden dit af uit een statuswijziging naar 'Removed', 'Cancelled' of een vergelijkbare status. | ||
|
Waarom dit belangrijk is
Dit is een alternatieve, niet-succesvolle afsluiting van het proces. Door geannuleerde items te analyseren, kun je problemen met planning, prioritering of het vastleggen van requirements opsporen.
Waar vind je dit?
Afgeleid uit de historie van het work item wanneer het veld System.State verandert naar een eindstatus in de categorie 'Removed'.
Vastleggen
Afgeleid uit een wijziging van het veld State naar 'Removed' of 'Cancelled'.
Gebeurtenistype
inferred
|
|||
|
Work item gesloten
|
Dit markeert de definitieve afsluiting van het work item na de uitrol en eventuele controles achteraf. We leiden dit af uit een statuswijziging naar 'Closed' of 'Done'. | ||
|
Waarom dit belangrijk is
Deze activiteit markeert de succesvolle afronding van het hele proces voor een work item. Dit is het definitieve eindpunt van de levenscyclus.
Waar vind je dit?
Afgeleid uit de historie van het work item wanneer het veld System.State verandert naar 'Closed' of een vergelijkbare eindstatus in de categorie 'Completed'.
Vastleggen
Afgeleid uit een wijziging van het veld State naar 'Closed'.
Gebeurtenistype
inferred
|
|||
|
Work item goedgekeurd
|
Dit is de formele goedkeuring van een work item. Daarmee is bevestigd dat het item duidelijk is omschreven en klaar is voor ontwikkeling. Meestal leiden we dit af uit een wijziging van het veld 'State' naar bijvoorbeeld 'Approved' of 'Ready for Dev'. | ||
|
Waarom dit belangrijk is
Door goedkeuringen te volgen, kun je de tijd tussen het indienen van een idee en de start van de ontwikkeling analyseren. Zo worden mogelijke vertragingen in de plannings- en backlogbeheerfase zichtbaar.
Waar vind je dit?
Afgeleid uit de historie van het work item door een wijziging van het veld System.State naar 'Approved' of een vergelijkbare aangepaste status te herkennen.
Vastleggen
Afgeleid uit een wijziging van het veld State naar 'Approved'.
Gebeurtenistype
inferred
|
|||
Extractiegidsen
Klaar om te beginnen?
Begin vandaag met het verbeteren van de softwareontwikkelingscyclus. Deze template is een eerste stap naar waardevolle inzichten in je processen.
Optimaliseer de softwareontwikkelingscyclus in Azure DevOps, begin vandaag!
Verkort de doorlooptijd met 30% en haal bottlenecks uit je workflow voor softwareontwikkeling.
Geen creditcard nodig. Je kunt binnen enkele minuten aan de slag.