Kiedy działa programowanie parowe? Kiedy tego unikać?

Zamiast niewolniczego programowania przez cały czas, w naszym zespole wybieramy programowanie w parach. Myślę, że najlepiej działa w następujących okolicznościach:

• Ramping nowych członków zespołu w projekcie (zamiast pozwalać im samodzielnie przedzierać się przez dokumentację lub kod).
• Posiadanie młodszych i starszych osób współpracuje (pomaga pokazać niektóre umiejętności i sztuczki bardziej doświadczonych programistów, a także pozwala starym psom czasami uczyć się nowych sztuczek).
• Gdy ktoś próbuje wyśledzić wadę, często pomaga sparować ze świeżym zestawem oczu.

Kiedy używać programu parowania i dlaczego?

Kiedy unikać programowania par? Dlaczego?

Badania opracowane przez Laurie Williams wskazują, że programowanie par najlepiej sprawdza się w zespołach przemysłowych, kiedy

• Pary pracują nad specyfikacją, projektowaniem i złożonymi zadaniami programistycznymi - eksperymenty wskazują, że poprawa jakości nie jest pokazywana podczas pracy nad prostymi zadaniami w parze, ale może wystąpić poprawa prędkości. Należy również pamiętać, że „programowanie” par często obejmuje czynności inne niż pisanie kodu.
• Każda osoba w parowaniu ma mniej więcej ten sam poziom wiedzy - podczas gdy programowanie par jest świetne do treningu, pary są najbardziej zaangażowane, gdy są na tym samym poziomie.
• Role obracają się regularnie - regularne obracanie pomaga utrzymać włączony drugi pilot, ponieważ osoby zwykle mają największy udział, gdy prowadzą samochód lub wyczuwają, że będą jechać.
• Pary zmieniają się regularnie - zespoły wyraziły komfort wiedząc o różnych częściach budowanego systemu. Rotacja par pomaga w przekazywaniu wiedzy, co zmniejsza pewne ryzyko w projekcie. W środowisku akademickim pary są często przypisywane, jednak w branży zwykle są one przydzielane często podczas pojedynków. W obu przypadkach para jest najbardziej skuteczna, gdy obie osoby są chętnymi uczestnikami, którzy dostrzegają wartość w działaniu parowania.

Z mojego osobistego doświadczenia wynika, że ​​mój zespół XP spędza średnio około 60% naszego czasu programowania. Pozostałą część czasu poświęca się na indywidualny rozwój. Często zdarza się łączenie w pary w celu utworzenia wstępnego projektu, praca nad projektem przez kilka godzin, a następnie powrót do siebie, aby ukończyć trudne lub trudne części kodu.

Odkryłem również, że programowanie par jest najskuteczniejsze w blokach trwających około 1,5 do 2,5 godziny. Wszystko o wiele mniej wymaga zwykle zbyt dużego obciążenia, aby ustawić, a znacznie więcej, a pary stają się zepsute i zmęczone. Zepsuty i zmęczony oznacza, że ​​nie komunikujesz się dobrze i możesz pozwolić, aby wady dostały się do systemu.

Programowanie w parach działało dla mnie w bardzo, bardzo niewielu sytuacjach.

Gdzie zawodzi programowanie parowe

Krótko mówiąc, programowanie parami nie działa dla mnie jako główny sposób tworzenia oprogramowania. Mogę sparować program na dzień, a może na tydzień, szczególnie jeśli skupiamy się na konkretnym problemie. Ale potem? Skończyłem. Toast. Nie chcę nikogo widzieć, rozmawiać z nikim i potrzebuję przynajmniej kilku dni w jaskini, aż znów będę w stanie znaleźć się w towarzystwie ludzi.

To smutna historia, ale zabawne jest to, że jestem teraz o wiele szczęśliwszy z tego, jak się skończyła. Z radością jestem zatrudniony na podstawie umowy, w której pracuję z domu lub z kawiarni, i poznałem nowych przyjaciół i odkryłem więcej San Francisco, niż kiedykolwiek myślałem, że to możliwe. Mam rower i laptop i tak długo, jak dotrzymuję terminów i regularnie odprawiam kod, mój czas jest mój.

Wymienię duże problemy, które mam z programowaniem parami z góry, a później przedstawię szczegóły i anegdoty.

1. Split focus.
2. Bez eksperymentów.
3. Brak wysokich nut.
4. Brak dumy z własności.
5. Nie ma ucieczki...

... Zapytałem moich współpracowników, czy widzieli to, co widziałem, jeśli coś mi umknęło, cokolwiek - nie widziałem, jak to może działać, jak ludzie mogą to robić dalej. Powiedzieli, że mam się dobrze, że zajęło mi to trochę czasu, aby się dostosować i dostosować. Na początku było to trudne.

