SAFe. Continous Delivery Pipeline

SAFe. Continous Delivery Pipeline

Podstawowym celem wszystkich konfiguracji dostarczanych przez SAFe jest tworzenie wysoce wydajnych fabryk z rzeczywistymi "rurociągami" produkcyjnymi zapewniającymi zrównoważony i ciągły przepływ wartości o najlepszej wydajności ekonomicznej, w jak najkrótszym czasie, ze stałą uwagą w celu eliminacji strat i opóźnień.
14 kwi 2020 984
Podstawowym celem wszystkich konfiguracji dostarczanych przez SAFe jest tworzenie wysoce wydajnych fabryk z rzeczywistymi "rurociągami" produkcyjnymi zapewniającymi zrównoważony i ciągły przepływ wartości o najlepszej wydajności ekonomicznej, w jak najkrótszym czasie, ze stałą uwagą w celu eliminacji strat i opóźnień.

W tym momencie możemy już podkreślić fakt, że głównym celem wszystkich konfiguracji dostarczanych przez SAFe jest tworzenie wysoce wydajnych fabryk z prawdziwymi "rurociągami" produkcyjnymi zapewniającymi zrównoważony i ciągły przepływ wartości o najlepszej wydajności ekonomicznej, w najkrótszym czasie czas ze stałą uwagą na eliminację strat i opóźnień.

Jest to najlepiej widoczne, jeśli spojrzymy na konfigurację programu, w której Agile Release Train jest zorganizowany dokładnie wokół idei wdrożenia koncepcji ciągłej dostawy z czterema podprocesami:
  • Ciągła Eksploracja
  • Ciągła Integracja
  • Ciągłe Wdrażanie
  • Wydanie na Żądanie

Element Ciągłej Eksploracji jest prowadzony głównie przez PM, którzy współpracują z klientami w celu zaspokojenia ich potrzeb, analizują badania rynku i handlu oraz inne źródła informacji. Współpracują również z architektami w celu zdefiniowania najlepszego rozwiązania technicznego do realizacji tych potrzeb i syntetyzują całą tę pracę w Vision, Roadmap i priorytetowej liście Features, które mają zostać wdrożone przez zespoły w pociągach.

Proces Ciągłej Integracji to praca wykonywana przez zespoły w celu podzielenia funkcji na historie użytkowników, wdrożenia tych historii, ciągłej integracji każdego pionowego segmentu nowej funkcjonalności, przetestowania go, a także integracji z pracą wszystkich innych zespołów w celu ponownego zgromadzenia Stories w Features. W tym punkcie PM mogą potwierdzić początkowe założenia. Ogromny wkład ma automatyzacja uruchamiania zestawów testowych w środowiskach pomostowych emulujących produkcję.

W odniesieniu do ciągłego wdrażania, SAFe przyjmuje inne podejście od poprzedniego wspólnego zrozumienia, które, krótko mówiąc, oznaczało, że powinieneś dostarczać do produkcji w sposób ciągły, bez względu na to, czy tobie, czy klientom to się podoba, czy nie, lub jesteś na to przygotowany. W SAFe wdrożenie jest całkowicie oddzielone od wydania.

Ciągłe Wdrażanie to proces, który obsługuje sprawdzanie poprawności nowego przyrostu systemu w środowiskach, które są w 100%, jeśli to możliwe, podobne do rzeczywistych środowisk produkcyjnych. Te środowiska wdrażania mogą w niektórych przypadkach być dokładnie środowiskami produkcyjnymi, ale nie oznacza to, że nowe wdrożone funkcje są natychmiast dostępne do rzeczywistego użycia.

Nowe Features są sprawdzane osobno w tych środowiskach, w połączeniu z resztą nowych dodanych elementów i sprawdzania, czy nie psują również starszych funkcji. Jeśli wdrożenie odbywa się w rzeczywistych środowiskach produkcyjnych, istnieją techniki takie jak "feature toggles", "canary releases" i "dark launches", które "ukrywają" nową funkcjonalność przed zdecydowaną większością użytkowników, pozwalając na testowanie w prawdziwym świecie, ale w kontrolowanych warunkach.

Praca na bardzo skomplikowanych systemach oznacza, że wydanie jest czasem krokiem, który wymaga widocznej pracy, takiej jak zbudowanie pakietu, aktualizacja dokumentacji, przeszkolenie użytkowników, uzyskanie akceptacji dla aspektów takich jak zgodność i tak dalej. Oznacza to, że ciągła dostawa nie jest możliwa w większości przypadków.

Każda organizacja musi jednak być w stanie zainicjować proces wydania, gdy nadejdzie żądanie. Dlatego modelowanie podprocesu "Wydanie na Żądanie" jest koniecznością dla wszystkich organizacji, a wszystkie trzy poprzednie podelementy powinny wspierać tę zdolność i sprawić, by była jak najbardziej płynna i wydajna.

Jednym z głównych celów każdego programu SAFe powinna być pełna automatyzacja "rurociągu" ciągłego dostarczania związanego z każdym aspektem, od integracji i testowania do udostępniania i wdrażania środowiska.

SAFe Continous Delivery Pipeline.jpg


Wdrożeniowa rola inżyniera pociągu i Scrum Mastera w SAFe


Trwa długa dyskusja na temat roli Scrum Masters w Agile. Wszystkie obowiązki, cechy i funkcje obowiązują również w SAFe. A ponieważ zespół Agile prawie nigdy nie jest niezależny, w SAFe jest to jeszcze bardziej oczywiste. Zespół powinien być zdolny do samodzielnej pracy przez większość czasu, ale zawsze mając na uwadze zależności z innymi zespołami w pociągu.

Tak więc funkcja i obowiązki SM mają powiązania rozciągające się na zewnątrz na prawie każdą inną rolę, ceremonię i proces w SAFe. A ponieważ ktoś musi się upewnić, że "mechanizmy" pociągu działają z najwyższą wydajnością, nowa rola została zdefiniowana specjalnie do wykonywania pracy Scrum Master, ale na poziomie Programu. Rolą tą jest Inżynier ds. Uwolnienia Pociągu działający jako Główny SM dla całego pociągu obsługującego procesy Programu. Ta postać jest głównym punktem eskalacji dla SM każdej drużyny, jest głównym organizatorem ceremonii na poziomie programu, pomaga w usuwaniu przeszkód dla całego pociągu, działa jako trener SAFe i tak dalej.

Chcesz wdrożyć SAFe w swojej organizacji? Sprawdź naszą ofertę szkoleniową SAFe.



Iulian Velea
Technical Project Manager | Certyfikowany konsultant programu SAFe (SPC4)

Udostępnij

Masz jeszcze jakieś pytania?
Skontaktuj się z nami
Thank you!
The form has been submitted successfully.