SpareBank 1 Utvikling

Dette er SpareBank 1 Utvikling, og på denne siden kan du bli bedre kjent med hvem vi er, hva vi gjør og hvordan vi jobber – gjennom oss som faktisk jobber her. Så kan du vurdere selv om du også har lyst til å bli en del av det vi mener er det beste og triveligste IT-miljøet i bransjen. Med de flinkeste folka.

Vi skaper en enklere og bedre hverdagsøkonomi

Vi utvikler og forvalter løsninger som brukes av over 1 million kunder. Det er vi skikkelig stolte av! Her kan du bli enda bedre kjent med selskapet, måten vi jobber på, løsningene vi lager, og ikke minst - ukas aller beste dag: Fagdagen.

Miljøbilde fra SpareBank 1

SpareBank 1 Utvikling på Medium @sparebank1-digital

Hvordan har teamet det når alle er på hjemmekontor?

Lenge før vi befant oss på hjemmekontor i mars hadde vi i SpareBank 1 Utvikling jobbet med å måle teamets helse. Noen team hadde kommet lengre enn andre og vi teamledere lærte kontinuerlig av hverandre. Arbeidet ble ekstra viktig nå når alle plutselig måtte jobbe hjemmefra. Hvordan ville “den nye normalen” påvirke oss?Mars 2020 — tomme lokaler hos SpareBank 1 UtviklingJeg er teamleder for Team Betaling, ett av utviklingsteamene som leverer de digitale løsningene for SpareBank 1-bankene. Vi hadde siden juni 2019 hatt en del utskiftninger på teamet, så vi startet måling av teamets helse når alle de nye utviklerne var på plass. For å spare tid gjenbrukte vi spørsmål fra et annet team og rakk såvidt å komme i gang før pandemien traff oss.Helsesjekk for Team Betaling uke 5 og 11 — svaralternativer Ja=5, Tja=3 og Nei=1Vi brukte mer tid på å diskutere hva spørsmålene betydde enn å reflektere rundt svarene som var gitt. Konklusjonen etter to helsesjekker var at vi måtte ha nye spørsmål. I retrospekt var det kanskje ikke den beste løsningen å arve spørsmål fra et annet team, men da kom vi i hvert fall i gang.TrygghetVi visste det var viktig å bygge tryggheten i teamet slik Amy Edmondson snakker om i sin TED-talk Building a pshygologically safe workplace. Det var også godt kjent at trygghet troner øverst etter Googles funn om hva som kjennetegner high performing teams gjennom prosjektet Aristotle.https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/Tid for å ta frem egne spørsmålVia Microsoft Teams og Confluence (Miro var under innføring og kom på plass like etter) jobbet vi frem våre egne spørsmål.Resultat fra workshopDet var mange gode diskusjoner underveis som f.eks. “Kan alle faggrupper i teamet svare på spørsmål om vi har redusert gjeld?” “Ja, det kan vi”. Både design, utvikling og test har gjeld de kan redusere. Og hva syntes vi om å svare på “Jeg har kunnet si hva jeg mener og blitt hørt?” Var vi trygge nok på hverandre til å svare oppriktig her? Ja, vi mente det.Gjennomføring av helsesjekkSpørsmålene ble lagt inn i Microsoft Forms slik at teamet kunne svare anonymt i forkant av selve gjennomgangen.Frekvensen på helsesjekken ble annenhver uke for å få hyppig feedback nå som alle satt hjemme. Gjennomgangen av resultatene med teamet ble satt til 30 minutter. Spørsmålene som hadde snitt på tre eller lavere ble plukket ut for diskusjon. Vi forsterket også spørsmålene som hadde høyt snitt for å forstå hva vi gjorde bra og hvordan vi kunne gjøre mer av det. De få gangene tiden ble knapp under gjennomgangen, satte vi opp egne møter som f.eks. retrospektiv for videre diskusjon.Helsesjekk med de nye spørsmålene — Svaralternativer Helt uenig=1, litt uenig=2, litt enig=3 og helt enig=4MøterFør pandemien hadde vi en del diskusjoner rundt arbeidsflyten. Diskusjonen fortsatte, men årsaken hadde endret seg. Utfordringen hadde gått fra tidvis visuell støy og vanskeligheter med å jobbe fokusert i kontorlandskapet til savn etter raske avklaringer ved pulten/kaffemaskinen og summingen i landskapet.For å kompensere for dette savnet steg møteaktiviteten, som igjen førte til hyppigere fokusskifter og mindre effektiv arbeidsflyt. For å sikre mer tid til fokusert arbeid testet teamet ut å blokke tid i kalenderen slik som Vidar Moe skriver om i sin artikkel Ikke jobb mens jeg forstyrrer. Vi syns det hjalp, og sammen med god dialog mellom produkteier og teamet ble vi også enda flinkere på prioritering av oppgavene.Et annet møte vi måtte se på var standupen. Med 18 personer på Teams ble standup i drøyeste laget og vi besluttet etter en helsesjekk å gå over til skriftlig standup på Slack. Teamet ble enig om å liste opp planene for dagen og eventuelle behov for hjelp. Og ikke minst, passe på å si hei nå som vi ikke så hverandre.“Jeg har kunnet si hva jeg mener og blitt hørt?” hadde stort sett høy score. De gangene den gikk litt ned var årsaken for mange deltagere i et Teams-møte. Terskelen for å ta ordet var høyere nå enn når vi satt i samme møterom. Tiltaket ble å dele opp i mindre arbeidsgrupper som gjorde det tryggere å ta ordet. Vi prøvde også å alltid ha kamera på og bruke hånden eller chatten i Teams for å be om ordet eller gi små kommentarer.Etter hvert endret vi frekvensen på helsesjekken fra annenhver uke til en gang i måneden, både for å ha færre møter, men også for å rekke og gjennomføre tiltakene vi satte oss fra gang til gang.Det sosialeSelv om møter ofte var tema på helsesjekken, var kanskje den største gjengangeren etter pandemien det sosiale. Vi savnet møtene ved kaffemaskinen, de tilfeldige møtene i gangene, det å spise lunsj sammen, kakefeiring og ikke minst noe så enkelt som å si “Hei, hvordan går det?”Det var ikke like enkelt å få gjort noe med det sosiale når smittevernsreglene ble justert regelmessig. Når vi ikke kunne treffes fysisk prøvde vi å få til så mye som mulig digitalt. Kahoot ble innført fast hver fredag som en del av fredagens markering av hva vi hadde fått til gjennom uken. Kakefeiring på leveranser ble samlet opp med levering av noe godt på døren hjemme hos hver enkelt. Vi gjennomførte Team Canvas som gjorde at vi ble bedre kjent med hverandre som team og enkeltpersoner. Alle tiltak hjalp, men de sosiale arenaene er og blir best når vi møtes fysisk.Som teamleder har det også vært viktig med hyppige 1–1 samtaler da helsesjekken ikke erstatter den viktige dialogen med hver enkelt. Vi har også hatt jevnlig retrospektiv for å få mer helhetlig innblikk i teamets tilstand.Uten helsesjekken og verdien den gir hadde vi ikke kunne hatt like god innsikt i teamets helse, spesielt nå som alle sitter på hjemmekontor. Helsesjekken hjelper teamet til å finne hva som bør være fokus for kontinuerlig forbedring og videreutvikling slik at vi skal kunne bli enda Bedre sammen.SpareBank 1 Utviklings VerdiplattformHvordan har teamet det når alle er på hjemmekontor? was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Sissel Sveum

