Czy kiedykolwiek stosowaliście pair programming?

Hej, z czystej ciekawości, czy poza rozmowami rekrutacyjnymi zdarzało Wam się zawodowo uprawiać Pair programming? Z jednej strony jest sporo zalet takiego rozwiązania. Z drugiej jest to marnotrastwo zasobów i zastanawiam się czy w praktyce takie rowiązanie ma czasami zasosowanie?

Tak, trudno w ogóle nazwać to marnotrawieniem zasobów, dużo więcej marnotrawi się na zespołowych spotkaniach po nic, a tutaj mamy lepszy design, instant review, rozpropagowanie wiedzy etc. Już nawet pair programming z rubber duck prowadzi do znajdowania wielu błędów w rozumowaniu, a tu masz kaczkę, która odpowiada i zna się na programowaniu.

bakunet napisał(a):

Z drugiej jest to marnotrastwo zasobów i zastanawiam się czy w praktyce takie rowiązanie ma czasami zasosowanie?

Różnica jest taka jak pomiędzy czytaniem artykułu na zadany temat poddanego peer-review a czytaniem wątku na zadany temat na którymkolwiek z forów. Oba mogą nieść przydatne informacje ale uczciwie rzecz biorąc w profesjonalnej dyskusji unika się powoływania na ten drugi sposób.

Teoretycznie co dwie głowy to nie jedna, sam raz rozwiązywałem jedne problem i rano się budzę i sobie uświadomiłem, że błąd zrobiłem, było za późno bo wysłałem już rozwiązanie, a tak jak są dwie osoby, to drua widzi bardziej wysokopoziomowo, bo pierwsza na szczególach się skupia, ale też też też.

Ja tak pracuję praktycznie codziennie, czasem nawet w trzy osoby.

Nie nazwałbym tego marnowaniem zasobów. W taki sam sposób jak dwa koła w rowerze ktoś by nazwał "marnowaniem zasobów", bo przecież są monocykle. Jedyne osoby które mówią że to jest "marnowanie", to te które tego nigdy nie spróbowały.

Popularne przekonanie jest takie że jeśli dwie osoby pracują razem, to oznacza to że dostarczają dwa razy wolniej. Ale to po prostu nie jest prawda. Nigdy nie widziałem spadku szybkości dowożenia kiedy osoby się łączyły w pary.

Żeby było faktycznie marnotractwo, to musiałoby dojść do sytuacji kiedy jedna osoba w parze nic nie robi (tzn nie myśli nad czymś , nie mówi , nie rozwiązuje ,nie planuje) - po prostu siedzi i się nudzi, wtedy faktycznie byłoby to marnotractwo. Ale tak nie jest - osoba która akurat nie klika zawsze coś robi, coś co ta druga osoba musiałaby zrobić, zastanowić się , wymyślić ,spytać, znaleźć jakiś edge case, jakieś rozwiązanie.

Także to nie jest żadne marnotrawstwo.

Tak, zdarzyło się kilka razy. Bardzo fajna sprawa, dużo szybciej się podejmuje decyzje, wpada na możliwe edge case'y, code review na bieżąco więc ciężko popełnić literówkę czy błąd logiczny, można się czegoś nauczyć choćby w kwestii obsługi IDE bo każdy robi te same rzeczy w różny sposób. I ogólnie przyjemniej się pracuje bo wiadomo że od razu się też pogada. Odpowiedzialność za kod spada na dwie osoby więc też trochę mniejsza presja.
Czy dwie osoby są w stanie w ten sposób wypracować tyle co osobno - raczej nie, choć wymusza to że skupiamy się tylko na kodzie i nie rozpraszamy się. Zmniejsza to też potrzebę przerw na kawę na pogaduchy w kuchni. Ważne moim zdaniem żeby osoby tak pracujące były w przyjaznych relacjach.
No i raczej niewykonalne w pracy zdalnej - próbowałem ale było to raczej na zasadzie że jedna osoba pisze a druga obserwuje, nie da się tak łatwo przejąć sterów.

obscurity napisał(a):

Czy dwie osoby są w stanie w ten sposób wypracować tyle co osobno - raczej nie, choć wymusza to że skupiamy się tylko na kodzie i nie rozpraszamy się.

No oczywiście że są, i nawet więcej.

a konkretnie jakie zalety? ja widzę same wady

IMO zależy są miejsca gdzie jest to pożyteczne i fajne a są miejsca gdzie to jest marnotrawienie zasobów i próba malowania obrazu zamiast napisani kodu. Jak rozwiązujemy trudny Bug który jest nieoczywisty, projekt ma duża liczbę requestow i kod musi być zoptymalizowany lub featur jest trudny algorytmicznie/matematycznie to tak daje benefit. Ale jak widze 3 gości spuszczajacych się nad designem kodu w korpo systemie ktory ma pare tysięcy użytkowników dziennie to mi sie śmiać chce i wtedy jest o marnowanie zasobów xD.

Riddle napisał(a):

obscurity napisał(a):

Czy dwie osoby są w stanie w ten sposób wypracować tyle co osobno - raczej nie, choć wymusza to że skupiamy się tylko na kodzie i nie rozpraszamy się.

No oczywiście że są, i nawet więcej.

Oczywiście, że mniej. Nie jesteś w stanie dostarczyć więcej jeśli tylko jedna osoba pisze itd.

1. masz trudny bug - dwie osoby sprawdzające różne możliwości = szybciej go znajdziesz więc pair programming nie ma sensu zazwyczaj (są wyjątki oczywiście)
2. masz po prostu do napisania kod, np. musisz zajrzeć do dokumentacji api itd. = co ci po tym, że dwie osoby będą patrzeć na oczywiste klasy i dojdą do takich samych wniosków?

