Mówi się, że w pracy najtrudniejsze jest jej rozpoczęcie, a potem to już z górki. Nierozsądnym byłoby kłócenie się z tak objawioną, ludową prawdą, toteż stworzono masę frameworków, które z założenia powinny ułatwiać wykonanie tego milowego kroku.
Poniższy artykuł nie będzie jednak próbował nawrócić Cię na jedynie słuszną drogę spośród wielu metod organizacji pracy, gdyż na różnych etapach rozwoju firmy potrzeba różnych bodźców koniecznych do stymulacji procesów – niekoniecznie musi więc to być akurat Scaled Agile Framework. Chciałbym podkreślić tylko jedno – planowanie w SAFe to ewenement wśród wszelkich korporacyjnych spotkań i warsztatów. Jeśli nie udało Ci się jeszcze zaznajomić z SAFe-m, odsyłam do mojego poprzedniego artykułu.
Na początku kilka słów wyjaśnienia. Program Increment Planning (w skrócie PI Planning) to cykliczne, a zarazem centralne wydarzenie dla zespołów pracujących w przytoczonym we wprowadzeniu frameworku. Stanowi ono serce pracy całego Agile Release Trainu (w skrócie: ART-u). W rytmie jego bicia, działają wszystkie zgromadzone pod nim zespoły. PI Planning sprawdza i wyznacza puls. Jako punkt kulminacyjny inkrementu sprawia, iż excelowe założenia managementu mają szansę się urzeczywistnić. Co najważniejsze – ostateczną decyzję zostawia zespołom, wspierając i definiując ich autonomiczność.
PI Planning to w dużym skrócie skoordynowane planowanie pracy zespołów, w naszym przypadku, programistycznych przy współuczestnictwie wszystkich niezbędnych osób mogących dostarczyć pomocy ART-owi. Warto przy tym określić nieprzypadkowość słowa „wszyscy”. SAFe w istocie zakłada wprost namacalną dostępność, a nawet wyłączność, osób i ról, dzięki którym zespoły posiądą wszelkie niezbędne informacje, by rozwiać niepewności mogące zaistnieć przy planowaniu. Fizyczne przebywanie w, choć dużym, to wciąż jednym, pomieszczeniu to prawdopodobnie nie to, do czego przyzwyczaiły nas poprzednie dwa lata, lecz w tym szaleństwie jest metoda.
Dzięki bezpośredniej komunikacji jesteśmy w stanie szybciej rozwiązywać niejasności, błyskawicznie poznać problemy, przed jakimi stają członkowie zespołów, a także móc poróżnić się na forum całego pociągu co do założonych w opisie funkcjonalności hipotez. Przede wszystkim celem takiego podejścia jest osiągnięcie konsensusu i zadeklarowania się zespołów do liczby i czasu dostarczonych funkcjonalności. Ów sposób planowania pokazuje, że właśnie w dialogu znajduje się odpowiedź na większość nurtujących nas pytań, które trudniej jest zadać awatarowi z komputera.
Nasze planowanie ma oczywiście charakterystyczny, ustandaryzowany przebieg. Na samym początku, przed zgromadzonymi na sali, przytaczany jest kontekst biznesowy, w jakim się znajdujemy. Wymagania, jakie stawiają przed nami nie tylko użytkownicy naszych produktów, lecz także rynek i jego meandry, osadzane są w rzeczywistości naszej pracy i funkcjonalności, które już dostarczyliśmy lub dopiero będziemy dostarczać. Dalej przedstawiane są zagadnienia związane bezpośrednio z wizją na ten i przyszłe inkrementy, jak i wątki architekturalne, kluczowe dla zachowania spójności wytwarzanego oprogramowania i jego dobrej jakości. Po wyczerpującym wstępie, a jeszcze przed główną pracą następuje przypomnienie zasad dobrego planowania, wyjaśnienie reguł gry, w jaką zaraz zacznie grać ze sobą setka osób. Następnie zespoły, zachowując respekt dla priorytetów, pobierają funkcjonalności z głównej listy zadań i przystępują do studium ich wykonalności poprzez ich oszacowanie w całym swoim dostępnym czasie. Czynności te stanowią lwią część dnia i kończą się wstępną prezentacją poczynań zespołów. Po wszystkim, na zakończenie pierwszego dnia planowania, management zbiera się, by przedyskutować i ewentualnie zasugerować zespołom zmiany, jakich mogłyby dokonać, by cały ART mógł lepiej sprostać oczekiwaniom rynku.
Drugi dzień rozpoczyna się od przedstawienia wyżej wymienionych rezultatów popołudniowej dyskusji, po czym wchodzimy na ostatni wiraż w tym biegu. Po jego pokonaniu pozostaje tylko nabrać prędkości i dopiąć wszystkie formalności związane z planowaniem pracy zespołów – omówić zależności, których istnienie jest kluczowe dla powodzenia naszej pracy, zidentyfikować ryzyka mogące wystąpić podczas implementacji, czy też sformułować cele biznesowe stanowiące specyficzną formę interfejsu-umowy między biznesem a technologią. Po tak intensywnym finiszu czeka na nas jeszcze kilka aktywności: ostateczna prezentacja planów zespołów, omówienie zagrożeń programowych, głosowanie w uznaniowej skali nad prawdopodobieństwem powodzenia Program Incrementu z potencjalnymi dyskusjami i ewentualnym przeplanowaniem, a wszystko to zwieńczone gremialną retrospekcją z właśnie zakończonego planowania i znalezieniem dalszych akcji zeń płynących.
Kilka akapitów nie jest w stanie dokładnie oddać ducha współpracy, jaki nieustannie krąży nad współpracującymi członkami ART-u. Każdy z nich ma bowiem swoje tempo i takt. Niekiedy także boryka się z różnymi arytmiami, szczególnie na początkowych etapach rozwoju, ale dobrze naoliwiony, rozpędzony pociąg dowożący pasażerów na czas z nawiązką rekompensuje wszystkie nakłady pracy, jakie muszą zostać wykonane, by dojść do porozumienia, tak kluczowego dla wspólnego osiągania celów.