W tym artykule opowiem Ci co to jest Big Room Planning i jak wygląda ono z punktu widzenia programisty. Opowiem Ci krok po kroku jak wygląda planowanie pracy całej firmy w praktyce. Zobaczysz jakie są kolejne fazy planowania Big Room i co to jest Big Room Planning.
CO TO JEST BIG ROOM PLANNING?
Spotkanie Program Increment Planning (w skrócie PI Planning), zwane też Big Room Planning to spotkanie wielu zespołów w wielkiej sali. Stąd prawdopodobnie wzięła się nazwa procesu Big Room Planning. Spotkanie to pozwala zaplanować pracę wielu zespołów programistycznych na najbliższy kwartał. W czasie takiego spotkania planujemy 6 najbliższych sprintów, co daje 3 miesiące.
Celem tego spotkania jest zaplanowanie naszej pracy na najbliższe 3 miesiące. Dzięki takim spotkaniom wszyscy pracownicy mogą poznać plany firmy na najbliższe miesiące Sama idea planowania Big Room wydaje się sensowna, bo kładziemy nacisk na współpracę między zespołami. Jeśli pracowałeś w firmach z branży IT, to pewnie wiesz, że zwykle takiej komunikacji brakuje. Dzieje się tak, kiedy szefostwo firmy boi się dzielić wiedzą ze swoimi pracownikami.
Wtedy takie planowanie pracy odbywa się w gronie kilku osób w gabinecie dyrektora.
Więcej o koncepcji Big Room Planning i o współpracy między zespołami programistów możesz znaleźć na przykład tutaj
SPOTKANIE OTWIERAJĄCE BIG ROOM PLANNING
Kiedy wszystkie zespoły w firmie spotykają się w dużej sali, to na początku przedstawiamy wizję. Pokazujemy wszystkim jakie mamy produkty, na czym zarabiamy, ile zarabiamy, jakie są nasze cele. Ta część spotkania to prezentacja dotychczasowych rezultatów i nakreślenie wizji. Wyzwania – czyli mówimy o tym co możemy zrobić lepiej, co możemy zautomatyzować, jak nasze oprogramowanie może sprawić, aby nasza firma zarabiała jeszcze więcej pieniędzy.
Technical debt – dług techniczny, czyli na przykład brak testów, albo brak środowisk testowych. Dług techniczny to wszystkie kompromisy, na które poszliśmy po to, żeby jak najszybciej dostarczyć nowe oprogramowanie. Można powiedzieć, że są to rzeczy, które musimy zrobić, ale świadomie odkładamy je na później.
Wiemy, że taki dług techniczny trzeba uwzględnić w naszej codziennej pracy.
Poza tym omawiamy tu na przykład środowiska testowe, podejścia do testowania, narzędzia, wewnętrzne biblioteki, framworki.
BREAKUT ROOM
W dotychczas opisanym procesie uczestniczyły wszystkie zespoły deweloperskie. Kolejny etap, który dzieje się zwykle tego samego dnia zakłada podzielenie zespołów. W praktyce każdy zespół idzie do swojej sali, gdzie odbywa się planowanie pracy zespołu na najbliższe miesiące. Ten etap może mieć kilka etapów. Najpierw dzielimy się na grupę dwóch zespołów, potem na osobnym spotkaniu każdy zespół osobno planuje swoją pracę.
Cel jest taki, żeby wszystkie zespoły spotkały się, kiedy zaplanują już swoje zadania.
ZALEŻNOŚCI MIĘDZY APLIKACJAMI
Teraz coś czego wiele zespołów nie robi wcale. Ustalenie zależności między poszczególnymi zadaniami. To bardzo ważny wynik naszej pracy na poziomie kilku poszczególnych zespołów. Dzięki temu etapowi jako programista mam wrażenie, że wiem więcej o tym jak działa cała firma. Na tym etapie wiemy już skąd będziemy pobierać dane i który zespół może nam w tym pomóc. To nie jest takie oczywiście, bo pracowałem w zespołach, które zaczynały prace programistyczne bez żadnego planowania. W efekcie podczas prac programistycznych nie było wiadomo nawet z kim można się skontaktować aby ustalić wspólny kontrakt, czyli strukturę danych wymienianych między aplikacjami. Zbieranie wymagań stawało się zbyt dużym obciążeniem dla programistów.
RYZYKO
Na tym etapie próbujemy przewidzieć czynniki, które mogą opóźnić dostarczanie naszego oprogramowania.
Te czynniki nazywamy ryzykiem. Oto kilka przykładów:
- Zespół nie ma doświadczenia w danej technologii
- Musimy pobrać dane z zewnętrznego systemu, więc mogą zdarzyć się problemy z integracją.
- Sezon urlopowy – brak pracowników może spowodować opóźnienia związane z dostępami, albo z tworzeniem baz danych przez dział Devops.
- Testowanie przez zespół Security może potrwać dłużej niż zakładamy
- Niespodziewane problemy podczas testowania E2E (end to end)
TESTOWANIE
Na spotkaniu w ramach zespołu zastanawiamy się w jaki sposób będziemy testowali nasze aplikacje. Rozmawiamy o tworzeniu środowisk testowych, tworzeniu baz danych, kolejek, specjalnych aplikacji zbudowanych tylko na potrzeby testów. Przykład: Każde zapytanie do państwowej usługi (na przykład KRD) generuje pewien koszt. Aby zaoszczędzić pieniądze, możemy zbudować aplikację, która udaje zewnętrzny system.
W dzisiejszym świecie większość systemów jest zbudowana z mniejszych aplikacji, które wymieniają się danymi. Te aplikacje to tzw. mikroserwisy. Dlatego musimy zaplanować testy E2E(ang. end to end). Zakres testów E2E obejmuje wiele aplikacji. Oczywiście możemy testować każdą aplikację w izolacji i robimy to zawsze, ale testy E2E pozwalają nam przetestować wszystkie aplikacje współpracujące ze sobą. Pozwala to nam wykryć ewentualne problemy w komunikacji, problemy z dostępem do danych itp.
CELE ZESPOŁU NA NAJBLIŻSZY KWARTAŁ
Ustalamy ogólne cele na nadchodzący kwartał. Mogą to być historie użytkownika, wraz z oczekiwanym terminem wdrożenia.
Jak może wyglądać cel? Oto kilka przykładów:
- Działająca strona logowania do dnia 01.01.2022
- Zamawianie rowerów w internetowym sklepie rowerowym do dnia 01.01.2021
- Rezerwacja biletów na przejazd pociągiem do dnia 20.05.2021
Jak widzisz każdy cel jest osadzony w czasie. Zespół pracujący nad daną funkcją systemu może ocenić czy termin jest osiągalny. A jeśli pojawią się jakieś zagrożenia, to w tym momencie zespół może je omówić i przygotować się na nie.
CONFIDENCE VOTING
Kiedy mamy już listę celów, zespół programistyczny ocenia w jakim stopniu jest przekonany o sukcesie. Każdy cel jest oceniany w przedziale od 0% do 100%.
Zwykle wysoko oceniamy zadania, na które mamy duży wpływ – na przykład zbudowanie aplikacji, która ma wykonać konkretne zadania, a my dysponujemy wszystkimi niezbędnymi danymi.
Ale niektóre zadania generują w programistach niepewność. Nisko oceniamy tu zadania, których realizacja zależy od innego zespołu, albo na przykład od stabilnego działania zewnętrznego systemu.
PODSUMOWNIE
Planujemy pracę w gronie konkretnego zespołu. Trwa to zwykle jeden albo dwa dni. Kiedy każdy zespół zakończy planowanie, wszyscy spotykają się ponownie w dużej sali. Może to się wydarzyć pod koniec drugiego dnia Big Room Planningu. Teraz jest czas na podsumowanie. Przedstawiciel każdego zespołu przedstawia plany danego zespołu. Należy tu przedstawić zadania, które planujemy, ryzyka jakie zidentyfikowaliśmy, oraz wyniki confidence voting.
Jeśli interesuje Cię bardziej techniczna strona programowania, to zobacz moją serię o podstawach języka C#