Schadoow napisał(a):

Ale jak widze 3 gości spuszczajacych się nad designem kodu w korpo systemie ktory ma pare tysięcy użytkowników dziennie to mi sie śmiać chce i wtedy jest o marnowanie zasobów xD.

To jest prawda.

Tylko ze to nie jest argument przeciwko PP tylko przeciwko niestosowaniu YAGNI i przeciwko przedwczesnej optymalizacji.

W poprawnym zespole, jak masz bardzo małą apke, to trzech gości siada, robi Pair Programming przez 1-2h, piszą całą aplikacje, i zostawiają - idą do następnych zadań. To "spuszczanie się" o którym mówisz to faktycznie jest słabe, nie powinno do niego dojść, ale to nie jest przez PP, tylko przez jakiś niezdrowy pedantyzm. W Pair Programming scenariusz jest prosty: siadasz do zadania (w dwie osoby), robisz to co jest absolutnie konieczne, i tyle.

Temat szeroki, wiele zależy, a odpowiedzi na zasadzie - "tak"/"nie", klasyka, smutne.

Szkoda że nie ma nic nt. zbyt częstej potrzeby łączenia w pary, nawet do prostych rzeczy i/lub rozwiązywania problemów za kogoś

ewentualnie gdy jest duża różnica w doświadczeniu, więc ciężko zrozumieć się w parze

bakunet napisał(a):

Hej, z czystej ciekawości, czy poza rozmowami rekrutacyjnymi zdarzało Wam się zawodowo uprawiać Pair programming?

Tak.

Z drugiej jest to marnotrastwo zasobów i

Jakich konkretnie?

zastanawiam się czy w praktyce takie rowiązanie ma czasami zasosowanie?

Tak.

obscurity napisał(a):

No i raczej niewykonalne w pracy zdalnej - próbowałem ale było to raczej na zasadzie że jedna osoba pisze a druga obserwuje, nie da się tak łatwo przejąć sterów.

No bez przesady, przełączenie osoby udostępniającej ekran to 10 sekund.
No chyba, ze na żywo odbywa się to przy udziale pięści, to wtedy faktycznie zdalnie trudniej. :P

Schadoow napisał(a):

Ale jak widze 3 gości spuszczajacych się nad designem kodu w korpo systemie ktory ma pare tysięcy użytkowników dziennie to mi sie śmiać chce i wtedy jest o marnowanie zasobów xD.

Jakie ma znaczenie liczba użytkowników?
Ja mam w pracy bardzo dużo systemów, które nie mają żadnych użytkowników. Takich nie trzeba projektować?

anonimowy napisał(a):

Oczywiście, że mniej. Nie jesteś w stanie dostarczyć więcej jeśli tylko jedna osoba pisze itd.

Linijek kodu zapewne nie, działających ficzerów tak.

Na szczęście na tym forum nie ma crudowców, którym płacą od napisanej linijki.

1. masz trudny bug - dwie osoby sprawdzające różne możliwości = szybciej go znajdziesz więc pair programming nie ma sensu zazwyczaj (są wyjątki oczywiście)

Niezupełnie, bo sprawdzając niezależnie niekoniecznie będą sprawdzały różne możliwości. :)
Do tego sprawdzając razem, jedna może zauważyć coś, co druga przeocza.

2. masz po prostu do napisania kod, np. musisz zajrzeć do dokumentacji api itd. = co ci po tym, że dwie osoby będą patrzeć na oczywiste klasy i dojdą do takich samych wniosków?

Co jeśli nie ma dokumentacji API?

Tak, pracowałem.
Tak staram się też tak pracować bo to bardzo rozwija zespół.
Polecam CodeWithMe od JetBrains do tego, nie trzeba udostępniać pulpitów itp. No i w ogóle warto pomyśleć, czemu takie narzędzia powstają, skoro programowanie w parach to strata czasu.

somekind napisał(a):

Co jeśli nie ma dokumentacji API?

No nie wiem, korzystasz np. z jakiejś klasy z jakiejś biblioteki to wchodzisz do jej źródeł żeby zobaczyć jaką metodę musisz nadpisać żeby dodać porządane zachowanie. Jak druga osoba mi to niby przyśpieszy?

I co robicie żeby nadążyć za drugą osobą? Przecież, niektórzy ludzie tak szybko przełączają okna, pliki itd. że druga osoba nie jest w stanie się zorientować o co chodzi. Trzeba jej tłumaczyć więc automatycznie zwalniamy (coś jak z czytaniem na głos a czytaniem w myślach)

Są pewne wady.
To jest okropnie męczące. Po dwugodzinnej sesji, właściwie mogę zamknąć komputer, bo i tak nic więcej oprócz odpowiadania na maile tego dnia nie zrobię.
Jeśli druga osoba ma niekompatybilne nastawienie, nie jest łatwo. W pracy programisty nie musisz się z wszystkimi lubić, aby pracować wydajnie, w pair programming to konieczność. Więc po prostu nie we wszystkich zespołach zadziała.

Też polecam CodeWithMe.

Wiedzę że jest ogromne niezrozumienie w tym wątku tego jak Pair Programming działa i powinien działać. Obserwuje tutaj: garstkę ludzi którzy faktycznie to rozumieją; sporą część ludzi którzy nigdy tego nie próbowali i trzymają pewne niepoprawne przekonania; oraz również mała cześć ludzi która to spróbowała, ale nie tak jak się to powinno robić, i teraz są zrażeni.

