Kvalitet i smidige prosjekt Erfaringer PERFORM prosjektet i SPK. Mette Gjertsen Prosjektleder Statens Pensjonskasse mette.gjertsen@spk.

Transkript

1 Kvalitet i smidige prosjekt Erfaringer PERFORM prosjektet i SPK Mette Gjertsen Prosjektleder Statens Pensjonskasse mette.gjertsen@spk.no

2 Agenda 1. Statens pensjonskasse 2. Kort om prosjektet 3. Personer og samspill 4. Programvare som virker 5. Samarbeid med kunden 6. Reagere på endring

3 Dette er Statens pensjonskasse En av Norges beste pensjonsordninger Markedets beste boliglån? Forsikring fra dag én Tjenestepensjon for medlemmer yrkesaktive medlemmer (inkl med delvis pensjon), arbeidstakere med opptjente rettigheter og pensjonister Pensjonene er fordelt på alderspensjonister, uførepensjonister, som mottar ektefellepensjon og barn som mottar barnepensjon Gunstig boliglån til stadig flere Vi har lånekunder som utgjør en låneportefølje på 27 milliarder kroner Forsikringsordninger Gruppelivsforsikring: ved død utbetales et engangsbeløp til etterlatte Yrkesskadeforsikring Bilansvarssaker for politiet og forsvaret og noen særordninger for forsvaret Vi forvalter pensjonsordningen for alle apotekene Fondsmidlene var på 4,7 milliarder per

4 Med en sterk involvering og forpliktelse fra SPKs toppledelse! PERFORM er SPKs største og mest forretningskritiske prosjekt noensinne Varighet Størrelse Ca prosjekttimer personer, maks i 2010 Ca 80 interne ressurser fra forretningsområder og IT Til sammen 12 scrumteam 2 rammeavtaleleverandører som hovedleverandør Ivaretar til sammen 6 scrumteam SPK også leverandør Ivaretar til sammen 6 scrumteam Tre rammeavtale leverandører på kundesiden i sentrale roller Alle på en flate

5 PERFORM er etablert for å møte fire svært kritiske forretningsmessige drivere 1. Arbeidsavklaringspenger Ikrafttredelse Samordne midlertidige ytelser fra NAV 2. Pensjonsreform Ikrafttredelse Nye regler for offentlig tjenestepensjon 3. Utdatert teknisk plattform SPKs pensjonssystem kjører på en teknisk plattform som er utdatert 4. NAV Pensjonsprogram NAV leverer nye systemer i des og innfører nytt regelverk (pensjonsreform fra) sommeren NAV integrasjon Forberede full prosjektoppbygging NAV integrasjon Forberedelse nytt saksbehandlersystem Effektivisering og optimalisering av nytt Nytt regelverk saksbehandlersystem Videre på nytt saksbehandlersystem

6 Hvilke gevinster gir smidig utvikling? 1) Raskere i produksjon 2) Bygger det kunden trenger

7 Prosjektledelse Scope Risk Cost Time Integration Human Resource Quality Communication Procurement

8 Manifestet for smidig programvareutvikling Vi finner bedre måter å utvikle programvare på ved å gjøre det selv og ved å hjelpe andre med det. Gjennom dette arbeidet har vi lært oss å verdsette følgende: Personer og samspill fremfor prosesser og verktøy Programvare som virker fremfor omfattende dokumentasjon Samarbeid med kunden fremfor kontraktsforhandlinger Å reagere på endringer fremfor å følge en plan Dette vil si: Selv om punktene som står til høyre har verdi, så verdsetter vi punktene til venstre enda høyere. Forfattet av : Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

9 Manifestet for smidig programvareutvikling Vi finner bedre måter å utvikle programvare på ved å gjøre det selv og ved å hjelpe andre med det. Gjennom dette arbeidet har vi lært oss å verdsette følgende: Personer og samspill fremfor prosesser og verktøy Programvare som virker fremfor omfattende dokumentasjon Samarbeid med kunden fremfor kontraktsforhandlinger Å reagere på endringer fremfor å følge en plan Dette vil si: Selv om punktene som står til høyre har verdi, så verdsetter vi punktene til venstre enda høyere. Forfattet av : Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

10 PERFORM Prosjektdirektør Prosjektleder Produksjons setting Innføring ITO Bestiller Leverandør Delprosjekt forretning PL :SPK Delprosjekt Utvikling PL :SPK Delprosjekt arkitektur LBF Team App. Ark. Team Miljøteam Delprosjekt test Aksepttest kriterier Funksjonell test Godkjenningsprøve Regelverk PL: SPK Saksbehandlings system PL:Steria Innføring Forretning PL :Accenture

