Pracowałem w kilku sklepach, w których kierownictwo przekazało mi pomysł programowania w parach albo mnie, albo innemu menedżerowi / programistowi, i wcale nie mogę się za tym wycofać. Z punktu widzenia programisty nie mogę znaleźć powodu, dla którego przejście na ten styl kodowania byłoby korzystne, ani jako kierownik małego zespołu nie widziałem żadnej korzyści.

Rozumiem, że pomaga to w podstawowych błędach składniowych i może być pomocny, jeśli musisz coś wymieszać, ale menedżerowie, którzy nie są w pętli programowania, wydają się postrzegać to jako sposób na powstrzymanie ich projektantów przed przejściem na Facebooka lub Reddita niż jako narzędzie do projektowania.

Jako ktoś bliski progu rozwoju, który najwyraźniej nie do końca rozumie z książki rzuconej po mojej stronie lub strony wiki na ten temat ... z wysokiego stanowiska kierowniczego, jakie są korzyści z programowania w parach w przypadku Scruma lub Agile środowiska?

Częściowo zależy to od tego, jak robisz programowanie w parach. W niektórych przypadkach sterownik pary pisze kod, podczas gdy drugi członek pary obserwuje i omawia szczegóły projektu i implementacji systemu. Kolejny przypadek programowania par obejmuje obie osoby piszące kod jednocześnie - jedna osoba pisze zaimplementowaną funkcjonalność, a druga aktywnie rozwija i pisze kod testowy na poziomie jednostki i integracji, ponownie omawiając szczegóły dotyczące projektu i implementacji systemu.

Niezależnie od rodzaju programowania par skutecznie służy jako ciągły przegląd kodu . Dwójka ludzi patrzy na kod, szukając błędów, zanim uciekną one do późniejszego środowiska testowania systemu / akceptacji lub pola. Masz również dwie osoby, które bardzo dobrze rozumieją określoną część systemu, aby służyć jako redundancja w celu zminimalizowania współczynnika autobusu . Zarówno wczesne wykrywanie defektów, jak i rozpowszechnianie wiedzy o systemie w zespole zmniejsza koszty budowy systemu.

Rozpowszechnianie wiedzy nie ogranicza się tylko do wiedzy technicznej zespołu. W zależności od tego, kim jest para, może pozwolić na przepływ informacji między starszym członkiem firmy do nowego członka na temat innych rzeczy wykraczających poza projekt - stylu kodowania, kultury firmy, oczekiwań i tak dalej. Może również pozwolić komuś, kto jest bardziej zaznajomiony z technologią lub narzędziem, na dzielenie się swoją wiedzą na temat tej technologii lub narzędzia w zastosowanych warunkach rzeczywistych.

Jak już wspomniałeś, pomaga to programistom skupić się na bieżących działaniach . Oprócz przepływu wiele osób rzadziej przeszkadza wielu osobom pracującym nad czymś niż jednej osobie nad czymś pracującym. Jeśli przechodzisz przy czyimś biurku, a on pracuje sam, ale musisz z nim porozmawiać, możesz zapukać i porozmawiać z nimi. Jest to mniej prawdopodobne, jeśli zobaczysz, że dwie lub więcej osób współpracuje lub prowadzi dyskusję - nie będziesz ich przerywać. Przerwy kosztują czas, a spędzanie więcej czasu oznacza wyższe koszty. W najlepszym interesie firmy leży maksymalizacja wydajności pracowników.

Istnieją jednak pewne wyzwania, które należy pokonać, aby programowanie w parach było wykonalne. Rozważ takie rzeczy, jak starcia osobowości lub wybranie par, aby właściwie rozpowszechniać wiedzę. Zastanawia się również, kiedy dokładnie obrócić pary. Programowanie parami wykonane przypadkowo prawdopodobnie nie będzie skuteczne jako zaplanowane. W zależności od składu zespołu parowanie ludzi może nie być skuteczne.