Pomyślałem więc, że napiszę dużą odpowiedź składającą się z trzech części, czyli: błędne przekonania tych którzy tego nie próbowali, tego jak nie powinno się stosować pair programming, postaram się potem wypisać zalety takiego podejścia, oraz jego wady - bo wady oczywiście są, tylko że nie takie jakie są tutaj wymienione.

Część pierwsza - błędne przekonania

• Marnowanie zasobów (czasu ludzkiego) - to jest jak na razie największe błędne przekonanie które występuje w tym wątku, więc może zacznę od niego. Weźmy pod lupę zespół, który ma 5-6 programistów i popatrzmy na jednego programistę. Załóżmy że spędza 30 minut na daily, godzinę z hakiem na jakieś pozostałe spotkania i 45 minut na obiad i 15 minut na youtube'a, i odejmijmy to. Zostaje około 5h na faktyczną pracę programistyczną (nie ważna jest konkretna ilość, w innych zespołach tej "faktycznej pracy" może być 7h a może być 3h). Jeśli dochodzą jakieś inne rzeczy niezwiązane z programowaniem (tylko np z produktem), jak gadanie z klientem, ustalanie jakichś reguł w firmie, etc. to je również odejmujemy. Interesuje nas teraz ilość czasu spędzona na faktycznym programowaniu (featurach, bugach, deployach, etc.) (np w IDE), weźmy tą liczbę 5h. Dla przykładu, załóżmy też że każdy z tych 5-6 programistów w zespole właśnie tyle czasu spędza na faktycznym programowaniu.

  • Teraz, gdybyśmy się znaleźli w sytuacji, w której praca programisty przypomina fabrykę, a linijki kodu oznaczają produkt, to faktycznie oponenci Pair Programming mieliby racje. Gdyby było tak że programista dajmy na to pisze 100 linijek w godzinę, to znaczy to 200 linijek na 2h, 300 linijek na 3h, 400 linijek na 4h i tak dalej. Jeśli przyrost linijek byłby liniowy; oraz każda dodatkowa linijka to byłaby jakaś "nowa jednostka" jakości, to wtedy faktycznie Pair Programming byłby marnowaniem zasobów - dwie osoby przy jednej klawiaturze napiszą dwa razy mniej kodu. Znaczyłoby to również to, że taka osoba musiałaby pisać kod ciągle - bez przerw na myślenie, zastanawianie się, obgadanie, analizowanie.

  • Jak to wygląda na prawdę:

    • Pomińmy wszystkie nie programistyczne rzeczy: spotkania, daily, calle, obiady, wyjścia na fajkę czy do kuchni, maile, story pointy, jiry, taski, PR'y. Weźmy pod lupę tylko czas na faktyczne programowanie. Z czego to się składa? Jeśli składałoby się w 100% z pisania kodu, to faktycznie - znowu - pair programming nie ma sensu; ale tak nie jest. Na tworzenie feature'ów składa się:
      • Pisanie kodu
      • Identyfikacja i usuwanie niepotrzebnego już kodu
      • Projektowanie rozwiązań
      • Debugowanie
      • Projektowanie i pisanie testów
      • Kompilowanie i budowanie
      • Przeklikiwanie się przez UI
      • Analiza aktualnego rozwiązania
      • Wymyślenie nowych potencjalnych rozwiązań
      • Czytanie kodu w poszukiwaniu błędów
      • Korzystanie z kontroli wersji żeby przeanazlizować aktualny stan kodu
      • Google'owanie w poszukiwaniu nowych rozwiązań i odpowiedzi
      • Rozmawianie z innymi członkami nt "czemu tu jest tak zrobione"

    Wszystkie te rzeczy (oprócz faktycznego klikania w klawiaturę), można spokojnie robić w dwie osoby, i połączenie dwójki ludzi do tego nie jest marnowaniem czegokolwiek. Programiści nie piszą kodu ciągle - popatrzcie kiedyś na swoją pracę, zróbcie taki auto-eksperyment. Zobaczycie wtedy że faktycznego pisania kodu jest mało, a więcej jest analizy, myślenia, proponowania rozwiązań, prób i błędów. Nie ma programisty który kiedy usłyszy jakiś problem, napisze na raz 50 linijek od czapy bez zastanowienia się jak automat, ludzie nie tak tworzą kod; tworzą go powoli, metodycznie, krok po kroku, zastanawiając się nad całością jak i nad częściami. Robiąc to w dwie osoby nic nie tracimi.

    • Błędne przekonanie #0 - output kodu/faktyczna ilość kodu która powstaje, jest mniejsza z pair programming - jak mówiłem, to po prostu nie jest prawda. Ilość kodu jaka powstaje jest podobna; tzn. może powinienem powiedzieć że ilość dostarczonych feature'ów i bugfixów jest taka sama, bo irocznicznie linijek jest mniej - często w dwie osoby wychodzą lepsze rozwiązania, które nierzadko mają mniejszą objętość linijkową, ale tak czy tak dostarczają taką samą wartość. Poza tym, jest ogromna ilośc danych i statystyk prównująca pracę samemu i pracę w parach, i nie wynika z nich żeby praca w parach była wolniejsza. To jest to samo dziwne przekonanie, jak pierwszy raz się dowiadujemy że 0⁰ to jest 1. Wydaje się dziwne i błędne, ale tak jest. Podobnie jest z Pair Programming - wydaje się że traci się czas, i robi się rzeczy dwa razy wolniej, ale kiedy tego spróbujesz to zauważasz że nic nie tracisz.
