SpareBank 1 Utvikling

Et spennende sted å jobbe

Vi er de 14 SpareBank 1-bankenes felles utviklingsselskap. Vår oppgave er å skape de aller beste løsningene og brukeropplevelsene i bransjen – fordi hverdagsøkonomien er viktig for folk. Vi lykkes ved å la kompetanse, læring og frihet definere oss, og fordi vi jobber kompromissløst data- og kundedrevet.

Et godt sted å være

For å kunne yte på jobb, må vi trives på jobb. Våre medarbeidere får derfor stor tillit og mye ansvar, men også den støtten, veiledningen og opplæringen de trenger for å mestre og like jobben sin. Dessuten passer vi på å le sammen. Mye. Det blir nemlig veldig gode løsninger av god stemning.

@sparebank1-digital på Medium

Er du utvikler? Gratulerer med sikkerhetsjobben!

I SpareBank 1 Utvikling legger vi mye innsats i å lage løsninger med riktig sikkerhet innebygd. Noe av det gjøres av oss med “sikkerhet” i stillingstittelen, men den viktige sikkerhetsjobben er det utviklerne som gjør.Av og til er sikkerhet enkelt å se. Det kan være autentisering, kryptering eller validering, eller annen sikkerhetsfunksjonalitet. Det er åpenbart viktig at det virker, men applikasjonssikkerhet er mye mer enn som så. Sikkerhet er summen av hvordan applikasjonen din reagerer når noen med uærlige hensikter pirker borti applikasjonslogikken eller den tekniske stacken. Sikkerhet er en egenskap i applikasjonen, og oppstår eller forsvinner i den daglige utviklingen av helt vanlig kode.Denne er katastrofal. Én ordinær kodelinje, så faller hele korthuset sammen. Ser du hvor?Heldigvis jobber de fleste av oss også mer eller mindre smidig. Et nøkkelkonsept her er at utviklingsteamene har selvstendig ansvar for applikasjonene sine. Det inkluderer sikkerhetsegenskapene, like mye som ytelsen og brukeropplevelsen. Sikkerhetsarbeidet i en utviklingsorganisasjon er selvsagt mer enn å peke på at utviklerne har ansvaret, men man vil aldri lykkes om utviklerne ikke har forutsetningene for selv å oppdage at det kan være fare på ferde i dagens fjerde pull request.Slike endepunkt som spiser JSON har du sikkert tusen av. Payload parses av et rammeverk, og du får et objekt ut. Vakkert. Men er du sikker på hva slags objekter som faktisk blir lagd? Eller at det bare er JSON som godtas?Her har jeg oppdaget at applikasjonen godtar Content-Type satt til YAML! Da kan jeg unytte at rammeverket RESTeasy tillater at man kan lage helt vilkårlige objekter. Her lager jeg et ScriptEngineManager-objekt, som tar inn en URLClassLoader, som laster min javakode fra min server og kjører det på din. Dette er insecure deserialization, som bl.a. Jackson har hatt mye av.Hvordan sørger man for at utviklerne lukter sikkerhetsuglene i kodemosen? At SQL må være parameterisert, eller at serialisering har sine fallgruver? Som mye annet er det øvelse som gjelder, og vi har den tvilsomme fordelen av at vi som bransje gjentar de samme sikkerhetsfeilene om og om igjen. Dermed kan man øve seg på alt som har gått feil før. Her følger noen varianter vi i SpareBank 1 Utvikling har prøvd med stort hell! Først en kort oversikt, så detaljer om hver enkelt, med fordeler og ulemper:Natas: Enkel testing av sårbar appKWASHC: Fiks en rekke sårbarheter i en webappHack yourself first: Strukturert workshopBugbounties: Test andres løsninger på lovlig visOnline trainingTil slutt er det også et avsnitt om nyttige verktøy for sikkerhetstesting.NatasNatas fra Over the wire består av et tredvetalls “capture the flag”-oppgaver (CTF), der man skal utnytte en sårbarhet i oppgaveapplikasjonen for å skaffe seg en nøkkel som man bruker for å få tilgang til neste oppgave.FordelerKrever ikke noe oppsett. Det er bare å starte på oppgave 0 og fortsette derfra.Fungerer godt som gruppearbeid.Dekker svært mange vanlige sårbarhetsklasser, gjerne i flere varianter eller med utilstrekkelige fikser.Går over http og ikke https, så forutsetter ikke at man må sette opp sertifikathåndtering i webproxy (se avsnitt om verktøy).UlemperKommer ikke med noen form for forklaring eller introduksjon til sårbarhetene, så det er nok en del av oppgavene som kan være vanskelige å starte på om man står på bar bakke. Man finner fasit for oppgavene om man søker, men da må man ha litt disiplin for ikke å bare lese hele løsningen.Ikke fokus på hvordan man bør fikse sårbarhetene.Kantega Web Application Security Hero Challenge (KWASHC)KWASHC er i stor grad utviklet av Kantega i Trondheim (si navnet litt fort!). Hovedfokuset er ikke på å finne sårbarhetene, men å fikse dem i koden. Består av en serverkomponent med oppgaver og scoreboard, og en sårbar bloggtjeneste skrevet i Java.Mange røde lys. Her trengs en Security Hero!FordelerFokus på sikker koding, og ikke testing.Forklarer sårbarhetene, så man har et greit grunnlag for å finne løsninger selv om det er nytt stoff.Open source, så du kan tilpasse eller utvide som du vil.Scoreboard gjør det underholdende å kjøre i mild konkurranseform, gjerne mellom grupper.UlemperKrever litt lokalt oppsett.Ikke den aller mest moderne tekniske frontendstacken, med Spring MVC og serverside-rendret jsp. Kanskje du vil modernisere den?Hack yourself firstTroy Hunt, bl.a. kjent for ‘; — have i been pwned?, holder en veldig god applikasjonssikkerhetsworkshop kalt Hack yourself first.https://medium.com/media/27fbf4aad2a99001fe4a10c9369b5cac/hrefSpareBank 1 Utvikling har både leid inn Troy for å holde denne workshopen on-site, og sendt enkeltutviklere på fellesworkshops hos NDC Security. Det er en blanding av undervisning og oppgaver over to dager.Troy har også mye innhold online på Pluralsight, inkludert Hack yourself first i videoform. Det er nok likevel ikke helt det samme som å delta på en workshop.FordelerNøkkelferdig opplegg fra profesjonell kursholder.To fulle dager lar en gå litt i dybden på mange tema. Holder man workshopen internt legger det rette til gode diskusjoner om hvordan man selv bygger løsninger.UlemperKoster en del.BugbountiesI år opprettet vi en applikasjonssikkerhetsgruppe for jobbing sammen på fagdagen. Der har vi blant annet tenkt å jobbe med bugbounties. Bugbounty-program er uorganisert sikkerhetstesting: Firma registrerer løsningene sine hos tilbydere som Bugcrowd eller HackerOne, og så kan hver og en av oss sikkerhetsteste dem fritt innenfor de rammene de spesifiserer. Det er en veldig god øvelse på å få se ting fra angriperens perspektiv. -Hva inneholder denne applikasjonen? Hva slags teknologistack finner vi, og hvordan kan vi prøve å misbruke funksjonalitet eller implementasjon?HackerOne har forøvrig en flott Hacktivity-side, der fulle rapporter på publiserte sårbarheter ligger. Mye fin inspirasjon.FordelerDet blir ikke mer realistisk enn produksjonsløsninger.Man får utforske varierte teknologistacker, og får reflektere litt over likheter og forskjeller, og patterns som legger opp til sårbarheter. Da blir det enklere å gjenkjenne dem i egne systemer.Det er veldig tilfredsstillende når man finner noe!En del av programmene utbetaler penger for funn.UlemperSystemene som er del av slike programmer er typisk ganske modne, og det kan være relativt utfordrende.I motsetning til opplæringsløsninger og CTF’er er man aldri sikker på om det faktisk er en sårbarhet å finne i den delen av løsningen man pirker på.Man må være den første som rapporterer en gitt sårbarhet i en løsning for å bli premiert direkte. Det er likevel tilfredsstillende å finne.Programmene krever typisk en form for proof-of-concept-angrep som beviser sårbarheten. Avhengig av sårbarheten kan det være omfattende å lage. Se hacktivity for eksempler.Online trainingFlere leverandører har opplegg for guidet selvopplæring i applikasjonssikkerhet. SpareBank 1 Utvikling har foreløpig ikke valgt å gå for en slik løsning, men det kan være det passer utviklingsorganisasjoner bedre. Av de jeg har prøvd selv, virker Adversary som en av de mer komplette. Du kan teste dem selv, med denne gjennomgangen av en feil i autorisasjonskontrollen Facebook hadde i 2018.Portswigger Academy er gratis, og har også noen gode labs det er verdt å ta en kikk på.FordelerLav terskel for å komme i gang.Dekker typisk bredt.UlemperNoe varierende kvalitet og forvirrende plattformer.VerktøySkal man eksperimentere med websikkerhet er det veldig nyttig å bruke en webproxy, som lar en se og endre på trafikken mellom nettleser og server. Noen alternativer:Burp Suite. Industristandarden. Koster litt i full utgave. Verdens eneste fungerende Java Swing-applikasjon!OWASP ZAP. Gratis, open source. Den andre Java Swing-applikasjonen.Charles proxy. Populært på Mac.Fiddler. Populært på Windows.Burp i aksjon. Hva skjer om jeg endrer det som ser ut som en konto-ID, og sender requesten på nytt? Det er enkelt å finne ut med slike verktøy.Heldigvis går de fleste seriøse webløsninger over TLS (https), men det betyr også at webproxyen til å terminere TLS-forbindelsen. For å unngå at nettleseren (med rette) protesterer på sertifikatfeil, forutsetter det at man setter opp nettleseren sin til å stole på CA-sertifikatet som proxyen har generert. De forskjellige proxyleverandørene forklarer hvordan man går fram for å gjøre det, men et konkret tips er å bruke en dedikert nettleser, så slipper man å sende all legitim trafikk gjennom proxyen når man ikke tester. Firefox har sitt eget oppsett av både proxy og sertifikater, mens andre i større grad baserer seg på globale systeminnstillinger.OppsummeringHer var det mye å velge mellom, selv om det ikke er en utfyllende liste. Mange av tilnærmingene utfyller hverandre på en god måte, men hvor skal man begynne? Det kommer mye an på hvor mye man føler man kan, men en mulig rekkefølge å iterere over kan være:Om du kan, dra på Hack yourself first. Den har blitt holdt flere ganger i -Norge, for eksempel på NDC Security i Oslo.Online training om noen tema, enten i de dedikerte løsningene foreslått over, eller på Pluralsight.Når man er klar til å eksperimentere litt selv kan må gå over på NATAS eller KWASHC.Bugbounties er supert når man er klar til å eksperimentere på virkelige systemer!Happy hacking!https://medium.com/media/ccf1ae94a5427c2c844a32ed831b1262/hrefEr du utvikler? Gratulerer med sikkerhetsjobben! was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Jon Are Rakvåg

