HYPPIGE LEVERANSER HVORDAN KOMMER SPK DIT? Ved Mette Gjertsen Statens pensjonskasse

Størrelse: px

Begynne med side:

Download "HYPPIGE LEVERANSER HVORDAN KOMMER SPK DIT? Ved Mette Gjertsen Statens pensjonskasse mette.gjertsen@spk.no"

Anna Nygaard
8 år siden
Visninger:

1 HYPPIGE LEVERANSER HVORDAN KOMMER SPK DIT? Ved Mette Gjertsen Statens pensjonskasse

2 Fra SPKs strategi IT-tjenestene for kjerneprosessene i SPK er overordnet ansett å være gode og stabile. Det er etablert et regime rundt styring av IT-tjenestene for kjerneprosessene og etter hvert også for stabs-/støtteprosessene, med god balanse mellom forretningsmessig og teknologisk fokus. På grunn av regelverket er det i vesentlig grad skreddersøm og egenutviklede ITløsninger innenfor kjerneprosessene, med bruk av hyllevarekomponenter og offentlige felleskomponenter der hvor dette er hensiktsmessig. Delmål (Stabilt, Kostnadseffektivt, Fremtidsrettet) - SPK skal ha sikre, stabile og tilgjengelige IT-tjenester iht SLA (Service Level Agreement) med en bevisst og god balanse mellom kost og nytte - SPK skal ha en kostnadseffektiv drift, forvaltning og videreutvikling av ITtjenestene - SPK skal ha fleksible og fremtidsrettede ITløsninger som muliggjør kontinuerlig forbedring og endring i tråd med virksomhetens behov 2

På grunn av regelverket er det i vesentlig grad skreddersøm og egenutviklede ITløsninger innenfor kjerneprosessene, med bruk av hyllevarekomponenter og offentlige felleskomponenter der hvor dette er

3 Kostnadseffektivt effektivisere utifra helhetlig flyt og riktig sourcing, samt konsolidere «Videre kostnadseffektivisering i drift, forvaltning og utvikling utifra en helhetlig prosessflyt-tankegang:» Tiden det tar fra en endring besluttes til den gir verdi for bruker skal forsøkes kortes ned. Aktivitetene fra en oppgave startes til endringen gir verdi i produksjon er mange, og flere av disse kan trolig gjennom et kritisk blikk forenkles, automatiseres, gjennomføres raskere eller elimineres. Vi skal vurdere flyteffektivitet i et helhetsperspektiv, der både utvikling, drift og også senere utvikling tas hensyn til, slik at ikke lokal optimalisering går på bekostning av helheten. 3

Aktivitetene fra en oppgave startes til endringen gir verdi i produksjon er mange, og flere av disse kan trolig gjennom et kritisk blikk forenkles, automatiseres,

4 Dagens leveranseregime 4

5 Hyppigere leveranser = samme prosess oftere? Pr i dag har SPK 3 hovedleveranser og 8 delleveranser på kjernesystemet PUMA og tilknyttete systemer i året. Dette ble innført etter prinsippet samme prosess oftere. Dette tar veldig mye tid og ressurser og er ikke videre flyteffektivt. 5

kjernesystemet PUMA og tilknyttete systemer i året.

6 Kjennetegn ved dagens leveranseregime Tar tid - minste tid fra bestilling av endring til i produksjon er 6 uker For hovedleveranser tar testløpet 6 uker Tester mye og gjentatt på det samme i forskjellige miljø Mye tid til håndtering av at vi hele tiden tester på rett kode Skille mellom hoved og delleveranser viskes gradvis ut Produksjonssetting skjer koordinert og av produksjonssettingsteam 6

i forskjellige miljø Mye tid til håndtering av at vi hele tiden tester på rett kode Skille mellom

7 Fra SPKs strategi «Tiden det tar fra en endring besluttes til den gir verdi for bruker skal forsøkes kortes ned» Vi klarer ikke øke leveransehyppigheten for enkle endringer med dagens leveranseprosess. 7

Hyppigere leveranser = samme prosess oftere? Pr i dag har SPK 3 hovedleveranser og 8 delleveranser på kjernesystemet PUMA og tilknyttete systemer i året.

8 Hyppigere leveranser = samme prosess oftere? Pr i dag har SPK 3 hovedleveranser og 8 delleveranser på kjernesystemet PUMA og tilknyttete systemer i året. Dette ble innført etter prinsippet samme prosess oftere. Dette tar veldig mye tid og ressurser og er ikke videre flyteffektivt. Hyppige leveranser betyr annen måte å jobbe, ansvarliggjøre og samhandle på. KULTURENDRING!!!! 8

