"Er du klar?"
Så klar som jeg kan være, tænker jeg, mens jeg gennemgår min mentale tjekliste en sidste gang.
Pilot: Snørebånd, benremme, brystrem, handsker, radio, hagerem, tjek.
Linjer: Alle frie og uhindrede, venstre over højre, så jeg kan dreje til min foretrukne side, tjek.
Vinge: Forkanten er åben og spredt pænt ud i en hesteskoform, tjek.
Vind: Der kommer en let brise, lidt for svag til en baglæns start. Jeg beslutter at vente et par minutter.
"Vælg dit øjeblik."
Jeg nikker til instruktøren, mens jeg kigger på vindfløjen. Efter endnu et minut kan jeg mærke, at vinden tager lidt til. Vindfløjen ser godt ud. Jeg venter et par sekunder for at se, om det varer ved. Det gør den.
Vind: tjek.
Luftrum: Ingen andre svævefly i nærheden af start og ingen andre svævefly klar til start, tjek.
Jeg tager en dyb indånding... "START!", jeg trækker A-tragterne mod mig. Vingen pustes op, mens den stiger. Jeg slipper stigrørene og trækker i bremserne for at bringe den til standsning over mig. Vingens form ser bekendt ud, godt. Der er ingen synlige knuder, fremragende. Et vindstød drejer vingen en smule. Den er ikke længere centreret over mig. Skal jeg afbryde? Jeg bremser lidt for at få vingen til at pege fremad og tager to skridt for at komme ind under vingen igen. Vingen lægger sig til rette. Jeg holder vingen i denne position i et sekund eller to for at bekræfte, at jeg har kontrol. Når vingen er faldet til ro, er alle tegn nu grønne. Mens jeg holder konstant pres på bremserne, drejer jeg mig selv 180 grader. Efter en kort sprint mærker jeg, at benstropperne strammes, mens vingen trækker mig væk fra jorden.
Jeg flyver.
Du har gættet det; jeg har en risikabel hobby. Det betyder, at jeg er en risikotager, ikke? Jo, på en måde. Men også nej! Som paraglider bruger jeg en betydelig mængde energi på at mindske risici. Med solid forberedelse og sunde marginer bringer jeg risikoen ned på et acceptabelt niveau. Derfor er et bedre udtryk risikomanager.
Tjek vores ledige stillinger
Ingen risiko, ingen forretning
Det bringer mig til det aktuelle emne, risikostyring i softwareudvikling. Mere specifikt, hvordan styrer vi vores risici, så vi med sikkerhed kan implementere forbedringer uden stress? Når alt kommer til alt, er implementering af software lidt det samme som en paragliding-lancering. I begge tilfælde er der stor sandsynlighed for, at risici materialiserer sig i faktiske problemer.
Desværre er den eneste måde at eliminere alle risici på at undgå dem helt. Stop paragliding eller, tilsvarende, stop implementeringen af softwareforbedringer. Det første er faktisk et godt valg. Det andet, ja, nogle risici må vi bare leve med. Men vi kan stadig reducere risikoen, så hvordan gør vi det hos Easy LMS?
Desværre er den eneste måde at eliminere alle risici på at undgå dem helt.
Hvad er risiko overhovedet?
En risiko er en begivenhed med en sandsynlighed for at indtræffe og en bestemt (negativ) effekt. Kombinationen af sandsynlighed og effekt afgør, hvor høj en risiko er. Så en begivenhed, der med stor sandsynlighed vil ske og have en stor (negativ) indvirkning, er en høj risiko. En begivenhed, der sandsynligvis ikke vil ske, og som har en meget begrænset indvirkning, er en lav risiko. Hvis sandsynligheden og/eller konsekvenserne bliver større, øges risikoen og omvendt.
Håndtering af risici
Da risiko er en kombination af sandsynlighed og konsekvens, følger det, at man kan reducere en risiko:
Sænk sandsynligheden for, at det sker (sørg for, at det sker sjældnere).
Sænk konsekvenserne (sørg for, at det ikke er en stor ting, hvis det sker).
Gør begge dele.
Som paraglider kan jeg f.eks. overveje risikoen for, at jeg styrter ned, fordi jeg starter med en grim knude i mine liner. Jeg reducerer blandt andet denne risiko ved:
Kombinationen af alle foranstaltninger giver mig selvtillid nok til at løbe glad ned mod bjergets kant. Jeg stoler på min forberedelse, mine færdigheder, mit udstyr og mine beslutninger. Risikoen er der stadig, men jeg har reduceret den til et niveau, jeg er villig til at acceptere. Når jeg paraglider, vil starten altid være et anspændt øjeblik for mig. Det kræver, at jeg er opmærksom. Men jeg er ikke stresset.
På samme måde har vi foranstaltninger på plads hos Easy LMS for at styre risici og holde os i ro. Lad os se på risikoen for at introducere fejl i systemet, når vi frigiver en ny funktion. Der er to måder, hvorpå vi minimerer denne risiko:
Vi har foranstaltninger på plads hos Easy LMS for at styre risici og holde os i ro
Så hvordan kan disse tiltag hjælpe os hos Easy LMS?
Testdrevet udvikling (TDD)
Test Driven Development, eller TDD, er den praksis, hvor man skriver en automatiseret test af den ønskede opførsel af en ny funktionalitet, før man skriver koden til selve funktionaliteten. TDD hjælper med at reducere risikoen for, at vi introducerer fejl på følgende måder:
Ved at teste adfærden i automatiske tests er der større sandsynlighed for, at fejl opdages under udviklingen.
Fejl opdages tidligere i udviklingsprocessen ved at skrive tests, før koden skrives.
At skrive tests, før koden skrives, tvinger udvikleren til at tænke over, hvordan man tester den ønskede adfærd uafhængigt af den endelige kode.
At skrive testbar kode er lidt som at skrive en læselig bog. Det tvinger udvikleren til at anvende struktur på koden. Som følge heraf har testbar kode en tendens til at være vedligeholdelsesvenlig kode.
Ved religiøst at følge TDD opbygger vi over tid en testsuite, der omfatter alle tests, der er skrevet tidligere. Før udrulning kører vi alle disse tests. Hvis vores nye funktionalitet skaber et problem med eksisterende funktionalitet, vil vi vide det.
På disse måder hjælper TDD med at reducere sandsynligheden for at introducere fejl i systemet.
Små iterationer
Hos Easy LMS arbejder vi i små iterationer og frigiver ofte små ændringer. Vi udfører ofte en eller to implementeringer om dagen. Vi gør det i små trin, selv når vi introducerer et stort stykke funktionalitet. Det hjælper os på følgende måde:
Vi får feedback fra kunderne meget tidligere, end hvis vi skulle vente med udrulningen, til en funktion er helt "færdig". På baggrund af den tidlige feedback kan vi nemt ændre retning, hvis det er nødvendigt.
Det er meget nemmere at komme sig over en fejl, hvis forskellen til den sidste stabile version er lille.
Korte iterationer er nemmere at planlægge og styre. Et team kan simpelthen ikke komme bagud i forhold til tidsplanen i længere tid. Det fører til mindre stress og forhindrer teams i at føle behov for at skære hjørner.
Daglig udrulning skaber en stærk drivkraft mod en mere strømlinet og pålidelig udrulningsproces. Hvis ikke, ville vi føle smerten hver dag.
På den måde er korte iterationer med til at reducere sandsynligheden for og konsekvenserne af, at der bliver introduceret fejl i systemet.
TDD og arbejdet i små iterationer giver os selvtillid. Vi bliver styrket i vores tro på, at det, vi er ved at implementere, fungerer. Hvis der er problemer, vil de være små.
Korte iterationer er nemmere at planlægge og styre
Unit-tests er grønne, tjek..
Jeg flytter sagen til 'I QA-review', hvilket automatisk udløser en implementering i vores staging-miljø.Et par dage tidligere implementerede vi en lille ændring i de statusser, der vises i deltageroversigten flere steder i appen. Ændringen skulle få statusserne til at afspejle en deltagers status mere præcist.
Det var måske mere præcist, men det var også forvirrende. Kunder, der så på den nye situation med gamle briller, fik det indtryk, at der ikke blev sendt invitationer ud.
Nu stod jeg her, klar til at implementere løsningen. Baseret på den feedback, vi fik i dagene efter udgivelsen, forbedrede vi nu vores oprindelige ændring. Jeg ser på forløbet af den automatiserede udrulning til vores staging-miljø, hvor vi udfører vores sidste test før udrulning.
Akcepttestene bliver grønne, tjek..
Jeg åbner browseren og navigerer til staging-miljøet for at teste ændringen en sidste gang. Staging-miljøet er sat op på samme måde som vores live-applikation.
Det virker, som jeg forventer, tjek..
Ændringen er lille, hvilket gør det nemt at teste. Enhedstestene og accepttestene styrker yderligere min tillid til, at den eksisterende funktionalitet fungerer som før. Alle lys er grønne. Jeg starter udrulningen.
Jeg tager en slurk af min kaffe og tjekker mine beskeder, mens udrulningen kører. Jeg tænker på, hvordan ændringen skal hjælpe vores kunder. Vi tjekker med supporten om en dags tid. Vi forventer, at kunderne ikke længere vil kontakte supporten om denne status. Hvis vi får mere feedback, er jeg sikker på, at vi vil have en ny implementering klar i denne uge for yderligere at forbedre vores applikation og bygge videre på vores kunders behov.
Efter et par minutter bliver det sidste trin i implementeringen grønt..
Vi flyver.
Tjek vores ledige stillinger