Ikke jobb mens jeg forstyrrer!

Våren 2015 var jeg på vei til å bli utbrent.Vi hadde laget ny nettbankplattform som stadig flere av teamene våre tok i bruk. Samtidig var ikke plattformen ferdig. Det var kode vi måtte forbedre, samtidig som nye krav dukket opp.Selv om mye var likt den gamle plattformen, var også mye annerledes. Teamene trengte hjelp til å forstå detaljene. Det gjorde at utviklingsarbeidet stadig ble avbrutt av pirk på skulderen, meldinger, eposter og møter.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?Foto: Getty ImagesAvbruddene gjorde at vi følte at vi fikk gjort svært lite. Situasjonen var uholdbar. Samtidig visste vi at flere av avbruddene var verdifulle for systemet som helhet: Hvorfor skulle folk bruke tid på å finne ut av hvordan detaljene fungerte, eller regne ut hva som ville være beste tilnærming til en ny utfordring i den nye arkitekturen, når vi ofte satt med svaret?I SpareBank 1 Utvikling bruker vi ofte A3-metoden når vi har vanskelige problemer vi skal løse. Vi valgte å kjøre en A3 på avbruddsproblemet. Hvordan kunne vi hjelpe de rundt oss, og samtidig gjøre utvikling på en bærekraftig måte?Hvorfor er avbrudd så krevende for utviklere?Dette er et lurespørsmål.Avbrudd er ikke spesielt krevende for utviklere. Avbrudd er spesielt krevende for alle som driver med problemløsning.Alle som jobber med problemløsning bygger mentale modeller av problemdomenet i hodet. Disse modellene har flere abstraksjonsnivåer, som en må ha i hodet samtidig for å klare å resonere rundt problemet, og forhåpentligvis også nærme seg en løsning.https://www.monkeyuser.com/assets/images/2018/79-focus.pngAvbrudd som omhandler andre tema enn akkurat det en jobber med, river ned den mentale modellen. Den må bygges opp igjen, før en kan fortsette med arbeidsoppgaven. Denne kontekstbyttingen er mentalt krevende, og den tar tid. I arbeidet med A3-en, målte vi på de forskjellige typene avbrudd, og lengden på dem. Vi fant forskjellig byttekost for forskjellige typer avbrudd, med i snitt tre minutter for chat, opp til femten minutter for møter.Hvis det i tillegg er systemutvikling en driver med, og en er midt i en debuggingssesjon for å forstå mer av problemdomenet, så kan byttekosten gå vesentlig opp, siden en i tillegg til å bygge opp den mentale modellen igjen, også må få systemet tilbake i tilstanden en var i, som før en ble avbrutt.Alle har en begrenset mengde kognitiv kapasitet, som vi kan bruke av hver dag. Gjennom dagen blir den brukt opp. Avbruddene, og tiden det tar å komme seg tilbake til oppgaven en holdt på med, spiser av denne kapasiteten.Forskjellige typer avbruddVi så at vi trengte håndtere avbruddene forskjellig. Vi har delt dem inn i fire typer: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?”Ta tilbake kontrollen over tiden dinEn fin dag for en leder. En trist dag for en utvikler.For mange prosjekt- eller teamledere er kalenderen over en drømmedag.For en utvikler er denne dagen ødelagt før den har begynt. Hun vet at med denne kalenderen kommer hun nesten ikke til å få gjort noe som helst:Hun kommer på jobb åtte-halv niSjekker epost, Slack og nye Pull RequesterRekker akkurat starte på utviklingsoppgaven før retroenForbereder seg litt til retroenGjennomfører retroenGjør litt etterarbeid etter retroenRekker kanskje akkurat komme igang igjen med utviklingen før hun skal spise lunsj i elleve-halv tolv tidenKommer tilbake fra lunsj og sjekker epost, Slack og nye Pull RequesterRekker akkurat komme igang igjen med utviklingen før hun må forberede seg litt til workshopenGjennomfører workshopenLitt etterarbeid etter workshopenRekker kanskje fortsette litt på utviklingsoppgaven før hun går hjem i fire-halv fem tidenMer sannsynlig er hun såpass sliten etter totimers workshop, at det heller blir en ekstra kaffekopp og en ny sjekk av epost og Slack før hun går hjem igjen, frustrert over nesten ikke å ha produsert noen ting på en hel dag.Paul Graham har skrevet en fantastisk artikkel om disse utfordringene. Den heter Maker’s Schedule, Manager’s Schedule.Slik kunne vi ikke ha det.Løsningen for oss ble å innføre en fast blokk i kalenderen hver dag:Fast blokk i kalenderen hver dag for å kunne jobbe effektivtVi kan nå bare kalles inn til møter fra 13 og utover. Med denne blokken i kalenderen har vi fått tilbake kontrollen over vår egen tid. Folk kan velge å kalle oss inn til møter også mellom åtte og 13, men da er det vi som bestemmer om vi skal prioritere møtet eller ikke. Er det et viktig møte, ber vi som oftest om at møtet flyttes til etter 13.Når på dagen bør en ha møter?Vi har valgt å blokke ut første del av dagen, fordi det er da vi er mest opplagt og jobber best. Det er da det er viktigst å ha sammenhengende tid til å drive med utvikling for oss. Noen jobber best på kveld og natt, men for oss er det de første timene av arbeidsdagen som gjelder.Møter som krever høy grad av interaksjon og meddeltakelse bør legges så tidlig på ettermiddagen som mulig. Møter som er av typen informasjonsmøter, for eksempel allmøter og demoer, kan gjerne legges mot slutten av dagen.Hvordan vi har håndtert de andre avbruddstypene går vi nærmere inn på i del to av denne bloggposten, som kommer snart.Takk til Børge Lund for hans humoristiske betraktninger rundt dette temaet, og for tittelen til denne artikkelen.Ikke jobb mens jeg forstyrrer! 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