W końcu wycofałem się do siebie. Pomiędzy oślepiającymi bólami głowy, bezsennością i dudniącymi, niezaspokojonymi potrzebami pisania kodu, przestałem odpowiadać na dane wejściowe. Mogłem patrzeć na ekran i nic nie widzieć. Ktoś mógł się ze mną niespodziewanie porozmawiać, a ja ich nie usłyszę. Spełniłem podstawowe wymagania mojej pracy, ale mnie tam nie było. Zużyłem wszystko, co właśnie pojawiłem się tego dnia. Zacząłem sprawdzać iPhone'a, gdy mój drugi partner pisał.

W końcu - niecałe trzy miesiące później i po raz pierwszy - zostałem zwolniony za to, że nie pasowałem do zespołu podczas programowania w parach.

Nie sam

Napisałem to nie tylko po to, aby to zrozumieć, ale także, aby móc o tym mówić. Zakłada się, że programowanie parami działa dla większości ludzi i jest znacznie łatwiejsze i szybsze niż programowanie solo. Może tak być, ale nie musi, ale jako długoterminowa praktyka programowanie w parach nie działa dla mnie. Istnieje wiele innych osób, dla których programowanie parami nie działa dla żadnego z nich. My też mamy znaczenie ...

Mój zespół zajmuje się programowaniem par od samego początku, na długo przed tym, jak tam pracowałem, jako część sklepu w stylu „ekstremalnego programowania”. Programowanie w parach jest stanem domyślnym ; ludzie naprawdę wybierają się singleton tylko wtedy, gdy jest nieparzysta liczba, lub od czasu do czasu na dochodzenia, szczególnie te, które polegają na plątaniu się wrogim sprzętem i próbowaniu jego uruchomienia.

„Junior / senior” to nie jedyna droga. Przydatny jest „średniozaawansowany / młodszy”; pomaga facetowi na średnim poziomie zsyntetyzować zdobytą wiedzę, zmuszając go do przekazania jej komuś innemu. Wyzwania „Średniozaawansowany / Średniozaawansowany” stanowią wyzwanie dla dwóch osób, które dzielą się swoją wiedzą, komunikują się i pracują w zespole. I nawet jeśli masz dwóch naprawdę starszych facetów, są szanse, że mają oni różne obszary specjalizacji i mogą wymyślić różne podejścia. Aspekty dzielenia się wiedzą nie kończą się, gdy ktoś jest niejasno „przyśpieszony” w projekcie. Programowanie w parach jest raczej uosobieniem organizacji uczącej się . Nowe techniki i najlepsze praktyki rozprzestrzeniają się szybko.

Programowanie w parach pomaga również utrzymać jakość kodu (mniej defektów) i poczytalność kodu (nie tylko robi to, co zamierza, ale robi to, co powinno ... idealnie bez schodzenia wielotygodniowego królika dziura robi złą rzecz lub dwie różne właściwe rzeczy, które będą się dziko sprzeczały). Pomaga programistom utrzymać koncentrację: tutaj, w sercu Doliny Krzemowej, domu 80-godzinnego tygodnia pracy, możemy pracować tylko 40 godzin tygodniowo, ponieważ intensywnie kodujemy przez osiem godzin dziennie, zmieniając rzeczy precz ze sobą. (Ponadto, jeśli dłużej zajmujesz się programowaniem w parach, prawdopodobnie się przewrócisz. A przynajmniej wypalisz.) Jest to doskonałe rozwiązanie dla równowagi między życiem zawodowym a prywatnym, a także pomaga organizacji, gdy ważne jest, aby szybko realizować zadania (szczególnie w przypadku krótkich opóźnień).

To nie wszystko, całkowicie, 100% brzoskwinie i śmietana; Uważam, że programowanie w parach jest czasami przeszkodą w stosowaniu intuicyjnych procesów mózgowych, które są przydatne w niektórych problemach. Ostatnio, w ramach zadania przecieku pamięci, spędziłem trochę czasu zarówno z parami, jak i bez; bez niego czułem się bardziej swobodnie, próbując eksperymentować, nie wiedząc dokładnie, jak wyjaśnić, co robiłem w danym momencie. Istnieją również pewne zalety pracy w trybie singleton, możliwość przejścia na styczną i wykonania pewnych dzikich refaktoryzacji (cenionych w metodyce XP) na podstawie kaprysu.

