Estimering av kostnader i IT-prosjekter

Transkript

1 Planleggingsfasen.. Esimering av kosnader i IT-prosjeker Jo Hannay Simula Research Laboraory Deparmen of Sofware Engineering 2 Gjennomføringen. Overskridelser Beydelig underesimering av kosnader % av prosjeker har kosnadsoverskridelser. Gjennomsnilig overskridelser er 30-40%. Hva er e esima? En (kvalifiser) gjening/beregning på hva e IT-prosjek vil komme il å kose å gjennomføre (il førse release). Prosjeke vil kose kr. 50 mill. Brukes i anbudskonkurranser, i konraksinngåelser og for a diverse akører (leverandør, kunde, prosjekledere, ) skal kunne beregne ugifer. Overopimisme: For lav esima, alså underesimering. Urealisisk syn på usikkerheen i esimaer. Folk er eplekjekke mh egen vurderingsevne. 3 4 Hva er en usikkerhesvurdering? En (kvalifiser) gjening/beregning på hvor usikker e esima er. Prosjeke vil kose kr. 50 mill. +/- kr. 10 mill., og de er jeg 75% sikker på. Ehver kosnadsesima i bør være gi med e usikkerhesanslag. Eplekjekk (overconfidence): For snever usikkerhesinervall med for sor sikkerhe. Prosjeke vil kose kr. 50 mill. +/- kr. 5 mill., og de er jeg 95% sikker på.

