All posts in DevOps

Skandinaviens största event kring projektledning, ”Passion for Projects”, genomfördes nyligen på Svenska Mässan i Göteborg. Det handlar om passion, inte bara om passion för projekt utan även passion för förändring, utveckling och lösningar – det handlar om leverans av förändring och transformation…

 

Läs hela inlägget här:

https://www.netrelations.com/sv/inspiration/blogg/highlights-fran-passion-for-projects-2018/

 


I takt med att informationsteknologi och digitalisering blir allt viktigare för företag och organisationer så blir även inverteringar mer integrerade och komplicerade. Detta leder till att det blir svårare att retroaktivt anpassa fundamenten till nya inriktningar, livscykelhantering blir avgörande för vilka risker och möjligheter man har att anpassa mot strategier och kvalitetsförväntningar.

 

Icke funktionell kravställning & Teknisk skuld

 

I takt med att informationsteknologi och digitalisering blir allt viktigare för företag och organisationer så blir även inverteringar mer integrerade och komplicerade. Detta leder till att det blir svårare att retroaktivt anpassa fundamenten till nya inriktningar, livscykelhantering blir avgörande för vilka risker och möjligheter man har att anpassa mot strategier och kvalitetsförväntningar.

 

Icke-funktionella krav anger kvalitetskriterier

För att undvika att hamna i ett läge där man inte längre har möjlighet att möta marknadens behov inom en rimlig tid och investeringsnivå så bör man redan tidigt etablera nyckeltal som indikerar trender på de icke-funktionella kraven och den tekniska skuld som man har upparbetat i lösningen. Dessa nyckeltal agerar som en baslinje (nollmätning) som man sedan mäter förändringar mot. Det pratas väldigt mycket idag om IT säkerhet och vikten av informationssäkerhet – inte minst i samband med ny lagstiftning och medias reportage kring organisatoriska fadäser inom just IT säkerhet.

Beslutsfattare och kravställare av informationssystem och tjänster underskattar ofta vikten av de icke-funktionella kraven, kanske för att det är grumligt vad det egentligen innebär, samt att det ofta rör sig om tekniska eller designmässiga kvalitetsaspekter och vedertagna begrepp från yrkeskåren. Icke-funktionella krav är krav som anger kvalitetskriterier som kan användas för att bedöma driften av ett system, i stället för specifika beteenden. Planen för genomförande av icke-funktionella krav beskrivs ofta i dokumentation för systemarkitekturen och underhålls vanligtvis av en lösningsarkitekt. Några vanliga områden man pratar om kring icke-funktionella krav är:

  • Säkerhet – Nivå av preventiva säkerhetsåtgärder för att motverka otillbörlig tillgång
  • Förvaltningsbarhet – Livscykelaspekter för att bedöma hur utvecklingsbart systemet är
  • Tillgänglighet – Toleranser för systemets tillgänglighet
  • Användbarhet – Intuition mått för användare att konsumera nya funktioner
  • Prestanda – Kapacitetsmått under tung last

 

Kvantifiera den tekniska skulden

Framgångsrika organisationer använder moderna metoder för att utveckla lösningar med inbyggda kvalitetsgrindar för att systematiskt och inkrementellt bygga lösningen med rätt kvalitetsegenskaper. Vilket innebär att man ibland medvetet inte bygger lösningen med full funktion. Vanligtvis gör man en prototyp för att tidigt utvärdera egenskaper och riktningsbeslut. Eftersom vissa delar har medvetet blivit eftersatta och kommer behöver kompletteras så aggregeras det en skuld, eg. teknisk skuld. Begreppet (teknisk skuld) fungerar precis som vanlig ekonomisk skuld, genom att man lånar för att tidigare kunna erhålla produkten så får man betala ränta så länge man har lånet kvar.  Precis som amortering på ett ekonomiskt lån så betalar man tillbaka sin tekniska skuld med refaktorisering, dvs man förbättrar kvalitén i koden. Teknisk skuld kan mätas genom att kvantifiera attribut och kodmönster med tidsfaktorer och övervakas kontinuerligt (continuous inspection). Koden kan delas upp i olika alvarsgrader som exempelvis att det luktar illa till riktigt buggar och sårbarheter som akut måste fixas före det produktionssätts.

Genom att kontinuerligt mäta och medvetet styra utvecklingen inkrementellt så får man även tidiga varningssignaler och minimerar kvalitetsbrister. Genom kvalitetsprofiler så kan man mäta specifika grader av kvalitetsbrister och säkerställa att man inte överstiger satta tröskelvärden. Enhetstestning och utforskande testning kan påverka kvalitetsgrindar och kan med fördel innefattas i kvalitetsprofilen. Kvalitetsgrindar säkerställer att varje inkrement uppnår rätt nivå och mäts i perioder mot baslinjen för att se trender och tendenser. Ju tidigare man upptäcker en kvalitetsbrist, desto mindre blir i regel skadan och ju enklare blir det att åtgärda.

