Czym jest SAFe?

W celu wyjaśnienia czym jest SAFe (Scaled Agile Framework) wykorzystam powyższą grafikę.

Cel SAFe przedstawiony jest na górze grafiki. Jest nim pomoc organizacji w osiągnięciu zwinności biznesowej (ang. Business Agility). Realizowane jest to poprzez wdrożenie podejść Lean, Agile oraz DevOps. SAFe zawiera zestaw zasad i dobrych praktyk, aby to umożliwić.

Zbudowany jest wokół 7 głównych kompetencji przedstawionych na grafice z lewej strony (6 kompetencji) oraz na dole (jedna kompetencja).

Szczegóły głównych kompetencji SAFe wraz z wyjaśnieniem zostały przedstawione na Rysunku 2.

Dodatkowo na Rysunku 1 możemy zaobserwować, że fundamentem, podstawę SAFe stanowią dodatkowo:

• Core Values,
• Lean Agile Mindset,
• SAFe Principles,
• Implementation Roadmap,
• SPC.

Szczegóły możesz znaleźć na oficjalnej stronie SAFe. Wystarczy, że na głównej grafice przedstawiającej konfigurację SAFe wybierzesz zagadnienie, które Cię interesuje. Zostaniesz przekierowany do szczegółowej dokumentacji.

Jakie są konfiguracje SAFe?

SAFe występuje w 4-ch konfiguracjach nazywanych:

• Essential,
• Large Solution,
• Portfolio,
• Full.

Rozpocznijmy od konfiguracji Full.

W konfiguracji SAFe Full możemy wyróżnić kilka poziomów, na których występują zespoły:

• Portfolio,
• Rozwiązania,
• Programu,
• Zespołu.

Na każdym poziomie występują zespoły oraz Backlog. W konfiguracji SAFe Full na poziomie Portfolio występuje Epic Owner oraz Enterprise Architect. Epic oraz Enabler zarządzane są poprzez Portfolio Backlog.

Na poziomie Solution występuje Solution Architect/Eng., Solution Management oraz Solution Train Engineer (STE). Capability oraz Enabler zarządzane są poprzez Solution Backlog.

Na poziomie Programu występuje System Architect/Eng., Product Management oraz Release Train Engineer (RTE). Feature oraz Enabler zarządzane są poprzez Program Backlog.

Na poziomie zespołu występuje Product Owner, Scrum Master oraz pozostali członkowie zespołu. Story oraz Enabler zarządzane są poprzez Team Backlog.

Na każdym poziomie występują również tablice Kanban.

W konfiguracji SAFe Porfolio występują poziomy Portfolio, Programu oraz Zespołu.

W konfiguracji SAFe Large Solution występują poziomy Rozwiązania, Programu oraz Zespołu.

W konfiguracji SAFe Essential występują poziomy Program oraz Team.

Więcej na temat konfiguracji SAFe znajdziesz w sekcji SAFe for Lean Enterprises.

Czym jest Backlog, Epic, Capability, Feature, Story czy Enabler omówimy w dalszej części artykułu.

Rozpocznijmy od omówienia jak wygląda praca na poziomie zespołu.

Jak wygląda praca na poziomie zespołu?

W konfiguracji SAFe (przykładowo w konfiguracji Full przedstawionej na Rysunku 3) na dole po lewej możemy znaleźć Zespół Agile. Składa się on z od 5 do 11 osób w tym Scrum Master oraz Product Owner.

Scrum Master odpowiedzialny jest za wsparcie oraz pomoc zespołowi w realizacji zaplanowanych celów iteracji. Zajmuje się organizacją i moderowaniem spotkań, rozwiązywaniem konfliktów, usuwaniem przeszkód realizacji celów iteracji oraz edukowanie o SAFe.

Product Owner natomiast reprezentuje Klienta przed Zespołem. Odpowiada za priorytetyzację Backlogu, definiowanie Historyjek (Story) oraz ich kryteriów akceptacji. Współpracuje również przy opracowaniu wizji oraz roadmapy.

