Dette blogginnlegget er skrevet for deg som lurer på hva Knowit gjør av smidig metodikk, forvaltning og utvikling, også kalt “Agile Devops”.
Heidi Hundåla er Senior prosjektleder hos Knowit Solutions
Jeg har intervjuet to gode kollegaer som jobber hos to av våre kunder som illustrerer hvordan “Agile Devops” fungerer i praksis.
Utviklingen av samfunnet i dag fører til stadig nye behov og ønsker om konstant forbedring av applikasjoner på nett og bedre sikkerhet. Knowit hjelper deg og din bedrift med å få dette til, men hvordan gjøres det i praksis?
Mange bedrifter velger skyteknologi for å dekke behovene sine. Med skyteknologi går utvikling til produksjon raskere. Utfordringer til drift, som for eksempel god ytelse ved økning i antall brukere, innkjøp av servere, “Single Sign-on” eller backup, slipper man å tenke på. Dette er typiske fordeler man får automatisk ved å velge en skyløsning for applikasjonene/tjenestene/produktene dine. Knowit kan bistå på alt av skyløsninger enten de kommer fra Azure, Google eller Amazon. Knowit satser på sky og utdanner et stort antall teknologer samtidig som flere jobber med dette i dag. Skyteknologi er ingen forutsetning for å levere smidig og kontinuerlig, men det gir en teknisk fordel i mange sammenhenger i dagens teknologimarked.
Smidig prosjektorganisering (Agile) handler om å få produsert én del av produktet, bit for bit, — til produktet fungerer bra i produksjon uten for mye planlegging (*).
Med “Devops” (**) får man ny funksjonalitet og forbedring raskere ut i produksjon fordi reelle brukere er viktige kilder til forbedring. De gir oss det vi trenger i utviklingsteamet.
Med “Agile Devops” organiseres teamet best mulig slik at vi virkelig minimerer tiden det tar fra en funksjonell forbedring er oppdaget til at den er i produksjon. Prosessen må med andre ord gi mulighet for rask tilbakemelding fra bruker til utvikler.
Utviklerne lærer fortløpende hvilke konsekvenser ny funksjonalitet og forbedringer får i produksjon og kan kontinuerlig forbedre sin egen kode og prosesser relatert til å få ut endringer (som f.eks. bedre automatiske tester) og gir derav brukerne det de vil ha før de blir lei av å vente, for eksempel bedre menyvalg eller at applikasjonen ikke virker i IE 11 (nettleser).
Med alle disse forutsetningene har vi mulighet for en effektiv organisasjon rundt applikasjonsutvikling og som er med på å øke “speed-to-market” (***).
Erfaringer med Agile Devops i bank
Per i dag har Knowit flere konsulenter i en større norsk bank hvor de har utviklet mange tjenester til rådgivere, service-senter og kunder. De driver med Agile Devops. Funksjonalitet flyttes fra en stor monolitt til uavhengige skytjenester i en lokal sky, som for eksempel søknad på forskjellige typer lån, søknad på kredittkort og regionsperre på kort. Disse tjenestene har blitt forenklet, automatisert og er programmert som løst koblede mikrotjenester. Organisasjonen av utviklingsteam speiler behovene til forretningssiden, hvor for eksempel forsikringsavdelingen og avdeling for daglig bank har hvert sitt team. Våre konsulenter jobber i kredittbank-teamet og jeg har snakket med teamleder der.
Smidig bank
I banken driver teamene med Scrum eller Kanban (****), men det varierer hvor autonome de er, da det spriker i erfaring og tverrfaglighet. Uten tverrfaglighet blir de avhengig av andre for å få sine leveranser i produksjon. Teamlederen fra Knowit sier de har tilgang til alle miljø og slipper venting på drift eller interessenter. De har frihet under ansvar.
Hele den tekniske strukturen i banken er tilrettelagt for at mange kan produksjonssette samtidig. Ingen springer i beina på hverandre. Provisjonering av nye applikasjoner og miljøer er automatisert. Applikasjoner i form av mikrotjenester er mindre spesialiserte enheter. Dette blir sett på som viktig for å kunne levere raskere. Tidshorisonten reduseres siden det er enklere å sette opp, dermed går hyppigheten opp. De er i dag på flere releaser i uken. Forsetter det slik, blir det daglige releaser.
Forretningssiden gir tilbakemelding til teamene om at de er veldig fornøyde med hastigheten det tar fra krav oppstår til de er ute i produksjon. Sammenlignet med før i tiden, med en vannfallslignende utviklingsprosess, ser de en stor forbedring i “speed-to-marked” i tiden det tar å få tjenestene levert ut i produksjon.
Utfordring
En utfordring de har er at de ikke følger Scrum-regelen på maks 9 på teamet. De har hatt et problem med at det ble altfor mange deltagere i ett team, noe som blant annet førte til at stand-up-møter ble til lange statusmøter. Dette er et typisk problem i utviklingsprosjekter uavhengig av sky og devops. Da kan løsningen være å dele opp i to mindre team og heller la “Scrum Master” for hvert team snakke sammen.
Devops
På grunn av automatisering, takket være skytjenester, er driftskostnadene redusert. Utviklingsteamet har tilgang til alle miljø og teamet gjør alt selv, for eksempel å spinne opp et nytt testmiljø. God grunndesign på organisasjon og det tekniske gjør at rettighetene til et team speiles i tilganger til logger og overvåkning, slik at man slipper å stoppe opp i en feilsøking, for eksempel, på grunn av manglende tilgang.
Skytjenestene gjør det enkelt å måle hvordan tjenestene går i produksjon og testmiljø, noe som gjør at utviklingsteamet selv fanger opp kapasitetsproblemer og fikser dem før brukerne varsler om problemer, såkalt proaktiv overvåking. Med så mange mikrotjenester som skal snakke sammen så har teamet fokus på god testdekning med automatiserte tester som oppdateres jevnlig. Teamet benytter også testing i produksjon og for dem er dette hverdagen siden testmiljøer rett og slett ikke dekker alt som ligger i ymse bank-kjerne-systemer.
Hver fredag har de demonstrasjon av det nyeste for forretningssiden og interessenter for å vise progresjon og få raske tilbakemeldinger.
Sikkerhet
Sikkerhet er innbakt i den daglige jobben til utviklerne. Videre har de automatisk sikkerhetstesting og regelmessige penetrasjonstester. Dette er vi i Knowit vant med å ha søkelyset på i prosjektene våre.
Erfaringer med Agile DevOps i forsikring
Knowit har en rekke konsulenter i forsikringsbransjen, deriblant et stort selskap som spenner over mange land. Her driver de også med Agile Devops. Ett team leverer verktøy for at skadebehandlere kan gjøre jobben sin på en god og effektiv måte. Det kan være registrering, behandling, utbetaling eller tilrettelegge for partnertjenester som f.eks. leiebil ved uhell. Også her har de en monolitt de jobber med å flytte ut i skyen, men mye blir fremdeles gjort som en del av monolitten. Det er ikke alt som passer til å flytte i skyen enda på grunn av avhengigheter. Kodebasen i monolitten er over 15 år gammel. De jobber med Windows-applikasjoner, web-applikasjoner og flere forbedringer på backend (kjernefunksjonalitet). Teknisk gjeld og forbedring av kodekvalitet inngår som en naturlig del av oppgavene deres . Organisasjonen av utviklerne speiler delvis avdelingene og noen team er crossover. På fire av teamene er Knowit-folk teamledere og jeg har snakket med en av dem.
Smidig forsikring
Mange av teamene på forsikringsselskapet bruker Scrum eller Kanban, men autonomiteten varierer. Det er forskjellig kultur i teamene. Teamleder fra Knowit sier de har et smidig forhold til smidig. Ingenting følges slavisk. De bruker ikke stand-up om de føler at det ikke gir dem noe tilbake. “Scrum Master”-rollen, estimering og sprinter har de forkasta. I stedet har de beskyttende ledere over dem som tar vekk støy når det trengs og de leverer kode til produksjon fortløpende. De kjører Kanban-ish, siden de opererer med flere oppgaver om gangen enn de grensene som Kanban setter.
Teamet ble tidligere avbrutt av interessenter som ba om funksjonalitet som ikke var i oppgavelista, hvor teamleder ga saken videre til lederne over og ba om at dette kommer den rette veien, via prioritering. Det er viktig å la folk være i fred på teamet. Da øker trivselen og produktiviteten. Oppgavene blir prioritert fortløpende av produkteier og teamleder, som er gode til å samarbeide. Teamet er tverrfaglig og består av utviklere, forretning, testere, og ux. De har mandat til å foreslå forbedringer og de får støtte av lederne til dette. De får sjelden nei. Dette er løsningen og sukesskriteriet for at teamet skal få arbeidsro og at oppgavene blir gjort.
Små endringer levert til produksjon gir liten risiko. Kontinuerlig oppdatering av automatiske tester gjør at de er trygge på at det går bra. Gjennom retrospektivene sine endrer de sin egen prosess og vil, hvis det skulle trengs, innføre “Scrum Master” igjen som rolle.
Devops
Når en oppgave plukkes opp har utvikler ansvar for den helt til den er i produksjon. Alle på teamet ønsker å levere kvalitet, dette er en viktig kultur å bygge på. Hvis forretning ønsker en høyt prioritert endring, er det ofte et krav at forretning har testkapasitet før oppgaven i det hele tatt startes på. Utvikler skal slippe å vente. Hvis den er viktig, forplikter bestiller seg til å verifisere endringen omgående. Det skal ikke være noe “neste uke”. Hvis det ikke er klart, er det ikke vits i å starte på oppgaven. Det er viktig for utvikler å få rask tilbakemelding.
Teamet har god kontakt med brukerne og tar hensyn til måten de jobber på når de utvikler nye tjenester. Utviklingen skal støtte det faktum at måten skadebehandlerne jobber på har endra seg de siste 15 årene. De endrer hele kjernelogikken.
De har også testere på teamet som fortrinnsvis skriver tester med en gang oppgaven defineres og som trykker på alle knapper som ikke skal trykkes på. Både testere og utviklere har ansvar for å oppdatere automatiske tester som i neste omgang er med på å minske risiko for feil i produksjon. Skytjenestene gir mye gratis, hvilket hjelper på hastigheten. Disse faktorene er med på å forbedre “speed-to-market”.
Utfordring
For en del år tilbake var det vanlig å levere “Big bang” fire ganger i året på monolitten. Da var det mye som kunne gå galt og helgejobbing måtte tas i bruk. Dette har gradvis endret seg fra fire ganger i året - til en gang i måneden — til omtrent hver dag. På stand-up er standardspørsmålet “hva hindrer oss i å gjøre deploy i dag?”.
Kulturen teamet har nå med å ta ansvar fra A til Å har ikke passet alle på teamet alltid. Det har tatt tid å innføre. Endringer på den tekniske siden kan være rett frem, men å endre måten de jobber sammen på er ofte en utfordring.
De demonstrerer funksjonalitet for interessentene fra tid til annen, men teamleder innrømmer at dette er et forbedringspunkt. De må ha det oftere. Det er viktig med demo jevnlig for å holde interessentene oppdatert på status og for å unngå unødvendige spørsmål til utviklerne. I tillegg er det bra for deling av kunnskap innad i teamet, “hvordan virker siste nytt i praksis?”
Sikkerhet
Det finnes mange gode prosesser for GDPR og generell sikkerhet i selskapet, blant annet prosesser for å godkjenne applikasjoner i skyen. Teamet føler seg veldig trygge på at de ikke setter sikkerhetshull ut i produksjon.
Oppsummering
Selv om kontinuerlige leveranser og smidig metodikk er vanlig i dag, er det likevel mange bedrifter som ikke får til dette. Utviklere opplever til stadighet å bli avbrutt med nye funksjonalitetsønsker og de må ta i bruk overtid for å bli ferdige med planlagte oppgaver. Teamkultur med frihet under ansvar er særdeles viktig, og i dette inngår aksept fra forretningssiden for at oppgaver tar tid å løse. Dette har begge team jeg har beskrevet her.
Bedriftene har ofte ikke testmiljøer eller såkalte staging-miljøer (et miljø som ligner på produksjon), og kvaliteten på det som leveres blir dårlig. Å bruke skytjenester gjør det lett å kunne spinne opp de miljøene de trenger. Automatiske tester og tid til å definere dem, slik de har i begge eksemplene her, er viktig for å få til kontinuerlig produksjon. Å ha tverrfaglighet på teamet, som aktive produkteiere og egne testere er helt klart et fortrinn i kvalitet og brukbarhet i produksjon, — man får reell gevinst. Venting gjør folk demotiverte. Unngå det. Og ha demo.
Den tekniske og det organisasjonsmessige er like viktig.
Et sluttpoeng er at om man ikke har oppnådd sitt fulle potensial selv om man har innført smidige ritualer og prosesser, kan være nyttig å snakke med en profesjonell som Knowit. Vi kan hjelpe til som nøytral part for å løfte teamet videre. Sånn oppstår det enda bedre verdiskapning og teamets tilfredshet øker.
(*) Definisjonen på “bra” kan variere, men per i dag anbefaler de fleste “Minimum Valuable Product” eller som jeg har vært med på: “Walking Skeleton”).
(**) Devops = Development + Operations, utvikling + drift, - det vil si utviklingsteamet gjør utvikling og drift.
(***) “Speed to market” er det samme som “Time to Market” og betyr tiden det tar fra de første ideene rundt et produkt oppstår og dets eventuelle tilgjengelighet på forbrukermarkedet. Bedrifter bruker beregning av time-to-market for å evaluere hvordan produkter utvikles og hvordan ett bestemt prosjekt håndterer ekstern konkurranse.
(****) Kanban er en måte for å begrense igangsatt arbeid i en produksjon. En ny jobb må vente hvis antall påbegynte jobber har nådd en grense. Så snart en jobb er ferdig, kan neste ventende jobb settes i gang. I tillegg har man en tavle med oppgaver, styring av arbeidsflyt, tydelige regler, hyppige tilbakemeldinger og kontinuerlig forbedring gjennom samarbeid, utvikling og eksperimenter.
Scrum er et rammeverk for å utvikle informasjonssystemer. Scrum-prinsippet bygger på samarbeide innenfor team fra tre til ni medlemmer som bryter ned oppgaver til prosjekter som kan ferdigstilles innen gitte tidsrom, såkalte «sprint», som vanligvis strekker seg fra to uker til én måned. Metoden omfatter også daglige vurderings- og planleggingsmøter som ikke skal vare lenger enn ett kvarter.