Sprint w TOGAF ADM - czyli Scrum4EA (cz. IV)

Kategoria II

Niniejszy wpis stanowi kontynuację prezentowanej przeze mnie już wcześniej problematyki adaptacji technik zwinnych (na przykładzie Scrum’a) na potrzeby tworzenia architektury korporacyjnej. Roboczo podejście to określiłem mianem Scrum4EA. Tym razem chciałbym skoncentrować się na sercu Scrum’a jakim jest sprint oraz odnieść go do ADM (Architecture Development Method – czyli metody tworzenia i wykorzystania architektury korporacyjnej), będącej centralną częścią TOGAFa. Chciałbym podkreślić, że niniejsze rozważania mają charakter wstępny, dlatego będę zobowiązany za Państwa uwagi/komentarze.

Zgodnie z The Scrum Guide sprint jest to ograniczone czasowo przedsięwzięcie (czasami przyrównywane do projektu) trwające maksymalnie jeden miesiąc (lub krócej), podczas którego  powstaje przyrost używalnej i potencjalnie gotowej do wydania funkcjonalności. Czyli analogicznie jak projekt, tak i sprint ma zrealizować określony cel i dostarczyć działający produkt lub działający przyrost już istniejącego produktu (por rysunek 1).

Rysunek 1. Budowa metodyki Scrum
Źródło: Wikipedia

Sprinty mają stałą długość przez cały okres trwania prac nad produktem (czyli najczęściej n sprintów trwa n-miesięcy), a nowy sprint rozpoczyna się bezpośrednio po zakończeniu i podsumowaniu poprzedniego.

Każdy sprint zawiera opis tego, co należy zbudować, projekt do wykonania oraz elastyczny plan przeprowadzenia prac, które mają doprowadzić do powstania oczekiwanego produktu.

Na pojedynczy sprint składają się następujące czynności: planowania sprintu, codzienne  Scrum’y, okres wytwarzania, przegląd sprintu oraz retrospektywa sprintu.

Podczas sprintu:

  • Niedozwolone są zmiany, które wpłyną na przyjęty na początku cel sprintu.
  • Skład zespołu wytwórczego pozostaje stały.
  • Cele jakościowe dotyczące wytwarzanych w ramach sprintu produktów nie ulegają obniżeniu.
  • Zakres prac może być wyjaśniany i renegocjowany pomiędzy właścicielem produktu oraz zespołem wytwórczym zawsze, gdy odkrywane są nowe aspekty wykonywanej pracy.

W tym momencie pojawia się pytanie, gdzie sprint może zostać wykorzystany przy przedsięwzięciu tworzenia architektury korporacyjnej realizowanym z wykorzystaniem TOGAF ADM. Dla przypomnienia przedstawiłem na rysunku 2 strukturę TOGAF ADM.

Rysunek 2. Struktura TOGAF ADM
Źródło: The Open Group

Na cykl ADM składa się:

  • etap przygotowywania organizacji do wdrożenia architektury korporacyjnej (faza wstępna);
  • etap planowania architektury (faza A), który kończy się przygotowaniem produktu architektonicznego “Wizja architektury”;
  • etap projektowania architektury (fazy B-D) , który kończy się przygotowaniem wstępnej wersji produktu architektonicznego “Dokument definiujący architekturę”;
  • etap planowania przejścia (fazy E-F), który kończy się produktem “Plan strategii i implementacji”;
  • etap nadzoru nad implementacją zaplanowanych projektów (faza G) – w ramach którego wykorzystuje się tzw. “kontrakt architektoniczny”.

Dodatkowo w ciągu całego cyklu niejako “w tle” działają fazy zarządzania zmianą (faza H) i zarządzania wymaganiami (w ramach której to fazy powstaje i jest aktualizowana “Specyfikacja wymagań architektonicznych”).

