Datatemplate voor de softwareontwikkelingscyclus
Datatemplate voor de softwareontwikkelingscyclus
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om te volgen
- Instructies voor data-extractie uit Jira Software
Attributen van de softwareontwikkelingscyclus
| Naam | Beschrijving | ||
|---|---|---|---|
|
Activiteit
Activity
|
De naam van een specifieke gebeurtenis of statuswijziging in de levenscyclus van een ontwikkelitem. | ||
|
Beschrijving
Dit attribuut staat voor een afzonderlijke stap of mijlpaal in het softwareontwikkelproces. De activiteiten zijn afgeleid van wijzigingen in het statusveld van de Jira-issue of van andere belangrijke gebeurtenissen, zoals codecommits of reviews. Bij process mining vormen deze activiteiten samen de procesmap. Door activiteiten te analyseren, kun je de processtroom herkennen, de duur van afzonderlijke fasen meten en afwijkingen van de standaardworkflow opsporen, zoals herstelrondes of overgeslagen kwaliteitscontroles.
Waarom dit belangrijk is
Activiteiten beschrijven de stappen in het proces. De volgorde ervan is belangrijk om de processtroom zichtbaar te maken, bottlenecks te vinden en procesvariaties te analyseren.
Waar vind je dit?
Meestal afgeleid uit statuswijzigingen in de issuegeschiedenis of changelog van Jira. Je kunt de gegevens ook aanvullen met data uit gekoppelde ontwikkeltools.
Voorbeelden
Ontwikkeling gestartCodereview uitgevoerdQA-test afgerondGeïmplementeerd in productie
|
|||
|
Ontwikkelitem
DevelopmentItem
|
De unieke identificatiecode van één werkeenheid, zoals een story, bug of task, in Jira Software. | ||
|
Beschrijving
Het ontwikkelitem is de primaire case-ID en staat voor een afzonderlijke werkeenheid, zoals een functie, bugfix of task. Het verbindt alle activiteiten voor dat item, van de eerste uitwerking en planning tot en met ontwikkeling, testen en implementatie. In Jira komt dit meestal overeen met de issue key, bijvoorbeeld 'PROJ-123'. Met dit attribuut kun je de volledige levenscyclus van elk werkitem volgen. Het vormt de basis voor procesmaps, het berekenen van doorlooptijden en het herkennen van verschillen in de route die items door het ontwikkelproces afleggen.
Waarom dit belangrijk is
Dit is de unieke sleutel die alle bijbehorende ontwikkelactiviteiten met elkaar verbindt. Zo kun je één werkitem van begin tot eind volgen.
Waar vind je dit?
Dit is het standaardveld 'key' voor een issue in het Jira Software Issue API-object.
Voorbeelden
PROJ-101CORE-5432API-789
|
|||
|
Tijdstip van gebeurtenis
EventTime
|
De exacte datum en tijd waarop een specifieke ontwikkelactiviteit of gebeurtenis plaatsvond. | ||
|
Beschrijving
Het tijdstip van de gebeurtenis is de timestamp waarop een activiteit plaatsvond. Dit vormt de tijdsbasis voor alle process mining-analyses en legt de chronologische volgorde van gebeurtenissen per case vast. Dit attribuut is nodig om alle tijdsgebonden metrieken te berekenen, waaronder doorlooptijden, verwerkingstijden en wachttijden tussen activiteiten. Hiermee kun je de procesprestaties in de tijd analyseren en zien waar en wanneer vertragingen optreden in de levenscyclus van ontwikkeling.
Waarom dit belangrijk is
Deze timestamp is nodig om gebeurtenissen in de juiste volgorde te zetten en alle duurmetingen te berekenen. Die zijn belangrijk om de procesefficiëntie te begrijpen en vertragingen op te sporen.
Waar vind je dit?
Dit komt overeen met de timestamp 'created' van elke vermelding in de changelog of geschiedenis van een issue.
Voorbeelden
2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
|
|||
|
Bronsysteem
SourceSystem
|
Het systeem waaruit de gegevens over de levenscyclus van ontwikkeling zijn gehaald. | ||
|
Beschrijving
Dit attribuut geeft aan waar de data vandaan komt. Voor dit proces is dat altijd 'Jira Software'. Het is handig om de herkomst te onderscheiden wanneer je meerdere bronsystemen in één analyse combineert. In een bredere IT-omgeving maakt het vermelden van het bronsysteem de herkomst van data duidelijk. Ook helpt het bij het beheren van datakwaliteit en integraties tussen verschillende platforms.
Waarom dit belangrijk is
Maakt de herkomst van data duidelijk. Dat is belangrijk wanneer je data uit meerdere systemen combineert of werkt aan datagovernance en audits.
Waar vind je dit?
Dit is een vaste waarde die je tijdens de data-extractie en -transformatie toevoegt.
Voorbeelden
Jira Software
|
|||
|
Laatste data-update
LastDataUpdate
|
De timestamp die aangeeft wanneer de data voor dit proces voor het laatst vanuit het bronsysteem is bijgewerkt. | ||
|
Beschrijving
Dit attribuut registreert de datum en tijd van de meest recente data-extractie uit Jira Software. Zo zie je hoe actueel de geanalyseerde data is. De tijd van de laatste update is belangrijk om te weten hoe actueel de procesinzichten zijn. Analisten en zakelijke gebruikers kunnen hiermee controleren of ze met actuele data werken en zien tot welk moment gebeurtenissen in de analyse zijn meegenomen.
Waarom dit belangrijk is
Geeft aan hoe actueel de data is. Zo kun je controleren of analyses en dashboards de meest recente processtatus weergeven.
Waar vind je dit?
Deze timestamp wordt gegenereerd en vastgelegd aan het einde van het extractie-, transformatie- en laadproces (ETL).
Voorbeelden
2024-03-15T02:00:00Z2024-03-16T02:00:00Z
|
|||
|
Itemprioriteit
ItemPriority
|
De prioriteit van het ontwikkelitem, die aangeeft hoe dringend het is. | ||
|
Beschrijving
De itemprioriteit geeft het relatieve belang of de urgentie van een werkitem aan. Jira heeft een standaardveld 'priority' met instelbare niveaus, zoals Highest, High, Medium en Low. Door prioriteiten te analyseren, kun je controleren of het proces wordt gevolgd en bottlenecks bij urgente items opsporen. Het dashboard 'Priority Item Conformance Check' gebruikt dit attribuut bijvoorbeeld om te controleren of items met hoge prioriteit sneller worden afgehandeld, of juist in dezelfde wachtrijen blijven staan als items met een lage prioriteit.
Waarom dit belangrijk is
Helpt te analyseren of items met hoge prioriteit sneller worden afgehandeld dan items met lage prioriteit en of ze een kortere route volgen, zodat SLA’s worden gehaald.
Waar vind je dit?
Dit is het veld 'priority' in het object 'fields' van het Jira Issue API-antwoord.
Voorbeelden
HoogsteHoogGemiddeldLaag
|
|||
|
Itemstatus
ItemStatus
|
De huidige status van het ontwikkelitem in de workflow. | ||
|
Beschrijving
Dit attribuut geeft aan in welke fase het ontwikkelitem zich op een bepaald moment bevindt, zoals 'In Progress', 'In Review' of 'Done'. De opeenvolgende statuswijzigingen leveren de activiteiten op voor process mining. Het attribuut 'Activity' staat voor de wijzigingsgebeurtenis, terwijl 'ItemStatus' de status van het item weergeeft. Je kunt dit gebruiken als dimensie om te filteren en analyseren. Zo zie je hoeveel items zich in een bepaalde status bevinden en kun je kenmerken onderzoeken van items die lang in dezelfde status blijven.
Waarom dit belangrijk is
Geeft een momentopname van de plek van een item in de levenscyclus. Dit is nodig voor statusanalyses en om te begrijpen wat de huidige status is van werk dat nog loopt.
Waar vind je dit?
Dit is het veld 'status' in het object 'fields' van het Jira Issue API-antwoord.
Voorbeelden
Te doenIn uitvoeringIn beoordelingAfgerond
|
|||
|
Itemtype
ItemType
|
De classificatie van het ontwikkelitem, zoals Bug, Story, Task of Epic. | ||
|
Beschrijving
Het itemtype geeft aan wat voor werk er wordt uitgevoerd. Jira gebruikt hiervoor het standaardveld 'issuetype'. Verschillende soorten werkitems hebben vaak een eigen workflow. Dit attribuut is belangrijk voor vergelijkende analyses. Je kunt het proces filteren op een bepaald type werk, bijvoorbeeld om de levenscyclus van een 'Bug' te vergelijken met die van een 'Story'. Zo zie je of bepaalde soorten werk vaker vertraging oplopen, herstelwerk vragen of afwijken van het standaardproces.
Waarom dit belangrijk is
Hiermee kun je de procesanalyse opdelen en vergelijken hoe verschillende soorten werk, zoals bugs en nieuwe functies, worden afgehandeld en waar de processen van elkaar verschillen.
Waar vind je dit?
Dit is het veld 'issuetype' in het object 'fields' van het Jira Issue API-antwoord.
Voorbeelden
StoryBugTaskEpic
|
|||
|
Projectnaam
ProjectName
|
De naam van het Jira-project waartoe het ontwikkelitem behoort. | ||
|
Beschrijving
In Jira zijn alle werkitems ingedeeld in projecten. De projectnaam geeft context op hoofdlijnen en verwijst vaak naar een product, team of initiatief. Dit attribuut is handig om te filteren en projecten te vergelijken. Je kunt het SDLC-proces voor verschillende projecten of producten analyseren en vergelijken. Zo zie je welke projecten efficiënter werken, waar meer herstelwerk nodig is en of teams verschillende procesvarianten volgen.
Waarom dit belangrijk is
Hiermee kun je de procesanalyse opdelen naar project, product of team. Zo kun je prestaties vergelijken en goede werkwijzen herkennen.
Waar vind je dit?
Dit is het veld 'project' in het object 'fields' van het Jira Issue API-antwoord.
Voorbeelden
Ontwikkeling van mobiele appKernplatformDatawetenschap
|
|||
|
Teamnaam
TeamName
|
Het ontwikkelteam dat verantwoordelijk is voor het werkitem. | ||
|
Beschrijving
Dit is het agile- of featureteam dat aan het ontwikkelitem werkt. In Jira wordt dit vaak vastgelegd in een aangepast veld, of afgeleid uit andere informatie, zoals het project of een specifiek onderdeel. Dit attribuut is nodig om prestaties per team te analyseren. Je kunt dashboards filteren op metrieken zoals doorlooptijd, herstelwerk en doorvoer per team. Het wordt gebruikt in de dashboards 'Inter-Phase Handoff Efficiency' en 'Developer Workload & Item Progress'.
Waarom dit belangrijk is
Hiermee kun je de prestaties van ontwikkelteams meten en vergelijken, goed presterende teams herkennen en goede werkwijzen delen.
Waar vind je dit?
Dit is vaak een aangepast veld in Jira. Vraag de Jira-beheerder welk veld hiervoor wordt gebruikt. Dat kan bijvoorbeeld 'Team', 'Squad' of iets vergelijkbaars zijn.
Voorbeelden
Team PhoenixKernservicesUI/UX Avengers
|
|||
|
Toegewezen aan
Assignee
|
De gebruiker die op dit moment verantwoordelijk is voor het ontwikkelitem. | ||
|
Beschrijving
De toegewezen gebruiker is in de huidige fase verantwoordelijk voor het werkitem. In Jira is dit een standaardveld dat verandert wanneer het item naar andere personen of teams gaat. Door te analyseren aan wie werk is toegewezen, krijg je zicht op de verdeling van werk en werklast en op overdrachtsmomenten. Je ziet welke ontwikkelaars of teams bij bepaalde fasen betrokken zijn, waar een bottleneck zit en hoe het werk binnen de organisatie wordt verdeeld.
Waarom dit belangrijk is
Geeft aan welke gebruiker of bron verantwoordelijk is voor een activiteit. Zo kun je de werklast analyseren, middelen beheren en overdrachten tussen personen volgen.
Waar vind je dit?
Dit is het veld 'assignee' in het object 'fields' van het Jira Issue API-antwoord.
Voorbeelden
Alice SmithBob JohnsonNiet toegewezen
|
|||
|
Eindtijd gebeurtenis
EventEndTime
|
De timestamp waarop een activiteit of status is afgerond. | ||
|
Beschrijving
Dit attribuut geeft aan wanneer een activiteit is afgerond. Het is de timestamp van de volgende activiteit in de reeks voor een bepaalde case. 'EventTime' (StartTime) geeft aan wanneer een activiteit begint, terwijl EventEndTime het einde markeert. Het verschil tussen deze timestamps is de verwerkingstijd van de activiteit. Dit is nodig om de KPI 'Average Stage Processing Time' te berekenen en dashboards te maken die de duur van activiteiten analyseren.
Waarom dit belangrijk is
Geeft het eindpunt van een activiteit aan. Zo kun je de duur van elke processtap berekenen, wat nodig is voor bottleneckanalyse.
Waar vind je dit?
Dit is een afgeleid attribuut. Bij een bepaalde gebeurtenis is de eindtijd gelijk aan de starttijd van de volgende gebeurtenis voor dezelfde case.
Voorbeelden
2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
|
|||
|
Fixversie
FixVersion
|
De softwareversie waarin het ontwikkelitem daadwerkelijk is opgelost en uitgebracht. | ||
|
Beschrijving
De 'Fix Version' in Jira geeft aan in welke release het afgeronde werk voor een item is opgenomen. Hiermee wordt het concrete resultaat van de ontwikkelinspanning vastgelegd. Dit attribuut geeft de werkelijke release aan. Je kunt die vergelijken met 'PlannedReleaseVersion' om de leverprestaties te analyseren. Ook kun je hiermee alle items van een specifieke release groeperen en zien wat er is opgeleverd.
Waarom dit belangrijk is
Bevestigt in welke release het werk is opgenomen. Zo kun je releases analyseren en bijhouden welke functies zijn opgeleverd.
Waar vind je dit?
Dit komt overeen met het veld 'fixVersions' in het Jira Issue API-antwoord.
Voorbeelden
v2.1.1-hotfixv3.0.0-hoofdreleasev2.2.0
|
|||
|
Geplande release
PlannedReleaseVersion
|
De doelsoftwareversie of release waarin het item volgens planning wordt geïmplementeerd. | ||
|
Beschrijving
Dit attribuut, vaak het veld 'Affects Version/s' in Jira, geeft aan voor welke release een functie of oplossing bedoeld is. Het vormt een deadline of doel voor het afronden van het werk. Dit attribuut is belangrijk voor de KPI 'On-Time Release Delivery Rate'. Door de werkelijke implementatiedatum te vergelijken met de geplande releasedatum van deze versie, kun je meten of de planning wordt gehaald en hoe voorspelbaar het releaseproces is.
Waarom dit belangrijk is
Bepaalt de beoogde leverdatum of release. Hiermee kun je het percentage tijdige opleveringen berekenen en analyseren of de planning wordt gehaald.
Waar vind je dit?
Dit komt overeen met de velden 'versions' of 'fixVersions' in de Jira Issue API. Welk veld voor de planning wordt gebruikt, kan verschillen.
Voorbeelden
Versie 2.1Release Q1 2024Lancering van Project Phoenix
|
|||
|
Is herstelwerk
IsRework
|
Een aanduiding die aangeeft of een activiteit deel uitmaakt van een herstelwerkcyclus. | ||
|
Beschrijving
Dit booleaanse attribuut is waar als een activiteit een stap terug in het proces weergeeft, bijvoorbeeld wanneer een item na een mislukte QA-test teruggaat naar ‘Ontwikkeling gestart’. Dit wordt bepaald door de activiteitenreeks van een case te analyseren. Herstelwerk herkennen is belangrijk om de efficiëntie en kwaliteit van processen te verbeteren. Dit attribuut ondersteunt rechtstreeks de KPI ‘Percentage herstelwerkactiviteiten’ en het dashboard ‘Frequentie en routes van herstelwerkcycli’. Zo kun je de verspilde inspanning kwantificeren en de oorzaken opsporen van kwaliteitsproblemen die tot herstelwerk leiden.
Waarom dit belangrijk is
Markeert expliciet activiteiten die deel uitmaken van inefficiënte herstelwerkcycli. Zo kun je verspilling en kwaliteitsproblemen in het proces nauwkeurig meten en analyseren.
Waar vind je dit?
Dit is een berekend attribuut. Je moet eerst de verwachte processtroom definiëren en daarna elke activiteit markeren die afwijkt door terug te gaan naar een eerdere fase.
Voorbeelden
truefalse
|
|||
|
Melder
Reporter
|
De gebruiker die het ontwikkelitem oorspronkelijk heeft aangemaakt of gemeld. | ||
|
Beschrijving
De melder is degene die de issue in Jira heeft aangemaakt. Dat kan een ontwikkelaar, QA-tester, productmanager of klant zijn, bijvoorbeeld via een servicedesk-koppeling. Door melders te analyseren, krijg je zicht op waar het werk vandaan komt. Je kunt bijvoorbeeld nagaan of bugs die het QA-team meldt een andere levenscyclus hebben dan bugs die klanten melden. Ook helpt dit om communicatiepatronen en de informatiestroom aan het begin van het proces te begrijpen.
Waarom dit belangrijk is
Geeft aan waar het werkitem vandaan komt. Je kunt hiermee patronen analyseren op basis van wie tasks aanmaakt of bugs meldt.
Waar vind je dit?
Dit is het veld 'reporter' in het object 'fields' van het Jira Issue API-antwoord.
Voorbeelden
Charles DarwinMarie CurieIsaac Newton
|
|||
|
Onderdeel
Component
|
Een subsectie of functioneel gebied van een project waartoe het item behoort. | ||
|
Beschrijving
In Jira worden onderdelen gebruikt om issues binnen een project in kleinere, beter beheersbare groepen in te delen. Een onderdeel kan bijvoorbeeld een functiegebied zijn, zoals 'Gebruikersauthenticatie', een technische laag zoals 'Backend API' of een module zoals 'Rapportage'. Door per onderdeel te analyseren, krijg je een gedetailleerder beeld van het ontwikkelproces. Je kunt zien of bepaalde delen van de applicatie meer bugs opleveren, langere ontwikkelcycli hebben of vaker herstelwerk vragen. Dat kan wijzen op technische schuld of complexiteit.
Waarom dit belangrijk is
Hiermee kun je het proces opdelen naar functionele of technische productgebieden en zien welke onderdelen vertragingen of kwaliteitsproblemen veroorzaken.
Waar vind je dit?
Dit is het standaardveld 'components' in het object 'fields' van het Jira Issue API-antwoord.
Voorbeelden
GebruikersinterfaceDatabaseAPI-gatewayAuthenticatie
|
|||
|
Oplossing voor item
ItemResolution
|
De uiteindelijke uitkomst of reden waarom een ontwikkelitem is gesloten. | ||
|
Beschrijving
De oplossing geeft aan waarom een item is gesloten. De status kan bijvoorbeeld 'Closed' zijn, terwijl de oplossing 'Done', 'Won't Do', 'Duplicate' of 'Cannot Reproduce' is. Zo krijg je belangrijke context over de uitkomst van het werk. Door de oplossing te analyseren, kun je onderscheid maken tussen werk dat succesvol is afgerond en items die zijn geannuleerd of afgewezen. Dat is belangrijk voor kwaliteitsanalyses en om te zien hoeveel waardevol werk daadwerkelijk is afgerond, tegenover werk aan items die uiteindelijk zijn geschrapt.
Waarom dit belangrijk is
Maakt onderscheid tussen afgeronde items en items die om een andere reden zijn gesloten. Dat is nodig voor een nauwkeurige analyse van productiviteit en kwaliteit.
Waar vind je dit?
Dit is het veld 'resolution' in het object 'fields' van het Jira Issue API-antwoord. Het wordt meestal alleen ingevuld wanneer een issue is gesloten.
Voorbeelden
AfgerondWordt niet uitgevoerdDuplicaatNiet reproduceerbaar
|
|||
|
Sprintnaam
SprintName
|
De naam van de agile sprint waaraan het ontwikkelitem is toegewezen. | ||
|
Beschrijving
Voor teams die Scrum gebruiken, is een sprint een vaste periode waarin een reeks werkzaamheden wordt afgerond. Dit attribuut bevat de naam of identificatiecode van de sprint waartoe een item behoort. Analyse per sprint is belangrijk voor process mining in agile teams. Je kunt de prestaties van afzonderlijke sprints beoordelen, zien welk werk doorschuift en de voortgang ten opzichte van sprintdoelen volgen. Dit geeft een specifiekere tijdscontext dan algemene datumbereiken.
Waarom dit belangrijk is
Geeft agile teams belangrijke context om de procesefficiëntie en doorvoer per sprint te analyseren.
Waar vind je dit?
Deze informatie staat meestal in een aangepast veld 'Sprint', dat wordt beheerd door Jira Software (Agile). De data is beschikbaar via de Issue API.
Voorbeelden
PROJ-sprint 1Q4-2023-sprint 3November PI-sprint 2
|
|||
|
Totale doorlooptijd
CycleTime
|
De totale doorlooptijd van begin tot eind voor een ontwikkelitem. | ||
|
Beschrijving
De doorlooptijd meet de totale tijd vanaf het aanmaken van een ontwikkelitem tot de uiteindelijke afhandeling, bijvoorbeeld de implementatie in productie. De berekening gebeurt op caseniveau: de timestamp van de eerste gebeurtenis wordt afgetrokken van die van de laatste gebeurtenis. Dit is een belangrijke KPI om de totale snelheid en efficiëntie van het proces te meten. De KPI ‘Gemiddelde doorlooptijd van begin tot eind’ en het dashboard ‘Analyse van de totale doorlooptijd van de softwareontwikkelingscyclus’ zijn rechtstreeks op deze berekening gebaseerd. De doorlooptijd verkorten is vaak een belangrijk doel van procesverbetering.
Waarom dit belangrijk is
Meet de snelheid van het ontwikkelproces van begin tot eind en geeft een belangrijke prestatie-indicator voor de algehele efficiëntie en leveringssnelheid.
Waar vind je dit?
Dit is een berekend attribuut op caseniveau. Het is de timestamp van de laatste gebeurtenis min de timestamp van de eerste gebeurtenis voor een bepaalde ‘DevelopmentItem’.
Voorbeelden
12096002592000604800
|
|||
|
Wachttijd bij overdracht
HandoffWaitTime
|
De stilstandtijd tussen twee opeenvolgende activiteiten. | ||
|
Beschrijving
Deze metriek berekent de wachttijd tussen het afronden van de ene activiteit en het starten van de volgende. Het is de tijd waarin werk stilligt, in afwachting van iemand die het oppakt. Deze metriek is belangrijk voor de KPI ‘Gemiddelde wachttijd bij overdracht’ en het dashboard ‘Efficiëntie van overdrachten tussen fasen’. Lange wachttijden bij overdrachten wijzen vaak op afstemmingsproblemen, beperkte capaciteit of gebrekkige communicatie tussen teams, bijvoorbeeld tussen ontwikkeling en QA. Minder stilstand helpt de totale doorlooptijd te verkorten.
Waarom dit belangrijk is
Brengt stilstand en wachttijd in het proces in beeld. Zo worden inefficiënte overdrachten tussen teams of personen en problemen met de afstemming zichtbaar.
Waar vind je dit?
Dit is een berekende metriek: de starttijd van een activiteit min de eindtijd van de vorige activiteit voor dezelfde case.
Voorbeelden
017280043200
|
|||
Activiteiten in de softwareontwikkelingscyclus
| Activiteit | Beschrijving | ||
|---|---|---|---|
|
Geïmplementeerd in productie
|
Deze gebeurtenis markeert het moment waarop de codewijzigingen voor het ontwikkelitem live gaan in de productieomgeving. Dit kan worden afgeleid uit een laatste statuswijziging naar 'Done' of 'Released', of worden vastgelegd via een expliciete gebeurtenis uit een gekoppelde CI/CD-tool. | ||
|
Waarom dit belangrijk is
Dit is het belangrijkste eindpunt voor een geslaagd proces. Het is nodig om de totale end-to-end-doorlooptijd te berekenen en de implementatiefrequentie en doorvoer te meten.
Waar vind je dit?
Dit kan worden afgeleid uit de changelog van de Jira-issue wanneer de status verandert in 'Released' of 'Done'. Voor meer nauwkeurigheid kun je implementatiegebeurtenissen vastleggen die CI/CD-tools zoals Jenkins of Bamboo doorgeven, of de functie Deployments in Jira gebruiken.
Vastleggen
Timestamp van de statuswijziging naar 'Done' of 'Released'.
Gebeurtenistype
inferred
|
|||
|
Ontwikkeling gestart
|
Dit is het moment waarop een ontwikkelaar actief aan het ontwikkelitem begint te werken. Meestal is dit af te leiden uit een statuswijziging in de Jira-workflow, bijvoorbeeld wanneer de status van het issue verandert in ‘In Progress’. | ||
|
Waarom dit belangrijk is
Dit is een belangrijk moment om de actieve ontwikkeltijd te meten. Je kunt wachttijd onderscheiden van werk dat waarde toevoegt. Dat helpt bottlenecks te vinden.
Waar vind je dit?
Af te leiden uit de changelog van het Jira-issue. Dit is de timestamp waarop het veld ‘status’ voor het eerst verandert in ‘In Progress’, ‘In Development’ of een vergelijkbare actieve status.
Vastleggen
Timestamp van de statuswijziging naar ‘In Progress’.
Gebeurtenistype
inferred
|
|||
|
Ontwikkelitem aangemaakt
|
Dit is het begin van de levenscyclus: een nieuw ontwikkelitem, zoals een story, bug of taak, wordt vastgelegd in Jira. Het systeem registreert deze gebeurtenis voor elk issue met een aanmaaktimestamp. | ||
|
Waarom dit belangrijk is
Deze activiteit markeert het begin van het proces. Dat is nodig om de totale doorlooptijd te berekenen en het aantal binnenkomende items bij te houden.
Waar vind je dit?
Dit is een basisgebeurtenis voor elk Jira-issue. De aanmaaktimestamp staat in het veld ‘created’ van het issuerecord en is beschikbaar via de Jira API.
Vastleggen
Het timestampveld ‘created’ van het Jira Issue-object.
Gebeurtenistype
explicit
|
|||
|
QA-test afgerond
|
Dit geeft aan dat het ontwikkelitem alle kwaliteitscontroles heeft doorstaan en klaar is voor de volgende fase, zoals User Acceptance Testing of release. Dit is af te leiden uit een statuswijziging vanuit de belangrijkste teststatus. | ||
|
Waarom dit belangrijk is
Dit markeert het einde van een belangrijke kwaliteitscontrole. Door de duur van de QA-fase te analyseren, kun je testprocessen en de inzet van medewerkers verbeteren.
Waar vind je dit?
Af te leiden uit de changelog van het Jira-issue. Dit is de timestamp waarop het veld ‘status’ verandert van ‘In QA’ naar een volgende status, zoals ‘Ready for UAT’ of ‘Ready for Release’.
Vastleggen
Timestamp van de statuswijziging van ‘In QA’ naar ‘Ready for UAT’.
Gebeurtenistype
inferred
|
|||
|
QA-test gestart
|
Deze gebeurtenis markeert het begin van de formele kwaliteitscontrole van het ontwikkelitem. Dit is af te leiden uit een statuswijziging in Jira wanneer het issue de status ‘In QA’, ‘In Testing’ of ‘Ready for Testing’ krijgt. | ||
|
Waarom dit belangrijk is
Dit is een belangrijk moment waarop de kwaliteitscontrole begint. De tijd tussen ‘Ontwikkeling afgerond’ en dit moment laat zien of er vertraging zit in de overdracht tussen ontwikkel- en QA-teams.
Waar vind je dit?
Af te leiden uit de changelog van het Jira-issue. Dit is de timestamp waarop het veld ‘status’ verandert in een aangewezen QA-teststatus, zoals ‘In QA’.
Vastleggen
Timestamp van de statuswijziging naar ‘In QA’ of ‘In Testing’.
Gebeurtenistype
inferred
|
|||
|
UAT goedgekeurd
|
Dit geeft aan dat User Acceptance Testing succesvol is afgerond en belanghebbenden de release hebben goedgekeurd. Dit is af te leiden uit een statuswijziging van ‘In UAT’ naar bijvoorbeeld ‘Ready for Release’ of ‘Done’. | ||
|
Waarom dit belangrijk is
Deze mijlpaal bevestigt dat de business akkoord is en dat het item klaar is voor implementatie in productie. Dit is een belangrijke controle om te zorgen dat het opgeleverde werk aan de verwachtingen van gebruikers voldoet.
Waar vind je dit?
Afgeleid uit de changelog van de Jira-issue. Dit is de timestamp waarop de status verandert van 'In UAT' naar de volgende status in de workflow, wat aangeeft dat het item is goedgekeurd.
Vastleggen
Timestamp van de statuswijziging van 'In UAT' naar 'Ready for Release'.
Gebeurtenistype
inferred
|
|||
|
Codereview uitgevoerd
|
Dit geeft aan dat een collega of teamleider de code heeft beoordeeld op kwaliteit, standaarden en werking. Dit is af te leiden uit een statuswijziging, bijvoorbeeld van ‘In Review’ naar ‘Ready for QA’, of uit geïntegreerde ontwikkeltools. | ||
|
Waarom dit belangrijk is
Dit is een belangrijke kwaliteitscontrole. Door de duur en uitkomsten, zoals herstelwerk, te analyseren, kun je de codekwaliteit verbeteren en fouten later in het proces beperken.
Waar vind je dit?
Meestal af te leiden uit de changelog van het Jira-issue wanneer de status een ‘Code Review’-status verlaat. Als tools voor codebeheer zoals Bitbucket of GitHub zijn geïntegreerd, kan het ook een expliciete gebeurtenis zijn.
Vastleggen
Timestamp van de statuswijziging van ‘In Review’ naar de volgende status.
Gebeurtenistype
inferred
|
|||
|
Item klaar voor ontwikkeling
|
Dit geeft aan dat een ontwikkelitem volledig is uitgewerkt, beoordeeld en geprioriteerd, zodat een ontwikkelaar ermee aan de slag kan. Meestal is dit af te leiden uit een statuswijziging in de workflow, bijvoorbeeld van ‘Backlog’ naar ‘To Do’ of ‘Ready for Dev’. | ||
|
Waarom dit belangrijk is
Door dit bij te houden, meet je hoe klaar de backlog is en hoelang items wachten voordat de ontwikkeling begint. Zo kun je de tijd voor planning en uitwerking onderscheiden van de actieve ontwikkeltijd.
Waar vind je dit?
Af te leiden uit de changelog van het Jira-issue. Zoek naar een timestamp waarop het veld ‘status’ verandert in bijvoorbeeld ‘Ready for Dev’, ‘To Do’ of ‘Selected for Development’.
Vastleggen
Timestamp van de statuswijziging naar een status waarin het item klaarstaat voor ontwikkeling.
Gebeurtenistype
inferred
|
|||
|
Ontwikkeling afgerond
|
Deze activiteit geeft aan dat de ontwikkelaar klaar is met coderen en dat het item klaar is voor de volgende fase, zoals codereview of testen. Dit is af te leiden uit een statuswijziging in Jira, bijvoorbeeld van ‘In Progress’ naar ‘In Review’ of ‘Ready for QA’. | ||
|
Waarom dit belangrijk is
Dit markeert het einde van de ontwikkelfase. Zo kun je de codeertijd analyseren en zien hoe efficiënt items aan het QA-team worden overgedragen.
Waar vind je dit?
Af te leiden uit de changelog van het Jira-issue. Leg de timestamp vast waarop het veld ‘status’ verandert van een actieve ontwikkelstatus naar een volgende status, zoals ‘In Review’ of ‘Ready for QA’.
Vastleggen
Timestamp van de statuswijziging van ‘In Progress’ naar ‘In Review’ of ‘Ready for QA’.
Gebeurtenistype
inferred
|
|||
|
Ontwikkelitem geannuleerd
|
Dit geeft aan dat een ontwikkelitem is beëindigd voordat het was afgerond. Dit wordt afgeleid uit een statuswijziging naar een eindstatus zoals 'Canceled', 'Rejected' of 'Won't Do', vaak in combinatie met een specifieke oplossing. | ||
|
Waarom dit belangrijk is
Deze activiteit houdt uitkomsten bij waarbij het proces niet succesvol is afgerond. Door te analyseren waarom items worden geannuleerd, kun je problemen met planning, prioritering of het vastleggen van vereisten opsporen.
Waar vind je dit?
Afgeleid uit de changelog van de Jira-issue. Dit is de timestamp waarop de 'status' van de issue verandert in 'Canceled' of 'Won't Do' en een bijbehorende oplossing wordt ingesteld.
Vastleggen
Timestamp van de statuswijziging naar 'Canceled', 'Rejected' of 'Won't Do'.
Gebeurtenistype
inferred
|
|||
|
Ontwikkelitem gesloten
|
Dit is de laatste administratieve handeling en bevestigt dat er geen werk meer aan het item wordt verwacht. Dit wordt vaak afgeleid uit een statuswijziging naar 'Closed' en het invullen van het veld 'Resolution'. | ||
|
Waarom dit belangrijk is
Dit markeert het absolute einde van de levenscyclus van een item. Door dit te vergelijken met 'Deployed to Production' kun je administratieve vertraging of een periode van monitoring na implementatie herkennen.
Waar vind je dit?
Afgeleid uit de changelog van de Jira-issue. Dit is de timestamp waarop het veld 'status' verandert in 'Closed' en een oplossing wordt ingesteld.
Vastleggen
Timestamp van de statuswijziging naar 'Closed'.
Gebeurtenistype
inferred
|
|||
|
QA-test mislukt
|
Dit geeft aan dat het QA-team een fout heeft gevonden en het ontwikkelitem terugstuurt naar de ontwikkelaars voor herstelwerk. Dit is af te leiden uit een statuswijziging terug naar een eerdere status, bijvoorbeeld van ‘In QA’ naar ‘In Progress’ of ‘To Do’. | ||
|
Waarom dit belangrijk is
Deze activiteit helpt herstelrondes te herkennen. Door bij te houden hoe vaak dit gebeurt, meet je de kosten van kwaliteitsproblemen en zie je waar verbetering nodig is in de ontwikkeling of de vereisten.
Waar vind je dit?
Af te leiden uit de changelog van het Jira-issue. Leg dit vast wanneer het veld ‘status’ verandert van een teststatus, zoals ‘In QA’, naar een eerdere ontwikkelstatus, zoals ‘In Progress’.
Vastleggen
Timestamp van de statuswijziging van een teststatus naar een ontwikkelstatus.
Gebeurtenistype
inferred
|
|||
|
UAT gestart
|
Dit markeert het begin van User Acceptance Testing, waarin belanghebbenden uit de business of eindgebruikers de nieuwe functionaliteit beoordelen. Dit is af te leiden uit een statuswijziging in Jira naar bijvoorbeeld ‘In UAT’ of ‘User Acceptance Testing’. | ||
|
Waarom dit belangrijk is
Deze activiteit houdt bij wanneer de laatste validatiefase voor de release begint. Door de duur te analyseren, zie je vertragingen door de beschikbaarheid van belanghebbenden of feedbackrondes.
Waar vind je dit?
Af te leiden uit de changelog van het Jira-issue. Dit is de timestamp waarop het veld ‘status’ wordt bijgewerkt naar ‘In UAT’ of een vergelijkbare aangewezen status.
Vastleggen
Timestamp van de statuswijziging naar ‘In UAT’.
Gebeurtenistype
inferred
|
|||
|
Voorbereid voor release
|
Geeft aan dat het ontwikkelitem alle controles heeft doorstaan en is opgenomen in een specifieke softwareversie, klaar voor implementatie. Dit wordt vaak afgeleid wanneer de status van een issue verandert in 'Ready for Release' of wanneer het veld 'Fix Version' is ingevuld. | ||
|
Waarom dit belangrijk is
Deze activiteit helpt bij het volgen van de releasegereedheid en de tijd die items wachten op een implementatiemoment nadat al het ontwikkel- en testwerk is afgerond.
Waar vind je dit?
Meestal afgeleid uit de changelog van de Jira-issue, wanneer de status verandert in 'Ready for Release'. Dit kan ook worden afgeleid uit de timestamp waarop het veld 'Fix Version/s' wordt ingevuld.
Vastleggen
Timestamp van de statuswijziging naar 'Ready for Release' of van het invullen van 'Fix Version'.
Gebeurtenistype
inferred
|
|||
Extractiegidsen
Klaar om te beginnen?
Bereid je data met deze template voor en begin vandaag nog met het optimaliseren van de softwareontwikkelingscyclus. Krijg inzicht waarmee je sneller kunt opleveren en de kwaliteit verbetert.
Optimaliseer de softwareontwikkelingscyclus in Jira Software, begin vandaag!
Spoor inefficiënties op en verkort de doorlooptijd in de softwareontwikkelingscyclus met 30%.
Geen creditcard nodig. Begin binnen enkele minuten met optimaliseren.