Pracując nad bardziej złożonym produktem mamy do wyboru kilka różnych modeli organizacji zespołów wchodzących w jego skład i tym samym naszej pracy. Przyjrzyjmy się dwóm najbardziej popularnym podejściom i zastanówmy, kiedy, jaki układ sprawdza się lepiej.
Component Teams
W tym, bardziej tradycyjnym podejściu każdy zespół odpowiada za rozwój i utrzymanie swojego komponentu. W zależności od układu, komponent może mieć różną formę, jak na przykład: warstwa aplikacji, moduł, API, baza danych, itd. Pojedynczy element backlogu produktu wymaga najczęściej zmian w kilku komponentach, tym samym wspólnego planowania i koordynacji pracy pomiędzy zespołami.
Features Teams
W tym podejściu pojedynczy zespół jest w stanie zrealizować zadanie przekrojowo. Wymaga to jednak wiedzy i umiejętności pozwalającej wprowadzać zmiany we wszystkich, lub przynajmniej w większości składowych produktu.
Co mówi Scrum Guide?
"If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner."
Scrum Guide nie mówi więc żeby podzielić się komponentami, porobić 'component-backlogi' i koordynować w ten sposób prace nad większym produktem. Scrum, jak i inne metodyki zwinne, sugerują jednoznacznie, aby pozostać przy jednym backlogu produktu, jednym właścicielu produktu oraz aby zorganizować zespoły wokół funkcjonalności zorientowanych na użytkownika. Zarówno w mniejszym jak i większym produkcie, pojedynczy Scrum Team powinien być w stanie zaimplementować dowolny element backlogu produktu.
Gdy goni nas czas
Component Teams
Zastanówmy się jak najczęściej wygląda synchronizacja pracy w obrębie takich zespołów.
Powyżej widzimy cztery przykładowe sprinty zespołów próbujących wspólnie dostarczyć trzy funkcjonalności.
Jak na dłoni widać powstające opóźnienia. 'X' w sprincie drugim oznacza, iż Component Team A nie mógł podjąć wcześniej zaplanowanych prac, a na przykład musiał zająć się incydentem na produkcji (życie).
Dodajmy do tego fakt, iż zespoły muszą na końcu przetestować połączone rozwiązania oraz iż podczas testów wychodzą rzeczy do poprawy. I tak może się okazać, iż Component Team C musi wrócić do F3 i wprowadzić zmiany, pomimo iż prace nad nim ukończył dwa sprinty temu.
Features Teams
Cechą charakterystyczną takich zespołów jest możliwość skupienia na danej funkcjonalności i jej ukończenia bez potrzeby oczekiwania na innych. Taki układ sprawdza się więc najlepiej, gdy zależy nam na jak najszybszym dostarczeniu nowego produktu na rynek lub gdy w istniejącym produkcie chcemy wprowadzić wiele zmian w krótkim czasie.
Warto przez chwile zastanowić się czego, w porównaniu z podejściem Components Teams, unikamy:
- Między zespołowego procesu omawiania i rozbijania danej funkcjonalności (krótsze spotkania)
- Między zespołowego procesu planowania (krótsze spotkania)
- Przekazywania niedokończonych części rozwiązania między zespołami
- Koordynacji testów między zespołami
- Okresów oczekiwania na inny zespół, aby wspólnie coś omówić, zmienić lub przetestować
W tym podejściu eliminacja zbędnych zależności między zespołami, sprzyja szybkiemu dostarczaniu wartości dla końcowego użytkownika, skracając czasy wytwarzania (Cycle Time).
Gdy zależy nam na jakości
Przechodząc do bardziej kontrowersyjnego punktu, a mianowicie jakości rozwiązania. Szeroko rozumianej jako stabilność i niezawodność systemu, czytelność kodu, łatwość wdrażania zmian oraz oczekiwana wydajność.
Component Teams
Na pierwszy rzut oka intuicja podpowiada nam, iż w podejściu, w którym mamy dedykowany zespół odpowiedzialny za dany komponent ta, powyżej zdefiniowana, jakość, będzie na wyższym poziomie. Nie można oczywiście uogólniać, jednak często spotykaną sytuacją jest pewnego rodzaju "byle jakość". A mianowicie, z zewnątrz wydaje się, iż wszystko jest pod kontrolą, komponent spełnia być może choćby oczekiwane wskaźniki pod względem niezawodności i dostępności, zmiany są implementowane w miarę przyzwoitym czasie. Jednak, gdy spojrzy się głębiej zobaczymy wiele długu technicznego, wiele obejść problemów zamiast ich faktycznego rozwiązania u podstaw. Bardzo często komponenty utrzymywane przez dedykowany zespół posiadają nietypowe cechy czy przypadłości, a wdrożenie nowej osoby trwa długo. Jest to oczywiście na rękę osobom pracującym przy nich, bo w końcu to oni "wiedzą o co chodzi" i bez ich "specjalistycznej" wiedzy dany komponent by po prostu przestał działać.
Features Teams
Gdy wymagamy od zespołów, aby były w stanie wprowadzać zmiany przekrojowo w obrębie produktu, jego komponenty, siłą rzeczy, muszą być czytelne i posiadać, na ile to możliwe, spójną architekturę. Zespoły developerskie są więc niejako zobligowane wobec siebie do zachowania maksymalnego porządku i dyscypliny, inaczej nie były by w stanie efektywnie pracować.
Gdy budujemy produkt od zera mamy czyste pole i stosunkowo łatwo zacząć od prostych ustaleń, takich jak: jednolite standardy dokumentacji, modelowania oprogramowania, nazewnictwa czy wytycznych co do architektury. Wraz ze wzrostem złożoności produktu możemy je stopniowo rozbudowywać i ulepszać. W ten sposób każdy zespół obojętnie do jakiej części produktu by nie zajrzał napotka na znajome elementy, koncepcje i konwencje, a to umożliwia stosunkowo łatwe wprowadzanie w nich zmian.
Natomiast, jeżeli nie zadbamy o możliwie jak największą spójność w obrębie komponentów, należy jasno powiedzieć, iż możemy skończyć z problemami o wiele gorszymi niż poruszane powyżej dla Component Teams. jeżeli programiści nie będą w stanie gwałtownie zrozumieć zastanego kodu skończymy z pokładami duplikatów w obrębie komponentu. jeżeli nie będą świadomi aktualnych wytycznych co do doświadczeń użytkownika w obrębie komponentu Front-end, możemy skończyć z niejednolitym zachowaniem aplikacji, itd.
Sytuacja wygląda jeszcze trudniej, gdy chcielibyśmy przejść z modelu Component Teams na Feature Teams, a każdy komponent do tej pory oparty był na innych standardach i posiada, na przykład inny stack technologiczny. Czeka nas w tym przypadku ogrom pracy związanej z refaktoryzacją i wypracowywaniem wspólnych praktyk i konwencji utrzymując jednocześnie aktualne rozwiązanie. W takiej sytuacji warto zapoznać się z Team Topologies, które proponują szereg rozwiązań wspomagających.
Gdy zależy nam na ludziach
Inną perspektywą, którą możemy przyjąć porównując Component Teams z Feature Teams jest aspekt ludzki.
Component Teams
Tutaj z reguły panuje zasada "wolnoć Tomku w swoim domku". Co znaczy, iż zespół developerski ma mniejszą bądź większą swobodę kształtowania technicznych rozwiązań w obrębie swojego komponentu. Ma to tę zaletę, iż programiści nie są bardzo ograniczani przez nadrzędne wytyczne co do metod pracy, stosowanych konwencji, architektury itd. Mogą pozwolić sobie na eksperymentowanie w obrębie swojego komponentu. Czują się za niego odpowiedzialni.
Z drugiej strony są zamknięci w swojej zespołowo-komponentowej bańce. Możliwość nauki od innych sprowadza się do kilku kolegów lub koleżanek z zespołu.
Features Teams
W tym podejściu developerzy zyskują możliwość nauki w obrębie większej ilości komponentów. Tyczy się to zarówno aspektu technicznego jak i biznesowego. Mają styczność z kodem wielu programistów, a wszyscy wiemy, iż programiści uczą się najlepiej przez czytanie kodu innych. Mają możliwość pracy z logiką biznesową w obrębie całego produktu, co powinno przełożyć się na głębsze zrozumienie domeny, trafniejsze pomysły i mniejszą ilość błędów.
To co jednak dobrze brzmi na papierze w rzeczywistości może napotkać na pewne trudności. Nałożone ograniczenia techniczne mogą prowadzić, w dłuższej perspektywie, do frustracji developerów. A konieczność znajomości logiki biznesowej w obrębie wszystkich komponentów może zwiększać poziom niepokoju czy stresu. Wszak możliwości poznawcze ludzi mają pewne limity.
Gdy trzeba wybrać
W przypadku budowania nowego produktu wybór wydaje się oczywisty. Podejście Feature Teams zapewni większe skupienie na końcowym użytkowniku i szybszą pętlę zwrotną. jeżeli nie zaniedbamy kwestii jednolitych standardów to w sposób naturalny powinniśmy również otrzymać produkt o lepszej jakości.
Dla istniejących produktów opartych o Component Teams decyzja jest dużo trudniejsza. Powiedziałbym, iż jeżeli produkt jest już w fazie utrzymania bez większych planów rozwojowych chyba lepiej zainwestować energię i środki w poprawę sposobu pracy istniejących zespołów aniżeli robić kosztowną rewolucję. Można oczywiście też eksperymentować z podejściami hybrydowymi.
Gdyby ktoś chciał bardziej zgłębić temat polecam lekturę: Scaling Lean & Agile
Development (autorzy Craig Larman i Bas Vodde).