• Nie lubią partnera - każdy w zespole ma fajniejszych ludzi i mniej fajnych, takich których lubi bardzo, i takich których lubi mniej. Kiedy większość ludzi pierwszy raz słyszy pojęcie "Pair programming", często pojawiają im się negatywne myśli w głowie - nie z powodu programowania w parach - tylko przez wizję tego, że ich szef ich usadzi z osobą której nie lubią. Na to się składają dwa pomniejsze błędne przekonania:
  • Błędne przekonanie #1 - to nie ja ustalam kiedy robię PP, tylko szef/lead/terminarz. To jest zupełnie błędne przekonanie, bo to programiści sami adhocowo ustalają kiedy i z kim pracują, jest to bardzo luźne i nie podlega regulacjom. Jeśli nie masz ochoty z kimś parować - to po prostu tego nie robisz, albo robisz to bardzo rzadko lub programujecie w trzy osoby, z kimś kogo oboje lubicie.
  • Błędne przekonanie #2 - nie chcę spędzić całego dnia z kimś kto mi patrzy przez ramię. To jest kolejne błędne założenie, bo pair programować nie trzeba w cale cały dzień, pół dnia czy nawet na długość taska! Możecie parować 5 minut, 10 minut, 20 minut czy cały tydzień - ile chcecie. To jest normalne że ludzie zmieniają pary nawet w połowie taska. To nie jest żaden committment, że jeśli zaczniesz z kimś task (który okaże się że trwa 2 tygodnie), to musisz z tym kimś parować przez 2 tygodnie. Możesz odejść bez słowa jak tylko Ci się podoba.
  • Błędne przekonanie #3 - nie mogę pracować z niekompatybilnym partnerem. Jeśli faktycznie taka sytuacja zachodzi, że w jakiś sposób się nie dogrywanie, to jest to spory problem sam w sobie, i tak czy tak go trzeba rozwiązać, jeśli macie pracować w jednym zespole - pair programming jest do tego świetny, wtedy powinniście wziąć trzecią osobę, jakiegoś seniora który będzie trochę programowała, ale będzie też mentorem - wygładzi wszystkie nierówności; i ostatecznie doprowadzi do sytuacji w którym będziecie mogli pracować razem. To jest oczywiście bardzo dobry i pożądany wynik.
• Chcieliby parować się z seniorami, a nie juniorami
  • Błędne przekonanie #4 - W pary łączą się tylko osoby, które potrzebują pomocy oraz * Dwóch juniorów zrobi słaby kod* - to też jest kolejne częste przekonanie, takie że najlepsze osoby w zespole często pracują same; a w pary łączą się tylko stażyści/słabsze osoby. To oczywiście nie jest prawda; w pary w takim zespole łączą się wszyscy. Sporo ludzi, kiedy słyszy o pair programming, ma takie przekonanie że "tylko wtedy łączymy się w pary, jeśli mamy jakiś problem którego nie możemy sami rozwiązać" i w momencie w którym ten problem jest naprawiony, i już możemy dalej działać sami, to wtedy się znowu rozdzielamy. To nie jest prawda - w Pair Programming ludzie pracują w parach ciągle, nawet nad trywialnymi taskami.
  • Błędne przekonanie #5 - często bedę parowany z innym juniorem, i to nie ma sensu. Otóż jest dokładnie odwrotnie. Dwóch stażystów/internów nigdy nie łączy się w pary, absolutnie i bezwzględnie. Byłoby to bardzo niemądre z wielu powodów, głównym jest to że dwóch juniorów pracujących razem mogłoby sobie nawzajem utrwalać błędy. W pary łączymy tylko: albo dwóch seniorow/najlepszych programistów; albo seniora i juniora; ewentualnie seniora i mida. Nigdy nie powstaje para junior+junior.
• Kłótnie i nieporozumienia
  • Błędne przekonanie #6 - co jeśli osoba A znajdzie jedno rozwiązanie, a osoba B znajdzie inne i się pokłócimy. Tutaj chciałbym z gruntu powiedzieć - to się zdarza bardzo rzadko, kiedy ludzie parują bardzo często mają podobne opinie i się zgadzają nt tego jak rozwiązanie powinno wyglądać. Są czasem różne opinie nt tego jak finalny kod powinien wyglądać, ale to się zdarza może raz na miesiąc. Wtedy wystarczy szybko spytać kogoś obok o trzecią opinię, i po prostu w ten sposób rozstrzygnąć temat. Poza tym pamiętajmy, że nie chodzi o to żeby wprowadzić moje rozwiązanie, tylko dobre rozwiązanie.
  • Błędne przekonanie #7 - ja lubię mój kod takim jaki jest, i nie chcę żeby ktoś go zmienia. Tutaj mamy do czynienia z przekonaniem osoby która nigdy nie stosowała Pair Programming, bo każdy kogo znam po praktycznie tygodniu przestał mieć takie przekonanie. Jeśli codziennie parujesz z każdym z zespołu, to taki koncept jak "mój kod" po prostu przestaje mieć sens i znaczenie. Staje się to oczywiste, że cały kolektywny program to jest wynik ewolucji i pracy wielu osób, bez silosów i bez kawałków: "to jest mój kawałek, a to jest kawałek heńka".
  • Błędne przekonanie #8 - mamy różne style pracy, ja chcę pracować po swojemu. To jest faktycznie duży problem - przez pierwsze kilka razy jak z kimś parujemy. Potem, zauważyłem, uczymy się stylów pracy osób z którymi parujemy, i zaczynamy dostrzegać w nich wady i zalety, rozumiemy czemu mają taki styl, jak również oni uczą się naszego stylu. Staramy się potem wziąć dobre rzeczy z obu stylów, i starać się wyeliminować te złe. Oczywiście znowu mamy knowledge sharing, bo możemy podłapać dobre cechy ze stylu pracy kogoś innego i odwrotnie.
