Fra Smidig til DevOps til Kontinuerlig Produktutvikling i Autonome Team?

DevOps (Development og Operations) er et begrep som benyttes for å referere til et kulturelt skifte. Det er et sett av praksiser som underbygger samarbeid og kommunikasjon mellom utvikling, drift og testing med automatiserte prosesser for levering av programvare og infrastrukturendringer.

DevOps (DZone.com)

DevOps som fenomen og begrep har vært mye diskutert de senere årene. Det om­tales ofte i sam­men­­­heng med Smidig system­utvikling og en Smidig/Lean til­nærming til IT, og ofte i sam­men­­heng med bruk av moderne sky-tjenester for operasjon og drift av pro­gramvare.

I følge tilhengerne gir DevOps store gevinster, og benyttes av ‘alle’ de kule selskapene som f. eks. Google, Facebook og Netflix. Det har etter hvert også fått utbredelse her i Norge, blant annet i Finn, Oslo kommune og Posten. Til­heng­erne viser til store forretningsgevinster som forbedret brukeropplevelse og engasjement, økt evne til endringer og innovasjon, og raskere tid til marked. Programvare er ofte ikke ferdig utviklet i løpet av et prosjekt, men må kontinuerlig videreutvikles og vedlikeholdes. Denne kontinuerlige videre­utviklingen står for store deler av kostnadene ved implementasjon av nye IT-løsninger, og også her spiller DevOps en rolle.

Historien
Smidig systemutvikling med teknikker og metoder som f.eks. Scrum og Kanban er etterhvert blitt mer og mer vanlig ved utvikling av nye systemer. En av de viktige prinsippene fra det Smidige Manifestet er: «Lever fungerende programvare hyppig, med et par ukers til et par måneders mellom­rom. Jo oftere, desto bedre.». Hovedfokuset til smidige systemutviklingsmetodene har vært rettet mot utviklingen av program­vare, og stort sett utelatt driftsdelen. DevOps blir av mange sett på som en logisk fortsettelse av smidig­beveg­elsen. DevOps har oppstått som praksis ved å benytte mange av de samme prinsippene som Smidig hentet fra Lean, Teory of Constraint og ledelse. Teoriene og prinsippene er tilpasset og plassert inn i IT sin verdistrøm.

DevOps har oppstått blant praktikere fra tre ulike retninger. Patrick Debois arbeidet med Smidig Infra­struktur og ble inspirert av John Allspaw sin presentasjon «10+ Deploys Per Day: Dev and Ops Cooperation» (Flickr) på Velocity konferansen i 2009 i USA. En slik endringstakt var revolusjonerende for en bransje som var vant til kvartalsvis eller halvårlige nye versjoner av pro­gram­­vare. Inspirert av flere fra Velocity konf­eransene i USA startet Patrick Debois konferanseserien DevOpsDay i Gent Belgia i 2009. Med dette navnet ble begrepet DevOps innført, og DevOps-bevegelsen så sin begynnelse. Konferanseserien har siden sprett seg utover til flere steder i Europa og USA. Den kom til Norge i 2016.

Den andre påvirkningen er fra Lean og mer spesifikt fra Lean Startup av Erik Ries og «Four Steps to the Epiphany» av Steven Blank. Disse teknikkene har også hatt en stor påvirkning på systemutviklingsmiljøet, og spesielt startup miljøet. De har ofte behov for å lansere produkter veldig raskt. DevOps bygger på prin­sip­per fra Lean som f.eks. effektivisere flyt, minimalisere ledetid, kontinuerlig forbedring, redusere batch-størrelser og fokus på verdi for kunden.

Sist men ikke minst arbeidet Jez Humble har gjort med utvikling og promotering av teknikkene for konti­nuerlige leveranser (Continuous Delivery). En kontinuerlig pipeline av kode og infrastruktur som alltid er klar til å settes i produksjon. Denne tankegangen er en videreføring av kontinuerlig testing og konti­nuerlig inte­gra­sjon. Sammen med at vi har fått infrastruktur som kan håndteres som kode — Infrastructure as Code, er disse initiativene starten på det som vi i dag kaller DevOps.

