Kontinuerlig forbedring av testprosessen Erfaringer fra prosjekt Perform

Steria fagdag 2012

13/06/2012

Kjetil Røe, PMP

Anders Vindvad, PMP

Hvem er vi?

13.06.2012 2

Kjetil Røe Sterias Prosjektleder

i Perform

Siv.ing

PMP, ScrumMaster

Anders Vindvad ScrumMaster i SPK-team

i Perform

Cand.scient

PMP, ScrumMaster

Agenda

13/06/2012 3

Dette skal du få høre om

Prosjekt Perform

Test i prosjekt Perform

Problemløsning

Forbedringer

Erfaringer

Oppsummering

www.steria.com

13/06/2012

Prosjekt Perform

Statens Pensjonskasse 2008 - 2011

780.000 prosjekttimer

180 personer, ca 80 fra SPK

3 leveranser årlig

3 ukers iterasjoner

2 hovedleverandører fra 2009, SPK var både kunde og leverandør

2008

NAV integrasjon

Forberede full prosjektoppbygging

2009

NAV integrasjon

Forberedelse nytt saksbehandlersystem

2010

Nytt regelverk

Videre på nytt saksbehandlersystem

2011

Effektivisering og optimalisering av nytt saksbehandlersystem

Hvorfor ble prosjekt Perform etablert?

1. Arbeidsavklaringspenger Ikrafttredelse 01.03.2010

Samordne midlertidige ytelser fra NAV

2. Pensjonsreform Ikrafttredelse 01.01.2011

Nye regler for offentlig tjenestepensjon

3. Utdatert teknisk plattform SPKs pensjonssystem kjører på en teknisk

plattform som er utdatert

4. NAV Pensjonsprogram NAV utvikler nye IKT-system

– SPK må samordne seg med NAV

4 kritiske forretningsmessige drivere

13.06.2012 6

Hvorfor smidig gjennomføring?

SPK skulle i årene 2008 - 2011

Bytte ut kjernesystemet bit for bit

Bytte til et ukjent regelverk i fart innen fristen

Produsere pensjoner i linja på gammelt og nytt

regelverk med riktig kvalitet

SPK valgte en smidig gjennomføringsmodell med Scrum og PS2000 for å kunne

Spesifisere, bygge og kvalitetssikre løsningen litt og litt

Justere seg inn mot et bevegelig mål under vegs

Kunne verifisere riktig kvalitet under vegs i prosjektet

Ekstern risikovurdering

13/06/2012 7

Fra Metier mars 2010

Risikoanalyse fra Perform

13/06/2012 8

I tidlig fase var dette en risikosport

Øyeblikksbilde fra

tidlig fase av Perform

Høy sannsynlighet

Høy konsekvens

Takk til adm. dir.

Finn Melbø i SPK

PL: SPK

PL:Steria

PL :Accenture

Perform organisering

Prosjektleder

Delprosjekt arkitektur

Delprosjekt test

Delprosjekt forretning PL :SPK

Prosjektdirektør

Innføring

Delprosjekt Utvikling PL :SPK

Regelverk

Produkt-eiere

Innføring Drift

Arkitektur Team

Miljø Team

Akseptansekriterier

Funksjonell test

Godkjennings-prøve

Produksjonssetting

Innføring Linje

Bestiller Leverandør

LBF Team

En måte å se prosjektet på

Gjennomføringsplan

• 3 releaser årlig i 3(4) år -> Over til forvaltning

• Er i en konstruksjonsiterasjon året rundt

• Jobber med 2 til 3 releaser i parallell -> Hektiske perioder

Release

3 releaser pr år

www.steria.com

13/06/2012

Test i Perform

Hvem tester hva

Testprosessen

Testing i iterasjoner

Testing og ansvar

Kontrollpunkter

Enhetstest

Integrasjonstest –

Kontinuerlig integrasjon

Funksjonell systemtest

Funksjonell Integrasjonstest

Kontrollpunkt

Godkjenningsprøve

Akseptansetest

Produksjonstest

Hvem tester hva i Perform

Leverandør

DP Test

Linje (funksjonell/IT)

Akseptansekriterier

pr brukerhistorie

Iterasjon n - 1 Iterasjon n Iterasjon n + 1

Kjør System

Integrasjonstester

Testprosessen i utviklingsteamene

Lag og kjør

enhets- og

integrasjonstester

Definer og

forfin

funksjonelle

testbetingelser

Lag og kjør

funksjonelle

systemtester

Testing i iterasjoner

JUnit-tester

Utviklers test, enhetstest av java-klasser

Kan også være integrasjonstester

Compile-time ved hver bygg av modulen på byggserver

FlexUnit-tester

Testing av brukergrensesnittet

Compile-time

Fitnesse-tester

Funksjonelle tester

Kan være integrasonstester

Samarbeid mellom utvikler og funksjonell/tester

Kjøres automatisk en gang i døgnet og gir rapport via mail

Manuell-testing

Manuelle kjørebeskrivelser lagret i Quality Center

Lages og testes av tester på teamet

13/06/2012

Scrum team

Krav

A&D

Kode

Test

Utrulling

Regresjonstestmiljø

Krav

A&D

Kode

Test

Utrulling

Regresjonstestmiljø

Krav

A&D

Kode

Test

Utrulling

Akseptansetestmiljø

Krav

A&D

Kode

Test

Utrulling

Godkjenningsmiljø

Iterasjon 1 Iterasjon 2 Iterasjon N - Godkjenning Akseptansetest

PERFORM Linjen

Teamansvar Teamansvar Teamansvar

DP-Test ansvar

Hvert team tester sin funksjonalitet i hver iterasjon

Det er et kontrollpunkt etter hver iterasjon

DP-Test tester leveransen som en helhet

