Inrättande av KPI:er för agila mjukvaruteknikteam

apr 24, 2021
admin

Varje produktivt mjukvaruteknikteam håller reda på sina förbättringar med hjälp av en uppsättning utvalda indikatorer som kallas KPI-teknikmetriker. Det här är de 5 mest väsentliga KPI-utvecklingsmåtten (Key Performance Indicator) som du bör börja spåra idag.

Har du någonsin arbetat med ett ingenjörsteam där inga KPI-mått mättes? Om du har gjort det vet du förmodligen hur svårt det är att avgöra om teamet är på rätt spår för release eller inte.

Sanningen är att om du vill nå dina affärsmål måste du se till att din programvara uppfyller alla krav. För att göra det måste du implementera KPI-teknikmätningar i utvecklingsprocesserna.

Om du sätter upp KPI-teknikmätningar för ditt mjukvaruutvecklingsteam undviker du dålig kvalitet och missade deadlines. Du får ett produktivt team och en högkvalitativ produkt.

Här är fem viktiga KPI-utvecklingsmått som du bör spåra för att nå dina affärsmål.

Sprint Burndown

Vad är Sprint Burndown?

Agila team organiserar sin utveckling i sprintar. En sprint burndown mäter hur mycket arbete teamet slutförde under en sprint.

Vad är fördelarna?

  • En sprint burndown är bra för att hålla teamet medvetet om eventuella vägspärrar som uppstår.
  • Genom att mäta sprintfördelningen kan du kontrollera om teamet uppfyller sin prognos.
  • Med hjälp av ett sprintfördelningsdiagram kan teamet hantera sina framsteg. Om laget inser att det kanske inte når sprintmålet kan lagmedlemmarna vidta lämpliga åtgärder för att hålla sig på rätt spår.

Hur mäter du det?

Agila team använder sprintfördelningsdiagram för att visualisera sitt arbetsflöde. Diagrammet har en x-axel som representerar tid och en y-axel som representerar mängden arbete som återstår att slutföra. Du kan mäta tiden i timmar eller story points. Eller så kan du komma på din egen statistik. Huvudmålet här är att allt prognostiserat arbete ska vara slutfört i slutet av sprinten.

Ett verktyg du kan använda är Jira Sprint Breakdown chart. För att använda det måste du skapa ett Jira Software-konto och ett Jira Software Scrum-projekt.

Du kommer att se en vertikal axel som representerar story points. Den horisontella axeln visar tiden. Den röda linjen i diagrammet representerar den mängd arbete som återstår i sprinten. Den grå linjen är den faktiska arbetslinjen. Om den röda linjen ligger under den grå linjen betyder det att teamet är på rätt spår. Om den röda linjen däremot ligger över den grå linjen innebär detta att projektet ligger efter tidsplanen.

Bildkälla: Jira Sprint Burndown Chart

Release Burndown

Vad är Release Burndown?

Release Burndown ger en överblick över hur lanseringen fortskrider. Den liknar Sprint burndown, men är mer omfattande. Den hjälper teamen att kontrollera om de kommer att klara av att släppa produkten till ett visst datum. Om de inser att de ligger efter i tidsplanen kan de informera användare och intressenter om förseningen. Om så inte är fallet kan de minska omfattningen av arbetet för att släppa produkten i tid.

Vad är fördelarna?

  • Du kan kontrollera hur snabbt ditt team arbetar sig igenom backloggen.
  • Du kan få en inblick i hur tillagt och borttaget arbete påverkar teamets framsteg.
  • Göra förutsägelser om hur många sprintar det kommer att ta för ditt team att slutföra arbetet.

Hur mäter du det?

Release burndown mäts med hjälp av ett diagram som liknar sprintfördelningsdiagrammet. Skillnaden är att den horisontella axeln representerar sprintarna och den vertikala axeln representerar det återstående arbetet (dagar, timmar eller story points).

Till exempel kan vi titta på bilden nedan. Det är ett Jira-utgivningsdiagram. Du kan se att teamet inledningsvis har fastställt fyra sprintar och 43 story points. Under dessa fyra sprintar har teamet minskat antalet stories från 43 till 26. Teamet har också förutspått att lanseringen av produkten kommer att ta ytterligare sju sprintar, vilket ger totalt 11 sprintar.

Bildkälla: Jira Release Burndown Chart

Cykeltid

Vad är cykeltid?

Cykeltid är ett KPI-utvecklingsmått som mäter hur mycket tid teamet ägnar åt att arbeta med en uppgift. Diagram över cykeltid används av Scrum Masters och produktägare för att kontrollera effektiviteten i utvecklingsprocessen.

Vad är fördelarna?

  • Det ger information om teamets övergripande prestanda.
  • Det gör det möjligt att uppskatta slutförandet av framtida uppgifter.
  • Du kan märka eventuella flaskhalsar och fördröjningar i arbetsflödet.

Hur mäter du det?

Cykeltiden är lika med slutdatum minus startdatum. Om teamet till exempel börjar arbetet den 1 december och avslutar det den 10 december är cykeltiden nio dagar.

Om teamet börjar arbeta den 1 december och avslutar uppgiften samma dag är cykeltiden inte noll utan en. För projekt som börjar och slutar samma dag är cykeltiden lika med slutdatum minus startdatum +1.

