PI Planning bez tajemnic

PI Planning - co to jest?

Product Increment Planning, czyli Planowanie Przyrostu Programu, jest głównym wydarzeniem dla wszystkich członków Agile Release Train (ART). Celem PI Planningu jest wypracowanie wspólnego zrozumienia wizji i celów produktu, czego efektem jest utworzony przez Zwinne Zespoły Agile plan w postaci Program Board osadzony w Timeboxie przyjętym przez ART. Rekomendacja ze strony SAFe dla długości PI to 8 -12 tygodni. Możemy zatem powiedzieć, że optymalne planowanie obejmuje jeden kolejny kwartał. Dodatkowo SAFe zaleca również, aby podczas planowania przyszłej pracy kadencje sprintu trwały 2 tygodnie, co daje nam od 4 - 6 sprintów.
Kolejnym ważnym elementem wydarzenia jest współpraca. Podczas PI Planningu Zespoły Agile mają doskonałą okazję do synchronizacji swoich planów, omówienia zależności oraz ryzyk, które mogą się pojawić podczas tworzenia realizacji planu w kolejnym kwartale.

Przygotowanie do PI Planning

Przed każdym PI Planningiem musimy się przygotować jako Zespół Agile, Product Ownerzy oraz inne osoby biorące udział w planowaniu w ramach ART. Dobre przygotowanie może ułatwić zespołom wykorzystanie dwóch dni na zaplanowanie pracy na 8 - 12 tygodni. Co więc robimy? Przed PI Planningiem warto zarezerwować czas, aby każdy Zespół Agile mógł wykonać Refinement Funkcjonalności (Features), wytypowanych przez Product Management jako kluczowe. SAFe rekomenduje wybranie tzw. Top 10 Features, czyli 10 najważniejszych funkcjonalności. Dobrą praktyką podczas Refinementu jest to, aby w drodze do poznawania wymagań i szczegółów zadań, ocenić stopień ich złożoności, np. poprzez głosowanie. Możemy tutaj użyć techniki T-Shirt size, czyli estymowania Funkcjonalności (Features) od XS, aż po XL.

Wydarzenie PI Planning

Musimy tutaj zaznaczyć jedną bardzo ważną rolę w całym PI Planningu, jak i SAFe. Jest to mistrz całego zamieszania, czyli Release Train Engineer. RTE jest odpowiedzialny za organizację i facylitację PI Planningu. Upewnia się, że cele i oczekiwany wynik jest jasny dla wszystkich, dba o jego sprawny przebieg oraz pomaga Zespołom Agile w rozwiązywaniu przeszkód napotkanych podczas wydarzenia.

Wydarzenie PI Planning powinno trwać dwa dni, gdzie wszystkie aktywności powinny być wykonane. Przykładowy „rozkład jazdy” prezentujemy poniżej:

Pomijając agendę PI Planningu praktyką stosowaną przez RTE jest Scrum of Scrums, czyli synchronizacja wszystkich Scrum Masterów dotycząca sprawdzenia postępu planowania oraz rozmowy na temat ryzyk i przeszkód.

Jeśli chodzi o szczegółowość planowania na 8-12 tygodni, dobrą praktyką jest wykorzystanie metody EDUF (Enough Design Upfront), czyli planowanie dwóch najbliższych sprintów z większą ilością szczegółów. Pozostałe sprinty mogą zawierać historyjki na poziomie bardziej ogólnym z naciskiem na identyfikację zależności. Pamiętajmy, że w ramach kadencji Przyrostu Programu zespoły będą uczestniczyć w wydarzeniach na poziomie zespołu np. Planowania Sprintu. Więc wraz z nabyciem większej wiedzy plany najprawdopodobniej ulegną zmianie.

Dzień 1 PI Planningu

Kontekst Biznesowy - jest to spotkanie otwierające PI Planning, gdzie Właściciel Biznesowy (Business Owner) lub osoby z Managementu (Senior Executives) przedstawią informacje na temat warunków biznesowych otaczających produkt oraz wizję całego portfolio produktowego.

Produkt Wizja Rozwiązania - Product Management przekazuje informacje na temat obecnej wizji produktowej oraz zaznacza zmiany, które miały miejsce od ostatniego PI Planningu. Omawiane są również, jak wygląda obecnie rozwiązanie, jak wyglądają poszczególne części produktu (Features), jak się ze sobą komunikują itp.

Wizja Architektury & Standard Developmentu - Architekci systemowi (System Architects/Engineering) prezentują wizję architektury rozwiązania systemowego. Dodatkowo osoba, która pełni funkcję System Architekt/Engineer przedstawia wspierające Agile praktyki, jakimi mogą być jak automatyzacja testów, DevOps czy CI/CD.

Zasady Planowania & Lunch - Release Train Engineer przedstawia proces planowania oraz jakie spodziewany wynik na koniec PI Planningu.

Planowanie w Zespołach Agile (I Runda) - po wysłuchaniu wszystkich informacji odnośnie Pi Planningu oraz Produktu Zespoły Agile rozchodzą się do swoich grup, gdzie rozpoczyna się pierwsza iteracja planowania przyszłych sprintów. Zespół Agile wraz ze Scrum Masterem oraz Product Ownerem współpracują nad ułożeniem planu dla poszczególnych iteracji Produktu. Scrum Master podczas tego wydarzenia jest osobą, która facylituje dyskusje oraz działania Zespołu Agile. Podczas tego wydarzenia Zespoły Agile tworzą pierwszą wersję planu na najbliższy kwartał.

