"Er du klar?"
Så klar som jeg kan være, tenker jeg mens jeg går gjennom den mentale sjekklisten min en siste gang.
Pilot: Skolisser, benstropper, bryststropp, hansker, radio, hakestropp, sjekk.
Linjer: Alle er frie og uhindret, venstre over høyre slik at jeg kan svinge til min foretrukne side, sjekk.
Vinge: Forkanten er åpen og sprer seg fint ut i en hesteskoform, sjekk.
Vind: Det blåser opp en lett bris, litt for svak for en bakkestart. Jeg bestemmer meg for å vente noen minutter.
"Velg ditt øyeblikk."
Jeg nikker til instruktøren mens jeg følger med på vindfløyen. Etter et minutt til kjenner jeg at vinden tar seg litt opp. Vindfløyen ser bra ut. Jeg venter noen sekunder for å se om det varer. Det gjør den.
Vind: sjekk.
Luftrom: Ingen andre seilfly i nærheten av oppskytingen og ingen andre seilfly klare for oppskyting, sjekk.
Jeg trekker pusten dypt... "START!" Jeg trekker A-løftet mot meg. Vingen blåses opp mens den stiger. Jeg slipper stigerørene og trekker i bremsene for å få den til å stoppe over meg. Formen på vingen ser kjent ut, bra. Det er ingen synlige knuter, utmerket. Et vindkast snur vingen litt. Den er ikke lenger sentrert over meg. Skal jeg avbryte? Jeg bremser litt for å rette vingen mot fronten, og tar to skritt for å komme inn under vingen igjen. Vingen legger seg til rette. Jeg holder vingen i denne posisjonen i et sekund eller to for å forsikre meg om at jeg har kontroll. Når vingen har satt seg, er alle tegn nå grønne. Mens jeg holder et konstant trykk på bremsene, snur jeg meg 180 grader. Etter en kort sprint kjenner jeg at benstroppene strammer seg idet vingen drar meg opp fra bakken.
Jeg flyr.
Du har gjettet det; jeg har en risikofylt hobby. Det betyr at jeg er en risikotaker, ikke sant? Vel, ja, på en måte. Men også nei! Som paraglider bruker jeg mye energi på å redusere risikoen. Med solide forberedelser og gode marginer får jeg risikoen ned på et akseptabelt nivå. Derfor er et bedre begrep risikostyrer.
Se de ledige stillingene våre
Ingen risiko, ingen virksomhet
Dette bringer meg over til det aktuelle temaet, nemlig risikostyring i programvareutvikling. Mer spesifikt, hvordan håndterer vi risikoene våre slik at vi trygt kan distribuere forbedringer uten stress? Når alt kommer til alt, er distribusjon av programvare litt som en paragliding-lansering. I begge tilfeller er det sannsynlig at risikoer kan materialisere seg i faktiske problemer.
Dessverre er den eneste måten å eliminere alle risikoer på å unngå dem helt og holdent. Slutt å fly paraglider, eller, tilsvarende, stopp utrullingen av programvareforbedringer. Det første er faktisk et gyldig valg. Det andre, vel, noen risikoer må vi bare leve med. Men vi kan fortsatt redusere risikoen, så hvordan gjør vi det hos Easy LMS?
Dessverre er den eneste måten å eliminere alle risikoer på å unngå dem helt og holdent
Hva er egentlig risiko?
En risiko er en hendelse som har en viss sannsynlighet for å inntreffe og en bestemt (negativ) konsekvens. Kombinasjonen av sannsynlighet og konsekvens avgjør hvor høy en risiko er. En hendelse som har stor sannsynlighet for å inntreffe og som har store (negative) konsekvenser, er altså en høy risiko. En hendelse som er usannsynlig og har svært begrensede konsekvenser, er en lav risiko. Hvis sannsynligheten og/eller konsekvensene blir større, øker risikoen, og omvendt.
Håndtering av risiko
Siden risiko er en kombinasjon av sannsynlighet og konsekvens, følger det at du kan redusere en risiko:
Som paraglider kan jeg for eksempel tenke på risikoen for at jeg krasjer fordi jeg starter med en stygg knute i linen. Jeg reduserer denne risikoen blant annet ved å
Kombinasjonen av alle tiltakene gir meg nok selvtillit til å løpe lykkelig ned mot fjellkanten. Jeg stoler på forberedelsene, ferdighetene, utstyret og beslutningene mine. Risikoen er der fortsatt, men jeg har redusert den til et nivå jeg er villig til å akseptere. Når jeg paraglider, vil starten alltid være et anspent øyeblikk for meg. Det krever at jeg er på vakt. Men jeg er ikke stresset.
På samme måte har vi i Easy LMS iverksatt tiltak for å håndtere risiko og holde oss rolige. La oss se på risikoen for å introdusere feil i systemet når vi lanserer en ny funksjon. Vi minimerer denne risikoen på to måter:
Vi har tiltak på plass hos Easy LMS for å håndtere risiko og holde oss rolige
Så hvordan kan disse tiltakene hjelpe oss i Easy LMS?
Testdrevet utvikling (TDD)
Testdrevet utvikling, eller TDD, innebærer at man skriver en automatisert test for den ønskede oppførselen til en ny funksjonalitet før man skriver koden for selve funksjonaliteten. TDD bidrar til å redusere risikoen for at vi introduserer feil på følgende måter:
Ved å teste oppførselen i automatiske tester er det større sannsynlighet for at feil oppdages under utviklingen.
Feil oppdages tidligere i utviklingsprosessen ved å skrive tester før koden skrives.
Å skrive tester før koden skrives tvinger utvikleren til å tenke på hvordan den ønskede oppførselen skal testes uavhengig av den endelige koden.
Å skrive testbar kode er litt som å skrive en leselig bok. Det tvinger utvikleren til å strukturere koden. Som et resultat har testbar kode en tendens til å være vedlikeholdbar kode.
Ved å følge TDD religiøst bygger vi opp en testsuite over tid, som består av alle tester som er skrevet tidligere. Før distribusjon kjører vi alle disse testene. Hvis den nye funksjonaliteten vår skaper problemer med eksisterende funksjonalitet, får vi vite det.
På disse måtene bidrar TDD til å redusere sannsynligheten for å introdusere feil i systemet.
Små iterasjoner
Hos Easy LMS jobber vi i små iterasjoner og lanserer små endringer ofte. Vi utfører ofte en eller to distribusjoner per dag. Vi gjør dette i små steg, selv når vi introduserer en stor funksjonalitet. Dette hjelper oss på følgende måte:
Vi får tilbakemeldinger fra kundene mye tidligere enn om vi skulle vente med utrullingen til en funksjon er helt "ferdig". Basert på de tidlige tilbakemeldingene kan vi enkelt endre retning hvis det er nødvendig.
Det er mye lettere å komme seg etter en feil hvis forskjellen fra den siste stabile versjonen er liten.
Korte iterasjoner er enklere å planlegge og administrere. Et team kan rett og slett ikke komme på etterskudd i særlig lang tid. Dette fører til mindre stress og hindrer teamene i å føle behov for å ta snarveier.
Distribusjon daglig skaper en sterk drivkraft mot en mer strømlinjeformet og pålitelig distribusjonsprosess. Hvis ikke, ville vi føle smerten hver dag.
På denne måten bidrar korte iterasjoner til å redusere sannsynligheten for og konsekvensene av at feil blir introdusert i systemet.
TDD og det å jobbe i små iterasjoner gir oss selvtillit. Vi blir styrket i troen på at det vi er i ferd med å implementere, fungerer. Hvis det er noen problemer, vil de være små.
Korte iterasjoner er enklere å planlegge og administrere
Enhetstester er grønne, sjekk.
Jeg flytter saken til "I QA-gjennomgang", noe som automatisk utløser en distribusjon til staging-miljøet vårt.
Et par dager tidligere distribuerte vi en liten endring i statusene som vises i deltakeroversikten flere steder i appen. Endringen skulle gjøre at statusene gjenspeiler statusen til en deltaker mer nøyaktig.
Det var kanskje mer presist, men det var også forvirrende. Kunder som så på den nye situasjonen med gamle briller, fikk inntrykk av at det ikke ble sendt ut invitasjoner.
Nå var jeg klar til å distribuere løsningen. Basert på tilbakemeldingene vi fikk i dagene etter lanseringen, hadde vi nå forbedret den opprinnelige endringen. Jeg ser på fremdriften i den automatiserte distribusjonen til staging-miljøet vårt, der vi utfører de siste testene før distribusjon.
Akseptansetestene blir grønne, sjekk.
Jeg åpner nettleseren og navigerer til staging-miljøet for å teste endringen en siste gang. Staging-miljøet er satt opp på samme måte som live-applikasjonen vår.
Det fungerer som jeg forventer, sjekk.
Jeg tar en slurk av kaffen og sjekker meldingene mine mens distribusjonen kjører. Jeg tenker på hvordan endringen skal hjelpe kundene våre. Vi tar kontakt med kundestøtte om en dag. Vi regner med at kundene ikke lenger vil kontakte kundestøtte angående denne statusen. Hvis vi får flere tilbakemeldinger, er jeg sikker på at vi vil ha en ny distribusjon klar denne uken for å forbedre applikasjonen ytterligere og bygge videre på kundenes behov.
Etter noen minutter blir det siste trinnet i distribusjonen grønt.
Vi flyr.
Se de ledige stillingene våre