Definisjon
DevOps er et kulturelt skifte. Det er et sett av praksiser som underbygger samarbeid og kommunikasjon mellom utvikling, drift og testing med automatiserte prosesser for levering av program­vare og infra­struktur­endringer i produksjon. DevOps samler utvikling og drift, strøm­linje­former leveranse­prosessen innen systemutvikling, legger vekt på læring ved kontinuerlig tilbake­melding fra produksjon til utvikling, og forbedrer syklustiden (ledetiden). DevOps bidrar til å levere programvare raskere, til å utvikle programvare med høyere kvalitet, og til å forbedre implementasjon av kravene.

DevOps bringer smidig tankegang inn i alle fasene av systemutviklingslivs-syklusen. DevOps har fokus på flyt fra utviklingsfasen til drift, og bringer sammen utviklerne med driftspersonell og kvalitetssikrere/testere. Dette medfører at man lærer om pro­blemene tidligere, reduserer tid til marked, får tilbakemeldinger raskere, øker release-takten, bedrer kvalitet og får mer fornøyde brukere. Ved at kommunikasjon og samarbeid øker, gir det bedre muligheter til innovasjon og til å utvikle en mer produktiv kultur.

DevOps er en utvidelse av Smidig og tar ofte i bruk teknikker som har kommet til i den senere tiden; kontinuerlig integrasjon, kontinuerlig test og kontinuerlig deployment.

DevOps plassert ift. Smidig og Lean (Marschall).

Det er altså ikke en utvikler som kan drifte litt, ei heller ikke en spesiell rolle i et team. Det er teamet som utvikler, leverer og forvalter programvare i produksjon iht. DevOps praksiser og prinsipper.

DevOps er basert på:

• Kultur — menneskene og prosessen først. Hvis du ikke har en god kultur, vil alle automatiseringsforsøk være nytteløse. Programvare er laget av og for mennesker. DevOps krever en kulturendring for et felles ansvar for levering av programvare med høy kvalitet til sluttbrukeren.
• Automatisering — er avgjørende i DevOps for å få rask tilbakemelding. DevOps er avhengig av full auto­matisering av bygg, distribusjon og testing for å oppnå korte ledetider, og dermed rask levering og til­bakemeldinger fra sluttbrukere.
• Måling — DevOps har en spesiell fokus på måling. Kvalitet og delte (eller i det minste på linje) insentiver er kritiske. Hvis du ikke kan måle, kan du ikke forbedre. En vellykket DevOps-implementeringen vil måle alt den kan, så ofte den kan.
• Deling — utvikle en kultur der folk deler ideer, prosesser, verktøy, kunnskap, infrastruktur og feirer suksess sammen for å bringe utvikling og drift team tettere sammen. Deling er tilbakekoblingssløyfa i syklusen, og derfor avgjørende å skape en kultur hvor folk deler ideer og problemer.

Det er tre prinsipper som ligger til grunn for DevOps:

1. Systemtenkning. Det første prinsippet fokuserer på ytelsen til hele systemet, i mot­setning til optimalisering innen en bestemt avdeling/ funksjon. Det handler om å skape en kontinuerlig flyt av verdi fra utvikling, via drift til kunden, ved bruk av teknikker og prinsipper fra Lean.

2. Forsterke tilbakemeldingssløyfer. Det andre prinsippet er å bygge inn kontinuerlig tilbakemelding fra neste steg i flyten for å raskere oppdage problemer, gjøre korreksjoner, og løse problemer der og da når de oppstår. Dette gir en prosess med kontinuerlig forbedring.

3. Kultur for kontinuerlig eksperimentering og læring. Det tredje prinsippet er å bygge en kultur med høy grad av tillit som støtter et dynamisk og viten­skap­elig til­nærming med eksperimenter i en kultur for læring. Bevisst ta risiko og lære av feil, og forstå at repetisjon og praksis er en forutsetning for mestring.

DevOps handler om rask og fleksibel utvikling og implementasjon for å støtte forretningsprosesser. For å lykkes med DevOps må også de viktige teknologiske forut­setningene som verktøy for bygging, automatisering, over­våking, mikrotjenestearkitektur og sky-løsninger være implementert.

What’s next?