Sayonara, Internet Explorer

Er det ikke kjipt når du har tatt på fullt turtøy og skal ut på en lang ferd mot en vakker horisont, bare til å merke at det er en stein i skoen?Du står da i et viktig veivalg:Skal du bare dure på? Selv om det gjør vondt og går mye tregere, kan du potensielt nå målet ditt.Skal du fjerne steinen? Det tar kanskje litt tid å ta av skoen, men turen blir mye morsommere og du kommer kjappere til mål.På nettsidene har vi fjernet vår stein; Internet Explorer (IE).Alle som har jobbet med web de siste årene vet hvor ressurskrevende det er å tilpasse løsninger sånn at det fungerer greit på IE. Spesielt når man utvikler løsninger som pusher hva våre teknologiske muligheter er, tar det nesten like lang tid å få dette til å fungere på IE.Fokuset vårt vil være på mobil, ikke Internet Explorer.Trygt valgFor sparebank1.no er det et trygt valg å fjerne supportering av IE. Mobil blir bare mer og mer den foretrukne enheten for brukerne våre, og Chrome samt Safari er desidert de mest populære nettleserne. Etter dette kommer Edge og langt bak med stadig synkende trafikk: IE. Microsoft har selv sagt at de skal slutte supportering av IE i 2021 og fokusere fullt på Edge.Dette betyr ikke at nettsidene vil slutte fungere på IE. Det betyr bare at vi kommer til å prioritere andre oppgaver enn å fikse IE feil. Over tid vil det være mer og mer gunstig for brukeren å velge en annen nettleser. Vi står heller ikke alene om dette: Både finn.no, nav.no og spleis.no gir varsling hvis du bruker Internet Explorer.Problemet er bedrifter som har IE som standard nettleserFor de som får en Windows PC fra jobb og booter denne opp er det en stor sannsynlighet at default nettleser er Internet Explorer. Dette er problemet.Jeg antar at en stor andel av brukere ikke egentlig bryr seg om hvilken nettleser de bruker. Den nettleseren som er mest tilgjengelig er den de bruker, og normalen blir at nettsider kan oppføre seg litt rart eller at man får flere og flere varslinger.Når selv Microsoft har gått ut med at Internet Explorer kan være en risiko for sikkerhet, regler og universelle standarder, kan det ikke være opp til den individuelle ansatte å gjøre et skippertak mot bedriftens anbefalinger ved å bytte nettleser. Bedriften må sette en bedre standard med å tilrettelegge en nettleser som faktisk er supportert og fungerer.Uansett, for å bruke et av Japans mest misforståtte ord:Sayonara, Internet Explorer.Sayonara, Internet Explorer was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Lasse Olsen

Playwright vs Cypress

Not too long ago, Cypress seemed to be the most exciting new end-to-end testing framework out there, quickly growing in popularity within different development teams. However now there’s a new kid on the block named Playwright, and it aims to solve a similar issue — helping developers automate their user-flows in a more user-friendly way.This article will compare the two, and hopefully make it clearer which testing framework suits your needs the most, by making you aware of their similarities, differences, strengths and weaknesses.About the frameworksFor an introduction to the fundamentals of Cypress.io, check out my other article named “Testing with Cypress”. In short, Cypress is a tool for setting up, writing, running and debugging tests. It compiles all the tests into Javascript, runs in an instance of a chromium-based browser that includes Chrome, Edge, Brave and Electron. Cypress also just recently added full-support for Firefox browsers.Playwright is essentially a browser automation tool and the processor of the node library Puppeteer, as it has the same functionality along with several improvements such as Cross-browser testing and device emulations. Playwright is also written and maintained by the same people who created Puppeteer, and are now working at Microsoft. This article won’t cover Puppeteer, but it’s handy to know of its similarities, especially if you’re already familiar with it.SimilaritiesSimilarly to Cypress, Playwright is an open-source, Javascript-based library, for automating your end-to-end tests. Both aim to provide a single API that developers and testers can use to interact with web applications across the major browser engines. There is a difference between the two when it comes to browser support, but both offer the ability to run tests and interactions in Firefox and Chromium browsers. Other similarities include functionality, like taking screenshots, stubbing requests, and testing on various screen sizes. If you want to run your tests as part of your continuous integration flow, or prefer to run the tests without a UI interface, then you’ll be happy to hear both offer headless options so that you can run your tests directly in the Terminal.To summarize:Both are Open-source and Javascript-basedCan install both as an npm-package.Single API for testing in several browsers (Both support Firefox and Chromium)Share a lot of the same functionality, like screenshots, stubbing and setting custom view-ports.Neither supports testing in IE11Can be run from the TerminalFrequently updated GitHub ReposDifferencesWhile they both aim to solve a similar issue, they have different ways of doing so. Cypress is more of a “full-package”, and it creates a folder structure along with example files, and you are stuck with the test runner you get with the framework. Playwright, on the other hand, does not make any files and can be configured to work with the test runner of your choice. The two frameworks also run their tests differently. Cypress runs the tests in run-time, and Playwright is promise-based and can run several different browsers and different user contexts in the same test, while Cypress needs to be re-run with the other browser options.Cypress has gone for a syntax more similar to JQuery, but instead of “$”, it uses the keyword “cy”, and a function name. Having one keyword to access everything, might make more sense for designers and junior front-end developers, less familiar with async and creating instances of objects, than the more Javascript approach Playwright has. The example below shows the syntax differences between the two frameworks, and the test scenario is to check if an element with the class name “App-logo” exists.// Cypressdescribe(‘Navigation and Element test’, () => {it(‘Finds the react logo’, () => {cy.visit(‘<http://localhost:3000>');cy.get(‘.App-logo’).should(“exist”);})})// Playwrightimport * as playwright from ‘playwright’;const browsertype = playwright.chromium;(async () => {const browser = await browsertype.launch();const page = await browser.newPage();await page.goto(‘<http://localhost:3000/>');const logo = await page.$(‘.App-logo’)if(!logo) throw new Error(“Cannot find logo”)await browser.close(); // Close browser again})();As previously mentioned Playwright has a syntax closer to Javascript, where you create instances of objects. The ability to create object instances allows us to run multiple tabs, browsers and user contexts at the same time. The example above shows how Playwright uses the async functionality to wait for a UI-element to appear before continuing the test, Cypress, however, solves a similar issue by automatically re-trying the assertions until it reaches the set timeout.One of the most significant benefits of Playwright is its ability to test across multiple pages and domains. Along with setting multiple user contexts. Both are very useful if you’re using third-party sign-ins, pop-ups, iframes (such as BankID in Norway) etc. in your application. Cypress, on the other hand, would require you to write separate tests to simulate the different user scenarios and would require you to stub a lot of the requests to work.To summarize:Playwright works on Webkit-browsers, Cypress does not.You can choose test-runner in PlaywrightPlaywright lets you test in several browsers at the same time.Playwright supports multi-tabs and frames.Cypress doesn’t run in headless mode by default, Playwright does.Playwright awaits UI-elements before running interactions, Cypress re-try assertions until timeout.Size and performanceWhen it comes to size and performance, it’s a bit of a mixed bag. Since Cypress has a built-in test runner, Jest has been added to the comparison, as it’s the most popular Javascript test runner, and needed to achieve similar functionality to Cypress in Playwright. Looking at the minified size, Cypress is technically smaller with it’s 1.6MB against the 2.85MB of Playwright + Jest, but where Playwright + Jest shine is when you look at the dependencies where Playwright + Jest has 14, compared to the 125(!) of Cypress.To test performance, a colleague and I wrote a test in both Playwright + Jest and Cypress. The test scenario covers the following steps:Go to sparebank1.noPress “Godta alle” button for the cookie pop-upFind postal code input and enter 3324Check if a button with the class “ffe-shortcut-button” and text “SpareBank 1 Modum” is visible.Click the button, and check if the page now is Sparebank 1 Modum.The results show that it’s only milliseconds separating the two in terms of speed. Cypress ran the test in 3 seconds, whilst Playwright slightly beat that by completing the test in 2.33 seconds. Essentially it means that both run the test fast, and whilst Playwright was somewhat quicker, it’s not that big of a difference that it should affect your choice of framework.What to pick?So which of these frameworks should you choose? The answer is it depends on how experienced you are with testing, and what functionality you find essential. If you’re new to testing and want a more plug-and-play approach that includes everything you need to get started, then Cypress is the best choice for you. It has good documentation and a broader community that makes it easier to get help and find answers to specific scenarios you find challenging.If you are more familiar with testing, need to test Webkit browsers or your tests need to cover scenarios spanning across multiple pages and domains, then Playwright is the choice for you. Playwright is also the right choice for you if you have fallen in love with a specific test runner or don’t need one at all. With the framework being reasonably new, we can also expect that the community, documentation and framework in general will continue to improve over time.Cypress:➕ Easy to understand documentation➕ A broader community and easier to find answers about specific issues➕ Easier to understand for people new to testing➕ You only have to read up on one framework as Cypress has everything included.➖ Doesn’t support multi-page and third-party implementations.➖ More extensive and with more dependencies➖ Generates several example files and folders➖ You have to re-run tests to run in another browser.Playwright:➕ Broader browser support➕ Fewer dependencies than Cypress➕ Supports multi-page and third-party implementations➕ Lets you choose your test runner.➕ Doesn’t generate any files.➕ You can run multiple browsers using the same test.➖ Documentation not as good➖ Newer and with a smaller communityPlaywright vs Cypress was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av HeleneKassandra

