Programowanie / współpraca w parach w małej firmie

20

Pracuję w małej firmie deweloperskiej jako główny programista. Mamy dwóch innych programistów, a także mojego szefa, który jest programistą, ale tak naprawdę nie robi już dużo z kodowania.

Problem, który próbuję rozwiązać, jest wieloaspektowy. Wszyscy mamy tendencję do pracy nad własnymi projektami bez dużej współpracy między nami. Prawdę mówiąc, ja (jako najbardziej zaawansowany programista) proszę o opinię / pomoc innych bardziej niż oni, ponieważ cenię wkład oka zewnętrznego.

Chcę zacieśnić naszą współpracę i wyraziłem to im. W dużej mierze dlatego, że chciałbym im pokazać kilka rzeczy na temat tego, jak zostać lepszymi programistami i postępować zgodnie z lepszymi praktykami. Biorąc jednak pod uwagę typ osobowości innych naszych programistów, myślę, że wygodniej jest im pracować samodzielnie.

Czytałem o programowaniu w parach i przeczytałem (na niektórych forach), że to nie działa dobrze, gdy jeden programista jest bardziej zaawansowany niż inni (którym jestem). A jednak uważam, że konieczne jest rozpoczęcie współpracy, aby nasza praca nie była tak różnorodna.

Moje pytanie brzmi: czy ktokolwiek kiedykolwiek był w podobnej sytuacji i co dla nich działało?

Zdaję sobie sprawę, że nie jest to sytuacja uniwersalna, ale jestem gotów spróbować wielu podejść.

Wszyscy pracujemy we wspólnym obszarze, programiści nie mają indywidualnych biur / kabin.

Ryan Williams
źródło
2
Czy ty i inni deweloperzy macie oddzielne biura, kabiny lub siedzicie we wspólnym obszarze?
@hatchet Wszyscy pracujemy we wspólnym obszarze.
Ryan Williams

Odpowiedzi:

12

Ponieważ zostało już omówione w innych odpowiedziach, dlaczego programowanie w parach nie jest dla ciebie rozwiązaniem , omówię to , z czym obecnie eksperymentowaliśmy i jestem zadowolony z wyników.

Moim zdaniem, co możesz zrobić, aby zwiększyć współpracę, to mieć dwie osoby w każdym projekcie. Każda z nich działa w innej części projektu, ale ponieważ te części muszą zostać zintegrowane, dwaj programiści muszą współpracować. Wymaga to również, aby dwaj programiści omówili architekturę (warstwowanie i interfejsy) projektu, a następnie zdecydowali się na przyjęcie różnych ról.

A jeśli to podejście ograniczy liczbę projektów, które Twoja firma może obsłużyć jednocześnie, możesz przypisać tej współpracującej parze dwa projekty jednocześnie.

Niedawno eksperymentowaliśmy z tym podejściem, mając jeden z nich opracowujący modele + integrację z apis i drugi programista obsługujący widoki i kontrolery . Odkryliśmy następujące zalety tego ustawienia:

  1. Struktura kodu daje wynik znacznie lepszy niż w przypadku, gdy tylko jeden pracuje nad wszystkimi aspektami projektu.
  2. Nie musimy im przypominać o popełnieniu kodu w repozytorium itp.
  3. Muszą włożyć trochę wysiłku w testowanie siebie kodu, zamiast polegać wyłącznie na naszej dedykowanej kontroli jakości.
Ozair Kafray
źródło
1
Zastanowię się również nad tym. Naprawdę podoba mi się oddzielenie rozwoju widoków i kontrolerów od modeli, ponieważ zmusza to programistów do opracowania dobrego API dla modeli. Aby działać jednocześnie, wymusza także pisanie odpowiednich testów.
Ryan Williams
1
Zdecydowałem się przyjąć tę odpowiedź, ponieważ po jej omówieniu i rozmowie z kilkoma członkami zespołu jestem przekonany, że najlepszym sposobem na zainicjowanie współpracy jest podział ról w tym samym projekcie. To może nie działać, ale wydaje się być najlepszym dopasowaniem, jakie słyszałem.
Ryan Williams
7

Moim zdaniem programowanie parami nie jest rozwiązaniem problemu, który poruszasz.

Istnieją dwie różne role w programowaniu parowym. Obserwator jest tam do przeglądu i informacji zwrotnych na temat kodu napisanego przez kierowcę . Jeśli próbujesz przekazać pomysły na usprawnienie decyzji podejmowanych przez twoich młodszych programistów, zastanawiam się, jak skuteczna może być ich umiejętność krytycznej oceny kodu, który piszesz, gdy pełnisz rolę kierowcy.

