Co proponuje SAFe?

Termin Scaled Agile Framework został stworzony przez Deana Leffingwella i opisany w jego książce „Agile Software Requirements” w 2011 r. Leffingwell proponuje sprawdzone dobre praktyki i zaprzęgnięcie różnych metod Agile do działalności firmy. SAFe łączy w sobie Scrum, XP, Kanban i Lean. Wszyscy menedżerowie zaangażowani w SAFe (liderzy określani jako Lean-Agile Leaders) powinni kierować się zasadami Lean Management, planowania długofalowego i filozofii Kaizen. O ile takie połączenie wydaje się rozsądne, o tyle sposób wykonania i niektóre pomysły budzą kontrowersje wśród doświadczonych praktyków Agile. SAFe to praktycznie pełny ekosystem odpowiadający na wiele pytań „jak?” od poziomu budżetu do integracji przyrostów wykonywanych przez pojedyncze zespoły.

Framework SAFe jest podparty dziewięcioma zasadami zaczerpniętymi z Agile i Lean:

• Patrz z perspektywy ekonomii.

• Zastosuj myślenie systemowe.

• Załóż zmienność, zachowaj opcje.

• Buduj przyrostowo, korzystając z szybkich, zintegrowanych cykli uczenia.

• Oprzyj kamienie milowe na obiektywnej ocenie działających systemów.

• Zwizualizuj i ogranicz WIP, zmniejsz rozmiar porcji i zarządzaj długością kolejek.

• Nadaj rytm, synchronizuj z wskrośdomenowym planowaniem.

• Uwolnij wewnętrzną motywację pracowników umysłowych.

• Zdecentralizuj podejmowanie decyzji.

Autor łączy zespoły w większe zespoły zespołów określane jako Agile Release Train, które mają korzystać z samoorganizacji obszarze narzuconych ram. Cała koncepcja została podzielona na trzy hierarchicznie ułożone poziomy: zespół, program i portfolio.

Zobacz również:

• Partnerstwo w zakresie rozwoju oprogramowania - 5 najlepszych praktyk
• Sztuczna inteligencja pomaga rozwiązywać problemy z sieciami

Taka propozycja szybko uzyskuje aprobatę, bo jest gotową instrukcją do wdrożenia. Z Agile Manifesto wynika, że najlepsze pomysły i rozwiązania wyłaniają się z samoorganizujących się zespołów.

Na najniższym poziomie zespoły stosują Scrum, pracując w dwutygodniowych, zsynchronizowanych w obszarze programu iteracjach, dostarczając przyrosty produktu po każdych dwóch tygodniach. Scrum nie określa praktyk, jakie mają stosować deweloperzy i testerzy, ale można wykorzystywać te sprawdzone i dobrze określone w programowaniu ekstremalnym, w skrócie XP. Praktyki XP poprawiają jakość rozwiązań i produkowanego kodu. Z tego powodu zespoły są określane jako zespoły ScrumXP. Można również korzystać z Kanban zamiast Scrum. Na poziomie zespołów pracujemy z rejestrem zespołu i wymaganiami w postaci user story. Każdy zespół ma wykonawcę Scrum i właściciela produktu. Rejestr zespołu powstaje na planowaniu wspólnym dla całego programu.

Na poziomie programu zespoły są pogrupowane wokół strumienia wartości biznesowej w tzw. Agile Release Trains (w skrócie ART). Określone jest to jako cadence (najlepszym odpowiednikiem tego wyrazu jest tempo, sprawdza się tu także metafora pociągu). Cadence wyznacza rytm dla całej organizacji. ART startuje wraz ze wspólnym planowaniem kolejnego wydania (Release), które zawsze składa się z pięciu iteracji po dwa tygodnie. Jednym z wyników spotkania jest tablica programu (Program Baord), która wizualizuje, co robią poszczególne zespoły i jakie są pomiędzy nimi zależności. Przygotowanie i przebieg spotkania są szczegółowo opisane.

Wypuszczenie przyrostu na produkcję następuje, kiedy biznes uzna, że uzyska wystarczającą wartość i może stworzyć przyrost programu. Słowem, jest możliwość wydań na produkcję poza rytmem całego „pociągu”. Każde wydanie musi dostarczyć zestaw funkcjonalności i elementów architektury. Cztery iteracje są jak sprinty, ale ostatnia jest poświęcona na innowację i planowanie kolejnego pociągu. Żeby to podkreślić, piątą iteracją jest Innovation and Planning (IP). To czas na przygotowanie produktu do wydania (hardening) i dowolnej innowacji zespołów (hackathon). Ta druga praktyka jest zgodna z coraz śmielej propagowaną ideą pozostawiania slack time w Kanban i praktykami w firmach Google czy Spotify.