DevOps inifrån och ut

Alla vill ha DevOps! Att införa nya saker i en organisation är dock alltid en utmaning.

Det är ett äventyr, och du kommer att ha ett brokigt gäng följeslagare på resan. Med karaktärerna från Insidan ut som utgångspunkt tittar vi på dessa personligheter och hur du kan göra vem som helst till en bra reskamrat!

DevOps-omvägen

Innan vi kan börja behöver vi nog prata lite om det här med DevOps. Det råder stor oenighet om definitionen av DevOps. I det här blogginlägget utgår vi från att DevOps är en uppsättning metoder som främjar automatisering, ett helhetsperspektiv på applikationen samt högre hastighet i mjukvaruutveckling och driftsättning. Det handlar alltså om att utveckla mjukvara, leverera den till kunder och se till att den fortsätter fungera efter leveransen.

Vi tror att DevOps och Continuous Delivery kommer att bli lika viktiga för branschen som Agile har varit. Utvecklare kommer att se med förvirrad uppgivenhet på organisationer som inte använder Continuous Delivery och DevOps. Låt oss därför titta på de personligheter du kan möta på din resa mot modern mjukvaruutveckling.

Välkommen till kontrollrummet

I filmen Insidan ut befinner vi oss inne i huvudet på en flicka som heter Riley. Grundkänslorna ilska, avsky, rädsla, glädje och sorg delar på en kontrollpanel, och kombinationen av dessa olika perspektiv formar Rileys personlighet och beteende. Känslorna är förstås en tydlig förenkling, men de har hjälpt många att bättre förstå hur känslor fungerar. Låt oss därför försöka tillämpa samma förenkling på DevOps-övergången i en teknikorganisation.

Glädje

I Glädjes värld är allt fantastiskt. Glädje är en tidig användare, experimenterar alltid och är oftast bättre på att starta saker än att avsluta dem. Det är nödvändigt att ha Glädje omkring sig – vi behöver mentaliteten att allt är fantastiskt. Men vi måste också komma ihåg att annorlunda inte automatiskt är bra.

Vi behöver kontinuerligt reflektera över de val vi har gjort och inte bara fortsätta springa mot ett glänsande mål. I alla förändringsprocesser är det viktigt att vi alltid är medvetna om varför vi gör det vi gör och hur det hänger ihop med det övergripande målet. Vi försöker lösa problem, inte bara plocka på oss en massa nya verktyg för sakens skull.

Personer med Glädjes egenskaper tenderar att vara Technology Apologists. De är mycket imponerade av att ett verktyg fungerar eller ens existerar, men uppmärksammar inte nödvändigtvis dess bristande mognad eller användbarhet. Begreppet Technology Apologist myntades i boken The inmates are running the asylum av Alan Cooper.

Det kan vara svårt att hålla Glädje på rätt spår och få henne att följa etablerade processer. Glädje kan fungera som en varningssignal för problem som väntar runt hörnet. Se till att det är så enkelt att göra rätt att Glädje inte kan låta bli att skapa det Jira-ärende för förbättringen som hon just kom på.

Favoritcitat från din Glädje-karaktär:

• ”Så här gör de på Facebook”

• ”Jag hittade det här nya verktyget”

• ”Jag läste på HackerNews …”

• ”Åh, ja, det fungerar inte riktigt än, men […]”

Glädjes favoritverktyg:

• Något hon själv kompilerade från något kodrepository, skrivet i ett hippt språk som Rust eller Go.

• Alternativt Vim.

Något hon själv kompilerade från något kodrepository, skrivet i ett hippt språk som Rust eller Go.

Alternativt Vim.

Ilska

Ilska får s!t gjort! Du kan vara säker på att få höra det från Ilska om något är trasigt. Om Ilskas kollegor inte riktigt följer kodstilen eller slösar tid på möten, kommer det inte att gå obemärkt förbi. Ilska är mycket produktiv, men vägen blir ofta ojämn när du arbetar med Ilska. Produktiviteten tenderar att sjunka när en arg utvecklare regelbundet står vid ditt skrivbord.