Sądzę, że sprint Scrum’owy można zastosować co najmniej na dwa różne sposoby w ramach cyklu TOGAF ADM. W niniejszym wpisie przedstawię pierwszy z tych sposobów. Przy czym w sposobie tym nie następuje, przedstawione  w moich wcześniejszych wpisach, przedefiniowanie ról występujących zarówno na poziomie Scrum’a i TOGAF ADM. Będzie miało ono zastosowanie w drugim obszarze adaptacji sprintu na potrzeby architektury korporacyjnej, który zostanie omówiony w kolejnym wpisie.

Tak więc, w pierwszym ze sposobów wykorzystania sprinta w TOGAF ADM cały czas będą funkcjonować „dwa światy”, tj.:

  • Na poziomie ról: zespół Scrum’owy, właściciel produktu oraz Scurm master (role występujące w Scrum’ie), a także główny architekt wraz z zespołem architektonicznym (role występujące w TOGAF ADM).
  • Na poziomie artefaktów/produktów architektonicznych: rejestr produktu, rejestr sprintu (artefakty występujące w Scrumie), a także dokument definiujący architekturę, specyfikacja wymagań architektonicznych, kontrakt architektoniczny (produkty architektoniczne występujące w TOGAF ADM).
    Warto podkreślić, że nawet na bardzo wysokim poziomie ogólności występują różnice terminologiczne między Scrumem a TOGAF ADM – tj. artefakt w Scrumie byłby traktowany w TOGAF ADM jako produkt architektoniczny (zgodnie z obowiązującą terminologią produkt architektoniczny w TOGAF ADM składa się z n-artefaktów cząstkowych, takich jak katalogi, macierze, diagramy oraz dodatkowych informacji); zaś produkt w Scrumie odpowiadałby rozwiązaniu dostarczanemu w ramach cyklu TOGAF ADM .

Sprint będzie korzystał z efektów pracy zespołu architektonicznego, a także będzie przekazywał do niego informacje zwrotne (np. w formie wniosków o z zmianę w architekturze, wniosków o odstępstwo).

W szczególności oznacza to, że część projektów, których definicje powstają w ramach fazy F (na bazie modeli architektonicznych), byłaby realizowana zgodnie ze  Scrum’em – a zespół architektów korporacyjnych będzie nadzorował w ramach fazy G (od strony architektonicznej) poszczególne sprinty Scrum’owe. Dotyczy to zwłaszcza projektów o niedużym zakresie, które powinny szybko dostarczyć korzyści do organizacji. Oczywiście pozostałe projekty byłyby realizowane (od strony zarządczej) przy pomocy klasycznych metod, takich jak Prince2 czy też PMI (por. rysunek 3, na którym np. projekty A i B mogłyby być realizowane zgodnie ze Scrum’em).

Rysunek 3. Nadzór nad projektami zaplanowanymi w fazie F cyklu TOGAF ADM
Źródło: Opracowanie własne

W praktyce oznacza to, że podczas planowania poszczególnych sprintów zespół wykonawczy dokonywałby prognozy zakresu funkcjonalności, które zostaną dostarczone w ich ramach na bazie tzw. rejestru produktu. Scrum definiuje rejestr produktu jako uporządkowaną listę wszystkich cech, funkcjonalności, wymagań, ulepszeń i korekt błędów, które odzwierciedlają zmiany wprowadzane do produktu w przyszłych jego wydaniach. Elementy rejestru produktu mają takie atrybuty jak: opis, kolejność i oszacowanie (estymację). Rejestr produktu jest często uporządkowany według wartości, ryzyka, priorytetów lub potrzeb.

Różnica w stosunku do klasycznego Scruma byłaby taka, że w Scrum4EA rejestr produktu bazowałby na materiałach architektonicznych – a w szczególności “Dokumencie definiującym architekturę” (Architecture Definition Document – jest to kluczowy z punktu widzenia TOGAF ADM produkt architektoniczny) oraz “Specyfikacji wymagań architektonicznych”.

