"Jesteś gotowy?"
Gotowy jak tylko mogę, myślę, przechodząc przez moją mentalną listę kontrolną po raz ostatni.
Pilot: Sznurowadła, pasy na nogi, pas piersiowy, rękawice, radio, pasek pod brodę, sprawdź.
Linie: Wszystkie wolne i niezakłócone, lewa nad prawą, dzięki czemu mogę skręcić w preferowaną stronę, sprawdź.
Skrzydło: Przednia krawędź jest otwarta i ładnie rozłożona w kształcie końskiej podkowy, sprawdź.
Wiatr: Pojawia się lekki wietrzyk, trochę za słaby na odwrotny start. Postanawiam przeczekać kilka minut.
"Wybierz swój moment".
Kiwam głową do instruktora, obserwując wiatrowskaz. Po kolejnej minucie czuję, że wiatr nieco się wzmaga. Wiatrowskaz wygląda dobrze. Czekam kilka sekund, by sprawdzić, czy to się utrzyma. Utrzymuje się.
Wiatr: sprawdź.
Przestrzeń powietrzna: Brak innych szybowców latających w pobliżu startu i brak innych szybowców gotowych do startu, sprawdź.
Biorę głęboki oddech... "START!", przyciągam do siebie podnośniki A. Skrzydło nadmuchuje się podczas wznoszenia. Puszczam taśmy i zaciągam hamulce, by zatrzymać skrzydło nade mną. Kształt skrzydła wygląda znajomo, dobrze. Nie widać węzłów, świetnie. Podmuch wiatru lekko obraca skrzydło. Nie jest już wyśrodkowane nade mną. Czy powinienem przerwać? Wciskam hamulec, by skierować skrzydło do przodu i robię dwa kroki, by ponownie znaleźć się pod skrzydłem. Skrzydło osiada. Utrzymuję skrzydło w tej pozycji przez sekundę lub dwie, by sprawdzić, czy mam nad nim kontrolę. Po ustabilizowaniu się skrzydła wszystkie znaki są teraz zielone. Utrzymując stały nacisk na hamulce, obracam się o 180 stopni. Po krótkim sprincie czuję, jak pasy na nogach napinają się, a skrzydło odrywa mnie od ziemi.
Lecę.
Zgadłeś; mam ryzykowne hobby. To oznacza, że jestem ryzykantem, prawda? Cóż, tak, w pewnym sensie. Ale też nie! Jako paralotniarz poświęcam znaczną ilość energii na ograniczanie ryzyka. Dzięki solidnemu przygotowaniu i zachowaniu zdrowych marginesów, obniżam ryzyko do akceptowalnego poziomu. Dlatego lepszym określeniem jest menedżer ryzyka.
Sprawdź nasze oferty pracy.
Bez ryzyka, bez biznesu
To prowadzi mnie do tematu, jakim jest zarządzanie ryzykiem w rozwoju oprogramowania. Mówiąc dokładniej, w jaki sposób zarządzamy ryzykiem, abyśmy mogli bez stresu wdrażać ulepszenia? W końcu wdrażanie oprogramowania jest podobne do startu paralotni. W obu przypadkach ryzyko może przerodzić się w rzeczywiste problemy.
Niestety, jedynym sposobem na wyeliminowanie wszystkich zagrożeń jest ich całkowite unikanie. Zaprzestanie latania na paralotni lub, równoważnie, zaprzestanie wdrażania ulepszeń oprogramowania. To pierwsze jest w rzeczywistości dobrym wyborem. Drugi, cóż, z niektórymi zagrożeniami będziemy musieli po prostu żyć. Ale nadal możemy zmniejszyć ryzyko, więc jak to robimy w Easy LMS?
Niestety, jedynym sposobem na wyeliminowanie wszystkich zagrożeń jest ich całkowite unikanie
Czym w ogóle jest ryzyko?
Ryzyko to zdarzenie o określonym prawdopodobieństwie wystąpienia i określonym (negatywnym) wpływie. Połączenie prawdopodobieństwa i wpływu określa, jak wysokie jest ryzyko. Tak więc zdarzenie, którego wystąpienie jest bardzo prawdopodobne i które ma duży (negatywny) wpływ, stanowi wysokie ryzyko. Zdarzenie, które jest mało prawdopodobne i ma bardzo ograniczony wpływ, jest niskim ryzykiem. Jeśli prawdopodobieństwo i/lub wpływ są wyższe, ryzyko wzrasta i odwrotnie.
Zarządzanie ryzykiem
Ponieważ ryzyko jest kombinacją prawdopodobieństwa i wpływu, wynika z tego, że aby zmniejszyć ryzyko, można to zrobić:
Zmniejsz prawdopodobieństwo jego wystąpienia (upewnij się, że zdarza się to rzadziej).
Zmniejsz wpływ (upewnij się, że nie jest to wielka sprawa, jeśli się zdarzy).
Zrób jedno i drugie.
Na przykład, jako paralotniarz, rozważmy ryzyko upadku, ponieważ startuję z paskudnym węzłem na linkach. Wśród innych środków, zmniejszam to ryzyko poprzez:
Połączenie wszystkich środków daje mi wystarczającą pewność siebie, aby szczęśliwie zbiegać w dół w kierunku krawędzi góry. Ufam swojemu przygotowaniu, umiejętnościom, sprzętowi i podejmowanym decyzjom. Ryzyko nadal istnieje, ale zredukowałem je do poziomu, który jestem w stanie zaakceptować. Podczas latania na paralotni start zawsze będzie dla mnie napiętym momentem. Wymaga ode mnie czujności. Ale nie jestem zestresowany.
Podobnie w Easy LMS wprowadziliśmy środki mające na celu zarządzanie ryzykiem i zapewnienie nam spokoju. Rozważmy ryzyko wprowadzenia błędów do systemu podczas wydawania nowej funkcji. Minimalizujemy to ryzyko na dwa sposoby:
W Easy LMS wprowadziliśmy środki mające na celu zarządzanie ryzykiem i zapewnienie nam spokoju
W jaki sposób te środki pomagają nam w Easy LMS?
Test Driven Development (TDD)
Test Driven Development, czyli TDD, to praktyka pisania zautomatyzowanych testów dla pożądanego zachowania nowej funkcjonalności przed napisaniem kodu dla samej funkcjonalności. TDD pomaga zmniejszyć ryzyko wprowadzenia błędów na następujące sposoby:
Dzięki testowaniu zachowania w testach automatycznych istnieje większe prawdopodobieństwo wychwycenia błędów podczas rozwoju.
Błędy są wychwytywane wcześniej w procesie rozwoju poprzez pisanie testów przed napisaniem kodu.
Pisanie testów przed napisaniem kodu zmusza programistę do zastanowienia się, jak przetestować pożądane zachowanie niezależnie od ostatecznego kodu.
Pisanie testowalnego kodu jest trochę jak pisanie czytelnej książki. Zmusza programistę do zastosowania struktury do kodu. W rezultacie testowalny kod jest zwykle kodem łatwym w utrzymaniu.
Przestrzegając religijnie TDD, z czasem budujemy zestaw testów, obejmujący wszystkie testy napisane w przeszłości. Przed wdrożeniem uruchamiamy wszystkie te testy. Jeśli nasza nowa funkcjonalność spowoduje problem z istniejącą funkcjonalnością, będziemy o tym wiedzieć.
W ten sposób TDD pomaga znacznie zmniejszyć prawdopodobieństwo wprowadzenia błędów do systemu.
Małe iteracje
W Easy LMS pracujemy w małych iteracjach, często wprowadzając niewielkie zmiany. Często wykonujemy jedno lub dwa wdrożenia dziennie. Robimy to małymi krokami, nawet gdy wprowadzamy dużą funkcjonalność. Pomaga nam to w następujący sposób:
Otrzymujemy informacje zwrotne od klientów znacznie wcześniej, niż gdybyśmy mieli czekać z wdrożeniem, aż funkcja zostanie całkowicie "ukończona". Opierając się na wczesnych informacjach zwrotnych, możemy łatwo zmienić kierunek, jeśli zajdzie taka potrzeba.
O wiele łatwiej jest naprawić błąd, jeśli różnica w stosunku do ostatniej stabilnej wersji jest niewielka.
Krótkie iteracje są łatwiejsze do zaplanowania i zarządzania. Zespół po prostu nie może pozostawać w tyle za harmonogramem przez znaczną ilość czasu. Prowadzi to do mniejszego stresu i zapobiega sytuacji, w której zespoły czują potrzebę pójścia na skróty.
Deploying daily tworzy silne dążenie do bardziej usprawnionego i niezawodnego procesu wdrażania. W przeciwnym razie codziennie odczuwalibyśmy ból.
W ten sposób krótkie iteracje pomagają zmniejszyć prawdopodobieństwo i wpływ błędów wprowadzanych do systemu.
TDD i praca w małych iteracjach dają nam pewność siebie. Umacniamy się w przekonaniu, że to, co zamierzamy wdrożyć, działa. Jeśli pojawią się jakieś problemy, będą one niewielkie.
Krótkie iteracje są łatwiejsze do zaplanowania i zarządzania.
Testy jednostkowe są zielone, sprawdź.
Przenoszę zgłoszenie do "W przeglądzie QA", co automatycznie uruchamia wdrożenie w naszym środowisku przejściowym.Kilka dni wcześniej wdrożyliśmy niewielką zmianę w statusach wyświetlanych w przeglądzie uczestników w kilku miejscach w aplikacji. Zmiana miała na celu dokładniejsze odzwierciedlenie statusu uczestnika..
Mogło to być bardziej dokładne, ale było też mylące. Klienci, którzy patrzyli na nową sytuację przez stare pryzmaty, odnosili wrażenie, że zaproszenia nie zostały wysłane.
Teraz byłem gotowy do wdrożenia rozwiązania. W oparciu o informacje zwrotne, które otrzymaliśmy w ciągu kilku dni po wydaniu, ulepszyliśmy naszą pierwotną zmianę. Patrzę na postęp zautomatyzowanego wdrożenia do naszego środowiska przejściowego, w którym przeprowadzamy ostateczne testy przed wdrożeniem.
Testy akceptacyjne zmieniają kolor na zielony, sprawdź.
Otwieram przeglądarkę i przechodzę do środowiska przejściowego, aby przetestować zmianę po raz ostatni. Środowisko przejściowe jest skonfigurowane w taki sam sposób, jak nasza aplikacja na żywo.
Działa zgodnie z oczekiwaniami, sprawdź.
Zmiana jest niewielka, co ułatwia testowanie. Testy jednostkowe i akceptacyjne dodatkowo wzmacniają moją pewność, że istniejąca funkcjonalność działa tak jak wcześniej. Wszystkie światła są zielone. Uruchamiam wdrożenie.
Biorę łyk kawy i sprawdzam wiadomości, gdy trwa wdrożenie. Myślę o tym, jak zmiana powinna pomóc naszym klientom. Za dzień skontaktujemy się z pomocą techniczną. Spodziewamy się, że klienci nie będą już kontaktować się z pomocą techniczną w sprawie tego statusu. Jeśli otrzymamy więcej informacji zwrotnych, jestem przekonany, że w tym tygodniu będziemy gotowi do kolejnego wdrożenia, aby jeszcze bardziej ulepszyć naszą aplikację i dostosować ją do potrzeb naszych klientów.
Po kilku minutach ostatni etap wdrażania zmieni kolor na zielony.
Latamy.
Sprawdź nasze oferty pracy.
