Zespół funkcjonalny kontra Zespół komponentowy

Zespoły funkcjonalne (ang. Feature Teams) są coraz popularniejsze w świecie Agile. Ale czy to oznacza, że powinniśmy zdecydowanie zarzucić rozwiązanie z zespołami komponentowymi ang. (Component Teams)? Nie jestem do końca przekonany…

Czym jest zespół komponentowy?

Zespół komponentowy, to „klasyczny” sposób organizacji zespołów. Tworzone są one wokół „komponentów”, którymi często są poszczególne warstwy systemu (baza danych, frontend, backend, aplikacja na komórki) lub moduły (logowanie, przetwarzanie danych o płatnościach, moduł raportów, moduł konfiguracji, itp.). Każdy Zespół komponentowy jest właścicielem swojej części i całkowicie za nię odpowiada.

Ma to kolosalne skutki. Możemy uzyskać pełną czystość kodu. Nikt nam nie będzie nam w nim grzebał. Mamy też pełną wiedzę, jak nasz komponent funkcjonuje w każdym tego aspekcie.

Ale konsekwencją tego niestety jest to, że jeżeli inny zespół będzie musiał zmienić cokolwiek w naszym komponencie, to będzie zmuszony przekazać nam do wykonania część swojego zadania. Ten fragment na ogół nie przyniesie wartości użytkownikowi końcowemu. Pomimo wykonanej przez nas pracy, użytkownik/klient w ogóle nie odniesie z niej korzyści, dopóki nie zakończy się praca pozostałych zespołów.

Jeśli zapiszemy wymagania w przy pomocy Historyjki Użytkownika (ang. User Story) będziemy widzieli, że nie realizujemy go na rzecz użytkownika końcowego, tylko dla innego zespołu.

Taki sposób tworzenia fragmentów rozwiązań jest mało zwinny. Znacznie gorzej ma się sprawa w dużych systemach. W nich praktycznie żadna funkcjonalność nie może być w pełni zrealizowana przez pojedynczy zespół komponentowy. Czego byśmy nie dotknęli, to pojedynczy „feature” (z punktu widzenia klienta) musi przejść przez wiele zespołów. To skutkuje duplikacją wymagań albo zwiększeniem liczby elementów Rejestru Produktu (ang. Product Backlog), które mają niewielką (albo nawet zerową) wartość dla klienta/użytkownika.

To nie jest tak, że nie da się zrealizować tym sposobem większych projektów, ale zarządzanie zależnościami w takiej sytuacji to spory kłopot.

Może więc Zespół funkcjonalny?

Zespół funkcjonalny, jak sama nazwa wskazuje, jest zbudowany wokół jakiejś funkcjonalności lub części systemu. Zespół taki powinien być interdyscyplinarny, to znaczy potrafić dostarczyć kompletne rozwiązanie. Niezależnie od liczby warstw i komponentów – Zaspół funkcjonalny powinien posiadać wszystkie kompetencje.

Gdy mówimy o interdyscyplinarności, to zawsze powtarzamy, że kompetencje te ma posiadać cały zespół, a nie poszczególni jego członkowie. W składzie nie potrzeba samych „omnibusów”. Wystarczy, że zespół będzie w stanie zrealizować całą funkcjonalność (w domyśle: użyteczną dla klienta) od początku, do końca.

Zespół funkcjonalny nie jest zespołem wysoko wyspecjalizowanym. Tworzymy uwzględniając aktualny poziom wiedzy i umiejętności jego członków. Zwykle będzie tak, że na początku do Rejestru Produktu trafią głównie dobrze znane wymagania dotykające obszarów systemu, na których ten zespół się zna. Ale prędzej czy później zespół funkcjonalny będzie musiał się nauczyć innych „komponentów”. Zbyt wysoka specjalizacja powoduje bowiem więcej problemów niż korzyści.

Problemy zespołów funkcjonalnych

Zespół funkcjonalny nie jest wolny od wad. Przede wszystkim, żeby zbudować prawdziwie interdyscyplinarny zespół często będziemy potrzebować więcej osób. A to z kolei może doprowadzić do tego, że zamiast zespołu będziemy mieć jedynie grupę ludzi o niezbędnych kompetencjach. Niektórzy znajdą się w nim tylko ze względu na swoje umiejętności, a nie wspólny cel.

Budowa zespołów funkcjonalnych bywa też trudna w systemie, gdzie liczba niezależnych i wyspecjalizowanych komponentów idzie w dziesiątki bądź setki. Wówczas albo szukamy „omnibusów”, albo budujemy ogromne zespoły, bądź stosujemy rozwiązania hybrydowe. Do takich należy zespół funkcjonalny stworzony w ramach pewnego „obszaru”, czyli zbioru komponentów.

Główne problemy dotykające zespoły obu rodzajów prezentuje powyższa grafika. Widzimy na nim „spaghetti” zależności, które pojawia się na styku Rejestru Produktu i poszczególnych zespołów komponentowych. Jednakże to samo spaghetti powstaje pomiędzy zespołami funkcjonalnymi a tworzonym kodem.

Jedne zespoły borykają się z podziałem funkcjonalności na kod znajdujący się w poszczególnych komponentach systemu. Drugie mają identyczny problem z utrzymaniem spójności codebase’u.