• Przesadny pedantyzm nad kodem
  • Błędne przekonanie #9 - dwoje ludzi nad kodem będzie spędzało za dużo czasu próbując go uładnić. Tutaj znowu to nie ma za wiele wspólnego z programowaniem - jeśli osoba pisze sama, to również może być zbyt pedantyczna. Wystarczy żeby dwie osoby miały z tyłu głowy taki fakt: "znajdźmy wspólne rozwiązanie, i wypchnijmy". Obie przecież chcą skończyć szybko.
• Jedna osoba nic nie robi
  • Błędne przekonanie #10 - jedna osoba pisze, druga się nudzi; ewentualnie znane jako czekanie na swoją kolej na pisanie - to w ogóle nie tak wygląda, jest to zupełnie błędne przekonanie. Jeśli stosuje się pair programming chociaż kilka razy, to zaczynasz zauważać że osoba która pisze właściwie nie za bardzo ma siły mentalne żeby zastanawiać się nad rozwiązaniem - to osoba która siedzi z boku wymyśla cały design i opisuje go, a osoba która siedzi przy klawiaturze go tylko zapisuje - przelewa na papier design osoby która siedzi obok. Tutaj chodzi o to że łatwiej jest zaprojektować system, jeśli możesz po prostu wypuścić pomysły z głowy, i nie martwić się pisaniem - bo robi to druga osoba. Potem zmiana, i ta pierwsza osoba zaczyna designing i wtedy ta druga zamienia się w "tego piszącego". Oczywiście oboje powinni designować system, ale często ta która pisze skupia sie na pisaniu, a ta druga osoba w parze to czyta, analizuje, designuje, daje rady, znajduje błędy, literówki, edge case'y. Ja czasem to nazywam "brain and the hand", czyli osoba która siedzi z boku to jest "brain", która projektuje rzeczy, a "hand" jest przelewa na klawiaturę. Po minucie czy dwóch następuje zmiana.
• Chciałbym pomocy też z innymi rzeczami
  • Błędne przekonanie #11 - pair programming można stosować tylko do programowania, to również jest nie prawda. Jesli dwie osoby są razem w parze, to robia razem wszystko co jest związen z projektem, również rozmawianie z klientami, ustalanie wymagań, i wszystko co jest potrzebne do stworzenia produktu - nie tylko programowanie.

Poza tym, jeszcze jest socjologiczny powód - ludzie po prostu nie lubią wychodzić ze swojej strefy komfrotu. Ktoś pracował jako programista samemu 5-10 lat, i teraz miałby pracować z kimś innym? To jest wyjście ze strefy komfortu, zmiana przyzwyczajeń, a ludzie tego nie lubią robić. Tylko znowu, to nie jest argument przeciwko PP, tylko przeciwko zmianom przyzwyczajeń.

Część druga - zalety pair programming

O zaletach można mówić długo, ale takie najważniejsze dla mnie to:

• Jeśli kod piszą dwie osoby, to można od razu mergować taki kod, bo nie ma potrzeby na code review. Robiliśmy na początku PR'y, ale nikt nigdy na nich nic nie znajdował, więc uznaliśmy że gra nie warta świeczki - od razu można mergować.
• Wymiana wiedzy i informacji - jeśli dwie osoby pracują nad jednym zadaniem, to siłą rzeczy wymieniają się wiedzą informacjami. Zawsze jest conajmniej jeden senior w parze, więc taki knowledge share jest bardzo wartościowy i bardzo efektywny.
• Code review normalnie trwa 10-15 minut, max. 30. Kiedy robimy pair programming, i dostarczenie taska trwa np 8h, to review nad tym taskiem trwa 8h - czyli tyle ile druga osoba na niego patrzyła. To jest kolejny powód czemu późniejsze code review już nie jest potrzebne - review zostało zrobione continuuously podczas pisania.
• Brak silosów i one-man-army; jeśli każdy task jest dowożony zawsze przez dwie osoby, to nie ma osoba która znałaby task którego inni nie znają - wszystko się rozkłada, co ma ogromne zalety.

Część trzecia - faktyczne wady pair programming

To z czym się muszę zgodzić, z @ArchitektSpaghetti to faktycznie pair programming jest bardziej męczące niż pisanie samemu; ale to też nie jest czarno białe - otóż jak piszemy sami, to dostarczamy mniej rozwiązań i te rozwiązania są mniejszej jakości. Kiedy robimy PP, to dostarczamy w tym samym czasie dużo więcej rozwiązań i często więcej jakości - więcej outputu w tym samym czasie; ergo robimy więcej pracy. Siłą rzeczy, skoro robimy większą i trudniejszą pracę, to jesteśmy bardziej zmęczeni, ale potem mamy więcej czasu żeby odpocząć na obiedzie, w game roomie, czy wstać od kompa i coś porobić. Poza tym, nie jest to żadna nowość; bo praktycznie każda metodyka z Extreme Programming jest męcząca.

Druga rzecz, która faktycznie jest challengem (trochę), to jest pracowanie w taki sposób zdalnie. Pair programming kiedy siedzi się obok siebie z jednym komputerem i jedną klawiaturą, to jest coś co ja uważam za niesamowity sposób na to żeby dostarczyć szybko coś bardzo dobrego. Jeśli obaj pracujemy zdalnie, to dochodzą do tego dodatkowe komplikacje, jak konieczność użycia własnie CodeWithMe, co nie jest idealne. Warto tylko dodać, że to nie jest argument przeciwko PP; tylko przeciwko pracy zdalnej.