Det skal være lett å gjøre rett — del 3

Det skal være lett å gjøre rett — del 3I forrige artikkel i serien så vi på noen av verktøyene vi bruker til utvikling. Nå skal vi se mer på noe som er minst like viktig, nemlig å få koden ut i produksjon.Som vi vet fra blant annet Accelerate er en av tingene som skiller organisasjoner med høy og lav ytelse er hvor ofte kode rulles ut til produksjon. Hyppige produksjonssettinger fører til færre produksjonsfeil, kortere mean time to recovery (Tiden det tar fra en feil oppstår til den er fikset) og kortere ledetid fra commit til prodsetting.Men det er ikke nok å rulle ut kode til produksjon ofte, det må gjøres på en forutsigbar og trygg måte. Det må kunne gjøres med lave skuldre. Og som de fleste som har vært med på kvartalsvise eller halvårsreleaser som gjøres manuelt kan si: Det å prodsette sjeldent gjør veldig vondt.Det finnes mange artikler som sier noe om hvorfor store releaser gjør vondt, men i bunn og grunn handler det om at dersom du prodsetter mange endringer samtidig, så er sannsynligheten for at det er feil i en av de stor. Og da må hele leveransen rulles tilbake, prosjektledere og interessenter må informeres og du må jobbe overtid for å fikse det. Så må ny produksjonssetting planlegges og driftsressurser må bookes på nytt. Kanskje det til og med blir nattarbeid.Dersom endringssettet du prodsetter er mindre, så er det også mindre som må rulles tilbake, og konsekvensen blir lavere. I tillegg så blir mulighetsrommet for feil lavere. Det er færre endringer, og dermed færre mulige syndere som må sjekkes ut.Applikasjonsarkitektur og verktøy spiller sammenHvis du skal kunne levere kode hyppig, må du også ha en applikasjonsarkitektur som støtter opp under dette. Det finnes flere måter å angripe problemstillingen på, men det vanligste i dag er å dele opp i mindre tilstandsløse applikasjoner som tilsammen utgjør et system.Vi har valgt å basere våre containerbaserte applikasjoner på manifestet The Twelve-Factor App. Det er et manifest som er skrevet av folkene bak tjenesten Heroku. Manifestet beskriver 12 egenskaper de mener at moderne applikasjoner bør ha. Dette setter en del krav til applikasjonene vi deployer:Applikasjonene må være tilstandsløse. Det gjør at applikasjonene er lettere å forvalte og forstå, de blir enklere å skalere horisontalt og det gjør at de passer bedre inn i en verden hvor de kan bli revet ned og startet opp i løpet av sekunder.Hemmeligheter, som er typisk api-nøkler, sertifikater og passord, injiseres fra miljøet rundt. Vi har i tillegg valgt å gjøre løsningen for å legge inn hemmeligheter i en app selvbetjent, slik at om du er en DBA som har generert en databasebruker, legger du den selv inn i applikasjonen som skal ha hemmeligheten. Dermed slipper vi å sende hemmeligheter rundt på mer eller mindre kreative måter som sms, epost eller post-it lapper.DeploymentVi har opp gjennom årene hatt flere verktøy for deployment. Felles for disse er at de som regel har løst et spesifikt problem i et spesifikt miljø. Da vi skulle ha et verktøy til containerplattformen vår, ville vi ha et verktøy som kunne løse deployment i alle miljøer. Vi valgte til slutt å lage vårt eget deploymentverktøy, som var tilpasset våre prosesser og vårt miljø.Resultatet ble Shifter! Som noen sikkert vet er Shifter også en karakter fra Byggmester Bob, og han er ganske god på å flytte rundt på containere.Kilde: https://www.amazon.sg/Fisher-Price-Bob-Builder-Shifter-Vehicle/dp/B06XPYCSHVLitt av grunnen til at vi valgte å utvikle vårt eget deployment-verktøy var fordi vi ville tilpasse det til våre behov og våre verktøy. Blant annet så ønsket vi å kunne vise relevante metrics fra applikasjonen direkte i grensesnittet, slik at man enkelt kan følge med på hva som skjer når man prodsetter en endring.Her har du relevante metrikker for responstid, feilrater og ressursbruk.I tillegg til det grafiske grensesnittet har Shifter et restbasert API som kan benyttes fra jenkins og andre script for å bygge og deploye applikasjoner. Derfor har shifter blitt en viktig del av både utvikling og produksjonsetting hos oss, som hjelper oss å sove godt om natten.I del fire av denne serien skal vi skrive litt om hvordan vi organiserer oss for å kunne jobbe godt med kontinuerlig forbedring av verktøyene våre.Det skal være lett å gjøre rett — del 3 was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Ola Hast

Det skal være lett å gjøre rett — del 2

