Nyttestyring og gode brukerhistorier. Stein Grimstad, 25.august, ITPP

Transkript

1 Nyttestyring og gode brukerhistorier Stein Grimstad, 25.august, ITPP

2 Presentasjonen er basert på egne erfaringer, forskning, erfaringsrapporter og diskusjoner med fagpersoner Oppdrag som produkteier og/eller arkitekt hos Telenor, Fronteer, Skatteetaten, Lindorff, m.fl. Forskningsprosjektet SMOIS (se: ) og HIT-nettverket Diskusjoner med Gunnar Olving (Promis), Magne Jørgensen (Simula), Kjetil Strand (Promis), m.fl. Send kommentarer og spørsmål til: stein@scienta.no

3 Svært mange IT-prosjekter leverer vesentlig mindre forretningsverdi ennforventet. Ca 10% av IT-prosjekter leverer ikke forretningsverdi i hele tatt (nasjonale og internasjonale studier) Gjennomsnittelig ca. 30% mindre nytte enn forventet Mye funksjonalitet som utvikles har liten forretningsverdi Ca % høyere kostnader enn forventet i gjennomsnitt Svært få IT-prosjekter ender med å koste vesentlig mindre enn budsjettert

4 Noen resultater fra forskningsprosjektet SMIOS 35 prosjekter fra 11 offentlige aktører deltok i en undersøkelse for å identifisere hva som kjennetegner de prosjekter som lykkes best Ca 70% rapporterte at de hadde leverte nytte som planlagt (eller mer) Ca halvparten leverte ogsåihht. planlagt tid, kostnad og kvalitet Nyttestyring er blant de hyppigst nevnte suksessfaktorer, utfordringer og forbedringsområder Typiske kjennetegn ved de mest suksessfulle prosjektene Har en kunde som er sterkt involvert i planlegging av nytte og nyttestyring underveis Har høy grad av linje-involvering (typisk mer enn 50% av totalt ressursbruk) Har fleksibilitet i omfang (alt er ikke må -funksjonalitet) Har hyppige leveranser til produksjon (eller en realistisk evaluering) Bruker kontrakter som unngår fastprisoppførsel for leverandør (og kunde)

5 SMIOS: Nyttestyring Nyttestyring JA Nei Business case ved oppstart 26 (31% med problemer) 9 (22% med problemer) Plan for nyttestyring 17 (29% med problemer) 18 (28% med problemer) Underveisstyring av nytte 15 (20% med problemer) 20 (35% med problemer) Ansvarlig for gevinstrealisering (uthenting av nytte) 18 (28% med problemer) 17 (29% med problemer) Underveisstyring av nytte er den praksisen som slår mest positivt ut, men er minst i bruk og mest umoden!

6 Seks sentrale steg i nyttestyring 1. Finn verdien av effektmålene 2. Anslå hvor mye hver epos bidrar til detenkelte effektmål 3. Vurder om scope bør justeres 4. Fordel epos et sitt nyttebidraget på brukerhistorier 5. Bruk av nyttestyringsmodellen underveis: Prioritering av brukerhistorier Justering av brukerhistorier Verifikasjon av leveranser Rapportere fremdrift, m.m. 6. Oppdater modellen når nye resultater foreligger Epos Brukerhistorier Effektmål Gevinst

7 Finn verdien av effektmålene Epos Effektmål Verdi av hvert effektmål Brukerhistorier Gevinst Del opp gevinstene slik at det er 1-1 mellom gevinster og effektmål Bestem verdien av kvalitative gevinster (anbefalt: MISHRI-modellen) X viktigere enn M, men ikke viktigere enn N Y dobbelt så viktig som Z

8 Anslå leveranseområdenes bidrag til effektmålene EPOS Automatic Regression Tests Design Split Runtime Split Effektmål EG01: Leveranser i alle releaser 70 % 30 % 0 % 170 EG02: Økt utviklingseffektivitet 35 % 65 % 0 % 75 EG03: Støtte for innovative tjenester 10 % 10 % 80 % 50 EG04: Økt offshoring 40 % 60 % 0 % 22 EG05: Økt robusthet 30 % 30 % 40 % 52 EG06: Bedre støtte for IT-modernisering 20 % 50 % 30 % 45 Leveranseområdeverdi Epos Effektmålverdi Brukerhistorier Effektmål Gevinst Ekspertestimering av leveransenes påvirkning på effektene (estimering av nyttebidrag) Gjennomgang av tilgjengelige produksjonsdata, målbilder, markedsanalyser, og lignende Input til ekspert-estimering Justere resultatene fra ekspertestimering

9 Estimering av nyttebidrag Metode: 1. Beskriv estimeringsoppgaven slik at alle involverte vet de skal gjøre 2. Presenter bakgrunnsinformasjon (feks. baseline-målinger) 3. Gjennomfør ekspertestimering : Planning Poker eller Wide Band Delphi 4. Verifiser resultatene mot andre datakilder, og gjør nødvendige endringer Tips: Vær oppmerksom på at eksperter ofte overvurderer effekten av egne babyer Feks arkitekter og ny teknologi La flere kompetanseområder delta i estimeringen Produkteiere, arkitekter, forretningsutviklere, m.m. Gi opplæring dersom de som estimerer ikke kjenner godt til teknikken

