logo

Netmaking

22 71 95 97

Yngve Høiseth

Forbedret håndtering av ikke-funksjonelle oppgaver

Vi har forbedret håndteringen av ikke-funksjonelle oppgaver for våre kunder. Her forklarer jeg hvorfor og hvordan.

Funksjonell vs. ikke-funksjonell

Et funksjonelt krav beskriver hva et system skal gjøre. For eksempel skal en nettbutikk legge til rette for kjøp av varer.

Funksjonelle oppgaver opprettes og prioriteres som regel av produkteier – for eksempel nettbutikkens markedsansvarlige.

Et ikke-funksjonelt krav beskriver hvordan et system skal være. For eksempel skal nettbutikken være stabil.

Når man løser en ikke-funksjonell oppgave gjør man systemet mer i tråd med de ikke-funksjonelle kravene. Noen eksempler:

  • skrive automatiske tester for deler av kodebasen der slike mangler
  • automatisere manuelle rutiner (for eksempel rutiner for lansering av nye versjoner)
  • forbedre kodekvaliteten
  • oppdatere underliggende programvare (for eksempel operativsystem) 
  • øve på påføring av sikkerhetskopierte data

Ikke-funksjonelle oppgaver er ofte kun kjent for de som jobber med teknisk utvikling og drift. For eksempel er rutiner for påføring av sikkerhetskopierte data sjelden kjent for produkteier.

Som teknisk leverandør med vekt på langsiktighet og godt håndverk har vi i Netmaking et ansvar for at systemene vi utvikler og drifter holder et høyt nivå også hva ikke-funksjonelle krav gjelder. Derfor har vi gått gjennom og forbedret rutinene våre for håndtering av ikke-funksjonelle oppgaver.

20 prosent-regelen

Vi utforsket ulike muligheter, og begynte med det som anbefales av DevOps-bevegelsen: Sett av en viss andel av tiden (i utgangspunktet 20 prosent) til ikke-funksjonelle oppgaver. La den med teknisk ansvar for systemet – i vårt tilfelle ledende utvikler på det aktuelle kundeteamet – prioritere tidsbruken.

En slik ordning ville gitt oss handlingsrom til å utbedre ikke-funksjonelle problemer uten at produkteier behøvde å være involvert.

Da vi skulle iverksette dette i praksis kom vi imidlertid frem til at metoden ikke passer til måten vi jobber med våre kunder. Vi ville ha vært nødt til å bruke mye tid på å overvåke tidsbruken, og vi slet med å finne en god modell for å sikre at ikke-funksjonelle oppgaver var tilstrekkelig synliggjort for produkteier.

Prioriteringen av ikke-funksjonelle oppgaver er nemlig ikke bare en teknisk sak, men må ses i sammenheng med virksomheten for øvrig. For eksempel medfører ofte utførelse av ikke-funksjonelle oppgaver redusert risiko, og risikotoleranse varierer fra kunde til kunde, prosjekt til prosjekt og over tid. Planer for systemets varighet er et annet hensyn som spiller inn. 

Forbedret prosedyre

I stedet for å gjemme bort de ikke-funksjonelle problemene fra produkteier bestemte vi oss for å heller øke synligheten. Dette skjer på følgende måter:

Ny kategori i supportportalen

Illustrasjon: Ny kategori for ikke-funksjonelle oppgaver i supportportalen (forkortet til bokstaven I). Vi har gitt kategorien fargen svart for å symbolisere hullet man graver seg ned i hvis man lar være å utføre ikke-funksjonelle oppgaver.

Ved å gi ikke-funksjonelle oppgaver en egen kategori gjør vi det lettere for produkteier å være bevisst på slike oppgaver og ta stilling til prioriteringen av dem. Det er i tillegg tydeligere for utviklere at de kan opprette slike oppgaver på kundens vegne.

Oppfølging

Vi vil diskutere de ikke-funksjonelle oppgavene i oppfølgingsmøter og i kontinuerlig arbeid med produkteier på samme måte som vi diskuterer andre oppgaver. Det blir da relevant å se tidsbruken og antallet ventende ikke-funksjonelle oppgaver i sammenheng.

Se for eksempel for deg at det ligger et tosifret antall ikke-funksjonelle oppgaver i backloggen samtidig som kun to prosent av timene ble brukt til slikt i løpet av den siste tiden. Da kan det være på sin plass å prioritere slike oppgaver fremover.

Veien videre

Vår erfaring tilsier at produkteiere i varierende grad ønsker å være involvert i beslutninger om ikke-funksjonelle oppgaver. Noen ønsker å overlate slikt til oss – «gjør det dere mener er hensiktsmessig» – mens andre vil være tettere på dette arbeidet.

Vi legger fremdeles til rette for slike forskjeller i praksis, men har altså en tydeligere definert og synligere standard prosedyre.

Dersom du har innspill til denne endringen hører vi gjerne fra deg.

Yngve Høiseth

Yngve Høiseth

Yngve har vært innom både befalsskole og bank før han landet hos oss. I tillegg til webutvikling er Yngve opptatt av hvordan ting kan gjøres bedre, på alle mulige måter, noe som er bra for både oss og våre kunder. Yngve har også en ullgenser.