Du kan ersätta dagar med veckor, timmar eller till och med sprintar.

Överväg att använda cykeltidsdiagram för att visualisera ditt arbetsflöde. Dessa diagram visar hur lång tid det tog att slutföra ett ärende jämfört med dagen för slutförandet.

Till exempel kan vi titta på diagrammet nedan. På x-axeln ser du datumet när uppgiften avslutades och på y-axeln ser du den tid som lagts ner. De gröna cirklarna är uppgifter. En heldragen cirkel indikerar ett kluster av problem, medan en öppen cirkel indikerar ett enskilt problem. Om du använder ett verktyg som Jira kan du se uppgiftens nyckel, dess kod och ledtiden genom att föra musen över cirkeln. Den röda linjen representerar den genomsnittliga cykeltiden och den blå linjen representerar den rullande genomsnittliga cykeltiden.

Slutmålet är att teamet ska ha konsekventa cykeltider för arbetsmoment som har liknande story point-värden. Lägre värden innebär att teamet arbetar effektivt, medan högre värden kan tyda på flaskhalsar i arbetsprocessen.

Bildkälla: Jira Cycle Time Chart

Team Velocity

Vad är Team Velocity?

Velocity är ett annat agilt KPI-teknikmått som mäter mängden arbete som ett team slutför under en sprint. Arbetsmängden mäts vanligtvis i story points eller timmar.

Produktägare använder velocity för att beräkna hur snabbt ett team kan arbeta sig igenom backloggen. Hastighetsindexet är unikt för varje team och du bör inte jämföra hastigheten mellan olika team.

Till exempel: Låt oss säga att du vill slutföra 300 story points i backloggen. Du vet att utvecklingsteamet i genomsnitt slutför cirka 50 story points per iteration. Med den informationen till hands kan du förutsäga att teamet kommer att behöva sex iterationer för att slutföra det nödvändiga arbetet.

Vad är fördelarna?

  • Det är mycket användbart för prognoser.
  • Det kan hjälpa dig att planera framtida sprintar.
  • Det kan hjälpa dig att förstå om teamet är blockerat eller om dina processförändringar fungerar.

Hur mäter du det?

Om du har ett stabilt team på plats kommer du att lyckas fastställa en genomsnittlig hastighet genom att mäta minst 5-7 sprintar. Om din vanliga sprint är veckovis och teamet slutför 250 story points under en femveckorsperiod är din genomsnittliga hastighet 50 story points per vecka.

Låt oss titta på Jira Velocity Chart nedan. De blå staplarna representerar åtagandet och de gröna representerar det faktiska arbetet som slutförts. I sprint nummer 1 planerade teamet 16 story points och slutförde 16 story points. Detta tyder på att deras uppskattningar var korrekta. I den andra sprinten planerade teamet dock 19 story points men slutförde endast 12. Detta tyder på att de nästa gång bör minska sin planering.

Ett inkonsekvent flöde är en indikator på att du har problem i utvecklingen och behöver göra förändringar.

Bildkälla: Jira Velocity Chart

Kumulativt flöde

Vad är kumulativt flöde?

Kumulativt flöde visualiserar statusen för dina ärenden under en viss tidsperiod. Det visar hur dina ärenden flyttas från en status till en annan när projektet fortskrider.

Vad är fördelarna?

  • Det är användbart för att identifiera flaskhalsar.
  • Hjälper team att se till att arbetsflödet är konsekvent.
  • Det visar hur stabilt ditt arbetsflöde är.
  • Det hjälper dig att förstå hur du kan göra din process mer förutsägbar.

Hur mäter du det?

Det enklaste sättet att mäta kumulativt arbetsflöde är att använda diagram. De visualiserar de tre viktigaste mjukvarutekniska mätvärdena för ditt flöde, inklusive cykeltid, genomströmning och pågående arbete.

Låt oss titta på diagrammet nedan. Den horisontella x-axeln anger tiden, medan den vertikala y-axeln anger arbetsmomenten. De olika färgerna representerar de olika arbetsflödestillstånden. Om banden fortskrider parallellt innebär det att din genomströmning är stabil. Det indikerar att antalet nya arbetsuppgifter som kommer in i ditt arbetsflöde är detsamma som antalet arbetsuppgifter som lämnar det.

Om ett band smalnar av snabbt betyder det att du har mer kapacitet än vad du behöver. Du bör flytta kapaciteten för att optimera flödet.

Om ett band breddas snabbt betyder det att fler kort kommer in i motsvarande steg än det finns uppdrag som lämnar det.

Bildkälla: Kanbanize Cumulative Workflow Chart

Summering Up

Att spåra de KPI-utvecklingsmått som beskrivs ovan kan leda till ett framgångsrikt resultat av produktutvecklingsprocessen. Du kommer att lyckas så småningom sluta att ifrågasätta projektets framskridande och få en detaljerad inblick i varje skede av utvecklingslivscykeln.

Om du vill sätta stopp för den onda cirkeln med produkter av låg kvalitet, missade deadlines och kodfel, börja implementera KPI-utveckling idag. Du kommer att lyckas släppa en förstklassig produkt utan medföljande risker.

distribuerad guide

Lämna ett svar

Din e-postadress kommer inte publiceras.