Vaner, uvaner og abonnement

Hvor mange har ikke inngått et abonnement, bare for innse at det etter kort tid gir deg dårlig økonomi og samvittighet? Selv den mest viljesterke har vel inngått et treningsabonnement i januar for så å bli et passivt støttemedlem, som sørger for at de få som holder ut gjennom året, opplever blanke speil, skinnende vekter og dundrende musikk. Dette er historien om hvordan vi i SpareBank 1 bruker maskinlæring for å hjelpe kundene våre til å få oversikt over abonnementene sine.Men la oss starte fra begynnelsen. I SpareBank 1 bruker vi maskinlæring for å klassifisere banktransaksjoner. Vi ser på om du f.eks har vært i matbutikken, eller om du har vært på kafé. Tanken er at du med et filter kan få oversikt over hvor mye du bruker på f.eks mat i måneden, eller hvor mye du bruker på moro og fjas. Det vi derimot manglet, var et filter for faste utgifter og abonnement. Mange kunder har større nytte av å kunne kategorisere hva som er faste utgifter og ikke, eller rett og slett få oversikt over hvilke abonnement en har. I tillegg inngikk vi en avtale med en tredjepartsleverandør om abonnementshåndtering. Denne tredjeparten tilbyr kansellering av abonnement og endring av abonnement (f.eks endring til et billigere mobilabonnement med de samme vilkårene).Som så mange andre modeller, fikk vår første modell en høy bias (partiskhet). Den fungerte veldig godt for de som lagde modellen. Kort fortalt ble det en regex lignende modell som sa at Netflix-, HBO- og Spotify-transaksjonene dine er abonnement. Vi fikk forsåvidt gode tilbakemeldinger fra våre kolleger da de også stort sett kun har en eller flere av disse 3. Alt så rosenrødt ut og vi kunne sole oss i glansen og flotte oss med vanskelige maskinlæringutrykk for å fremheve vår egen fortreffelighet.Alle elsker NetflixHvor mange forskjellige abonnement tror du kundene til SpareBank 1 har? Jeg kan gi deg et hint: vi har rundt en million kunder. Og jeg skal gi deg enda et hint: svaret er større enn 3. For det viste seg ganske fort at det finnes mange abonnement. Mange, mange abonnement…Det var bare en ting å gjøre, brette opp ermene.For å forstå løsningen må man skjønne problemet. Klientene våre sitter på transaksjoner som spenner over flere måneder og år. Transaksjonene har begrenset informasjon, men vi valgte å benytte oss av dato, beløp, transaksjonskode (unik kode som spesifiserer hva slags type transaksjon det er) og transaksjonstekst.Eksempel på transaksjonMaskinlæringsalgoritmene trenger tall for å fungere, så det første steget er vektorisering. Som så mange andre bruker vi Pandas for å lese og manipulere store datasett.DatoDet første vi gjør, er å endre dato til dag i måneden (i eksemplet blir 22.12.2019 til 22) for så å bruke sci-kit learns StandardScaler på den. Rammeverket beregner gjennomsnittet og variansen for oss, basert på hele treningsdatasettet. Da kan vi senere (når vi skal beregne nye abonnement) vektorisere ved å bruke ligningen under.Standardscalerens ligningBeløpDen neste featuren (egenskapen) er beløp, som vi bruker sci-kit learns RobustScaler på. Grunnen er at vi har noen veldig store beløp som gjør at denne fungerer bedre enn Standardscaleren.Men hvorfor gjør vi om tall til tall, jeg sa jo nettopp at maskinlæringsalgoritmene trenger tall for å fungere? Forklaringen ligger i at tallene bør være i noenlunde samme størrelsesorden og at de bør ligge over og under 0 for å fungere optimalt. Tenk på dag i måneden. Her har vi: Min(dag_i_mnd) = 1 og Max(dag_i_mnd) = 31.Hva med beløpet? Siden vi har alt fra lønnstransaksjoner og boligsalg til store innkjøp kan Min(beløp)=mange hundre tusen i minus og Max(beløp)=mange hundre tusen i pluss. Dag i måneden og beløp er altså på helt forskjellige skalaer når det gjelder nominelle tall. Ved å normalisere de, får vi begge featurene rundt null og på samme skala.TranskasjonskodeTransaksjonskodene er av type kategori (categorical features) og bør one-hot-encodes. I praksis har vi noen hundre transaksjonstyper i bruk og hver transaksjon vektoriseres da til ca. 200 dimensjoner, der 1 dimensjon har lengde 1 og de øvrige har lengde 0.La meg forklare med et litt enklere eksempel. La oss si at vi har 3 transaksjonskoder (i stedet for 200): R_013 (Lønn), R_714 (Visakjøp) og R_718 (Minibank). En transaksjon har en av disse 3, men aldri flere. “Vanlig” normalisering gir ingen mening her. R_718 er på ingen måte “større enn” R_714, på samme måte som at R_710 ikke er “mindre enn” R_714. Det er bare forskjellige transaksjonskoder som er tilfeldig nummerert og som har forskjellig mening.Eksempel på one-hot-encodingTransaksjonstekstTransaksjonsteksten er den siste og kanskje vanskeligste. Det finnes mange måter å represente tekst på, men vi har valgt å gå for word embeddinger ved bruk av fastText. fastText er et rammeverk fra Facebook som gir oss 100-dimensjonale word embeddings. Hvert unike ord er altså representert ved 100 floats og vi vektoriserer opp til 7 ord per transaksjonstekst. Dette kan virke merkelig, men disse embeddingene har visse egenskaper som vi benytter oss av. Syntaktisk og semantisk like ord vil f.eks ligge nære hverandre i vektorrommet. Vi benytter transfer learning når vi trener våre egne word embeddinger (vi baserer oss på pre-trente embeddinger fra Language Technology Group).Til sammen gir dette oss en 902 dimensjonal feature vector:Når disse featurene er vektorisert, clustrer vi de ved hjelp av dbscan. dbscan er en unsupervised clustringsalgoritme som er flink til å finne clustre med lik tetthet og tilfeldig form. Det viktigste argumentet til dbscan er epsilon og min_samples. min_samples bestemmer hvor mange punkter som minst må være innenfor epsilon avstand fra hverandre for å kalles kjerneelementer. Oppfyller man dette kriteriet har man et cluster. Når man har dette minimumet av kjerneelementer, kan man se på grenseelementer som må være innenfor epsilon avstand fra minst et kjernepunkt. Disse vil også bli medlemmer av clusteret. Vi hadde størst suksess med en epsilon rundt 0.3 og min_samples ≥ 3 når vi skulle finne de faste utgiftene. Altså, minst 3 punkter som er innenfor 0.3 avstand fra hverandre + et tilfeldig antall grenseelementer som er innenfor 0.3 avstand fra minst et av disse kjernepunktene.1,2 og 3 er mindre enn epsilon avstand fra hverandre og er derfor kjerneelementer. 4 er kun mindre enn epsilon avstand fra 2 og kalles da et grenseelement. 5 er mer enn epsilon avstand fra alle og kalles støy.Et par observasjoner (hopp over disse hvis du synes dette avsnittet var vanskelig).Vi benytter euclidian distance i clustringen. Det finnes flere måter å måle avstand på (se scipy spatial distance), men det viste seg at euclidian distance ga best resultat. Med word embeddings benytter vi oss ofte av cosine similarity, for å finne likheter mellom ord. Hvordan passer dette inn med euclidian clustring? Løsningen ligger blant annet i det som kalles monotonic transformations. Når cosine similarity øker, minsker euclidian distance (når unit vector length er lik), altså akkurat det vi ønsker. Den komplette forklaringen er mer kompleks og krever en egen bloggpost.Et annet punkt er at dag i måneden gir månedlige abonnement. Vi har også kvartalsvise, halvårs og årsabonnement, løst ved å lage en ekstra feature basert på modulusfunksjoner.Du kan også oppleve noen problemer ved å bruke dag i måneden i månedslutten hvis du får helg/helligdag på en sen dato.Den siste utfordringen er at du vil ha markert Netflix abonnementet ditt allerede den første måneden du får opp transaksjonen, ikke vente til du har 3 Netflix transaksjoner. Hvordan dette ble løst ligger utenfor scopet til denne bloggen, men ta gjerne kontakt så deler vi gjerne.ResultaterHer er et typisk mobilabonnement. Kunden har variable summer (brukt mer mobildata f.eks) og variable datoer (lørdag-/søndag-/helligdag-problematikk, bankene prosesserer ikke betalingen til abonnementet før første bankdag). Ved å ha en passe epsilon under clustringen vil disse variasjonene være små nok til å bli naboer i det 902 dimensjonale vektorrommet.Et annet problem vi hadde med vår første regex versjon, er de firmaene som både har abonnement og selger enkeltprodukter. Et eksempel er Viaplay, en strømmetjeneste som har både abonnement og muligheten for å leie enkeltfilmer. I dette tilfellet markerer clustringen kun de som faktisk er abonnementer (markert som grønne).Ikke alle abonnement kan finnes med regex’er. Mange bedrifter bruker kundenummer og faktureringsnummer som transaksjonstekst.Noen bedrifter endrer transaksjonsteksten fra måned til måned.Noen ganger er navneendringene store. Hvordan er det mulig for algoritmen å skjønne at CanalDigital plutselig heter Telenor? I vanlig språk er god, bra og fantastisk semantisk like ord. På samme måte viser våre word embeddinger at CanalDigital er det ordet som er mest likt Telenor.Disse eksemplene er noen få eksempler på hvordan algoritmen fungerer. De viser dog ikke det store volumet vi fant. Hos kundene våre finner vi hundrevis, om ikke tusenvis av abonnement. Det er alt fra aviser og treningssentre til datingtjenester og japanske tegneserier. Det er norske, amerikanske, polske og rumenske abonnement. Abonnement som du nå kan filtrere og håndtere i SpareBank 1 sin mobilbank.Vaner, uvaner og abonnement was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Inge Johnsen