Det skal være lett å gjøre rett — del 2Vi har valgt å lage en rekke verktøy som gjør livene våre enklere. Disse hjelper oss med å sette opp utviklingsmiljø, deployment og andre vanlige arbeidsoppgaver. Som vi var inne på i første del av denne artikkelserien har vi sett at dette gir oss både fart, trygghet og god nattesøvn. Et skikkelig kinderegg! Men hvordan kom vi egentlig i gang?Alle må starte en plassDa vi startet vår reise som verktøymakere, hadde vi et likt utgangspunkt som veldig mange andre bedrifter: En nedlåst Windowsplattform med Office og IE forhåndsinstallert, men dessverre ikke så veldig mye mer. Og du hadde heller ikke rettigheter til å installere noe selv. Dette er et veldig rasjonelt utgangspunkt om man ikke skal drive med utvikling.Bare det å få satt JAVA_HOME var i seg selv en utfordring, siden maskinen både titt og ofte fikk miljøvariablene resatt av administrasjonsverktøyet. Hele prosessen med sette opp og vedlikeholde et fungerende utviklingsmiljø var en frustrerende affære, som også gjorde det veldig vanskelig å teste ut nye ting. Utviklere brukte ofte ukesverk på å få satt opp alt og på å bli produktive medarbeidere.Dette gjorde at vi ble kjent med våre to første venner: Virtualbox og Vagrant.Kilde: medium.com/@botdotcom/installing-virtualbox-and-vagrant-on-windows-10Kombinasjonen av Virtualbox og Vagrant ga oss muligheten til å scripte oppsettet av et virtuelt linux-miljø uten å måtte forlate windows-plattformen. Da tok det ikke lang tid før vårt første hjemmelagde verktøy, provision-dev ble født.Nå har vi forlatt windows helt til fordel for en utviklingsplattform som kjører Linux, men verktøyet provision-dev lever videre.Provision-devProvision-dev er et konfigurasjonsrepo som lar oss velge selv hva vi ønsker å installere på maskinene våre. Sett utenfra så inneholder provision-dev to script.Configure.sh lar deg velge hva du vil installere i utviklingsmiljøet. Det kan typisk være hvilken versjon av Intellij man ønsker. Videre kan man velge om man ønsker å installere verktøy for sikkerhetstesting, databaseverktøy, mobilutvikling osv.configure.sh brukes til å velge hvilke verktøy man ønsker å installere i sitt miljøNår man har valgt hva man ønsker i utviklingsmiljøet sitt så kjøres steg to av provision-dev, nemlig provision.sh.Provision.sh setter opp alt du trenger for å gå fra en nytanket laptop med linux til å ha et fullt fungerende utviklingsmiljø med et utvalg Java-versjoner, Maven, Node, IDE og kode-editorer. Samt en rekke ekstraverktøy som ikke alle nødvendigvis trenger. Men det er likevel viktig at spesialistene også slipper å bruke masse tid på å sette opp sine verktøy.Dette gjør at du i løpet av få timer fra du får utlevert en maskin, kan ha et ferdig oppsatt utviklingsmiljø. Og vi har som mål at alle nye utviklere skal gjøre sin første commit mot master i løpet av første dag.BobBob er også en viktig del av plattformen vår. Av en eller annen grunn så virker det som at utviklere er fascinert av Byggmester Bob og de andre karakterene i serien. Som regel ender det opp med at interne verktøy får sine navn derifra.Kilde: YoutubeVår Bob startet som en rekke script som ble brukt til å bygge nettbank-applikasjonene, derav navnet Byggmester Bob. Etterhvert samlet vi disse scriptene i et felles gitrepo, slik at vi enklere kunne holde de like på tvers av utviklermaskinene. Som en ekstra bonus så bruker vi provision-dev til å sette opp en cron-job som sørger for at Bob alltid er oppdatert med de siste forbedringene som er gjort.I løpet av de sju årene siden første commit, så har Bob fått mange flere ferdigheter. Vi bruker nå Bob til blant annet å håndtere lokalt utviklingsmiljø, deploye til OpenShift og sette opp byggejobber.Bob har flere funksjonsområderBob er et verktøy du bruker fra kommandolinjen. Kommandoene og strukturen er inspirert av git, og både autocomplete og dokumentasjon av kommandoene er tilgjengelige fra terminalen. Kommandoene er gruppert etter funksjonsområde slik at det er lett å bruke og finne fram. Det er viktig for at det skal bli brukt.Bob og provision-dev utgjør basisen blantverktøyene våre og er de vi bruker mest i hverdagen, men de er ikke alene.Generering av applikasjonerI SpareBank 1 Utvikling er vi nå i overkant av 20 team som jobber med å lage stadig bedre nettbanktjenester til kundene våre. Og for at de skal kunne gjøre det, så må de kunne jobbe uavhengig av hverandre. Samtidig så skal vi kjøre et stort antall applikasjoner i containere og da ønsker man at mye er løst standardisert måte.Et godt eksempel på dette er logging. God logging er viktig av mange årsaker, og en god kandidat for standardisering. Det gjør livet enklere både for deg som utvikler og andre som har behov for å se i loggene. Og hvis man bruker verktøy som ELK-stacken, Splunk eller Humio kan man lettere søke på tvers av applikasjoner og få et bedre oversiktsbilde over applikasjonene dine.For å sørge for at alle som skal lage en ny applikasjon hos oss har et likt utgangspunkt har vi tatt i bruk applikasjonsgeneratorer. Bruk av en slik generator kan bidra til å fjerne en del yak-shaving:Oppsett av loggingStandardisert konfigurasjonOppsett av maven-prosjekt og avhengigheterI tillegg så gjør dette det mulig for oss å sørge for at applikasjonene kommer med ønskede sikkerhetsmekanismer innebygd.Det finnes flere verktøy du kan bruke. Av de enkleste så har man create-react-app og Spring-initializr. Vi hadde bruk for å lage noe litt mer tilpasset til vårt miljø, så derfor valgte vi Yeoman.Yeoman er et kommandolinjeverktøy som gjør det enkelt å kjøre generatorer. Det er basert på Javascript og Node slik at det fungerer fint på de fleste maskinplattformer. Det finnes også et utall ferdiglagde generatorer som man kan ta i bruk, eller man kan gjøre som oss, og lage en som er tilpasset din organisasjon.Her er et eksempel fra awl-generatoren vår. AWL står for Alliansens weblag og er templatene vi bruker til å lage apier og andre applikasjoner som er eksponert mot internett. Her har du mulighet til å velge hva slags type applikasjon det er og så får du et utgangspunkt med riktig konfigurert sikkerhetsnivå og frontend-modul ved behov.FallgruveneVerken standardisering eller verktøy som Bob er uten fallgruver. Og de bør man være klar over.Bob er en abstraksjon på toppen av en rekke verktøy. Det positive med abstraksjonen er at man forenkler mange operasjoner som i utgangspunktet er komplekse. Da slipper man å sette seg inn i hvordan det fungerer under panseret og man får utført det du ønsker å oppnå. Baksiden med dette er at det ikke alltid er lett å forstå hva som skjer. Derfor kan verktøy bli brukt feil og det kan bli vanskelig for brukerne å feilsøke hva som gikk feil de gangene det ikke fungerer som forventet. Abstraksjonene bør derfor være på riktig nivå og heller kombineres i et byggescript.I tillegg så tror vi at det er viktig at verktøyene er åpne. Dersom noen lurer på hvordan det fungerer under panseret, må koden være lett tilgjengelig og det må også være mulig for alle å bidra i utviklingen. Dette er noe vi skal skrive mer om i en senere artikkel.I del tre av denne serien skal vi se mer på hva vi har gjort for å gjøre produksjonssetting raskere, tryggere og hvordan det også bidrar til god nattesøvn.Det skal være lett å gjøre rett — del 2 was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Ola Hast

Det skal være lett å gjøre rett