Ett sätt att hantera Ilska är att säkerställa att ni är överens och att Ilska inte har orealistiska förväntningar på mognadsgraden i det de arbetar med. Det är också mycket viktigt att inte låta Ilska styra alla era beslut. Då kommer ni att fladdra runt som en eldfluga för att släcka dagens brand du jour.

Du behöver dock komma ihåg att ilska inte uppstår ur tomma intet. Hitta grundorsaken och hantera den. Ta reda på vad som driver ilskan, så blir den en kraftfull allierad. Ilska får sk!t gjort!

Favoritcitat från din ilska-karaktär:

• ”Pipelinen är trasig”

• ”Vem förstörde min build?”

• ”Jag tänker inte vänta på IT längre, jag köper en egen server”

Ilskans favoritverktyg:

• Print Screen-tangenten

• Outlook

• Att gå bort till ditt skrivbord

Avsky

Avsky fyller en mycket viktig funktion: att hindra oss från att bli förgiftade. Det är sunt att ha en viss skepsis mot nya verktyg eller arbetssätt. Eftersom många förändringsledare tenderar att präglas av glädje upplever vi att avsky är väldigt bakåtsträvande. De är för tveksamma för att vi ska kunna arbeta med dem på ett meningsfullt sätt. Men på många sätt är avsky en barometer för framgång. Kom ihåg att det som nu är status quo en gång var nytt och motbjudande.

Innan vi kan övertyga avsky går övergången till DevOps inte i någon aptitlig riktning. Och eftersom DevOps är något vi strör ovanpå, bör det vara aptitligt. Det vi rör oss mot bör vara mer attraktivt än status quo.

Vi behöver förstå vad avskyns skepsis bottnar i och skära bort de giftiga delarna. Eller koka dem tillräckligt länge för att de ska bli oigenkännliga. Gör små förbättringar för avskyn. Skapa ett Git-alias eller ett litet script som tar bort en del av smärtan.

Jag beklagar att behöva säga det, men det här kan vara punkten där du börjar ta skärmbilder och lägga dem i ett Word-dokument eller en PowerPoint-presentation.

Favoritcitat från din avsky-karaktär:

• ”Det här ser kusligt mycket ut som ett verktyg från 90-talet”

• ”Den här nya lösningen verkar väldigt komplex”

• ”Tro inte att det fungerar här bara för att det fungerar på andra ställen”

• ”Jag är inte säker på att det tillför något värde för företaget att jag lär mig Git. Det är för sådana som du”

Avskyns favoritverktyg:

• Den IDE som IT-avdelningen har godkänt

• SharePoint

Rädsla

Rädsla är viktigt. Rädsla hindrar oss från att skada oss. Vår erfarenhet är att rädsla tenderar att fokusera på den säkraste vägen på kort sikt. För många företag kan det säkraste vara att fortsätta arbeta i SVN. Att fortsätta arbeta som vi brukar. Men det skadar verksamheten på längre sikt. Rädsla ser situationen ur ett ”Ops”-perspektiv. Vi har något som måste fortsätta fungera. Det är det viktigaste av allt vi gör, för hur skulle vi annars kunna skapa värde för våra kunder? Rädsla värdesätter stabilitet över allt annat.

En viktig sak när du hanterar rädsla är att inte göra något oväntat. Se till att du har en tydlig och transparent roadmap med en tidslinje. Var ärlig om du vet att den närmaste tiden kommer att innehålla gupp på vägen. Då kan rädslan förbereda sig.

Involvera om möjligt Rädslan i förändringsprocessen. Och när du är som mest irriterad på Rädslan för att den är en petig skitstövel, kom ihåg att allt Rädslan upptäcker och påpekar är betydligt billigare än att åtgärda det som hamnade i produktion.

Favoritcitat från din Rädslan-karaktär:

• ”Jag tror inte att det kommer att fungera”

• ”Det fungerar nu, varför ändra på det?”

• ”Jag är inte säker på att det är en så bra idé att välja ett Open Source-verktyg”

• ”Hur ska vi veta att […]?”

Rädslans favoritverktyg:

• Excel

• Visual Studio 2010

• Ett Word-dokument på fjorton sidor som beskriver en installationsprocess

Sorg

Sorg är det som ger Glädje ett sammanhang, sorg är det som får oss att reflektera. Först när vi omfattar detta och skapar en balanserad helhet kan vi bli en framgångsrik DevOps-organisation.

Sorg är den nödvändiga motpolen till teknikapologeten Glädje. Sorg ser till att vi inte glömmer varför den senaste förändringen misslyckades. För Glädje kan detta kännas som en eländig nejsägare. Men det är inte sorgens syfte.

Som Sorg säger: ”Att gråta hjälper mig att sakta ner och älta tyngden av livets problem”. Och det är så det känns. Men om vi inte ältar lite, om vi inte genomför våra retrospektiv ärligt och minns både motgångar och framgångar – hur ska vi då kunna förbättra oss? Hur ska vi kunna lyckas? Sorg ger oss alla viktiga lärdomar vi behöver för att bli bättre nästa gång.

I grunden är jag Glädje. Jag startar saker, blir distraherad och startar nya saker. Ibland glömmer jag att verkligheten också behöver lite kärlek och omsorg. Jag måste vara väldigt noga med att inte bara sätta Sorg i den kritade cirkeln och säga: ”Stör inte mina framsteg”.

Jag blir irriterad när jag (igen) har fått den här fantastiska idén och presenterar den för någon som visar sig vara en faktadriven, realistisk och sansad person. Det hjälper mig att förstå vilka idéer som är viktiga och vilka som kanske bäst får stanna vid just idéer.

Så respektera och bekräfta Sorg – där finns mycket sanning att hitta.

Favoritcitat från din Sorg-karaktär:

• ”I den senaste förändringen glömde vi ...”

• ”Kom ihåg att alla behöver vara med på tåget”

• ”Det blev ett enormt krångel förra gången vi bytte verktyg eftersom ...”

• ”Problemet finns fortfarande kvar med det nya verktyget, bara på en annan plats i processen”

Sorgs favoritverktyg:

• Minnet av vad som har prövats tidigare. Den samlade erfarenheten av alla svårigheter med förändringar från företagets start fram till nu.

• En kaffemugg från en sedan länge försvunnen verktygsleverantör

Bing Bong

Bing Bong är Rileys låtsaskompis. När han inte längre behövs offrar han sig för Rileys psykiska hälsa.

På så sätt kan vi se honom som ett exempel på en kodbas eller verktygsstack som har varit. Den var viktig och var vid en tidpunkt den mest kritiska delen av organisationens arbetssätt. Vi bör fatta våra beslut utifrån lärdomarna från tiden då Bing Bong var kung på våra gator, men vi bör inte försöka bevara honom på konstgjord väg eller, för den delen, upprätthålla begränsningar som vårdade av hur vi brukade arbeta.

Så länge vi inser att den verktygsstack som vi omsorgsfullt har byggt ihop genom åren är det som gjorde det möjligt för oss att komma dit vi är, bör vi med gott samvete kunna säga adjö till den och gå vidare till DevOps. Det är svårt att komma till den insikten, särskilt i företag med kodbaser vars första rader kod skrevs innan företag som Uber eller Tesla ens hade grundats.

Vi måste erkänna att alla de beslut som ledde oss till den röra vi nu befinner oss i var rätt vid tidpunkten de fattades. Och vi måste inse att vi kan komma mycket längre genom att förändra oss.

Mot DevOps

Om du är på väg mot Continuous Delivery och DevOps och behöver någon att bolla med, eller om du bara försöker komma på hur du ska börja, hör gärna av dig. Vi har stor erfarenhet av att vara en värdefull följeslagare på sådana resor.

Om du känner igen dig själv eller någon av dina kollegor i någon av dessa karaktärer, dela gärna ditt favoritcitat från dem med oss.

Vi önskar dig lycka till och god psykisk hälsa.

Alla bilder i det här blogginlägget kommer från filmen Insidan ut. Upphovsrätt: ©2015 Disney/Pixar.