“Ikke nok et jævla statusmøte!”

Vi ville for mye, og fant oss selv i det ene statusmøtet etter det andre. Backloggen økte for hver eneste dag, men målene var like langt unna. Vi måtte endre måten vi jobbet på — og det fort!Seks måneder tidligere: Team Oversikt — et av utviklingsteamene som lager mobilbanken til SpareBank 1 hadde såvidt begynt å jobbe med OKR’er, og alle var begeistret over å endre fokus fra oppgaver til mål. Ved inngangen av kvartalet hadde vi samlet hele teamet, og hamret ut våre “objectives”. Vi satte noen få, ambisiøse “key results”, som føltes akkurat passe komfortable å sikte mot. Alt etter boken. Vi oppdaterte Trello, syncet med Jira og Slack, kalte inn til regelmessige backlogmøter, teammøter og stand ups.Noe gikk galt på veien…Kvartalet var over, alle hadde gjort sitt beste. Vi hadde riktignok nådd et par av målene, men vi var milevis fra andre. Noen hadde vi ikke jobbet med i det hele tatt. Vi klarte ikke å holde fokus gjennom kvartalet, og teamet var lei av hyppige koordineringsmøter. Det var ingen tvil om at OKRer var riktig for oss, men vi måtte finne en mer effektiv måte å jobbe med de på.Monday commitments and friday winsInspirasjon fant vi hos den amerikanske forfatteren Christina Wodtke. I boken ‘Radical Focus” beskriver hun en elegant og enkel måte å sikre fokus på de riktige tingene, samtidig som man tar vare på kvaliteten, teamet og kunden. Essensen er at det du gjør hver dag, må ha en direkte kobling til de målene du har satt deg. Det så ut til å være akkurat hva vi trengte.Bilde: OKR eksempel fra Radical FocusVi skisset opp den nye tavla,og erstattet møtene våre med monday commitments, og friday wins:Monday commitments kickstarter uken. Hele teamet er samlet foran tavla. “Hvordan ligger vi an i forhold til målene vi har satt oss” og “hva må vi ha fokus på denne uken for å nå målet?” Vi blir enige om de viktigste oppgavene og det er kun de som havner på tavla. Dette er de oppgavene vi forplikter oss til i felleskap, og som vi strekker oss for å levere innen fredag. Vi har satt av 15 minutter til møtet.Fridays wins er for vinnere, og handler om å feire hva vi har fått til og dele hva vi har lært. Vi setter av minst 30 min i kalenderen, og setter oss i kaffekroken. Helst har noen på teamet bakt eller kjøpt med noe godt å spise. Resultatet er alltid stolthet over det vi har fått til sammen. Og her skal alt frem — det er mye som fortjener oppmerksomhet, uten at det nødvendigvis har flyttet nøkkeltall.“You don’t have to do it perfectly, but you do have to commit!”- Christina WodtkeMandag 6 uker senereDet er stort engasjement fra hele teamet. Tallene fra forrige uke er kommet opp på tavla, og alle har ideer til hvordan vi skal komme enda nærmere målet. Nye kamper skal kjempes — og vinnes. Vi gjør en team-helsesjekk, og scorer 4,7 av 5 på spørsmål om det er tydelig for alle hvilke mål de jobber mot.Ved å endre måten vi jobber på har vi fått en sterkere kobling mellom de aktivitetene vi gjør hver dag og målene vi har satt oss. Radikalt fokus gir energi til teamet og bygger kultur og samhold. Og de jævla statusmøtene? De er ikke lenger en kilde til frustrasjon, men noe som gir teamet økt fokus og energi. Og når vi lykkes, feirer vi alle seire sammen!Skrevet av:Marthe SlaatsveenThomas Allan NygaardReferanser:Christina Wodtke (2015) Radical Focus. Cucina Media, LLCJohn Doerr (2018) Measure what matters. PortfolioLes mer…om hvordan egen fagdag radikalt forbedret tilfredsheten i organisasjonenhttps://medium.com/sparebank1-digital/torsdag-er-den-nye-l%C3%B8rdagen-f547e55aadd3og Endelig et statusmøte vi utviklere liker“Ikke nok et jævla statusmøte!” was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Thomas Allan Nygaard

