Är er organisation redo för devops och det ökade kravet på just in time-leveranser via kontinuerlig leverans? Kontinuerlig leverans och kontinuerlig integration är för många företag fortfarande buzzwords medan det för andra är verklighet och vardag. För vissa är det ett måste utan vetskap om varför och just detta är ett ganska vanligt förekommande problem inom it idag. Vi kastas runt mellan alla dessa buzzwords och tror att vi har behov av dem utan att faktiskt veta när dessa skall användas eller varför man bör använda dem.

Jag tänker presentera en mognadsmodell för kontinuerlig leverans som ger samma fördelar som kontinuerlig leverans idag ger de ledande företagen i den digitala transformation som vi befinner oss i. Förhoppningsvis kan du identifiera var din organisation befinner sig och även få lite insyn i vart andra är på väg.

De här är inget projekt som du kan bocka av med en checklista. Att införa kontinuerlig leverans och andra metoder kräver tid, mentorskap och kontinuerlig coachning. Det är inget projekt som man kan köpa utan det är en transformation, en uppfostran och ett kontinuerligt förändringsarbete som man måste vårda löpande i sin organisation.

Läs också: Hört talas om DevSecOps? Så säkrar du koden utan att tappa fart

Företag vill ha ökad innovation inom mjukvaruutveckling.
Att slösa tid och resurser på att hålla system uppe med en massa underhåll är något som it-ledare vill komma ifrån, bland annat genom ökat stöd för devops. Man vill på så sätt få mer tid över till inkrementella innovationer för att hänga med i den snabba digitala förändring som pågår.

Marknad vill ha programvaruleverantörer som kan leverera nya funktioner och tjänster i den takt som företaget vill.
Vanligast är att man vill få saker levererade inom sex månader, helst snabbare. Men så blir oftast inte fallet på grund av andra saker runt produktionen av programvara som tar onödigt fokus ­­- så som verktyg, förvaltning och för många nivåer i organisationen vilket leder till långsamma affärsbeslut.

Man vill ha en mogen företagskultur och utvecklingsprocesser, men oftast har man istället en stor omognad som hindrar bra kommunikation och bromsar leveranser
Bristen på bra kommunikation och samarbete skapar missförstånd och hindrar organisationen från att kunna göra smidiga leveranser. Många it-chefer ser det inte på det sättet. De ser ofta inte värdet av kommunikation och använder olika roller för att separera progravaruutvecklare från möten med kunder.

Det här är en artikel från Expert Network

Men devops-kulturen ställer nya krav på företagen - att gå från en centraliserad organisation till en mer decentraliserad sådan. Ett företag som ligger långt fram här är Toyota som har gjort den här resan för länge sedan.
Det är inte helt enkelt att nå dessa mål. Vi måste dagligen arbeta med att kontinuerligt förbättra organisationen. Vi kanske till och med måste göra oss av med celler, silos och roller för att istället lägga ansvaret på medarbetarnivå och bli av med mikromanagement. Detta är också vad tre av de fyra punkterna i det agila manifestet pekar på:

  • Människor och interaktion före processer och verktyg
  • Kundsamarbete framför kontraktsförhandling
  • Anpassning till förändring framför att följa en plan
 
Det finns en tydlig mognadsmodell som är indelad i fem nivåer för att enkelt och snabbt kunna se vart man själv befinner sig i sin organisation och lättare kan vägleda sig fram till nästa. Att det kallas mognadsnivåer beror på att varje steg behöver genomgås för att bli mogen för nästa steg. 
Nivå 1: Några få utvecklare är hjältarna idag
Nivå 2: Adaptiv leveransprocess
Nivå 3: Reguljära leveranser 
Nivå 4: Release på kommando 
Nivå 5: Hypotesdriven utveckling

Nedan är typiska kännetecken för varje nivå:
Nivå 1: Några få utvecklare är hjältarna idag (ad hoc-lösningar).
  • Teamen kör oftast manuella tester för att hitta fel och defekter.
  • Det saknas oftast automatiska tester och enhetstester.
  • Systemintegration är jobbigt, tar tid och skapar många problem.
  • Leveransprocessen är oftast manuell, i vissa fall automatisk.
  • Utvecklare, testare, operation och projektledare har alla olika mål vilket ofta leder till konflikter.
  • Support och förvaltning sker ad hoc, kringgås eller ignoreras.
  • En eller flera personer får rycka in och agera superhjältar mellan teamen och rädda kritiska projekt
  • Man kastar runt resurser
