Pracowałem przy użyciu Pair Programming codziennie przez ponad dwa lata. Przez ten czas wspólnie z zespołem mieliśmy swoje wzloty i upadki przy stosowaniu tego podejścia. Ogólnodostępna wiedza zazwyczaj przedstawia Pair Programming jako cudowne rozwiązanie pasujące do każdego. W rzeczywistości napotkaliśmy i rozwiązaliśmy problemy, o których nie teoria wspominała, a po czasie wypracowaliśmy własne podejścia do Pair Programmingu.
Teoria
Oficjalnie podczas Pair Programmingu dwoje programistów używa jednego i tego samego komputera do pracy. Siedzą wspólnie przy jednym biurku, używają tej samej klawiatury i monitora, zmieniając się co jakiś czas. Gdybym ściśle trzymał się tej definicji, to nie mógłbym powiedzieć, że używałem Pair Programmingu do pracy. Zdecydowanie woleliśmy pracować każdy przy swoim biurku — ceniliśmy sobie swoją przestrzeń osobistą. Zamiast tego używaliśmy udostępniania ekranu.
Podczas pracy w parze, każda z osób ma przydzieloną odpowiedzialność. Osoba, która aktualnie pisze kod (nie mów “pracuje”, bo ktoś może zrozumieć, że druga osoba z pary w tym czasie nic nie robi), nazywana jest Driverem. Na drugą osobę mówimy Navigator. Zależnie od wybranego podejścia, ich role będą się nieco różnić, ale główna zasada będzie taka sama. Częścią wspólną wszystkich podejść jest to, że Driver oraz Navigator muszą być w pełni skupieni na pracy. Patrząc przez pryzmat czasu, było to największym wyzwaniem.
Jak zacząć?
Nie staraj się wprowadzić nowego podejścia od razu do całego zespołu. Zasugeruj nowe podejście, ale wystarczy, że jedna osoba będzie chciała spróbować
Ustalcie sposób pracy — przy jednym biurku, biurko obok biurka, udostępnianie ekranu podczas wideokonferencji, a może wbudowane w IDE udostępnianie ekranu
Wybierz podejście, od którego zaczniecie
Ustalcie, kiedy będziecie robić przerwy. Krótka przerwa od zadania pozwala się lepiej skupić na pracy oraz odświeża umysł
Rozmawiajcie podczas pracy. Dużo. Mów na głos wszystko, co masz w głowie, nawet gdyby miało brzmieć głupio. Każdy pomysł może naprowadzić Was na rozwiązanie
Teraz do rzeczy!
Strong technique oraz Traditional technique
Najpopularniejsze oraz najczęściej opisywane podejścia, chociaż osobiście ich nie lubię. Nie używam ich, więc nie będę ich wliczał do prezentowanych tutaj podejść Pair Programming, ale warto o nich wiedzieć. W Strong technique Navigator jest mózgiem. Dyktuje Driverowi wszystko, co ten ma napisać. W tym podejściu Navigator dominuje nad Driverem sprowadzając go do roli code monkey. Traditional technique daje nieco więcej swobody, bo Driver może brać bardziej czynny udział w pracy nad rozwiązaniem i próbować nakierować Navigatora na inny tor rozumowania. Nadal jednak to podejście bardziej angażuje jedną stronę oraz nie mówi wprost, kiedy osoby w parze powinny zamienić się rolami.
Zalety:
Najprostsze podejście; wymaga tylko drugiej osoby
Wady:
Angażuje jedną stronę bardziej od drugiej
Zakłóca komunikację, zwłaszcza Strong technique — aby Driver mógł zmienić sposób implementacji, musi najpierw zamienić się rolami z Navigatorem
Często niepoprawnie używane podczas wprowadzania nowych osób do projektu. W tym przypadku “Pair Programmingiem” niektórzy nazywają sytuację, kiedy doświadczony w projekcie programista programuje, podczas gdy nowy tylko siedzi i patrzy
Podejście Test-Driven Development
Podejście wymuszające oraz bazujące na Test-Driven Development. Najprościej mówiąc, Driver pisze test, który nie przechodzi, a następnie Navigator przejmuje jego rolę.
Następny w kolejce Driver implementuje najprostszy możliwy kod oraz robi niezbędny refactoring. Kolejnym i ostatnim krokiem jest napisanie następnego testu, który nie przechodzi, oraz ponowna zmiana Drivera. Navigator natomiast jest tutaj osobą, która skupia się bardziej na ogóle: pilnuje, aby logika biznesowa była spełniona, udziela wskazówek podczas developmentu, sprawdza dokumentację albo pełni po prostu rolę gumowej kaczuszki.
Pozytywnym efektem ubocznym tego podejścia do Pair Programmingu jest bardzo dobrze przetestowany jednostkowo kod. Na początku, zwłaszcza jeżeli nie masz zbyt dużego doświadczenia w Test-Driven Development, możesz doświadczyć dysproporcji pomiędzy czasem potrzebnym na napisanie testu oraz jego implementację. Musisz przestawić się na testowanie głównie jednostkowo — testy integracyjne w tym podejściu są dodawane zazwyczaj na końcu tylko jako sprawdzenie poprawności komunikacji Twojej aplikacji ze światem zewnętrznym. Struktura testów będzie pasowała do piramidy testów, więc być może to nie będzie najlepsze podejście, jeżeli preferujesz test diamond lub trophy.
Zalety:
Jasno określony moment zmiany Drivera
Częste zmiany Drivera oraz Navigatora ograniczają rozproszenie uwagi
Wynikiem jest dobrze przetestowany kod
Historia w repozytorium opisuje zmiany małymi krokami
Wady:
Jeżeli nie masz doświadczenia lub dopiero zaczynasz TDD, to podejście może być przytłaczające
Bardzo intensywny sposób pracy bez ustalonych przerw
Pipeline musi być przystosowany do nieprzechodzących testów na branchu
Podejście Pomodoro
Hybrydowe podejście pomiędzy Traditional technique oraz Pomodoro. Ustal długość sesji, w czasie których pracujecie oraz określcie długość przerw między sesjami. Stosowaliśmy około 20–25 minutowe sesje — jest to zazwyczaj wystarczający czas, aby “załadować kontekst” oraz napisać trochę kodu. Po każdej sesji zróbcie 5 minut przerwy. Co kilka cykli potrzebna jest dłuższa przerwa, zazwyczaj po mniej więcej 2–4 sesjach programowania. Nie przesadzaj z dłuższą przerwą, 10–20 minut powinno być wystarczające. Po każdej przerwie Driver powinien zamienić się rolami z Navigatorem.
W tym podejściu znika podział na piszącego testy oraz implementację. Driver musi robić to wszystko: pisać testy, ich implementację oraz robić refactoring, tak długo, jak trwa jego sesja. Gdy tylko sesja się kończy, zrób commit oraz przekaż kod Navigatorowi — będzie musiał dokończyć pracę.
Ważne jest, aby pamiętać, że w trakcie programowania przez Drivera, Navigator ma także mnóstwo pracy. Musi nadążać za tokiem rozumowania Drivera, sprawdzać dokumentację, podpowiadać rozwiązania albo wyszukiwać rozwiązań problemów w Internecie. Navigator musi być wsparciem, aby Driver mógł wykonywać swoją pracę tak efektywnie jak to tylko możliwe. Jako Navigator musisz także pilnować czasu sesji, jednak bądź nieco elastyczny. Jeżeli Driver ma niedokończoną myśl, to pozwól mu ją skończyć. Podobnie z drugiej strony — kiedy widzisz, że Driver ma z czymś problem i nie jesteś w stanie wytłumaczyć rozwiązania, zasugeruj wcześniejszy koniec sesji.
Podczas używania podejścia Pomodoro, mieliśmy zasadę, aby używać krótkich przerw do wstania od komputera i zrobienia kilku kroków. Pozwalało to na odświeżenie umysłu i ułatwiało skupienie się na pracy podczas następnej sesji.
Zalety:
Może bardziej do Ciebie pasować, jeżeli nie jesteś zaznajomiony z TDD
Daje Navigatorowi czas na szukanie i sugerowanie lepszego rozwiązania problemu
Zmusza ludzi w parze do myślenia na głos oraz rozmawiania. W przeciwnym razie dokończenie pracy po czyjejś sesji jest trudne
Jasno określa przerwy i pozwala na odświeżenie umysłu
Wady:
Wymaga osób o podobnym poziomie doświadczenia, inaczej mniej doświadczona osoba może nie nadążać za bardziej doświadczonym programistą
Pipeline muszą być gotowe na to, że kod na branchu może się nawet nie skompilować
Podejście Mob Programming
Właściwie, to nie jest podejście Pair Programming, ale technika pozwalającą rozszerzać wiedzę i rozwiązywać bardzo zawiłe problemy. Podczas Mob Programmingu musisz zaangażować więcej osób, najlepiej cały zespół. W czasach, gdy jeszcze pracowaliśmy w biurze, był to okres, gdy siadaliśmy wspólnie w jednej salce z rzutnikiem i udostępnialiśmy na nim ekran. Driver dbał o to, aby na ekranie zawsze był widoczny aktualny kod, a cały zespół urządzał burzę mózgów, aby znaleźć rozwiązanie.
Ze względu na ilość uczestników, niektóre tematy mogą być analizowane równolegle. Czasami podczas pracy naturalnie tworzyły się pary, które sprawdzały przydatność zasugerowanego rozwiązania zanim zostanie ono zintegrowane przez Drivera.
Podejście Mob Programming ma także inny ważny aspekt — budowanie morale zespołu. Wykorzystaj to do wspólnego pójścia na kawę lub wspólnego obiadu. Prawdopodobnie nadal pracujesz z domu, ale to też jest OK! Używaliśmy także mini gier online, aby na chwilę oderwać się od problemu i móc spojrzeć na niego świeżym okiem. Polecam Haxball oraz Among Us jako kilkuminutowe przerwy na odświeżenie.
Głównym problemem tego podejścia jest utrzymywanie skupienia na problemie. Im zebranie jest większe, tym łatwiej pojedyncze osoby mogą stracić zainteresowanie tematem. Prostym sposobem na rozwiązanie tego jest poproszenie takie osoby o sprawdzenie jednego, małego i konkretnego tematu. Pamiętaj, aby też zmienić Drivera od czasu do czasu.
Zalety:
Świetnie wyrównuje wiedzę w zespole
Najlepiej sprawdza się przy rozpoczynaniu dużych i skomplikowanych zadań
Może zostać użyte z programistami z innych zespołów, aby wyjaśnić zależności między zespołami
Podnosi morale
Wady:
Angażuje mnóstwo osób
Pojedyncze osoby mogą stracić zainteresowanie
Dyskusje nad rozwiązaniem mogą się przeciągać. Driver (albo wybrany Navigator) powinien wiedzieć, kiedy ją zakończyć
No dobrze, które podejście powinienem wybrać?
Po pierwsze, najpierw znajdź osobę, która chce spróbować Pair Programmingu. Nie możesz do tego nikogo zmusić. Zmuszony programista nie będzie zadowolony z pracy i nie będzie na niej wystarczająco skupiony, aby pracować efektywnie. Wystarczy znaleźć jedną osobę, inni pewnie dołączą sami, gdy zobaczą efekty. Nie próbuj także pracować nowym podejściem od 8 do 16, raczej zacznij od małego i prostego zadania.
Jeżeli chodzi o wybór, to czując się dobrze w Test-Driven Development, zacznij od tego podejścia. Jeżeli jednak dopiero zaczynasz z TDD lub zupełnie go nie znasz, to zacznij od podejścia Pomodoro. Pomodoro może wydawać się trudnym do utrzymania podejściem, więc (chociaż nie jestem jego fanem) możesz zacząć od Traditional technique. Po prostu pamiętaj, aby często zmieniać Drivera z Navigatorem. Mając przed sobą duży i trudny problem, użyj Mob Programmingu. Zasugeruj to podejście nawet jeżeli to nie Twoje zadanie jest trudne — wyjdziesz z inicjatywą czegoś nowego. Ostatecznie to cały zespół jest odpowiedzialny za rozwiązanie.
Częste problemy
Różne godziny pracy
Często zdarza się tak, że różne osoby w zespole zaczynają pracę o różnych godzinach. Sam lubię zaczynać pracę o 7 rano, a kiedyś byłem w parze kolegą, który wolał pracować od 10. Nadal udało się nam zrobić Pair Programming — wykorzystaliśmy maksymalnie dostępne wspólne 5 godzin. Pozostałe 3 godziny można spokojnie przeznaczyć na zadania, które każdy z nas musi robić, ale nigdy nie ma na nie czasu, np. code review, odpowiedzieć na maile, udzielić wsparcia innym zespołom, sprawdzić infrastrukturę, pójść na spotkanie czy napisać fragment kodu, który później przekażesz drugiej osobie w parze. Każde z tych zadań zużywa dużo czasu, a większość w nich można wykonać niezależnie.
Osoba w mojej parze ma inne przyzwyczajenia/podejście do pracy
Jak dla mnie, to jest największy problem. Jest tym bardziej dotkliwy, im bardziej dwie osoby są dogmatyczne i nie chcą pójść na ustępstwa. Patrząc na to od drugiej strony, Pair Programming jest dobrą metodyką, aby poznać inne podejście i wyciągnąć z niego to, co najlepsze. Wymaga to od Ciebie dialogu popartymi argumentami, które nie opierają się na przyzwyczajeniach lub emocjach. Zastanów się, czy brak możliwości prowadzenia takiego dialogu to jest coś, nad czym samemu nie powinieneś popracować. W najgorszym wypadku, gdy nie potraficie się zupełnie dogadać, możesz zasugerować zmianę pary na inną.
Mój manager nie pozwala nam na Pair Programming
Zasadnicze pytanie brzmi “dlaczego manager decyduje o metodyce Twojej pracy”? Mikrozarządzanie jest bardzo szkodliwe dla wydajności oraz oddolnych inicjatyw. Osoba, która nie jest bezpośrednio odpowiedzialna za utrzymywanie aplikacji nie powinna mieć ostatniego zdania na temat używanych w projekcie bibliotek lub technik. Wyjątek to oczywiście próba użycia technologii niezgodnych z założeniami firmy, jak np. użycie rzadkiego języka zamiast tego, który jest używany powszechnie. Jeżeli jednak potrzebujesz argumentów, podeślij managerowi jedną z najbardziej znanych prac na temat Pair Programmingu. Wystarczy przeczytać podsumowanie na pierwszych stronach: nakład pracy zwiększa się o około 15%, ale zyskuje się mniejszą ilość błędów, łatwiejsze utrzymanie aplikacji oraz lepszą satysfakcję programistów.
Pracuję zdalnie i nie mogę usiąść obok nikogo, aby stosować Pair Programming
Nie musisz siedzieć przy jednym biurku z drugim programistą, aby stosować Pair Programming. W czasie, gdy pracowałem jeszcze w biurze, zawsze używaliśmy wideokonferencji (Teams, Slack, Zoom), nawet gdy siedzieliśmy 2 metry od siebie. Driver udostępnia swój ekran oraz prowadzi ciągły dialog z Navigatorem. Dobrze mieć dostęp do dwóch monitorów, aby na jednym mieć wyświetlony cały czas udostępniony kod. Możesz też używać rozwiązań wbudowanych w IDE, np. Idea Code With Me.
Programista skupiony na jakości kodu i zrozumieniu potrzeb biznesowych. Specjalizuje się w Javie, uwielbia pracę z nowymi technologiami. W życiu prywatnym lubi tworzyć własne urządzenia automatyki domowej, uprawiać bonsai i strzelać z łuku.
