Posty otagowanePair Programming
ALT.NET a programowanie w parach
Ostatnio wywiązała się bardzo ciekawa dyskusja na liście mailingowej altdotnet na temat doświadczeń związanych z programowaniem w parach. Wszystkie osoby zainteresowane tą praktyką zachęcam do przeczytania wątku poświęconego tej dyskusji.
Najbardziej interesującym aspektem w zamieszczonych wypowiedziach jest zgodność co do tego, że programowanie w parach nie jest złotym środkiem i nie warto programować w parach przez cały czas pracy, bowiem występują czasami zadania na tyle łatwe, że programowanie w parach jest po prostu nieefektywne. Patrząc na zamieszczone w wątku przykłady, takie jak tworzenie prostych widoków, wydaje mi się to bardzo rozsądnym argumentem.
Poruszony został także temat ping pong programming, o którym pisałem także w poprzednim poście. Jak widać z wypowiedzi, wiele osób chwali sobie wykorzystanie tej praktyki w celu nauczania w zespole TDD, które nie tylko moim zdaniem jest bardzo trudne w obyciu i wymaga dłuższego okresu nauczania.
Jimmy Bogard wspomniał również o wykorzystaniu par w procesie projektowania. Z mojego doświadczenia wynika, że jest to bardzo skuteczna metoda. Należy jednak zwrócić uwagę na to, że projektowanie w metodologiach zwinnych eliminuje tak zwanny “upfont design” poprzez nieustanne projektowania. Stosując więc projektowanie w parach każda para rozpoczynając implementację kryterium akceptacyjnego tzw. “user story“, korzystając na przykład z UMLa, może wyznaczyć i przedyskutować proponowaną przez nią architekturę. Największą zaletą tego rozwiązania moim zdaniem jest to, że zostaje wymuszany proces projektowania, które często zostaje pomijane w przypadku, gdy nad danym zadaniem pracuje tylko i wyłącznie jedna osoba. Poza tym mam nadzieję, że każdy jest świadom tego, “że co dwie głowy to nie jedna” i w efekcie końcowym zapewnia to, w stosunkowo krótkim czasie, powstanie “lepszej” architektury. Projektując w parach żadna z zaangażowanych osób się nie nudzi, o czym nie zawsze można powiedzieć w przypadku większej liczby osób. Oczywiście występują również sytuacje, w których wymagany jest udział większej liczby osób, gdyż dyskutowane rozwiązanie nie dotyczy tylko jednego kryterium akceptacyjnego. Tych faz projektowania jest jednak stosunkowo mało.
1 comment Grudzień 16, 2008
Programowanie w Parach – Hot Or Not?
Mój kolega z byłej ławki Marek Goldmann poruszył dosyć ciekawy aspekt metodologii Extreme Programming, którym jest
programowanie w parach. Programowanie w parach jak i inne elementy metodologii Extreme Programming są często pomijane w trakcie implementacji metodologii zwinnych w większości firm. Prowadzi to najczęściej w późniejszej fazie projektu do utrudnień związanych z jego realizacją. Dowodem na to jest wypowiedź Jima Shorea na jego blogu. W porównaniu do innych aspektów Extreme Programming przyznaje, że nie poświęciłem wystarczającej uwagi praktyką związanych z programowaniem w parach. Wydaje mi się, że jest tak głównie, dlatego, że jako pracownik jestem przekonany o tym, że większość firm nie wprowadzi programowania w parach ze względu na koszty, z którymi się to wiąże. Zresztą jestem ciekaw ile firm w Polsce stosuje przynajmniej po części inne elementy Extreme Programming takie jak Test Driven Development czy Continuous Integration?
Jako, że żadne rozwiązanie nie jest złotym środkiem na wszystkie problemy, nie śmiem twierdzić, że wprowadzenie programowania w parach rozwiąże całkowicie większość problemów. Pewne zalety jednak są widoczne natychmiastowo. Przede wszystkim zwiększona wykrywalność błędów, która jest jednym z głównych powodów stosowania programowania w parach. Ostatnimi czasami miałem możliwość pracowania wspólnie z kolegą przy tworzeniu skryptów automatyzacji buildu i deployementu aplikacji, nad którą pracujemy. Mimo, że niektóre z opisywanych wymagań w poście Marka nie były spełnione, jestem przekonany, że nie był to czas zmarnowany. Poza wykryciem wielu bugów i wielu problemów, które pojawiłyby się w późniejszej fazie uzyskaliśmy bardzo ważny dla nas cel. Mianowicie to, że nie tylko jedna osoba jest teraz w stanie zarządzać i wprowadzać zmiany w powstałych skryptach. Czyli, mogę śmiało stwierdzić, że powstała pewna współwłasność kodu.
Powracając do wpisu Marka. W komentarzach pojawiła się ciekawa uwaga dreamera:
“Zapomniałeś wspomnieć o b. ważnej moim zdaniem rzeczy: między partnerami w parze nie powinno być zbyt dużej różnicy w doświadzczeniu/wiedzy/umiejętnościach – w przeciwnym razie przepływ wiedzy będzie minimalny (jeśli wogóle jakiś będzie) a obie osoby będą pracowały poniżej swoich możliwości – co ogólnie prowadzi do frustracji…”
Nie zgodzę się do końca z tą wypowiedzią, dlatego że dobór takiej pary może z sobą nieść również dużo zalet. Osoby pracujące przez dłuższy czas przy jednym projekcie mogą się szybko “wypalić”, przez co ich produktywność się zmniejszy lub mogą w ogóle zrezygnować z pracy. Źródłem tego problemu najczęściej jest brak dalszego rozwoju. Rozwiązaniem wówczas może być właśnie programowanie w parze z osobą mniej doświadczoną najlepiej nową w zespole. Mimo, że osoba bliska “wypalenia” w takiej parze pełni role mentora sama ponownie przechodzi proces nauczania, co daje jej poczucie rozwoju. Można by się pokuśić o stwierdzenie, że przy zastosowaniu takiego rozwiązania “upieczemy dwie pieczenie na jednym ogniu”: nowa osoba będzie poznawać nieznane jej dotychczas zagadnienia, a jednocześnie nie będzie przestoju w dalszej realizacji zadań w projekcie.
Jedną z praktyk, która moim zdaniem może dobrze zadziałać w sytuacji gdy między osobami występuje duża różnica umiejętności jest ping pong programming. W sytuacji tej osoba A bardziej doświadczona pisze test nadając pewien tok myślenia drugiej osobie B w parze, która jest odpowiedzialna za stworzenie implementacji. W trakcie gdy za “sterami” usiądzie osoba B starająca się doprowadzić kod do takiej postaci by test przeszedł, osoba A jako nawigator może koncentrować się na definiowaniu kolejnych testów i nadzorem kodu pisanego przez partera.
Metody te nie zawsze mogą przynieść zamierzony efekt, dlatego, że nie każda osoba musi chcieć pracować w parze. W tej sytuacji nie należy narzucać rozwiązań na siłę. Warto też pamiętać o tym by osoby w zespole nie pracowały w tej samej parze nie dłużej niż jeden dzień, gdyż może to doprowadzić do wielu efektów ubocznych.
W celu bardziej dogłębnego zapoznania się z praktyką programowania w parach polecam wysłuchanie podcastów zamieszczonych na stronie agiletuning.pl. Jako, że nie mam dużego doświadzenia z tą praktyką chętnie chciałbym usłyszeć o waszych przeżyciach i rozmyśleniach związanych z tym tematem.
4 comments Grudzień 11, 2008
