PR Review pomiędzy zespołami
Wspólnie z Krzysztofem Witczakiem stworzyliśmy serię artykułów, w których zastanawiamy się skąd tak duża popularność Pull Request Review, oraz jakie problemy Pull Request Review tworzy w naszych zespołach. Następnie podjęliśmy temat rozwiązywania kwestii PR Review i mierzenia, czy jest lepiej.
W serii PR Review:
PR Review pomiędzy zespołami [TEN ARTYKUŁ]
Jeśli czytałeś/aś poprzednie artykuły z serii, to wiesz, że nie darzę PR Review miłością.
Do samego artykułu pojawiły się jednak komentarze:
To, co opisałeś w artykułach działa u mnie – ale tylko jeśli chodzi o mój zespół. Pomiędzy zespołami mam stare i nieefektywne PR Review. Co robić, jak żyć?
Aby zaadresować tę i podobne kwestie, w dzisiejszym wydaniu przejdziemy przez problemy / powody / rozwiązania problemów dookoła PR Review.
Przykładowa aplikacja
Aby zilustrować temat posłużymy się praktycznym przykładem. Załóżmy, że robimy modularny monolit na frontendzie. Mamy wspólne repo, ale i kilka aplikacji, które korzystają z wspólnego codebase.
Część zmian zamyka się w folderach modułowych pojedynczych zespołów. Wtedy nie ma oczywiście żadnego problemu. Kłopoty rodzą się, kiedy musimy zmienić kod innego zespołu bądź współdzielony np.:
Zmieniamy design systemu znajdujący się współdzielonych plikach.
Chcemy zmodyfikować fasadę, którą wystawił dla nas zespół zewnętrzny.
Aplikujemy zmiany na biblioteki wspomagające np. analityka, zarządzanie networkingiem.
Wtedy możemy napotkać następujące problemy:
Problemy
Przyjrzyjmy się głównym zagwozdkom:
Wysoki time-to-first resposne
Pierwsze reakcje na PR-y pojawiają się z dużym opóźnieniem. Deweloperzy muszą wielokrotnie przypominać o oczekującym review, nawet po kilku dniach od zgłoszenia.
Zaburza to płynność pracy i rytm dostarczania. Zamiast skupiać się na dostarczaniu, zespoły tracą czas na śledzenie statusu PR-ów i wysyłanie przypomnień.
Taka sytuacja nie tylko opóźnia dostarczanie funkcji, ale też znacząco podwyższa poziom frustracji w zespołach.
Sprawdzane po łebkach
Review odbywa się bez pełnego zrozumienia kontekstu zmian. Recenzenci, nie znając dokładnie celu i założeń modyfikacji, skupiają się na łatwo zauważalnych aspektach, takich jak nazewnictwo czy struktura kodu.
W rezultacie głębsze problemy architektoniczne czy logiczne umykają uwadze, ujawniając się dopiero na etapie testów lub, co gorsza, na produkcji. Takie podejście prowadzi bezpośrednio do problemów jakościowych i technicznych długów.
Rework i waste
Istotne uwagi do kodu pojawiają się dopiero po przejściu wewnętrznego, zespołowego review. To prowadzi do wielokrotnego powtarzania cyklu "zmiana kodu -> wewnętrzne review -> zewnętrzne review".
Każda iteracja tego procesu istotnie wydłuża czas dostarczenia funkcjonalności.
Utrata zaufania
Powtarzające się opóźnienia związane z między zespołowym PR review prowadzą do zmniejszenia zaufania. Zespoły zaczynają postrzegać siebie nawzajem jako przeszkody, a nie współpracowników dążących do wspólnego celu.
To oczywiście prowadzi do nawarstwiania się kolejnych problemów w komunikacji i współpracy, tworząc błędne koło nieefektywności.
---
W poprzednim newsletterze o PR Review opisywałem podobne problemy, ale w kontekście wewnątrz zespołowym. Jak widać, w przypadku review między zespołami, problemy te zostają jeszcze bardziej spotęgowane.
Diagnoza
Zanim zaczniemy wprowadzać zmiany, warto poświęcić czas by dokładnie przeanalizować sytuację w naszej organizacji. To nie jest praca, którą da się wykonać siedząc samotnie z kartką papieru. Musimy zebrać twarde dane i pogłębione informacje od deweloperów.
Oto kluczowe obszary, na które warto zwrócić uwagę:
Zbieranie danych: Ile faktycznie mamy PR-ów cross-zespołowych? Jak wyglądają czasy ich przetwarzania w porównaniu do PR-ów wewnątrz zespołowych?
Rozmowy z zespołami: Na co dokładnie wskazują jako problem? Co im najbardziej przeszkadza w procesie?
Analiza wąskich gardeł: Czy jest zespół, od którego zależy wiele innych i jest przez to przeciążony?
Porównanie z procesami wewnętrznymi: Czy PR-ki wewnątrz zespołowe są przetwarzane znacznie szybciej?
Dokładna analiza może ujawnić zaskakujące fakty.
Może się okazać, że problem dotyczy tylko jednego przeciążonego zespołu, od którego zależy wiele innych.
Albo że PR-ki wewnątrz zespołowe są przetwarzane równie wolno, co sugerowałoby szerszy problem z kulturą code review w organizacji.
Możliwe, że problem wcale nie leży w Pull Request Review 😃
Jednak zakładając, że problem jednak nadal występuje, warto pójść krok dalej.
Powody
Po zdiagnozowaniu sytuacji w naszym modularnym frontendzie, warto zastanowić się nad przyczynami problemów. Zwykle powodów trzeba szukać niżej.
Oto wyjaśnienia, które najczęściej stoją za nieefektywnymi procesami PR review między zespołami w naszej organizacji:
Rozbieżne standardy i praktyki
Brakuje jasno określonych zasad dotyczących PR review między zespołami pracującymi nad różnymi modułami. Nie ustalono:
Do kogo konkretnie kierować prośby o review
Ile czasu powinno trwać sprawdzenie kodu
Jak wcześnie powiadamiać o nadchodzących dużych zmianach
Ta niejasność prowadzi do nieporozumień i opóźnień. Zespoły odpowiedzialne za poszczególne moduły mają różne oczekiwania co do procesu.
Brak analizy wpływu
Zespoły nie analizują, czy ich zmiany wpłyną na kod innych modułów. W rezultacie zauważają to zbyt późno w procesie. Aktualizacje są wrzucane na szybko, bez odpowiedniego przygotowania, a inne teamy są zaskakiwane nieprzewidzianymi modyfikacjami.
To prowadzi do chaosu i konieczności wprowadzania poprawek “na kolanie”.
Słaba wymiana informacji pomiędzy zespołami
Każdy zespół skupia się na swoim module, nie znając realiów pracy nad innymi częściami frontendu, czyli zakresu obowiązków, roadmapy i celów innych zespołów. Typowy przykład pracy w silosach.
To powoduje, że recenzenci nie rozumieją w pełni celu i kontekstu zmian. Trudniej jest ocenić potencjalny wpływ modyfikacji na cały system.
Wysoki stopień organizacyjnego Work-In-Progress
Problem ten jest powiązany z kulturą single ownership, o której wspominałem w poprzednim newsletterze. Zespoły mają:
Dużo pracy nad własnymi modułami
Napięte deadliny zespołowe
Brak czasu na zajmowanie się PR-ami dotyczącymi innych części frontendu
W rezultacie, review między zespołowe traktowane jest jako dodatkowe obciążenie, a nie integralna część pracy.
Shadow IT – niewidoczne procesy
Praca nad review i łączna liczba przepracowanych godzin nie są widoczne dla organizacji. Zadania krążą na najniższym poziomie, zwiększając obłożenie. Jednocześnie z poziomu dowożenia nie widać całego progresu.
To sprawia, że problem jest de facto ukrywany przed liderami organizacji. Niektóre zespoły mogą być nieproporcjonalnie obciążone requestami o review, ale trudno jest ocenić rzeczywisty wpływ tego procesu na produktywność zespołów.
Brak widoczności tego aspektu pracy utrudnia podjęcie odpowiednich działań naprawczych.
---
Zrozumienie wyżej wymienionych powodów jest kluczowe – nie chcemy adresować samych problemów, a raczej skupić się na Root Causes.
W kolejnej części omówimy, jak można bezpośrednio zaadresować tę sytuację – skupimy się na 3 grupach rozwiązań:
Rozwiązania na poprawę współpracy
Standardy wystawiania PR Review
Jednym z kluczowych kroków w usprawnianiu procesu jest wyznaczenie jasnych standardów współpracy. W naszym modularnym frontendzie brakuje często podstawowych informacji, które mogłyby znacząco usprawnić proces review. Oto co warto uwzględnić:
Informacje o Contributing w repozytorium: Aktualnie brakuje jasnych wytycznych dla kontrybutorów. Dodajmy plik CONTRIBUTING.md, który będzie zawierał podstawowe zasady pracy z kodem w naszym projekcie.
Struktury i atrybuty jakościowe: Określmy, na jakich aspektach kodu najbardziej nam zależy. Czy to modularność, wydajność, czy może łatwość testowania? Jasno komunikując te priorytety, ułatwimy recenzentom skupienie się na kluczowych aspektach.
Uzasadnienie istotności zmian: Wymagajmy od autorów PR-ów krótkiego wyjaśnienia, dlaczego dana zmiana jest istotna z perspektywy zespołu. Zalinkujmy do dokumentu, przeklejmy część historyjki.
Lista osób do powiadomienia: Ustalmy, kogo należy poinformować o zmianach w poszczególnych modułach. Może to być lista code owners lub ekspertów w danych obszarach.
Wymagane testy: Jasno określmy, jakie testy powinny być uruchomione przed zgłoszeniem PR-a do review. Może to obejmować testy jednostkowe, integracyjne czy testy wydajności.
Wprowadzenie tych standardów i zawarcie ich w dokumentacji projektu znacząco ułatwi proces review:
Recenzenci będą wiedzieli, na co zwracać uwagę, a autorzy PR-ów będą lepiej przygotowani do prezentowania swoich zmian.
To z kolei przyspieszy cały proces i poprawi jakość dostarczanego kodu.
W poprzednim newsletterze o dokumentacji pisałem o znaczeniu dobrej dokumentacji dla zespołu. Te same zasady stosują się do dokumentacji procesu PR review - im lepsza dokumentacja, tym sprawniejsza współpraca między zespołami.
Standardy obsługi PR Review
Jednym z kluczowych aspektów usprawnienia procesu PR review między zespołami jest ustalenie jasnych standardów obsługi.
Cytując Google z książki Software Engineering:
Feedback within 24 working hours refers to the expectation at Google that reviewers provide feedback on code reviews within a 24-hour timeframe. This does not necessarily mean the review is completed within a day, but that initial feedback is given within this time frame.
It’s considered good practice to acknowledge receipt of the change if unable to complete the review within 24 hours, and let the author know it will be completed as soon as possible.
Więc co można zrobić lepiej?
Feedback w ustalonym czasie: Ustalmy zasadę, że recenzenci powinni dostarczyć wstępną odpowiedź na PR w ciągu X. Nie chodzi o to, że pełne review musi być zakończone w tym czasie. Chodzi o wstępną informację zwrotną, która pozwoli autorowi PR-a zorientować się w sytuacji.
Jasna komunikacja statusu: Zachęćmy recenzentów do jasnego komunikowania statusu review: "Rozpocząłem review, spodziewaj się komentarzy do końca dnia." / "Z powodu innych priorytetów, będę mógł zająć się tym PR-em dopiero w przyszłym tygodniu."
Narzędzia wspomagające: Rozważmy wykorzystanie narzędzi, które pomogą w zarządzaniu procesem. Np. Axolo, które tworzy dedykowany kanał na PR Review i informuje o zbliżającym się deadline.
Dashboardy pokazujące status PR-ów i czas oczekiwania na review.
Wprowadzenie tych standardów pomoże w lepszym zarządzaniu oczekiwaniami zarówno autorów PR-ów, jak i recenzentów.
Rozwiązania na usprawnienie procesów międzyzespołowych
Aby usprawnić proces PR review między zespołami, kluczowe jest zwiększenie efektywności procesów z jakimi pracują zespoły. Oto kilka rozwiązań, które mogą w tym pomóc:
Analiza wpływu na inne zespoły
Przed zgłoszeniem PR-a, zespoły powinny przeprowadzić analizę wpływu zmian na moduły zewnętrzne. To obejmuje:
Identyfikację repozytoriów/folderów innych zespołów, na które wpływają zmiany
Analizę współdzielonych komponentów, które mogą być dotknięte
Wcześniejsze informowanie o nadchodzących dużych zmianach
Taka analiza pozwoli uniknąć niespodzianek i ułatwi planowanie review przez inne zespoły.
Ujawnienie Shadow IT w procesie review
Aby zwiększyć widoczność pracy nad PR review:
Ujawnienie ukrytej pracy: Raportujmy czas poświęcony na review między zespołami. Podsumowaniami dzielmy się na synchronizacjach liderów.
Dedykowany czas na review: Dedykujmy część czasu zespołu/liderów na tę aktywność. Wyznaczmy w każdym sprincie określoną ilość czasu na review między zespołami. To może być np. 10-20% czasu zespołu. Eskalujmy, gdy ten czas zostanie przekroczony.
Zmniejszenie międzyzespołowego WiP
Ograniczenie równoległej pracy: Ograniczmy liczbę jednocześnie prowadzonych tematów między zespołowych, przy zwiększeniu skupienia na pracy w toku. Regularnie przeglądajmy i dostosowujmy te limity w zależności od aktualnych potrzeb i możliwości zespołów.
Dostosowywanie limitów: W przypadku wzmożonej pracy na obszarach jednego zespołu celowo ograniczajmy dodatkowe zadania.
Cykliczne przeglądy backlogu PR-ów: Regularnie analizujmy zaległe PR-y szukając źródła opóźnień. Sprawdzajmy, czy nie są one spowodowane przez nawał pracy między zespołami.
Wprowadzenie tych praktyk pomoże ujawnić rzeczywisty nakład pracy związany z PR review między zespołami i umożliwi lepsze zarządzanie tym procesem.
Rozwiązania na redukcję liczby review
Choć review między zespołami jest ważne, można zastosować strategie, które zmniejszą ich liczbę bez utraty jakości. Oto kilka propozycji:
Sub Context
Jednym z najbardziej efektywnych podejść jest stworzenie "sub kontekstów" w ramach większych modułów:
Jak się do tego zabrać?
Wydzielamy w repozytorium lub folderze innego zespołu miejsce dedykowane dla naszego zespołu.
Ustalamy jasne granice i kontrakty dla tego sub kontekstu.
Zespół "właściciel" określa ogólne reguły, ale nie musi review'ować każdej zmiany.
To podejście przypomina koncepcję opisaną przez Nicka Tune'a w artykule o Mapper Contexts i Supercontexts. Dzięki temu możemy znacznie zmniejszyć liczbę review między zespołami, jednocześnie zachowując kontrolę nad ogólną strukturą.
Ograniczenie zakresu
Nie wszystkie zmiany wymagają pełnego review przez inny zespół. Możemy przykładowo:
Określić kluczowe obszary kodu wymagające review przez właściciela.
Automatycznie przypisywać recenzentów tylko do zmian w tych obszarach.
Wykorzystać narzędzia takie jak GitStream do automatyzacji tego procesu.
To podejście nawiązuje do koncepcji, którą opisywałem w artykule o określaniu ważności systemów i obszarów. Skupiamy się na review tego, co naprawdę istotne.
Lider zewnętrzny
Zamiast angażować w review cały zespół, możemy wyznaczyć jednego lidera:
Określmy jasno, co chcemy sprawdzać w kodzie innego zespołu.
Delegujmy aktywność review do wyznaczonego lidera z drugiego zespołu.
Lider dba o review podczas prac, konsultując się z resztą zespołu tylko w razie potrzeby.
Zespół bazowy weryfikuje zmiany w trybie "Show", a nie "Ask" (nawiązując do koncepcji Ship/Show/Ask).
To podejście pozwala na zachowanie kontroli jakości przy jednoczesnym zmniejszeniu obciążenia całego zespołu procesem review.
Podsumowanie
Wprowadzenie tych rozwiązań wymaga pewnych zmian w organizacji pracy, ale może znacząco zmniejszyć liczbę review między zespołami, jednocześnie utrzymując wysoką jakość kodu.
Pamiętajmy, że celem nie jest całkowite wyeliminowanie review między zespołami, ale optymalizacja tego procesu tak, by był jak najbardziej efektywny.
A Ty, jak sobie radzisz z PR Review pomiędzy zespołami?