Część czwarta - złe zaznajomienie z konceptem

To jest kolejny problem który widzę często w IT. Sporo tematów w IT jest bardzo skomplikowane, jak np SOLID, wzorce, TDD, MVC, Agile i masa innych. To są tematy na które trzeba spędzić miesiące jak nie lata żeby je zrozumieć, do tego zalicza się również Pair Programming.

Jeśli mamy nowicjusza, kogoś kto się nie zetknął z tymi konceptami nigdy, to odpowiednim sposobem żeby go wprowadzić w temat, byłoby kilkugodzinna prezentacja i wyjaśnienie tego: czym jest Pair Programming, skąd się wzięło, czemu go stosujemy, w jakich kontekstach ma znaczenie, po co go stosujemy, i czemu działa. Ale niestety tak się dzieje, kiedy nowicjusz pyta kogoś "Co to jest Pair Programming" to odpowiedź zwykle brzmi "to po prostu ludzie piszą razem kod na jednej klawiaturze cały dzień".

No to jeśli ktoś w taki sposób dowie się o Pair Programming, to nic dziwnego że od razu odrzuci taki pomysł bez dodatkowych informacji. Także odpowiednim podejściem tutaj było odpowiednie zaznajomienie kogoś z tematem. Podobny problem ma TDD, kiedy zamiast opisać cały proces, wszystkie zalety i skąd to się wzięło, często jedynym opisem jest "TDD to pisanie testu przed kodem", - ten same efekt - automatyczne odrzucenie pomysłu; ale to w sumie nie jest wina osoby która odrzuca ten pomysł, tylko tego kto w tak szczątkowy sposób opisał dyscyplinę.

Zakończenie

Do wszystkich którzy nie są poplecznikami PP: @gajusz800 , @Miang i wszystkich którym nie podoba się ten pomysł:

• Też kiedyś byłem w takim miejscu, że usłyszałem że niektórzy pracują w dwójkę, i tak samo jak wam, bardzo mi się to nie spodobało. Brzmiało to jak odebranie mojej wolności, jakbym już nie był programistą, tylko klepaczem kodu, który musi się dzielić klawiaturą z kimś obok, i bardzo długo tego nie spróbowałem. Jeśli tak podchodzicie do tematu, że "kod jest mój i tylko mój", i "ja pracuję tak jak lubie i dajcie mi spokój" to faktycznie Pair Programming nie ma sensu. Pytanie się sprowadza do tego - jaki jest wasz cel - jeśli waszym celem jest siedzieć samemu nad klawiaturą i klepać - to proszę bardzo. Ale jeśli waszym celem jest zwiększenie prędkości, dostarczanie feature'ów szybciej, mniej bugów, szybsza naprawa bugów i ogólnie lepsza jakość softu, to Pair Programming jest warty uwagi. Oddajecie trochę komfortu (na początku, bo potem to znika), za zwiększenie jakości waszej pracy.

• Dodam też że raczej nie przekonają nikogo argumenty tutaj; to że taka metodyka jest wartościowa i warta spróbowania, można się przekonać dopiero jak się jej spróbuje - tylko oczywiście z kimś kto wie co robi. Podobnie jest z pisaniem testów - tutaj też wielu ludzi mówi na początku: "cooooooo, połowę mojego czasu miałbym spędzić na pisanie testów?", oraz "marnotractwo czasu" i "napiszę dwa razy mniej kodu".

Riddle napisał(a):

Pair programming kiedy siedzi się obok siebie z jednym komputerem i jedną klawiaturą, to jest coś co ja uważam za niesamowity sposób na to żeby dostarczyć szybko coś bardzo dobrego.

W moim przypadku oznaczałoby to natychmiastowe dostarczenie wypowiedzenia. Gdyby ktoś mi kazał tak pracować.

Riddle napisał(a):

Poza tym, jest ogromna ilośc danych i statystyk prównująca pracę samemu i pracę w parach, i nie wynika z nich żeby praca w parach była wolniejsza.

No to wstaw proszę chociaż 5 takich badań

Riddle napisał(a):

Błędne przekonanie #2 - nie chcę spędzić całego dnia z kimś kto mi patrzy przez ramię. To jest kolejne błędne założenie, bo pair programować nie trzeba w cale cały dzień, pół dnia czy nawet na długość taska! Możecie parować 5 minut, 10 minut, 20 minut czy cały tydzień - ile chcecie

Ale gościu, tutaj rozmawiamy o codziennym Pair Programming na dłużej niż 10 minut. Na 10 minut to po prostu szybki call bo ktoś potrzebuje drugiej pary oczu/pomocy i o tym nie dyskutujemy w tym wątku

Na resztę aż szkoda odpowiadać bo widzę powymyślałeś sobie jakieś błędne przekonania o których nikt nie wspominał ani nikt nie uznaje i argumentujesz swoje własne kontrargumenty

anonimowy napisał(a):

No to wstaw proszę chociaż 5 takich badań

Riddle napisał(a):

Błędne przekonanie #2 - nie chcę spędzić całego dnia z kimś kto mi patrzy przez ramię. To jest kolejne błędne założenie, bo pair programować nie trzeba w cale cały dzień, pół dnia czy nawet na długość taska! Możecie parować 5 minut, 10 minut, 20 minut czy cały tydzień - ile chcecie

Ale gościu, tutaj rozmawiamy o codziennym Pair Programming na dłużej niż 10 minut.

