PERFORM et smidig prosjekt PERFORM. Flere usikkerhetsfaktorer vil påvirke PERFORM. 4 av SPKs endringsdrivere =>PERFORM. Kompetanse

Transkript

1 Pensjonering Medlemsdatahåndtering FTO/ NRS/GKR S Pay to Lønnsfiler $ g Lånehåndtering Yrkesskadeog gruppelivshåndtering Premieberegning Kapitalforvaltnin Kunderådgivning Statens Pensjonskasse er Norges største pensjonsforvalter PERFORM et smidig prosjekt Mette Gjertsen Prosjektleder Statens Pensjonskasse pensjon gunstige lån forsikring Ca kunder/arbeidsgivere (stat og kommune/fylkeskommune) Ca medlemmer Ca. 17 milliarder kroner i årlige utbetalinger Ca. 330 milliarder i statsgaranterte utbetalingsforpliktelser Kompetanse Statens Pensjonskasse en overraskelse i staten Ca. 350 faste medarbeidere i Statens Pensjonskasse IT-området Har 70 faste og 130 konsulenter - > øke med ytterligere 10 faste i år Satser på intern utvikling og vedlikehold av programvare Er fremtidsrettet satser på Java, OpenSource, SCRUM, FitNesse, SOA, confluence, Jira, Linux, hibernate, spring m.m. Har stor grad prosjektbasert organisering PERFORM Prosjektorganisasjon som skal sikre en kostnadseffektiv innføring av pensjonsreformen i Statens Pensjonskasse Varighet - 3 år Størrelse 150 årsverk fordelt på 190 hoder. Ca 70 medarbeidere fra SPK og 120 konsulenter Kontraktsform PS leverandører i konstruksjonsdel; SPK, Accenture og Steria Metodikk Scrum PERFORM Pensjoner for fremtiden /Jon Arve Bilde 3 4 av SPKs endringsdrivere =>PERFORM Arbeidsavklaringspenger Stortingsmelding nr. 9 ( ) En ny tidsbegrenset inntektssikring med antatt virkning fra mars 2010 Pensjonsreform Pensjonsprogram Flere usikkerhetsfaktorer vil påvirke PERFORM Usikkerhetsfaktorene er i hovedsak knyttet til implementering av nytt regelverk som følge av Pensjonsreformen, ettersom hoveddelen av reformen ikke er besluttet St.meld. Nr.5 ( ) Opptjening og uttak av alderspensjon i folketrygden NOU 2007:4 - Ny uførestønad og ny alderspensjon til uføre Rapport: Offentlig tjenestepensjon og AFP i offentlig sektor (mars 2009) Forlik i lønnsoppgjøret i offentlig sektor juni Selvbetjening SPK Interaktiv Betjening av pensjonister og medlemmer MP databasen Betjening av bedrifts-kunder MP applikasjon Eksterne grensesnitt Utdatert teknisk plattform (MP) SPKs pensjonssystem kjører på en teknisk plattform som er utdatert og SPK må tilpasse seg de endringer NAV gjør SPK utbetaler pensjoner gjennom og samordner våre ytelser med NAV. NAV leverer nye systemer i des og innfører nytt regelverk (pensjonsreform fra) sommeren Startet 2005 med kostnadsramme >1 MRD. Dette betyr at vi vil få endringer underveis i forhold til Funksjonalitet Teknisk løsning Estimater. Vi må bygge en endringsrobust løsning for arbeidsprosesser og IT-systemer Hvis forutsetningene endres vil det påvirke PERFORM under avvikling fra leverandør. 1

2 Metode besluttes desember 2007 Hva er smidig utvikling? Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Vi benytter iterative metode i pensjonsprosjektet, fordi: Økt forretningsinvolvering ettersom kravene endres underveis (pensjonsreform). Hyppige interne (ikke produksjon) leveranser Bedre kobling mellom IT og forretning Samarbeid hele tiden! Risiko reduserende Synliggjør tidlig Vanskeligste først That is, while there is value in the items on the right, we value the items on the left more. Sprinten omformer krav til kjørbar funksjonalitet Sermonier i Scrum Produktkø Prioritert Sprintkø 24t Utvikling Detaljplanlegging analyse og design Test -Hva er gjort? - Hva skal gjøres? - Hindere? - Gjenstående og Forbruk Visjon Etabler, estimer, ranger Produkt backlog 1 2 Demo Review Erfaring Retrospectiv 1 2 Demo Review Erfaring Retrospectiv KP dag1 Siste dag dag1 Siste dag Planlegge Dekomponert av teamet Løsningen - Demonstrasjon av ny funksjonalitet, som kan kjøres Sprint (2-4 uker) Sprint (2-4 uker) Kontinuerlig reestimering og detaljering av produkt backlog Produkt eier og teamet i fellesskap. Løfter blikket ser hva som ligger foran oss., hva er nå det? Standard Scrum-rolle. Ansvarlig for prioritering mellom ulike områder. Ansvarlig for Produkt-backlog (prioritert liste over krav o.a. arbeid som det er ønskelig at utviklingsteamene gjør). Overordnet for produktets suksess. Obligatorisk deltakelse i iterasjonsplanleggingsmøter (halv dag hver 3. uke), demo ved iterasjonsslutt (et par timer hver 3. uke). Frivillig deltakelse i daglige møter (et kvarter hver dag per team). Plassering i organisasjonen: Delprosjektleder Forretning En person fra kunden/på vegne av kunden som er for å etablere og prioritere produktkøen. Må kunne fagområdet. Velger hva som skal gjøres i neste sprint. Må kjenne IT-messige avhengigheter. Vurderer resultatet etter hver sprint sammen med andre interessenter. Må kunne vurdere delresultat i forhold fremtidig helhet. Må ha god kjennskap til scrum/smidig Er dette virkelig én person i større prosjekt? 2