Vi hadde estimert konverteringen av kredittkortfunksjonaliteten i nettbanken over på ny plattform, til et halvt årsverk. Da vi var ferdige hadde vi brukt ett og et halvt årsverk, altså tre ganger så lang tid. På tross av dette hadde ledelsen tillit til oss. Hvorfor hadde de det? Hva hadde det ekstra årsverket gått med til?Verktøy.Det hadde stort sett gått med til verktøy. Vi var i en situasjon hvor vi skulle konvertere både privatnettbanken og bedriftsnettbanken vår over på ny plattform. Vi så tidlig at vi kunne få god nytte av en del script og verktøy vi hadde laget. Ledelsen så også at dette hadde potensiale til å bli god investering, så dermed ble vi verktøymakere i tillegg til utviklere.Men hva var det egentlig vi så? Hvorfor følte vi det var verdt å bruke dobbelt så mye tid på verktøy i starten som på faktisk konvertering av funksjonalitet?Vi kan se på verktøyene våre som en variant av standardiserte, automatiserte prosesser.The Toyota Way.Hvis Taiichi Ohno og gjengen bak smidigmanifestet er foreldrene til Lean og Smidig, kan vi si at William Deming er bestefaren. I 1950 inspirerte Deming Ohno og Toyota med det som skulle bli kjernen i Toyota Production System, eller Lean, som er det amerikanske betegnelsen på det.Kjernen i Lean består av to ting:Kontinuerlig forbedring — hvordan skape en organisasjon som har kontinuerlig forbedring som basis i kulturen sinRespekt for folk — trua på at folk som får mulighetene og rammebetingelsene, alltid vil gjøre sitt besteDeming mente at basis for kontinuerlig forbedring, er standardiserte prosesser. Hvis vi ikke har standardisert, så er det der vi bør begynne: Finn beste måte å utføre en operasjon på, la alle gjøre operasjonen på denne måten, og sørge for at det er så lett å gjøre det at det føles dumt å la være.Vi som jobber med IT kan gjøre det enda bedre enn å standardisere — vi kan ofte automatisere operasjonene i tillegg.En operasjon alle 150 utviklerne våre gjør flere ganger om dagen eller i uka, er å opprette brancher med tilhørende byggejobber. Vi har laget oss et scriptrammeverk som heter bob, så hos oss gjør vi dette med onelinerenbob feature begin <featurenavn>bob feature begin og bob ci job openMed denne onelineren får viopprettet branchen med rett navnestandardopprettet byggejobben for branchensikret at vi får med oss en commithook slik at den automatisk bygger ved pushVil vi gå til jobben i Jenkins UIet, skriver vibob ci job openså går vi rett dit i nærmeste nettleser.Men vil ikke slike verktøy stå i veien for forbedring, snarere enn å hjelpe?Vi tror det viktigste vi kan gjøre for ikke å gå den fellen, er å sørge for at verktøyene våre er så åpne som mulig, slik at alle kan være med å bidra. Har du forslag til en forbedring, legg opp en pull request, og så tar vi det derfra. På den måten får du også eierskap til verktøyene, du merker at du kan forbedre dem selv.Siden alle teamene våre stort sett bruker de samme verktøyene, så gjør det at det blir lettere å hjelpe hverandre på tvers av team, og også bytte team. Vi kjenner oss igjen i infrastrukturen, og kan fokusere på funksjonaliteten. På denne måten er verktøyene våre med på å skape fellesskap mellom teamene våre, noe vi ofte føler kan være vanskelig, og som vi jobber mye med på fellesarenaene våre som faggruppene og fagdagen hver torsdag.En bil det er lett å starte og kjøre avgårde i.Verktøyene våre hjelper ikke bare med forbedring, de gjør ting enklere for oss også. Operasjoner vi gjør ofte, eller burde gjøre ofte, bør være lette å gjøre — det må være lett å gjøre rett. Tenk hvor enkelt det er å starte og kjøre avgårde med bilen over, på tross av hvor kompliserte de mekaniske og elektriske prosessene som faktisk sørger for at bilen kjører, er?Vi bruker OpenShift som containerplattform, så et tilsvarende eksempel hos oss kan være det å dra opp et containermiljø for applikasjonen en jobber med lokalt. Hos oss gjør vi det med onelinerenbob openshift upVi trenger altså bare disse 16 tegnene og den lokale docker-compose.yaml filen som tilhører applikasjonen, for å spinne opp et fullt testmiljø i openshift for den aktuelle applikasjonen.Enkel utenpå, og litt komplisert inni.Når ting er automatisert og standardisert, så gjør vi ting likt.Et av verktøyene våre som hjelper oss med dette, er applikasjonsgeneratorene våre. Når vi skal lage et nytt api, eller en ny frontendapplikasjon, så genererer vi opp applikasjonene. Dette garanterer blant annet atapplikasjonene har rett konfigurerert sikkerhetat vi har kontroll på hvilke deler av den totale sikkerhet som håndteres av plattformen, og hva som håndteres av applikasjonene selvLike sikkerhetsmekanismer.På denne måten kan vi lage mange nye applikasjoner og deploye mange nye endringer, og fortsatt sove godt om natten.I del to av denne artikkelserien skal vi fortelle om hvordan verktøyene våre er laget. Vi delte også mer om disse temaene på JavaZone VR tidligere i høst.Det skal være lett å gjøre rett was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Vidar Moe

Testavdelingen — Alive and Kicking eller Welcome to my nightmare?