Bez tej dynamiki utracone zostaną korzyści z programowania w parach.

Jako starszy programista proponuję rozważenie z szefem silniejszego programu szkolenia pracowników i rozwoju. Twoi młodsi programiści powinni otrzymać ramy do doskonalenia swoich umiejętności. Zazwyczaj można używać metod takich jak oświecenie, pisanie dokumentu standardów kodowania, oddzielanie samodzielnych zadań od własnej pracy i zapewnianie odpowiednich procesów przeglądu kodu.


źródło
Wezmę pod uwagę twoje myśli. Trochę parsować i rektyfikować w myślach to, co obecnie robimy. Szczere uczucie, które mam, jest trochę niepewne na mojej pozycji jako głównego programisty. Nie dlatego, że nie czuję się komfortowo z perspektywy umiejętności, ale raczej dlatego, że obaj nasi programiści są starsi ode mnie (jeden znacząco, jeden nie), a jeden ma jeszcze kilka lat doświadczenia. W takim przypadku tradycyjne przeglądy kodu wydawałyby się niezręczne, ponieważ nie chcę wyglądać, jakbym oddychał im po szyjach. Z drugiej strony, może to właśnie muszę zrobić.
Ryan Williams
Jeszcze jedna rzecz. Czy uważasz, że korzyści są mniejsze, niż warto sparować z nimi program, kiedy jestem kierowcą? Nadal można go wykorzystać jako sposób na wskazanie najlepszych praktyk i nadal mieć pewien wkład i informacje zwrotne na temat tego, co robię (nawet jeśli związek na pewno byłby niezrównoważony).
Ryan Williams,
Jeśli relacja programowania par jest jednym ze sposobów, sugerowałbym, że nie byłby angażujący, a być może nawet trochę protekcjonalny dla twoich współpracowników. W zależności od tego, w jaki sposób go modelujesz, może to dość łatwo powiedzieć: „tak programuję i jest to najlepsze podejście”. Nie nazwałbyś tego programowania parami, ponieważ nie ma on obu składników.
Chyba tak się właśnie boję. Dzięki za myśli. Przyjmuję twoją odpowiedź za bycie pierwszym. (Było też kilka innych dobrych.)
Ryan Williams
Recenzje @RyanWilliams Code nie dotyczą „łamania szyi”. Nie chodzi o to, że je kontrolujesz. W naszym miejscu używamy ReviewBoard jako platformy i komentujemy kod innych użytkowników . Nie ma „hierarchii”. Nauka w tym przypadku jest „domniemana”. Uczą się czytając twój kod i jego kod, od twoich i innych pytań deweloperów oraz odpowiedzi / komentarzy na te pytania. Poznają też inne części bazy kodu, co jest dość korzystne dla IMHO.
Johannes S.
5

TL; DR : Nie sądzę, aby programowanie w parach działało dla ciebie. Zamiast tego należy spróbować, aby ludzie troszczą się o jakość długotrwałego ich kodu i uczynić z nich chce , aby znaleźć odpowiedź. Należy to zrobić nieformalnie.


O kulturze i jakości

Wydaje mi się, że ten problem nie dotyczy metodologii programowania, ale raczej kultury . Z mojego doświadczenia wynika, że ​​kulturę można kierować, ale rzadko mówiąc o tym ludziom. Oznacza to, że próba wymuszenia określonego przepływu pracy na ludziach, którzy nie ewoluowali naturalnie lub są zbyt daleko od dotychczasowej praktyki, może mieć negatywne konsekwencje.

Innymi słowy, nie chcesz wyglądać jak ten garnitur, który pojawia się, modląc się o najnowsze modne słowa, nawet jeśli ostatecznie jesteś. Większość programistów, których znam, mentalnie oznaczałaby cię jako szum tła. Nie bądź korporacyjną pszczołą.

Moim zdaniem podstawowe pytanie, które powinieneś sobie zadać, brzmi: „Czy jestem zadowolony z jakości i wartości biznesowej kodu, który wystawia moja organizacja?” a jeśli odpowiedź na to pytanie jest przecząca, należy zapytać „jak to odwrócić?”.

Ostatecznie jakość i wartość są ludzkimi definicjami, o których tylko Ty lub ktoś w Twojej organizacji może (i powinien) pomyśleć.

Programowanie par i mikrozarządzanie

Tak więc, ryzykując, że zabrzmi to nieco naprzód i szorstko, wydaje mi się, że czytanie o programowaniu w parach sprawiło, że pomyślałeś o jakiejś formie mikrozarządzania lub na odwrót. MM to pewny przepis na wyobcowanie większości ludzi.

