Wywiad z Andrzejem Maćkowiakiem, SAFe Program Consultant w Dziale Rozwoju Oprogramowania.

Czas czytania artykułu: 6 minut
Michał
18.11.2021

Każda firma informatyczna istniejąca obecnie na rynku musi zdecydować, w jakim modelu organizacyjnym chce wypuszczać swoje produkty na rynek. O tym, jak dokonać zmiany już działającego systemu bez spowalniania produkcji, opowiedział Andrzej konsultant ds. wdrażania metodologii SAFe.

Michał: Czym w ogóle jest SAFe?

Andrzej: SAFe, czyli Scaled Agile Framework, jest jedną ze zwinnych technik wytwarzania oprogramowania. Z uwagi na wciąż rosnące potrzeby naszego działu, jak i zwiększającą się liczbę pracowników, postanowiliśmy dostosować się do szybko zmieniającego się otoczenia biznesowego. Zwinność, jaką mieliśmy na poziomie pojedynczych zespołów, okazała się niewystarczająca, toteż wchodząc na jej kolejny poziom, zorganizowaliśmy się w zespoły, zwane w terminologii SAFe ARTami- Agile Release Train. Dzięki temu jesteśmy w stanie jeszcze lepiej dopasowywać się do wymagań naszych interesariuszy, a także użytkowników naszego oprogramowania, w szybki sposób dostarczając to, czego w danym momencie potrzebują najbardziej.

Dlaczego akurat SAFe?

Jak już wspomniałem, brakowało nam przede wszystkim zwinności, która oczywiście istniała w pojedynczych zespołach. Za cel postawiliśmy sobie przeskalowanie jej na poziom organizacji. Wcześniej tworzyliśmy szczegółowe plany na kilka lat w przód. Dziś po wprowadzeniu SAFe, planujemy pracę tylko z trzymiesięcznym wyprzedzeniem. Po tym okresie wybieramy kolejne funkcjonalności, którymi będziemy zajmować się w następnym okresie. Sam wybór SAFe podyktowany był jego już istniejącą implementacją w naszej branży. Jako metodologia dobrze udokumentowana, wciąż rozwijana i z dostępnością do wsparcia konsultantów w prawidłowy sposób wpasowała się w nasze potrzeby. Moja rola w byciu SPC, czyli SAFe Program Consultant polega na szkoleniu całej organizacji w metodologii SAFe, wdrażaniu jej w działach i nauczaniu zespołów zaczynających w niej pracować.

Jak wyglądała implementacja zmiany na poziomie organizacji?

Na samym początku zawiązana została grupa, której zadaniem było kierowaniem całą zmianą. Następnie wyszkoleni zostali liderzy, menadżerowie i agenci zmiany, którzy mieli za zadanie być adwokatami zmiany na krótkim dystansie w swoich obszarach odpowiedzialności. Dalej, chcąc zawiązać połączenie pomiędzy klientem a firmą, przeanalizowano obszary, które przynoszą wartość klientowi i określiliśmy tzw. Operation Value Stream’y, innymi słowy – proces ukazujący nam sposób wytwarzania wartości dodanej dla użytkownika końcowego, który z kolei przynosi wartość samej firmie. W takim procesie wykorzystywane są różne systemy – w naszym przypadku jest to Fitting Software, czyli oprogramowanie służące do dostosowywania aparatów słuchowych do potrzeb klienta protetycznego.

Dla każdego z tak zidentyfikowanych obszarów zdefiniowany został osobny ART. Mając w ten sposób opisaną strukturę organizacyjną, szkolimy ludzi odpowiedzialnych bezpośrednio za jej działanie i rezultaty, by byli oni w stanie przygotować zakres pracy. Wśród tych osób wyróżniamy nowe i już istniejące role w SAFe, z których najważniejszym jest RTE , czyli Release Train Engineer. Na samym końcu, tuż przed wystartowaniem pierwszego pociągu szkoleni są członkowie zespołów. Sercem, a zarazem zwieńczeniem wszystkich przygotowań, jest wydarzenie zwane PI - Program Increment Planningiem. Stanowi ono początek egzekucji pracy nad dostarczaniem funkcjonalności.

