spor 2 kontinuerlig forbedring av testprosessen
TRANSCRIPT
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