Eti Estimering i av kostnader i IT-prosjekter

Transkript

1 Planleggingsfasen.. Eti Estimering i av kstnader i IT-prsjekter Stein Grimstad (Simula) 1 2 Gjennmføringen. Overskridelser I gjennmsnitt sterk underestimering av kstnader % verptimistiske i gjennmsnitt Ingen vesentlig frbedring ver tid. Studier indikerer at vi er like dårlige til å estimere sm fr 30 år siden Knsekvenser: Gjennmføringsprblemer Misfrnøyde kunder Dårlig lønnsmhet eller tap fr leverandør 3 4

2 Hvrfr har vi disse prblemene? Grunnleggende prblemer: Det er urealistisk å frvente perfekte estimater (en del faktrer er ikke mulig å vite på frhånd, fr eksempel m nøkkelpersnell blir rammet av sykdm, selv små feilvurderinger kan ha stre knsekvenser) Kravene endrer seg underveis (skal prsjektet vente til alle krav er klare, kmmer det aldri i gang, nye lver/frskrifter, markedet endrer seg) Kmplekse prsjekter (baserer seg på ny teknlgi, lite mulighet til å akkumulere erfaringer, tidspress, mer preg av frskning enn prduksjn ) Kmplekse rganisasjnsendringer fte en del av leveransen (suksesskriterier kan ligge utenfr prsjektet, mye følelser g psisjnering invlvert) Oppdragsgiverprblemer: Hvrfr har vi disse prblemene? Undervurderer kmpleksiteten av å være ppdragsgiver Avsetter fr lite tid/ressurser til frberedelser/invlvering/ppfølging Uklare krav» Men dette er gså en faktr sm kan bidra til bedre estimeringsnøyaktighet. Hvrfr? Mangler IT-kmpetanse i egen rganisasjn (få leier inn hjelp til å være kunde) Kmmunikasjnsprblemer med leverandør (mangler felles språk) Mangel på frankring i ledelse / frretningsstrategi Apati verfr IT-leverandører (det er slik de er-hldningen)? 5 6 Leverandørprblemer: Hvrfr har vi disse prblemene? Lite erfaringer mhp planlegging g gjennmføring av nye typer (f eks svært stre) IT-prsjekter» De virkelig stre prsjektene får man strt sett ppleve kun 1-2 ganger i sin karriere.» Fare fr at man verfører erfaringer fra mindre g mellmstre prsjekter til stre prsjekter, ma de vesentlige frskjellene (bla mhp prduktivitet g risik-eksplsjn) tar man ikke nk hensyn til. Feilaktig bruk av histriske data» Antar at vi vil jbbe mer effektivt enn i tidligere prsjekter (vi har kanskje lært ne av de feilene vi faktisk gjrde, men hva med alt sm kunne ha skjedd?) Leverandørprblemer: Hvrfr har vi disse prblemene? Mangelfull læring av tidligere prsjekter» Frskningsresultater viser at vi er svært dårlige i å lære av tidligere vurderinger.» Feedback er svært mangelfull. F eks, det er ingen felles frståelse av hva et estimat er. Fr lite fkus på risik» Sterk undervurdering av størrelse på det uventede Uheldig valg av systemutviklingsprsess» Uklare krav, mange aktører, høy risik, sammen med en rendyrket fssefalls-mdell er den typiske feilen sm gjøres. 7 8

3 Kan vi frvente at det er ptensial fr frbedring? Ja! Frdi: Vi er inknsistente når vi estimerer» Om vi estimerer den samme ppgaven t ganger basert på den samme infrmasjnen så vil estimatene sm ftest bli helt frskjellige Det er systematiske skjevheter i estimatene» Overptimisme» Irrelevant infrmasjn Eksempel på manipulasjn IFI-studenter estimerte arbeidsmengde til den samme prgrammeringsppgaven Gruppe A: Fikk den riginale spesifikasjnen, sm var en side lang Grup B: Fikk en versjn av spesifikasjnen sm hadde identisk tekst, men var på syv sider. Økningen i lengde skyldes dbbel linjeavstand, vide marger, større fnt- størrelse g mer avstand mellm avsnittene» Wishful thinking» Sekvens-effekter 9 10 Resulter 1000 Estim mate Estimeringsprsess Lng Length Nrmal Lng Nrmal Difference Mean % StDev % 11 12

