Feature Team kontra Component Team 

Feature Team to konstrukcja, która cieszy się niesamowitą popularnością w dzisiejszym agile’owym światku. Ale czy to znaczy, że stary dobry Component Team powinien odejść do lamusa? Nie do końca…

Co to Component Team?

Component Team, to „klasyczny” sposób organizowania zespołów. Tworzymy je wokół „komponentów”, którymi mogą być poszczególne warstwy systemu (baza danych, frontend, backend, aplikacja na komórki) bądź moduły (renderowanie, przetwarzanie danych o płatnościach, moduł integracyjny, itd.). Każdy Component Team jest właścicielem swojego komponentu i odpowiada za niego w całości.

To niesie ze sobą poważne konsekwencje. Z jednej strony otrzymuje absolutną czystość kodu. Nikt nam nie grzebie w naszej części. Mamy też pełnię wiedzy na temat tego jak dany komponent dokładnie działa.

Niestety, jeśli inny zespół będzie musiał dokonać zmiany w naszej części systemu, to będzie musiał przekazać nam do realizacji część swojego wymagania. „Część”, czyli niestety coś, co nie przyniesie wartości użytkownikowi końcowemu. Pomimo tego, że zrealizujemy te wymaganie, nasz klient w ogóle na nim nie skorzysta zanim pozostałe zespoły nie wykonają swoich części.

W przypadku zapisania wymagania w notacji User Story będziemy widzieli, że nie realizujemy go na rzecz żadnego użytkownika końcowego, tylko na rzecz innego zespołu.

Takie tworzenie kawałków rozwiązań jest mało zwinne, ale to jeszcze nic strasznego. O wiele gorzej wygląda sprawa z dużymi systemami, gdzie praktycznie żadna funkcjonalność nie może być w pełni zrealizowana przez jeden Component Team. Czegokolwiek się nie dotkniemy, to jeden „feature” (z punktu widzenia klienta) musi przejść przez wiele zespołów. To powoduje duplikację wymagań albo mnogość elementów backlogu, które mają niską (albo nawet zerową) wartość.

I tu trafiamy na oczywisty problem pod tytułem „Jak tym wszystkim zarządzać?”. Jeżeli jedna funkcjonalność rozpisana zostaje na kilkanaście US-ów, które trafiają do kilku różnych zespołów, to jak biedny Product Owner ma odpowiedzieć na pytanie „Kiedy zostanie zrealizowana funkcjonalność X?”

Nie mówimy, że nie da się tego zrobić, ale zarządzanie zależnościami na dużym projekcie korzystającym z Component Teamów to prawdziwa udręka. Wiemy, bo to przeżyliśmy.

To może Feature Team?

Skoro już padło słowo „feature”, to przejdźmy do drugiego bohatera dzisiejszego tekstu, czyli do Feature Teamu. Jak sama nazwa wskazuje, jest to zespół zbudowany wokół jakiejś funkcjonalności lub części systemu. W ramach niej, zespół jest całkowicie kross-funkcjonalny, to znaczy potrafi dostarczyć kompletne rozwiązanie. Niezależnie od liczby warstw i komponentów – Feature Team posiada kompetencje do wszystkich.

Gdy mówimy o kross-funkcjonalności, to zawsze powtarzamy, że wspomniane kompetencje ma posiadać cały zespół, a nie poszczególni jego członkowie. W składzie nie musimy mieć 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.

„Within a feature team organization, when specialization becomes a constraint…learning happens.” – LeSS

Metodyka LeSS otwarcie mówi o tym, że Feature Team nie jest zespołem wysoko wyspecjalizowanym. Owszem, zespół tworzymy uwzględniając aktualny poziom wiedzy i umiejętności. I pewnie będzie tak, że na początku do backlogu trafią głównie dobrze znane wymagania dotykające obszarów systemu, na których ten zespół się zna. Ale prędzej czy później Feature Team będzie musiał się nauczyć innych „komponentów”.

„(…) when requirements do not map to the skills of the teams, learning is ‘forced,’ breaking the overspecialization constraint. Feature teams balance specialization and flexibility.” – LeSS

Teza postawiona przez autorów LeSS brzmi: zbyt wysoka specjalizacja powoduje więcej problemów niż korzyści.

Kłopoty Feature Teamów

Feature Team nie jest pozbawiony wad. Przede wszystkim, żeby zbudować prawdziwie kross-funkcjonalny zespół często będziemy potrzebować więcej osób. A to z kolei może doprowadzić do tego, że zamiast prawdziwego zespołu będziemy mieć po prostu zbieraninę potrzebnych nam ludzi. Niektórzy znajdą się w nim tylko ze względu na kompetencje, a nie na cel.