Przeczytałeś dokładnie to co napisałem? Sam to zacytowałeś 5 minut, 10 minut, 20 minut czy cały tydzień - ile chcecie.

i w tym wątku wyraźnie widać zalety studiów, stuenci maja doświadczenie z pracą grupową i cwaniaczkami kßórzy se próbują znawsze znaleźć frajera co by za nich robił i się nie nabiorą na kolejną taką akcję ;)

Praktykowałem okazjonalnie w różnych firmach - zwykle na kilka dni max.

1. Bardzo efektywne - w sensie tego co powstaje
2. Ultra męczące psychicznie - napiernicza się kod bez zwyczajowych przestojów, bo (jak w pasjansie) druga osoba zwykle od razu widzi gdzie jest problem.
   ... i po kilku godzinach mózg kondycyjnie wysiada

Trochę inaczej działa pair programming zdalnie - nie zapierdala się tak, bo czasem ktoś się jednak mentalnie wyłącza na chwilę, ale nie jest tak męczący.

PP to dla mnie narzędzie zapierdolu - może mieć czasem uzasadnienie w krytycznych fazach projektu, ale potem musi być odpoczynek.
I najlepiej 2-3 godziny dziennie max.

O wiele bardziej od PP lubię "przekazywanie zadań" - czyli nikt nie kisi branchów, feaczerów za długo - tylko najdalej w drugim dniu pracy przekazuje komuś "pałeczkę".
(ale PMowie strasznie tego nie lubią... bo im marnuje story pointsy).

jeszcze odnośnie opinii ze druga osoba zauważy błedy i nie trzeba będzie potem review czy innego sprawdzania robić.
psychologicznie jest znana taka zależność że trudniej jest zmienić zdanie jak już coś powidziałeś głośno albo się pod tym podpisałeś.
Tu mamy dwie osoby które nawzajem się zgodziły ze sobą że coś jest zrobione jak należy.
Jeżeli jedna z nich następnego dnia stwierdzi że cos jednak jest niewłaściwie, to trudniej będzie jej sie do tego przyznać, a drugiej się przyznać że też tego nie spostrzegła.
I dopiero na produkcji błąd się pokaże w całej okazałości ;)

Nie lubię jakiegokolwie pair programmingu. Narzędzie do zapierdolania i gonienia programistów do ciągłego kodzenia. Okazjonalny jest spoko. Mamy jakiś problem i wtedy wspólna praca z kimś ogarniętym jest fajna. Korzystałem tylko ze zdalnego pair programmingu i natrfiałem na buców, którzy potrafili mieć pretensje, kiedy się o coś ich pytałem. Ze skrajnymi introwertykami też nie było fajnie, bo wtedy oboje siedzieliśmy w ciszy i tylko czasem się odzywaliśmy. Najfajniej było z ziomkiem, który potrafił wykorzystać swój exp i mnie poprowadzić, miałem wtedy kilka miesięcy expa, więc tego typu mentoring podczas pair programmingu był spoko.

Ostatecznie skojarzenia mam negatywne i dużo przyjemniej programuje mi się samemu. Wolę czasem coś przedyskutować na callu, niż siedzieć na nim przez prawie 8h codziennie. Straszna męczarnia dla mnie.

Dobrze rozpisane taski i pair programming w taki sposób aby nie było blokerów to najszybszy sposób na utrzymanie wiedzy o featuerach u dwóch developerów, do tego praca idzie bardzo sprawnie. Nie ma lepszego sposobu niz pair programming jeśli chodzi o przyspieszenie wypuszczenia jakiegoś feature na czas. Zdarzyło się i nawet pracować w 4 osoby nad jednym featuerem i tempo było świetne, blokery wyeliminowane jak najszybciej a potem development to już poezja.

Lubię pracować z kimś nad rozwiązaniem jakiegoś problemu/buga oraz przy implementacji jakiegoś trudnego ficzera typu wielowątkowość, gleboka refaktoryzacja, jakieś zagmatwane tematy związane z integracją systemów, itp.

Gdybym mial z kimś siedzieć klepiąc kolejny endpoint, albo jakieś zadanie typu daily job to bym się pochlastał.

@Riddle

Teraz, gdybyśmy się znaleźli w sytuacji, w której praca programisty przypomina fabrykę, a linijki kodu oznaczają produkt, to faktycznie oponenci Pair Programming mieliby racje. Gdyby było tak że programista dajmy na to pisze 100 linijek w godzinę, to znaczy to 200 linijek na 2h, 300 linijek na 3h, 400 linijek na 4h i tak dalej. Jeśli przyrost linijek byłby liniowy; oraz każda dodatkowa linijka to byłaby jakaś "nowa jednostka" jakości, to wtedy faktycznie Pair Programming byłby marnowaniem zasobów - dwie osoby przy jednej klawiaturze napiszą dwa razy mniej kodu. Znaczyłoby to również to, że taka osoba musiałaby pisać kod ciągle - bez przerw na myślenie, zastanawianie się, obgadanie, analizowanie.

I tak czasem jest.

Jak to wygląda na prawdę:

No tak, Ty pewnie znasz wszystkie firmy, projekty i zespoły i jesteś w stanie określić "prawdę" :D

Prawda jest taka, że jest praca przy której to ma sens, jak i również praca przy której nie ma to sensu.

A feedback do pomysłu/kodu dostane również przy review, nie potrzebuje do tego udostępniać komuś na żywo ekranu.

To jest kolejny problem który widzę często w IT. Sporo tematów w IT jest bardzo skomplikowane, jak np SOLID, wzorce, TDD, MVC, Agile i masa innych. To są tematy na które trzeba spędzić miesiące jak nie lata żeby je zrozumieć, do tego zalicza się również Pair Programming.