Na dole diagramu możemy zauważyć, że Zespół Agile pracuje w iteracjach. Wykorzystuje Scrum, tablicę Kanban oraz Team Backlog.

W Team Backlog znajdują się Historyjki (Story) oraz Enablers.

Wydarzenia Zespołu Agile

Głównymi wydarzeniami zespołu są:

• Daily Stand-up (DSU),
• Iteration planning,
• Iteration review,
• Iteration retrospective,
• Backlog refinement.

Spotkanie Daily Stand-up (DSU) jest to krótkie codzienne spotkanie około 15 minutowe.

Podczas spotkania zespół odpowiada na kilka pytań:

• co wczoraj zrobiłem, aby zrealizować cele iteracji?
• co planuję robić dzisiaj, aby zrealizować cele iteracji?
• czy mam jakieś ograniczenia, aby zrealizować cele iteracji?

Iteration planning polega na zaplanowaniu pracy dla zespołu na kolejną iterację. Podczas spotkania ustalamy możliwości zespołu. Musimy wziąć pod uwagę planowane urlopy, szkolenia czy inne nieobecności. Następnie zespół analizuje oraz estymuje historyjki. Wspólnie z Product Ownerem ustalane są cele najbliższej iteracji. Product Ower odpowiada za priorytetyzację historyjek oraz enablers. Ostatnim etapem jest potwierdzenie przez zespół, że zrealizuje cele iteracji. Bardzo ważne jest, aby do planowania być odpowiednio przygotowanym. Product Owner musi wcześniej przygotować Backlog zespołu. Wszystkie historyjki muszą być znane zespołowi wcześniej. Podczas planowania nie możemy omawiać nowych historyjek.

Iteration review jest spotkaniem, na którym przeglądamy czy cele iteracji zostały zrealizowane oraz zaplanowane zadania. Jest to też spotkanie, na którym powinniśmy otrzymać informację zwrotną od głównych stakeholderów.

Iteration retrospective ma na celu identyfikację kluczowych elementów, które powinniśmy poprawić. Na spotkaniu powinniśmy wybrać 1-2 problemy/zagadnienia i zastanowić się jak możemy je poprawić w najbliższych iteracjach. W wyniku powinniśmy przygotować historyjkę lub enabler i umieścić go w Team Backlogu w celu realizacji w przyszłości.

Backlog refinement ma na celu szczegółowe omówienie historyjek przez Zespół z Product Ownerem. Historyjki powinny zawierać odpowiedni opis oraz kryteria akceptacji. Tak przygotowane historyjki będą gotowe do zaplanowania podczas planowania iteracji.

Team Backlog

Team Backlog zbudowany jest z historyjek (User Story) oraz enabler story. Mogą również pojawić się tzw. spikes. Możemy to zaobserwować na Rysunku 3. Po prawej stronie od Team Backlog znajdują się Story oraz Enabler, które są realizowane przez Zespół podczas iteracji.

Historyjka (User Story) jest krótkim opisem funkcji systemu, który ma zostać dostarczony. Opisywane są w postaci zrozumiałej przez użytkownika. Historyjka musi zostać zrealizowana przez zespół w trakcie iteracji. Nie może być dłuższa niż jedna iteracja. Jeśli jest za duża wówczas powinna zostać podzielona

Dobrą praktyką jest definiowanie historyjki według formatu: Jako (rola użytkownika) chciałbym/chciałabym (aktywność) tak, aby (wartość biznesowa). Rozmiar historyjki opisujemy przez „Story points”.

Więcej na temat historyjek możesz poczytać na stronie SAFe o Story.

Enabler Story są historyjkami, które wspierają realizację User Story a związane są z przygotowaniem infrastruktury, projektowaniem architektury, odkrywaniem możliwych rozwiązań czy weryfikacji zgodności rozwiązania ze standardami. Bardzo często Enabler związany jest z zaprojektowaniem architektury rozwiązania czy przygotowaniem infrastruktury.

W Team Backlog możemy również znaleźć Spike. Jest to Enabler polegający na odkrywaniu (ang. exploration enabler). Może polegać na pozyskaniu dodatkowej wiedzy technicznej. Spike może zostać dodany do Team Backlog w dowolnym momencie.