2 5 Overskridelser Ingen vesenlig forbedring over id. Sudier indikerer a vi er like dårlige il å esimere som for 30 år siden. Ingen læring av feil eller erfaring. Konsekvenser: Prosjek: kursendring, omorganisering, avbrudd Kunder: misfornøyde, økonomiske ap Leverandør: dårlig lønnsomhe, ap (også av anseelse), konkurs Samfunn: sore verdier går ap, infrasrukur kommer ikke på plass. - IKT er i følge SSB Norges nes sørse næring. Prosjeker i sørrelsesorden > MNOK Global sasning på IKT for humaniære, økologiske og økonomiske ufordringer. Spørreundersøkelse 2007 av mer enn 1000 IT-uviklere: (hp://cerificaion.compia.org/projec) To av de re mes kriiske fakorene ved IT-prosjekkaasrofer er relaer il kosnadsesimering. 6 SKARP-prosjeke 1995: Dagens skaeregnskapssysem (Sandardska) er over 20 år gammel, Cobol-baser og vanskelig å vedlikeholde, og oppfyller ikke formelle krav il sikkerhe, konroll og sporbarhe i slike sysemer. De koser også svær mye å drife (50-60 mill kroner pr år). 1996: Prosjeke iniier. Dee er de sørse i-prosjeke direkorae noensinne har igangsa, med en kosnadsramme på nærmere 1 milliard kroner. 2000: WM-Daa får faspriskonrak på levering av de nye skaeregnskapssyseme (SOFIE) for Skaedirekorae. 2002: Tesingen av leveransene fra WM-daa skulle sare idlig våren 2002, og skulle eer planen sees i drif høsen De er forsinkelser i prosjeke. Ryker om a WM-daa allerede uvikler grais. 2003: Skaedirekorae k hever avalen med WM-Daa. Skaeeaen mener a årsaken il forsinkelsene i SKARP-prosjeke førs og frems skyldes de uføre konraken med VM-daa medføre. VM-daa aper presisje, 250 millioner kroner, og 28 ansae måe gå. 2003: Ny avale inngås med Cap Gemini, baser på Todel konrak: SOFIE Basis (kjernen) og SOFIE Innføring (brukergrensesnie)) PS2000 konraksandarden og ieraiv/inkremenell prosess. 2005: Pilokommuner i drif (Sor bidragsyer for å bedre kvalieen på syseme. Brukersøe senral. Sor ufordring som må løses: konverering av daa fra gammel sysem). 2006: Cap Gemini inngår re konraker om sluleveranser (uvide funksjonalie og feilreinger). Svær fleksibel konraksform i forhold il hvilke uvidelser og feilreinger som skal med i hvilken release. 2007/2008: Alle skaeoppkreverne ar i bruk syseme i løpe av 2007, med unnak Oslo kemnerkonor som ikke vil a syseme i bruk før SOFIE er baser på Oracle Applicaions og over 1000 egenuviklede programvaremoduler. Hva er probleme? Task/Oppgave-definisjon Kosnadsesimering: Forsøk på å foruse fremiden (forecasing). Vellykke: sjakk, forsikring, medisin Til dels vellykke: vær, håndverk, gambling (J. Shaneau) Kaasrofal: børs og finans, kjeærligheslive, sysemuvikling -Uvikling - IT-Sysem / Sprin release 7 Komplekse sysemer / Ill-srucured ask / Task complexiy (H.A. Simon, K.A. Ericsson, D.J. Campbell, S. Bonner, R.E. Wood, M. Abdelmohammadi, A. Wrigh). Sysemuvikling er en kompleks ikke-srukurer oppgave o o o o Løs definere krav som endrer seg underveis (behovsendringer, nye forskrifer, markedsendringer, må være sånn ellers kommer man aldri igang) Komplekse prosjeker (ny eknologi, vanskelig å bygge på idligere erfaringer, idspress, nyuvikling -- ikke produksjon) Personal-problemer (sykdom, avgang av nøkkelpersonale, rekruering) Ny IT-sysem medfører komplekse organisasjonsendringer (ikke-it-akige suksesskrierier, følelser og posisjonering) Esimering av sysemuvikling er 2. ordens kompleks og ikke-srukurer! 8 Sysemuviklingsprosess

3 Capabiliy Mauriy Model Inegraion (CMMI): (hva som burde skje) Task/Oppgave-definisjon Mauriy Level 5 In Task-definisjon Ou Kosnadsesimering Prob abiliy arge Sysemuviklingsprosess -Uvikling - IT-Sysem /Sprin release iliy arge Mauriy Level 4 In Ou Probab Mauriy Level 3 In Ou Proba abiliy arge Mauriy Level 2 In Ou Prob babiliy arge Mauriy Level1 In Ou Pro obabiliy arge -??? - Esima med usikkerhesvurdering 9 10 Task/Oppgave-definisjon Task/Oppgave-definisjon Sysemuviklingsprosess Sysemuviklingsprosess -Uvikling - IT-Sysem Sprin release -Uvikling - IT-Sysem / sprin release In Ou In Ou Top-down-esimering E Boom-up-esimering x1 x2 x3 x = E x1 x2 x3 x4 X1.1 X4.1 + X2.1 X3.1 -??? usikkerhesvurdering -??? usikkerhesanslag 11 12

4 Top-down eller boom-up? -esimering vs. Esimerings-modeller Resula: Magne Jørgensen,Top-Down and Boom-Up Exper Esimaion of Sofware Developmen Effor, Journal of Informaion and Sofware Technology 46(1):3--16, Donald MacGregor, Decomposiion for judgmenal forecasing and esimaion, in Principles of forecasing: A handbook for researchers and praciioners, 2001, p Top-down-esimering forerukke av managers, boom-up-esimering forerukke av eknisk personell (programmerere) Top-down-esimering avhengig av a de finnes gode analogier Boom-up avhengig av dybdekunnskap Top-down kan gi bedre esimaer -esimering: Kvanefiseringssege er gjor på en ikke-eksplisi, ikke-analyisk måe, muligens baser på inuisjon. Merk: Inuisjon er illær inegrer kunnskap (Hogarh: Educaing Inuiion, 2001.) Esimeringsmodeller: COCOMO, SLIM, PRICE-S, Esimacs, MkII Funcion Poin, IFPUG Funcion Poin, Feaure Poins, Kvanefiseringssege er gjor på en analyisk, mekanisk, saisisk måe. Resula: I mange disipliner (økonomi, medisin, meeorologi, managemen) viser forskning a modeller gir bedre esimaer enn eksperer gir (J. Armsrong, Principles of Forecasing. A Handbook for Researchers and Praciioners,2001). p g ( g p g ) Men i sysemuvikling viser forskning a eksperesimering er bedre enn modellene! (M. Jørgensen, Esimaion of Sofware Developmen Work Effor: Evidence on Exper Judgmen and Formal Models. Inernaional Journal of Forecasing, 23(3), 2007.) Kvanefiseringsseg g Top-down er raskere og billigere usikkerhesvurdering Gjelder å finne re nivå: Kombinasjon av op-down og boom-up. (de er ofe en forvenning om a boom-up er fasien ) Analogi-baser esimering Eksempel på eksper-esimering Baser på å finne analoger: liknende prosjeker, proo-/erkeypiske prosjeker. Hisoriske daa -> Sysemaisere hisoriske daa -> Essensielle karakerisikker -> Erkeyper Resula: Vanskelig. De ser u il a prosjekledere må ha analoger som er svær like il de prosjeke som skal esimeres. Man baserer seg på overflae-likheer. De finnes ennå ingen god forsåelse av dype karakerisikker av IT-prosjeker som ville gjøre de mulig å lage erkeyper. Man må ha i sede ha en sor base med hisoriske prosjeker. (cues) Hvilke og hvor mange? Vi er lær opp il å sanke all ilgjengelig informasjon og dereer a en besluning. (Rasjonel og analyisk.) Men de er rolig ikke slik vi har overlevd som ar! Vi er ikke gode il å behandle mye informasjon. Besluningssraegier som bruker få men vikige cues: Take he bes (G.Gigerenzer, E. Todd, ABC Group, Heurisics ha Make Us Smar, Oxford, G. Gigerenzer,, Gu Feelings, he Inelligence of he Unconscious,, Penguin, 2007). Avhenger av esimeringsprosess? Ja. Syrer esimeringsprosess? Ja. Men de er rolig mye å hene på å gjøre forbedringer. Srebe mo å sysemaisere hisoriske daa og lage verkøy som kan hjelpe prosjekledere å finne analogiske prosjeker. På vei mo erkeyper: Hva er de essensielle karakerisikkene? Hvor mye informasjon er nødvendig? Fordrer en eori for sysemuvikling. Kvanefiseringsseg g - Analogibaser usikkerhesvurdering - Analogibaser usikkerhesvurdering 15 16

5 (cues) Syrer prosjekleders innrykk av prosjeke? Ja, mer enn man skulle ro. IFI-sudener esimere arbeidsmengde il den samme programmeringsoppgaven Gruppe A: Fikk den originale spesifikasjonen, som var en side lang Gruppe B: Fikk en versjon av spesifikasjonen som hadde idenisk eks, men var på syv sider. Økningen i lengde skyldes dobbel linjeavsand, vide marger, sørre fon-sørrelse og mer avsand mellom avsniene Long Normal Difference Mean % SDev % Resula:. Folk lar seg påvirke av fysisk sørrelse på kravspesifikasjon, av ledende ord, av irrelevan informasjon; selv om de gjøres oppmerksom på hva som er irrelevan! (M. Jørgensen, S. Grimsad. How o Avoid Impac from Irrelevan and Misleading Informaion When Esimaing Sofware Developmen Effor,, IEEE Sofware(May/June), 2008). Mye av esimeringsprosessen er ubeviss! Mye av esimeringsprosessen er ubeviss! Irrelevan og ledende informasjon. Ankereffek. Gruppe A :Tidlig anslag 10 mill->endelig anslag 30 mill Gruppe B: Tidlig anslag 20 mill->endelig anslag 50 mill Timeslo-effek. De ar meg 3 dager programmere 2 user sories, men gi meg 3 dager så får jeg ferdig 4. Overopimisme ved imeslo-spørsmålsilling. (T. Jørgensen 2009) Hva er esimae egenlig? De gir mye høyere esimaer å sare med idelle imer (ana ingen forsyrrelser, full konsenrasjon og opp produkivie) for dereer å esimere mes sannsynlig, enn å gå re på mes sannsynlig. Dee rolig i all hovedsak fordi man i de sise ilfelle egenlig esimerer Idelle imer. (M. Jørgensen 2009). Eksponering il urelaer analogi-baser prosess før esimering gir analogi-baser prosess i esimeringen. Mes sannsynlig Timesloeffek Ideelle imer? Irrelevan/ledende Ankereffek imer? informasjon - Analogibaser usikkerhesanslag - Analogibaser usikkerhesanslag Ue av konroll? Hva skal man gjøre? Man kan kompensere for de ubevisse effekene dersom man forsår når og i hvilken grad de oppsår. Man kan øke bevissheen om fallgruber. Ve a de er vanlig å bruke analogier feil: Dee prosjeke er dobbel så sor som de forrige, så da ar de dobbel så lang id. Feil! Ve a de er dårlig læring. Derfor: Ikke ana a du kommer il å gjøre de bedre nese gang! (De vil oppså andre vanskeligheer!) Ve a forsåelse av risiko er ufullsendig Ue av konroll? Hva skal man gjøre? Man kan forbedre kommunikasjonen mellom kunde og leverandør: Dee krever a man seer av mer ressurser il forberedelser/involvering/oppfølging (agile er vanskelig for kunden) a kunden blir IT-kyndig (mer akuel under agile/scrum) a man ar problemsillingene seriøs også på oppledelsesnivå a man bruker gode konrakssandarder (PS2000) som eksplisi ar silling il risikodeling Dårlig læring av erfaring Irrelevan/ledende informasjon Ankereffek Feil bruk av analogier Timesloeffek Dårlig forsåelse av usikkehe/risiko Ideelle imer? Mes sannsynlig imer? Uklare krav Ikke felles forsåelse Irrelevan/ledende informasjon Ankereffek Dårlig læring av erfaring Feil bruk av analogier Fylleffek Dårlig forsåelse av usikkehe/risiko Ideelle imer? Mes sannsynlig imer? - Analogibaser usikkerhesanslag - Analogibaser usikkerhesanslag 19 20

6 Incenivmodell: Usikkerheshåndering Ue av konroll? Hva skal man gjøre? Man kan bruke en hensiksmessig uviklingsprosess: Sudier vi har gjennomfør vise blan anne a (2003): Fossefall: 55% overskridelse Inkremenelle/ieraive i prosesser: 24% overskridelse Sysemuviklingsprosess -Uvikling - IT-Sysem /Sprin release Uklare krav Ikke felles forsåelse Irrelevan/ledende informasjon Ankereffek Dårlig læring av erfaring Feil bruk av analogier Fylleffek Dårlig forsåelse av usikkehe/risiko Ideelle imer? Mes sannsynlig imer? - Analogibaser usikkerhesanslag Tross al ikke så ille Sandish Group CHAOS rappor 1994: Gjennomsnilig overskridelse på 189% M. Jørgensen, K. Moløkken-Øsvold: CHAOS-rapporen ikke il å sole på. Biased uvalg. (How Large Are Sofware Cos Overruns? Criical Commens on he Sandish Group s CHAOS Repors. Informaion and Sofware Technology, (4): p ) Ikke så mye verre enn andre næringer? Ikke le å si. Mye poliikk, anbudsspill, osv. Evidensbaser veiledning il esimeringsprosess 23 24

7 Forberedelser 1. Forså esimeringsprobleme o Idenifiser mål og krav il nøyakighe o Idenifiser ineressener og poliiske posisjoner o Spesifiser foruseninger o Besem nedbrying av probleme 2. Enighe om besluninger og foruseninger o Idenifiser relevane besluninger og foruseninger som kan påvirke o Avgjør om de er meningsfull og nødvendig å esimere på nåværende idspunk o Avklar fleksibilie og prosjekpriorie 3. Innhen relevan informasjon Forberedelser o Idenifiser selskapsspesifikke p kosnadsdrivere o Pass på a kildene er uhilde o Innhen informasjon fra flere kilder o Unngå irrelevan informasjon o Idenifiser hisorisk daa fra idligere prosjeker 4. Velg esimeringsprosess o Baser prosessen på ilgjengelig informasjon o Beny organisasjon og personspesifikk informasjon Esimeringsfasen 5. Esimer mes sannsynlig arbeidsmengde o Srukurer esimeringsprosessen o Separer mes sannsynlig arbeidsmengde fra ilbud, plan ec. o Beskriv foruseninger o Beskriv underliggende informasjon for eerprøvbarhe Esimeringsfasen 7. Gjennomgang av esimeringsprosessen og esima o Beny uavhengige eksperer il gjennomgang o Sørg for a gjennomgangen kan føre il forandringer o Beny en sjekklise 6. Anslå usikkerhe 27 28

8 Anvendelsesfasen 8. Beny esimaene i ilbudsskriving o Ta ugangspunk i mes sannsynlig arbeidsmengde og esima- usikkerheen 9. Beny esimaene i planleggingen o Besem buffer for uforusee hendelser o Planlegg akivieer som reduserer usikkerhe, som uvikling av delfunksjonalie o Planlegg l re-esimering i Anvendelsesfasen 10. Kommuniser esimaer, ilbud, plan og usikkerhe o En god esimeringsprosess er e god salgsargumen! o Tilpass informasjon eer modenhe o Spesifiser risiko, og hvordan denne skal hånderes o Tilgjengeliggjør oversiklige esimaer og anakelser o Erkjenn og forhold dere il moakers mål, uen å redusere realismen 11. Konroller kosnadene o Moniorer uviklingen og re-esimer o Sørg for å holde alle delakere informer o Favoriser enkelhe Lær av erfaringer Læringsfasen o Arranger erfaringsgjennomganger o Forså underliggende årsaker for evenuelle avvik o Oppdaer sjekklisen, erfaringsdaabasen, WBS ec. på bakgrunn av gjennomgangen o Ikke overgeneraliser Typer usikkerhe i esimaene og hvordan disse hånderes Normalvariasjon i produkivie o Angis f eks som minimum-maksimum maksimum inervaller per akivie Risiko som følge av kjene risikofakorer o Angis f eks som sannsynlighe x ufall, sam innvirkning på oal kosnadsforbruk og evenuelle ilak men kan gjøre Risiko som følge av uvenede hendelser ( forven de uvenede ) o Angis som risikobuffer baser på andel kosnader il håndering av uvenede hendelser Kaos (f eks oal endring i prosjekes manda) o Krisehånderingsruiner 31 32

9 Li om (formelle) esimeringsmodellener COCOMO, SLIM, PRICE-S, Esimacs, MkII Funcion Poin, IFPUG Funcion Poin, Feaure Poins, Vikig prinsipp: Bruk enkle meoder dersom de ikke er påvis a de mer komplisere modeller er bedre og de er de ikke for de som er nevn ovenfor! De sudiene som er gjennomfør viser a enkle modeller er mins like gode som de mer avansere modellene. En grunn il dee er a enkle modeller er mer robuse, dvs de gjør ikke så mange anagelser mhp fordelinger og sammenhenger. Dessuen, enkle modeller muliggjør a brukeren skjønner anagelser og uregninger, kan forholde seg il esimaene. Sudier viser også a eksper-esimaer, selv uen bruk av hjelpemidler, som ofes gir mer nøyakige esimaer enn bruk av modeller. Kor oppsummering Når du skal esimere arbeidsmengde for en uviklingsoppgave eller e prosjek så bør du: o Ha hisoriske daa for lignende oppgaver ilgjengelig (eller ha ilgang på personer med svær relevan erfaring). o Unngå irrelevan informasjon (f eks hva personer som er mye mer erfarne enn deg ville bruk på oppgaven eller hva kunden forvener) o Frigjøre deg fra fakorer som fører il ønskeenkning (f eks unngå siuasjoner der esimae blir e middel il å signalisere effekivie) i ) o Srukurere prosessen vha sjekkliser (lag din egen baser på idligere erfaring og kombiner med andres!) o Kombiner esimaer fra flere ulike kilder (hels uavhengige) o Ikke fokusere på dealjer, men på de mes usikre områdene (høy dealjering av akivieer fører ofe il dårligere nøyakighe, men sørre ro på dem) Eksperimen: individuell vs gruppe-esimering esimering Gruppe-esimering i Tyve fagpersoner fra samme firma esimere hver for seg arbeidsmengden for de samme sysemuviklingsprosjeke [*] Delakerne hadde forskjellig bakgrunn Prosjek var e reel prosjek som var implemener De dele seg dereer opp i fem grupper. Hver gruppe ble enig om e felles esima Gjennom diskusjon og kombinasjon av kunnskap [*] Moløkken-Øsvold and Jørgensen (2003): Sofware Effor Esimaion: Unsrucured Group Discussion as a Mehod o Reduce Individual Biases. In The 15h Annual Workshop of he Psychology of Programming Ineres Group