3 i PERFORM Delprosjekt forretning nivå Leverandørnivå Team- Team 1 del 1 3 team Team 2 avsvarlig Team 5 totalt del 2 5 team Team 6 Team3 del 3 3 tea, Team 4 teamet leverandørnivå, forretningsarkitekt, funksjonell arkitekt, teknisk arkitekt Scrum Master Standard Scrum-rolle. Ansvarlig for å fjerne eller redusere konsekvens av hindringer. Når hindringsbacklogg er tom, trer ScrumMaster inn i rollen "Team" Ansvarlig for at teamet følger den metodikken de har blitt enige om. Ansvarlig for å kalle inn til alle standard Scrum-møter (iterasjonsplanleggingsmøter, daglige møter, demo, refleksjonsmøter) Obligatorisk deltaker på ovenstående møter. Plassering i organisasjonen: Delprosjekt Teknisk Team Standard Scrum-rolle. Ansvarlig for at teamet jobber sammen på en effektiv måte og at framdriften er så god som den kan være. Ansvarlig for å levere et best mulig produkt (designet, utviklet og testet) innenfor rammene av hver enkelt iterasjon og prosjektet som helhet. Ansvarlig for estimering. Obligatorisk deltakelse i alle standard Scrum-møter. Plassering i organisasjonen: Delprosjekt Arkitektur, delprosjekt Teknisk, delprosjekt Test (har mao. medlemmer fra alle disse delprosjektene slik at teamet har den nødvendige tverrfaglige kompetansen). Teamet - Perform - - Avklare med produkteier og arkitekter hvordan løsning skal fungere funksjonelt - Tester - Finner sammen med funksjonelt hvordan løsningen må testes. Utvikler testene gjennom testverktøy. - Utviklere - Utvikler løsningen og bygger automatiske tester - Teamarkitekt - Deltar i løsningsbeskrivelsesfasen foran oppstart av ny konstruksjon - Veileder utviklerne - Deltar i koordinering på tvers av teamene sammen med funksjonelt - Veldig aktiv i planlegging av iterasjon SPK-spesifikk rolle. Ikke nødvendig på små prosjekter, men kan være ønskelig på større prosjekter s forlengede arm med spisskompetanse innenfor et funksjonelt område. Ansvarlig for overordnede krav og avklaring overfor teamet på sitt funksjonsområde. Ansvarlig for prioritering innenfor sitt funksjonsområde. Obligatorisk deltakelse i iterasjonsplanleggingsmøter demo ved iterasjonsslutt daglige møter Plassering i organisasjonen: Delprosjekt Forretning Artefakter Kode (kjørende system) Hver iterasjon skal ende opp i testet, kjørbar, potensielt utgivbar kode. Det viktigste målet på framdrift blir hvor mye av dette som teamet eller teamene klarer å levere hver iterasjon Hindringsbacklog Hindringsbackloggen Scrummasterens verktøy for å følge opp hindringer. Når en hindring blir oppdaget i daglig møte eller på annet tidspunkt, legger scrummasteren inn hindringen i hindringsbackloggen. Hindringene i backloggen bør ha statuser, f.eks. Ikke påbegynt, Under arbeid og Ferdig, og kan gjerne være i form av en synlig tavle med gule lapper. Iterasjonsbacklog Teamets del av den utvalgte produkt-backloggen brytes ned i oppgaver av 0,5-3 dagsverks varighet. Disse oppgavene utgjør Teamets iterasjonsbacklog. Framdrift i teamets følges opp daglig i forhold til deres iterasjonsbacklog. 3