Na Rysunku 3 przy Team Backlog możemy również zaobserwować, że pod backlogiem znajduje się informacja o wymaganiach niefunkcjonalnych (NFR). W SAFe wymagania niefunkcjonalne są przeważnie częścią DoD (Defintion of Done) historyjki. Wymagania niefunkcjonalne są ograniczeniami projektowanego rozwiązania. Definiują atrybuty rozwiązania takie jak bezpieczeństwo, niezawodność, wydajność, skalowalność czy użyteczność.

Więcej o wymaganiach niefunkcjonalnych NFR możesz znaleźć na stronie SAFe o NFR.

Team Backlog w SAFe powiązany jest z Program Backlog, który omówię w dalszej części artykułu.

Zespół podczas pracy korzysta z tablicy Kanban nazywanej na tym poziomie Team Kanban. Kanban jest narzędziem umożliwiającym monitorowanie przepływu historyjek. Ma postać charakterystycznej tablicy, w której kolumny są możliwymi statusami historyjki. Umożliwia zwizualizowanie statusu wszystkich historyjek z iteracji.

Przykładowa tablica Kanban zespołu dostępna jest na stronie SAFe o Kanban.

Jak wygląda praca na poziomie programu?

Przejdźmy teraz do omówienia poziomu programu oraz wyjaśnienia jak wygląda praca na poziomie programu.

W konfiguracji SAFe po lewej nad zespołem Agile widzimy Business Owners, System Architect/Engineering, Product Management oraz RTE. Po prawej widzimy Agile Release Train, Feature oraz Enabler. Jest to poziom programu. Wyjaśnimy te pojęcia.

Agile Release Train (ART) jest zespołem Zespołów Agile. Składa się z od 5 do 12 zespołów, czyli od 50 do 120 osób. ART musi posiadać umiejętności i kompetencje, aby być w stanie zaprojektować rozwiązanie, zaimplementować, wdrożyć i dostarczyć rozwiązanie do Klienta. W związku z tym, że występuje wiele zespołów Agile ich praca musi być zsynchronizowana oraz transparentna dla innych. W tym celu zespoły pracują w ramach Program Increment (PI) a ich praca zarządzana jest poprzez Program Backlog. W Program Backlogu występują Features oraz Enablers, które wyjaśnię w dalszej części artykułu.

Do pracy wykorzystywana jest również tablica Kanban.

Na poziomie programu występuje Release Train Engineer (RTE). Jest to szef Scrum Masterów dla całego pociągu (train).

Product Manager odpowiada za zarządzanie Program Backlogiem, przygotowaniem wizji oraz roadmapy. Pełni rolę szefa Product Ownerów.

Możemy również wyróżnić System Architect/Engineering, który odpowiada za przygotowanie architektury, wytycznych czy technicznych enablerów dla pociągu.

Business Owners reprezentuje głównego stakeholdera dla pociągu.

Wydarzenia Agile Release Train (ART)

Praca całego Agile Release Train (ART) odbywa się w ramach Program Increment (PI). Jest to okres, podczas którego zespoły pracują nad dostarczeniem działającego oraz przetestowanego rozwiązania. PI trwa przeważnie od 8 do 12 tygodni, czyli od 4 do 6 iteracji. Ostatnia specjalna iteracja zwana jest Innovation and Planning (IP).

Podczas PI możemy wyróżnić kilka kluczowych wydarzeń na poziomie ART:

• PI Planning,
• ART sync:
  • Scrum of Scrums,
  • PO Sync,
• System Demo,
• Inspect & Adapt.