A może tak się dzieje gdy ewangeliście sprzedają na konfach i w książkach swoje wymysły stworzone pod konkretne konteksty jako silver bullety, a później wychodzi tak sobie \_o_/

http://mango2.vtt.fi/virtual/agile/docs/publications/2005/2005_multiple_case_study_pair_programming.pdf

Some studies have also attempted to summarize the effects of pair
programming and calculate overall cost-benefit ratios for adopting
it. This task involves identifying and quantifying the effects of
pair programming on the multiple parameters discussed in
previous sections. While the results are initial at best, Müller [10]
reported an increase of 5% on the total project costs caused by
applying pair programming. According to Williams and Kessler
[1], pairs have a higher efficiency and overall productivity rate
compared to individual developers, and pair programming
increases the business value of a project.

Usefulness in different application scenarios. In addition to
evaluating, if pair programming is beneficial, it should be also
considered, when it is most useful [18]. For example, pair
programming may be most beneficial when applied to only certain
types of tasks [1]. In the existing empirical studies, some scattered
observations about the suitability of pair programming for
different types of tasks have been provided

The complexity of a task is one of the factors affecting the
feasibility of using pair programming. Lui and Chan [9] report
that pair programming improved productivity most in demanding
design tasks. Similar findings have been made also in [8, 25]
where pairing was not found useful in simple, rote tasks.
Regarding different software development activities, there are
studies suggesting that pair programming is not very useful in
testing tasks [8], but more beneficial in performing design and
code reviews and tasks related to architecture and coding [26].

The effect of the complexity of the task on the usefulness of pair
programming was also brought up by the developers in the final
interviews. The developers felt that pair programming was more
useful for demanding and complex tasks than for rote tasks.
“If no one knows how a task should be done, it’s useful to do it
in pairs to think of different ideas.” [Case three]

On the other hand, the some developers felt that tasks, which
require a lot of logical thinking, were best when done solo:
“It’s difficult for two people to think together, so thinking
about a logical task should be done alone.” [Case four]

Productivity. The results of the empirical analysis revealed that
the productivity of pair programming compared to solo
programming varied a lot between the case projects. Thus, based
on the empirical data, no indications towards the superior
productivity of one of the programming styles could be detected.

Rationale for pair programming. As a summary, the developers
found pair programming most suitable for following application
scenarios: a) learning in the beginning of a project, b) solving
problems and thinking of ways to do complex tasks and c) finding
little mistakes from simple code. Similar findings have also been
reported in literature [1, 8, 26]. The a) scenario conforms to
claims that pair programming increases confidence and is an
effective means for learning and training. The two latter
application scenarios highlight the two levels of product related
benefits gained from pair programming: ones related to long-range
“strategic” issues, e.g. improved designs, and the ones
related to the short-range, immediate issues, e.g. code with less
minor defects such as syntax errors and typos.

However, the developers did not agree about the usefulness of pair
programming in scenarios b) and c); some considered thinking in
pairs to be difficult, and others preferred to do simple tasks on
their own. There are also existing studies indicating that pair
programming is inefficient for performing simple, routine-like
tasks (e.g. [25]). One common problem with adopting pair
programming identified in the literature is scheduling difficulties,
i.e. finding common time for the developers to work in pairs [24,
33, 34].

Jeśli kod piszą dwie osoby, to można od razu mergować taki kod, bo nie ma potrzeby na code review. Robiliśmy na początku PR'y, ale nikt nigdy na nich nic nie znajdował, więc uznaliśmy że gra nie warta świeczki - od razu można mergować.

David Farley ostatnio promuje na YT taką radosną teorię. Ale on ma książki do sprzedania i skupia się na technikach działających w greenfieldzie. Ciekawe, czy gdyby miał utrzymywać wieloletni system legacy w zespole ze słabymi programistami, to jak szybko zmieniłby zdanie. Ogólnie lubię książki Davida Farley, ale z tym mergowaniem prosto do mastera, to przegina, według mnie.

Mi zaufanie do takich praktyk spadło, gdy zauważyłem jak koleś zmergował z zaskoczenia kod, który dodawał milion niepotrzebnych zależności do biblioteki, zupełnie łamiąc wszelkie zasady rozumu i godności kodu. Twierdził, że „it was reviewed in pair programming”. No i nic nie można było zrobić, bo zadanie w scrumie (osobny zespół) było już zamknięte. Ja tam nadal lubię formalizm przyklepywania PR. Przynajmniej wiadomo, kto się nie przyłożył do review.

anonimowy napisał(a):

No nie wiem, korzystasz np. z jakiejś klasy z jakiejś biblioteki to wchodzisz do jej źródeł żeby zobaczyć jaką metodę musisz nadpisać żeby dodać porządane zachowanie. Jak druga osoba mi to niby przyśpieszy?

Normalnie - zauważając to, czego Ty nie zauważysz.

Poza tym pisałem o API. Odgadywanie czemu nieudokumentowane API zwraca X a nie Y, to często niezła zabawa.

I co robicie żeby nadążyć za drugą osobą? Przecież, niektórzy ludzie tak szybko przełączają okna, pliki itd. że druga osoba nie jest w stanie się zorientować o co chodzi. Trzeba jej tłumaczyć więc automatycznie zwalniamy (coś jak z czytaniem na głos a czytaniem w myślach)

Pair-programming nie stosuje się do naparzania kodu, który wie się jak napisać, tylko do znajdowania rozwiązań, przy których w pojedynkę ślęczałoby się godzinami. Druga osoba nie ma tu czego spowolnić.