Zespół architektoniczny a Scrum - czyli Scrum4EA (cz. III)

W kolejnym wpisie nt. zastosowania podejścia zwinnego do wytwarzania architektury korporacyjnej chciałbym odnieść się do  ostatniej z ról, jaką definiuje Scrum, a mianowicie Zespołu Wytwórczego (Deweloperskiego). Zgodnie ze ScrumGuide (odnoszę się do jego polskiej wersji, przygotowanej przez inicjatywę “PodDrzewem.pl”), jest to zespół złożony z profesjonalistów, których zadaniem jest dostarczenie, na zakończenie każdego Sprintu, gotowego do wydania Przyrostu produktu. Tylko te osoby są zaangażowane w wytwarzanie Przyrostu.

W przypadku prac nad architekturą korporacyjną mówimy o Zespole Architektonicznym, który ma dostarczyć w określonych momentach (np. w ramach cyklu TOGAF ADM na koniec każdej z faz) określone produkty architektoniczne (lub przyrosty już istniejących produktów).

Poniżej przedstawiona jest charakterystyka Zespołu Wytwórczego w kontekście Zespołu Architektonicznego:

• Zespół Wytwórczy jest samoorganizujący się. Nikt (nawet ScrumMaster) nie może mówić Zespołowi, jak należy przekształcać elementy Rejestru Produktu w Przyrosty gotowej do wydania funkcjonalności. Tutaj występuje pierwsza różnica z Zespołem Architektonicznym – bo w normalnej sytuacji kieruje nim Główny Architekt i to on jest głównym “Concept Makerem”.
• Zespół Wytwórczy jest wielofunkcyjny, w swoim składzie posiada wszystkie umiejętności niezbędne do wytworzenia Przyrostu. Tutaj występuje zgodność (przynajmniej teoretyczna) z Zespołem Architektonicznym.
• Scrum nie przewiduje tytułów innych niż „Wytwórca” dla członków Zespołu Wytwórczego. Reguła ta obowiązuje bez względu na charakter pracy wykonywanej przez daną osobę i nie ma od niej wyjątków. Tutaj mamy do czynienia z kolejną rozbieżnością w przypadku Zespołu Architektonicznego. Zazwyczaj składa się on bowiem z: Architekta Biznesowego,  Architekta Danych, Architekta Aplikacji, Architekta Infrastruktury Technicznej. Czasami spotyka się także: Architekta ds. Integracji oraz Architekta Bezpieczeństwa. Czyli występuje rozróżnienie ról.
• Mimo, iż pojedynczy członkowie Zespołu Wytwórczego  mogą posiadać wyspecjalizowane  umiejętności oraz mogą skupiać się na konkretnych dziedzinach, odpowiedzialność za wykonywaną pracę ponosi cały Zespół. Tutaj widzę spójność z podejściem architektonicznym – mówimy przecież o dostarczeniu  jednej, spójnej architektury przez Zespół.
• Zespół Wytwórczy nie składa się z podzespołów przeznaczonych do wykonywania  konkretnych rodzajów zadań. Tutaj też mogą występować różnice przy pracach Zespołu Architektonicznego, który wewnętrznie może się dzielić na zespoły robocze (jeden zajmie się aspektami biznesowymi, drugi np. kwestiami infrastruktury).
• Optymalna wielkość Zespołu Wytwórczego mieści się w granicach 3-9 osób. Tutaj jest najczęściej zgodność z Zespołem Architektonicznym, którego liczebność rzadko kiedy przekracza 9 osób (zawsze można wprowadzić skalowanie Scrum – ale o tym przy okazji innego wpisu).

Podsumowując: można dokonać mapowania koncepcyjnego Zespołu Architektonicznego na Zespół Wytwórczy w Scrum, i postawić pomiędzy nimi znak równości. Wymagać to będzie pewnego wysiłku po stronie Zespołu Architektonicznego i jego przeorganizowania (przynajmniej mentalnego). Przy czym ten wysiłek jest zgodny z koncepcją architektury korporacyjnej – bo zakładamy, że “od teraz” nie mówimy o czterech różnych domenach (i czterech różnych typach architektów), ale dążymy do  jednej, spójnej architektury, która ma zostać opisana/zaprojektowana przez po prostu architektów korporacyjnych.

Być może ciężko będzie się na początku przestawić na taki tok prac (bo przecież “od zawsze” był architekt od biznesu i architekci od IT), ale efekt końcowy powinien być zdecydowanie lepszej jakości niż przy klasycznym kształcie (i sposobie funkcjonowania) Zespołu Architektonicznego.