3 Skuteczne Podejścia do Pair Programming

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