W naszym poprzednim artykule rozmawialiśmy o Epics i powiązanych procesach. Jednakże firmy mają klientów, którzy muszą jak najszybciej wdrożyć swoje potrzeby. Kto zarządza tymi wszystkimi prośbami? Kto tłumaczy je na coś, co zespoły mogą następnie wdrożyć? Kto sprawdza wyniki wdrożenia? To łatwa odpowiedź, ponieważ w Scrumie istnieje specyficzna rola zwana Product Ownerem, który zajmuje się tym wszystkim. Czy te działania i ta rola są również obecne w SAFe? Odpowiedź brzmi tak, ale z dużym zwrotem akcji.

Product Owner w SAFe (Scaled Agile Framework)

Przede wszystkim ktoś musi zarządzać klientami. Zawsze mieć z nimi kontakt. Aby stale badać ich potrzeby, odpowiadać na ich prośby, ustalać ich priorytety i definiować plan dostaw. Nie tylko to, ale ta osoba musi być ekspertem w konkretnej dziedzinie opracowywanego produktu lub usługi. Musi monitorować zmiany kontekstu rynkowego i biznesowego. Musi także być w stanie spojrzeć w przyszłość i przewidzieć z ekonomicznego punktu widzenia, co ma sens być wdrożone, czy co nie.

Po drugie, zespoły potrzebują stałej obecności kogoś, kto jest ekspertem funkcjonalnym i może pomóc im w przełożeniu potrzeb klientów na historie, które mogą zrozumieć i wdrożyć. Pomóc im nadać priorytet pracy, odpowiedzieć na wszelkie pytania, które mogą mieć podczas codziennych czynności. Potrzebują kogoś, kto poradzi sobie ze zmianami wymagań, zakresu i priorytetów z pragmatycznego punktu widzenia, jednocześnie uwzględniając ich potrzeby techniczne. Potrzebują komunikować swoje postępy ludziom biznesu w sposób zrozumiały i na który można zareagować.

Patrząc na dwie poprzednie krótkie części, czy uważasz, że jedna osoba poradzi sobie w obu obszarach? Ludzie SAFe mówią nie! Właśnie dlatego zdefiniowali dwie oddzielne role: pierwsza dotyczy klienta oraz biznesu i nazywa się Product Manager. Drugi dotyczy zespołu i technologii i nazywa się Product Owner. Czy to rozdzielenie przynosi nieco złożoności, a może konfliktowych punktów widzenia? Może i właśnie dlatego te dwie osoby muszą pracować przez większość czasu jako jedna jednostka.

Mówiąc o "podziale pracy", te dwie role, współpracując z właścicielami Epic, podzielą Epics na Funkcje, a następnie na Historie, dostarczą szacunków (w razie potrzeby angażują zespoły), pracują z nimi na etapie wdrażania i następnie ponownie agregują Historie w Funkcje i Funkcje z powrotem w Epic MVP i implementację Epic.

Budowanie dużych systemów. Stożek niepewności. Planowanie horyzontów

Kolejna sekcja odnosi się do organizacji, która musi zbudować duże rozwiązanie, system, który angażuje tysiące ludzi, ma wiele podkomponentów, wymaga dużej interakcji, a także zawiera elementy pochodzące od dostawców zewnętrznych. Czy uważasz, że rozwój i dostarczenie takiego systemu można rozwiązać dzięki zwinnemu podejściu?

Do tej pory powinieneś wiedzieć, że odpowiedź brzmi "tak". SAFe ma konfigurację dedykowaną właśnie dla takich firm, która nazywa się "Large Solution". To organizuje przedsiębiorstwo w strukturę o nazwie Solution Train w celu modelowania wszystkich potrzeb wdrożenia dużego systemu. Zaczyna się od zdefiniowania potrzeb jako Możliwości, podzielenia ich na Funkcje i Historie, wdrożenia, agregacji i weryfikacji. Ta konfiguracja określa, że Solution Train musi składać się z wielu pociągów zwinnego zwalniania, obejmuje dostawców zewnętrznych i zajmuje się aspektami integracji rozwiązania oraz równoległymi, ale równie ważnymi kwestiami, na przykład zgodnością. Znajdziesz także wszystkie role i funkcje, które współpracują w ramach tej organizacji.

Podczas iteracyjnej implementacji dowolnego rozwiązania, wszystko, co robimy, na poziomie abstrakcyjnym, ma na celu zmniejszenie "stożka niepewności" w stosunku do cech (zakresu) i projektu, które doprowadzą do sukcesu systemu zdolnego do obsługi prawdziwego klienta i potrzeby rynku. Stożek niepewności jest metaforą podkreślającą, że na początku liczba niewiadomych jest dość duża, ale stosując iteracyjne podejście, niepewności te przekształcane są w ustaloną wiedzę, ustalony projekt i ustalony zakres. Te iteracyjne kroki stanowią cykle uczenia się i jeśli spojrzymy na sposób, w jaki procesy są zdefiniowane w SAFe, możemy je zidentyfikować, zaczynając od poziomu zespołu, codziennie lub w Sprintcie, aż do cyklu przyrostu produktu, na poziomie ART oraz Solution Increment dla Solution Train.

Zdarzenia w celu prowadzenia cykli uczenia się w SAFe (Scaled Agile Framework)

Istnieją specjalne zdarzenia, które pomagają uruchomić te cykle uczenia się na każdym z trzech poziomów. Zdarzenia, takie jak planowanie przyrostu produktu, spotkania przed i po planowaniu PI, prezentacja systemu i rozwiązania. Twórcy rozwiązań muszą zrozumieć, że największy z tych cykli faktycznie kontroluje ewolucję systemu, a nowych funkcji nie można dodać szybciej niż najwolniejsza częstotliwość integracji. Tak więc, starając się zoptymalizować dostarczanie wartości i uczynić ją bardziej wydajną, podejście powinno być od góry do dołu.

Ponieważ wszystko jest zwinne i nawet tak duża organizacja będzie musiała być w stanie szybko zareagować na zmiany, można stworzyć fałszywe wrażenie. Wrażenie, że w świecie zwinnym nie ma planowania, nie ma kontroli i wszystko jest tylko chaosem. Ale jeśli przyjrzymy się dokładniej, zobaczymy, że tak naprawdę w Agile jest więcej planowania niż w tradycyjnym podejściu. Na przykład w Waterfall wszystkie plany mają miejsce na początku, a założeniem jest, że można przewidywać przyszłość z dużą precyzją.

W SAFe, będąc w kontekście dużego rozwiązania, możemy zidentyfikować co najmniej pięć horyzontów planowania, począwszy od wysokiego poziomu szczegółowości i silnego zaangażowania do bardziej gruboziarnistych i mniej zaangażowanych w:

• Dzienny plan na poziomie zespołu - dzieje się to głównie podczas codziennych stand-upów
• Iteracja / sprint - plan definiujący pracę, nad którą zespół będzie pracował podczas następnej iteracji
• Planowanie przyrostu produktu - na poziomie Programu i obejmujące Zatwierdzone Funkcje i Enabler dla bieżącego PI
• Plan produktu - obejmująca krótkoterminową (3-4 PI) ocenę funkcji i kamieni milowych
• Plan rozwiązania - obejmująca wieloletnią wizję, kamienie milowe, wydarzenia i plan działania dla Rozwiązania

Chcesz wdrożyć SAFe w swojej organizacji? Sprawdź nasze portfolio szkoleń SAFe.

Iulian Velea
Technical Project Manager | Certified SAFe® Program Consultant (SPC4)