PI Planning jest wydarzeniem, podczas którego zespoły z ART zapoznają się z wizją, celami oraz ustalają prace na najbliższy PI. W wydarzeniu biorą udział wszyscy. Product Manager odpowiedzialny jest za priorytetyzację Features, natomiast Zespoły Agile za utworzenie i wstępną estymację historyjek. System Architect odpowiada za wyjaśnienie architektury rozwiązania. Planowanie PI powinno być spotkaniem stacjonarnym. Przeważnie trwa 2 dni. Jeśli planowanie PI jest realizowane online wówczas może trwać 3-4 dni. Podczas planowania PI bardzo ważne jest zidentyfikowanie zależności pomiędzy zespołami czy ryzyk. W celu lepszej identyfikacji zależności wykorzystywana jest Tablica Programu (Program Board), która zawiera informację o features realizowanych przez konkretne Zespoły Agile, zależności pomiędzy zespołami związane z features czy kamienie milowe. Podczas PI każdy z zespołów powinien również określić cele Zespołu Agile na następny PI. Muszą być one związane z celami programu.

Przykładowa agenda PI planning dostępna jest na stronie SAFe o PI Planning.

ART sync ma na celu ustalenie czy Zespoły Agile realizują swoje cele zgodnie z planem.

Składa się ze spotkań:

• Scrum of Scrums (SoS),
• PO sync.

Podczas PI możemy również wyróżnić wydarzenie, którym jest Demo Systemu (System Demo). Jest to spotkanie, które występuje po każdej iteracji i ma na celu przedstawienie dostarczonych features oraz otrzymanie informacji zwrotnej. Podczas Demo Systemu należy zaprezentować zintegrowane rozwiązanie, czyli cały feature, który mógł być realizowany przez kilka Zespółów Agile.

Wydarzenia I&A ma na celu przeprowadzenie PI system demo, zapoznanie się ze wskaźnikami jakościowymi i ilościowymi oraz przeprowadzenie warsztatów problem-solving.

PI System Demo jest prezentowane pod koniec PI, natomiast System Demo, o którym wspomniałem wcześniej po każdej iteracji.

Program Backlog

Program Backlog zbudowany jest z Features oraz Enablers. Możemy to zaobserwować na Rysunku 3. Nad Story oraz Enabler, możemy zaobserwować Features oraz Enablers.

Feature jest funkcją systemu, którą ART musi dostarczyć w trakcie jednego PI. Zawiera nazwę, hipotezę biznesową oraz kryteria akceptacji.

Przypomnijmy, że historyjka (user story) musi być dostarczona w ciągu iteracji (np. 2 tygodniowej), natomiast feature w ciągu PI (np. 10 tygodniowego).

Feature jest implementowany przez historyjki. Może zostać podzielony na historyki, które zostaną przydzielone do różnych zespołów Agile.

Product Management współpracuje z System Architect, aby zachować odpowiednią proporcję Features oraz Enablers. Enablers budują Architecture Runway.

Enabler Feature wspiera realizację Features. Enabler może dotyczyć przygotowania architektury, zaprojektowania interfejsów, przygotowania infrastruktury czy odkrywania możliwych rozwiązań. O Enablerach mówiliśmy już przy okazji Enabler Story. W przypadku Enabler Feature różnica jest taka, że występują na poziomie programu a Enabler Story na poziomie zespołu.

Program Kanban jest metodą wykorzystywaną w celu wizualizacji, monitoringu oraz zarządzenia przepływem Features przez różne fazy. Kolumny w tablicy Kanban symbolizują kroki procesu pracy nad Features.

Jak wygląda praca na poziomie rozwiązania?

Omówmy teraz jak wygląda praca na poziomie rozwiązania (Solution).

W konfiguracji SAFe po lewej nad Business Owners znajduje się poziom Large Solution, gdzie możemy wyróżnić Solution Architect/ Engineering, Solution Management oraz STE. Po prawej stronie znajduje się Solution Train, Capability oraz Enabler. Wyjaśnijmy co oznaczają te pojęcia.

Solution Train składa się z wielu Agile Release Trains (ARTs) oraz może zawierać również zespoły zewnętrznych Dostawców. Jego celem jest dostarczanie dużych rozwiązań, dlatego wymaga wykorzystania wielu ARTs.

W Solution Train znajdują się również Solution Architect/Engineering, Solution Management oraz STE. Praca synchronizowana jest poprzez Solution Backlog oraz Solution Kanban.