10 Fordeling av nyttebidraget på brukerhistorier Lag en enkel algoritme for å score nyttebidragene A. Kategoriser storyene i Høy, Lav, Middels, og gi hver kategori en vekting B. Finn en passende KPI (feks antall berørte kunder) C. Flat fordeling (alle brukerhistorier i et epos er like viktige) Gjør manuellejusteringer dersom noenhistorier er opplagt viktigere enn det algoritmen tilsier Ikke viktig med millimeternøyaktighet Kan være hensiktsmessig å gjøre denne fordelingen underveis i prosjektet (så sent som mulig) Epos Brukerhistorie Effektmål Gevinst

11 Nyttestyring underveis i prosjekter Bruk nyttemodellen ifbm. prioritering av brukerhistorier Muliggjør kost-nytte-analyser (nyttebidrag / estimat) Ikke glem å hensynta andre, viktige faktorer som risiko, lovmessige forhold, tilgjengelighet påkompetanse, læring, m.m. Evaluer alle leveranser opp mot nytte Fra det første high-level design til produksjonssatt kode Sørg for hyppige leveranser til produksjon Oppdater modellen når ny kunnskap foreligger (viktig at det er enkelt å endre modellen) Rapporter på levert nytte Oftemer relevant enn tradisjonelle målinger basert på forbruk, kravspesifikasjon og estimeringsnøyaktighet (CPI, o.l.)

12 Brukerhistorier og effektiv nyttestyring Egenskaper ved brukerhistoriene Bidrar til prosjektets effektmål Levere forretningsverdi i seg selv Beskriver behov, og ikke løsning Er detaljertenokfor design og estimering Muliggjør hyppige leveranser til produksjon Unngå Å transformere en tradisjonell kravspesifikasjon til en brukerhistorie-drakt Tekniske brukerhistorier (utviklingsoppgaver) hvor det viktigste er forhold som at brukerhistorien passer inn i én sprint, kun medfører endringer i ett system, o.l. Å legge føringer på design og implementasjon i brukerhistorien og akseptansekriteriene

13 INVEST (sjekkliste for brukerhistorier) Independent Brukerhistorien bør stå på egne bein (levere nytte uavhengig av andre stories). Færrest mulig avhengigheter til andre historier. Negotiable Frem til at løsningen er godkjent, så kan brukerhistorier og akseptansekriterier endres/fjernes/legges til (også underveis i sprinten) Valuable Alle brukerhistorier må gi forretningsverdi Estimable Må være mulig å estimere brukerhistorien med tilstrekkelig nøyaktighet for kost-nyttevurdering og prioritering. Size Brukerhistorien bør være så liten så mulig, men ikke mindre enn at den leverer forretningsverdi. Dette reduserer sunk-cost og optimaliserer læring. Testable Brukerhistorien må danne et godt grunnlag for utvikling og test.

14 SMART (sjekkliste for akseptansekriterier) Specific Kriteriet bør være konkret og nyttefokusert Measureable Det må gå klart frem hvordan kriteriet skal verfiseres (hva måles, og hvordan) Assignable Det må gå klart frem hvem som skal verifisere kriteriet Realistic Kritieriet må være realistisk gikk rammer og tilgjengelige ressurser Time-related Det må være mulig å sannsynliggjøre at designet oppfyller kriteriet før utvikling starter, og at levert løsning oppfyller kriteriet før produksjonssetting

15 Oppsummert Epos Effektmål Independent Negotiable Valuable Estimable Small Testable Prioritet Status Brukerhistorie Akseptansekriterie Verifikasjonsmetode Finansielle gevinster Kvalitative gevinster Løsningsdesign med estimat Specific Measurable Assignable Time-related Generelle Krav Utviklingsoppgave(r)

16

17 Noen anti-patterns for nyttestyring Anti-pattern Fastprislignende kontrakt / ikke fleksibelt scope Få leveranser underveis Kommentar Kan føre til at leverandør blir mer opptatt av kontrakt enn av nytte (spesielt ved underestimering), og at kunde blir opptatt av å få 100% av kravspesifikasjon Mindre læring, tar lengre tid før hypoteser blir verifisert. Ikke skille på brukerhistorier og utviklingsoppgaver Medfører gjerne at det blir viktigere at brukerhistorien passer inn i én sprint og kan utvikles av ett team enn at historien leverer nytte for forretningsdomenet. Ikke ha med nytte som kontollparameter Undersøkelse på HIT-seminar (Mars 2016): Budsjettkontroll (73%) Tidkontroll (67%) Ihht kravspesifikasjon (40%) Nytte (28%) Produktivitet (27%) Produkteier-team med kun domenekompetanse Må også ha kompetanse innen områder som requirements engineering, arkitektur/utvikling, verifikasjon og validering, risikohåndtering, estimering og risikohåndtering