11 Teamet - Perform Teamarkitekt Funksjonelt ansvarlig Seniorutviklere Juniorutviklere Scrum master Tester Til sammen: 7-9 ressurser

12 Muntlig rapportering i prosjektet Prosjektledermøtet PL perform, PD perform, DPL utvikling, DPL forretning, DPL test, DPL leveranse, DPL Arkitektur Metascrum (DPL utvikling, PL leverandør, PL Perform, DPL Arkitektur, DPL Forretning, DPL test) Statusmøte DP forretning Dagligmøte DP test Dagligmøte DP arkitektur Scrum av scrum PL leverandør Scrummastre Testleder lev. Scrum av scrum PL leverandør Scrummastre Testleder lev. Dagligsscrum Scrummaster teamet Dagligsscrum Scrummaster teamet Dagligsscrum Scrummaster teamet Dagligsscrum Scrummaster teamet

13 Manifestet for smidig programvareutvikling Vi finner bedre måter å utvikle programvare på ved å gjøre det selv og ved å hjelpe andre med det. Gjennom dette arbeidet har vi lært oss å verdsette følgende: Personer og samspill fremfor prosesser og verktøy Programvare som virker fremfor omfattende dokumentasjon Samarbeid med kunden fremfor kontraktsforhandlinger Å reagere på endringer fremfor å følge en plan Dette vil si: Selv om punktene som står til høyre har verdi, så verdsetter vi punktene til venstre enda høyere. Forfattet av : Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

14 Leveransestrategi i PERFORM Behovsfase Godkjenningsog avslutningsfase Løsningsbeskrivelsesfase Detaljplanlegging / KPn Analyse og design KP2 KP1 Progresjon Iterativ konstruksjonsfase Testing Utvikling Kjennetegn for SPKs regime for leveransestyrt produksjonssetting: HMP 0 Kontraktsinngåelse HMP 1 Godkjent løsningsbeskrivelse HMP 2 Leveranse klar til godkjenning HMP 3 Godkjent leveranse - 3 hovedleveranser i året - Krav om felles akseptansetest før hver hovedleveranse - Krav om overleveringsnotat til ITO - Krav om forvaltningsgaranti ca 3 uker etter en leveranse Utover dette : Mulighet for delleveranser Mulighet for produksjonsfix er Målsetning at PERFORM skal levere til produksjon i hovedleveransene

15 Prosjektgjennomføringen Vi jobber etter smidig metodikk i prosjektet SCRUM Utviklingsprosessen Godkjenning Behovsanalyse Løsningsbeskrivelse Konstruksjon Akseptansetest Produksjonssetting Driftsprøve (Eies av IT) 3 årlige leveranser Produktkøprosessen Mellom 5 og 7 iterasjoner DP forretning er kravstiller og DP utvikling leverer iht krav DP arkitektur og test jobber på tvers DP utvikling består av 3 hovedteam (leverandører) med 12 team Overordnet design og spesifikasjon gjøres i fellesskap for deretter å splittes i tre Produktkøen danner grunnlaget for utvikling Oppdragsavtaler opprettes med alle tre leverandører Målpris for konstruksjonsfasen Medgått tid på øvrige oppgaver Arkitektur defineres/utvikles både i forkant av og gjennom iterasjonene Vi bygger iterativt Starter med detaljert planlegging og inngåelse av en forpliktet kontrakt pr team Videre aktiviteter er detaljert design/ analyse, utvikling og test Avsluttes med et kontrollpunkt Godkjenningsprøve gjennomføres før overlevering

16 Kontinuerlig i konstruksjon -funksjonell test og integrasjonstest er del av konstruksjon April 09 September 09 Desember 09 April 10 Septem Konstruksjon Godkjenning Produksjon Forvaltning Behov Løsning Konstruksjon Godkjenning ProduksjonForvaltning Behov Løsning Konstruksjon Godkjenning Produksjon Forvaltning Behov Løsning Konstruksjon Godkjenning Produksjon Forvaltning Behov Løsning Konstruksjon Godkjenning Produksjon Behov Løsning Konstruksjon

