PR Review - Usprawnienia - Zwiększenie zaufania
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:
Usprawnienia - Zwiększenie zaufania [TEN ARTYKUŁ]
Z ostatniego wydania artykułu mogliście dowiedzieć się, jak utrzymywać jakość bez konieczności uciekania się do PR Review. Dziś opisujemy temat od strony bardziej interpersonalnej - jak budować zaufanie do nowych metod.
Rozwiązania na zwiększenie zaufania
Jednym z głównych powodów przeprowadzania PR Review nie są problemy funkcjonalne, ale emocjonalne. Nie ufamy naszym kolegom/koleżankom, że wypełnią swoje obowiązki jak należy. To sprawia, że chcemy sprawować bezpośredni nadzór nad ich pracą.
Praktyki opisane poniżej adresują te problemy – chcemy zwiększyć zaufanie do naszego zespołu, tak by powierzać im określone obszary produktu,
Główną metodą, którą możemy tutaj polecić jest wspomniane już Ship / Show / Ask i przejście więcej na tryb “Ship” i “Show”. Istnieje jeszcze kilka praktyk wartych polecenia:
Techniczne Show & Tell
Podejście Show & Tell często pojawia się dookoła metod zwinnych. Jest to metoda na zaangażowanie interesariuszy w wyniki sprintu – tak, aby przedyskutować to co zostało dowiezione i ustalić dalsze akcje.
To samo podejście możemy zastosować do technicznej pracy.
Wykorzystujemy Ship / Show / Ask i zbieramy materiały w trakcie sprintu.
Spotykamy się +/- raz per sprint, po jego zakończeniu.
Przegadujemy to, co zostało wdrożone, jak działa, jakie są wyniki.
W ramach tego spotkania podejmujemy się review kodu, który jest już wdrożony.
Takie spotkanie skupia się na cyklicznej wymianie wiedzy i uczeniu od siebie wzajemnie. Dzielimy się dobrymi praktykami i jednocześnie adresujemy problemy, z którymi będziemy musieli sobie poradzić w kolejnych tygodniach.Sama dyskusja ma charakter o wiele głębszy niż typowe PR Review. Do Technicznego Show&Tell możemy bardziej się przygotować. Każdy ma na to spotkanie czas. Mamy miejsce na otwarte pytania.
Dzięki temu:
Poznajemy punkt widzenia innych osób.
Rozwijamy kompetencje kolegów i koleżanek o kluczowe praktyki
Łatwiej adresujemy palące kwestie w zespole.
Ostatecznie, zaufanie wzrasta.
Określenie ważności systemów i obszarów
Wymagania jakościowe nie są takie same dla wszystkich systemów i obszarów:
Dojrzały system posiadający 10k aktywnych użytkowników będzie miał inną tolerancję na błędy i fuckupy niż startup mający 10 użytkowników.
Inaczej podejdziemy do tempa rozwiązywania problemów w projekcie z 99.99 SLA, a inaczej w wewnętrznej aplikacji w trybie maintenance, utrzymywanej przez jedną osobę na part-time.
Inne oczekiwania jakościowe mają prototypy rozwiązań, co do których ani my ani biznes nie ma pewności, bo budujemy je pierwszy raz. Inne, kiedy robimy refactor czy rewrite i wiemy, jak oczekiwania spotkały się z rzeczywistością (poziomy ryzyka i niepewności są zupełnie inne).
Moduł będący naszą główną domeną biznesową będzie miał inne założenia co do oczekiwanej długości życia kodu niż moduł będący domeną generyczną. Tę domenę być może zastąpimy w przyszłości usługą third party albo zoutsourcujemy dla innej firmy. Dlatego powinniśmy mieć inne oczekiwania co do pokrycia testami, niezawodności, dokładności monitorowania, architektury.
I tak dalej…
Z wyżej wymienionych względów, utrzymywanie tego samego standardu jakości i kodu nie jest optymalnym inżynieryjnie rozwiązaniem. Zastanów się, czy praktyki, które stosujecie są dopasowane do fazy i znaczenia tego projektu. Czy każdy w zespole zdaje sobie z tego sprawę?
Zadbaj, aby te praktyki były w zespole wiążącym elementem wzajemnego zrozumienia – niczym kontrakt. Niech każdy wie, co jest od niego oczekiwane, czemu w tym projekcie jesteśmy bardzo dokładni, a w innym mniej. Zobaczysz jak wiele rozbieżności znajdziesz pomiędzy poszczególnymi członkami zespołu.
Mając ustalone jasne reguły łatwiej jest sobie ufać, bo każdy wie co jest od niego oczekiwane.
Unikanie matkowania
Ciekawym i zupełnie nieoczywistym problemem jest “matkowanie” mniej doświadczonych programistów.
Świetni liderzy, mając dobre intencje wyjątkowo dokładnie weryfikują zmiany mniej doświadczonych programistów. Jest to forma mentoringu i nauki. W sytuacjach ekstremalnych może jednak dojść do sytuacji, gdzie zespół polega na liderze jako na swojej “siatce bezpieczeństwa”, trochę jak na kolejnej warstwie testów.
Te zachowania są często nieświadome:
Nie mam czasu zrobić dokładnego self-review, ale lider na pewno złapie, jeżeli mam tam jakiś błąd (lenistwo).
Jeżeli lider jest z tym OK no to na pewno jest dobrze (abdykacja ownershipu).
Lider też nie wyłapał tego błędu (brak odpowiedzialności za własne błędy).
Tworzy to ogromny bus factor w zespole, wywiera presję na liderze i przyczynia się do powstania dysbalansu wysiłku.
Jeżeli jesteś takim liderem – chociaż to zabrzmi kontrowersyjnie – przestań ratować swój zespół. Gdy zabraknie siatki, wielu z nich szybko dojrzeje i podniesie swoje standardy.
Trial by fire
Często w naszych firmach zakładamy, że bardziej doświadczona osoba zawsze musi patrzeć mniej doświadczonej na ręce.
Jeżeli jednak nie jesteś w stanie usunąć wymogu approvala od członków zespołu nawet po okresie 6 miesięcy, zastanów się, dlaczego tak się dzieje:
Co nowa osoba musiałaby zrobić, aby zyskać Twoje zaufanie?
Czy brakuje jej jasno sprecyzowanych oczekiwań, albo ścieżki rozwoju?
Co najgorszego może się stać, jeżeli jednak na to pozwolisz?
Jak szybko uda się tą najgorszą sytuację odwrócić?
Z naszego doświadczenia firmy, które mocno unikają konfrontacji dochodzą do poziomu „ruinus empathy” z Radical Candor:
Podejście „trial by fire” promuje przeciwne zachowanie
Aby móc wrzucać kod na produkcję, musisz otrzymać odpowiednią liczbę “approvali” dotyczących Twojej jakości kodu od bardziej doświadczonych kolegów.
Każdy kto przejdzie ten okres “próbny” staje się zaufany – może wdrażać bez approvala. Razie trudnych sytuacji sama zgłosi się do reszty zespołu o radę.
To podejście warto połączyć z określeniem podziału ważności obszarów i systemów – by określać w których miejscach mamy takie prawa.
Jest to prosta zasada i łatwa do wdrożenia w założeniach funkcjonalnych, ale trudniejsza w emocjonalnych.
Dlatego upewnij się, że ta obawa o wrzucanie zmian przez twoich kolegów i koleżanki jest uzasadniona - że nie jest to tylko Twój własny strach lub ego.
Podsumowanie
W serii PR Review to już wszystko.😅 Na tym etapie pewnie dostrzegasz już, że wiele z opisanych praktyk się uzupełnia, ma części wspólne lub nawet bardzo podobne założenia. PR Code review jest głęboko zakorzeniony w kulturze większości firm a dla wielu developerów odejście od tego procesu wydaje się być wręcz obrazoburcze 😊.
Mamy nadzieję, że po lekturze rozumiesz, że istnieją lepsze alternatywy. Zachęcamy do eksperymentów w Twoim zespole i zmierzenia sytuacji przed i po w oparciu o metryki powyżej - a potem wróć do nas, i pochwal się jak Ci poszło!