W tym miejscu pojawia się zagadnienie, że zgodnie ze Scrum rejestr produktu nigdy nie jest kompletny, ewoluuje on wraz z produktem i środowiskiem, w którym produkt ten będzie używany. Jest więc to twór dynamiczny – ciągle się zmienia. Może pojawić się wątpliwość , że takie podejście jest niezgodne z ujęciem architektonicznym, w którym niejako wszystko jest określone na samym początku  – tj. podczas projektowania architektury. Zauważyć jednak warto, że architektura (jako zbiór modeli) oraz wymagania architektoniczne – zwłaszcza na poziomie architektury strategicznej i segmentów – nie schodzą na duży poziom szczegółowości – można powiedzieć, że są one korytem rzeki, a rejestr produktu pozwala na wypełnienie tego koryta szczegółową zawartością.

Jednocześnie istnieje możliwość wprowadzenia pętli sprzężenia zwrotnego, tj. jeżeli zmiany w ramach rejestru produktu przekraczają pierwotne ustalenia wynikłe z architektury/wymagań architektonicznych wówczas powinna istnieć ścieżka eskalacji takich kwestii (w ramach fazy G i H cyklu ADM) do zespołu architektów korporacyjnych.

Po wybraniu zakresu pracy, które zostaną zrealizowane w ramach danego sprintu zespół wykonawczy ustala, jak zamieni tę funkcjonalność w produkt lub przyrost produktu. Wybrane elementy rejestru produktu wraz z planem ich wykonania noszą nazwę rejestru sprintu (por. rysunek 1).  Zespół wykonawczy zwykle rozpoczyna pracę od stworzenia projektu produktu i planu prac niezbędnych do przetworzenia elementów rejestru produktu w działający produkt lub przyrost produktu. W tym miejscu można również wykorzystać dokumenty architektoniczne powstałe w ramach cyklu ADM – ułatwią one opracowanie projektu produktu, a w przypadku większych przedsięwzięć (w które zaangażowanych jest kilka zespołów scrumowych) pozwolą na zachowanie spójności tych prac. Jest to także miejsce na wykorzystanie kontraktów architektonicznych pochodzących z poziomu TOGAF ADM.

Każdy sprint zakończony jest przeglądem oraz retrospekcją.

Celem przeglądu jest przeprowadzenie inspekcji produktu lub jego przyrostu i dostosowanie, jeśli wystąpi taka konieczność rejestru produktu.  Podczas tego przeglądu zespół Scrum’owy i interesariusze produktu wspólnie dyskutują nad wykonanymi pracami oraz pracują nad tym, co może zostać wykonane w następnej kolejności (tj. w ramach kolejnego sprintu). Jest to etap prac, na którym mogą być również wykorzystywane produkty architektoniczne (zwracam uwagę na sygnalizowaną na początku wpisu różnicę między produktem w rozumieniu Scrum’a a produktem architektonicznym w rozumieniu TOGAF ADM) – dotyczy to w szczególności planowania zakresu prac dla kolejnego sprintu. Wskazane byłoby, aby w samym spotkaniu uczestniczył reprezentant zespołu ds. architektury korporacyjnej (jako interesariusz produktu Scrum’owego).

Inną funkcję pełni natomiast retrospekcja. Można ją porównać do spojrzenia na sprint od strony metodycznej – tj. jako inspekcja działań zespołu Scrum’owego oraz opracowanie planu usprawnień, które zostaną zrealizowane w najbliższym sprincie. W przypadku integracji Scrum’a z podejściem architektonicznym retrospekcja nabiera szczególnie istotnej roli – ponieważ  następuje połączenie dwóch różnych światów, dwóch różnych filozofii działania. Dlatego Scrum master powinien zachęcać zespół Scrum’owy do identyfikacji niedoskonałości występujących na styku tych „dwóch światów” i propozycji ich usprawnień.

Uwaga: W niniejszym wpisie wykorzystałem polskie tłumaczenie “The Scrum Guide” przygotowane w ramach inicjatywy PodDrzewem.pl.