4 Samhandlere Forretning Eier Delsystemer Krav Overlevering Interne/eksterne brukere Samhandlere Forretning KPn KP2 KP1 Artefakter Produkt-backlog Det finnes kun én produkt-backlog per produkt. Produkt-backloggen er en prioritert liste over all funksjonalitet som er ønsket og alt annet arbeid som produkteier og andre ønsker inn i produktet. Alle kan legge til punkter i produkt-backloggen, men bare produkteier kan prioritere den. Estimering av produkt-backloggen er teamenes ansvar. Hver iterasjon blir en bit av produkt-backloggen valgt ut til å implementeres i iterasjonen, og denne blir da brutt ned i oppgaver som legges i iterasjonsbackloggen (se nedenfor). Ferdigstilte punkter blir flyttet ut av produkt-backloggen, alternativt til en ferdiglogg. Produkt-backloggen etableres tidlig i prosjektet og alle kjente krav til produktet på overordnet nivå skal legges inn der. En aktør og interessentliste kan være til hjelp for å identifisere alle krav til produktet, og brukerhistorier kan være et egnet format å beskrive kravene på. Det er viktig at produkt-backloggen blir vedlikeholdt videre i prosjektforløpet. bør bruke noe tid hver iterasjon sammen med e og noen fra teamene (gjerne med arkitekturkompetanse) til å se framover, finne nye krav og reprioritere. Prosjektledelse Scope Risk Time Integration Quality Communication Cost Human Resource Procurement Strategiske ledelsesprosesser Eierstyring ITO virksomhetsstyring Forretningsstrategi Gjennomføringsstrategi Arkitekturstrategi Gjennomføringsmodell II Feilhåndtering Endringshåndtering Utviklingsprosesser Leveranse Overordnede krav (CRV) og konsekvensanalyse Behovsanalyse Løsningsbeskrivelse Konstruksjon Godkjenning Produksjonssetting Godkjenning Behovsanalyse Løsningsbeskrivelse Konstruksjon Akseptansetest Produksjonssetting Driftsprøve (ITO ) Forretning-/linjeressurser Produktkøprosessen Arkitekter Utviklere Testressurser Gevinstrealisering Prosjektledelse Kommunikasjon Teknologi- og miljøforvaltning Støtteprosesser Risikoledelse Styring av suksessfaktorer Anskaffelser Dokumenthåndtering Ressursledelse Kvalitetsledelse Kostnadsledelse Tidsledelse Leveranseledere Gjennomføringsmodell PS2000 R1 R2 R3 R4 Delleveranser (Release) Tid PS2000 kontraktsstandard Særtrekk Definert gjennomføringsmodell, basert på iterative prosesser Regulerte forpliktelser for begge parter Integrert samarbeid tilrettelagt i gjennomføringsmodellen Erfaringer basert på dokumentert beste praksis innebygd Håndtering av usikkerhet tilrettelagt Motiverende elementer i form av incentivordninger tilrettelagt Rutiner for konfliktløsning ved bruk av uavhengig ekspert inkludert Behovsfase Godkjenningsog avslutningsfase Løsningsbeskrivelsesfase Detaljplanlegging / Analyse og design Testing Progresjon Iterativ konstruksjonsfase Utvikling Iterativ Trinn per Delleveransekonstruksjonsfase Detaljplanlegging / Analyse og design KPn KP2 KP1 Testing Utvikling Behovsanalysbeskrivelse og Løsnings- Prod.setting Godkjenning innføring Kontraktsinngåelse HMP 0 HMP 1 løsningsbeskrivelse HMP 2 Leveranse klar til godkjenning HMP 3 leveranse HMP 0 Kontraktsinngåelse HMP 1 løsningsbeskrivelse HMP 2 Leveranse klar til godkjenning HMP 3 leveranse 4

