Verdi vs. Kostnad
- Wednesday, May 20th, 2009
- Skriv en kommentar
Jeg leste nettopp en liten blogpost av Ron Jeffries hvor han sier at “story cost does matter”. Det er tydeligvis ikke mulig å kommentere på xprogramming-bloggen uten å være medlem, så da lager jeg min egen lille blogpost om temaet.
Poenget er at noen har foreslått at man ikke skal ta høyde for kostnad når man prioriterer historiene i backloggen. I stedet skal man bare se på verdi. Slik planlegging uten estimater kalles naked planning. Jeffries sier:
“Suppose without loss of generality that your highest value stories have value 100. Suppose that stories vary in cost between 1 and 3. And uppose we have time to do 30 points of work.”
“We can do 10 3-point stories and get value 1000. Or we can do 30 1-point stories and get value 3000. 3000 would be more. Story cost does matter.”
Dette angrepet er nokså naivt – det virker som om Ron har gått glipp av hele poenget. Saken er nemlig den at de ligger en skjult verdi i de oppgavene som har høy kostnad. Funksjonalitet med høy kostnad og høy verdi er langtidsinnvesteringer, og det er dem som vil skille deg fra dine konkurrenter. Ting som er raskt å implementere kan hvem som helst kopiere i løpet av kort tid, og vil ikke gjøre ditt produkt eller din løsning unik.
Problemet med estimater – i tillegg til den enorme usikkerheten og unøyaktigheten – er at de vil få deg til å favorisere korttidsinvesteringer fremfor langtidsinvesteringer. Du vil gjøre akkurat som Ron gjør – fokusere på at 3000 er et høyere tall enn 1000. Jeg er derimot overbevist om at det er viktig å fordele innsatsen gjevnt mellom oppgaver med lav kostnad og oppgaver med høy kostnad.., det vil man tjene på over tid. Og tanken er at om man ser helt bort fra estimater når man planlegger, så vil denne fordelingen skje helt naturlig.
Til slutt kommer Ron med et spørsmål til leseren:
“Suppose that, like most organizations, you don’t really know much about the value of your stories. Should you do high-cost ones, low-cost ones, or what?”
Hvabehager? Hvis du ikke vet noe om verdien bør du ikke gjøre noen av dem i det hele tatt!!! Du bør istedet finne ut hvilke stories som har verdi. Om du ikke vet noe om verdien så famler du rundt i blinde, og da spiller det liten rolle om kostnaden er høy eller lav.
Kategorier: Softwareutvikling.
RSS feed for kommentarene.
Tilbaketråkk.
May 20th, 2009 at 9:58 am
AAAH, en post etter mitt hjerte :)
1) Verdi vs kostnad = oppfattet verdi (perceived value). Oppfattet verdi er hvordan den som faktisk får NYTTE av verdien oppfatter den. Oppfattet verdi vil bli påvirket av kostnad (eller teoretisk satt opp som oppfattet_verdi = verdi/pris). Dette kan eksemplifiseres ved det berømmelige flyvalget: hvis du skal fra A til B har du to alternativer: ett lavprisselskap og et komforselskap. Begge flyr samme distanse på lik tid, komforselskapet tilbyr samme type sitteplasser som lavprisselskapet men legger på champagne, varm mat, kaffe og aviser og PS3 spilling under flighten. Lavprisselskapet tilbyr bare en plass og mulighet til å kjøpe en sandwich. Hvilke selskap velger du å fly med? Hvis komforselskapet er dobbelt så dyrt som lavprisselskapet? Prisen påvirker absolutt den oppfattete verdien fra flyselskapene.
Overført til Storypoints høres dette ut som den evinnelige diskusjonen om at “så lenge vi tilfører verdi til produktet blir det bedre”. Regner med at det er vanlig fra leverandøres / utviklerens side. Kunden / brukeren av produktet vil derimot lure hvis feature med høyest verdi ble implementert men tok 3 mnd alene å utvikle.
2) Innovativ teori tilsier at jo mer verdi du tilfører produktet vil kostnaden etterhvert bli større og større. Dette kan illustreres i en S kurve, hvor kostnaden for å tilføre verdi i begynnelsen av produktet er høyt, deretter når omrisset er på plass leveres verdi over lav kost, før man tilnærmer seg potensialet til produktet og verdi/kostnad blir bare lavere og lavere. MAO vil aldri cost for story points være nøytralt men være påvirket av HVOR du er i produktets livssyclus (dyrere i begynnelsen og slutten av produktets livssyklus).
3) Ettersom kostnad i dette tilfellet ofte sammenfatter timer man må bruke for å skape verdien man ønsker, kan også kostnad ses på som proporsjonalt med kompleksitet (Trenger naturlig nok ikke være det). Ved økt kompleksitet øker usikkerheten ved kost. Dette burde tilsi at lav kost burde gi større sikkerhet rundt kostnaden. Ved å IKKE ta hensyn til kost tar man derfor ikke høyde for denne potensielle usikkerheten.
4) Et unntak finnes naturlig nok i “compliance” eller der hvor verdi MÅ tilføres pga eksterne reguleringer eller krav. I så tilfelle må kostnaden til verdien som tilføres måles mot kostnaden ved å IKKE tilføre verdien.
Min konklusjon: vurder alltid verdi mot kostnad. Da påstår jeg at man øker den oppfattede verdien av dem som faktisk skal ha nytte av verdien, potensielt lavere kompleksitet og bedre evne til å holde estimatene.
B-)
May 20th, 2009 at 10:12 am
Takk for en spennende kommentar, Bård. Den fikk meg bl.a. til å tenke på hva Mary Poppendiek sa i sitt Lean-foredrag her i Bergen nylig.
Hun påpekte at at det er en veldig liten prosent av funksjonaliteten i de aller fleste produkter som faktisk brukes (som gir verdi til brukeren). Hennes påstand er at vi bør holde produktene våre enkle. Ved å passe på å holde kompleksiteten lav, vil vi oppnå lave drifts og veldikeholdskostnader, som også er en verdi i seg selv.
Dette får meg til å trekke slutningen at man bør konsentrere seg om noen få kjernefunksjoner, og ikke pøse på med mengder av stories med lav kostnad – fordi kostnaden egentlig er større akumulert sett, bare skjult i forkant.
For meg blir alt dette med kostnad/estimat/rissiko veldig komplisert, og jeg tror det koster mye å ta gode valg basert på dette. Det er derfor jeg har tro på den smidige retningen som sier at man ikke skal vurdere dette i det hele tatt, og i stedet bare se på verdi. Dette setter selvsagt endel andre krav til gjennomføringen av prosjektet, i forhold til forventninger, tidsfrister osv.
Et annet lite poeng som jeg ikke vet om jeg fikk frem i posten: Faren i dag er at enkelte stories med stor verdi men også stor initiell kostnad kanskje aldri vil bli prioritert. Men akkurat de storiene er kanskje det som vil gjøre produktet et unikt forsprang.., og kanskje også lavere kostnad in the long run.
May 20th, 2009 at 10:53 am
Godt poeng, og det støtter opp under S kurve teorien. Uansett hvor mye man prøver å la stories være “uavhengige” vil man jo forsøke å bygge noe generisk, gjenbrukbart inn i arkitekturen som forhåpentligvis gir kostnadsgevinst for videre implementasjon. Sånn sett vil jeg tro at de store initielle kostnadene er større i begynnelsen av produktet enn midt i. Samme som kostnaden på slutten av produktet blir større pr. story ettersom man opplever større teknisk avhengighet og potensielle følgefeil, eller rett og slett opplever begrensninger i produktet.
Sånn sett vil høye initielle kostnader gjerne bli redusert på sikt, og derfor viktig å tas med i regnestykket.
Og jeg er veldig enig i den smidige tilnærmingen til risiko og kompleksitet. Det er bedre å bryte opp kompleksiteten i mindre biter, angripe de og stole på at du kan løse dem underveis ved bruk av gode og fornuftige teknikker, enn å hele tiden være “føre var” og unngå alt som finnes av risiko. Man vinner ikke på den måten :)
B-)