sie
20

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

Źródło: Andrzej Sobczak
Print Friendly

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”. Więcej na ten temat można przeczytać tutaj.
  • 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.

Andrzej Sobczak

Profesor, kierownik Zakładu Zarządzania Informatyką w Instytucie Informatyki i Gospodarki Cyfrowej SGH. Ma ponad 8 letnie doświadczenie we wdrażaniu koncepcji architektury IT i architektury korporacyjnej. Posiada certyfikaty TOGAF 8/9, ArchiMate 2.0, ITIL, MSP.

Polecane wpisy

TAGI DLA WPISU

Dyskusja do artykułu “Zespół architektoniczny a Scrum – czyli Scrum4EA (cz. III)

  1. Mapowanie to nie jest do końca poprawne. Ponieważ w oparciu o poprzednie artykuły z cyklu “scrum4ea” w zespole architektonicznym Scrum Masterem jest Główny Architekt (co uważam za pomieszanie z poplątaniem). W takim zespole jak “Zespół Architetkoniczny” Product Ownerem powinien być Główny Architekt, który w sposób subtelny wiąże cele biznesowe z celami technicznymi. Taki PO zna się na rzeczy na poziomie high level i może wymagać od zespołu developerskiego pewnych działań, wymagających standaryzacji oraz uspójnienia architektury platformy w całej korporacji. Rola Scrum Mastera to tylko trzymanie pewnych ram stawianych przez Scrum Guida, a także usuwanie pojawiających się blokad, których zespół samodzielnie nie może zlikwidować. Zgodnie z Guidem nie można mieszać ról PO i SM.

Dodaj komentarz

W celu wzięcia udziału w dyskusji jako zalogowany użytkownik możesz zalogować się poprzez jeden z poniższych serwisów.

Twój adres e-mail nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Captcha Captcha Reload

Możesz użyć następujących tagów oraz atrybutów HTML-a: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>