5 Scrum sprint mappet til PS2000 trinn Visjon, effektmål og gevinstønsker tydelige Behovsfase Sprint demo Demonstrerbare komponenter HMP 0 Kontraktsinngåelse Løsningsbes - krivelsesfase KPn KP2 HMP 1 løsnings - beskrivelse Produktkø Detaljplanlegging / Analyse og design KP1 Sprintkø Progresjon Iterativ konstruksjonsfase Testing Utvikling Sprint planlegging HMP 2 Leveranse klar til godkjenning Dekomponert sprintkø Godkjennings - og avslutningsfase HMP 3 leveranse - Hva er gjort? - Hva skal gjøres? - Hindre? - Brenndiagram og Forbruk Daglig Scrum Definisjon av ferdig Hva er et kontrollpunkt PS2000? Verifikasjon at man er ferdig i iterasjonen. Når er man ferdig? det er utviklet tilstrekkelige funksjonelle tester for punktet alle tilhørende utviklingsoppgaver er ferdige øvrige oppgaver knyttet til punktet er ferdigstilt dokumentasjon er utviklet i henhold til prosjektets krav, inkl krav SPK stiller til alle prosjekter funksjonelt har godkjent at punktet er ferdig punktet har passert kontrollpunkt Hva kontrollerer vi i PERFORM.. Demo Kodekvalitet Arkitekturretningslinjer Dokumentasjon Testkvalitet Fastpris prosjekter Bruksområder: Leveranser som kan spesifiseres veldig nøye Leveranse av standardiserte løsninger Fordeler og ulemper: Forutsigbar pris (men det kan løpe på endringer) Kan gi omfattende kontraktsadministrasjon Lite rom for erfaringsbaserte justeringer underveis Leverandøren vil snevre inn omfanget Leverandøren vil benytte billigst mulig ressurser Kunden vil få levert mest mulig innenfor fastprisen Løpende timer Bruksområder Leveranser som ikke kan spesifiseres detaljert Prosjekter med stor usikkerhet (eks. F&U) Konvertering, rapportutvikling Fordeler og ulemper Kan bli kostbart uten stram kostnadsstyring Kan gjennomføre erfaringsbaserte justeringer underveis Lite kontraktsadministrasjon og endringshåndtering Leverandøren vil selge flest mulig timer Målpris - en mellomvei PERFORM - Overordnet Bruksområder Systemutvikling basert på relativt godt spesifisert behovsanalyse Godt nok grunnlag for realistiske estimater Erkjennelse av at krav og prioriteringer kan endre seg underveis Fordeler og ulemper Relativ forutsigbarhet mht. kostnader Klare leveranseavtaler mht. omfang og kalendertid Rom for erfaringsbaserte justeringer i iterasjoner Støtter integrert samarbeidsmodell Felles incentiver om å levere kvalitet til avtalt tid og kostnad Finansdep. Ekstern kvalitetssikrer Fornyings- og Adm. dep. Adm. direktør Statens Pensjonskasse Styringsgruppe Prosjekteier Prosjektdirektør PERFORM FAD kvalitetssikrer 5

6 PERFORM Målpris - en mellomvei Delprosjekt arkitektur Delprosjekt test Prosjektdirektør Prosjektleder Delprosjekt Utvikling PL :SPK App. Ark. Team Funksjonell test PL: SPK PL:Steria Delprosjekt forretning PL :SPK LBF Team Aksepttest kriterier Regelverk Saksbehandlings system Forretning Miljøteam Godkjenningsprøve ITO Produksjons setting Bruksområder Systemutvikling basert på relativt godt spesifisert behovsanalyse Godt nok grunnlag for realistiske estimater Erkjennelse av at krav og prioriteringer kan endre seg underveis Fordeler og ulemper Relativ forutsigbarhet mht. kostnader Klare leveranseavtaler mht. omfang og kalendertid Rom for erfaringsbaserte justeringer i iterasjoner Støtter integrert samarbeidsmodell Felles incentiver om å levere kvalitet til avtalt tid og kostnad PL :Accenture Hvordan komme frem til kostnad? Erfaringer fra oppstartsfasen Startet opp med timeestimat på overordnede arbeidspakker. Benyttet erfaringstall fra tidligere prosjektet. Fordel: Får et ståsted idet man starter Ulempe: Vanskelig å få inn læring uten større reestimeringsjobb Ulempe: Må gå svært detaljert til verks for å kunne bruke disse estimatene direkte Hvordan komme frem til kostnad? nå Masterplan med brukerhistorier på overordnet nivå som dekker alt som skal gjøre i prosjektet. Består av ca 300 overordnede brukerhistorier. Benyttet planning poker for å fastsette historienes relative forhold. Lage Gui for person er 2 => at lage GUI for pensjonsberegning er 20 altså 10 ganger større. Hvordan komme frem til kostnad? nå Lærer fart underveis Hvor mange timer brukte prosjektet pr. relativ verdi i første release, i andre release osv. Får da en fart pr relativ verdi som inneholder læring. Brenndiagram Kan alle forstå et brenndiagram? Ut fra dette kan man fortløpende lage oppdaterte prognoser. Nåværende fart = (faktisk forbrukt denne release) / (Sum relative verdier levert denne release) Gjenstående = Sum gjenstående relative verdier * nåværende fart 6

7 Risikostyring I scrum styres risiko på flere nivå : Prioritering av oppgaver i produktkø ROI Risiko for prosjektet Scrum masteren identifisering og fjerning av hindringer for farten i teamet Risikostyring I større prosjekter Samme som på foregående side har vi sett nødvendigheten av utvidet risikostyring fordi: det er suboptimalt dersom alle team skal bruke tid på å fjerne samme hindring mye flere risiki/hindringer som går på tvers av alle team, og som eksisterer nettopp fordi man har mange team. Kanskje nok i mindre prosjekter med 1-2 team har vi risikostyring på delprosjekt- og prosjektnivå i tillegg 7