Hastighet (programvareutvikling)

en metrikk i smidig programvareutvikling for utført arbeid, som definert av laget

Innen smidig programvareutvikling er implementeringshastighet[1] eller hastighet (engelsk: velocity) et mål på utført arbeid per iterasjon.[2] Det brukes til planlegging av sprinter og måling av lagets ytelse.

Prinsipp rediger

Hovedideen bak hastighet er å hjelpe et lag med å anslå hvor mye arbeid laget kan fullføre i en gitt tidsperiode basert på hvor raskt lignende arbeid har blitt fullført tidligere. Hastighet som den er definert innen programvareutvikling er et relativt mål, og vil avhenge av hvordan man definerer enhetene. Med andre ord vil hastighetstallet bety lite, mens hastighetstrenden kan gi en viss innsikt av hvordan prosjektet utvikler seg over tid.

Terminologi rediger

Følgende terminologi brukes i ved sporing av hastighet_

Arbeidsenhet
En arbeidsenhet er den enheten teamet har valgt for å måle hastighet. Dette kan enten være en ekte enhet som en arbeidstime, en arbeidsdag, et produktkø-element eller et storypoint.[3] Hver oppgave i programvareutviklingsprosessen ska da vektes i forhold til den valgte enheten.
Intervall
Et intervall er varigheten av hver iterasjon i programvareutviklingsprosessen som hastigheten måles for. Lengden på et intervallet bestemmes av laget. Ofte er intervallet en uke, men det kan være så langt som en måned.

Kritikk rediger

Et problem med hastighet som begrep i prosjektarbeid er at man blander sammen effektivitet i utført arbeid med presis planlegging. Med andre ord kan et team blåse opp hastigheten ved å estimere arbeidsoppgavene mer konservativt. Dersom et team sier at en oppgave vil ta 4 timer eller 4 poeng, men istedet bruker 2 timer eller 2 poeng, vil hastigheten se bedre ut (noen ganger kalt poenginflasjon).[4][2]

Et annet problem med hastighet er at det ikke tar hensyn til kvaliteten på det ferdige produktet, eller brukerens prioriteringer eller mål. Hastigheten kan økes ved å forsømme godt design, refaktorere, ignorere kodingsstandarder og opparbeide seg teknisk gjeld. Bare det å fullføre programvarefunksjoner så raskt som mulig vil øke hastigheten uavhengig av kvalitet. På samme måte inkluderer hastighet alt utført arbeid uavhengig av fordelene ved det arbeidet. For eksempel vil det å bygge en programvarefunksjon som ingen ønsker eller trenger fortsatt telle som "utført arbeid".

Et tredje problem med hastighet er at det ofte misbrukes som et mål for effektivitet eller lagytelse. Hastighet er imidlertid en beregning av arbeid utført, ikke effektivitet. Hastigheten kan økes ved å jobbe overtid eller legge til lagmedlemmer, men ingen av disse alternativene trenger å medføre økt effektivitet eller ytelse. 

Referanser rediger

  1. ^ «Estimering av produktkøen med T-skjortestørrelser». Bouvet Norge (norsk). Besøkt 21. januar 2022. 
  2. ^ a b Essential Scrum. A Practical Guide to the Most Popular Agile Process 
  3. ^ Measures of size, arkivert fra originalen on 2010-10-26, https://web.archive.org/web/20101026030031/http://agilesoftwaredevelopment.com/2006/12/measures-of-size, besøkt 2022-01-21 
  4. ^ «point inflation». innolution.com. Besøkt 6. juni 2019.