Warto tutaj wspomnieć o bardzo ważnym elemencie, jakim są zależności. W momencie planowania Features na przyszłe sprinty może się okazać, że dany Zespół Agile będzie potrzebował wsparcia innego zespołu, aby móc ukończyć swoje zadanie/a. Dlatego też podczas PI Planningu wykonujemy 2 czynności:

1. Ustalenie zależności oraz uzgodnienie z innymi Zespołami Agile sekwencji i synchronizacji pracy.
2. Uzupełnienie Tablicy Zależności / Tablicy Programu (Dependency Board/ Program Board) między Zespołami Agile, w celu zapewnienia transparencji i ułatwienia monitorowania zmian podczas kadencji Przyrostu Programu

Wstępny przegląd planów - Zespoły Agile prezentują wstępny plan na przyszłe sprinty lub to, co im się udało stworzyć podczas planowania. Dodatkowo informują o ewentualnych problemach z planowaniem, ryzykach i zależnościach. Interesariusze, czyli Właściciele Biznesowi, Managerowie Produktu oraz inne Zespoły Agile komentują lub pomagają w wyjaśnieniu kwestii podniesionych przez Zespół Agile.

Przegląd planów przez management oraz rozwiązywanie problemów - po każdym Wstępnym Przeglądzie Planów management spotyka się w celu ich omówienia oraz znalezienia jakieś rozwiązania danych sytuacji, ale również negocjacji zakresu zadań dla Zespołów Agile. Release Train Engineer (RTE) odpowiada za facylitację tego spotkania oraz również za pomoc w znalezieniu rozwiązań tzn. dba o to, aby management wypracował rozwiązania, które są możliwe do osiągnięcia przez Zespoły Agile.

Dzień 2 PI Planningu

Korekta Planowania (przegląd) - Management prezentuje wynik spotkania Przeglądu Planów oraz Sesji Rozwiązywania Problemów. Zostają przekazane informacje na temat zmiany zakresie planowania, rozwiązania ryzyk oraz problemów.

Planowanie w Zespołach Agile (II Runda) - po poznaniu przez uczestników ewentualnych zmian z PI Planningu, Zespoły Agile rozchodzą się do swoich grup, gdzie kończą planowanie przyszłych sprintów. Podczas tej części Zespoły Agile finalizują swoje prace oraz dopracowują zależności z innymi Zespołami Agile.

Finalny przegląd planów & Lunch - Zespoły Agile prezentują swoje plany na przyszłe sprinty (przypominamy planowanie optymalne dla 4-6 sprintów). Na koniec prezentacji każdego z planów, Zespoły Agile przekazują informację odnośnie ryzyk i zależności. Dodatkowo Zespół Agile podczas tego spotkania uzyskuje zgodę Właściciela Biznesowego na swój plan. W momencie, gdy Business Owner nie akceptuje planu, Zespół Agile dostaje możliwość jego zmiany/aktualizacji. Po wykonaniu zmian, plan jest jeszcze raz przedstawiany do akceptacji.

Ryzyka programowe - tak jak wspomnieliśmy, Zespoły Agile również informują o ryzykach i problemach. Każde z nich jest rozwiązywane, tak aby nie stanowiło przeszkody w osiągnięciu celu przez Zespoły Agile. Aby pomóc przy ich rozwiązaniu oraz kategoryzacji, korzystamy z podejścia ROAM (Resolved, Owned, Accepted, Mitigated).

Głosowanie n.t. wykonalności planu - tak zwany Confidence Voting jest wykonywany praktycznie na końcu PI Planningu. Każdy Zespół Agile korzystając ze swojej dłoni głosuje na plan swojego Zespołu Agile przez pokazanie palcami poziomu zaufania od 1-5, gdzie jeden oznacza, że plan praktycznie jest nie do wykonania, a 5 oznacza wykonanie go w 100%.

Zmiany do planów Zespołów Agile - jeżeli jest taka potrzeba, Zespoły Agile w swoich grupach dokonują zmian w obecnym planie, aby zminimalizować ryzyka, zależności lub stał się on wykonalny.

Retrospektywa PI Planningu - wydarzenie jest prowadzone przez Release Train Engineer (RTE) w celu zebrania informacji co poszło dobrze, co nie do końca się udało i co można zrobić inaczej podczas następnego PI Planningu.

Wynik PI Planningu

Po zakończeniu PI Planningu, Release Train Engineer (RTE) i inni interesariusze Agile Release Train (ART) podsumowują indywidualne cele PI (PI objectives) każdego z Zespołów Agile w zestaw celów programu PI i używają ich do śledzenia postępów w realizacji celów. Tablica Programu (Program Board) jest często używana podczas Scrum of Scrums do śledzenia zależności oraz postępu prac.

Na koniec najważniejsze: Agile Release Train (ART) przystępuje do wykonania PI, śledząc postępy prac i dostosowując się w razie potrzeby do zmian, które zachodzą, gdy pojawia się nowe informacje dotyczące produktu. Wykonywanie PI rozpoczyna się od zaplanowania przez wszystkie Zespoły Agile pierwszej iteracji, wykorzystując swoje plany PI jako punkt wyjścia.

Tyle teorii. Jeśli chciałbyś zobaczyć, jak PI Planning wygląda w praktyce, teraz masz na to unikalną okazję. Zespół SAFe z Deloitte organizuje symulację PI Planningu, podczas którego będzie można zobaczyć na żywo PI Planning w pigułce.