Estimering av kostnader i softwareutvikling. Hans Christian Benestad PhD, Expertware AS

Transkript

1 Estimering av kostnader i softwareutvikling Hans Christian Benestad PhD, Expertware AS 1

2 Lesson 1: Planlegging er nødvendig 2

3 men ikke tilstrekkelig 3

4 Lesson 2: Vit hvorfor du estimerer 4

5 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

6 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

7 Lesson 3: Estimerere og andre IT-folk har menneskelige egenskaper (!) 7

8 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

9 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

10 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

11 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

12 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

13 Lesson 4: Forstå hva et estimat er 13

14 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 h h Tidsforbruk kan ofte tilnærmes med en parametrisk fordeling, f.eks. gamma-fordeling 14

15 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

16 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

17 Eksempel på anbefalt teknikk For Utviklingsfasen Iterativ utvikling Outsourcet utvikling 17

18 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

19 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

20 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 21

22 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

23 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

24 Low-tech alternativ:excel 24

25 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

26 En abonnementsbasert web-tjeneste 26

27 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