AMP med fokus på mognadsbedömningar

Innan jag började på Omegapoint så frilansade jag som egen konsult parallellt med studier på KTH. Som egen junior konsult var det svårt att hitta uppdrag jag tyckte var intressanta och jag tyckte också att jag saknade en större gemenskap. Jag hittade Omegapoint och deras kompetenskultur genom att jag var med på studentkonferensen och började min karriär och kompetensresa på Omegapoint för 3 år sedan, då som deltagare i Academy Professional Program.

Under mina tre år på Omegapoint har jag varit hos två kunder under längre perioder men också fått möjligheten att delta på en rad Technical Due Diligence av olika bolag. Under en Technical Due Diligence analyserar man ett bolags mognadsnivå i en rad olika områden, ofta på uppdrag av en investerare. Jag tyckte sådana bedömningar var väldigt roliga att genomföra, man får under en intensiv period inblick i hur ett bolag ser på utvecklingen av sin produkt, vilka bekymmer de har och hur de tacklar just sin branschs utmaningar. Det fick mig också att tänka på hur vi sprider kunskapen om att göra sådana bedömningar, hur vi vidareutvecklar vår produkt och att vi borde göra sådana mognadsbedömningar på våra befintliga kunder och våra egna team.

Dessa frågor fick mig att söka till Academy Masters Program (AMP) och påbörja mitt andra stora kompetensskutt på Omegapoint!

Mina mål med AMP

• Att själv bli expert på tekniska mognadsbedömningar

• Att ta leadroller ute hos kund och att kunna hjälpa kunden att förbättra sin organisations förmåga att leverera mjukvara snabbt och säkert

• Att bidra till kvaliteten och täckningen av Omegapoints tekniska bedömningar

• Att bidra till kunskapsspridningen inom Omegapoint inom området

Hur jag försöker uppnå målen

Det finns redan en uppsjö best practices och modeller för mognadsbedömningar av alla de slag. Jag började min resa genom att studera exempelvis OWASP OpenSAMM och utfallen från DORA State of DevOps. En observation som jag gjorde då var att det var blandad abstraktionsnivå på modellerna, en del är så abstrakta att det är svårt att förstå vad de egentligen menar, andra så specifika att de riskerar vara utdaterade innan mina 18 månader i AMP är över. Dessutom låg tonvikt på väldigt olika områden, State of Devops fokuserar på devops och kulturen kring det området, OpenSAMM fokuserar på säkerhet. Vissa modeller tog inte någon hänsyn alls till vart subjektet i fråga befann sig i för fas eller bransch. Ytterligare en aspekt jag tyckte jag behövde väva in är vad de som redan jobbade på Omegapoint som experter i exempelvis säkerhetsområdet tyckte.

Min hypotes blev att det är bättre att vi utvecklar vår egna modell som passar väl in i ramen hur vi vill utföra just den här typen av bedömningar. Modellen lånar friskt från andra modeller och våra egna experters erfarenheter. Den består av ett gäng olika capabilities vi tycker ett bolag bör ha, förklaring om vad vi menar i detalj, vanliga misstag man gör, när just denna capabilityn inte är applicerbar och ett gäng frågor för att stötta under intervjuprocessen. Planen är att successivt provköra modellen och iterera fram något vi blir nöjda med. Men jag tror det blir lättast att förklara med ett litet exempel hur en intervju går till, där intervjufrågorna och våra rekommendationer baserar sig på modellen:

Startupen ACME AB förmedlar en B2B tjänst där företag snabbt kan beställa in närmsta tillgängliga reparatör för att fylla på och laga kaffemaskiner. ACME AB är live och har nu ett hundratal kunder och fyra leverantörer av reparationstjänster. Bolaget består av fyra anställda, CEO som sköter ekonomi och marknadsföring, CTO Ragnar som dessutom är utvecklare och skrivit det mesta av kodbasen, en webutvecklare och en testare. Vi har bara fått en dag för bedömningen och intervjuar här Ragnar om testdata:

A: “Hur hanterar ni er testdata?”

R: “Ja du, bra tycker jag. Vi har ett skript som drar ned den, tvättar bort kunddatan och så trycker vi in datan i testmiljön”

A: “Okej, går det att köra testen lokalt också?”

R: “Ja, det är bara att man kör skriptet på sin utvecklingsmaskin. Alla utvecklare kör skriptet, vi behöver ju datan för att kunna testa”

A: “Hur mycket data snackar vi om?”

R: “Ungefär 1 TB, alltså, det inkluderar ju all data om användarbeteende som vi samlar in i webportalen, det är därför det blir så mycket”

A: “Okej, använder ni den datan till något? Beror några tester på den?”

R: “Nja, inte än, men vi har stora planer att bli en data driven dynamisk tjänst, ser vi att användaren darrar med musen exempelvis, vill vi framhäva nödknappen för att beställa en kaffemaskinsreparatör”

A: “Berätta mer om hur ni anonymiserar datan…”

Det kan ta tid att utreda alla aspekter av hur ACME AB hanterar sin test data, så vi nöjer oss här och fokuserar mer på vad vi skulle ge för feedback. I realtiteten skulle man borra ned sig djupare i vissa områden och även ta en titt på skriptet Ragnar pratat om.

• ACME AB verkar bero lite väl mycket på extern data för sina tester. Ett vanligt misstag är att låta även unit tester bero på externt state som i detta fall, produktionsdata. Vi rekommenderar ACME AB att i betydligt högre grad mocka externa beroenden och att sätta upp testdatan i testerna i kod, så den blir versionerad tillsammans med testet. Vi anser detta bör göras omgående då ACME är en startup och sannolikt kommer ändra sitt dataschema mycket den närmsta tiden, det gör att risken ökar för att mycket tid och pengar måste läggas på att laga trasiga tester.

• ACME AB hämtar också ut alldeles för mycket data. 1 TB tar en stund att ladda ned och detta leder till både frustration för utvecklarna och att utvecklingshastigheten minskar. Mer specifikt påverkar detta hur lång tid det tar för en förändring att komma till produktion. I de fall ni måste bero på produktionsdata i tester bör det endast vara precis den data som är intressant för testerna. Vi anser att detta är något som borde åtgärdas omgående då det direkt påverkar värdet era utvecklare kan producera.

• Vad gäller anonymisering av data…

För att återkoppla lite till målen så tror jag att även om vi finner att det var en mindre fantastisk idé att försöka utveckla en egen modell, så kommer jag själv komma en bra bit på väg mot att bli expert genom modellens utvecklande. Jag kommer också få praktiskt erfarenhet genom att genomföra ännu fler bedömningar där jag driver bedömningarna själv i högre grad, vilket kommer hjälpa mot målet att ta mer lead ute på uppdrag. Då jag kontinuerligt har interna workshops i området så bidrar jag till vår interna kunskapsspridning. Visar sig modellen dessutom fungera bra så tror jag att det går att göra Omegapoints tekniska bedömningar ännu ett snäpp vassare.