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 zespoleNajlepiej 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łamiPodnosi moraleWady:Angażuje mnóstwo osóbPojedyncze osoby mogą stracić zainteresowanieDyskusje 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 problemyRóżne godziny pracyCzę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 pracyJak 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 ProgrammingZasadnicze 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 ProgrammingNie 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.