10 Resulaer Esimaene som var baser på gruppe-diskusjon var nærmere den fakiske k arbeidsmengden d enn gjennomsnie av de individuelle esimaene Mulig forklaring: Gruppenes evne il å idenifisere flere prosjek-akivieer Mulig forklaring: A de i gruppen måe begrunne esimaene sine kan medføre a realisme øker Vi fan lignende resulaer i e eksperimen hvor vi undersøke usikkerhesinervall [*] Gruppediskusjoner medføre a man anga mer realisiske usikkerhesinervaller Forskning på gruppe-esimering esimering Få sudier innen Sofware Engineering men mange relevane sudier innen andre forskningsfel (psykologi, business forecasing, ec) Resulaer Kombinering av esimaer forbedrer esimeringen (spesiel når de som esimerer har forskjellig bakgrunn). Markes. Srukur kan forbedre esimeringen (for eksempel: redusere påvirkningen fra irrelevan informasjon) Flere hoder husker mer Ulemper Ressurs-krevende (dyr) sammenligne med individuell esimering Group hink kan forekomme (for eksempel: alle er enige med sjefen) Group polarizaion kan forekomme (for eksempel: gruppen er mer opimisisk enn gjennomsnie av individene) [*] Combinaion of sofware developmen effor predicion inervals: Why, when and how? Jørgensen and Moløkken, SEKE 2002 Gruppe-esimering vinner frem i norsk IT- indusri i (undersøkelse på JavaZone 2007) Srukurer gruppe-esimerings påvirkning på opplevd esimeringsnøyakighe (JavaZone 2007) 50% opplever a esimeringsnøyakigheen var forbedre 30% opplever a esimeringsnøyakigheen var uendre 10% opplever a esimeringsnøyakigheen var forverre 10% visse ikke

