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

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.

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.

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.

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ł.

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 .

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.

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.