17 Kontinuerlig produksjonssetting gir virkelig kvalitet - Mellom prosjekttimer - Godkjenningsprøve med varighet 4-8 uker - Gradvis utrulling av ny funksjonalitet - Gradvis utrulling til nye brukere - Gradvis migrering fra SPK-MP (Klient-tjener basert C løsning) til PUMA (java og Flex basert tjenesteorientert løsning) - 2 faste produksjonsfix er planlagt fra PERFORM etter en hovedleveranse - Produksjonssettes i løpet av en helg (For enkelte av leveransene vurderes nedetid på 1 dag i tillegg) - Rettet opplæring av brukere - Superbrukere og funksjonelt ansvarlige fra PERFORM tilstede i forretning første uken etter produksjonssetting. - Inneholder 5-7 iterasjoner PERFORM leverer løsning i produksjon hver hovedleveranse

18 Definisjon av ferdig DOD Definition of done sakset fra SPKs smidighåndbok 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 ansvarlig har godkjent at punktet er ferdig punktet har passert kontrollpunkt

19 Hvorfor kontrollpunkt? Til for besvarelse av et spørsmål : Er koden produksjonssettbar? Hva brukes resultatet av kontrollpunktet til? Forteller hvilke produktkøelementer som er ferdig og klar til godkjenningsprøve. Kompetanseoverføring. Koden kjører i eget miljø som kunden/brukere kan prøve løsningen i. Merkantil milepæl i PS2000

20 Hva kontrollerer vi i kontrollpunktet.. Demo leverer man det som funksjonelt sett er bestilt? Har dette den funksjonelle kvaliteten som bestilt? Kodekvalitet Er koden forvaltbar Følger koden kodestandarder Utvikler kodekvaliteten seg korrekt Arkitekturretningslinjer Følger man standard for database Følger man standard for bruk av SPRING Følger man standard for oppdeling av moduler

21 Hva kontrollerer vi i kontrollpunktet.. Dokumentasjon Er systemdokumentasjon ok Er driftsdokumentasjon etablert Er brukerdokumentasjon laget Er leveransedokumentasjon laget Følger man retningslinjer for overlevering Testkvalitet Er testdekning god nok Er det nok negative tester Har man flyttet koden til systemintegrasjonstestmiljø Har man testet på teammiljø Har man sammenlignet PUMA <=> MP

22 Testmodell/strategi i SPK/Perform Enhetstest (ET) Integrasjonstest (IT) Kontinuerlig bygg og integrasjonstest på felles kodebase Systemtest (ST) Systemintegrasjonstest (SIT) Godkjenningsprøve (GP) Akseptansetest (AT) Produksjonstest (PT) GP Perform Godkjenningsprøve DP-test ET/IT ST/SIT Prosjekt Perform Konstruksjon DP-Utvikling AT SPKs Testsenter Regresjonstest PT Leveranseapparatet SPK DP leveranse

23 Systemintegrasjonstest - SIT Erfaringer fra SIT Finner feil tidligere og får rettet dem i konstruksjon Kan gjøre gjennomløpende tester Oppdager miljø- og systemrelaterte utfordringer tidlig Sluttbrukere kan teste applikasjonen

24 Godkjenningskriterier til test i en iterasjon 1) Inneholder produktkøelementet(brukerhistorien) som er løst i QC. 2) Inneholder funksjonell forklaring (link til systemdokumentasjon) på produktkønivået i QC 3) Inneholder testbetingelser i QC 4) Rapportert testdekning i QC og Clover (Enhetstestdekning) 5) Testbetingelser er godkjent av funksjonelt ansvarlig i QC 6) Alle testbetingelser er angitt som testet i QC 7) Manuelle tester er utført (QC testlab) 8) Negative tester skal lages hvis mulig ( begrunnelse på hvorfor utelatt) 9) Test i SIT 10)Struktur og navnestander for QC er fulgt

25 Systemtest og systemintegrasjonstest er del av konstruksjon Krever automatiserte tester PERFORM benytter fitnesse Smart bruk av fitnesse er vanskelig Krever teamtestmiljø Teamene tester sin kode, riktignok med all kode fra prosjektet inne. Krever systemintegrasjonstestmiljø Alle 12 team samler alt man har gjort i siste sprint og det gjennomføres tester på tvers av system Krever koordinering av test internt i konstruksjon

26 Manifestet for smidig programvareutvikling Vi finner bedre måter å utvikle programvare på ved å gjøre det selv og ved å hjelpe andre med det. Gjennom dette arbeidet har vi lært oss å verdsette følgende: Personer og samspill fremfor prosesser og verktøy Programvare som virker fremfor omfattende dokumentasjon Samarbeid med kunden fremfor kontraktsforhandlinger Å reagere på endringer fremfor å følge en plan Dette vil si: Selv om punktene som står til høyre har verdi, så verdsetter vi punktene til venstre enda høyere. Forfattet av : Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