Solution Train Engineer (STE) jest to szef wszystkich RTE z różnych ART. Koordynuje pracę w Trainie, wspiera RTE. Jest to rola podobna do RTE, ale na poziomie Solution.

Solution Manager odpowiada za zarządzanie Solution Backlog. Jest szefem Product Managerów z którymi współpracuje. Jest to rola podobna do Product Managera, ale na poziomie Solution.

Solution Architect/Engineering odpowiada za przygotowanie architektury na poziomie Solution. Współpracuje z System Architektami z różnych ART.

Wydarzenia Solution Train

Na poziomie Solution możemy wyróżnić wydarzenia takie jak:

• Pre-PI Planning,
• Post-PI Planning,
• Solution Train Sync,
• Architect Sync,
• Solution Demo,
• Inspect & Adapt.

Spotkania Pre- i Post- PI Planning mają na celu zaplanowanie prac dla Solution Train. Zawiera to konieczność synchronizacji wszystkich ART oraz Dostawców w celu realizacji rozwiązania. Każdy z ART musi znać wymagania, aby być w stanie odpowiednio zaplanować pracę podczas swojego PI Planning. Podczas spotkań musimy również zidentyfikować zależności pomiędzy ART i Dostawcami.

Solution Train Sync ma na celu weryfikację postępu prac, natomiast Architect Sync dotyczy synchronizacji na poziomie architektów z różnych ART i Dostawców.

Solution Demo ma na celu prezentację działającego rozwiązania natomiast Inspect & Adapt na weryfikacji wskaźników jakościowych i ilościowych. Dodatkowo możemy przeprowadzić warsztaty problem-solving.

Solution Backlog

W Solution Backlog znajdziemy Capability oraz Enabler.

Capabilities zachowują się podobnie jak Features, ale występują na poziomie Solution i dostarczane są przez Solution Train. Capability dekomponowane są na Features, które mogą być realizowane przez różne ART lub Dostawców.

Enabler Capability są enablerami, które wspierają dostarczanie Capabilities. Może to być przygotowanie architektury dla rozwiązania czy infrastruktury. O Enablers już pisałem więcej przy omawianiu poziomu programu czy zespołu.

Na poziomie Solution występuje również Solution Kanban.

Jak wygląda praca na poziomie portfolio?

Omówmy teraz jak wygląda praca na poziomie portfolio. Na poziomie potfolio omówimy tylko kilka zagadnień. Skupimy się na zespole oraz Backlogu.

Na poziomie Portfolio możemy wyróżnić Epic Owners oraz Enterprise Architect. Po prawej stronie widzimy Development Value Stream, Epic oraz Enabler. Wyjaśnijmy co oznaczają te pojęcia.

Development Value Stream jest sekwencją aktywności, która ma na celu przekształcenie hipotezy biznesowej w rozwiązanie. W skład Development Value Stream wchodzą aktywności, ludzie czy systemy. Development Value Stream skupia się na realizacji. Nad Development Value Stream możemy zaobserwować Operational Value Stream, który skupia się na celu.

Więcej o Value Stream możesz przeczytać w dokumentacji SAFe o Operational Value Streams i Development Value Streams.

Portfolio Backlog

Portfolio Backlog jest backlogiem w którym możemy znaleźć Epic oraz Enabler.

Epic musi zawierać Lean business case, definicję MVP (Minimum Viable Product), Epic Ownera oraz zostać zaakceptowany przez LPM (Lean Portfolio Management). Epic dekomponowany jest na Capabilities lub na Features w zależności od konfiguracji SAFe.

W backlog możemy również znaleźć Enabler Epic, który jest Enablerem na poziomie portfolio.

Na poziomie Portfolio występuje również Portfolio Kanban. Znajdują się w nim Epics.

W artykule opisałem tylko wybrane zagadnienia z SAFe. Mam nadzieję, że przybliżyłem Ci czym jest SAFe oraz w jaki sposób wykorzystać dokumentację w celu poszerzenia wiedzy.

Gdybyś chciał podzielić się ze mną swoim komentarzem napisz do mnie na marcin@marcinziemek.com