Jak badacie podczas programowania w parach?

20

Niedawno zacząłem od nowej pracy, a parowanie pomogło mi bardzo szybko zacząć działać. Mam jednak trudności z przeprowadzeniem krótkich wspólnych badań podczas naszego przepływu pracy, obejmujących funkcje API, przykłady kodu lub opcje poleceń. Kierownik mojego zespołu wzywa nas do przeprowadzenia wszystkich badań na naszej stacji parowania, a nie na poszczególnych laptopach, oraz do zsynchronizowania naszych badań poprzez ustne negocjowanie kroków między różnymi zasobami sieciowymi.

Badam, czytam i wchłaniam informacje inaczej niż mój partner w parowaniu i czuję się znacznie bardziej produktywny, kiedy mogę śledzić wątek badań na następnej stronie internetowej dokładnie wtedy, kiedy chcę, zamiast starać się zachować dokładne tempo i miejsce z czytanie mojego partnera. Obaj jesteśmy sprytni i szybcy, ale nie możemy nie poradzić sobie z różnymi ruchami i chwilowymi prędkościami, gdy wymyślamy różne rzeczy. Wydaje się, że o wiele łatwiej jest rozglądać się indywidualnie przez minutę, dopóki jedno z nas nie powie „Mam to”, a potem wróć do siebie i napisz kod.

Jak sparować program, jak wykonujesz krótkie zadania badawcze? Co jest dla Ciebie najlepsze i jak zachować synchronizację z partnerem?

traffichazard
źródło

Odpowiedzi:

14

Programowanie w parach jest narzędziem. Jak każde narzędzie, zdarzają się chwile, kiedy jest ono użyteczne, i czasy, kiedy nie jest. Korzystanie z odpowiednich narzędzi do pracy może obejmować różne narzędzia w różnych momentach, w tym ich kombinację.

Tak więc, jeśli sytuacja tego wymaga, oderwij się w razie potrzeby i spotkaj się w razie potrzeby.

Na przykład, jeśli oboje coś badacie, a jedno z was znajdzie coś interesującego, być może oboje możecie to zobaczyć razem. Ale jeśli oboje staracie się znaleźć odpowiedź, czasem rozdzielanie się w celu wyszukiwania równoległego jest bardziej produktywne.

Gdy jedno z was znajdzie odpowiedź, wznów pair programmingsesję.

Krótko mówiąc, nazywa się to Pair Programming,nie Pair Researching.

jmort253
źródło
8

Kiedy sparuję program, ktokolwiek nie pisze na głównym komputerze, ma dostęp do laptopa w celu przeprowadzenia badań. To sprawia, że ​​cały proces jest mniej frustrujący dla „nietypowego” członka pary.

westcoastdiff
źródło
1
Czy nie-typer nie jest zatem odrywany od tego, co stara się osiągnąć para? Jak on lub ona nadrabia zaległości drugiego programisty, gdy nie patrzyli?
Adam Lear
2
Jeśli dwie osoby pracują na dwóch komputerach, to nie jest programowanie w parach!
Johnsyweb,
6
Jeśli osoba na stanowisku programowania w parach bada, a nie programuje, wówczas proces nadrabiania zaległości polega po prostu na: „Hej, koleś! Sprawdź, co właśnie znalazłem ...”. To, że obie osoby badają coś niezależnie, nie oznacza, że ​​przestają się komunikować.
jmort253
Nie sądzę, żebym chciał pójść tak daleko - kiedy pisze się kod, chcę na to patrzeć. Mówię więcej o sytuacji, w której oboje wiemy, co musimy zrobić dalej, ale nie wiemy, jak to zrobić - poświęcamy chwilę, aby to sprawdzić.
traffichazard
2
Aby wyjaśnić moją odpowiedź. Nie-typujący członek na ogół prowadziłby badania tylko wtedy, gdy w tym czasie nie pisano kodu. Na przykład członek pisania też buduje lub bada. @Johnsyweb Myślę, że ważne jest, aby uznać, że programowanie w parach (lub coś w tym zakresie) nie jest propozycją typu wszystko albo nic.
westcoastdiff
3

Równoległe badania są bardzo przydatne, jeśli szukasz odpowiedzi w różnych lokalizacjach. „Czytasz ten artykuł, przejrzę książkę i zsynchronizujemy za 10 minut”. Ktokolwiek wymyśli (możliwe) rozwiązanie, powinien oczywiście podzielić się wiedzą.

Jednym świetnym sposobem na poradzenie sobie z tym jest użycie „ spike ”. Dzieje się tak podczas spotkania szacunkowego, aby zwiększyć dokładność szacunków. Krótko mówiąc, odkładasz oszacowanie konkretnego zadania do momentu, gdy szczyt (timeboxed) zostanie zakończony i będziesz wiedział wystarczająco dużo o problemie, aby pewnie nadać mu pewną liczbę. Może to obejmować wypróbowanie nowej biblioteki lib lub komponentu lub napisanie małego programu jako dowodu koncepcji.

Martin Wickman
źródło