Testavdelingen — Alive and Kicking eller Welcome to my nightmare?Er test på vei til å dø ut som egen profesjon? Kan vi i SpareBank 1 Utvikling legge ned testavdelingen, som flere andre innenfor bransjen har gjort? Vi jobber jo innenfor et regulert domene og må forholde oss til IKT-forskriften og pålegg og føringer fra Finanstilsynet. Er det et mareritt vi på test skal inn i eller er det en spennende reise vi skal på?Bilde: commons.wikimedia.orgFagmiljøet for test og kvalitet i SpareBank 1 Utvikling har endret seg mye de siste årene. Endringsreisen er langt fra over, og vi har gradvis entret ukjent farvann. Help, I need somebody med The Beatles beskriver kanskje en kjent følelse for flere innen testfaget nå om dagen? «Fail fast» er et uttrykk som vi på IT benytter. Vi tester ut hypoteser i raskt tempo, A/B-testing er normalen, og vi kan ta høyere risiko fordi vi oppdager våre egne feil raskt og retter dem så fort at kundekonsekvensen er ingen eller minimal.Men — hvis vi oppdager feilene våre så raskt at kundene ikke merker det, kan vi ikke bare kjøre all koden rett i produksjon og tenke som Gloria Gaynor: Samma det, I will survive?Welcome to my nightmare… Vi på test kjenner litt på en følelse som sikkert inspirerte David Bowie med flere til å skrive Under pressure. Hva skal vi gjøre nå som utviklerne skal automatisere alt selv? Er det virkelig slik at Bruce Springsteen hadde rett; My best was never good enough? Står vi på test igjen på stasjonen mens resten av IT-bransjen suser av gårde?Hvis du har lest boka Accelerate, stoppet du kanskje opp på avsnittet der det skrives at en av kjennetegnene til suksessfulle team er at det er utviklerne selv som skriver alle automatiske tester, inkludert akseptansetestene. Da er det virkelig Welcome to my nightmare for oss på test. Men er du glad i å lese og har litt utholdenhet (og samtidig litt optimistisk på vegne av test-profesjonen) så flyttet du blikket til neste avsnitt:«None of this means that we should get rid of testers. Testers serve an essential role in the software delivery lifecycle, performing manual testing such as exploratory, usability, and acceptance testing, and helping to create and evolve suites of automated tests by working alongside developers.» — Forsgren, Humble, KimVi har da også testere i nesten alle teamene, og det er ikke ofte vi innrømmer det, men vi blir nok litt lykkelige av å Break stuff. Og fortsatt er det sånn at når det brenner på do i noen av prosjektene vi fortsatt kjører, så kommer IT-direktøren og ber om en erfaren testleder. Da er det han som synger Help, I need somebody! Jeg har i en lang periode fått høre: «Vi trenger ikke flere testledere nå, Marianne» så det er nok fortsatt behov for å jobbe med å øke forståelsen for at det er nødvendig med erfarne testledere tidlig i prosjektfasene. Og samtidig biter vi oss i tunga og forsøker å ikke si som Keith Urban I told you so, når noen kommer og ber om hjelp.Konteksten avgjør Testerne og testlederne i SpareBank 1 Utvikling, som designerne og utviklerne våre, trives best i tverrfaglige team der vi sammen jobber mot forretningsmessige mål. Hadde SpareBank1 Utvikling vært en musikal så kunne tittelmelodien vært We are family og Sister sledge hadde vært husbandet. Samtidig har vi innsett at ikke alt lar seg løse i ett team og at også test i SpareBank 1 er avhengig av hva slags system det er man utvikler på eller mot.Også er vi jo veldig glad i API’er om dagen! Vi vil heller utvikle et API eller mot et API enn å forholde oss til gamle legacysystemer. Da kan vi bestemme farta selv. Gartner har en modell som kan brukes til å klassifisere systemene etter endringshastighet: Pacelayering. Den gir mye mening i en kontekstsbasert tilnærming til test. Samtidig må du ikke se deg blind på ulike «lag» i arkitekturen, fordi endringer skjer ofte i flere lag og systemer samtidig. Må teamet forholde seg til lange verdikjeder og gamle legacysystemer, som endrer seg sjelden — men mye — når de først gjør det, må de ha en annen testprosess enn et team som stort sett kan iterere på frontend-koden sin og basere videreutviklingen kun på tommel opp eller tommel ned fra kundene. Vi vil altså at det skal være fast and easy, i motsetning til hva Whitesnake prediker i Slow an’ easy. Slow hos oss i SpareBank 1 Utvikling betyr høy risiko og kompliserte releaser.Vi har kommet til den erkjennelsen at test og kvalitetssikring av software er kontektsbasert. Når vi blir spurt om hva er teststrategien i SpareBank 1 Utvikling så er svaret enten «det kommer an på»:Vis meg systemet ditt/forretningsmålene dine så skal jeg si deg hva strategien ereller kort oppsummert:Riktig kvalitet til rett tid.Tiden for å fokusere på å ha den beste testmetodikken beskrevet og dokumentert er forbi. Nå gjelder det å tenke at verden er dynamisk og vi dokumenterer det vi må. Vi har fokus på automatisering og det neste på lista er automatisert sikkerhetstest. Og med «infrastructure as code» og «pipeline as code» blir vi ikke arbeidsløse med det første. Testavdelingen er definitivt Alive and kicking!Kilder og inspirasjon:Accelerate — Nicole Forsgren, Jez Humble, Gene KimThoughtworks Technology Radar 2020Pace layering Application Strategy — GartnerLloyd RodenSoco TestradarTop ti software testing sangerNoen Twitter-folk det er verdt å følge:· Maaret Pyhäjärvi — @maaretp· Lisa Crispin — @lisacrispin· Michael Bolton — @michaelbolton· Ministry of testing — @ministryoftestFavorittspillelisten for testere på Spotify— Alive and Kicking:Testavdelingen — Alive and Kicking eller Welcome to my nightmare? was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Marianne Falkenås

Det er ikke alltid jeg mocker, men når jeg gjør det bruker jeg Troxy!

I SpareBank 1 Utvikling har vi lang erfaring med å teste hvordan våre applikasjoner oppfører seg under last, altså når mange samtidige brukere benytter en applikasjon. Dette skjer som oftest under en test som kalles ytelsestest, loadtest, performancetest, lasttest, ja dere skjønner greia. Når man kjører en av disse testene, så er det ikke alltid greit å også belaste alle bakomliggende systemer. Dette gjelder spesielt når man integrerer mot underleverandører.Så hva gjør man da? Jo da får man simulere kallene mot de eksterne systemene med hjelp av et simulerings- eller mockverktøy.Om vi går tilbake 15 år i tid var det ikke mange verktøy å velge mellom. Valget ble da å utvikle et eget verktøy som fikk navnet Troxy. Troxy ble spesialdesignet for å brukes som en simulator av eksterne systemer og måtte ha høy kapasitet for å kunne svare på forespørsler fra flere applikasjoner samtidig under lasttest.Troxy kan konfigureres for å settes opp mellom en klient og en webservice. Der fungerer Troxy som en proxy og kan lytte på trafikken og ta opp HTTP-request og HTTP-response. Disse opptakene kan deretter brukes til å svare istedenfor den faktiske tjenesten når applikasjonen sender forespørsler til andre systemer.En av hovedstyrkene til Troxy er at man i tillegg kan trekke ut verdier fra en request og deretter bruke de i responsen som sendes tilbake. Dette er spesielt nyttig om man vil bruke den samme mocken for flere forskjellige testbrukere og der, som et eksempel, fødselsnummer er en verdi som sendes med i request og som i tillegg er med i response. Dette gir noe dynamikk i en ellers statisk oppførsel.Troxy kan i tillegg enkelt utvides med små java-klasser der man har full kontroll over request og response, både under opptak og avspilling. Dette gjør at man f.eks. automatisk kan formatere opptak til å tilpasses sine formål, uten manuell redigering i etterkant.All funksjonalitet kan skriptes via et API mot Troxy, men trenger man manuelt å endre ting kan dette gjøres via et fullverdig UI. Her finner vi blant annet funksjonalitet for å endre modus på Troxy (Avspilling, Opptak osv), håndtere og redigere mocker, samt sjekke loggstatistikk for antall kall mot forskjellige endepunkter.Troxy har med årene blitt et fullverdig mockverktøy og SpareBank 1 Utvikling bruker det nå, i tillegg som simulator ved lasttester, innen både funksjonell test, automatisert regresjons- og integrasjonstest og som simulering av backend-systemer i vår Utviklerportal for åpne APIer.Som et konkret eksempel kan nevnes et testoppsett der det er mulig å konvertere automatiserte ende-til-ende tester til å kjøre mocket, helt uten manuell jobb involvert. Oppsettet tar i utgangspunkt i tester som kjører mot et dockerisert testmiljø inneholdende applikasjon under test sammen med Troxy. Testen kjøres først ende-til-ende med Troxy i opptaksmodus. Deretter kan den samme testen kjøres med Troxy i avspillingsmodus, fullstendig mocket, uten at applikasjonen sender kall bakover mot andre tjenester. Mockene blir lagret sammen med testen og øvrig kildekode.Da Troxy er et testverktøy som kan brukes av andre enn bare SpareBank 1 Utvikling, hvorfor ikke dele det som åpen kildekode? Som sagt så gjort, i 2019 ble det tatt en beslutning om å legge ut det kjære mockverktøyet vårt som open source. For å få det til måtte vi rydde litt i kildekoden, og dette ble gjort gjennom et godt samarbeid med våre utviklere på deres fagdag.Så trenger du et fleksibelt og utvidbart mockverktøy som i tillegg tåler høy last og kan brukes i mange ulike type testscenarier? Kanskje trenger du et godt alternativ til mer etablerte mockverktøy som f.eks Wiremock? Eller kanskje trenger du inspirasjon for å lage noe eget? Test ut Troxy da vel!Det er ikke alltid jeg mocker, men når jeg gjør det bruker jeg Troxy! was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Robert Hammarström