1. Mniej błędów w końcowym kodzie (wydajność)
   Nie całkowicie zastępuje recenzje kodu, ale jest bardzo skuteczny, jeśli chodzi o szybkie rozpoczęcie pracy. Istnieją badania, które wskazują w tym kierunku.

2. Szybsze ukończenie (skuteczność)
   Wskazuje na to szereg badań. Jeśli chodzi o złożone funkcje, 2 głowice są po prostu bardziej skuteczne. Do tego niezbędne jest doświadczenie w parowaniu.

(uwaga: jest to Twój sposób na menedżera: rozsądna finansowo decyzja, ponieważ uzyskujesz większą wydajność dzięki niższej liczbie błędów i bardziej efektywną dzięki szybszemu ukończeniu)

1. Nauczanie juniorów
   Możesz dodać juniora bezpośrednio do bardziej doświadczonego programisty. Jeśli masz grupę absolutnie początkujących, łatwo jest pozostać w pobliżu i pozwolić im, jako parom, ustalić podstawy. Trzymaj się i udzielaj rad. Koncepcja jest najwyraźniej bardzo stara i wynika z kunsztu.

Szybka odpowiedź: większość korzyści i kosztów jest opublikowana w Wikipedii, jednak spójrzmy na to z nieco innego punktu widzenia.

Chciałbym wspomnieć o konkretnych przypadkach korzyści związanych z programowaniem par, które dotyczą środowiska programistycznego agile / scrum, zaczerpniętych z postu na blogu :

Sukces lub porażka oprogramowania zależy od jego jakości, a programowanie w parach bezpośrednio poprawia jakość na wiele sposobów. Kiedy dwóch programistów współpracuje ze sobą, jakość wzornictwa poprawia się, gdy para rozwija krótki, prosty i łatwy w utrzymaniu kod z mniejszą liczbą błędów. Błędy są poważnym problemem jakościowym przy tworzeniu oprogramowania; z dwoma zestawami oczu piszących kod, wychwytuje się więcej błędów, zmniejszając w ten sposób koszty rozwoju. Błędy znalezione na późnym etapie procesu programowania są często kosztowne do naprawienia. Wczesne wykrywanie usterek oprogramowania zapobiega i pomaga zapobiegać trudnym problemom na drodze. Często pojawia się złożoność programowania, a dwa umysły pracujące nad rozwiązaniem problemu razem mogą zobaczyć więcej opcji i wyciągnąć wnioski szybciej niż jeden.

w podsumowaniu:

• Promuje komunikację w zespole
• Promuje efektywny transfer wiedzy na temat aplikacji
• Promuje odpowiedzialność za podejście do projektowania
• Daje lepszy, łatwy w utrzymaniu kod
• Pomaga wyeliminować błędny kod na wczesnym etapie
• Zwiększa produktywność zespołu, ponieważ członkowie zespołu będą mieć niepodzielną uwagę podczas kodowania
• Poprawia umiejętności komunikacji i współpracy członków zespołu
• Buduje koleżeństwo w miejscu pracy
• Sprawia, że ​​praca jest przyjemniejsza

Programowanie parami ma kilka zalet:

• Dwaj programiści mogą współpracować przy projektowaniu, potencjalnie tworząc lepszą architekturę / kod - dwie pary oczu mogą dostrzec błędy
• Wiedza instytucji jest lepiej zachowana - jeśli jeden programista odejdzie lub jest niedostępny, drugi powinien móc kontynuować pracę bez znacznej utraty wydajności
• Jest to jeden ze sposobów szybkiego szkolenia nowych programistów - połącz ich z doświadczonym członkiem zespołu programistów, a będą oni mogli poznać bazę kodu z perspektywy weterana zespołu
• Lepsza dyscyplina - sparowani programiści prawdopodobnie będą produktywni przez dłuższy okres czasu, ponieważ jeden lub drugi może przejąć kontrolę nad gwałtownymi ruchami. Potencjalnie uciążliwe zadania, takie jak testy jednostkowe, mogą być pomijane rzadziej niż w przypadku twórców solo.

Wikipedia ma również ładne podsumowanie kosztów i korzyści związanych z wpisem na wiki .