Programowanie w parach, gdy kierowca i obserwator mają różne poziomy umiejętności i doświadczenie

Wiem, że programowanie w parach jest zwinną techniką tworzenia oprogramowania, w której dwóch programistów pracuje razem na jednym stanowisku roboczym. Jeden, kierowca, pisze kod, a drugi, obserwator, przegląda każdą linię kodu podczas wpisywania.

Ale zastanawiam się, czy strategia nadal działa w tej sprawie. Na przykład

• jeśli mają zupełnie inny poziom umiejętności programowania.
• jeśli jeden nigdy nie doświadczył problematycznej domeny, a inny ma
• Czy nadal jest OK, jeśli mają niski poziom umiejętności programowania?

Czy możesz zasugerować strategię programowania par w powyższym przypadku?

Zakładając, że bardziej doświadczona osoba w parze ma temperament, aby mentorować drugą osobę, powiązanie osoby z małym doświadczeniem w języku lub dziedzinie problemowej z doświadczoną osobą ułatwi transfer wiedzy. Mniej doświadczona osoba miałaby mentora, który udzieliłby im wskazówek dotyczących języka, domeny, aplikacji oraz najlepszych praktyk lub konwencji zespołu.

Na C2 wiki znajduje się interesujące streszczenie na temat transferu wiedzy za pomocą programowania w parach . Bardziej starsza osoba, która została powołana do roli mentora zespołu, wiele się nauczyła od młodszych programistów, a jego wiedza wzrosła nawet w wyniku połączenia z młodszymi, mniej doświadczonymi programistami. Istnieją również inne historie o tym, że eksperci-programiści współpracują z ekspertami w dziedzinie.

To właśnie zostało stworzone programowanie przypadków użycia pary: dzielenie się doświadczeniami między starą brodą i młodym konikiem polnym.

Jest to dwukierunkowe dzielenie: zwinne owady mają wiele do nauczenia dla reumatycznych mózgów.

Kiedy awansowałem do mojego obecnego zespołu, byłem nowicjuszem w J2EE, ale byłem ekspertem w tej dziedzinie. Mój starszy (nowy lider zespołu) był wykwalifikowany w J2EE, ale nie na platformie.

Myślę, że nauczyłem się więcej o Java2EE w ciągu tych 4 miesięcy z programowaniem parami niż czytaniem książki, a lider zespołu również dowiedział się o platformie.

Różnica w doświadczeniach między nimi jest kluczem do sparowania programowania imho.

Opiszę moje doświadczenie i spróbuję wyciągnąć z tego „strategię”.

Kiedyś sparowałem z kompletnym nieprogramowującym. Był ekspertem w temacie opracowanego przez nas oprogramowania. Przeciwnie, nie miałem doświadczenia w dziedzinie problemów. I on też był w tej chwili moim przełożonym (wiem, że to może brzmieć dziwnie :)

Główną zaletą tej metodologii było to, że musiałem wyjaśnić wdrożenie wielu rzeczy z jego dziedziny wiedzy, zapewniając w ten sposób dokładność wdrożenia i jego zrozumienie procesu, co oznaczało, że rozumiał, dlaczego zajęło to tyle czasu.

Kolejną korzyścią jest łatwe skupienie się na zadaniu, brak rozpraszania uwagi (ha-ha, wyobraź sobie otwarcie Twittera przed nosem szefa).

Czasami było to jednak dość onieśmielające, ponieważ nawet przerwa na herbatę stała się dość „odwracaniem uwagi od pracy” (nie z jego punktu widzenia; po prostu niewygodne było proszenie o przerwę i tak dalej).

Tak więc nie jest to tak naprawdę programowanie parami, ponieważ właściwie nie mógł przejrzeć kodu, który został wpisany. Wydawało się jednak, że to rozsądna strategia (przynajmniej przez jakiś czas). Ostatecznie zadziałało w ogóle ze względu na względną prostotę zarówno metodologii programistycznej (mam na myśli, że nie było w niej złożonych technik projektowania oprogramowania, takich jak Wzorce OOP) i tematyki. To nie zadziałałoby, gdybyśmy musieli opracować kompilator. Wierzę, że nadal mogłoby to działać, gdyby nie-programista obserwator uczestniczył w procesie opracowywania małych, jasno określonych utworów. Powiedzmy, że jest w porządku, aby obserwował programowanie funkcji „oblicza parametr X z Y i Z według danego algorytmu”, ale może nie być tak dobrze, aby obserwował cały proces projektowania systemu (co oznacza rozwój architektury oprogramowania, tj. Hierarchię zajęcia,

Myślę, że działałoby to jeszcze lepiej, gdyby miał jakieś podstawowe umiejętności programistyczne, ponieważ nie musiałbym wyjaśniać „czym jest tablica”.

Mam nadzieję, że to pomoże :)

Z mojego doświadczenia wynika, że ​​jeśli obaj programiści mają niski poziom umiejętności, może to stanowić problem. W takim przypadku często występuje tendencja do próbowania kopiowania i wklejania. Myślę, że dobrym pomysłem może być nie łączenie ze sobą dwóch początkujących programistów, dopóki nie osiągną określonego poziomu określonego przez zespół.

W przeciwnym razie programowanie w parach może być świetnym pomysłem, zakładając oczywiście, że dwóch facetów jest gotowych podzielić się tym, co wiedzą. Jest to nie tylko świetny sposób na informowanie wszystkich o kodzie źródłowym, ale także dobre miejsce na nowe pomysły i dyskusje.

Tak długo, jak członkowie zespołu szanują się nawzajem, programowanie w parach może być korzystne bez względu na poziom doświadczenia programistów. Nawet jeśli młodszy programista wykryje kilka błędów składniowych (które wszyscy popełniamy!) Przed bardziej doświadczonym programistą, to wciąż zaoszczędzony czas na kompilowaniu kodu.

Myślę też, że może to otworzyć podejście programisty do możliwości innych członków ich zespołu, szczególnie jeśli mają otwarty umysł i oczekują, że każdy może cię czegoś nauczyć.