Start smart med premortem

Etter å ha gjennomført over 80 post mortemer siden 2017 sitter SpareBank 1 Utvikling igjen med store mengder verdifull læring, og en trygg arena for å ta frem innsikt sammen etter feil og hendelser. Under arbeidet med post mortem ble vi etterhvert også kjent med en beslektet metode - premortem. Formålet med premortem er å skape læring og forbedring uten at noe har gått galt. En besnærende tanke, men hvordan er det egentlig mulig?Bilde: www.theguardian.comHva er premortem?I Harvard Business Review-artikkelen “Performing a Project Premortem” fra 2007 beskriver Gary Klein en metode for å øke muligheten for at prosjekter lykkes. Ved å gjennomføre premortem i starten av prosjektet, eller før viktige beslutninger skal tas, søkes forbedring mens det fortsatt gjenstår tid og rom for endring. En slik tilnærming fremstår langt mer attraktiv enn alternativet der post mortem utføres etter at prosjektet har gått galt.I en premortem forflytter teamet seg mentalt frem i tid til et sted der prosjektet eller organisasjonen har mislykkes. Deretter ser man seg tilbake for å identifisere hva som kunne føre til at det gikk dårlig. Hovedoppgaven til teammedlemmene er å ta frem sannsynlige grunner til at man har feilet og reflektere over funnene.Kort beskrevet inneholder premortem følgende:Teamlederen tar med seg teamet et år frem i tid og informerer om at prosjektet på dette tidspunktet har feilet spektakulært.Teammedlemmene ser seg tilbake og skriver hver for seg ned årsaker til at det gikk så galt.Resultatene deles med gruppen ved at et og et notat leses opp av forfatteren. Når den første årsaken er presentert leser nestemann opp en ny. Slik går runden videre i gruppen helt til alle punktene er dokumentert.Teamet reflekterer over innspillene mtp. hvordan man kan styrke sin plan.Diskusjon om mulige grunner til at rekruttering av utviklere gikk galt i 2020.Hvorfor er premortem en god ide?Gary Klein viser til at effekten av “prospective hindsight” i premortem er betydelig høyere enn det tradisjonelle spørsmålet “Hva kan gå galt?” ved starten av et prosjekt.“Research conducted in 1989 by Deborah J. Mitchell, of the Wharton School; Jay Russo, of Cornell; and Nancy Pennington, of the University of Colorado, found that prospective hindsight — imagining that an event has already occurred — increases the ability to correctly identify reasons for future outcomes by 30%.“— Gary KleinVidere peker Klein på at premortem kan bidra til å redusere effekten av overmot ved starten av prosjekter. Teknikken skaper også trygge rammer for å kunne løfte frem og diskutere problemer. Ved at metoden belønner vanskelige innspill, bygger man kultur for å prate om utfordringer.Psykolog og nobelprisvinner i økonomi Daniel Kahneman omtaler premortem i sin anerkjente bok “Thinking, Fast and Slow”. Her er lenke til en kort video hvor Kahneman beskriver metodens positive effekter.“What the premortem technique does, which I think is beautiful, is that it legitimizes dissent. Actually, it turns things around. It rewards people for being imaginative in finding flaws in the current plan.”— Daniel KahnemanTid for eksperimentPå slutten av 2019 grep vi sjansen til å teste ut metoden ifbm. satsing på et nytt produktområde. Erfaringen fra første premortem var positiv, der teamets refleksjon skapte innsikt med betydelig verdi for deres videre arbeid. De positive erfaringene gav mersmak, og vi har nå prøvd ut premortem på følgende områder:Partneres bruk av SpareBank 1 sin finansplattformRekruttering av utviklereOrganisering av utviklingsteam med økt ansvarCovid-19 situasjonen (remote sesjon)Vår gjennomføringI premortemene som er utført til nå har det vært gunstig med en eller to dedikerte personer til å fasilitere sesjonen. Psykologisk trygghet er et viktig premiss for arbeidet som skal finne sted. Tydelig fokus på “blaimfree” dialog med trygge rammer vil være sentralt for en vellykket gjennomføring. Vi har derfor innledet hver premortem med en introduksjon av selve konseptet, inkludert viktigheten av å følge anbefalte retningslinjer. Ut over introduksjonen har det ikke vært behov for at teammedlemmene har forberedt seg særskilt til et premortem.For oss har det viktigste forarbeidet vist seg å være konstruksjonen av caset som har feilet spektakulært. En sterk historie som fremføres med innlevelse og troverdighet er utgangspunktet for å skape engasjement i gruppen. Både kreativitet og fremføring har så langt vært imponerende.Teamet skriver ned grunner til at det gikk galt.Etter at teamet er tatt med frem i tid, og informert om at man har feilet stort, er det dags for å reflektere. I denne delen av premortem har teamet sett seg tilbake og notert hver for seg årsaker til at utfallet ble negativt. Resultatene er så blitt delt i gruppen ved at et og et notat presenteres av skribenten. Årsaken henges deretter opp på veggen etter eventuelle spørsmål og kommentarer. Med første notat ferdig presentert leser nestemann opp en ny lapp. Runden blir avsluttet når alle årsakene er presentert og klistret på veggen.Med gjennomgang av mulige feilkilder sluttført var neste steg å velge ut hva man skulle fokusere på med resterende tilgjengelige tid. Deltagerne grupperte da først sammenfallende punkter og stemte så frem årsakene som var mest interessante å drøfte dypere mtp. rotårsaker og mulige tiltak. Prioriteringen ble gjort vha.“dot-voting”.Når arbeidsmøtet er ferdig og deltagerne har mottatt velfortjent takk for bidrag og innsats gjenstår noe etterarbeid. Dette består i at innspillene oppsummeres og deles med teamet, samt deles med andre som kan ha nytte av resultatet. Noen punkter krever ytterligere refleksjon og analyse, mens andre allerede har resultert i konkrete tiltak.Kan premortem bli for negativt?Et punkt vi var nysgjerrige på var om det kan bli for mye negativt fokus i en premortem? Daniel Kahneman trekker frem en bekymring han har registrert ifbm. at organisasjoner har et grunnleggende ønske om optimisme. Her fryktes handlingslammelse hvis man blir kjent med reell kostnad og risiko, som et resultat av at man kvier seg for initiativ som blir utfordrende. Kahnemans svar til dette er at balansepunktet mellom realisme og optimisme er en reell diskusjon. Samtidig argumenterer han for at å kjenne til feilkilder uansett er nyttig. Vi har så langt ikke opplevd utfordringer knyttet til at fokus på risikopunkter skaper negativ stemning eller frykt for handling. Inntrykket har tvert i mot vært at det skapes energi og et sterkt ønske om tiltak for å forbedre situasjonen.Tilbakemeldinger fra deltagereEt tydelig mønster i tilbakemeldingene etter våre premortemer er at det er positivt å jobbe med problemer før de oppstår. Deltagerne synes det er nyttig å være pro-aktive og reflektere over hva som er viktig. I tillegg liker man selve formatet, der lettbent og enkel gjennomføring skaper en positiv måte å diskutere mulige utfordringer på. Samtidig lar strukturen gruppa fokusere på det de selv ønsker uten negativt press eller stress. Videre vurderes premortem som en lærerik øvelse der det kommer frem punkter man ikke har tenkt på før.Kan vi risikere at historien som fremføres er for negativ? En av tilbakemeldingene fra deltagerne stilte spørsmålstegn ved om historien som ble fortalt i for stor grad var “worst case”. Dette spørsmålet er det verdt å reflektere over. Selv om våre case til nå ser ut til å ha truffet greit mtp. balanse på alvorlig konsekvens og realisme understreker punktet viktigheten av at materialet som presenteres er godt oppbygd og troverdig presentert.OppsummeringI SpareBank 1 Utvikling er post mortem en god følgesvenn for trygg læring når noe har gått galt. Det har vært lærerikt å teste ut en teknikk som søker å redusere behovet for bruk av post mortem. Erfaringene så langt støtter hypotesen om at premortem kan være en bidragsyter til dette. Gjennom refleksjon og innsikt mens det fortsatt er tid og mulighet for forbedring øker sannsynligheten for at det man jobber med blir vellykket.Start smart med premortem was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Kristoffer Berg

