3 Skuteczne Podejścia do Pair Programming

3 Skuteczne Podejścia do Pair Programming

pair programming

 

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.

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

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.

  • 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ę.

  • Częste zmiany Drivera oraz Navigatora ograniczają rozproszenie uwagi
  • Wynikiem jest dobrze przetestowany kod
  • Historia w repozytorium opisuje zmiany małymi krokami
  • 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.

  • 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
  • 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.

  • 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
  • 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.

 

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.

Paweł Pluta

Senior Software Engineer

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.

Opublikowano: 21 września 2021