Kontinuerlig inspektion

SonarQube (www.sonarqube.org) är ett bra verktyg för att kontinuerligt mäta och kvantifiera den tekniska skuld man har i lösningen. Genom statisk kodanalys så analyserar verktyget hela kodbasen och presenterar visuellt hur olika ögonblicksbilder av koden presterar mot den kvalitetsprofil man har fördefinierat. Det möjliggör en dialog kring icke-funktionella kvalitetsaspekter och teknisk skuldhantering som annars kan vara abstrakt och svårkommunicerad.

Genom att visualisera och använda verktyg som SonarQube för att analysera stora kodmassor så kan vi säkerställa att vi ser samma bild och gemensam förståelse för annars svåra begrepp att säkerställa handskakning med tydlig kommunikation med intressenter.

Tillsammans med en partner som har gedigen erfarenhet av kvalitetshantering och med effektiv kommunikation kring icke-funktionella krav så att du som kund kan komma till avgörande insikter och säkerställa att investeringar frodas under lång tid framöver.


I årets State of DevOps rapport så finns det med ett mycket intressant inlägg kring transformativt ledarskap (tranformational leadership). Bra ledarskap påverkar direkt teamets förmåga att leverera och detta bör ske genom agila och lean principer för maximal effekt.

Vad är då transformativt ledarskap?

Transformativt ledarskap är en modell där ledare inspirerar och motiverar anhängare för att uppnå högre prestanda genom att förankra sunda värderingar och målmedvetenhet, vilket underlättar omfattande organisationsförändringar. Dessa ledare uppmuntrar sina team att arbeta mot ett gemensamt mål genom sin vision, värderingar, kommunikation, exempel-inställning och deras uppenbara omsorg för sina efterföljares personliga behov.

Det som jag tycker är extra intressant med artikeln är just vilka karaktäristika egenskaper som effektiva ledare har för att genomföra transformeringar. Ledarna är ju mycket riktigt de som sätter tonen i organisationen och befäster önskade kulturella normer.

  • Vision. Har ett tydligt begrepp om var organisationen går och var den ska vara om fem år.
  • Inspirerande kommunikation. Kommunicerar på ett sätt som inspirerar och motiverar, även i en osäker eller föränderlig miljö.
  • Intellektuell stimulans. Utmaningar som följer efter att tänka på problem på nya sätt.
  • Stödjande ledarskap. Påvisar vård och hänsyn till efterföljarnas personliga behov och känslor.
  • Personligt erkännande. Säkerställer att mål och förbättringar av arbetskvaliteten uppnås. Ger personligen komplimanger till andra när de gör enastående arbete.

Men det är inte ledarens transformationsegenskaper som ensamt möjliggör transformeringen, utan det beror även på en lämplig arkitektur, god teknisk praxis, användning av agila/lean management principer. Bra ledare hjälper bygga högpresterande teams. Vidare så belyser artikeln en tydlig korrelation mellan transformationsledarskap och högpresterande teams. Analysen fann också att transformationsledarskapet är starkt korrelerat med Net Promoter Score (NPS).

State of DevOps har även andra bra artiklar, bland annat om Lean product management, så om du inte redan har hämtat hem rapporten så rekommenderar jag att hämta hem och läsa igenom… mycket nöje :)

 

 


För att vinna i schack så räcker det inte att vara mästare på en pjäs – exempelvis mycket bra på att positionera löparen. För att vinna så behöver man se till helheten, både kortsiktigt och långsiktigt. Så är det även med DevOps…

Schack vs. DevOps

Mången äro de som har spelat schack under dess 1500 år långa historia. Med dåtida gamification så tränade krigsherrar strategiskt och taktiskt tänkande över ett bräde med pjäser med specifika förmågor för att förmå att besegra sina motståndare på slagfältet. Från en tid då besegra fiendens kung var målet till en tid då det handlar om anpassning och digital transformation för att vinna kundens hjärta. Vår tids arena handlar om digitalisering och snabba anpassningar men i stora drag är modellen den samma – vi vill vinna.

För att vinna i Schack så räcker det inte att vara mästare på en pjäs – exempelvis mycket bra på att positionera löparen. För att vinna så behöver man se till helheten, både kortsiktigt och långsiktigt. Så är det även med DevOps då det inte räcker med att vara en fullstacksutvecklare med Zlatankapacitet i kodande. Detta för att det inte är en uppgift för enskilda resurser utan ett samarbete mellan flera discipliner (pjäser) som behöver orkestreras med precision likt en symfoniorkester dirigeras. Varje drag leder till en senare konsekvens som behöver vägas in före exekvering, med ambitionen att nå optimala förutsättningar och scenarion där IT-projekten möter affärsbehoven och de strategiska målen.

