"Ben je klaar?"
Zo klaar als maar kan, denk ik terwijl ik mijn mentale checklist nog een laatste keer doorloop.
Piloot: Schoenveters, beenriemen, borstriem, handschoenen, radio, kinriem, check.
Lijnen: Allemaal vrij en ongehinderd, links over rechts zodat ik naar mijn voorkeurskant kan draaien, check.
Vleugel: De voorrand is open en mooi uitgespreid in een hoefijzervorm, check.
Wind: Er steekt een licht briesje op, een beetje te zwak voor een achterwaartse lancering. Ik besluit een paar minuten te wachten.
"Kies je moment."
Ik knik naar de instructeur terwijl ik naar de windvaan kijk. Na nog een minuut voel ik de wind wat aantrekken. De windwijzer ziet er goed uit. Ik wacht een paar seconden om te zien of het aanhoudt. Dat doet het.
Wind: check.
Luchtruimte: Geen andere zweefvliegtuigen in de buurt van de lancering en geen andere zweefvliegtuigen klaar voor de lancering, check.
Ik haal diep adem... "START!", ik trek de A-richters naar me toe. De vleugel blaast zich op terwijl hij stijgt. Ik laat de stijgijzers los en trek aan de remmen om hem boven me tot stilstand te brengen. De vorm van de vleugel komt me bekend voor, goed. Er zijn geen knopen zichtbaar, uitstekend. Een windvlaag draait de vleugel iets. Hij is niet langer gecentreerd boven me. Moet ik afbreken? Ik trap wat op de rem om de vleugel naar voren te richten en zet twee stappen om mezelf weer onder de vleugel te brengen. De vleugel nestelt zich. Ik houd de vleugel een seconde of twee in deze positie om te controleren of ik de vleugel onder controle heb. Nu de vleugel stabiel is, staan alle borden op groen. Terwijl ik constant druk op de remmen houd, draai ik mezelf 180 graden. Na een korte sprint voel ik de beenbanden aanspannen terwijl de vleugel me van de grond trekt.
Ik vlieg.
Je hebt het al geraden; ik heb een risicovolle hobby. Dat betekent dat ik een risiconemer ben, toch? Nou, ja, een beetje wel. Maar ook, nee! Als paraglider steek ik veel energie in het beperken van risico's. Met een goede voorbereiding en gezonde marges breng ik het risico terug tot een minimum. Met een goede voorbereiding en het aanhouden van gezonde marges breng ik het risico terug tot een acceptabel niveau. Daarom is een betere term risicomanager.
Bekijk onze vacatures
Geen risico, geen bedrijf
Dit brengt me bij het onderwerp waar het hier om gaat, risicobeheer bij softwareontwikkeling. Meer specifiek, hoe beheren we onze risico's zodat we met vertrouwen en zonder stress verbeteringen kunnen implementeren? Het uitrollen van software is immers vergelijkbaar met een paragliding-lancering. In beide gevallen is de kans groot dat risico's uitmonden in echte problemen.
Helaas is de enige manier om alle risico's uit te sluiten ze volledig te vermijden. Stop met paragliden of, gelijkwaardig, stop met het uitrollen van softwareverbeteringen. De eerste is eigenlijk een geldige keuze. De tweede, wel, met sommige risico's zullen we gewoon moeten leven. Maar we kunnen nog steeds risico's verminderen, dus hoe doen we dat bij Easy LMS?
Helaas is de enige manier om alle risico's uit te sluiten ze volledig te vermijden
Wat is risico eigenlijk?
Een risico is een gebeurtenis met een waarschijnlijkheid en een bepaalde (negatieve) impact. De combinatie van waarschijnlijkheid en impact bepaalt hoe hoog een risico is. Een gebeurtenis die zeer waarschijnlijk plaatsvindt en een grote (negatieve) impact heeft, is dus een hoog risico. Een gebeurtenis die onwaarschijnlijk is en een zeer beperkte impact heeft, is een laag risico. Als de waarschijnlijkheid en/of impact groter wordt, neemt het risico toe, en omgekeerd.
Risico beheren
Aangezien risico een combinatie is van waarschijnlijkheid en impact, volgt hieruit dat je een risico kunt verminderen:
Laten we als paraglider bijvoorbeeld eens kijken naar het risico dat ik neerstort omdat ik lanceer met een vervelende knoop in mijn lijnen. Ik verminder dit risico onder andere door:
De combinatie van alle maatregelen geeft me genoeg vertrouwen om vrolijk naar beneden te rennen naar de rand van de berg. Ik vertrouw op mijn voorbereiding, vaardigheden, uitrusting en besluitvorming. Het risico is er nog steeds, maar ik heb het teruggebracht tot een niveau dat ik bereid ben te accepteren. Bij het paragliden zal de lancering altijd een spannend moment voor me zijn. Het vereist dat ik alert ben. Maar ik ben niet gestrest.
Op dezelfde manier hebben we bij Easy LMS maatregelen genomen om risico's te beheersen en ons rustig te houden. Laten we eens kijken naar het risico van het introduceren van bugs in het systeem bij het uitbrengen van een nieuwe functie. Twee manieren waarop we dit risico minimaliseren zijn:
We hebben bij Easy LMS maatregelen getroffen om risico's te beheersen en ons rustig te houden
Hoe helpen deze maatregelen ons bij Easy LMS?
Testgestuurde ontwikkeling (TDD)
Test Driven Development, of TDD, is de praktijk van het schrijven van een geautomatiseerde test voor het gewenste gedrag van een nieuwe functionaliteit voordat de code voor de functionaliteit zelf wordt geschreven. TDD helpt het risico dat we bugs introduceren op de volgende manieren te verkleinen:
Door het gedrag in automatische tests te testen, is de kans groter dat fouten tijdens de ontwikkeling worden ontdekt.
Fouten worden eerder in het ontwikkelproces ontdekt door tests te schrijven voordat de code wordt geschreven.
Het schrijven van tests voordat de code wordt geschreven, dwingt de ontwikkelaar na te denken over hoe het gewenste gedrag kan worden getest, onafhankelijk van de uiteindelijke code.
Het schrijven van testbare code lijkt een beetje op het schrijven van een leesbaar boek. Het dwingt de ontwikkelaar om structuur aan te brengen in de code. Als gevolg daarvan is testbare code vaak ook onderhoudbare code.
Door TDD nauwgezet te volgen, bouwen we in de loop der tijd een testsuite op met alle tests die in het verleden zijn geschreven. Voor de implementatie voeren we al deze tests uit. Als onze nieuwe functionaliteit een probleem veroorzaakt met bestaande functionaliteit, weten we dat.
Op deze manieren helpt TDD om de kans op het introduceren van bugs in het systeem sterk te verkleinen.
Kleine iteraties
Bij Easy LMS werken we in kleine iteraties, waarbij we vaak kleine wijzigingen uitbrengen. We voeren vaak één of twee implementaties per dag uit. We doen dit in kleine stappen, zelfs wanneer we een groot stuk functionaliteit introduceren. Dit helpt ons op de volgende manier:
We krijgen veel eerder feedback van klanten dan wanneer we zouden wachten met implementeren totdat een functie helemaal 'af' is. Op basis van de vroege feedback kunnen we gemakkelijk van richting veranderen als dat nodig is.
Het is veel gemakkelijker om van een fout te herstellen als het verschil met de laatste stabiele versie klein is.
Korte iteraties zijn gemakkelijker te plannen en te beheren. Een team kan eenvoudigweg geen significante vertraging oplopen. Dit leidt tot minder stress en voorkomt dat teams zich genoodzaakt voelen om te bezuinigen.
Dagelijks uitrollen zorgt voor een sterke drang naar een meer gestroomlijnd en betrouwbaar uitrolproces. Zo niet, dan zouden we de pijn dagelijks voelen.
Op deze manieren helpen korte iteraties om de kans op en de impact van bugs in het systeem te verkleinen.
TDD en het werken in kleine iteraties geven ons vertrouwen. We worden gesterkt in ons geloof dat wat we gaan implementeren werkt. Als er problemen zijn, zullen die klein zijn.
Korte iteraties zijn gemakkelijker te plannen en te beheren
Unit tests zijn groen, check.
Ik verplaats het ticket naar 'In QA Review', waardoor het automatisch wordt uitgerold naar onze staging-omgeving.Een paar dagen eerder hebben we op verschillende plaatsen in de app een kleine wijziging doorgevoerd in de statussen die worden weergegeven in het deelnemersoverzicht. De wijziging moest ervoor zorgen dat de statussen de status van een deelnemer nauwkeuriger weergaven.
Het was misschien nauwkeuriger, maar ook verwarrend. Klanten die door een oude bril naar de nieuwe situatie keken, hadden de indruk dat er geen uitnodigingen werden verstuurd.
Nu stond ik hier, klaar om de remedie te implementeren. Op basis van de feedback die we in de dagen na de release hebben ontvangen, hebben we onze oorspronkelijke wijziging nu verbeterd. Ik kijk naar de voortgang van de geautomatiseerde uitrol naar onze staging-omgeving, waar we onze laatste tests uitvoeren voor de uitrol.
De acceptatietests worden groen, check.
Ik open de browser en navigeer naar de staging-omgeving om de wijziging voor een laatste keer te testen. De staging-omgeving is op dezelfde manier opgezet als onze live applicatie.
Het werkt zoals ik verwacht, check.
De verandering is klein, wat testen gemakkelijk maakt. De eenheidstests en acceptatietests versterken mijn vertrouwen dat bestaande functionaliteit werkt zoals voorheen. Alle lichten staan op groen. Ik start de implementatie.
Ik neem een slok van mijn koffie en controleer mijn berichten terwijl de implementatie wordt uitgevoerd. Ik denk na over hoe de verandering onze klanten kan helpen. Over een dag nemen we contact op met support. We verwachten dat klanten geen contact meer zullen opnemen met support over deze status. Als we meer feedback krijgen, ben ik ervan overtuigd dat we deze week een nieuwe implementatie klaar hebben om onze applicatie verder te verbeteren en te bouwen aan de behoeften van onze klanten.
Na een paar minuten wordt de laatste stap in het programma groen.
We vliegen.
Bekijk onze vacatures