På nivå1 råder det bristande kommunikation och konflikter mellan olika nivåer i organisationerna. Man har bristande förståelse för att hela organisationen är ett team där roller, silos och murar skapar problem. För att komma vidare är det viktigt att börja riva murarna och utbilda företaget inom digital transformation.

Nivå 2: Adaptiv leveransprocess (Planerad leverans, oftast baserad efter timeboxar)
  • Tydligt produktägarskap är på plats (oftast Scrum PO)
  • Teamen jobbar i iterationer (oftast två-tre veckor långa)
  • Teamen blir mer självorganiserade och krossfunktionella
  • Det finns vissa automatiska tester
  • Styrning och kontroll över förvaltningen är på plats 
  • En produktionsliknande testmiljö finns i ett tidigt skede för projekten
  • Det finns vissa system och skript uppsatta för att bygga paket från versionshanterare 

Nivå 3: Team bygger kvalitet i sina leveransprocesser

  • Nu har man fler reguljära leveranser 
  • Teamen praktiserar utvecklingen med kontinuerlig integration av alla förändringar
  • Det finns tillräckligt med automatiska tester som hittar kritiska defekter snabbt
  • Integrationstesterna är snabba och automatiska 
  • Inga arbeten är klara innan de har gått genom en tydlig och diciplinerad Defintion of Done (DoD)
  • Testare är inte primärt fokuserade på regressionstester utan används i hela arbetsprocessen.
  • Databasförändringar har versionshantering och är skriptade.
  • Murar mellan gamla roller har börjat rivas, det är mer interaktion och kommunikation mellan det som en gång var överlämningsgränser

Nivå 4 Leverans på kommando (Leveranser är paketerade med ren affärsnytta)
  • Leveransprocessen stoppar automatiskt dåliga förändringar i versionshanteringen 
  • Tvärfunktionella produktcentrerade team hanterar produkten genom dess livscykel
  • Omfattande automatiska testsviter skapas genom TDD/ATDD och underhålls av utvecklare och testare som arbetar tätt ihop
  • Teamen övervakar och hanterar produkter i arbete och levererar arbete i små paket
  • Operation jobbar tätt ihop med utvecklare
  • Organisationen är mer decentraliserad för att snabbare kunna ta beslut som leder till förbättringar

Nivå 5 Hypotesdriven utveckling (Teamen fokuserar på att optimera cykeltiden för att lära sig av kunderna)
  • Alla nya krav beskriver hur värdet på funktionen kommer att mätas
  • Produktteamet bär ansvar för att implementera metrik för samla in data via tekniker så som A-/B-testning med mera.
  • Systemen är byggda efter arkitektur med hög kontinuerlig utplacering i fokus, och supportar stöd för test i produktion
  • Databasförändringar är frikopplade från applikationsleveransen 
  • Lean startup är en vanlig process på denna nivå
  • Man har börjat applicera exempelvis lean startup och använder kontinuerlig leverans för att aktivera affärsmässiga innovationer och experiment
  • Man ser varje leverans som nya startups 

När man når nivå 5 har man ett helt annat synsätt kring hantering och mätning av roi än när man stod på nivå 1. Man har börjat fokusera på kunderna och inlett ett partnerskap istället för att agera som ett tjänstebolag. På så sätt har man lättare att kunna leverera det folk faktiskt vill ha.

Läs också: Kontinuerlig leverans av kod ger mindre säkerhetsstrul

Om du känner att det är väldigt mycket som måste justeras för att hänga med här är det också ett tecken på att du faktiskt ligger efter och har stannat upp för länge i din organisation. Det är viktigt att inte bli självbelåten och stanna upp.

Fakta

Befattning: Utvecklare, arkitekt, mentor och coach
Företag: Softhouse
Linkedin: Johan Normén
Twitter: @johannormen
E-post: jnormen@gmail.com
Hemsida: www.softhouse.se
Expertområden: CI-/CD-arkitekturer, programmering, UX, agila metoder, lean, lean startups.
Certifieringar: PIM (produkt management system), Scrum master.
Bakgrund: Började som spelutvecklare och designer redan som 12-13-åring. Har jobbat med webb sedan 1995 och som konsult i 18 år. Jobbar som technical manager, säljstöd, UX, eventansvarig. Utsedd till Sveriges sjunde bästa utvecklare 2015 av TechWorld.