DevOps er i ferd med å gå mainstream. Flere og flere virksomheter tar prinsippene og teknikkene i bruk og det begynner å komme en del erfaringer fra større implementasjoner. Nå er nok ikke DevOps løsningen på alle utfordringene, men det er et stort steg på veien. Det er en forlengelse og utvidelse av Smidig som river ned veggen til enda en silo. DevOps tar i bruk enda flere prinsipper fra tradisjonell Lean. Hva er så neste steg? Ja, Design Thinking og Lean Startup er to deler av svaret.

Jeg tror at Lean, Smidig m.m. smelter mer og mer sammen til en kontinuerlig produktutvikling i autonome team. Utviklingen ser ut til å gå i retning av enda mer fokus på verdi, nytte og ende til ende flyt. Dette er som en følge av at system­utviklingsfaget påvirkes og plukker opp mer og med av Lean Produktutvikling. Reinertsen sine beskrivelser av flyt i produktutvikling med køteori og redusert batch-størrelse, og DevOps er et eksempel på dette. Det samme er Poppendieck’ene sitt arbeide med Lean Software Development.

Samtidig er det et økende fokus på å bli smidig på virksomhetsnivå. Virksomheter ønsker å kunne reagere raskere på krav til hyppige endringer. Begreper som Enterprise Agility og Lean Enterprise får en del oppmerksomhet både fra akademia, bøker om temaet og eksempel på virksomheter som har implementert det. F.eks. har et lokalt forsikringsselskap i Oslo omorganisert it-avdelingen og satser på Lean Produkt­utvikling med utviklerne plassert direkte inn i forretningsenhetene. Det skal bli spennende å følge de fremover.

Lean Startup gir oss en prosess for kontinuerlig læring gjennom eksperimentering og måling: Build — Measure — Learn. Metoden er ikke utelukkende for Startup, men kan også anvendes av tradisjonelle virksomheter. Lean UX adresserer flere av de samme problemstillingene for UX.

En av forutsetningene for å få til ende til ende verditenkning og flyt er at utvikling knyttes tetter opp mot forretningen og at vi klarer å fjerne en silo til. Dette på samme måte som DevOps-bevegelsen fjernet skille mot drift, og med moderne skytjenester som f.eks. serverless funksjoner/plattformer forsvinner vel kanskje drift helt — NoOps? Et annet interessant tema er Google sin vinkling på drift utført av systemutviklere — Site Reliability Engineering (SRE).

Initiativet for å knytte utvikling tettere på forretningen kaller noen BizDev.

Kontinuerlig systemutvikling. Basert på (Fitzgerald og Stol).

BizDev tar i bruk kontinuerlig planlegging og strategi der man benytter en kontinuerlig tilnærming i stedet for en årlig, top down tilnærming. Dette er ikke nytt, selv om de fleste virksomhetene vi kjenner ikke be­nytter en slik tilnærming i sine prosesser. Mintzberg beskrev kontinuerlig planlegging og strategi allerede i ’94. I de senere år har vår egen Bogsnes fått en del oppmerksomhet rundt kontinuerlig budsjettering — Beyond Budgeting.

Vi får da en ny tilnærming til systemutvikling som er en sammensmelting av moderne system­utviklings­metoder, og som tar i bruk velprøvde metoder og teknikker fra produktutvikling og innovasjon. En slik holistisk, integrert tilnærming med fokus på ende til ende flyt kan vi kalle Kontinuerlig Produktutvikling i Autonome Team — KPA, inntil noen kommer opp med et catchy navn :-) Vi utvikler og videreutvikler konti­nuerlig nye produkter i tett samarbeid med kundene, basert på prinsippene fra Lean, Smidig, DevOps og er organisert i kryssfunksjonelle autonome team. Vi benytter åpen programvare og implementerer produktene/ tjenestene i skyen.

Kilder:

Kim G. et al (2016) — DevOps Handbook, Wikipedia — DevOps, Ebert et al (2016) — IEEE, Hüttermann, M. (2012) — DevOps for developers, Kim G. et al (2013) — The Phoenix Project, Humble J. og Farley D. (2010) — Continuous Delivery, Fitzgerald B. og Stol K-J. (2015) — Continuous software engineering, Kennaley (2010) — Beyond a Tacit Understanding of Agile, Reinertsen (2009) — The Principles of Product Development Flow: Second Generation Lean Product Development og www.agilemanifesto.org/iso/no/principles.html.

Toppbilde: Daria Shevtsova on Unsplash