W obronie programowania w parach: w programowaniu w parach nie chodzi o faceta spoglądającego przez ramię innego faceta. To jest tak mikro, jak zarządzanie. PP polega na wykorzystaniu dwóch umysłów do myślenia o dwóch poziomach jednocześnie - jedna osoba zajmuje się wysokimi poziomami , dużymi problemami z obrazem , a druga zajmuje się nakrętkami i śrubami potrzebnymi do stworzenia działającego kodu. I moim skromnym zdaniem rzadko działa dobrze, jeśli dwóch uczestników nie jest w stanie zmienić miejsca. Powinni być podobnie doświadczeni, aby mieć podobny profesjonalny arsenał pojęć i wspólne profesjonalne słownictwo (nie jesteśmy powiązani z umysłem - jeszcze , muhahaha).

Powiedziałbym, że w twojej sytuacji, ponieważ jesteś małym zespołem i jesteś jedynym, który ma prawdziwe doświadczenie (tak brzmi dla mnie Twój post), programowanie parami lub przeglądanie większości kodu w większości przypadków nie działa. Masz tylko 24 godziny na dobę. Zamiast tego można rozważyć kilka rozwiązań:

  • Zachęć ich do wzięcia udziału w SO pod odpowiednim tagiem językowym lub opublikowania fragmentów kodu do recenzji w Code Review SE. Rozpocznij trochę nieformalnego konkursu na to, kto może zdobyć najwięcej SO powtórzeń tygodniowo.

    SO może robić cuda dla programistów początkujących, ponieważ zapewnia ciągłe informacje zwrotne i podąża za rytmem społeczności.

  • Rzuć okiem na kod, który rejestrują i nieformalnie rzuć mu wyzwanie, zadając pytania dotyczące jego ewolucji w dłuższej perspektywie. Większość początkujących programistów po prostu nie jest przyzwyczajonych do myślenia o tym, aby ich kod był czytelny i łatwy w utrzymaniu. Gdy dostaniesz te problemy do głowy, będą szukać więcej informacji na własną rękę, od ciebie lub z innych źródeł.

idoby
źródło
Jak wszyscy inni, doceniam twój wkład. Jedną rzeczą, którą zdałem sobie z tego sprawę, jest to, że mam pewien dyskomfort związany z byciem tym, który patrzy ponad ich ramionami. Oboje są w rzeczywistości starsi ode mnie i jeden ma znacznie więcej doświadczenia. Więc nie wyobrażam sobie ich jako ludzi, którzy będą obchodzić CE i prosić o recenzje kodu. Nie są nowicjuszami. Ale pochodzą z różnych języków i niekonwencjonalnych praktyk.
Ryan Williams
Widzę. Myślę, że to dobrze, że nie czujesz się komfortowo, patrząc na ich ramiona, ponieważ nie sądzę, że powinieneś. Nikt nie chce, aby ktoś zgadywał po każdym naciśnięciu klawisza (przesada).
idoby
4

Nie sądzę, aby programowanie w parach pomogło ci w twoim środowisku. To nie jest tak, że nie pomogłoby to podnieść umiejętności mniej doświadczonych programistów - jest nawet pytanie programistów o łączenie programowania z inżynierami o różnych poziomach umiejętności . Mimo że istnieją korzyści, takie jak dzielenie się wiedzą i mniej błędów, programowanie w parach wymaga więcej czasu. Z zespołem trzech programistów i tylko czterema osobami, które mają doświadczenie / doświadczenie w programowaniu, utrzymanie rutyny programowania w parach wydaje się trudne.

Myślę, że lepszą alternatywą w twojej sytuacji są przeglądy kodu, zwłaszcza jeśli odpowiednio je dostosujesz. Przegląd kodu może składać się z wszystkiego, od jednej osoby przeglądającej odrobinę kodu i przekazującej informacje zwrotne wielu osobom (nawet całemu zespołowi) w pokoju przez godzinę lub dwie, aby przejrzeć projekt i wdrożenie całego komponentu. Można je zmieniać odpowiednio do wykonywanej pracy, szczególnie w oparciu o wiedzę, doświadczenie i potrzeby zespołu. W dalszym ciągu można uzyskać aspekt dzielenia się wiedzą, gdy wiele osób bierze udział w przeglądzie w celu znalezienia problemów, przedstawienia sugestii i zdobycia wiedzy poprzez przeczytanie wyników przeglądu w celu włączenia komentarzy do własnej pracy, zanim zostaną one przejrzane .