11 Meoder for srukurer gruppe-esimering esimering Planning Poker Wide-band Delphi Planning Poker Smidig ( Agile ) esimeringseknikk Beskreve av Grenning [1] og Cohn [2] Team på 4-5 personer. En er kunde (produk eier), resen er uviklere (leverandører) (eller andre ineressener). 1. Kunden forklarer user sory 2. Teame diskuerer hvilken jobb som må gjøres 3. Alle velger e kor som represenerer esimae 4. Alle viser esimae si samidig 5. De med laves og høyes esima begrunner 6. Teame diskuerer esimaene 7. Gjena fra seg 3. frem il esimaene konvergerer 8. Teame blir enige om e esima [1] J. W. Grenning, Planning Poker, 2002 [2] M. Cohn, Agile Esimaing and Planning, 2005 Esimering av relaiv sørrelse Esimér relaiv sørrelse, ikke varighe Vi er flinkere å vurdere sørrelse enn id Uavhengig av hvem som ufører oppgaven Alernaive enheer for sørrelse Sory poins Ideelle dager Bli enige om en referanse Finn en en oppgave som dere vurderer il å være li sørre enn de aller minse, og gi den sørrelsen 2. Ei Esimer sørrelsen av reserende oppgaver relaiv liilil referanseoppgaven Uled varighe under planleggingen Mål prosjekhasigheen ee og bruk gårsdagens s vær Prosjekhasighe = summen av sory poins lever i ierasjon Planning Poker Team på 4-5 personer. En av dere er kunde (produkeier), resen er uviklere (leverandører). Velg en user sory som referanse en som ser lien u men ikke mins. Se den il Kunden forklarer user sory 2. Teame diskuerer hvilken jobb som må gjøres 3. Alle velger e kor som represenerer deres esima 4. Alle viser esimae si samidig 5. De med laves og høyes esima begrunner 6. Teame diskuerer esimaene 7. Gjena fra seg 3. frem il esimaene konvergerer 8. Teame blir enige om e esima

