Zobacz, co nowego w SAFe 4.0!

W stycznia 2016 r. Publicznie została wydana całkowicie nowa wersja Scaled Agile Framework (SAFe). Nie było to niewielkie przyrostowe wydanie, ale duża partia z kilkoma zasadniczymi zmianami i ulepszeniami.

W poprzednich wersjach SAFe zawsze występowało połączenie drobnego udoskonalenia ról, zmiany terminologii i / lub zmienionych wytycznych. Czasami na publicznej stronie internetowej były niewielkie zmiany. Jednak tym razem nastąpiła znaczna ewolucja. Struktura jest teraz łatwiej skalowalna dla tysięcy lub dziesiątek tysięcy praktyków Agile pracujących nad wspólnym zestawem rozwiązań, które wymagają innego poziomu myślenia, koordynacji i wzorców adopcji.

Podróż do V4

W SAFe v3 i wcześniejszych wersjach, skalowanie było bardziej ukierunkowane na mniejszą skalę, oferując wskazówki tylko dla praktykujących. Poprzednia iteracja Dużego Obrazu SAFe organizowała program, jak również kluczowe role realizujące różne jego aspekty w sposób poniżej:

SAFe v3.0 big poster

Bardziej powszechny był jeden Value-Stream (VS) z jednym Agile Release Train (ART). Ponieważ VS powiększył się w wyniku przyjęcia Agile, można było zobaczyć dodatkową formę ARTs. Ponieważ każdy ART był około 50-125 praktykujących, matematyka się sprawdziła. Koordynacja wielu SZT w obrębie dużego VS była trochę trudna, ale nie była nierozsądna. Dla małych i średnich przedsiębiorstw wykonujących prace w dużej mierze w oparciu o koncepcje Scrum i eXtreme Programing (XP), był to w większości dobry początek.

Coraz większe przedsiębiorstwa zaczynały jednak zdawać sobie sprawę z praktycznego użycia SAFe – uznając jednocześnie, że tradycyjne techniki rozwoju, nie mają zamiaru natychmiast przestać istnieć. Ponadto, wiele istniejących przedsiębiorstw przyjęło Kanbana na wielu poziomach. Problemy polegały na tym, że nie były one tak naprawdę wyraźnie określone w v3. Oczywiście, było to dorozumiane – i jeśli kopać wystarczająco mocno, można znaleźć streszczenie lub blog opisujący podejście lub dwa lub niektóre pomysły, ale tak naprawdę nie były one skodyfikowane w SAFe. Co więc robili konsultanci ds. transformacji? Cóż, wielu z nas eksperymentowało z różnymi wzorcami adopcji, aby dopasować je do potrzeb klienta. Jeśli jesteś lub byłeś Agile Coachem of Transformacji Zwinnej Przedsiębiorstw, możesz rozpoznać niektóre z tych wzorców projektowych:

• Opracowanie Portfolio Portfeli do agregacji strategii, budżetów i prognozowania
• Wymyślanie nowych ról wspomagających koordynację wielu części składowych, opartych na istniejących rolach na poziomie programu
• Definiowanie nowych kadencji ceremonialnych w celu synchronizacji pomiędzy strumieniami wartości, ART lub tradycyjnym wodospadem
• Identyfikacja nowych artefaktów w celu ujednolicenia wszystkich tych nowych wysiłków razem
• Dodanie elastyczności w planowaniu lub wykonywaniu pracy poprzez zastosowanie modeli ciągnięcia opartych na przepływie, takich jak Kanban

Jeśli któreś z nich brzmi znajomo, to nie jesteś sam. Ostatecznie, autorzy ram SAFe uznali te same potrzeby. Znalezienie wspólnych najlepszych wzorców dla tej ewolucji wymagało wykorzystania doświadczeń, informacji zwrotnych i wniosków o ulepszenia z różnych ekosystemów Agile, takich jak:

• Doświadczenie praktykujących Konsultantów SAFe (SPC),
• Większe przedsiębiorstwa prywatne i publiczne, a także instytucje rządowe, które zaadoptowały SAFa
• Społeczności i istniejący partnerzy biznesowi
• Dostawcy oprogramowania (przykładowo VersiomOne)

Wraz z tym wkładem i połączeniem eksperymentalnych pochodnych ram, takich jak SAFe LSE, narodziła się kolejna wersja Scaled Agile Framework. Aby wyraźnie wskazać transformację samego SAFa, nawet nazwa została zmieniona na SAFe 4.0 dla Lean Software and Systems Engineering . SAFe Big Picture, naturalnie wymagał remontu:

SAFe v4.0 big poster

Teraz, gdy poznaliśmy się największą powierzchowną różnicą, poznajmy pokrótce główne różnice pomiędzy SAFe 4.0 a poprzednią wersją (wersjami). Moim zdaniem, istnieje pięć głównych różnic:

Być może najbardziej znaczącą zmianą w aktualizacji SAFe jest dodanie warstwy Strumienia Wartości. Ta opcjonalna warstwa zapewnia dodatkową kadencję i synchronizację, wraz z nowymi rolami i skodyfikowaną możliwością skalowania do dziesiątek tysięcy zaangażowanych w pracę osób nad wspólnym produktem.

Terminy Solution Intent i Solution Context są przywoływane w tej warstwie. Dlaczego? Pierwotne Solution Intent może wymagać wielu Solution Contexts do rozważenia i wdrożenia w ramach pierwotnej intencji. Platformy lub zestawy dostawców rozwiązań są tego uproszczonymi przykładami.

Koncepcje inżynierii systemowej, takie jak projektowanie oparte na zestawie (jak podkreślono w zasadzie SAFe Principle #3 „Przyjmij zmienność; zachowaj opcje”) są przywoływane jako ważne rzeczy do rozważenia podczas tworzenia Zamiaru Rozwiązania.

Model-Based Systems Engineering – paradygmat, który kładzie nacisk na wizualne modele symulacji, projektowania i komunikacji – oraz zasady, które kierują tą praktyką, są obecnie przywoływane. Kiedyś znaliśmy to pod inną nazwą – Agile Modeling – ale nie musi to być Agile per say. Musi być szczupłe i wystarczające do współpracy z zewnętrznymi dostawcami rozwiązań, które mogą wymagać minimalnego poziomu sformalizowanej specyfikacji.

Wreszcie, mamy koncepcję Dostawcy(ów) i Klienta(ów). To jest ogromne. Dostawcy mogą być wewnętrzni w dużym przedsiębiorstwie – takim jak biznesowe lub techniczne jednostki organizacyjne – lub mogą być zewnętrzni pod względem dostawców części lub dużych ilości oprogramowania/twardego/programówfirmware stron trzecich. Rola Klienta jest również nowym, powołanym dodatkiem. Agile puryści mogą na to poprzestać na stwierdzeniach typu: „To jest to, co reprezentuje menedżer produktu/właściciel produktu”. Jednak jest to błędne przekonanie. Klienci mogą być pośrednimi (wewnętrzni lub reprezentowani przez menedżera produktu/właściciela produktu) lub mogą być naprawdę zewnętrzni w stosunku do przedsiębiorstwa – np. odbiorca systemu(ów) (np. instytucja rządowa lub producent sprzętu, np. Apple, Samsung lub Microsoft).

Kanban jako mechanizm przyciągania oparty na przepływie istnieje obecnie na wszystkich poziomach Ram. Systemy Kanban mogą być łączone razem w oparciu o punkty aktywacji w modelach przejścia stanów.

SAFe opiera się na fundamencie Przywództwa, Podstawowych Wartości i Myślenia Lean|Agile. Warstwa podstawowa obejmuje wskazówki dotyczące Wspólnot Praktyki, Domu Lean SAFe, Zasad SAFe oraz spójne wzorce wdrażania.

Nie ma już oddzielnych „Epik Architektonicznych, Cech, Opowieści” jako elementów planowania. Wyewoluowały w to, czym naprawdę są: technologicznymi narzędziami zwiększającymi możliwości biznesowe. Enablery mogą być podzielone na elementy architektury, infrastruktury i eksploracji. W rezultacie nie są wymagane oddzielne systemy Kanban pomiędzy Enablerami a biznesem.

SAFe 4.0 wskazuje na fakt, że Portfel SAFe jest tylko fragmentem lub częścią większej organizacji korporacyjnej, która kieruje się lub jest ograniczona wspólnym zarządzaniem, strategią i mechanizmami finansowania. Innymi słowy, każdy program wdrożeniowy SAFe (odwzorowany na dużym obrazie) może być tylko jednym portfelem w przedsiębiorstwie, z których każdy może mieć kilka portfeli z własnym programem SAFe. Jest to potencjalnie miejsce, w którym większe przedsiębiorstwa uzyskają największą wartość z SAFe 4.0.

To tylko krótkie podsumowanie tego, jak postrzegamy jako praktycy zwinnych i cyfrowych transformacji nową wersję SAFe.