Velkommen til Bankbokklubben

En hel klokketime dedikert til et spennende tema, med ivrig diskusjon blant vennlige og motiverte folk på søken etter innsikt og læring, i kombinasjon med en god kopp kaffe. Kan man egentlig starte dagen på en bedre måte?Hver onsdag morgen møtes Bankbokklubben i SpareBank 1 Utvikling på en kafe i nærheten av kontoret for å prate om det siste kapittelet i en bok vi leser sammen. Hvorfor gjør vi dette?Formålet med klubben er læring med en felles rytme gjennom fordypning i utvalgte bøker innen vårt interessefelt. Fremgangsmåten følger gjerne et slikt mønster:Gruppen blir enige om valg av ny bok. Kandidatlisten inneholder som regel en rekke godbiter, og det smerter å måtte velge bort de fleste.En avtalt del av boken leses på egenhånd, f. eks. et kapittel eller to.På det ukentlige klubbmøtet diskuteres hovedpunktene i kapittelet. Hva betyr dette for oss i SpareBank 1 Utvikling, og hvordan kan vi teste ut elementer vi har lyst til å undersøke nærmere?Rett som det er gjennomfører vi små eksperimenter og diskutere betydningen av funnene.Bankbokklubben i SpareBank 1 Utvikling tar en pause i diskusjonen av hva boken Deep Work byr på av innsikt, muligheter og utfordringer.Hvorfor fungerer dette for oss?Vi jobber med utrolig mange flinke folk, og det er interessant og nyttig med bredden i perspektiv dette skaper.Man kommer dypere i materialet gjennom diskusjon og repetisjon.Innsatsen som legges ned gjøres overkommelig ved å dele opp en bok i mindre bolker.Det blir enklere å lese ved en positiv forpliktelse i det å møtes for å jobbe videre med materialet sammen.Man kommer i kontakt med interessante temaer og tilegner seg innsikt man trolig ellers ikke ville oppnådd på egenhånd.Vi pleier en felles interesse i det å fordype seg i fag og læring innen vårt fagområde.Det er hyggelig å være sammen. Vi styrker samholdet i gruppa og lærer hverandre å kjenne enda bedre. Dette skjer på tvers av grupperingene vi jobber mest i.Med mange sterke kandidater er nåløyet trangt for å bli valgt som felles bok i Bankbokklubben.Bankbokklubbens opprinnelse kan spores tilbake til da det interne utviklingsmiljøet i selskapet ble etablert. I løpet av denne perioden ble en lesesirkel benyttet for å gå gjennom og jobbe med innholdet i boken The Toyota Way. Hver enkelt leste først et kapittel for seg, som så ble diskutert i gruppen med fokus på hva innholdet betydde for miljøet vårt. Dette skapte en felles plattform, og ga mye energi, til arbeidet med hvordan arbeidsprosesser og -miljø ble etablert og videreutviklet. Da siste kapittel var avsluttet, og boken lagt til side, var det flere oss som kjente på den samme følelsen. Den positive dynamikken fra lesesirkelen ville vi svært gjerne beholde. Dermed gikk det ikke lang tid før Bankbokklubben var etablert.Her er et utvalgt av våre favorittbøker:Culture codeThis is LeanLoonshotsAccelerateGood to GreatLean EnterpriseThe Phoenix ProjectFor tiden leser klubben boken Deep Work og diskuterer ting som: Hva er et godt mønster for bruk av tiden vår, for hver enkelt og for gruppene man er del av? Hva er gode strategier for å oppnå en slik tilstand for kunnskapsarbeidere? Hvordan bør vi måle bruk av egen tid, og hvilke eksperimenter kan vi enkelt gjennomføre for å etablere data og innsikt?Plutselig er en time over. Tiden formelig fløy avgårde, og vi er klare for å gyve løs på resten av dagen. Vel vitende om at nok et spennende kapittel venter for Bankbokklubbens medlemmer i uken som kommer.Velkommen til Bankbokklubben 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

