Wymiana par: jakie są zalety i wady?

Ogólna idea, którą popiera większość teoretyków Agile / XP , wydaje się polegać na tym, że pary powinny regularnie zamieniać. Na przykład każdy programista powinien zamieniać pary raz dziennie; połowa osób zamienia się na początku dnia, połowa osób zamienia się po obiedzie: z powodu czynników zewnętrznych, takich jak spotkania, święta itp., większość ludzi ma tendencję do zmiany czasów wymiany raz lub dwa razy w tygodniu, tak że konfiguracje par rozprowadzają się dość równomiernie w całym zespole.

Jednym z powodów częstej zamiany jest to, że wiedza jest szybko i równomiernie rozpowszechniana w zespole, zamiast posiadania określonych umiejętności i wiedzy skoncentrowanych na konkretnych osobach - co oznacza, że praca może przebiegać bezproblemowo, jeśli ludzie będą nieobecni lub opuszczą firmę. Kolejnym uzasadnieniem, które jest swego rodzaju konsekwencją dogmatu dotyczącego samego programowania par, jest to, że za każdym razem, gdy ktoś cię zamienia, dostaje nową recenzję kodu świeżą parą oczu, więc może to tylko poprawić jakość kodu.

Oba twierdzenia brzmią rozsądnie; z punktu widzenia zarządzania brzmi to tak, jakbyś miał wzrost zarówno stabilności, jak i jakości, i jako takie częste zamiany są prawie standardową teorią w większości książek Agile / XP , na które patrzyłem.

Tak więc, kiedy faktycznie zostaną wprowadzone w życie, co ludzie myślą o zamianie par

Punkt widzenia programisty?
Punkt widzenia menedżera?

Co powinno określić, kiedy ktoś zamieni się z / na parę?

agile pair-programming

Czy to to samo co „Programowanie parowe”?

— Robert Harvey

@Robert Harvey - Cóż, jest to jeden aspekt programowania par. Gdy zespół zdecyduje, że zamierza programować w parach (przez pewną część swojego dnia roboczego), musi zdecydować, jak ustawić programistów w pary, tj. Kiedy jeden programista powinien opuścić parę (inny powinien dołączyć w tym samym czasie ). To jest „Wymiana par”.

+1 za świetne pytanie. Niestety, myślę, że trudno jest znaleźć sklep, który regularnie wykonuje parowanie, a tym bardziej na tyle, by mieć dane o zamianie par. Mam nadzieję, że się mylę i otrzymujesz dobre odpowiedzi, jestem bardzo zainteresowany usłyszeniem niektórych.

— Jesse McCulloch

Osobiście uważam, że zamiana par jest bardzo rozpraszająca. Próba radzenia sobie z tak wieloma różnymi osobowościami i poziomami umiejętności w tak bliskich dzielnicach spowodowałaby zbyt dużo dysonansu poznawczego.

— Robert Harvey

@Jesse McCulloch - Pracuję w miejscu, w którym sparowane są tylko programy i wymieniane się, tak jak mówią książki. Pracowałem również w środowisku solo, więc mam dość dobre spojrzenie na kontrast. Chciałbym jednak usłyszeć opinie innych ludzi, ponieważ chciałbym sprawdzić, czy pasują one do moich, nie wpływając na nie zbyt mocno.

Odpowiedzi:

Programowanie par jest trudne.

Jest to trudne, ponieważ działa najlepiej, gdy 2 zaangażowane osoby są na poziomie umiejętności, co może być trudne w niektórych środowiskach pracy. Wymienianie może być trudniejsze, ponieważ musisz znaleźć kogoś o odpowiednim poziomie umiejętności, a następnie przyspieszyć bieżący problem. Korzyścią jest to, że więcej osób ma kontakt z dowolnym fragmentem kodu, który został sparowany. Powinno to prowadzić mniej razy, gdy kod nie może zostać naprawiony, ponieważ nikt nie wie o nim wystarczająco dużo. Powinno to również propagować własność grupy i zdolność każdego do podjęcia dowolnej pracy.

Odkryłem, że nawet w środowiskach, w których parowanie jest wykonywane, zamiana par nie jest warta kosztów. Może to jednak wynikać z tego, że nasze zadania nigdy nie zajmują więcej niż ~ 1,5 dnia. Okazało się, że ogromną korzyścią z rozkładania zadań jest nie większa niż ~ 1,5 dnia pracy. Zamiana par może być bardziej sensowna w kontekście dłuższych zadań.

— dietbuddha
źródło

Osobiście lubię łączyć się z ludźmi na wszystkich poziomach. Czasami się uczę, czasem uczę, a czasem po prostu załatwiamy sprawy. Ale uczenie się i nauczanie budują długoterminowy potencjał zespołu, który moim zdaniem jest równie ważny, jak sprawdzanie funkcji.

— William Pietri,

możesz tak myśleć, ale kierownik projektu, który widzi, że jego termin wyparowuje, gdy twoja wiedza przyzwyczaja się do szkolenia ludzi na czas, a nie do wypuszczania kodu tak szybko, jak tylko możesz, nie byłby w stanie się zgodzić. W ten sposób działa większość projektów, po prostu nie ma czasu, aby szkolić ludzi, aby mieli umiejętności potrzebne do wykonywania pracy, aby juniorzy pozostali wiszący, co jest dobre tylko do wzięcia na siebie winy za przekroczenie budżetu.

— jwenting

@William Pietri: Z mojego doświadczenia wynika, że parowanie nie jest dobrym formatem do nauczania. Nie mam problemu z zabraniem kogoś i przeprowadzeniem go przez kod, aby wyjaśnić mu, co się dzieje. To jednak nie jest programowanie parami.