Jaki jest przebieg PI?

Po PI Planningu zespoły w standardowy dla siebie sposób planują iteracje, których jest zwyczajowo pięć. Owymi iteracjami są dwutygodniowe cykle pracy. Ponieważ na PI Planningu zidentyfikowaliśmy zależności między zespołami, w trakcie egzekucji PI potrzebne są synchornizacje. SAFe przewiduje dwa spotkania w tygodniu – jedno dla Scrum Masterów, a drugie dla Product Ownerów i Product Managerów. Po każdej iteracji sprawdzamy, czy jakaś funkcjonalność jest już gotowa do wydania i jeśli znajdzie się odpowiedni kandydat, zespół organizuje System Demo, podczas którego prezentuje swoje dokonania. Ostatnia z iteracji jest mniej standardowa, bowiem przewiduje ona w całości czas poświęcony innowacjom, przygotowaniu finalnego System Demo, sesji Inspect & Adapt oraz sesji PI Planningu na kolejny okres. Co do Inspect & Adapt, stanowi ono istotne wydarzenie w ciągu trwania inkrementu, gdyż pozwala ono nam na samodoskonalenie swojej pracy. Za pomocą różnych technik staramy się dotrzeć do sedna trudności i przyczyny problemów. Mając je znalezione, jesteśmy w stanie zaadresować je w kolejnej iteracji, dodając je do planu prac ARTu na przyszły cykl.

Jakie były trudności?

Wyzwaniem okazał się dość oczywisty fakt, iż SAFe był dla nas czymś zupełnie nowym, choć przecież znaliśmy już definicję zwinności. Mimo tego, startowaliśmy od zera i uczyliśmy się go w praktyce. Mieliśmy również bardzo ambitną oś czasu – w sześć miesięcy, poczynając od pierwszego szkolenia, a na pierwszym PI Planningu kończąc, udało nam się ruszyć z pracami w całkiem nowej technice. Pewną trudność stanowiło pytanie, w jaki sposób poukładać wszystkie kompetencje i czynności, do których przywiązani byliśmy wcześniej, a także jak zaadaptować je do nowego ustawienia zespołów. Wyzywaniem była także organizacja PI Planningu w kontekście pandemii, gdyż do ostatniej chwili nie wiedzieliśmy, jaki będzie status obostrzeń – w samym wydarzeniu uczestniczyła ponad setka osób z wielu krajów.

Jak wpłynęło to na dział? Jakie zmiany obserwujemy już teraz?

Jesteśmy w trakcie pierwszego PI pierwszego ARTu w ogóle, toteż ciężko wyciągać konkretne i daleko idące wnioski. Na pewno zespoły mają lepiej zdefiniowaną wizję, a co za tym idzie – lepiej zorganizowaną codzienną pracę na tym, co czeka na nas w perspektywie trzech miesięcy. Zależności są unaocznione i w łatwy sposób możemy je monitorować. Doświadczenie innych firm wdrażających SAFe pokazuje, że z czasem powinno wzrosnąć zadowolenie i zaangażowanie pracowników, skróceniu ulec ma time-to-market, poprawi się jakość wytwarzanego produktu oraz zwiększy się produktywność. Mam nadzieję, że i my napotkamy dobre doświadczenia wypływające ze zmiany, a z tych gorszych wyciągniemy pouczające lekcje.

O autorze

Michał
Michał, software developer
Niezmiennie od 1994 związany ze Szczecinem. Student informatyki WI ZUT w Szczecinie. Najmłodszy software developer w Demant. Zawodowo odpowiedzialny za warstwę UI aplikacji desktopowych. Pasjonat .NET, eksperymentator IoT, specjalista od gadania oraz na wskroś szczecińskiego braku umiaru.