Linjen mottar prosjektet som et ”vanlig”prosjekt

13/06/2012

Testing og ansvar

Kontrollpunkt pr iterasjon

Demo – vise frem hva som er gjort! Teamet demonstrerer alt som er nytt

Delprosjekt forretning tester levert funksjonalitet i iterasjonen

Testkvalitet Har leverandøren kjørt og passert testene?

Er test gjennomført i henhold til retningslinjene?

Kodekvalitet - inspeksjon av koden

Arkitekturretningslinjer – forholder man seg til disse?

Dokumentasjon Er systemdokumentasjon ok

Er driftsdokumentasjon etablert

Er brukerdokumentasjon laget

Er leveransedokumentasjon laget

Hver 3. uke godkjennes nye brukerhistorier

Ikke godkjente brukerhistorier går tilbake til teamet til «ompuss»

www.steria.com

13/06/2012

Problemløsning

«Bitene henger ikke sammen»

Team og leverandører hadde testet og fått godkjent sine komponenter

under vegs.

I Godkjenningsprøven desember 2009 ble det tydelig at «bitene» ikke hang

godt nok sammen.

13/06/2012

Avhengigheter

Flere tiltak ble iverksatt

«Avhengighetsmøte» hver iterasjon for at alle team

skulle bli bevisst avhengigheter og se hverandre i hvitøyet

Påbud om å kjøre Demo i felles miljø

Påbud om å kjøre Integrasjonstester i felles miljø

Ende til ende tester i løpet av konstruksjonsfasen

Kunden avskaffet dagbotsanksjoner

Greit nok, men ikke helt sånn vi hadde tenkt…

Funksjonalitet fra en iterasjon pleide

å virke, men ofte ikke 100%

slik kunden hadde tenkt

Vi slet med å få spesifisert

kravene tydelig nok

«Jeg vet det når jeg ser det»-

syndromet

13/06/2012

Avhengigheter

Vi innførte

«Minidemo» – En halvformell demo litt etter halvvegs i en iterasjon

Var det «sånn» dere hadde tenkt? Nesten, bittelitt mer «slik»…

Forberedende møte før hver iterasjon

Lage tydelige akseptansekriterier for brukerhistoriene før iterasjonen

Kunden tester under vegs i iterasjoner – kan rette feil/misforståelser innenfor

iterasjonen i stedet for etterpå

Hva skal vi egentlig lage nå?

Utfordring: For lite gjennomtenkte og bearbeidede tanker fra

løsningsbeskrivelse.

Når tanker om ny funksjonalitet kommer for brått på teamene blir det vanskelig

å levere riktig og effektivt

Vanskelig å implementere og teste noe som er vagt.

13/06/2012

Jobbing med produktkøen hele tida

Tiltak

Løpende løsningsbeskrivelse. Jobbe med produktkø hele tiden for å få med den ferskeste informasjonen.

Involvere teamene i løsningsbeskrivelse og estimering. Det hjelper lite om noen andre vet hva som skal lages.

Skrive nødvendige og tilstrekkelige akseptansebetingelser for hver brukerhistorie.

www.steria.com

13/06/2012

Forbedringer

Når feilene flyr rundt i lokalet …

Utfordring: Effektiv fordeling av feil i godkjenningsperioden

Prinsipp: Teamet som har laget feilen retter feilen

Daglig Bug Board for alle 3 leverandører

Analyse og feilretting

13/06/2012

Innfør Bug Board

Vi vil ha god kvalitet…

Utfordring: Sikre god kvalitet på tvers av leverandører og team

Felles kontrollpunkt for alle leverandører

Kodekvalitet

Testkvalitet

Dokumentasjon

13/06/2012

Innfør Kontrollpunkt

Når skal vi teste…

Utfordring: Levere gjennomtestet funksjonalitet med lite feil i hver release

Teste tidlig på gjennomgående funksjonalitet

Teste kontinuerlig innenfor samme release

Prioritere å rette feil framfor ny funksjonalitet

Test grundig nok. Slurv kommer i retur på et tidspunkt som passer dårligere

13/06/2012

Test tidlig og kontinuerlig

www.steria.com

13/06/2012

Erfaringer

Vær smidig -> Ta læring og fjern hindringer

Smidige prosjekter har mange læringspunkter

Hvis noe ikke virker …

Gi det en sjanse til

Hvis det fortsatt ikke virker

Fjern det eller forandre på det!

13/06/2012

Viktig å tilpasse seg virkeligheten

Jobbe sammen

Samarbeid innad i team må fungere

Samarbeid mellom team må fungere

Samarbeid mellom leverandører må fungere

Min leveranse har ingen verdi før den virker korrekt sammen med resten

13/06/2012 27

Vi er alle i samme båt

Gjensidig avhengighet

Gjør personer /team/miljøer gjensidig avhengige av hverandre

Fjern sanksjoner og mekanismer som motvirker samarbeid

Bruk gulrot og incentiver i stedet for pisk og sanksjoner

13/06/2012

Jobb for samarbeid

www.steria.com

13/06/2012

Hvordan gikk det til slutt?

Oppsummering

Prosjektet leverte alle planlagte releaser fra høsten 2008 til februar 2012

En release ble utsatt med en måned

En release ble redusert i omfang

Alle andre releaser med riktig tid og scope

SPK klarte ved hjelp av Perform å saksbehandle Pensjonsreformen fra høsten

2010

Dette er det klart største prosjektet til SPK og innføringen har gått mye bedre

enn ved forrige innføring av kjernesystem

SPK har fått en ny plattform og et nytt, framtidsrettet saksbehandlingssystem

13/06/2012

Hvordan gikk det med Perform?

Testprosessen og tilpasningene som ble gjort må ha vært bra