— dietbuddha,

@jwenting: Jeśli mówisz, że programowanie w parach nie zadziała dobrze w sklepach, które skupiają się na bzdurnych terminach nad jakością i zrównoważonym rozwojem, nie twierdzę. Moja wskazówka: pracuj gdzieś, co nie jest szalone.

— William Pietri,

@dietbuddha: Działa dla mnie! Najszybszym sposobem na naukę nowego języka, frameworku lub biblioteki jest sparowanie się z ludźmi, którzy ją dobrze znają. Nie znam lepszego sposobu na przyspieszenie nooba niż parowanie. Np. To podejście do doświadczenia: slesinsky.org/brian/code/starting_xp.html

— William Pietri

Jestem zarówno programistą, jak i menedżerem. Oto moje zdanie:

Regularna wymiana jest świetna. Preferuję zamianę 2-4 razy dziennie, co jest tak szybkie, jak myślę, że możesz. Dla nas dzieje się tak w naturalnych momentach przełomowych: zazwyczaj lunch i popołudnie. Zmiana każdego dnia lub dwóch jest prawdopodobnie w porządku, ale martwiłbym się, że pójdę o wiele dłużej. (Słyszałem o zamianie jednego miejsca tak rzadko, jak co sześć tygodni, co moim zdaniem jest szalone; po tak długim czasie razem będziesz gotowy dźgnąć świętego.)

Jako programista uwielbiam to, ponieważ dostaję nowe perspektywy, sprawdzam inne obszary kodu i mogę albo trzymać się czegoś lub przejść od czegoś, co wolę. Niedawno przeszedłem z kodowania solo do parowania i jestem podekscytowany: uczę się więcej, bawię się lepiej i robię więcej.

Jako menedżer uważam, że jest świetny, ponieważ rozwiązuje wiele problemów związanych z ciężarówkami i wąskim gardłem. Np. W ten weekend biorę długi weekend na ślub przyjaciela i wcale się nie martwię: nad wszystkim, nad czym pracowałem, pracowały również inne osoby. Myślę też, że to naprawdę pomaga członkom zespołu doceniać swoje mocne i słabe strony oraz zachęcać do wspólnego posiadania kodu.

Jeśli chodzi o to, kto pozostaje przy bieżącej pracy, mam wrażenie, że zależy to głównie od zaangażowanych osób. Czasami chcesz coś przejrzeć, a czasem jesteś gotowy na zmianę. Czasami również wymieniamy się doświadczeniami, aby ktoś mógł dowiedzieć się czegoś, co ich interesuje. Staramy się, aby nasze jednostki pracy były dość małe (0,5-2,0 par dni), więc nie jest to wielka sprawa, jednak zamiana idzie .

— William Pietri
źródło

Dla mnie muszę powiedzieć, że zamiana jest dobra tylko wtedy, gdy: a) nie lubię kodować z facetem, z którym koduję, b) nie podoba mi się historia, nad którą pracuję (jak naprawianie linek stary błąd pamięci). W przeciwnym razie chcę pozostać od początku do końca. Osobiście uważam, że zamiana par zmniejsza jakość kodu, ponieważ dobry kod powinien mieć jedną wyraźną wizję, im więcej ludzi, którzy pracują nad jedną częścią, tym bardziej zaśmiecona staje się wizja. Jeśli chodzi o dzielenie się wiedzą, powiedziałbym, że większość ludzi ma pojęcie o tym, co się dzieje, ale nikt tak naprawdę nic nie rozumie.

@B Tyler - Myślę, że podstawa kodu jest wspólnym dziełem intelektualnym, więc musisz mieć jasną wizję, która jest również wspólną wizją. Właśnie dlatego uważam, że ważna jest zamiana: potrzeba dużo interakcji i dyskusji, aby wypracować solidne wspólne podejście.

— William Pietri,

Okie, oto odpowiedź od samozwańczego pragmatycznego programisty agile / xp. Programuję w parach od ponad dwóch lat. Jeśli programowanie par jest dobre, często zamieniaj pary (najlepiej co dwie godziny, jeśli nie co pół dnia). W naszym biurze staramy się wymieniać pary codziennie (zwykle) lub co dwa dni (w gorszym przypadku). Robienie tego samo w sobie może dać nam dużą pewność co do jakości kodu , który popełniamy, oraz uczenia się lub odbierania, które mamy przy każdej rotacji pary (wiemy, że weryfikacja kodu jest dobra, im więcej, tym lepiej i im wcześniej tym lepiej. To właśnie osiąga „programowanie par, w tym praktyka zamiany par” ).

Dlaczego nie zmieniamy par co dwie / cztery godziny? Właściwie byłem w zespołach, które też to ćwiczą. Z pewnością jest zdecydowanie chłodniejszy i bardziej produktywny. Ale tutaj jest umowa, przedział czasowy zamiany par nie powinien być regułą, powinien zdarzyć się sam; tylko wtedy kierownik lub firma mogą zobaczyć korzyści.

Byłem tego świadkiem i doświadczyłem. Jestem teraz jego ewangelistą. To nie teoria. Raczej jest to całkowicie pragmatyczne :) Szczęśliwe parowanie ping-ponga i zamiana par.

— karthiks
źródło

Niestety, jestem teraz całkowicie przekonany, że programowanie w parach jest ogólnie złym pomysłem; częste zamiany par w programowaniu par tylko pogarszają sytuację. Słyszałem całą teorię i dużo ją wypróbowałem w praktyce i po prostu uważam, że jest niewiarygodnie nieefektywna, o wiele bardziej nudna i frustrująca niż programowanie solo i skutkuje obniżeniem jakości kodu.