Kvalitet i smidige prosjekt Erfaringer PERFORM prosjektet i SPK Mette Gjertsen Prosjektleder Statens Pensjonskasse mette.gjertsen@spk.no
Agenda 1. Statens pensjonskasse 2. Kort om prosjektet 3. Personer og samspill 4. Programvare som virker 5. Samarbeid med kunden 6. Reagere på endring
Dette er Statens pensjonskasse En av Norges beste pensjonsordninger Markedets beste boliglån? Forsikring fra dag én Tjenestepensjon for 950 000 medlemmer 310 000 yrkesaktive medlemmer (inkl. 23 000 med delvis pensjon), 432 000 arbeidstakere med opptjente rettigheter og 231 000 pensjonister Pensjonene er fordelt på 138 000 alderspensjonister, 58 000 uførepensjonister, 47 000 som mottar ektefellepensjon og 2 000 barn som mottar barnepensjon Gunstig boliglån til stadig flere Vi har 36 800 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 31.12.2009
Med en sterk involvering og forpliktelse fra SPKs toppledelse! PERFORM er SPKs største og mest forretningskritiske prosjekt noensinne Varighet 2008-2011 Størrelse Ca 750.000 prosjekttimer 100-180 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
PERFORM er etablert for å møte fire svært kritiske forretningsmessige drivere 1. Arbeidsavklaringspenger Ikrafttredelse 01.03.10 Samordne midlertidige ytelser fra NAV 2. Pensjonsreform Ikrafttredelse 01.01.11 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. 2008 og innfører nytt regelverk (pensjonsreform fra) sommeren 2009 2009 2008 NAV integrasjon Forberede full prosjektoppbygging NAV integrasjon Forberedelse nytt saksbehandlersystem 2011 2010 Effektivisering og optimalisering av nytt Nytt regelverk saksbehandlersystem Videre på nytt saksbehandlersystem
Hvilke gevinster gir smidig utvikling? 1) Raskere i produksjon 2) Bygger det kunden trenger
Prosjektledelse Scope Risk Cost Time Integration Human Resource Quality Communication Procurement
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
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
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
Teamet - Perform Teamarkitekt Funksjonelt ansvarlig Seniorutviklere Juniorutviklere Scrum master Tester Til sammen: 7-9 ressurser
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
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
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
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
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
Kontinuerlig produksjonssetting gir virkelig kvalitet - Mellom 30 000 90 000 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
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
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
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
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
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
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
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
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
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
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
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
Teamet - Perform Teamarkitekt Funksjonelt ansvarlig Seniorutviklere Juniorutviklere Scrum master Tester Til sammen: 7-9 ressurser
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
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
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 1.1.2011 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 01.01.2012 Saksbehandlingstiden skal ikke øke utover dagens mål som følge av Pensjonsreformen
Behovene endrer seg underveis! Ikke påbegynt Under arbeid Til test Ferdig Funksjonalitet Pensjonsreform 1.1-2011 Overordnet produktkø Initiell produktkø Dynamisk produktkø Funksjonalitet rest sakssystem Funksjonalitet effektivisering
Vent med detaljering på det lengst unna i tid. Opprinnelig kø Levert 2010 Funksjonalitet Pensjonsreform 1.1-2011 Funksjonalitet rest sakssystem Nye og bedre effektiviserings tiltak i SPK ut fra 2 år mer erfaring Ny kø 2011 2012? Funksjonalitet effektivisering
Hvilke gevinster gir smidig utvikling? 1) Raskere i produksjon 2) Bygger det kunden trenger 3) Finner feilene tidligere