27 PERFORM Delprosjekt forretning (ca 30 årsverk SPK) Delprosjektleder Forretning Kommunikasjon Teamleder Behovsfase 1 4 Åv Teamleder Behovsfase 2 4 ÅV Produkteier SPK Produkteier Accenture Funksjonelle Arkitekter 3 interne og 1 pr leverandør Innføring og Opplæring 4 ÅV Produkteier Steria Funksjonelt ansvarlige og testere konstruksjon 6,5 ÅV Funksjonelle testere DP Test 3,5 ÅV

28 Produkteier i PERFORM Delprosjekt forretning Produkteier totalt Leverandørnivå Produkteier del 1 3 team Produkteier del 2 5 team Produkteier del 3 3 tea, Teamnivå Funksjonelt ansvarlig Team 1 Funksjonelt ansvarlig Team 2 Funksjonelt avsvarlig Team 5 Funksjonelt ansvarlig Team 6 Funksjonelt ansvarlig Team3 Funksjonelt ansvarlig Team 4 Produkteierteamet leverandørnivå Produkteier, forretningsarkitekt, funksjonell arkitekt, teknisk arkitekt

29 Teamet - Perform Teamarkitekt Funksjonelt ansvarlig Seniorutviklere Juniorutviklere Scrum master Tester Til sammen: 7-9 ressurser

30 Suksessfaktorer Produkteier og forretningsressurser allokeres i tilstrekkelig mengde Viktig at linjeledelse spiller på samme lag, omforent eierskap av produktkøen og prioriteringer Fokus på å få ut forventet forretningsverdi Samhandling Internt mellom produkteiere Mellom produkteier og linjeledelse Tett oppfølging av leverandører, produkteier bestemmer pri Kvalitetssikring av alt levert arbeid Meget god erfaring av Jira som verktøy Ledelsen/organisasjonen forstår behovet av tung intern kompetanse i prosjektet Forventingsstyring i forhold til leveranse Perform vs linjeorganisasjon VÅRE MÅL, ikke mitt og ditt DP Forretning et team, et mål

31 Manifestet for smidig programvareutvikling Vi finner bedre måter å utvikle programvare på ved å gjøre det selv og ved å hjelpe andre med det. Gjennom dette arbeidet har vi lært oss å verdsette følgende: Personer og samspill fremfor prosesser og verktøy Programvare som virker fremfor omfattende dokumentasjon Samarbeid med kunden fremfor kontraktsforhandlinger Å reagere på endringer fremfor å følge en plan Dette vil si: Selv om punktene som står til høyre har verdi, så verdsetter vi punktene til venstre enda høyere. Forfattet av : Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

32 Målene til prosjektet gir den løpende prioriteringen Utbetale rett pensjon til rett tid (i hele prosjektperioden og etter leveranse) Våre kunder skal få et forutsigbart produkt og en forutsigbar og korrekt premie under og etter implementering av Pensjonsreformen 85% av SPKs pensjonsytelser skal behandles maskinelt etter innføring av nytt regeverk pr PERFORM skal levere et fleksibelt saksbehandlersystem, hvor endringer raskt lar seg implementere SPK skal tilrettelegge for god informasjon om det nye regelverket til våre kunder og medlemmer SPK skal ha etablert en informasjons- og simuleringsløsning for nytt regelverk i løpet av 2010 Minimum 95 % av SPKs pensjonsytelser skal behandles maskinelt etter innføring av nytt regelverk pr Saksbehandlingstiden skal ikke øke utover dagens mål som følge av Pensjonsreformen

33 Behovene endrer seg underveis! Ikke påbegynt Under arbeid Til test Ferdig Funksjonalitet Pensjonsreform Overordnet produktkø Initiell produktkø Dynamisk produktkø Funksjonalitet rest sakssystem Funksjonalitet effektivisering

34 Vent med detaljering på det lengst unna i tid. Opprinnelig kø Levert 2010 Funksjonalitet Pensjonsreform Funksjonalitet rest sakssystem Nye og bedre effektiviserings tiltak i SPK ut fra 2 år mer erfaring Ny kø ? Funksjonalitet effektivisering

35 Hvilke gevinster gir smidig utvikling? 1) Raskere i produksjon 2) Bygger det kunden trenger 3) Finner feilene tidligere