Thomas Owens
źródło
Wydaje się być popularną opinią. Podoba mi się pomysł recenzji kodu. Ale w mojej głowie zgaduję, że przy ich osobowościach i poziomach umiejętności to ja będę recenzował, a oni po prostu słuchają (głównie niezaangażowani). Ale może istnieje sposób, aby zwiększyć ich zaangażowanie. Chyba muszę się nad tym zastanowić.
Ryan Williams,
Dla jasności nie mówiłem o programowaniu par jako czymś, co robimy cały czas. Poświęć mu raczej znaczną, ale nie ogromną część tygodnia pracy na większe lub bardziej złożone funkcje. (Jest to częściowo spowodowane praktyczną koniecznością. Mam własne wymagania, które należy spełnić.)
Ryan Williams,
2

Moje pytanie brzmi: czy ktoś kiedykolwiek był w podobnej sytuacji i co dla niego działało.

Ponieważ zapraszasz doświadczenie, oto co zrobiłem. Wybrałem podejście niskiego ryzyka i poprosiłem kogoś o dziesięciolecia młodszego ode mnie o wspólne spędzanie czasu. Nie oznaczyliśmy aktywności. Nikt oprócz mnie nie wiedział, że próbujemy nowej techniki.

Nie wiem dokładnie, z którymi szczegółami się odnosić, ale proces działał bardzo dobrze. Chciał zostać mentorem, o czym wcześniej nie miałem pojęcia. Dlatego bardzo pozytywnie otworzył komunikację w obu kierunkach.

Prawdę mówiąc, ja (jako najbardziej zaawansowany programista) proszę o opinię / pomoc innych bardziej niż oni, ponieważ cenię wkład oka zewnętrznego.

Wygląda na to, że możesz to ująć jako logiczny postęp tego, co obecnie robisz.

dcaswell
źródło
Martwię się, że nie jestem pewien, czy chcą być „mentorem”. Obaj są starsi ode mnie, a jeden (znacznie starszy) ma o kilka lat więcej doświadczenia niż ja. Ale podoba mi się druga część twojej porady.
Ryan Williams
Naturalne jest martwienie się, zanim coś zrobisz - ponieważ nie masz informacji. Z mojego doświadczenia wynika, że ​​jeśli tylko to zrobisz, ludzie poczują, że się nie martwisz, że jesteś zrelaksowany i pójdą dalej. A jeśli to działa - kontynuuj, a jeśli nie - spróbuj czegoś innego.
dcaswell
Może zaangażowanie ich w większy projekt, który normalnie bym sam wykonał, może to nieco złagodzić. Na przykład wkrótce przerabiamy nasz CMS. Jednak zajęło by mi trochę przyzwyczajenie się do tego pomysłu.
Ryan Williams
0

Kilka miesięcy po zadaniu tego pytania muszę powiedzieć, że jestem zadowolony z naszych wyników. Ale nie jest to dokładnie ten, który zaakceptowałem na początku. Pamiętaj, że jest to mały zespół, więc to rozwiązanie nie będzie pasować każdemu.

Zauważyłem, że najlepiej jest pozwolić wszystkim wykonywać swoją pracę. Z biegiem czasu rozwinęliśmy wzajemne zaufanie, w którym jeśli napotkamy problem, wzywamy innych do naszej pomocy. Nie sądzę, żeby ktokolwiek chciał współpracować z kimś obserwującym ich przez ramię. Czasami siedzę za kimś, a czasem pomagam mu rozwiązać problem bez zaproszenia. Czasami nie mam nic do dodania i może trochę ich denerwuję. Ale rozumieją, że nie jestem tam, aby ich harfować. Jestem głównie po to, aby zrobić sobie przerwę od tego, co robię i wprowadzić trochę współpracy.

Odkryłem, że PRAWI ludzie z czasem (w małym zespole) wychwytują i synchronizują się z tym, co robią inni. Nie ma potrzeby ciągłego zarządzania ani informowania kogoś, co robi źle.

Od czasu do czasu usiądź z kimś i rozwiąż problem, niezależnie od tego, czy jesteś ekspertem, czy ktoś się uczy, albo jedno i drugie. Wyjaśnij, dlaczego chcesz lub nie zrobiłbyś czegoś w jedną stronę, a nie w drugą. Dobre pomysły zwykle się sprawdzają, podczas gdy inni zostają w tyle. A na koniec dnia masz produktywną, spójną grupę ludzi, którzy mogą pracować nad różnymi rzeczami, ale mają wspólny cel.

Ryan Williams
źródło