Utvikleravdelingen er død! Lenge leve utvikleravdelingen!

Vi har vært på reisen med kryssfunksjonelle team hver dag siden 2014. Vi jobber så svetten siler med å gi teamene våre best mulig forutsetninger for å løse oppgavene sine.Plutselig en dag oppdaget vi at vi hadde kastet ut babyen med badevannet. Vi hadde optimalisert vekk utviklerkulturen vår.Hva var det egentlig som hadde skjedd?Foto fra BigStockBakteppetVi kan takke Frederick Taylor (1856–1915) for mye. Han populariserte standardisering av arbeidsmetoder. Dette gav oss massiv økning i produksjonsvolum for fabrikker over hele verden. Med på lasset fikk vi også med oss ledelsesprinsipper for å maksimalisere effektiviteten:Finn beste måte å gjøre en oppgave påDokumenter beste måte å gjøre oppgaven påTren opp medarbeiderne til å gjøre oppgavene på beste måteLedere og medarbeidere deler ansvaret for løsning av oppgavene. Lederne skal løse oppgavene de er bedre egnet til, heller enn medarbeiderneEn av utfordringene med disse, er at de har større fokus på å optimalisere enkeltroller heller enn systemet. I tillegg er ledelsesprinsippene er ofte blitt mistolket, eller brukt i feil kontekst. Mange mistolker dem fortsatt, over hundre år etterpå:en bruker rammeverket på arbeidsoppgaver det aldri var ment for å løseen ser bort i fra de kontinuerlige treningsaspektet, dvs. dropper kontinuerlig forbedringTa dette og bland det med tradisjonell avdelingsorganisering i underavdelinger som hver for seg er optimalisert for å være så effektive som mulig, dvs at alle i avdelingen til en hver tid jobber opp mot 100 prosent kapasitet, så har vi en standard bedrift. Deler av utfordringene med tradisjonell avdelingsorganisering har vi også erfart i SpareBank 1 IT.Avdelingsdrevet utviklingVi hadde konseptavdeling, arkitektavdeling, prosjektavdeling, forvaltningsavdeling og driftsavdeling. Nye løsninger ble tatt fram i midlertidige prosjektteam, hvor utviklere var leid inn kun med tanke på å utvikle den ene løsningen. Arkitekter støttet opp om prosjektteamet. Arkitektenes utfordring var mange. De var gjerne booket opp i flere prosjekter samtidig , de var få, og de var fullt ut prosjektfinanisert. Dermed fikk de sjelden mulighet til å dykke dypt ned i utviklingen — de måtte løpe til neste prosjekt.Avdelinger med forskjellige mål — et system optimalisert for konfliktNår løsningen var ferdig kodet og testet, ble den overlevert til forvaltningsteamet. Dette tok gjerne flere uker, siden koden sjelden var i henhold til standard, og måtte rettes og retestes før handoveren ble godkjent.Denne måten å jobbe på førte til lav tillit mellom avdelingene, og fremmedgjøring for de som jobbet i dem med de aktuelle løsningene.Mikrotjenestene gav oss teamSom så mange andre, hadde også vi en stor monolitt som alle de nye løsningene ble merget inn i. Vi fikk større og større utfordringer med å levere i monolitten, og dette medførte at vi startet et arkitekturprosjekt i 2012 for å bryte den opp i flere mindre tjenester — la oss kalle dem mikrotjenester. Da vi gjorde dette, bestemte vi oss for å bruke verdikjedeinngangen for å finne fornuftige deler å dele monolitten opp i. Da ble det også naturlig å lage team rundt verdikjedene. Dette var starten på de kryssfunksjonelle teamene våre. Med stabile team organisert rundt verdikjedene, fant vi svar på mange av utfordringene vi hadde hatt med den avdelingsdrevne utviklingen.Egne utviklereVi hadde hatt 100 prosent konsulentdrevet utvikling fram til 2012. Vi startet reisen med egne utviklere omtrent samtidig som vi startet reisen med microtjenester. I starten var vi totalt omtrent 50 personer som jobbet sammen i et fåtall team og omtrent ti av oss var ansatte utviklere og testere. Vi jobbet sammen, og hadde hyppige avdelingsmøter sammen.Entusiasmen var høy. I tillegg til å få en mer moderne arkitektur, hadde vi skapt oss et rammeverk som gjorde at vi kunne skalere opp til å støtte flere verdikjeder — og dermed også flere team. Det gjorde vi. I 2017 var vi blitt 15 team.Samtidig hadde vi ikke evnet å rekruttere egne utviklere i et like høyt tempo. i 2017 var vi gått fra omtrent 10 til omtrent 25 fast ansatte utviklere. Brorparten av skaleringen var gjort med konsulenter.OppsigelserI løpet av seks måneder vinteren 2017–2018 sa seks av utviklerne våre opp.Hva var det som hadde skjedd?Det viste seg at vi hadde jobbet så mye med å skape optimale arbeidsforhold for de kryssfunksjonelle teamene våre, at vi hadde kastet ut babyen med badevannet.I reisen fra et fåtall til da 15 team, ble utviklerne våre spredd tynnere og tynnere utover teamene. Med 25 utviklere på 15 team, så vil de fleste utviklerne enten være ensom som fast ansatt utvikler på teamet sitt, eller i beste fall har en utviklerkollega til i teamet. Den gangen vi var 10 stykker og et fåtall team, så vi hverandre og delte kaffemaskin hver dag. I 2017 var vi blitt 15 team spredd over tre etasjer. Vi traff ikke hverandre lenger. Utviklerkulturen vår var blitt anonym. Tilhørigheten var borte.Utviklerne går sammenOppsigelsene gav oss en skikkelig vekker. Sluttsamtalene var entydige. De som sluttet, følte liten tilhørighet til SpareBank 1 og var ikke fornøyd med den faglige utviklingen sin.Sommeren og høsten 2018 la vi opp til en rekke grep for å snu dette helt om. Vi ville skape et skikkelig bra fagmiljø med mye sosial trygghet og mye humør. Et sted det er godt å være.Vi gjorde to fundamentale grep:Vi satte opp utviklerne som en egen fagavdeling. Vi hadde tidligere vært organisert sammen med flere andre disiplinerVi innførte ukentlig fagdag. Du kan lese mer om fagdagen vår herFagavdelinger + kryssfunksjonelle team = santFor å bygge sosial trygghet og sosial tilhørighet i en hverdag hvor en jobber i kryssfunksjonelle team, er fagavdelingene våre blitt viktigere enn noen gang. I fagavdelingen har vi et fast møtepunkt. Der bygger vi kulturen vår, jobber sammen og blir bedre utviklere sammen. Vi mener dette er så viktig at vi bruker en hel dag hver uke på dette. Dette gir oss muligheten til å jobbe sammen på arkitekturutfordringer, ta kurs sammen, jobbe aktivt med blogg- og konferanseinnlegg, og jobbe med personal, rekrutterings- og brandingsaktiviteter. Ved å være sammen og jobbe sammen med disse aktivitetene, skaper vi også sosial tilhørighet og trygghet. Vi skaper utviklerkulturen vår.Fra standen vår på JavaZone.Faggruppene våreI tillegg til det strategiske kompetansearbeidet som foregår i fagavdelingene, gjør vi taktisk og operativt kompetansearbeid i faggruppene våre. Her er også konsulentene med, og de går gjerne på tvers av fagavdelinger. Vi har faggrupper for en rekke fagområder. Eksempler er teamledelse, applikasjonsarkitektur og sikkerhet.Shift left holder ikkeShift left er en trend som peker på at en skal flytte en rekke aktiviteter som tidligere typisk dukket opp sent i utviklingsprosessen, for eksempel test og sikkerhetsarbeid, tidligere i prosessen. Vi mener at dette på langt nær er nok for å skape en effektiv utviklingsprosess.Du skal ikke bare “shift left” — du skal “rotate left”. Du skal bevege deg fra en horisonal avdelingsstruktur med handovers og ressursoptimalisering, til en vertikal verdikjedeorientert struktur, med kryssfunksjonelle team som jobber flytoptimalisert.Vi må dyrke kulturen og den faglige tilhørigheten. Dette gjør vi i fagavdelingene og faggruppene våre. Samtidig er det i verdikjedene forretningsverdiene skapes. Da er de vi må optimalisere, og i de vi må jobbe.Synes du dette var interessant, så pratet Jostein Emmerhoff og jeg mye mer om dette teamet på JavaZone 2019. Foredraget finner du her.Utvikleravdelingen er død! Lenge leve utvikleravdelingen! 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