Ale ogólnie rzecz biorąc, korzyści znacznie przewyższają koszty, a parowanie zadziałało dla nas spektakularnie: od etapu rozruchu, poprzez przejęcie przez większą firmę i naszą późniejszą integrację. (Mówiąc o tym, programowanie par pomogło nam utrzymać ciągłość kultury poprzez ekspansję i pomimo niewielkich obrotów).

(Opracowujemy oprogramowanie w Perlu, cena katalogowa od ~ 4000 do 40 000 $).

Nigdy nie pracowałem w konfiguracji „Programowania par”, a mimo to mogę twierdzić, że należałem do trzech wymienionych przez ciebie okoliczności. Scenariusz, o którym wspominasz, wydaje się bardziej „regularnym programowaniem” z wprowadzonymi fazami pomocy / szkolenia. Czy nie zrobiliśmy tego wszystkiego przed powstaniem „programowania w parach”? Zakładam, że programowanie w parach wymagałoby bardziej zaangażowanego podejścia, w którym proces dzielenia się w zespole nie kończy się w chwili, gdy zmierzysz się z bezpośrednim zadaniem lub problemem. Ale to jest to, co „myślę”, a nie to, co „wiem”.

Osobiście do programowania w parach Chciałbym pracować w zespole, w którym mam szansę uczyć się i dzielić swoją wiedzą. Niezrównoważony zespół, w którym wszyscy, z którymi pracujesz, jest o kilka mil przed tobą, a następnie znacznie poniżej normy, może szybko stać się mało interesujący. Poza tym bałbym się współpracować z ludźmi, którzy są przekonani i trudni do przekonania.

Przez ostatnie kilka miesięcy eksperymentowaliśmy z programowaniem par w naszym zespole. Uważam, że jest to bardzo przydatne, gdy pracujesz nad czymś nowym (nowa technologia, nowa funkcja itp.), Ponieważ możesz szybko wysyłać pomysły innym osobom z zespołu i zatwierdzać je / unieważniać. Ponadto wzajemna ocena pomaga uniknąć błędów.

Inny kolega z drużyny próbował zastosować programowanie parowe z testem w celu wykonania ATDD i byli bardzo zadowoleni z wyników (według jego obliczeń wzrost o 20% kosztów deweloperskich doprowadził do skrócenia o około 50% czasu testu)

Dobranoc

wiele razy debatowaliśmy na temat praktyk programowania ekstremalnego i programowania par . W przeszłości jesteśmy w stanie zrozumieć, że programowanie jest działaniem solo, ponieważ programiści potrzebowali koncentracji i izolacji. Programiści w tym czasie znajdowali się w strefie , w stanie psychicznym, w którym mogli efektywnie skupić się na kodzie i podejmować dobre i twórcze decyzje.

Programowanie w parach wydaje się również ryzykowne, jeśli założymy, że jeden programista sobie przeszkadza. Z drugiej strony trudniej jest przerwać współpracę dwóch programistów. Na przykład w programowaniu solo łatwiej będzie przerwać, więc programistaowi solo jest prawie niemożliwe pozostanie w „strefie”.

Jakość kodu jest kolejna, gdy termin jest tuż za rogiem. Ludzie zawsze będą się spieszyć, będą programistami parami lub programistami solo: nie zastosują pewnych najlepszych praktyk i po prostu zapomną o testowaniu jednostkowym.

Trzymałbym się programowania par. Ponieważ jeśli chodzi o ryzyko, kiedy nie ma jednego programisty, zawsze będziesz mieć innego faceta, który udokumentuje proces i nauczy innych, jak to działa.

Praca na czymkolwiek, co nie jest trywialne, na ogół jest dobrym kandydatem do programowania w parach, dzięki czemu wiele osób rozumie kod, a nie tylko jeden programista znający część podstawy kodu. Innym przypadkiem jest sytuacja, w której ktoś chce przekazać pewne umiejętności. Przykładem może być sparowanie kogoś, kto jest naprawdę dobry w testach jednostkowych, z kimś, kto nie jest tak dobrze zaznajomiony z tą koncepcją, a tym samym pomaga w uzyskaniu początkowego nawyku na czymś.

Jeśli chodzi o miejsce, w którym należy unikać programowania w parach, należy wykonać proste zadania, w których lepiej byłoby podzielić pracę na dwie grupy i pozwolić każdemu programistowi wykonać część pracy oddzielnie, aby wykonać pracę. Niektóre zadania mogą wymagać sporo pisania, ale nie są tak duże, że warto poświęcić kilka godzin na znalezienie lepszego sposobu, aby to zrobić, ponieważ można to zrobić, jeśli każdy programista podejmie brutalną siłę przez kilka godziny.