12 Bør vi bruke fase eller fleksible sørrelser? Hva esimerer du? Fase sørrelser er enklere og mer effekiv Eksperimener med fleksible sørrelser indikerer a eame ofe sandardiserer uanse Færre valg øker empo Fibonacci-sekvensen er effekiv: 1, 2, 3, 5, 8, spli Husk: dee er esimaer Vi renger ikke den eksra presisjonen som fleksible esimaer gir Pluss/minus e par imer er ofe ikke veldig vikig Bør vi forsøke å bli (hel) enige eller skal vi bruke gjennomsnie?? Begrunn esimaene eer den førse runden med Planning Poker Avdekker hva man har a hensyn il i esimeringen Vikig for å avdekke mes mulig dealjer Anbefaling Gjør allid mins o runder med Planning Poker Forse så lenge forskjellene i esimaer er sore Bruk gjennomsnie (evenuel fleralle) når forskjellene er små Forhold man bør a hensyn il Bruke for mye id / grave seg ned i for mange dealjer Ikke diskuer alfor lenge før den førse runden med poker Eer en sund vil diskusjonene gi mindre verdi Bruk en soppeklokke dersom lange diskusjoner er e problem Husk a dee er esimaer Ikke fange opp de forskjellige synspunkene Mange spørsmål vil komme opp i diskusjonene Vikig å ha represenaner med forskjellige synspunk ilsede