Monorepo med Git och Maven: så fick vi det till!

I SpareBank1 Utvikling har vi tagit i bruk ett monorepo för vår nya generation med appar i digitalbanken. Vi har utgått från verktyg som vi känner gott från tidigare: Git, Maven och Jenkins. Detta är verktyg som i stor grad är mer tillpassade får multirepo än monorepo.Vi har tagit fram ett exempel-githubrepo som visar hur vi har arbetat runt många av de utfordringarna som kommer särskilt från bruk av Maven och Jenkins. Repot visar också hur Bazel-byggsystemet kan användas som ett mer monorepo-native alternativ till Maven.Mer om monorepo kommer på JavaZone 2019: Monorepo med Git og Maven — hvordan lære gamle hunder ny triks, 11 september kl 13:00 i rum 2.Bild av StartupStockPhotos från PixabayMonorepo med Git och Maven: så fick vi det till! was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Jonas Nordstrand

Torsdag er den nye lørdagen

For en utvikler i SpareBank 1 Utvikling er hver torsdag dedikert til fag. Vi kaller det enkelt og greit Fagdag. Denne dagen brukes til å ta kurs, teste ut nye teknologier, lage helt nye løsninger eller gjøre forbedringer på felles kode.Vi ønsker å dele det vi jobber med. Derfor bruker vi også Fagdagen til å lage artikler som denne, og til å forberede foredrag.Som utvikler i SpareBank 1 er du medlem av et kryssfunksjonelt team. Organisatorisk og faglig er du en del av Utvikleravdelingen. Utviklere, testere og designere jobber sammen i de tverrfaglige teamene, men hver torsdag forlater utviklerne teamet sitt. Denne dagen finner utviklerne sammen for å jobbe med fag. Vi forsøker på denne må å skape en felles utviklerkultur i SpareBank 1 Utvikling.Utvikling kan være så mangt! Her presenteres Hjernebank 1Kultur spiser strategi til frokostPeter Drucker skal ha sagt at “Culture eats strategy for breakfast”. Kort fortalt mente Drucker at kultur alltid vil vinne over struktur. Vi trenger struktur, men kulturen må underbygge strukturen. På QCon i mars var jeg på et foredrag med Randy Shoup. Han påstår at “Kultur spiser strategi og organisering og teknologi og prosess og … til frokost”.Vi tror på en kultur der deling, åpenhet og psykologisk trygghet er fundamentene. Med basis i denne kulturen bygger vi en organisasjon som støtter opp under disse verdiene. Når vi møtes hver torsdag er vi med på bygge denne kulturen. Vi deler kunnskap . Vi lærer og feiler sammen. Vi sosialiserer og vi blir bedre kjent. På denne måten blir vi tryggere på hverandre. Dette gjør det igjen enklere å kommunisere på tvers av teamene. Vi tror også at en god kultur gjør at våre dyktige utviklere ønsker å fortsette å være en del av SpareBank 1 over tid. Fakta er at siden vi startet med fagdagen har ingen utviklere avsluttet hos oss. Samtidig har vi blitt 13 nye utviklere i avdelingen.FlerkulturNår man har en kultur i teamet og en kultur i fagavdelingen, får man flerkulturelle utviklere. Om avstanden mellom “team-kultur” og “fag-kultur” er for stor, vil det kunne skape utfordringer. Resultatet kan bli at man ikke kjenner seg hjemme i fagavdelingen. Utvikleravdelingen i SpareBank 1 Utvikling er en ny avdeling. Når vi nå lager en felles kultur for denne avdelingen, må alle få være med å lage den. Fagdagen er en bra arena for dette. Vi har etablert to arbeidsgrupper. Den ene gruppen fokuserer på sosiale tiltak, mens den andre fokuserer på faglige tiltak. Dette har resultert i felles utflukter, middager og kodekata.Sterke fagmiljø kan også være en utfordring. I en matriseorganiasjon kan det bli konflikt mellom teamene og fagavdelingene. Teamene er tett på kunden og har fokus på levere løsninger på en effektiv måte. For at et team skal bli effektivt jobbes det hele tiden teamkulturen. Stabilitet er et viktig element for effektive team. Endrer man sammensettning av personer i et team viser forskning at det tar tid å bygge effektiviteten opp igjen. Mye av grunnen er at endringer av denne typen påvirker den psykologiske tryggheten i teamet. Denne tryggheten er ikke bare nødvendig for å være effektiv, men også for innvoasjon (Edmondson, 2008). På bakgrunn av dette er det derfor veldig viktig at teamene er tett innvolvert når fagavdelingen ansetter nye utviklere. Teamtilhørighet bør være avklart før ansettelsesprosessen starter og en representant fra teamet bør være med på intervjuene. På denne måten tror vi at vi skal klare å ansette utviklere som passer kulturen i både teamet og fagavdelingen.Snakk om kollegaFor å bli enda bedre kjent, har vi hver torsdag en quiz som vi kaller for Snakk om kollega. Alle har delt noen hemmeligheter med vår quiz master Jan Erik Modal. På bakgrunn av hemmelighetens vanskelighetsgrad får man poeng for riktig svar, og ikke minst minuspoeng om man svarer feil. Dette er en artig måte å bli kjent på og et fint avbrudd fra fagfokuset.Utviklerne gir tilbakeFor en leder er det ingen enkel avgjørelse å la utviklerne bruke 20% av sin tid utenfor teamet. Det er derfor viktig å vise resten av organisasjonen hva man gir tilbake. Vi har valgt å forløpende publisere alle aktiviteter som kommer fellesskapet til gode på en delt liste.Hva fagdagen brukes tilMålingFra første fagdag 13. desember i fjor, har vi målt tilfredshet med det sosiale og det faglige blant oss utviklere i SpareBank 1. Vi har brukt en skala fra 1 til 5, hvor 1 betyr svært lite tilfreds, og 5 betyr veldig tilfreds. Like før sommeren var det eksamen. Den ble gjennomført anonymt. Etter ett halvår med fagdag ønsket å måle hvor godt vi nå kjenner hverandre. Resultatet ble et gjennomsnitt på underkant av 80% riktige. Vi har dessverre ingen historiske resultater å måle mot. Vi vet derfor ikke om dette er et bra resultat, men magefølelsen tilsier at 80% riktige er bra.Utviklingen på bare 5 måneder har vært formidabel. Vi startet med en lite tilfredstillende måling i desember med en gjennomsnitlig tilferdshet på 2.41 for det sosiale, og 2.91 for det faglige. Utover vinteren og våren har gjennomsnittet beveget seg opp på 3 tallet, både for det faglige og det sosiale. Vår siste måling, utført 16. mai, ga oss 4.16 for det sosiale. En økning på hele 79%! Den faglige tilfredsheten ble målt til 4.37. En økning på imponerende 44%.Dette er tall vi er utrolig fornøyde med. Spesielt glad er vi for den høye scoren på det sosiale. Fagdagen må ta mye av æren for dette. Men også aktiviteter som vennegrupper og fagsamling med overnatting har hatt en innvirkning. Vennegruppene er en ren kopi av barneskolens opplegg, men i stedet for å hoppe på en trampoline sammen, så spiller vi dart eller spiser god mat.Veien videreFagdagen var er et halvårlig eksperiment. Det er nå besluttet at dette er en fast aktivitet, og at vi skal bruke en dag i uken på fag. Det faktum at vi ikke har noen turnover og at vi i år skal ha fire bidrag på JavaZone, har vært med på å gjøre det enklere å ta denne avgjørelsen.Synes du dette var interessant, så pratet jeg mye mer om dette teamet på JavaZone 2019. Foredraget finner du her.Anbefalt litteraturJeg elsker å lese om kultur og organisasjon, og hver onsdag morgen møtes bankbokklubben for en kaffe og en bokprat. Av de bøkene vi har lest det siste året vil jeg spesielt trekke frem disse:The Culture Code: The Secrets of Highly Successful Groups, Daniel CoyleLoonshots: How to Nurture the Crazy Ideas That Win Wars, Cure Diseases, and Transform Industries, Safi BahcallAccelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, Nicole Forsgren, Jez Humble, Gene KimTorsdag er den nye lørdagen was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Stian Conradsen