Varje parti Schack genomgår en livscykel bestående av 3 faser – Strategisk (Öppning), Taktisk (Mittspel) och Operativ (Slutspel). Genom att bryta ner livscykeln i faser så blir det kommunicerbart kring var man har utvecklingspotential. Att spela Schack på tid gör att man kan träna på att lägga proportionerligt med tid på faser och mäta hur man ligger till mot tidigare mätpunkter. Att mäta aktiviteter i utvecklingsprojekten innebär att man får mätpunkter och beslutsunderlag för framtida förbättringar och bättre kan anpassa situationen till sin fördel.

 

Öppning – Strategi

Nybörjare i Schack spelar ofta ut sina starkaste pjäser först, med tanken att göra en snabb schackmatt. Mer rutinerade spelare bygger upp en position efter en utstuderad strategi utan att förlora tempo genom att behöva flytta samma pjäs flera gånger under öppningen. Precis som i Schack så ser man att mer rutinerade IT-projekt har utarbetade planer och strategier för hur man skall hantera hela livscykeln och försöker leverera värde utan att behöva skapa samma värde flera gånger, dvs. inget nytt värde.

Stormästare i Schack spenderar mycket tid på öppningsstudier och motståndares tidigare partier. Att studera tidigare lärdomar från lyckade och misslyckade projekt är viktigt för att få en bra projektstart. Det är även viktigt att planera för förvaltning tidigt då det är i projektstarten man sätter förutsättningar för hur väl resultatet och effekter uppnås senare i livscykeln.

Genom att tidigt sätta upp arkitektur, integrationer och processer för automation och samarbete så säkerställer man tidigt att det som levereras samt överlämningar från olika discipliner fungerar smidigt och taktas efter förmåga. Man vill tidigt veta vad som fungerar då det är svårare att ändra strategier ju fler drag man har genomfört. Strategier måste integrera tekniken med affärinitiativen, Schack utan bra öppning är som DevOps utan strategi och styrning.

 

Mittspel – Taktik (Dev)

Mittspelet i Schack handlar om att lämna tryggheten från förberedda studier och taktiskt anpassa sig till rådande situation. Genom att rent psykologiskt läsa och påverka sin inre röst och motståndare genom undermineringar, taktiska fällor och små vinster. Genom att kontinuerligt utvärdera hur det går och om det finns några möjligheter eller problem så kan projektet bli mer adaptivt och teamet får en högre grad av överlappning och transparens i varandras roller vilket leder till naturlig kompetensöverföring och mindre risker. En svaghet är inte en svaghet om den inte går att attackera och tidig attack kan vara bästa försvaret.

Man försöker hitta positioner och ställningar som känns bra givet förutsättningar, så även i DevOps där man försöker få byggen att gå igenom tester och färdiga bitar distribuerade hela vägen och kontinuerligt övervaka, förfina och optimera flaskhalsar.

 

Slutspel – operativt (Ops)

Nu är vinsten i sikte – det är inte så mycket pjäser kvar på brädet och spelet går in i en mer operativ fas, där det gäller att kunna förutse vägen till vinsten. Projektet är nu i slutfasen och det gäller att få acceptans från kund och för förvaltningsorganisationen att säkerställa effektmål, förutsättningarna för vidareutveckling blir avgörande.

Mästaren är den med förmågan att kunna räkna hem vinstgivande drag med en tvingande serie drag. Ett bagage av svaga tidigare drag gör det avsevärt svårare att hitta rätt drag. Inte alla IT-projekt når denna fas, då de ibland faller platt under tidigare faser, men med bra verktyg för att mäta Teknisk Skuld genom kodanalys och bra arkitektur och dokumentation erbjuder en enklare acceptans och kan påvisa rätt kvalitet på rätt element – varken mer eller mindre utan precis på målet. Det är genom att motverka teknisk skuld som vi kan fortsatt vara agila och flexibla i framtiden.

 

Summering

Ett vanligt talesätt bland schackspelare är – Hotet är starkare än genomförandet. Tanken är att genom att hota med ett drag, så kan man påverka sin motståndare i en viss riktning som medför mer tankeverksamhet än att faktiskt utföra draget. Vi är människor med mänskliga relationer och utan tydlig kommunikation och tillit så kan hotet mot leveranser och överlämningar blir starkare än önskat.

Att inte göra något drag alls i en värld som digitaliseras blir en snabb schackmatt.

Det är genom DevOps som vi levererar moderna digitala lösningar, vi startar med en Strategi och en tydlig målbild för att sedan adaptivt och agilt hantera Taktiska faser och överlämningar för att säkra en Operativ seger och långsiktigt vinna våra kunders hjärtan.