systemer i året. Dette ble innført etter prinsippet samme prosess oftere.

9 CLICK TO EDIT MASTER TITLE STYLE VEIEN VIDERE

10 Det ultimate mål: Kontinuerlig leveranser av små inkrementer av funksjonalitet Kulturelle utfordringer -Måten man deler opp funksjonalitet må endres -Måten man tenker leveranser fra prosjekt må endres -Forretning må evne og være villig til å motta funksjonalitet stykkevis og delt -Smidigteamet må evne og være villig til å levere stykkevis og delt -Gi slipp på belte og bukseseler-det gir ikke bedre kvalitet -Ansvarliggjøre smidigteamet slik at de selv kan bestemme når ny funksjonalitet er klar til å gå i produksjon 10

funksjonalitet stykkevis og delt -Smidigteamet må evne og være villig til å levere stykkevis og delt -Gi slipp på belte og

Tester (FO) Juniorutviklere Scrum master Funksjonelt ansvarlig/test(fa) FO-utviklingsseksjon

11 Krever : God samhandling mellom forretning og IT Systemansvarlig Funksjonelt ansvarlig (FO) Linjen Innføring ( Forretningsområdet FO) Superbrukere/test - FO Seniorutviklere Til sammen: 7-9 ressurser Tester (FO) Juniorutviklere Scrum master Funksjonelt ansvarlig/test(fa) FO-utviklingsseksjon Forretningsstøtteteam teknisk (IT) Testleder IT Testansvarlig (FO) Systemeier servicedesk (FO-UT) Teamleder IT Prosess leder FP 11

12 Man må smake sin egen medisin på godt og vondt 12

13 Evne og tørre å levere stykkevis og delt MEN VI DELER FREMDELES I FOR STORE STYKKER 13

14 CLICK TO EDIT MASTER TITLE STYLE HVOR GÅR VI NÅ?

15 Lynleveranser Piloterer kontinuerlige leveranser på løvnoder i systemet Funksjonalitet og komponenter som ikke har avhengigheter fra andre Så langt! Forretningsressurser og utviklere i team bestemmer sammen om funksjonalitet har god nok kvalitet (tester i teammiljø og akseptansetest miljø) Produksjonssetterteam er flaskehals har oppgave på å lage verktøy slik at også smidigteamene kan produksjonsette Ønsker ikke å gi hvem som helst tilgang i produksjonsmiljøene 15

Forretningsressurser og utviklere i team bestemmer sammen om funksjonalitet har god nok kvalitet (tester i teammiljø

16 Leveranser med avhengigheter - Leverer funksjonalitet i produksjon som er sperret med av/på flagg - Når funksjonalitet er klar - Slår på funksjonalitet i testmiljø - Når god nok kvalitet, slår man på funksjonalitet i produksjon - Noe erfaring på dette i SPK STEG PÅ VEIEN TIL RELEASE TRAINS 16

funksjonalitet i testmiljø - Når god nok kvalitet, slår man på

17 Release trains All innsjekket kode går i produksjon til gitte tidspunkt uavhengig av status SPK håper å starte med dette fra høsten ca hver 3-4 uke - Funksjonalitet som er slått på blir tilgjengelig for linjen i produksjon - Funksjonalitet som er slått av blir tilgjengelig i test - Visker ut skille mellom hoved og delleveranser - Gjør det mulig å levere hyppigere der man har mange avhengigheter 17

tilgjengelig for linjen i produksjon - Funksjonalitet som er slått av blir tilgjengelig i test -

18 Fjerner avhengigheter Jobber kontinuerlig med å fjerne avhengigheter som gjør det umulig å levere kontinuerlig Det ultimate mål: Kontinuerlig leveranser av små inkrementer av funksjonalitet 18

19 Hvorfor er vi ikke der enda? Snakket om hyppigere leveranser siden hovedleveranser i året innført i delleveranser i tillegg innført i 2012 Ja vi leverer hyppigere, men til hvilken pris? Ofte nok Oftere enda mer bruk av ressurser Har vi gjort oss selv en bjørnetjeneste? Trengte modning med kvalitet i fokus Etablert samarbeidet med forretning Etablert smidig forvaltnings- og utviklingsorganisasjon 19

tillegg innført i 2012 Ja vi leverer hyppigere, men til hvilken pris?

Like dokumenter

LEVER OFTERE TEST SMARTERE

1 LEVER OFTERE TEST SMARTERE ØYSTEIN HANSEN CARL JOHNSON 2 Agenda Hvor kom vi fra Veien til moderne utviklingsorganisasjon Hvordan levere - automatisering - arbeidsflyt og verktøy Veien videre og våre