Omawiania sloganów, akronimów i powiedzeń ciąg dalszy. Ciągle łapiemy się na tym, że nie opowiedzieliśmy albo nie wyjaśniliśmy jakiegoś sformułowania, kóre wydaje się dla nas oczywiste. Dziś nadszedł czas, aby rozprawić się z „Release Early, Release Often” i powiedzieć dlaczego jest to korzystne.
RERO, FEFO i inne takie…
Nasz umysł nieubłaganie szuka skojarzeń. Nie dalej jak wczoraj opublikowaliśmy film pod tytułem „Quick Release„, w którym mówiliśmy między innymi o tym, dlaczego opublikowaliśmy tylko jeden film z naszej zdalnej sesji nagraniowej. Ponadto, oczywiście, mówiliśmy o zaletach szybkiego wypuszczania naszych dokonań, szczególnie jeśli robimy coś nowego. Zwinne eksperymenty mają to do siebie, że nie zawsze dają rezultaty zgodne ze spodziewanymi.
Innym naszym dziełem, który kojarzy się z dzisiejszym tematem jest „Fail Early, Fail Often„. Nie da się ukryć, że slogan brzmi skrajnie podobnie. Ale wszystkie agile’owe hasła po pewnym czasie zlewają się w jedno. „FEFO” dotyczy przekonania, że jeżeli już mamy odnosić porażki, to najlepiej, żeby następowały one jak najwcześniej. Ja sugerowałem inną strategię – skupmy się na osiąganiu sukcesów, a porażki po prostu uznajmy za naturalne i nieuniknione.
Nie da się jednak ukryć, że zarówno w przypadku sukcesów, jak i porażek, żeby odnieść je szybko, musimy szybko dostarczyć nasz produkt do odbiorcy końcowego. Pytanie, czy szybkie wypuszczanie produktów naszej pracy (Release Early) i częste ich oddawanie do użytku (Release Often) są ze sobą powiązane? Oczywiście, że tak.
Jeżeli jesteśmy w stanie szybko wypuścić coś dającego korzyść biznesową, to pewnie równie szybko jesteśmy w stanie dodać kolejne takie korzyści do kolejnej wersji, wypuszczonej w podobnym czasie. Czyli warto dobrze zacząć. Niestety, ciągle pokutuje postrzeganie dużych monolitycznych systemów jako dużych monolitycznych systemów, a nie zbiór funkcjonalności, procesów i narzędzi, z których każde może przynieść korzyść same w sobie.
Zacznijmy więc od tego, żeby znaleźć jakąś jedną rzecz, w której nasze rozwiązanie/produkt może pomóc. I zróbmy to jak najszybciej. A potem od razu jak się tylko da dostarczmy ją do odbiorców.
Early, czyli kiedy?
Co się stanie, jeśli będziemy zwlekać z wdrażaniem wyprodukowanych przez nas produktów czy funkcjonalności?
Po pierwsze i najważniejsze, nie zweryfikujemy zasadności naszych założeń. Nie wiemy czy to, co stworzyliśmy okaże się przydatne, potrzebne i będzie ochoczo używane przez odbiorców. Mamy nadzieję, że tak – w końcu z jakiegoś powodu zrobiliśmy to tak, a nie inaczej. Ale informację zwrotną dostaniemy dopiero w momencie, gdy ludzie zaczną korzystać z produktu. Może będą używali go niezgodnie z przeznaczeniem, a może w ogóle?
Ryzykujemy naprawdę dużo – możemy wykonywać dalszą pracę utrzymując błędne założenia i skazując się na straty bądź wyrzucenie mnóstwa pracy do kosza. Pół biedy, jeżeli to są tylko dwa filmy. Gorzej, jeśli to pół roku pracy. Nie lepiej wiedzieć, zamiast się domyślać?
Drugim i równie ważną konsekwencją odkładania produktów na półkę jest ich starzenie się. Mówimy o „obrastaniu kurzem”, ale sprawa ma się jeszcze gorzej. Zmienia się otoczenie, wymagania, potrzeby, technikalia, itd. Kawałek funkcjonalności, system czy produkt, który przeleżał kilka miesięcy na półce może w ogóle nie nadawać się do wypuszczenia.
Jeśli coś jest używane, to jest utrzymywane w stanie przydatności. Rzeczy schowane „na później” zwykle nie są serwisowane. Liczymy, że jak do nich wrócimy i otrzepiemy je z kurzu, to będą działać. Niestety, zwykle nie będą.
„Early” znaczy więc „jak tylko coś nadaje się do użycia”.
Often, czyli co ile?
Zabierając się za temat częstotliwości wdrożeń przypomniał mi się kolejny nasz film, w którym zastanawialiśmy się czy możemy być zwinni wdrażając się raz w roku. Spoiler alert: średnio. Mówiąc inaczej, będziemy wtedy borykać się z prolemami „ograniczonego agile’a„. Gdy jeden kawałek naszej organizacji jest zwinny, a drugi nie bardzo, będziemy mieli więcej problemów niż w klasycznym podejściu.
No dobrze, to kiedy i jak się wydawać? Wdrożenia mają swój koszt i niosą ze sobą pewne ryzyko. Każdy pewnie kiedyś widział „Release Early, Release Often” posunięte do absurdu, czyli development na środowisku produkcyjnym. Konsekwencji takiego działania chyba nie muszę nikomu przedstawiać.
Jeżeli chcemy się wydawać szybko i często, musimy operować na rzeczach, które są gotowe. To znaczy, że nie uciekniemy od technicznych rozwiązań wspierających Continuous Delivery. I chociaż CD można przyrównać do Release Early, Release Often, to Łukasz w swoim tekście podszedł do tematu bardziej od strony narzędziowej. I tych narzędzi będziemy potrzebować, jeżeli chcemy się wydawać często.
Rozstrzygając kwestię tego „kiedy i jak często”, odpowiem więc zgodnie z wykładnią pewnego zwinnego egzaminu. Wdrażajmy się tak często, jak to możliwe, ale tylko wtedy, kiedy to ma sens. Inaczej mówiąc: kiedy korzyści biznesowe przewyższają koszty i ryzyko.
Tylko niech to będzie jak najczęściej.