SpareBank 1 Utvikling skal prate på JavaZone

JavaZone 2019JavaZone er en av de store happeningene for oss i SpareBank 1 Utvikling. Dette er den største utviklerkonferansen i Nord-Europa, og er en fantastisk arena for å lære om alt det som foregår i industrien, fortelle om de spennende tingene vi jobber med hos oss, og ikke minst møte gamle kollegaer og treffe nye kjente.Jobbingen med JavaZone standen og foredrag, foregår nesten hele året hos oss. I år holder vi fire foredrag, og vi har en stand med aktiviteter hvor software og hardware i stor grad er hjemmelaget. Vi skal ikke røpe for mye av detaljene, men vi kan vel si at de som kommer bortom standen vår, skal få noe å tenke på.Her er foredragene vi skal holde på JavaZone i år:Torsdag er den nye lørdagen. Hvorfor bruker vi en dag i uken på fag?Stian ConradsenOnsdag 11. september, 1220, Rom 1Tordentale 20 minMonorepo med Git og Maven — hvordan lære gamle hunder nye triksAnders Gjendem og Jonas NordstrandOnsdag 11. september, 1300, Rom 2Presentasjon 45 minUtvikleravdelingen må dø! Lenge leve utvikleravdelingen!Jostein Emmerhoff og Vidar MoeOnsdag 11. september 1540, Rom 4Presentasjon 45 minHendelsesdrevet læring i SpareBank 1 — Erfaringer fra to år med post mortemKristoffer BergTorsdag 12. september 0900, Rom 1Lyntale 10 minVi har allerede delt av erfaringene våre fra to år med post mortem her på bloggen tidligere. I løpet av august slipper vi bloggposter som deler mer av det vi kommer til å prate om på JavaZone i år.Stemningsbilde fra JavaZoneSees i Oslo Spektrum fra 10. til 12. september. Dette blir gøy!SpareBank 1 Utvikling skal prate på JavaZone 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

Denne PSD2-datoen bør du kjenne til

Mye er sagt om PSD2 (eller betalingtjenestedirektivet som vi så kortfattet sier på norsk), men det er spesielt to datoer som har vært viktige.14. mars (i Norge ble dette april til slutt): Dagen alle skulle kunne teste løsningene bankene vil tilby til tredjeparter med konsesjon som betalingsforetak.14. september: Som tredje part skal du kunne hente ut informasjon fra banken på et vis som følger den tekniske spesifikasjonen for direktivet (den mye omtalte RTSen).Men ettersom tidslinjen for direktivet, og det som kalles “Søknad om fritak fra krav om reserveløsning for kontotilbyder (fallback)” har modnet i bankverdenen, har det dukket opp en ny dato. Denne er egentlig vel så viktig: 14. juni.Og hva er “Søknad om fritak fra krav om reserveløsning ….”? Dette er en søknad som bankene må sende til Finanstilsynet der de forteller om PSD2-løsningen sin, hvordan den er og hvordan den er blitt brukt. Dette skal forsikre om at den er god nok til at tredje partene kan stole på den, og ikke påberope seg retten til å bruke en annen løsning.Alternativet til en godkjent søknad kalles “fallback”. Med mindre banken ikke har en annen løsning implementert, vil tredje-part kunne bruke screen scraping som potensielt gir de tilgang til mer informasjon enn de har krav på under PSD2-direktivet.En forutsetning for søknaden er at du har hatt trafikk på PSD2-løsningen din, i minst 3 måneder før 14. september. Og vipps så kom datoen 14.juni opp!For resultatet av dette er jo at alle bankene vil måtte ha sin løsning i produksjon 14. juni, for å ha trafikk på den. Og det er da det hele egentlig begynner! For hvem vil vel være sist med å vise kontoer fra alle bankene i sine flater?Vi står nå klare med våre grensesnitt — og ønsker tredjeparter varmt velkommen. Frem til midten av juni gjør vi manuell innrullering av tredje parter. Så om du ønsker tilgang til våre grensesnitt er det bare å ta kontakt med meg på kristine.ursfjord@sparebank1.no.Se gjerne på portalen til en av våre banker for informasjon om tilgang f.eks. her.Denne PSD2-datoen bør du kjenne til was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Kristine Ursfjord

@sparebank1design og @sparebank1utvikler på Instagram