Ikke jobb mens jeg forstyrrer — del to

Ikke jobb mens jeg forstyrrer — del toI del en av denne historien fortalte jeg at jeg var på vei til å bli utbrent.Kombinasjonen av sterkt leveransepress og hyppige avbrudd var i ferd med å spise oss opp. Hvordan skulle vi klare å levere forbedringer raskt og med høy kvalitet, når vi ble avbrutt hele tiden?Gjennom å gjennomføre en A3 identifiserte vi de viktigste typene avbrudd vi ble utsatt for:Møter — både egne og andresElektronisk kommunikasjon — chat, epost, SMS osvSelvpåførte konsentrasjonsavbrudd — tankene spinner avgårde, enten på oppgaver en vet en skal gjøre, eller en kommer på nye oppgaver som trengs å gjøresPirk på skulderen og kapring ved kaffeautomaten — “Har du fem minutter?”Del en beskrev hvilke grep vi gjorde for å håndtere møtene.Men hva har vi gjort for å få kontroll med resten?Foto: Getty Images via IStock.Jeg sendte deg akkurat en epostDet er godt mulig. Det vet jeg ikke noe om. For jeg har skrudd av epostklienten. Jeg prøver så godt jeg kan å ha den lukket gjennom dagen. Helst ønsker jeg å sjekke epost om morgenen, etter lunsj, og før jeg går hjem om ettermiddagen. Har du sendt meg en epost på den private epostadressen min, så sjekker jeg den ikke før på kvelden.Før hadde vi epostklienten oppe, gjerne med pushvarsling aktivert, hele dagen. Dette var en av årsakene til at vi endte opp i den uholdbare situasjonen vi var kommet i. Det er en befrielse å kunne håndtere eposter på bestemte tider på dagen, heller enn å stadig skulle bli avbrutt av mer eller mindre viktige eposter.Ved å håndere epostene på denne måten, får jeg også muligheten til å prioritere arbeidet epostene resulterer i. Når jeg kan se gjennom flere eposter samtidig, kan jeg lettere ta stilling til hvilke som bør følges opp når.Kanskje har du ditt eget system for å håndtere oppgavene dine? For meg fungerer det best med en liste i et enkelt tekstdokument hvor jeg kan notere så mye eller lite jeg trenger om det som skal gjøres.TextEdit oppgavedokumentet mitt ble litt kjedelig, så det ble dette bildet istedet.Når en oppgave er gjort, sletter jeg den fra listen min. Det gir en god følelse. Derfor er det lurt å skrive opp også enkle oppgaver som å svare på en epost. Det lille dopaminkicket du får når du har gjort en oppgave og kan slette den fra listen, det har du fortjent.Det rister i buksaJa, det gjør det. Men det er sjelden. For jeg har skrudd av nesten alle pushvarslene mine. De eneste pushvarslene jeg har igjen er SMS, Facebook Messenger og direktemeldingene på Slack.Før hadde jeg pushvarsler med vibrasjonsvarsling på det meste, inkludert Facebook og private epostvarsler. Det var gøy i starten, men etterhvert som jeg ble mer og mer bevisst på hvordan disse avbruddene påvirket meg, var det en befrielse å skru dem av. Jeg har aldri sett meg tilbake.Jeg kom på en tingDet gjør jeg hele tiden. For å få det ut av hodet og jobbe videre med det jeg holder på med, så må jeg legge til en ny linje i oppgavelisten min. Da får jeg også samtidig prioritert oppgaven i forhold til alt det andre som står der som skal gjøres.Av og til er det utfordringer som er såpass krevende at føles umulig ikke å tenke på det. Tankene blir trukket mot det hele tiden. Da holder det ikke bare å notere det ned i oppgavelisten. Da må jeg også ta meg tid til å finne ut av når jeg skal jobbe med problemstillingen. Deretter booker jeg et møte i kalenderen med meg selv, slik at jeg vet at jeg har god nok tid til å jobbe grundig med det. Først da klarer hodet slippe taket, og jeg kan jobbe videre med det jeg holder på med.Det kan være lurt å sette av tid i kalenderen til å jobbe med krevende utfordringer.Så du Slackmeldingen min?Det kommer an på. For jeg har ofte skrudd av Slackklienten også. Er jeg midt inne i noe, så er det ikke sikkert jeg sjekker mobilen, selv om Slackappen gjør et rist.Jeg prøver å sjekke Slack samtidig som jeg sjekker epost. Da oppnår jeg den samme fordelen som nevnt over: Jeg kan gå gjennom alle meldingene og epostene samtidig, og lage en prioritert liste over hva som skal håndteres når. Er det trivielt å svare på meldingene, så svarer jeg selvfølgelig på dem med en gang.Men hva når noen trenger hjelp med en gang? Er det noen som trenger hjelp eller lurer på noe, så er det som oftest relatert til noe jeg jobber med. Jeg jobber i team. Dermed er det som oftest noen av teammedlemmene som trenger hjelp eller lurer på noe. Da prater vi heldigvis sammen. Det er som oftest alltid mer effektivt enn skriftlig på Slack, og mye hyggeligere.Har du tid til å tenke?Vi som jobber med kunnskapsarbeid, er ansatt for å løse komplekse problemstillinger som ofte aldri er løst før i vår kontekst. Samtidig er det en forventning om at vi skal være tilgjengelig for alle spørsmål, meninger, informasjon og møter i alle kanaler hele tiden. Dette er en situasjon som kan være farlig, og i verste fall føre til utbrenthet og årelange fravær fra arbeidslivet.Det lille dopaminkicket vi får for hver eneste Slackmelding, Facebookpost, møteinnkalling eller epost vi mottar, er godt. Følelsen vi får når vi har løst en komplisert oppgave som ofte kommer mange andre til nytte, er bedre.For å løse flere av de kompliserte oppgavene, må vi gi oss selv tid og rom til å tenke. Vi løser oppgavene best når vi jobber sammenhengende uten forstyrrelser.Ved å ta tilbake kontrollen over tiden min, unngikk jeg trolig å bli utbrent. Jeg håper du også tar tilbake kontrollen over tiden din. Det tror jeg er best for oss alle.Ikke jobb mens jeg forstyrrer — del to was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Vidar Moe

SpareBank 1 Utvikling på Instagram @sparebank1design / @sparebank1utvikler