Release Planning to jedno z najbardziej pożytecznych wydarzeń, które warto wprowadzić w sytuacji, w której mamy do czynienia ze Scrumem w dużej skali. Zresztą, w każdym podejściu zwinnym realizowanym w skomplikowanym środowisku i w odpowiednio dużych projektach, Release Planning może się przydać.
Po co Release Planning?
Na naszych spotkaniach i szkoleniach często opowiadamy, jak to jest ze Scrumem w dużej skali. Temat ten ma mało zwolenników, bo większość osób traktuje każde odstępstwo od Scrum Guide’a jak ciężki grzech. Inni z kolei mieli do czynienia z „dobrodziejstwami” SAFe’a lub byli zmuszeni do „transformacji na model Spotify”, która wyszła im bokiem. Nic dziwnego, że są sceptyczni.
Najlepiej mają ci, którzy pracują w małych zespołach, rozwijając specjalistyczne produkty. Ich temat działania w skali zupełnie nie dotyka, bo działają w podręcznikowym Scrumie.
Zacznijmy więc od tego, po co w ogóle możemy potrzebować „protezy” w postaci zarządzania przez wydania, a co za tym idzie wydarzenia o nazwie Release Planning. Jeżeli jesteśmy elementem większego ekosystemu, a w trakcie wdrożenia aktualizowane jest kilkadziesiąt różnych aplikacji, to trudno tu mówić o „wdrażaniu się co Sprint”. W takim wypadku będziemy mieli z góry narzucone okna wdrożeniowe, w których będziemy dostarczać nasz Przyrost.
Inną popularną sytuacją jest taka, w której potrzebujemy „dużych wersji produktu” z powodów marketingowych. Czasami też jesteśmy związani umową, która przewiduje konkretne terminy. Wtedy co prawda poszczególne Przyrosty jak najbardziej są możliwe do oddawania klientom do użytku, ale i tak potrzebujemy „wersji”.
Koniec końców, ktoś gdzieś potrzebuje od nas wydania naszego oprogramowania. Możemy powiedzieć, że „pracujemy zwinnie i nie przewidujemy wersjonowania naszego produktu”, ale trudno się spodziewać, że takie podejście spotka się ze zrozumieniem.
Release Planning, czyli zarządzanie przez wydania
Release Planning jest elementem specyficznego sposobu zarządzania wymaganiami, w których backlog tworzymy na poszczególne wydania. Zamiast tworzyć go w całości i na raz, zajmujemy się horyzontem czasowym określonym najbliższym releasem.
Nie różni się to w samej swojej idei od iteracyjnego tworzenia oprogramowania w Sprintach. Na Planowaniu Sprintu decydujemy o tym, co będziemy robić w najbliższej iteracji i budujemy pod to Sprint Backlog. Analogicznie działamy na Planowaniu Wydania. Tam decydujemy, co będziemy robić w najbliższym wydaniu i budujemy pod to Product Backlog. I tak jak Sprint Backlog zawiera „plan realizacji wymagań”, tak backlog budowany pod wydanie będzie na o wiele wyższym poziomie szczegółowości (patrz: Epic).
I tu możliwości jest kilka. Możemy po prostu oznaczać w naszym „zwykłym” backlogu wydanie na które wymaganie jest przewidziane. Wykorzystać do tego możemy tagi, etykiety albo nawet pole „wersja”, jeżeli nasze narzędzie takowe posiada. Alternatywą jest budowanie osobnych backlogów pod konkretne wydanie. W takim przypadku odpada konieczność filtrowania, ale za to wszystkie pomysły nieprzypisane do żadnej z wersji muszą wylądować gdzieś indziej.
Co ważne, w przypadku przedsięwzięć o dużej skali, takie Release Planning będzie także odpowiadał nam na potrzeby synchronizacji prac pomiędzy zespołami i Product Ownerami. Pozwoli dobrze podzielić pracę i mieć pewność, że gotowy na koniec wydania produkt faktycznie będzie wartościowy.
Jak przeprowadzić Release Planning?
Skoro już wiemy, po co robimy Release Planning, to spróbujmy sobie wyobrazić jak może on przebiegać. Wiemy, że chcemy zebrać tam wszystkie wymagania do wszystkich powiązanych ze sobą produktów. Na pewno niezbędni więc będą wszyscy Product Ownerzy.
Czy na Release Planning powinny trafić całe zespoły, czy tylko przedstawiciele? Tu z pomocą przyjdzie nam empiryzm. O wiele lepiej jest, gdy w decyzjach i ustaleniach biorą udział wszyscy. Ale jeśli na naszym projekcie znajduje się kilkaset osób, to takie wielkie spotkanie staje się po prostu mało praktyczne. Rozwiązań, jak zwykle, znajdziemy kilka.
Możemy pójść na łatwiznę i na Release Planning zabrać tylko przedstawicieli. Albo możemy podejść do tematu całościowo i ze spotkania pod tytułem Release Planning zrobić wydarzenie, które ma tylko i wyłącznie potwierdzić to, co ustaliliśmy między sobą wcześniej.
Zwykle wygląda to tak, że parę tygodni przed Planowaniem Wydania zarówno zespoły, jak i Product Ownerzy biegają między sobą i interesariuszami, próbując ustalić ogólny plan na najbliższe wydanie. Na samym spotkaniu zaś przedstawiciele podsumowują, przedstawiają i potwierdzają wcześniejsze ustalenia.
I tu warto dodać, że plan powstały na takim spotkaniu nie jest finalny, ostateczny i niezmienny. Tak jak w ramach Sprintu możemy, za wiedzą i zgodą Product Ownera, dokonać zmian zakresu, tak i tu jak najbardziej możemy modyfikować zakres wydania. Dobrą praktyką jest pozwalanie jedynie na zamiany wymagań o podobnej wielkości, wyrażonej np. w Story Point. To znaczy, że jeśli chcemy dorzucić nowy Epic o wartości x, to tyle samo pracy musimy z naszego planu wyrzucić.
Kolejną dobrą praktyką w przypadku zarządzania przez wydania jest „Release Retrospective”, które to spotkanie zepnie nam klamrą całe wydanie. Podsumuje też ono nasze wysiłki w okresie trochę dłuższym niż robi to Sprint Retrospective. Wnioski z tego „dużego retro” również będą na bardziej ogólnym poziomie, na który zwykle nie wchodzimy na „zwykłym retro”.
Czy Release Planning jest niezbędny?
Jak każdy „dodatkowy” element, tak i Release Planning należy traktować użytkowo. Jeżeli może on nam w czymś pomóc lub odpowiedzieć na jakieś nasze potrzeby, sprawdźmy czy nie będzie to dla nas dobre rozwiązanie. Jeżeli zaś dobrze sobie radzimy bez niego, nie zaprzątajmy sobie nim głowy.
Podobnie rzecz się ma w sytuacji, w której mamy jeden zespół rozwijający jeden produkt. Chęć ujarzmienia nowych funkcjonalności w „wersje” może kusić, ale niepotrzebny jest nam ten cały formalny ambaras. Z wydaniami świetnie poradzi sobie Product Owner decydując, kiedy już warto podbić numer wersji. Może utrzymywać plan rozwoju i sprzedawać wizję i roadmapę zespołom. Natomiast uciekajmy od wdrażania formalizmów, które zasadniczo nic nie wnoszą.
O wiele lepiej pracuje się wiedząc, dokąd zmierzamy. Jeszcze lepiej gdy znamy terminy. Jednak do tego wcale nie potrzebujemy rozbudowywać naszego procesu. Róbmy to tylko wtedy, kiedy widzimy z tego korzyści i kiedy nie radzimy sobie w inny, bardziej scrumowy sposób.
Tematem Scruma w wielkiej skali zajmowaliśmy się między innymi w filmach o planowaniu wydań i o wdrożeniu raz w roku. Jeżeli jesteś zainteresowany praktycznymi aspektami zwinnej pracy w dużych organizacjach bądź na wielkich projektach, zapraszamy na szkolenie Skalowanie Scrum.
