Scrum obfituje w określenia, które dla osób nowych „w branży” mogą być co najmniej niezrozumiałe. Dziś odczarujemy kolejne z nich, wyjaśniając kim jest Frequent Releaser.
Frequent Releaser, czyli kto?
Dla przypomnienia, Servant Leader to stary dobry Scrum Master. A kim jest Frequent Releaser? To osoba Product Ownera określana jest tym pieszczotliwym zwrotem. Dlaczego on a nie na przykład wspomniany SM albo Kierownik Projektu?
Otóż to Product Owner jest osobą, które może zdecydować o wdrożeniu rozwiązania na środowisko końcowe, czytaj: produkcyjne. Kiedy będzie to robił? Miejsc w naszym procesie jest naprawdę dużo, a w najbardziej zwinny sposób może się to odbyć choćby w trakcie trwania Sprintu.
Celem Product Ownera powinno być sprawdzenie swojego przewidywania w zakresie kierunku rozwoju produktu. Nie od dziś wiadomo, że nawet najlepszy pomysł nie przeżyje starcia z rzeczywistością, jeśli ta nie będzie na to przygotowana. Przykład z ostatnich dni – Elon Musk i jego nowe (stare) dzieło – Neuralink. Podziwiam gościa za wizjonerstwo. Jest w tym mistrzem.
Cel częstego release’owania
Wracając do Neuralink, powód dla którego chcemy „często wypuszczać nasz produkt [na rynek]” jest aż nadto widoczny. Nowa technologia testowana jest na razie na przedstawicielach braci mniejszych. Powiedzmy sobie szczerze, jest kontrowersyjnie.
„Wywiercimy Ci dziurę w głowie, włożymy do niej element wielkości monety i będziemy w ten sposób kontrolować wiele aspektów Twojego życia.”
Brzmi jak bajka. Fajnie podsumował to jeden z bardziej znanych YouTuberów mówiąc o tym, że pomysł ten idzie dalej, niż najbardziej śmiałe marzenia władz ChRL.
Ale do rzeczy. Ten kontrowersyjny pomysł, można wręcz powiedzieć eksperyment, trzeba jakoś oswoić, sprawdzić, zweryfikować i poczekać na informację zwrotną. Ta, na szczęście dla firmy Elona, nie jest negatywna. Można by nawet powiedzieć, że jest zaskakująco pozytywna. Oczywiście wszystko to spowodowane jest otoczką projektu – chęcią pomocy osobom, które dotknięte są różnymi chorobami. Co jest jak najbardziej godne pochwały.
Wracając do naszego projektu…
Wiemy już po co możemy chcieć częstego wdrażania. Sprawdźmy, co o naszym pomyśle sądzi rynek (interesariusze naszego projektu) zanim zaczniemy go rozwijać w kierunku, który będzie nas dużo kosztował, a nie da nam za bardzo możliwości zarobku. Można więc powiedzieć, że próbujemy uniknąć kursu na górę lodową, która nas po prostu zatopi (i naszą firmę również). Co więc robić? Wdrażać, wdrażać, wdrażać (parafrazując legendarne już słowa szefa WHO).
Niestety świat nie jest tak prosty i piękny. Zwykle nie pracujemy w małej, kilkuosobowej firmie, która pracuje nad wdrożeniem jednego produktu, który to już został zweryfikowany i uznany przez rynek. Nasza droga związana z wdrażaniem nowego produktu przeważnie nie będzie prosta. Wiąże się to wprost z nakładem pracy, jaki musimy poświęcić, aby takie wdrożenie przeprowadzić.
Zastopowanie firmy na czas wdrożenia, testy integracyjne i akceptacyjne,na środowiskach pre-produkcyjnych, czy w końcu zapewnienie ludzi do wdrożenia i weryfikacji jego powodzenia. To wszystko ma wpływ na to, czy to wdrożenie jest i będzie dla naszej organizacji opłacalne. Jeśli nie, po prostu go nie zrobimy (i nie zarobimy).
Frequent releaser, czyli jak często?
I tutaj dochodzimy do zasadniczego pytania – jak często powinniśmy się wdrażać. Product Ownera opisujemy przecież mianem „Frequent Releaser”. Z tym „frequent” jest jak ze słowem „ładny” – dla każdego oznacza coś zupełnie innego.
Co więc znaczy często i jak powinniśmy interpretować to słowo? Pośrednio już odpowiedziałem na to pytanie. Po pierwsze, sprawdźmy jak często potrzebujemy się „sprawdzać”. Wydaje mi się, że idealne będą do tego mierniki, którymi zmierzyć monitorować np. ilość zgłaszanych błędów czy koniecznych do wykonania reworków. Z drugiej strony musimy policzyć ile kosztuje pojedyncze wdrożenie. Bo może się okazać, że za dużo.
Częstotliwość będzie wypadkową m. in. dwóch z powyżej wymienionych czynników. Czy jest to lista kompletna? Pewnie nie, w każdej organizacji lista będzie różna, a jednym z nich może być m.in. częstotliwość wdrożeń narzucona np. umową z klientem czy w ogóle dostępnymi korporacyjnymi „weekndami wdrożeniowymi”. Jak to już często bywa, tu też nie jesteśmy w stanie dać tzw. złotej rady.
Dobrze jednak zdawać sobie sprawę ze skomplikowania tego zagadnienia. Na pewno pomoże nam to znaleźć właściwe rozwiązanie. No i oczywiście pamiętajmy, że „wdrożenie raz w roku„, to na pewno nie jest „często”.
