Praca W Parach — Jak ja to widzę?

W tym wpisie nie zamierzam się skupiać na przedstawieniu dokładnego opisu tego, jak wygląda praca w parach (org. Pair Programming). Nie przeczytałem nawet książki Kenta Becka, dzięki której to Pair Programming zyskało na popularności. 

To ciekawe!

Extreme Programming (XP) to metodyka wytwarzania oprogramowania, która została sformalizowana przez Kenta Becka w książce „Extreme Programming Explained: Embrace Change”.

To na czym mi zależy to pokazanie tego, w jaki sposób ja podchodzę do pracy w parach, a tak naprawdę do pracy w grupach. Mam nadzieję, że da Ci to trochę do myślenia. 

Zaczynajmy więc!

Problem

W swojej pracy uwielbiam rozmawiać z innymi programistami o napotkanych problemach w kodzie. Rozkładać je na czynniki pierwsze i dogłębniej analizować. Swoją drogą często wpadam w pułapkę zbyt głębokiego analizowania problemów, ale to chyba temat na inny wpis.

W projekcie, w którym aktualnie pracuję (piszę ten artykuł we wrześniu 2022) pojawia się wiele dylematów do analizy. Bynajmniej nie są one trywialne. 

Przyznam, że mam tendencję to próby rozwiązywania problemów na własną rękę tzn. włączyć tryb ⛔️ Do not disturb w teamsach i jechać z tematem. O ile dla wielu prostych bugów i zadań, które są oczywiste, jest to całkiem normalne, o tyle dla problemów bardziej skomplikowanej klasy może to być gwóźdź do trumny.

Zbyt długie skupienie na danym problemie i jeszcze dłuższe próby jego rozwiązania z łatwością mogą Cię skierować w kierunku zamknięcia się na inne sposoby rozwiązania problemu.  Wtedy już bliska droga do siedzenia nad taskiem tydzień lub więcej. 

I nie jest to przykład wyssany z palca. Samemu zdarzało mi się doprowadzać do takiej sytuacji, ale także byłem tego świadkiem u innych programistów.

Jak wygląda praca w parach u mnie?

Dlatego, kiedy łapię się na tym, że nie widzę rozwiązania, od razu staram się z kimś pogadać. Zdarza się, że musisz pokombinować z kimś dłużą chwilę, zanim dotrzesz do akceptowalnego rozwiązania. Czasem zdarzy się, że go nie znajdziesz. To, co chcę tutaj powiedzieć, to to, że w obu przypadkach częścią wspólną jest to, że skonsultowałeś problem z drugą osobą. To jest według mnie największy benefit, jaki daje praca w parach.

I co z tego zapytasz. A ja Ci odpowiem: Właśnie wzmocniłeś więzi zespołowe. Cholernie ważna sprawa w dzisiejszych czasach (fakt, brzmi to dziwnie). W czasach, w których większość zespołów developerskich opiera się na pracy zdalnej zdecydowanie trudniej prowadzić interakcje pomiędzy członkami zespołów. To, co w biurze przychodziło łatwo, tutaj jest znacznie trudniejsze i wymaga większego wysiłku, ale nadal jest potrzebne. Znacznie bardziej potrzebne niż wcześniej. 

Spójrz, zamiast spędzać kilka godzin (które jak wcześniej wspomniałem, może rozrosnąć się do wielu dni) i stać w miejscu po prostu pogadaj z kolegą/koleżanką z zespołu. Poznaj inny punkt widzenia, pozwól sobie na to, aby zagadać do innych i powiedzieć: Hej, mam problem. Masz chwilę?

Byłbym zapomniał. Istnieje spora szansa na to, że w czasie kiedy będziesz tłumaczył innej osobie, w czym masz problem, wpadniesz na jego rozwiązanie. Kiedyś chciałem skonsultować problem z Tomkiem, jednym z senior devów z mojego zespołu, czekałem chyba z dobrą godzinę, aż będzie wolny. Spotkanie trwało jakieś 15/20 sekund.

Zadziała metoda gumowej kaczuszki.

A rubber duck is in the bath. by S. Tsuchiya
A rubber duck is in the bath. by S. Tsuchiya

Nie tylko bugi

Wspólnie można również pracować nad nowymi funkcjonalnościami. Szalenie polecam pogadanie z jednym czy z dwoma devami, zanim siądziesz do pracy nad swoim zadaniem. Zaproponuj im swój pomysł na implementację, zbierz opinie, przegadajcie to. Masz wtedy zdecydowanie większą szansę na przygotowanie lepszego rozwiązania. Zamiast poprawiać kod na etapie pull requesta, możesz to zrobić dużo wcześniej.

Analiza techniczna zadań po Sprint Planningu

Jakiś czas temu zaproponowałem w swoim zespole programistów dodatkowe spotkanie po planowaniu sprintu. Jego celem jest przejrzenie zadań, które zaplanowaliśmy. Przegadujemy w takim gronie potencjalne problemy, proponowany sposób implementacji i często robimy podział tego, kto, nad czym i z kim będzie pracował.

To, co było z mojej perspektywy ważne to to, że na tym spotkaniu są tylko programiści, więc możemy rozmawiać kompletnie technicznie i bez oczu wielkiego brata, jakim jest Product Owner, Manager czy Scrum Master. 😎

Co więcej?

Szerzenie wiedzy w zespole. Przy okazji pytań, które pojawią się podczas dyskusji, jest również duża szansa na to, że dowiesz się czegoś nowego o konkretnej części kodu. Może to być powód, dlaczego coś zostało zaprojektowane tak, a nie inaczej, może twój rozmówca jest świadomy jakiegoś innego problemu w tej części kodu? Każda rozmowa zwiększa prawdopodobieństwo poznania czegoś nowego. 

Tak dużo rzeczy czeka na poznanie przez Ciebie, wystarczy zagadać. 🤗

To oczywiste

Byłoby książkowo, gdybyś w takich przypadkach prosił o pomoc różne osoby. Praca z ulubionym kolegą w zespole jest ok, ale rozmowa z wieloma ma ten plus, że podświadomie pokazujesz zespołowi, ze wspólna praca jest wartościowa. 

Być może to, co napisałem, jest oczywiste. Pracuj z innymi, to będzie super! Nie zamykaj się ścianach swojego umysłu!

Tak serio… pamiętasz o tym w swojej codziennej pracy? Interakcja z zespołem jest szalenie ważna. Szczególnie teraz w czasach popularności pracy zdalnej. Dbaj o to, wspólne rozgryzanie problemów buduje,  polepsza relacje, a na koniec dnia powoduje, że pracujesz w zespole, a nie z grupą osób.

Oferuj pomoc innym. Proś o pomoc również mniej doświadczone osoby.

Newsletter

Dołącz do grona osób zapisanych na mój mailing. W ramach powitania dostaniesz ode mnie darmowy e-book „Elementarz Mobilnego Programisty”.

Znajdziesz w nich kilka narzędzi oraz wskazówek dla programisty aplikacji mobilnych.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.

Wypełnij to pole
Wypełnij to pole
Proszę wprowadzić prawidłowy adres e-mail.
You need to agree with the terms to proceed