En riskabel affär

“Är du redo?”

Så redo som jag kan bli, tänker jag medan jag går igenom min mentala checklista en sista gång.

Pilot: Skosnören, benremmar, bröstremmar, handskar, radio, hakrem, check.

Linor: Alla fria och obehindrade, vänster över höger så att jag kan vända mig till sidan som jag föredrar, check.

Vinge: Framkanten är öppen och fint utbredd som en hästsko, check.

Vind: En lätt bris är på väg upp, lite för svag för en omvänd start. Jag bestämmer mig för att vänta ut den i några minuter.

“Välj ditt ögonblick.”

Jag nickar till instruktören medan jag tittar på vindflöjeln. Efter ytterligare en minut känner jag hur vinden tilltar lite. Vindflöjeln ser bra ut. Jag väntar några sekunder för att se om den håller. Det gör den.

Vind: check.

Luftrum: Inga andra skärmflyg flyger nära start och inga andra skärmflyg är redo för start, check.

Jag tar ett djupt andetag... “START!”, jag drar A-höjarna mot mig själv. Vingen blåser upp när den reser sig. Jag släpper höjarna och drar i bromsarna för att få den att stanna ovanför mig. Vingens form ser bekant ut, bra. Det finns inga synliga knutar, utmärkt. En vindpust vänder vingen något. Den är inte längre centrerad rakt ovanför mig. Ska jag abortera? Jag bromsar lite för att peka vingen framåt och tar två steg för att ta mig in under vingen igen. Vingen lägger sig. Jag håller kvar vingen i den här positionen i några sekunder för att verifiera att jag har kontroll över den. Med vingen nere är det grönt ljus. Jag håller ett konstant tryck på bromsarna medan jag vänder mig själv 180 grader. Efter en kort sprint känner jag hur benremmarna dras åt när vingen drar upp mig från marken.

Jag flyger.

Du har gissat rätt; jag har en riskabel hobby. Det innebär att jag tar risker, eller hur? Nja, typ. Men också inte! Som skärmflygare spenderar jag en betydande mängd med energi på att minska risker. Med gedigna förberedelser och goda marginaler får jag ner risken till en acceptabel nivå. Därför är 'risk manager' en bättre term.

Ingen risk, ingen affär

Detta för mig till ämnet i fråga: riskhantering inom mjukvaruutveckling. Mer specifikt, hur hanterar vi våra risker så att vi med säkerhet kan driftsätta förbättringar utan stress? Att driftsätta mjukvara liknar trots allt en skärmflygsstart. Båda är ögonblick där risker kan förverkligas till faktiska problem.

Tyvärr är det enda sättet att helt och hållet eliminera risker att undvika dem. Sluta skärmflyga eller, på motsvarande sätt, sluta driftsätta programvaruförbättringar. Det första kan faktiskt vara ett sunt val. Men det andra, ja, några risker får vi bara leva med. Men vi kan fortfarande minska risken, så hur gör vi det på Easy LMS?

Tyvärr är det enda sättet att helt och hållet eliminera risker att undvika dem

Vad är en risk egentligen?

En risk är en händelse som har en viss sannolikhet att inträffa och en viss (negativ) påverkan. Kombinationen av sannolikhet och påverkan avgör hur hög risken är. Så en händelse som med stor sannolikhet kommer att inträffa och har en stor (negativ) inverkan är en hög risk. En händelse som sannolikt inte kommer att inträffa och som har en mycket begränsad påverkan är en låg risk. Om sannolikheten och/eller påverkan blir högre ökar risken och vice versa.

Att hantera risk

Eftersom risk är en kombination av sannolikhet och påverkan, följer det att att du kan göra följande för att minska en risk:

• Minska sannolikheten att det inträffar (se till att det händer mer sällan).
• Minska påverkan (se till att det inte spelar så stor roll om det händer).
• Gör båda.

Som skärmflygare kan vi t.ex. överväga risken att jag kraschar efter att ha startat med en otäck knut i mina linor. Jag minskar denna risk, genom att bl.a.:

• Alltid följa samma startprocedur (minska sannolikheten).
• Bära hjälm (minska påverkan).

Att kombinera alla åtgärder ger mig tillräckligt med självförtroende för att gladeligen springa mot bergskanten. Jag litar på min förberedelse, kompetens, utrustning och mitt beslutsfattande. Risken finns fortfarande kvar, men jag har minskat den till en nivå som jag är villig att acceptera. Vid skärmflygning kommer starten alltid vara ett laddat ögonblick för mig. Det kräver att jag är alert. Men jag är inte stressad.

På samma sätt har vi åtgärder på plats på Easy LMS för att hantera risker och hålla oss lugna. Låt oss överväga risken med att buggar introduceras till systemet när en ny funktion släpps. Vi minimerar denna risk på två sätt:

• Utöva testdriven utveckling (TDD)
• Arbeta i korta iterationer

Vi har åtgärder på plats på Easy LMS för att hantera risker och hålla oss lugna

Så hur hjälper dessa åtgärder oss på Easy LMS?

Testdriven utveckling (TDD)

Testdriven utveckling, eller TDD, är att skriva ett automatiserat test för det önskade beteendet hos en ny funktionalitet innan du skriver koden för själva funktionaliteten. TDD hjälper till att minska risken för att introducera buggar till vårt system, på följande sätt:

• Genom att testa beteendet i automatiska tester är det mer sannolikt att misstag upptäcks under utvecklingen.
• När man skriver test innan man skriver kod, fångas misstag upp tidigare i utvecklingsprocessen.
• Att skriva tester innan man skriver kod tvingar utvecklaren att tänka på hur man testar det önskade beteendet oberoende av den slutliga koden.
• Att skriva testbar kod är lite som att skriva en läsbar bok. Det tvingar utvecklaren att tillämpa struktur på koden. Som ett resultat tenderar testbar kod att vara underhållbar kod.
• Genom att religiöst följa TDD bygger vi upp en testsvit över tiden, som omfattar alla tester som skrivits tidigare. Innan driftsättning kör vi alla dessa tester. Om vår nya funktionalitet orsakar problem med befintlig funktionalitet får vi reda på det.

På dessa sätt hjälper TDD till att avsevärt minska sannolikheten för att buggar introduceras i systemet.

Små iterationer

På Easy LMS, jobbar vi i små iterationer, och släpper små ändringar ofta. Vi utför ofta en eller två driftsättningar per dag. Vi gör detta i små steg, även när vi introducerar stora funktionaliteter. Detta hjälper oss på följande sätt:

• Vi får feedback från kunder mycket tidigare än om vi skulle vänta med implementeringen tills en funktion är helt "färdig". Baserat på den tidiga feedbacken kan vi enkelt ändra riktning om det behövs.
• Det är mycket lättare att återhämta sig från ett misstag om skillnaden mot den senaste stabila versionen är liten.
• Korta iterationer är lättare att planera och hantera. Ett team kan helt enkelt inte hamna så långt efter schemat. Detta leder till mindre stress och förhindrar att team känner behovet av att ta genvägar.
• Att driftsätta dagligen skapar en stark drivkraft mot en mer strömlinjeformad och tillförlitlig driftsättningsprocess. Om inte, hade plågan varit kännbar dagligen.

På dessa sätt hjälper korta iterationer till att minska sannolikheten och påverkan av att buggar introduceras i systemet.

TDD och att arbeta i små iterationer ger oss förtroende. Vi har förtroende för att det som vi håller på att driftsätta fungerar. Om det finns några problem så är de små.

Korta iterationer är enklare att planera och hantera

Unittesterna är godkända, check.

Jag flyttar biljetten till "In QA Review", som automatiskt utlöser en driftsättning till vår stagingmiljö.
Några dagar tidigare driftsatte vi en liten förändring av statusen som visas i deltagaröversikten på flera ställen i appen. Ändringen var tänkt att få statusarna att reflektera en deltagares status mer noggrannt.

Det kanske var mer noggrannt, men det var också förvirrande. Kunder som såg på den nya situationen ur sina gamla glasögon fick intrycket av att inbjudningar inte skickades ut.

Så där var jag, redo att driftsätta lösningen. Baserat på feedbacken vi fick under dagarna efter releasen har vi nu förbättrat vår ursprungliga förändring. Jag tittar på framstegen för den automatiserade driftsättningen till vår stagingmiljö, där vi utför våra sista tester innan driftsättningen.

Acceptanstestet godkänns, check.

Jag öppnar webbläsaren och navigerar till stagingmiljön för att testa ändringen en sista gång. Stagingmiljön är upprättad på samma sätt som vår liveapplikation.

Det funkar som förväntat, check.

Förändringen är liten, vilket gör testningen enkel. Unittesterna och acceptanstesterna stärker mitt förtroende ytterligare för att befintlig funktionalitet fungerar som den gjorde tidigare. Allt lyser grönt. Jag sätter igång driftsättningen.
Jag smuttar på mitt kaffe och kollar mina meddelanden medan driftsättningen körs. Jag funderar på hur förändringen ska hjälpa våra kunder. Vi kommer att checka in med support om en dag. Vi förväntar oss att kunder inte längre kommer att kontakta support angående denna status. Om vi får mer feedback är jag övertygad om att vi kommer att ha ytterligare en implementering klar den här veckan för att förbättra vår applikation mer och bygga mot våra kunders behov.

Efter några minuter lyser det sista steget i driftsättningen grönt.

Vi flyger.