4 1. Frstå estimeringsprblemet Frberedelser Identifiser mål g krav til nøyaktighet Identifiser interessenter g plitiske psisjner Spesifiser frutsetninger Bestem nedbryting av prblemet 2. Enighet m beslutninger g frutsetninger Identifiser relevante beslutninger g frutsetninger sm kan påvirke Avgjør m det er meningsfullt g nødvendig å estimere på nåværende tidspunkt Avklar fleksibilitet g prsjektpriritet 3. Innhent relevant infrmasjn Frberedelser Identifiser selskapsspesifikke kstnadsdrivere Pass på at kildene er uhildet Innhent infrmasjn fra flere kilder Unngå irrelevant infrmasjn Identifiser histrisk data fra tidligere prsjekter 4. Velg estimeringsprsess Baser prsessen på tilgjengelig infrmasjn Benytt rganisasjn g persnspesifikk infrmasjn Estimeringsfasen 5. Estimer mest sannsynlig arbeidsmengde Strukturer estimeringsprsessen Separer mest sannsynlig arbeidsmengde fra tilbud, plan etc. Beskriv frutsetninger Beskriv underliggende infrmasjn fr etterprøvbarhet 6. Anslå usikkerhet Estimeringsfasen 7. Gjennmgang av estimeringsprsessen g estimat Benytt uavhengige eksperter til gjennmgang Sørg fr at gjennmgangen kan føre til frandringer Benytt en sjekkliste 15 16

5 Anvendelsesfasen 8. Benytt estimatene i tilbudsskriving Ta utgangspunkt i mest sannsynlig arbeidsmengde g estimatusikkerheten 9. Benytt estimatene i planleggingen Bestem buffer fr ufrutsette hendelser Planlegg aktiviteter sm reduserer usikkerhet, sm utvikling av delfunksjnalitet Planlegg re-estimering Anvendelsesfasen 10. Kmmuniser estimater, tilbud, plan g usikkerhet En gd estimeringsprsess er et gdt salgsargument! Tilpass infrmasjn etter mdenhet Spesifiser risik, g hvrdan denne skal håndteres Tilgjengeliggjør versiktlige estimater g antakelser Erkjenn g frhld dere til mttakers mål, uten å redusere realismen 11. Kntrller kstnadene Mnitrer utviklingen g re-estimer Sørg fr å hlde alle deltakere infrmert Favriser enkelhet Læringsfasen Typer usikkerhet i estimatene g hvrdan disse håndteres 12. Lær av erfaringer Arranger erfaringsgjennmganger Frstå underliggende årsaker fr eventuelle avvik Oppdater sjekklisten, erfaringsdatabasen, WBS etc. på bakgrunn av gjennmgangen Ikke vergeneraliser Nrmalvariasjn i prduktivitet Angis f eks sm minimum-maksimum intervaller per aktivitet Risik sm følge av kjente risikfaktrer Angis f eks sm sannsynlighet x utfall, samt innvirkning på ttalt kstnadsfrbruk g eventuelle tiltak men kan gjøre Risik sm følge av uventede hendelser ( frvent det uventede ) Angis sm risikbuffer basert på andel kstnader til håndtering av uventede hendelser Kas (f eks ttal endring i prsjektets mandat) Krisehåndteringsrutiner 19 20

6 Litt m (frmelle) estimeringsmdellener COCOMO, SLIM, PRICE-S, Estimacs, MkII Functin Pint, IFPUG Functin Pint, Feature Pints, Viktig gprinsipp: pp Bruk enkle metder dersm det ikke er påvist at de mer kmpliserte mdeller er bedre g det er det ikke fr de sm er nevnt venfr! De få studiene sm er gjennmført viser at enkle mdeller (til g med rene ekspertestimater) er minst like gde sm de mer avanserte mdellene. En grunn til dette er at enkle mdeller er mer rbuste, dvs de gjør ikke så mange antagelser mhp frdelinger g sammenhenger. Dessuten, enkle mdeller muliggjør at brukeren skjønner antagelser g utregninger, kan frhlde seg til estimatene. Krt ppsummering Når du skal estimere arbeidsmengde fr en utviklingsppgave eller et prsjekt så bør du: Ha histriske data fr lignende ppgaver tilgjengelig (eller ha tilgang på persner e med svært relevant ev erfaring). Unngå irrelevant infrmasjn (f eks hva persner sm er mye mer erfarne enn deg ville brukt på ppgaven eller hva kunden frventer) Frigjøre deg fra faktrer sm fører til ønsketenkning (f eks unngå situasjner der estimatet blir et middel til å signalisere effektivitet) Strukturere prsessen vha sjekklister (lag din egen basert på tidligere erfaring g kmbiner med andres!) Ikke fkusere på detaljer, men på de mest usikre mrådene (høy detaljering av aktiviteter fører fte til dårligere nøyaktighet, men større tr på dem) Eksperiment: individuell vs gruppe-estimering Gruppe-estimering Tyve fagpersner fra samme firma estimerte hver fr seg arbeidsmengden fr det samme systemutviklingsprsjektet [*] Deltakerne hadde frskjellig bakgrunn Prsjekt var et reelt prsjekt sm var implementert De delte seg deretter pp i fem grupper. Hver gruppe ble enig m et felles estimat Gjennm diskusjn g kmbinasjn av kunnskap [*] Mløkken-Østvld and Jørgensen (2003): Sftware Effrt Estimatin: Unstructured Grup Discussin as a Methd t Reduce Individual Biases. In The 15th Annual Wrkshp f the Psychlgy f Prgramming Interest Grup

