Få bedre kontroll med smidig estimering!
Estimering er vanskelig
Vi har vel alle hørt om IT-prosjekter hvor estimatene blir over dobbelt så dyre som de opprinnelige estimatene skulle tilsi. I slike prosjekter sier man gjerne at en “bommer på estimatene”. For å gjøre noe med dette har mange gjort forsøk på å komme opp med forskjellige avanserte estimeringsmetoder.
En mye brukt tilnærming for å kunne ta hensyn til de mange faktorer som kan påvirke et estimat, er å skille mellom “størrelsesestimering” og “kostnadsestimering”.
Størrelsesestimering brukes til å finne ut hvor stor en ny funksjon vil være, for eksempel målt i funksjonspoeng eller “story points”.
Når vi har estimert størrelsen til den nye funksjonen kan tiden, og dermed kostnaden, det tar å utvikle funksjonaliteten, fortsatt være avhengig av mange ting, for eksempel om teknologien er umoden, domenet er ukjent, teamets erfaring, kunnskap om verktøy, hvor mye teknisk gjeld en tjeneste eller produkt har, osv.
Det sier seg selv at dette er en vanskelig øvelse basert på antagelser, som krever stor innsats, og med stor risiko for å bomme stygt.
Smidig estimering
De fleste programvareutviklingsprosjekter Systek har deltatt i, i det siste, har tatt estimering et skritt lenger, med såkalt “smidig estimering”.
Kort fortalt låser man kostnadene med en gitt teamstørrelse, og så får man teamet til å produsere så mye funksjonalitet som mulig. Og lager en leveranseplan basert på faktisk målt teamhastighet (levert funksjonalitet pr tidsenhet) i stedet for en hel del antatte faktorer.
Tjenesteutvikling framfor prosjekt?
Mange bedrifter har innsett at en tjeneste vil kreve kontinuerlig utvikling for å leve og utvikle seg sammen med nye krav fra brukerne, og krav som følge av den teknologiske utviklingen. Hvis ikke vil tjenesten fort bli utdatert, og kreve full nyutvikling. Det er dyrt og gir også et dårlig tilbud til brukere av tjenesten.
Bedriftene setter dermed av et team som kontinuerlig skal utvikle og videreutvikle tjenesten, i stedet for å starte og avslutte et prosjekt. Livssykluskostnaden for tjenesten blir dermed også tatt med i lønnsomhetsberegningen.
Bedrifter som gjør dette slipper dermed også den litt tunge overgangen fra prosjekt- til forvaltningsteam. Som kanskje også har blitt litt kunstig etterhvert som smidige team leverer til produksjon kort tid etter at utviklingen har startet.
Oppgaven blir dermed å finne ut hvor stort teamet skal være. Om man bommer litt her er ikke det så kritisk, teamet kan skaleres opp eller ned etterhvert som man ser hvordan teamhastigheten er i forhold til planlagte leveranser. Typisk vil utviklingen kreve et noe større team i starten, inntil tjenesten er skikkelig oppe og kjører, og et litt mindre team etterhvert som tjenesten har modnet seg.
Bruk kostnadsestimering i starten
Kostnadsestimering brukes dermed i starten for å finne ut hvor stort teamet skal være.
Eksempel: Basert på en antagelse om at den nye tjenesten er omtrent like omfattende som en av bedriftens eksisterende tjenester, har bedriftens ledelse antatt at de vil trenge et team på 7 personer de to første årene. Så lenge teamet har denne størrelsen vil det forbruke ca 1000 timer i måneden (~150*7), og 10 000 timer i året. Totalt ca 20 000 timer på to år.
Ganger du det med en gjennomsnitts-timepris så har du teamkostnaden. Dette vil ikke variere så mye.
Etter to år planlegger bedriften å skalere ned til et 3-4-manns team.
Bruk deretter tiden på kontinuerlig forbedring, ikke på kontroll
Når kostnadene er låst kan teamet konsentrere seg om å få så mye som mulig ut av disse timene, i stedet for å bruke mange timer på å estimere, kontrollere og re-estimere igjen. Kanskje kan du til og med spare et årsverk i kontroll, eller få en utvikler til uten ekstra kostnad?
Grovestimering — “Top down”
Produkteier vil være ansvarlig for å etablere og prioritere overordnede brukerhistorier i starten. Disse kan grovestimeres i story points. Bruk gjerne “top-down” estimering, dvs sammenlign med en historie av antatt samme størrelse.
Lag gjerne en leveranseplan, men hold den på et overordnet nivå
Etterhvert som de første historiene er levert er det mulig å måle teamhastigheten, og produkteier vil få bedre og bedre kontroll på når ny funksjonalitet kan bli levert. Slik kan hun kommunisere en overordnet leveranseplan til brukere og andre interessenter. Men hold leveranseplanen overordnet. Gjerne på epos-nivå, slik at det ikke påvirker leveranseplanen hvis produkteier legger til eller fjerner brukerhistorier basert på opparbeidet kunnskap og innsikt underveis.
Levér hele tiden og ønsk endringer velkommen!
Merk at det ikke vil medføre noe stort ekstraarbeid hvis produktkøen reprioriteres eller nye brukerhistorier kommer inn — så lenge leveranseplanen holdes overordnet, og teamet leverer ofte. Da slipper vi problemstillinger som “hvis denne funksjonaliteten ikke leveres i neste leveranse, så går det 3 måneder før den kan bli levert”.
Detaljestimering — “Top down” eller “Bottom up”?
Detaljert størrelsesestimering bør gjøres av teamet og produkteier i samarbeid, når en historie skal påbegynnes. Bruk gjerne “planning poker” for å estimere hele historien (Top down). Eller bryt ned historien i oppgaver som må utføres for å fullføre historien, og la estimatet bli summen av alle disse oppgavene (Bottom up). Eller en kombinasjon.
Noen smidige team har helt kuttet ut denne øvelsen. Det kan være hensiktsmessig hvis man er helt sikker på at funksjonaliteten skal utvikles uansett og at det må gjøres nå.
Men i mange tilfeller kan det være en god øvelse å detaljestimere: Hvis brukerhistorien er mye større enn produkteier trodde i starten, kan det være en fordel å dele den opp, ta vekk eller nedprioritere deler av historien. Eller revurdere om den i det hele tatt skal implementeres.
Hvordan passer dette med Prince2 eller Prosjektveiviseren?
Legg merke til at jeg har brukt begrepene, “størrelsesestimering”, “kostnadsestimering”, “top-down” og “bottom-up” estimering, som er kjente begreper fra mer tradisjonelle estimeringsmetodikker. Slik sett passer det bra med Prince2 og Prosjektveiviseren sine anbefalinger, hvor disse begrepene er brukt.
Prosjektet, eller tjenesteutviklingen, må fortsatt initieres og startes. Lønnsomheten vurderes og risikoer håndteres. Men oppfølgingen underveis, avslutningen, og overgangen til forvaltning, blir enklere.
Bedre kontroll, mindre stress og høyere produktivitet
Vår erfaring er at smidig estimering gir bedre kontroll med mindre innsats. Og gir større effektivitet enn tradisjonell estimering med tilhørende kontroll av om hver aktivitet går over eller under estimatet.
Slitasjen på teamet blir mindre ved at det slipper å forholde seg til mer eller mindre urealistiske tidsfrister som teammedlemmene ikke selv har fastsatt. Trivselen blir større og da går gjerne produktiviteten opp!
Er du en smidig prosjektleder? Da se vi etter deg! Se vår stillingsannonse
