"Bist du bereit?"
Ich bin so gut wie möglich vorbereitet, denke ich, während ich ein letztes Mal meine mentale Checkliste durchgehe.
Pilot: Schnürsenkel, Beingurte, Brustgurt, Handschuhe, Funkgerät, Kinnriemen, check.
Linien: Alle frei und ungehindert, links über rechts, so dass ich mich auf meine bevorzugte Seite drehen kann, check.
Flügel: Die Vorderkante ist offen und schön hufeisenförmig ausgebreitet, check.
Wind: Eine leichte Brise kommt auf, ein bisschen zu schwach für einen Rückwärtsstart. Ich beschließe, ein paar Minuten abzuwarten.
"Wähle deinen Moment".
Ich nicke dem Ausbilder zu und beobachte die Windfahne. Nach einer weiteren Minute spüre ich, wie der Wind ein wenig auffrischt. Die Windfahne sieht gut aus. Ich warte ein paar Sekunden, um zu sehen, ob es anhält. Das tut sie.
Wind: prüfen.
Luftraum: Keine anderen Segelflugzeuge in der Nähe des Starts und keine anderen Segelflugzeuge, die zum Start bereit sind, überprüfen.
Ich atme tief ein... "START!", ich ziehe die A-Tragegurte zu mir. Der Flügel bläst sich auf und steigt. Ich lasse die Tragegurte los und ziehe die Bremsen, um ihn über mir zum Stehen zu bringen. Die Form des Flügels kommt mir bekannt vor, gut. Es sind keine Knoten sichtbar, ausgezeichnet. Eine Windböe verdreht den Flügel leicht. Er befindet sich nicht mehr mittig über mir. Soll ich den Flug abbrechen? Ich bremse etwas, um den Flügel nach vorne zu richten und mache zwei Schritte, um mich wieder unter den Flügel zu bringen. Der Schirm pendelt sich ein. Ich halte den Flügel ein oder zwei Sekunden in dieser Position, um mich zu vergewissern, dass ich ihn unter Kontrolle habe. Wenn der Flügel steht, stehen alle Zeichen auf Grün. Mit konstantem Druck auf die Bremsen drehe ich mich um 180 Grad. Nach einem kurzen Sprint spüre ich, wie sich die Beingurte straffen und der Schirm mich vom Boden zieht.
Ich fliege.
Sie haben es erraten: Ich habe ein riskantes Hobby. Das heißt, ich bin ein Risikoträger, richtig? Nun, ja, irgendwie schon. Aber auch nein! Als Gleitschirmflieger verwende ich einen erheblichen Teil meiner Energie darauf, Risiken zu minimieren. Mit solider Vorbereitung und einer gesunden Marge bringe ich das Risiko auf ein akzeptables Niveau. Ein besserer Begriff ist daher Risikomanager.
Suchen Sie unsere Stellenangebote
Kein Risiko, kein Geschäft
Damit komme ich zum eigentlichen Thema, dem Risikomanagement in der Softwareentwicklung. Genauer gesagt, wie gehen wir mit unseren Risiken um, damit wir Verbesserungen ohne Stress einführen können? Schließlich ist die Einführung von Software mit einem Gleitschirmstart vergleichbar. In beiden Fällen ist es wahrscheinlich, dass sich die Risiken in tatsächliche Probleme verwandeln.
Leider kann man alle Risiken nur ausschalten, indem man sie ganz vermeidet. Mit dem Gleitschirmfliegen aufhören oder die Einführung von Softwareverbesserungen stoppen. Das erste ist eine gute Wahl. Die zweite, nun ja, mit einigen Risiken müssen wir einfach leben. Aber wir können das Risiko immer noch verringern. Wie machen wir das bei Easy LMS?
Leider kann man alle Risiken nur ausschalten, indem man sie ganz vermeidet.
Was ist überhaupt ein Risiko?
Ein Risiko ist ein Ereignis mit einer bestimmten Eintrittswahrscheinlichkeit und einer bestimmten (negativen) Auswirkung. Die Kombination aus Wahrscheinlichkeit und Auswirkung bestimmt, wie hoch ein Risiko ist. Ein Ereignis, dessen Eintreten sehr wahrscheinlich ist und das große (negative) Auswirkungen hat, ist also ein hohes Risiko. Ein Ereignis, dessen Eintreten unwahrscheinlich ist und das nur sehr geringe Auswirkungen hat, ist ein geringes Risiko. Je höher die Wahrscheinlichkeit und/oder die Auswirkungen sind, desto höher ist das Risiko und andersherum.
Risikomanagement
Da das Risiko eine Kombination aus Wahrscheinlichkeit und Auswirkung ist, folgt daraus, dass man ein Risiko verringern kann:
Senken Sie die Eintrittswahrscheinlichkeit (stellen Sie sicher, dass es seltener passiert).
Senken Sie die Auswirkungen (stellen Sie sicher, dass es keine große Sache ist, wenn es passiert).
Machen Sie beides.
Ein Beispiel: Als Gleitschirmflieger besteht die Gefahr, dass ich abstürze, weil ich mit einem unschönen Knoten in den Leinen starte. Neben anderen Maßnahmen reduziere ich dieses Risiko durch:
Die Kombination aller Maßnahmen gibt mir genug Selbstvertrauen, um fröhlich auf die Bergkante zuzulaufen. Ich vertraue auf meine Vorbereitung, meine Fähigkeiten, meine Ausrüstung und meine Entscheidungen. Das Risiko ist immer noch da, aber ich habe es auf ein Maß reduziert, das ich bereit bin zu akzeptieren. Beim Gleitschirmfliegen wird der Start für mich immer ein angespannter Moment sein. Er verlangt von mir Wachsamkeit. Aber ich bin nicht gestresst.
In ähnlicher Weise haben wir bei Easy LMS Maßnahmen ergriffen, um Risiken zu managen und uns ruhig zu halten. Betrachten wir das Risiko, bei der Veröffentlichung einer neuen Funktion Fehler in das System einzubringen. Zwei Möglichkeiten, wie wir dieses Risiko minimieren, sind:
Wir haben bei Easy LMS Maßnahmen ergriffen, um die Risiken zu beherrschen und uns ruhig zu halten
Wie helfen uns diese Maßnahmen bei Easy LMS?
Testgetriebene Entwicklung (TDD)
Bei der testgetriebenen Entwicklung (Test Driven Development, TDD) wird ein automatisierter Test für das gewünschte Verhalten einer neuen Funktion geschrieben, bevor der Code für die Funktion selbst geschrieben wird. TDD hilft bei der Verringerung des Risikos, dass wir Fehler einführen, auf folgende Weise:
Durch das Testen des Verhaltens in automatischen Tests werden Fehler während der Entwicklung eher erkannt.
Fehler werden früher im Entwicklungsprozess erkannt, wenn Tests vor dem Schreiben des Codes geschrieben werden.
Das Schreiben von Tests vor dem Schreiben des Codes zwingt den Entwickler, darüber nachzudenken, wie das gewünschte Verhalten unabhängig vom endgültigen Code getestet werden kann.
Das Schreiben von testbarem Code ist ein bisschen wie das Schreiben eines lesbaren Buches. Es zwingt den Entwickler, eine Struktur in den Code zu bringen. Infolgedessen ist testbarer Code in der Regel auch wartbarer Code.
Wenn wir TDD gewissenhaft befolgen, bauen wir im Laufe der Zeit eine Testsuite auf, die alle in der Vergangenheit geschriebenen Tests enthält. Vor der Bereitstellung führen wir alle diese Tests durch. Wenn unsere neue Funktionalität ein Problem mit der bestehenden Funktionalität verursacht, werden wir das wissen.
Auf diese Weise trägt TDD dazu bei, die Wahrscheinlichkeit der Einführung von Fehlern in das System erheblich zu verringern.
Kleine Iterationen
Bei Easy LMS arbeiten wir in kleinen Iterationen und geben häufig kleine Änderungen heraus. Wir führen oft ein oder zwei Implementierungen pro Tag durch. Wir tun dies in kleinen Schritten, auch wenn wir eine große Funktionalität einführen. Das hilft uns auf folgende Weise:
Wir erhalten viel früher ein Feedback von den Kunden, als wenn wir mit der Bereitstellung warten würden, bis eine Funktion vollständig "fertig" ist. Auf der Grundlage des frühen Feedbacks können wir bei Bedarf leicht die Richtung ändern.
Es ist viel einfacher, sich von einem Fehler zu erholen, wenn der Unterschied zur letzten stabilen Version gering ist.
Kurze Iterationen sind leichter zu planen und zu verwalten. Ein Team kann einfach nicht über einen längeren Zeitraum hinter den Zeitplan zurückfallen. Das führt zu weniger Stress und verhindert, dass die Teams das Gefühl haben, an allen Ecken und Enden sparen zu müssen.
Die tägliche Bereitstellung schafft einen starken Anreiz für einen rationalisierten und zuverlässigen Bereitstellungsprozess. Andernfalls würden wir täglich den Schmerz spüren.
Auf diese Weise tragen kurze Iterationen dazu bei, die Wahrscheinlichkeit und die Auswirkungen von Fehlern im System zu verringern.
TDD und die Arbeit in kleinen Iterationen geben uns Vertrauen. Das bestärkt uns in der Überzeugung, dass das, was wir bereitstellen werden, funktioniert. Wenn es irgendwelche Probleme gibt, werden diese klein sein.
Kurze Iterationen sind leichter zu planen und zu verwalten
Unit-Tests sind grün, check.
Ich verschiebe das Ticket auf 'In QA Review', was automatisch ein Deployment in unsere Staging-Umgebung auslöst.Ein paar Tage zuvor haben wir eine kleine Änderung an den Statusanzeigen in der Teilnehmerübersicht an mehreren Stellen in der App vorgenommen. Die Änderung sollte dafür sorgen, dass die Statusanzeigen den Status eines Teilnehmers genauer wiedergeben.
Das war vielleicht genauer, aber auch verwirrend. Kunden, die die neue Situation durch die alte Brille betrachteten, hatten den Eindruck, dass keine Einladungen verschickt wurden.
Jetzt war ich bereit, die Abhilfe zu schaffen. Auf der Grundlage der Rückmeldungen, die wir in den Tagen nach der Veröffentlichung erhalten haben, haben wir unsere ursprüngliche Änderung nun verbessert. Ich sehe mir den Fortschritt der automatisierten Bereitstellung in unserer Staging-Umgebung an, in der wir unsere letzten Tests vor der Bereitstellung durchführen.
Die Akzeptanztests werden grün, check.
Ich öffne den Browser und navigiere zur Staging-Umgebung, um die Änderung ein letztes Mal zu testen. Die Staging-Umgebung ist auf die gleiche Weise eingerichtet wie unsere Live-Anwendung.
Es funktioniert so, wie ich es erwarte, überprüfen Sie es.
Die Änderung ist klein, was das Testen einfach macht. Die Unit-Tests und Akzeptanztests stärken meine Zuversicht, dass die bestehenden Funktionen wie zuvor funktionieren. Alle Ampeln stehen auf grün. Ich stoße die Bereitstellung an.
Ich nehme einen Schluck Kaffee und überprüfe meine Nachrichten, während die Bereitstellung läuft. Ich denke darüber nach, wie die Änderung unseren Kunden helfen soll. Wir werden uns in einem Tag mit dem Support in Verbindung setzen. Wir gehen davon aus, dass die Kunden den Support nicht mehr wegen dieses Status kontaktieren werden. Wenn wir weitere Rückmeldungen erhalten, bin ich zuversichtlich, dass wir noch in dieser Woche ein weiteres Deployment durchführen können, um unsere Anwendung weiter zu verbessern und auf die Bedürfnisse unserer Kunden einzugehen.
Nach ein paar Minuten wird die letzte Stufe des Einsatzes grün.
Wir fliegen.
Suchen Sie unsere Stellenangebote