7 Resultater Estimatene sm var basert på gruppe-diskusjn var nærmere den faktiske arbeidsmengden enn gjennmsnittet av de individuelle estimatene Mulig frklaring: Gruppenes evne til å identifisere flere prsjekt-aktiviteter Mulig frklaring: At de i gruppen måtte begrunne estimatene sine kan medføre at realisme øker Vi fant lignende resultater i et eksperiment hvr vi undersøkte usikkerhetsintervall [*] Gruppediskusjner medførte at man anga mer realistiske usikkerhetsintervaller i Frskning på gruppe-estimering Få studier innen Sftware Engineering men mange relevante studier innen andre frskningsfelt (psyklgi, business frecasting, etc) Resultater Kmbinering av estimater frbedrer estimeringen (spesielt når de sm estimerer har frskjellig bakgrunn) Struktur kan frbedre estimeringen (fr eksempel: redusere påvirkningen fra irrelevant infrmasjn) Flere hder husker mer Ulemper Ressurs-krevende (dyr) sammenlignet med individuell estimering Grup think kan frekmme (fr eksempel: alle er enige med sjefen) Grup plarizatin kan frekmme (fr eksempel: gruppen er mer ptimistisk enn gjennmsnittet av individene) [*] Cmbinatin f sftware develpment effrt predictin intervals: Why, when and hw? Jørgensen and Mløkken, SEKE Gruppe-estimering vinner frem i nrsk IT-industri (undersøkelse på JavaZne 2007) Strukturert gruppe-estimerings g påvirkning gpå pplevd estimeringsnøyaktighet (JavaZne 2007) 50% pplever at estimeringsnøyaktigheten var frbedret 30% pplever at estimeringsnøyaktigheten g var uendret 10% pplever at estimeringsnøyaktigheten var frverret 10% visste ikke 27 28

8 Metder fr strukturert gruppe-estimering Planning Pker Wide-band Delphi Planning Pker Smidig ( Agile ) estimeringsteknikk ingsteknikk Beskrevet av Grenning [1] g Chn [2] Kunden frklarer user stry Teamet diskuterer hvilken jbb sm må gjøres Alle velger et krt sm representerer estimatet Alle viser estimatet sitt samtidig De med lavest g høyest estimat begrunner Teamet diskuterer estimatene Gjenta fra steg 3. frem til estimatene knvergerer Teamet blir enige m et estimat 29 [1] J. W. Grenning, Planning Pker, 2002 [2] M. Chn, Agile Estimating and Planning, Når kan vi bruke Planning Pker? Release-planlegging kunden velger funksjnalitet fr neste release estimatene er basis fr å priritere kravene g prsjektbemanningen Planning Pker kmmer raskt pp med realistiske estimater g avslører uklare krav Iterasjnsplanlegging g design Bryter ned kravene i knkrete ppgaver g tildeler ansvar fr ppgavene Estimering med Planning Pker avslører uklare krav Planning Pker kan fasilitere design-diskusjner Estimering av relativ størrelse Estimér relativ størrelse, ikke varighet Vi er flinkere å vurdere størrelse enn tid Uavhengig av hvem sm utfører ppgaven Alternative ti enheter fr størrelse Stry pints Ideelle dager Bli enige m en referanse Finn en en ppgave sm dere vurderer til å være litt større enn de aller minste, g gi den størrelsen 2. Estimer størrelsen av resterende ppgaver relativt til referanseppgaven Utled varighet under planleggingen l Mål prsjekthastigheten g bruk gårsdagens vær Prsjekthastighet = summen av stry pints levert i iterasjn 31 32

