Estimering av kostnader i softwareutvikling Hans Christian Benestad PhD, Expertware AS 1
Lesson 1: Planlegging er nødvendig 2
men ikke tilstrekkelig 3
Lesson 2: Vit hvorfor du estimerer 4
Estimering i SW livssyklus: Skreddersøm Før investeringsbeslutning: Anskaffelsens kost/nytte Basisestimat, kostnadsramme etc. Driftsfase: Vedlikeholdskostnader Analyse av alternativer Tilbuds- og kontraktsfase: Leverandørers pristilbud Forventet fortjeneste Før prosjektoppstart: Fremdriftsplan og bemanning Ressursforbruk/leveransetidspunkt Konstruksjonsfase: Planlegging av delleveranser Oppdatert fremdriftsplan Illustrasjon med tillatelse fra adg.no 5
Estimering i SW livssyklus: Start-ups og produktselskaper Introfasen langsom vekst, liten fortjeneste: Finansieringsbehov Kost/nytte mht. nyhetsgrad Tilbaketrekning: Lite nysalg, stabil fortjeneste Kost/nytte mht. renomme Analyse av alternativer Vekstfasen: Voksende salg og fortjeneste Kost/nytte mht. kundetilfredshet Modning/metningsfasen: Lavere salg, stabil fortjeneste Kost/nytte mht. kundelojalitet Illustrasjon med tillatelse fra adg.no 6
Lesson 3: Estimerere og andre IT-folk har menneskelige egenskaper (!) 7
Noen psykologiske effekter Overoptimisme Overkonfident (eplekjekk) i anslag av usikkerhet Vanskelig for å lære av tidligere estimeringsfeil Påvirket av forventninger Inkonsistens Påvirket av relevant og irrelevant informasjon 8
Effekten av irrelevant informasjon og «cues» Gruppe A: Fikk den originale spesifikasjonen, en side lang Gruppe B: Fikk identisk tekst, syv sider lang. Dobbel linjeavstand, vide marger, større fonter størrelse og mer avstand mellom avsnittene Gjennomsnitt estimat 117 timer 170 timer 9
Ankereffekt Gruppe A: Kravspek med tidlig antydning 1000 timer Gruppe B: Identisk kravspek med antydning 50 timerl Gjennomsnitt estimat 555 timer 99 timer NB: Ingen av utviklerne opplevde at de hadde blitt mye påvirket. De fleste mente at de ikke var påvirket i det hele tatt av kundens forventninger. 10
Timeslot-effekt Gruppe A: Hvor lang tid vil det ta å utvikle alle krav for system X? Gruppe A: Hvor mange av kravene for system X får du implementert i første iterasjon,30 timer)? Hvor lang tid tar det å utvikle resten av kravene? Gjennomsnitt estimat 200 timer 120 timer 11
Inkonsistens Syv utviklere estimerte de samme oppgavene i to runder med 3 måneders mellomrom 6 oppgaver 3 måneder Samme 6 oppgaver Gjennomsnittlig 71% forskjell fra første til andre runde Typisk: 29 timer -> 50 timer Inkonsistensen er 14% ved kombinasjon av enkeltestimatene Typisk 29 timer -> 33 timer 12
Lesson 4: Forstå hva et estimat er 13
Faktisk tidsforbruk for en gitt type oppgave varierer 20stk 10stk 5stk 25h 80h 200h 300h B2B-tjeneste: Integrer en ny business-partner, 100 ganger Partner# 1 80h 2 90h 3 25h 4 80h Faktisk forbruk 99 200h 100 90h Tidsforbruk kan ofte tilnærmes med en parametrisk fordeling, f.eks. gamma-fordeling 14
Hva er et «korrekt» estimat for fremtidige oppgaver? «Most likely» = 80 Median = p50 = 107h P10 = «best case» = 45h P90= «worst case» = 213h P70 = «bid?» = 145h 15
Lesson 5: Bruk historiske data i størst mulig grad I foregående eksempler kan realistiske estimater og usikkerhet leses rett ut av historiske data Men det skal mye til å samle inn slike data 16
Eksempel på anbefalt teknikk For Utviklingsfasen Iterativ utvikling Outsourcet utvikling 17
Prinsipper for poengestimering Estimer oppgaver i poeng, en relativ størrelse Mål antall poeng prosjektet løser i én iterasjon (fart) Alloker oppgaver for neste iterasjon i henhold til poengsum og fart Smidig «Planning poker» og «planning game» er basert på disse enkle prinsipper 18
Generell prosess for poengestimering Samle historikk Referanse 5 poeng Fart=20 poeng/itersjon Estimer A 2 p B 15 poeng C 5 poeng D 5 poeng E 2 p Lag alternative planer A, B, E B, D Gjennomfør iterasjon Oppdater historiikk A, B Fart=17 poeng/iterasjon 19
Fordeler og ulemper Tid for heft og uforutsette hendelser bakes inn i «fart» Slipper å estimere timer direkte Mindre press, passer bra som gruppeteknikk Enkel datainnsamling Ikke trivielt å enes om hva et poeng er Ikke direkte støtte for usikkerhetsvurdering Ikke en generell estimeringsteknikk 20
21
Low-tech løsning i MS Word Bruk mal og samme instruksjon hver gang Vis referanseoppgaver eksplisitt Be om at like store oppgaver blir gruppert sammen Send og motta elektronisk, kanskje anonymt 22
Lag iterasjonsplan Planlegg et par-tre sprinter framover Basert på poeng og kapasitet for en iterasjon (fart) Kombiner enkeltestimater Ta hensyn til spredning som indikator på usikkerhet 23
Low-tech alternativ:excel 24
Hvordan vi har benyttet forskningsresultater i EstimationWeb Inkonsistens Innhenting og kombinering av gruppeestimater Forventningspress Anonymisering Uklarhet i hva som estimeres Overkonfidens Overoptimisme for store oppgaver Format, anker, priming Standardiserte spørsmål og definisjoner, sjekkliste Justerbar tolkning av trepunktsestimater fra historiske data Spesielle input-metoder kan motvirke denne effekten, ideelle timer etc. Sjekklister, diskretisering av krav 25
En abonnementsbasert web-tjeneste 26
Oppsummering Tenk nøye gjennom hvordan estimatene skal brukes Lag en konsistent, repeterbar ramme rundt estimeringen, gjerne med verktøy Samle og benytt historiske data Unngå press mot individer Involver flere i estimeringen Så lett men allikevel så vanskelig Spørsmål og kommentarer? 27