�ݺ�ߣ

Editor's Notes

• #2: Bakgrunn fra Norges Bank, Statens vegvesen og Skatteetaten. De siste årene som utviklingsleder og nå prosjektleder i MAG. Fikk første møte med smidig i 2009, gjennom et prosjekt i Skatteetaten, som skulle samle inn opplysninger om PROM på bolig og levere nye likningsverdier. Sjokkopplevelse. prosjektledelse møter smidig, en vandring fra følelsen av å ha kontroll på det meste, grundig planlegging, gjøre ting på riktig måte og over til å bistå med å faktisk utvikle de rette oppgavene, tilrettelegge for mer effektiv utvikling osv, tjenende lederskap.
• #3: Det er på en måte en partybrems å si at en jobber i Skatteetaten… Litt dumt egentlig. Å betale skatt betyr som oftest at en har jobb. Skattepenger gjør at en får en fantastisk drahjelp i samfunnet, når livet går en litt i mot.
• #4: Startet utvikling våren 2011. Startet med under 10 personer og oppskalerte til ca i 100 personer i leveranseorganisasjonen. Utviklingsarbeidet var fordelt på Oslo og Grimstad. Avslutter mars 2016. På plan, På budsjett. Høy kvalitet. Vi mener altså å være et vellykket offentlig IT-prosjekt av et visst omfang. 50% interne og eksterne. Et stort antall interne har økt kompetanse innen smidig systemutvikling Baserte oss på rammeavtalene våre. Interne sentralt plassert i prosjektledelsen. Miks av interne og eksterne. Kjøp av kompetanse, setter sammen teamene selv. Ble etterhvert som en liten fabrikk, som utviklet for flere prosjekt. Det største var utviklingen av A-ordningen. Målsetningen var flerdelt – ta imot alle grunnlagsdata fra alle tenkelige firma og organisasjoner, kontrollere dem, gi oppgavegiver tilbakemelding, lagre dem. Dataene brukes videre til å presenteres på selvangivelsen dere eller til kontroll av data på selvangivelsen. Moedernisert plattform basert på Java og Open Source. Systemet skulle kunne skaleres opp og gi ekstrem ytelse. Data skulle skli igjennom uten bruk av menneskehender. XML som format, Altinn som sentral kanal for innrapportering. Vi skulle gjøre bruk av nye metoder – dvs smidig, nye verktøy for utvikling og prosjektstøtte. Vi skulle etablere et par interne felleskomponeter, bl.a. et felles lager og et partsregister. Vi skulle erstatte eksistererende 17 systemer med et. Vi nådde alle mål untatt et…
• #5: Vi leverte ikke et system. Vi leverte rett under 100. Applikasjonene ble etter hvert utviklet som et knippe felleskomponenter, med en rekke mikrotjenestebaserte applikasjoner, som et ledd i et ny arkitektur og et nytt målbilde. Erfaringen med å bygge denne type arkitektur får vi ta i en annet fora, men vi fikk mye dyrkjøpt læring på veien. Med denne arkitekturen ser vi at det gir raskere oppstart for nye prosjekt. Mange komponenter er generelle og kan gjenbrukes i stor grad av andre prosjelkt. De slipper å bruke tid på å lage løsninger for å håndtere register over personer og firma, slipper å lage løsninger for å motta data, sende ut svar, få oppgaver i en manuelle arbeidsliste osv. Vi oppnår i stadig større grad å kunne etablere mindre prosjekt. Prosjektene kan i større grad konsentrere seg om kjernen i det de skal lage – det funksjonelle scope.
• #6: Kontinuerlig oppbemanning – relasjoner var ikke på plass – helt nye team Begrenset med smidig kompetanse i starten Sterke meninger og flere med vetorett innen f.eks. brukskvalitet og arkitektur Ny systemtemutviklingsmetode – ikke helt ferdig, men vi fotfulgt i forhold til å bruke denne Avstand Oslo - Grimstad Kompetansebygging Kontrollmekanismer etableres for å bygge tillit
• #7: Krevende og langsiktig løsningsarbeid – år til løsning utvikles – uker å utvikle – hvordan involvere Planleggingshorisont – sette scope – vet mye om kommende release, noe om neste, men lite om det som kommer etter. Frustrerende periode med langtidsplanlegging, som aldri holdt stikk. Bedre å snu fokus – tenke at endringer er sunt og hele tiden vurdere hva som er viktigste. Samtidig som en ikke glemmer det store bildet. Når vi målet? Kan vi rapportere til Finans på en tilfredsstillende måte? Samspill løsning – utvikling Oslo og Grimstad Backlogg grooming Funksjonell i team inngår i løsning Varm kommunikasjon/tilstedeværelse.. Produkteier
• #8: Ny arkitektur – ingen hadde jobbet med det tidligere, men alle drømte om det.. Mange hadde sterke meninger om hvordan vi skulle løse det.. Vi måtte lære sammen og lære fort.. Det sies at den beste arkitekturen kommer fra teamene selv. Det kan være korrekt, men kan man forvente at seks team skal tolke, forstå og implementere sikkerhet på en tilfredsstillende måte i en kompleks driftsorganisasjon – hva med logging – feilhåndtering? Svaret er selvsagt at hvert enkelt team da må få ansvar for produktet til produksjonssetting selv. Det er jeg for, men det passer ikke overalt. Det passet ikke i dette prosjektet. Vi kunne gjort det med noen av komponentene, men vi hadde ikke mulighet til å klare det der vi var.
• #9: Selvdrevne så langt praktisk mulig Scrummaster – ble litt som teamleder fordi prosjektet var langt og stort. Måtte også ta noe mer ansvar i forhold til trivsel/videreutvikling etc Spesifikasjon trengte ikke kode – de andre skulle bidra med koding Arkitekt – kunne også bli dratt inn i større arkitekturroller, men hadde hovedsakelig ansvar for arkitektur i teamet. Omstridt rolle egentlig – alle burde jo være arkitekter.. Test Devops – viktig rolle for å minimalisere overleveringer, få med driftskrav ved oppstart. Tavla er i fokus Fokus på flytte lapper = suksess = glede Tavla avslører situasjon – Den lyver aldri – viktig for å skape forståelse – for å etablere kollektivt ansvar for å lykkes. Forvaltningsteam – komponentstyrt under prosjektet. Rakk aldri å gjøre det riktig. Vi stokker nå om, slik at teamene eier større del av verdikjeden og har helhetlig funksjonelt fokus. Bygge miljø for å lære– Arkitekt i sentrum / Ukens kode / kodegransk /teambytte / parprogrammering – halv fart, eller? SOS -> naturlig samhandling Status -> strategimøte Fagområder på tvers – test, devops, arkitekt Tabbetvist – greit å gjøre feil, men viktig å forstå at det er forskjell på dem..
• #10: Satsning på automatisering – rammeverk for ende til ende tester. Rammeverk for ytelsestester – eget ytelsestestmiljø i Altinn, hvor en kunne simulere Altinn-trafikk sammen med vår egen. Stor investering, men avdekket mye på veien, som måtte rettes. Data som ble borte på veien ved helt spesielle hendelser – ekstremt krevende å feilsøke. Bedre å finne dem før det skjer i produksjon. Test i smidig er litt utfordrende å få helt grepet på. Teamet skal være selvdrevent, teste og sette i produksjon selv. Jeg er litt gammeldags. Jeg tenker enda at det er jo noen som har bestilt et eller annet. Burde ikke en uavhengig teste at det er korrekt forstått og mottatt? Testgjennomføring var ekstremt viktige, etter hvert fikk tekniske testere en sentral rolle. Nå er mer og mer test flyttet over i teamene og det er veldig bra. Vi jobber nå med modeller og miljø for å sikre verdikjedetester, etter hvert som flere og flere tar i bruk felleskomponentene. Automatiserte tester – blir ikke det dobbel kode? Tilnærmet lik ingen følgefeil i prod. Større refaktureringer utført med trygghet!
• #11: A-ordningen – Skatteetaten mottar data på vegne av Staten og sender videre til andre som NAV og SSB. Alle opplysninger om alle med ansettelsesforhold i Norge rapporteres månedlig inn. Prosjekt endrer karakter – mer forvaltning – sprint 50 rundes – feirer på Skatteetats vis med boller og brus.. Sommeren nærmer seg. I juni skal Finans underrettes som Skatteetaten er klare til å starte A-ordningen. Ytelsestallene er not even close.. VI er ikke i nærheten av å kunne fortelle Finans, at vi er klare til å starte. Nytt tverrfaglig team settes sammen – et mål – løs ytelsen.. Fungerte fantastisk – I løpet av en sprint er vi nærme på å være gode nok. På to sprinter er vi i mål og mer til! Men hvordan respondere raskt nok på feil og tilbakemeldinger? Hvordan sikre at vi unngår store manuelle oppgaver når 220 000 oppgavegivere skal levere data hver måned – store datamengder?
• #12: Release koster. Vi starter opp med kvartalsvise releaser. Hele helger og mer til med nedetid. Overlevering, møter, gjennomgang av kjøreplaner, feilsøkinger. Vi tenkte at det var lurt å gjøre det oftere for å bli flinkere, for å ha mindre i releasene og senkes risiko. Kom oss ned i seks ukers utvikling, men test tok like langt tid og det samme gjorde prodsetting. Vi slet med å få ut forbedringer på under 16 uker. Vi planla å gå ned til en måned utvikling, men tenkte at det kom til å smerte og egentlig hjelpe litt. Vi begynte da å se på hva som gjorde at vi kunne legge ut feilrettinger på en dag. Kanskje var det veien å gå? Vi startet omleggingen av rytmen for prosjektet i november. Beholdt månedsreleaser, men tok alle feilretting og forbedringer på en kontinuerlig forbedring. Vurderte alle overlevering, evt byråkrati, automatiserte prosesser osv. Resultatet er at vi nå prodsetter endringer og feilrettinger – også på virksomhetskritiske komponenter, flere ganger i uka. Det meste på dagtid.
• #13: Fortsatt lang vei å gå. Mangler fortsatt erfaring og kompetanse. Kontrollerfunksjoner – skal påse at, rapporteringsregime. I en stor organisasjon med store tall, øremerkede midler, likebehandling etc er det krevende. Teknologisk også en utfordring, f.eks. automatiserte tester på PL/SQL. Cobol-kode som skal vedlikeholdes. Mange tekniske miljø som skal holdes vedlike. Sanering er en utfordring. Spre MAG-DNA et i linje og prosjekt Prosjekt og linje forbedrer/gjenbruker Rammeverk metode Komponenter nøkkelpersoner Fagnettverk / relasjoner Best of breed metodeverk PS2000 smidig i bunn Volere kravspek ISTQB smidig, osv Agile coach