9 Utprøving av Planning Pker Hva estimerer du? Gå sammen i grupper på 3 Tenk at dere sammen prgrammerer et Yahtzee-spill Det er ny sprint g dere estimerer brukerhistrier fr pengberegning Dere har estimert pengberegning fr Enere til 2 peng Estimer pengberegning g g fr Ett par g Hus (t estimater): 1. Diskuter hvrdan pengberegning fr Ett par er ift Enere 2. Estimer hver fr dere den relative størrelsen til pengberegning av Ett par ift Enere 3. Vis estimatet deres samtidig (med fingrene, én finger=1 peng) 4. De med høyeste g laveste estimat begrunner 5. Diskuter estimatet 6. Gjenta fra steg 2. frem til dere blir enige m et estimat Gjenta prsessen fr pengberegning av Hus (2+3 like) Bør vi bruke faste eller fleksible størrelser? Bør vi frsøke å bli (helt) enige eller skal vi bruke gjennmsnittet? Faste størrelser er enklere g mer effektivt Eksperimenter med fleksible størrelser indikerer at teamet fte standardiserer uansett Færre valg øker temp Fibnacci-sekvensenereffektiv:12358splitt er effektiv: 1, 2, 3, 5, 8, splitt Husk: dette er estimater Vi trenger ikke den ekstra presisjnen sm fleksible estimater gir Pluss/minus et par timer er fte ikke veldig viktig Begrunn estimatene etter den første runden med Planning Pker Avdekker hva man har tatt hensyn til i estimeringen Viktig fr å avdekke mest mulig detaljer Anbefaling Gjør alltid minst t runder med Planning Pker Frtsett så lenge frskjellene i estimater er stre Bruk gjennmsnittet (eventuelt flertallet) når frskjellene er små 35 36

10 Andre vanlige spørsmål Hva gjør du når kunden ikke er tilstede? Utnevner en av utviklerne til å presentere kravene Skriver ned antakelser, g sjekker disse med kunden i etterkant Hva gjør du dersm du ikke har krtstkk? t kk? Bruker fingre eller skriver estimatene på lapper Hva gjør du dersm enhetene du skal estimere i ikke passer med enhetene på krtene? Tilpasser enhetene. Fr eksempel et krt med 1 på kan dere bli enige m at betyr 100, 2 betyr 200, sv. Frhld man bør ta hensyn til Bruke fr mye tid / grave seg ned i fr mange detaljer Ikke diskutert altfr lenge før den første runden med pker Etter en stund vil diskusjnene gi mindre verdi Bruk en stppeklkke kk dersm lange diskusjner er et prblem Husk at dette er estimater Ikke fange pp de frskjellige synspunktene Mange spørsmål vil kmme pp i diskusjnene Viktig å ha representanter med frskjellige synspunkt tilstede Hvrfr virker Planning Pker? Industrial studies Samtidig visning av estimater kan redusere nen feilkilder Det første estimatet vil nrmalt danne et anker Nen i teamet har mer inflytelse enn andre Flere spørsmål blir stilt, g mer infrmasjn blir delt Flere hder husker mer De med frskjellige synspunkt har kmpetanse innen frskjellige mråder Flere estimerer Kmbinering av estimater reduserer ver-ptimisme Estimeringsstrategiene varierer Estimatene reflekterer teamets gjennmsnittelige evne til å løse ppgaven Ekspert-estimater estimater har en tendens til å basere seg på ekspertens evner Dere vet ikke nødvendigvis hvem sm vil ende pp med å gjøre ppgaven Det er gøy! gy Planning pker vs. unstructured grup Planning pker vs. individual expert Sprint planning (2 weeks) Planning scale Release planning Sprint planning (2-3 mnths) Team 8-12 develpers 4-6 develpers Autmated acceptance Yes N tests Pair prgramming Yes N Prgress visibility Stry cards n wall Jira Custmer view in Business analyst Develpers sessin 39 40

11 Felles fr begge studiene Planning pker vs. ustrukturert gruppe-estimering Mr! Begge teamene frtsatte med dette! Actual effrt (pair days) Mer effektiv estimeringsprsess gp Økt eierskap til estimatene Økt ansvar fr prjektets jktt prgresjn Men hvrdan påvirket det estimeringsnøyaktighet? Estimated effrt (pair days) Planning pker vs. Individuell ekspert-estimering Wideband Delphi (eksempel) Actual effrt (hurs) Estimated effrt (hurs) Frbredelse av estimeringsprsessen Utarbeid estimeringsmateriell Velg estimeringspersnell inklusive en rdstyrer Kick-ff-møte Ordstyreren presenterer estimeringsppgaven, estimeringsmaterialet, estimeringsprsessen, estimeringsstørrelsene, sv. Gruppen diskuterer valg av eksperter, etc. Individuell estimering Identifiser aktiviteter g estimer Snakk med eksterne eksperter ved behv Estimeringsmøte Ordstyrer ppsummerer estimatene g aktivitetslistene Ekspertene diskuterer resultatene (fkuser på annymitet) Oppsummering Ofte gjrt av rdstyrer g prsjektleder 43 44