Programowanie mobilne - 5 programistów na jednym komputerze?

Przeprowadzanie eksperymentów w celu ulepszenia naszych procesów jest częścią naszej codziennej pracy. Kiedy więc słyszę o czymś, co może nam pomóc w poprawie, chcę to zbadać. Na początku 2019 roku dołączyłem do konwencji Domain Driven Design Europe. Podczas przerw dużo rozmawiałem z innymi uczestnikami, głównie programistami.

W wielu z tych rozmów pojawiał się temat warsztatów Mob Programming z konwentu rok wcześniej. Deweloperzy byli bardzo, bardzo entuzjastycznie nastawieni do programowania mobowego: wielu deweloperów pracujących w tym samym pomieszczeniu na jednym komputerze. Wyjaśnili, jak wiele nauczyli się i rozwinęli jako zespół w wyniku tych sesji. Był to dla mnie wyraźny sygnał, by dowiedzieć się więcej na ten temat. Potem zdecydowałem, że będziemy z tym eksperymentować.

Istotną częścią eksperymentu jest hipoteza. Bez niej nie wiadomo, czy eksperyment się powiódł. Moja teoria zakładała, że programowanie mobów pomoże nam dzielić się wiedzą między programistami podczas tworzenia czystego kodu.

Zaplanowałem i przygotowałem naszą pierwszą sesję programowania mobów, co nie było takie trudne:

• Podłącz komputer do dużego ekranu

• Umieść stół przed ekranem.

• Dodaj pięć miejsc do stołu.

• Umieść na stole przekąski i materiały.

Byliśmy tam, pięciu programistów w pokoju z jednym komputerem:

Co wydarzyło się podczas naszej pierwszej sesji programowania mobów?

Wesley siada przy klawiaturze (używamy jego komputera) i automatycznie zostaje mu przypisana rola kierowcy. Kierowca jest inteligentnym urządzeniem wejściowym: może pisać, ale nie może podejmować decyzji. Pozostali deweloperzy otrzymują rolę nawigatora. To oni dyskutują o tym, co powinno się wydarzyć i mówią kierowcy, co ma robić.

Kierowca jest inteligentnym urządzeniem wejściowym: może pisać, ale nie może podejmować decyzji

Zaczynamy pracę nad prostą, rozgrzewającą historią, w której musimy usunąć nieaktualne treści w stopce witryny.

Nawigatory mówią Wesleyowi, aby uruchomił Dockera. Natychmiast pojawia się komunikat o błędzie. Wesley wyjaśnia, że czasami się to zdarza, ale zawsze udaje się to naprawić po kilku próbach. Nie ponawiamy próby, ale nawigatorzy wyjaśniają, które ustawienia należy zmienić. Od tej pory Docker zawsze uruchamia się bez błędu. 

Wesley zapisuje na karteczce samoprzylepnej to, czego dowiedział się o Dockerze. Umieszcza tę karteczkę samoprzylepną na dużym arkuszu papieru o nazwie Learnings.

Piszę na karteczce samoprzylepnej, że nieuruchomienie Dockera nas powstrzymuje. Podaję ją do Waste Snake, dużego arkusza papieru z narysowanym wężem. Na tym arkuszu umieszcza się karteczki samoprzylepne opisujące wszystko, co powstrzymuje tłum przed faktycznym programowaniem:

Po 12 minutach zabrzmi brzęczyk. Wszyscy muszą przesunąć się w prawo. Kierowca staje się nawigatorem, a jeden z nawigatorów staje się kierowcą. Jest to trochę kłopotliwe i zajmuje trochę czasu, aby zacząć od nowa. Ale po kilku zmianach idzie nam znacznie lepiej.

Kończymy historię i zaczynamy pracę nad następną: Yii2 view causes bogus comments in HTML, which causes HTML invalidation. Interesująca historia. Została już dwukrotnie podjęta przez różnych deweloperów, ale obaj utknęli w martwym punkcie. Każdy ma swój udział w tej historii. Ostatecznie rozwiązaliśmy problem w sposób, z którego wszyscy są bardzo zadowoleni.

Po dwóch godzinach sesja się kończy.

Czego nauczyliśmy się podczas naszej pierwszej sesji programowania mobów?

Robimy spotkanie retrospektywne, aby omówić, co poszło dobrze, a co możemy poprawić. Kluczowym wnioskiem jest to, że naprawiliśmy historię lepiej / dokładniej w jednej iteracji, niż gdyby pracowała nad nią jedna osoba.

Poprawiliśmy historię lepiej / dokładniej w jednej iteracji, niż gdyby pracowała nad nią jedna osoba.

Podczas retrospektywy wszyscy czują się pełni energii. Eksperyment spodobał się nam wszystkim. Stało się jasne, że programowanie mobowe rzeczywiście pomaga nam dzielić się wiedzą podczas tworzenia czystego kodu.

Większość wniosków była dość oczywista, na przykład gdy skrót był nieznany dla sterownika lub konfigurowanie narzędzi w celu zwiększenia wydajności. Stało się oczywiste, jak łatwo jest dodać marnotrawstwo do własnego procesu rozwoju, stosując obejścia, gdy system zachowuje się nieoczekiwanie. To potwierdza potrzebę przyjęcia the Improvement Kata.

Inne wnioski były bardziej subtelne. Na przykład znalezienie sposobów na podzielenie trudnego problemu na mniejsze problemy. Albo sugestie dotyczące tego, jak naprawdę pracować w oparciu o Test Driven, najpierw tworząc nieudany test, zamiast po prostu dodawać test później.

Eksperyment się powiódł! Kolejna sesja jest już zaplanowana

Jedną z trudniejszych rzeczy do osiągnięcia był poziom komunikacji między nawigatorami a kierowcą. Nie chcesz wszystkiego wyjaśniać, zwłaszcza bardziej doświadczonym deweloperom. Ale nie chcesz też pozwolić, by młodszy programista poczuł się jak rzucony na głęboką wodę. Z czasem tłum uczy się, jak zwracać się do poszczególnych kierowców we właściwy sposób.

Zdalne programowanie mobów

W Holandii mamy obecnie lockdown. Nasze biuro jest zamknięte i wszyscy pracują zdalnie. To sprawia, że programowanie mobów, jak opisano powyżej, jest niemożliwe, ponieważ nie możemy przebywać w tym samym pomieszczeniu.

Nadal jednak chcieliśmy przeprowadzać sesje programowania mobów. Metodą prób i błędów doszliśmy do następujących rozwiązań dla doskonałej zdalnej sesji programowania mobów:

• Każdy ma kamerę internetową i każdy włącza ją podczas sesji.

• Używamy Whereby do hostowania naszych spotkań, ponieważ możesz udostępniać swój ekran i nadal widzieć nawzajem swoje kamery.

• Kierowca loguje się na dedykowanym komputerze za pośrednictwem połączenia pulpitu zdalnego (w tym celu utworzyliśmy konto użytkownika mob w sieci wewnętrznej).

• Utworzyliśmy osobne konto użytkownika mob dla Git. Ułatwia to przełączanie ról.

Jak mogę eksperymentować z tym we własnym środowisku pracy?

Ze wszystkich artykułów, blogów i e-booków, które przeczytałem na temat programowania mobów, mogę zdecydowanie doradzić przeczytanie tych dwóch:

• The Mob Programming Guidebook (ostatnio przemianowany na Ensemble Programming Guidebook) autorstwa Maaret Pyhäjärvi.

• Mob Programming - A Whole Team Approach autorstwa Woody Zuill.

Następnie wybierz datę ze swoją drużyną i wypróbuj ją. Miłej zabawy!