!FrAgile Thinking

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.