Budowa Feature Teamu jest też trudna w systemie, w którym liczba niezależnych i wyspecjalizowanych komponentów idzie w dziesiątki bądź setki. Wtedy albo szukamy „omnibusów”, albo budujemy wielkie zespoły, albo stawiamy na rozwiązania hybrydowe. Do takich należy Feature Team stworzony w ramach pewnego „obszaru”, czyli zbioru komponentów.

Główne problemy dotykające Component Teamy i Feature Teamy idealnie prezentuje diagram z metodyki LeSS. Widzimy na nim wspomniane już „spaghetti” zależności, które pojawia się na styku backlogu i poszczególnych Component Teamów. Ale to samo spaghetti dotyka Feature Teamy i kod.

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. I tego nie przeskoczymy, gdzieś się te zależności należy rozwiązać.

Zwolennicy Feature Teamów mówią, ż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.

Ale nie zawsze trafiamy do takiego miejsca…

Idealny Feature Team

Podobnie jak wiele innych agile’owych pomysłów, także i ten sprawdza się idealnie… na papierze. Przypomnijmy tutaj nasz ulubiony Scrum, o którym sami autorzy mówią, że sprawdza się tylko dla jednego, ewentualnie dwóch zespołów.

„However, if more than one Scrum Team is working off the same Product Backlog and in the same codebase for a product, difficulties often arise. (…) These challenges appear when two Scrum Teams are integrating their work into a single increment, and become significantly more difficult when three or more Scrum Teams integrate their work into a single increment.” – Nexus Guide

Pięknie! Metodyka, o której od lat piszemy, mówimy i nauczamy wcale nie jest odpowiednia dla 80+% projektów, w których jest wykorzystywana. Bo jak często mamy do czynienia z li tylko jednym Zespołem Scrumowym? Większość przedsięwzięć to dziesiątki lub nawet setki osób pracujących nad danym rozwiązaniem. To zdecydowanie brzmi jak więcej niż jeden zespół…

I to też jest jeden z głównych powodów dla których wszędzie widzimy ScrumButy i ScrumAndy. To dlatego tak popularne są nasze szkolenia omawiające Skalowanie Scrum. Wyidealizowane, teoretyczne konstrukcje nie wytrzymują zderzenia z rzeczywistością i muszą zostać dostosowane do panujących warunków.

Nie znaczy to, że teoria jest do końca zła. Po prostu nie uwzględnia wszystkich zmiennych i czynników. Dlatego też tak ważne jest doświadczenie osób wdrażających wybrane przez nas podejście (zwinne lub inne). I tak samo wygląda sytuacja z Feature Teamami.

W teorii jest to piękny pomysł na organizację pracy, mający niewątpliwie dużo zalet nad Component Teamami. W praktyce, trudno jest zbudować idealny Feature Team i bardzo często okazuje się, że najlepiej sprawdza się… zdrowy rozsądek.

Samozorganizujmy się!

Samoorganizacja to jedno ze słów, na które uczulamy uczestników naszych szkoleń Scrum i Agile. Lojalnie ostrzegamy, że w trakcie naszych spotkań używamy go tyle razy, że powoli wszyscy mają go już dość. Podobnie sytuacja wygląda ze wspomnianą już kross-funkcjonalnością. Ale jednak te dwa aspekty budowania zespołów to podstawa, bez której nie damy rady ruszyć dalej.

Skoro wiemy, że nasz zespół ma być zdolny do realizacji postawionych przed nim wymagań oraz „samoorganizujący się”, to może pozwólmy im podzielić się samemu? 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ę stanie.

Gwarantuję, że nikomu w takim przypadku nie przyjdzie do głowy, żeby dzielić się „feature’ami” czy „componentami”. Podział będzie zdroworozsądkowy i ukierunkowany na ułatwienie wszystkim zainteresowanym pracy. Wielokrotnie wspominaliśmy o koncepcie Skin In The Game, który i w tym przypadku mówi jasno: osoby, których dotykają konsekwencje podejmowanych przez nich decyzji, wybierają lepiej niż „niezależni eksperci”.

Twory takie jak Feature Team i Component Team to świetna heurystyka i wskazówka, która pozwoli nam podjąć decyzję o tym, jak pomóc naszym zespołom się samozorganizować. 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.

Jeżeli wolisz posłuchać, jak w pięć minut omawiamy tematykę Feature Teamów i Component Teamów, zapraszamy do subskrypcji naszego kanału na YouTube.