Pośpiech nie zawsze jest dobrym doradcą.
Każdy ma swoją rację
Istotną częścią każdego projektu jest premiera nowej wersji oprogramowania. Nowa wersja produktu, aplikacji lub systemu, nad którym programiści intensywnie pracowali. Tak zwane „wyjście na produkcję” często kojarzy się z podekscytowaniem, adrenaliną i skrajną nerwicą :) Czy zawsze dobrze jest forsować wdrożenie następnej wersji oprogramowania tak szybko, jak to możliwe?
Jeśli jesteś product ownerem to zawsze chcesz, aby kolejne wersje Twojego oprogramowania były publikowane tak szybko, jak to możliwe. Warto jednak mieć świadomość, że zdarzają się sytuacje, w których paradoksalnie można zaoszczędzić czas i pieniądze… nie robiąc tego i wstrzymując trochę premierę nowej wersji. Takie zdanie forsują najczęściej analitycy biznesowi.
Zresztą brak wydania nowej wersji systemu także może wiązać się z ryzykiem a także kłopotami finansowymi i utratą wizerunku w oczach nie tylko użytkowników, ale także sponsorów (interesariuszy) projektu. Gdy pracujemy w Agile ostateczną decyzję dotyczącą wydania nowej wersji zawsze podejmuje jednak product owner - osoba, która powinna mieć pełny obraz aktualnej sytuacji w zakresie stanu zaawansowania prac i jakości wytwarzanego produktu.
Kazus Cyberpunka
Większość z nas zapewne pamięta najsłynniejszą premierę gry z 2020 roku. Wydanie długo wyczekiwanego Cyberpunka 2077 tuż przed sezonem świątecznym wywołało wiele negatywnych komentarzy na temat jakości gry i problemów, z jakimi borykali się niektórzy użytkownicy. Spowodowało to również spadek notowań giełdowych wydawcy. Niemniej gra odniosła ogromny sukces - trzeba przyznać, że 8 milionów zamówionych w przedsprzedaży egzemplarzy gry robi wrażenie. Pytanie jednak, czy każdy może sobie pozwolić na taką premierę lub wydanie nowej wersji, która spowoduje lawinę negatywnych komentarzy?
Na co zwrócić uwagę?
Każde nowe wydanie niesie ze sobą duże ryzyko wykrycia przez użytkownika poważnych usterek a to może kosztować utratę zaufania klientów. Tą utratę zaufania może łatwiej nadrobić duża firma, mająca wieloletnią renomę i uznane tytuły. Gorzej będą miały niewielkie software house’y.
Najważniejszymi elementami każdego projektu są ludzie zaangażowani w jego realizację. Nie da się wypuścić nowej wersji oprogramowania bez udziału w tym zadaniu osoby bardziej doświadczonej. I nie chodzi tu nawet o staż pracy ale o ilość różnego typu sytuacji, z którymi tacy specjaliści mieli już do czynienia. Dlaczego to takie ważne? Jak tu ujął Michael Jordan:
W swoim życiu doznawałem porażki za porażką. Dlatego odniosłem sukces.
Osoby, które w życiu zawodowym doświadczyły problemów, którym się nie powiodło parę deploymentów i wiedzą jaka atmosfera panuje podczas rollbacku, będą miały wiedzę o tym, co poszło nie tak i jak temu zapobiec w przyszłości.
Drugą sprawą jest automatyzacja procesów wszędzie tam, gdzie to tylko możliwe.
Rola Continuous Integration i Continuous Deployment
Przy wdrażaniu nowej wersji softu przydaje się ciągła integracja (CI). Jest to narzędzie używane przez DevOpsów, w którym po każdym procesie scalania system rozpoczyna proces kompilacji i testów jednostkowych; używane są też narzędzia do analizy statycznej kodu. Przeprowadzane są wreszcie wszelkie inne testy jakościowe, które można zautomatyzować.
Następnym krokiem jest (a przynajmniej powinno być) wdrożenie Continuous Delivery lub nawet Continuous Deployment (CD). Różnica między tymi dwiema metodami polega na podjęciu decyzji, czy chcemy zautomatyzować cały proces od środowiska programistycznego do środowiska produkcyjnego (Continuous Deployment), czy też pozostawić sobie możliwość ręcznej aktualizacji środowiska produkcyjnego tak jak w Continuous Delivery. CI/CD jest coraz bardziej dostępne.