13 Andre vanlige spørsmål Hva gjør du når kunden ikke er ilsede? Unevner en av uviklerne il å presenere kravene Skriver ned anakelser, og sjekker disse med kunden i eerkan Hva gjør du dersom du ikke har korsokk? Bruker fingre eller skriver esimaene på lapper Hva gjør du dersom enheene du skal esimere i ikke passer med enheene på korene? Tilpasser enheene. For eksempel e kor med 1 på kan dere bli enige om a beyr 100, 2 beyr 200, osv. Hvorfor virker Planning Poker? Samidig visning av esimaer kan redusere noen feilkilder De førse esimae vil normal danne e anker Noen i eame har mer inflyelse enn andre Flere spørsmål blir sil, og mer informasjon blir del Flere hoder husker mer De med forskjellige synspunk har kompeanse innen forskjellige områder Flere esimerer Kombinering av esimaer reduserer over-opimisme Esimeringssraegiene varierer Esimaene reflekerer eames gjennomsnielige evne il å løse oppgaven -esimaer har en endens il å basere seg på eksperens evner Dere ve ikke nødvendigvis hvem som vil ende opp med å gjøre oppgaven De er gøy! Når kan vi ellers bruke Planning Poker? Release-planlegging g kunden velger funksjonalie for nese release esimaene er basis for å prioriere kravene og prosjekbemanningen Planning Poker kommer rask opp med realisiske esimaer og avslører uklare krav Ierasjonsplanlegging og design Bryer ned kravene i konkree oppgaver og ildeler ansvar for oppgavene Esimering med Planning Poker avslører uklare krav Planning Poker kan fasiliere design-diskusjoner To indusrielle sudier Planning gpoker vs. Planning poker vs. unsrucured group individual exper Planning scale Release planning Sprin planning (2-3 monhs) (2 weeks) Team 8-12 developers 4-6 developers Auomaed accepance Yes No ess Pair programming Yes No Progress visibiliy Sory cards on wall Jira Cusomer view in session Business analys Developers

14 Felles for begge sudiene Moro! Begge eamene forsae med dee! Acual effor (pair days) Planning gpoker vs. usrukurer gruppe-esimering g Mer effekiv esimeringsprosess Øk eierskap il esimaene Øk ansvar for projekes progresjon Men hvordan påvirke de esimeringsnøyakighe? Esimaed effor (pair days) Planning gpoker vs. Individuell eksper-esimering Wideband Delphi (eksempel) Acual effor (hours) Esimaed effor (hours) Forbredelse av esimeringsprosessen Uarbeid esimeringsmaeriell Velg esimeringspersonell inklusive en ordsyrer Kick-off-møe Ordsyreren presenerer esimeringsoppgaven, esimeringsmaeriale, esimeringsprosessen, esimeringssørrelsene, osv. Gruppen diskuerer valg av eksperer, ec. Individuell esimering Idenifiser akivieer og esimer Snakk med ekserne eksperer ved behov Esimeringsmøe Ordsyrer oppsummerer esimaene og akivieslisene ene diskuerer resulaene (fokuser på anonymie) Oppsummering Ofe gjor av ordsyrer og prosjekleder

15 Slu