Oprettelse af KPI’er for agile softwareudviklingshold
Ethvert produktivt softwareudviklingsteam holder styr på deres forbedringer ved hjælp af et sæt udvalgte indikatorer kaldet KPI-udviklingsmetrikker. Dette er de 5 mest essentielle KPI-udviklingsmetrikker (Key Performance Indicator), som du bør begynde at spore i dag.
Har du nogensinde arbejdet med et ingeniørteam, hvor der ikke blev målt KPI-metrikker? Hvis du har, så ved du sikkert, hvor svært det er at sige, om teamet er på rette vej til udgivelse eller ej.
Sandheden er, at hvis du ønsker at nå dine forretningsmål, skal du sikre, at din software opfylder alle kravene. For at gøre det skal du implementere KPI-teknikmålinger i udviklingsprocesserne.
Gennem at opstille KPI-teknikmålinger for dit softwareudviklingsteam undgår du dårlig kvalitet og overskredne tidsfrister. Det, du får, er et produktivt team og et produkt af høj kvalitet.
Her er fem vigtige KPI-udviklingsmetrikker, som du bør spore for at nå dine forretningsmål.
Sprint Burndown
Hvad er Sprint Burndown?
Agile-teams organiserer deres udvikling i sprints. En sprint burndown måler, hvor meget arbejde teamet har udført i løbet af et sprint.
Hvad er fordelene?
- En sprint burndown er fantastisk til at holde teamet opmærksomt på eventuelle vejspærringer, der opstår.
- Gennem at måle sprint breakdown kan du kontrollere, om dit team opfylder sin prognose.
- Med et sprint breakdown-diagram kan teamet styre sine fremskridt. Hvis teamet opdager, at det måske ikke når sprintmålet, kan teammedlemmerne træffe passende foranstaltninger for at holde sig på sporet.
Hvordan måler du det?
Agile teams bruger sprintfordelingsdiagrammer til at visualisere deres arbejdsgang. Diagrammet har en x-akse, der repræsenterer tid, og en y-akse, der repræsenterer den resterende mængde arbejde, der mangler at blive udført. Du kan måle tiden i timer eller historiepunkter. Eller du kan finde på dine egne statistikker. Hovedformålet her er at få alt det forventede arbejde afsluttet ved sprintets afslutning.
Et værktøj, du kan bruge, er Jira Sprint Breakdown chart. For at bruge det skal du oprette en Jira Software-konto og et Jira Software Scrum-projekt.
Du vil se en lodret akse, der repræsenterer historiepunkter. Den vandrette akse viser tid. Den røde linje i diagrammet repræsenterer den mængde arbejde, der er tilbage i sprintet. Den grå linje er den faktiske arbejdslinje. Hvis den røde linje er under den grå linje, betyder det, at teamet er på rette vej. Hvis den røde linje derimod ligger over den grå linje, betyder det, at projektet er bagud i forhold til tidsplanen.
Release Burndown
Hvad er Release Burndown?
Release Burndown giver et overblik over udgivelsesforløbet. Det ligner Sprint burndown, men det er større i omfang. Den hjælper teams med at kontrollere, om det vil lykkes dem at frigive produktet inden en bestemt dato. Hvis de indser, at de er bagud i forhold til tidsplanen, kan de informere brugere og interessenter om forsinkelsen. Eller, hvis det ikke er tilfældet, kan de reducere omfanget af arbejdet for at frigive produktet til tiden.
Hvad er fordelene?
- Du kan kontrollere, hvor hurtigt dit team arbejder sig igennem backloggen.
- Du kan få indsigt i, hvordan tilføjet og fjernet arbejde påvirker dit teams fremskridt.
- Få forudsigelser om, hvor mange sprints det vil tage dit team at færdiggøre arbejdet.
Hvordan måler du det?
Release burndown måles ved hjælp af et diagram, der svarer til sprint breakdown-diagrammet. Forskellen er, at den vandrette akse nu repræsenterer sprints, og den lodrette akse repræsenterer det resterende arbejde (dage, timer eller story points).
Lad os f.eks. se på nedenstående billede. Det er et Jira release burndown-diagram. Du kan se, at teamet i første omgang har sat fire sprints og 43 story points. I løbet af disse fire sprints har teamet reduceret antallet af historier fra 43 til 26. Holdet har også forudsagt, at frigivelsen af produktet vil tage yderligere syv sprints, hvilket resulterer i 11 i alt.
Cyklustid
Hvad er cyklustid?
Cyklustid er en KPI-udviklingsmetrik, der måler, hvor meget tid holdet bruger på at arbejde på en opgave. Cyklustidsdiagrammer bruges af Scrum Masters og Product Owners til at kontrollere effektiviteten af udviklingsprocessen.
Hvad er fordelene?
- Det giver oplysninger om teamets samlede præstation.
- Det giver mulighed for at estimere færdiggørelsen af fremtidige opgaver.
- Du kan bemærke eventuelle flaskehalse og forsinkelser i arbejdsgangen.
Hvordan måler du det?
Den cykliske tid er lig med slutdatoen minus startdatoen. Hvis teamet f.eks. begynder arbejdet den 1. december og afslutter det den 10. december, er cyklustiden ni dage.
Hvis teamet starter arbejdet den 1. december og afslutter opgaven samme dag, så er din cyklustid ikke nul, men én. For projekter, der begynder og slutter på samme dag, er cyklustiden lig med slutdatoen minus startdatoen +1.
Du kan erstatte dage med uger, timer eller endda sprints.
Overvej at bruge cyklustidsdiagrammer til at visualisere din arbejdsgang. Disse diagrammer viser, hvor lang tid det tog at færdiggøre et problem i forhold til færdiggørelsesdagen.
Lad os f.eks. se på nedenstående diagram. På x-aksen kan du se den dato, hvor opgaven blev afsluttet, og på y-aksen kan du se den tid, der er brugt. De grønne cirkler er opgaver. En solid cirkel angiver en klynge af opgaver, mens en åben cirkel angiver en enkelt opgave. Hvis du bruger et værktøj som Jira, kan du se opgavens nøgle, dens kode og gennemløbstiden ved at føre musen hen over cirklen. Den røde linje repræsenterer den gennemsnitlige cyklustid, og den blå linje repræsenterer den rullende gennemsnitlige cyklustid.
Endmålet er, at teamet skal have ensartede cyklustider for arbejdsopgaver, der har lignende story point-værdier. Lavere værdier betyder, at teamet arbejder effektivt, mens højere værdier kan indikere flaskehalse i arbejdsprocessen.
Team Velocity
Hvad er Team Velocity?
Velocity er en anden agil KPI-teknikmetrik, der måler mængden af arbejde, som et team gennemfører i løbet af et sprint. Mængden af arbejde måles normalt i story points eller timer.
Produktejere bruger velocity til at beregne, hvor hurtigt et team kan arbejde sig igennem backloggen. Hastighedsindekset er unikt for hvert team, og du bør ikke sammenligne hastigheden på tværs af teams.
Lad os for eksempel sige, at du ønsker at færdiggøre 300 story points i backloggen. Du ved, at udviklingsteamet i gennemsnit færdiggør omkring 50 story points pr. iteration. Med disse oplysninger i hånden kan du forudsige, at teamet har brug for seks iterationer for at fuldføre det nødvendige arbejde.
Hvad er fordelene?
- Det er meget nyttigt til prognoser.
- Det kan hjælpe med at planlægge fremtidige sprints.
- Det kan hjælpe dig med at forstå, om teamet er blokeret, eller om dine procesændringer virker.
Hvordan måler du det?
Hvis du har et stabilt team på plads, vil det lykkes dig at etablere en gennemsnitshastighed ved at måle mindst 5-7 sprints. Hvis dit sædvanlige sprint er ugentligt, og holdet gennemfører 250 story points over en periode på fem uger, er din gennemsnitlige hastighedshastighed 50 story points om ugen.
Lad os se på Jira-velocity-diagrammet nedenfor. De blå søjler repræsenterer engagement, og de grønne søjler repræsenterer det faktisk udførte arbejde. I sprint nummer 1 planlagde teamet 16 story points og gennemførte 16 story points. Dette indikerer, at deres estimater var korrekte. I det andet sprint planlagde teamet imidlertid 19 story points, men gennemførte kun 12. Dette tyder på, at de næste gang bør reducere deres plan.
Et inkonsekvent flow er en indikator for, at du har problemer i udviklingen og skal foretage ændringer.
Kumulativt flow
Hvad er kumulativt flow?
Cumulativt flow visualiserer status for dine tickets over en periode. Det viser skiftet af dine billetter fra en status til en anden, efterhånden som dit projekt skrider fremad.
Hvad er fordelene?
- Det er nyttigt til at identificere flaskehalse.
- Hjælper teams med at sikre, at arbejdsflowet er konsistent.
- Det viser dig, hvor stabilt dit arbejdsflow er.
- Det hjælper dig med at forstå, hvordan du kan gøre din proces mere forudsigelig.
Hvordan måler du det?
Den nemmeste måde at måle kumulativ arbejdsgang på er ved at bruge diagrammer. De visualiserer de tre vigtigste softwaretekniske målinger af dit flow, herunder cyklustid, gennemløb og igangværende arbejde.
Lad os se på nedenstående diagram. Den vandrette x-akse angiver tiden, mens den lodrette y-akse angiver arbejdsemnerne. De forskellige farver repræsenterer de forskellige arbejdsflowtilstande. Hvis båndene skrider fremad parallelt, betyder det, at din gennemstrømning er stabil. Det indikerer, at antallet af nye opgaver, der kommer ind i dit workflow, er det samme som antallet af opgaver, der forlader det.
Hvis et bånd bliver hurtigt smallere, betyder det, at du har mere kapacitet, end du har brug for. Du bør flytte kapaciteten for at optimere flowet.
Hvis et bånd udvides hurtigt, betyder det, at der kommer flere kort ind i den tilsvarende fase, end der er opgaver, der forlader den.
Summing Up
Tracking af de KPI-udviklingsmetrikker, der er skitseret ovenfor, kan føre til et vellykket resultat af produktudviklingsprocessen. Det vil lykkes dig i sidste ende at holde op med at tvivle på dit projekts fremskridt og få et detaljeret indblik i hver enkelt fase af udviklingslivscyklussen.
Hvis du ønsker at sætte en stopper for den onde cirkel med produkter af lav kvalitet, overskredne deadlines og fejl i koden, skal du begynde at implementere KPI-udvikling i dag. Det vil lykkes dig at frigive et produkt i topkvalitet uden ledsagende risici.