Zwolennicy zespołów funkcjonalnych twierdzą, że o wiele łatwiej zarządza się kodem niż zależnościami pomiędzy wymaganiami. W wielu przypadkach jest to prawda, szczególnie jeśli mamy dobre narzędzia do zarządzania kodem i dobrych pracowników z doświadczeniem.

Idealny zespół funkcjonalny

Podobnie jak wiele innych zwinnych rozwiązań, także i to sprawdza się idealnie… w teorii.

Jest to piękny pomysł na organizację pracy, mający niewątpliwie dużo zalet nad zespołami komponentowymi. W praktyce, nie jest łatwo zbudować idealny zespół funkcjonalny i bardzo często okazuje się, że najlepiej sprawdza się… zdrowy rozsądek.

Zespół komponentowy	Zespół funkcjonalny
Tradycyjny sposób budowania zespołów	Nowoczesny sposób budowania zespołów
Odpowiedzialny jedynie za część kliento-centrycznej funkcjonalności	Odpowiedzialny za całość kliento-centrycznej funkcjonalności
Skupia się na jednej specjalizacji	Skupia się na wielu specjalizacjach
Określone indywidualne obowiązki	Wspólne obowiązki zespołu
Koncentruje się na zwiększaniu indywidualnej produktywności	Koncentruje się na wydajności systemu
Zależności między zespołami powodują konieczność dodatkowego planowania	Zwiększa elastyczność poprzez zmniejszenie zależności między zespołami
Działa ze złymi praktykami inżynierskimi	Wymagane są specjalistyczne praktyki inżynierskie
Wspiera kaskadowy sposób pracy	Wspiera iteracyjny sposób pracy
Dostarcza maksymalną liczbę linii kodu	Dostarcza maksymalną wartość dla klienta
Łatwy do implementacji	Trudny do implementacji

Zorganizujmy się samodzielnie!

Samoorganizacja to jedno ze słów kluczy w Scrumie. Podobnie jest z interdyscyplinarnością.

Skoro mamy świadomość, że nasz zespół ma być zdolny do realizacji postawionych przed nim wymagań oraz samoorganizujący się, to może pozwólmy im zorganizować się samodzielnie? Dajmy im ograniczenia, takie jak wielkości zespołów czy listę kompetencji, które mają znaleźć się w poszczególnych teamach i zobaczmy co się wydarzy.

Podział najprawdopodobniej będzie zdroworozsądkowy i ukierunkowany na ułatwienie wszystkim zainteresowanym pracy. Twory takie jak zespół funkcjonalny i komponentowy to świetna heurystyka i wskazówka, która pozwoli nam podjąć decyzję o tym, jak pomóc naszym zespołom się samoorganizować. To narzędzie które pomoże nam z wyprzedzeniem zidentyfikować problemy, które mogą się pojawić. Wiemy, czy spodziewać się ich po stronie kodu czy zależności pomiędzy wymaganiami.

Silosy kontra eksperci, czyli pułapki interdyscyplinarności

Zarówno podejście z wąską specjalizacją, jak i absolutną uniwersalnością niosą ze sobą różne problemy. Jeżeli chcemy wiedzieć wszystko, to wiele czasu poświęcimy na doskonalenie się i przekazywaniu/zdobywaniu umiejętności. Niejednokrotnie możemy się przekonać, że z wielu z nich nawet nie zdołamy wypróbować.

Jeśli zajmujemy się tylko i wyłącznie określonym kawałkiem systemu, to żeby zrealizować niektóre funkcjonalności będziemy musieli łączyć siły z innymi zespołami. Spowoduje to uciążliwe zależności pomiędzy poszczególnymi zadaniami w rejestrze produktu i konieczność częstej synchronizacji.

Na pewno warto znać się na tym, z czego często korzystamy. Jednak w dzisiejszych czasach trudno znać się na wszystkim i być absolutnie uniwersalnym.

Jeżeli mamy zespoły odpowiadające za poszczególne komponenty systemu, to w przypadku funkcjonalności wykorzystującej wiele z nich, zaplanowanie jej do realizacji będzie koszmarem z uwagi na zależności. Z drugiej strony, jeśli nasze zespoły potrafią realizować kompletne funkcjonalności dotykające wszystkich zakamarków systemu, to przy realizacji kilkudziesięciu z nich w każdym Sprincie, uzgodnienie tych wszystkich zmian i ich połączenie będzie koszmarem.

Musimy więc odpowiedzieć sobie na pytanie: w którym miejscu wolimy mieć problemy? Jest to kwestia indywidualna, bo niektórzy lepiej sobie poradzą ze wspólnym planowaniem, a inni z jednoczesnym operowaniem na kodzie przez wiele osób.

Literatura:

„Feature Teams”, LeSS.works, 2020

„Feature Teams vs Component Teams”, knowledgehut.com, 2020

Dzierżek T., „Feature Team kontra Component Team”, Bialko.eu, 2019

Dzierżek T., „Kross-funkcjonalność – definicja i pułapki”, Bialko.eu, 2018

Pichler R., „Are Feature Teams Or Component Teams Right For Your Product?”, RomanPichler.com, 2020