Niniejszym postem chciałbym zapoczątkować serię wpisów mających na celu przybliżenie tematyki wytwarzania oprogramowania w metodyce Agile. Jako osoba zainteresowana tematyką chciałbym przybliżyć jej stosowanie, przy okazji zdobywając wiedzę.
Od jakiegoś czasu zastanawiam się jak to jest programować w parach. Nie miałem do tej pory takiej możliwości z w powodu polityki w firmie, co nie zmienia faktu, że byłoby to ciekawe wyzwanie. Pragnę umieścić tutaj teoretyczne rozważania na temat pair programming.
Czym jest programowanie w parach?
Programowanie w parach to praca 2 osób przy jednej klawiaturze. Może się wydawać, że produktywność takiego tandemu jest równa ilości kodu która jest w stanie napisać jedna osoba. Po pierwsze – produktywność nie można liczyć w ilościach linii kodu! Jeżeli ktoś sądzi, że jest inaczej – czekam na komentarz. Pisanie oprogramowania polega głównie na myśleniu, a dopiero potem należy skonwertować myśli do wybranego języka programowania. A więc dlaczego by nie dorzucić drugiej osoby, która odpowiedzialna by była za bycie o jeden krok przed osobą przelewającą ustalenia na kod? Na tym polega programowanie w parach. Reasumując – programowanie w parach polega na podziale ról pomiędzy uczestników – jedna osoba prowadzi, druga jest pilotem. Osoba prowadząca siedzi przy klawiaturze i pisze kod. Rolą pilota jest myślenie o następnych zadaniach, możliwych błędach oraz śledzenie kodu pisanego przez prowadzącego.
Wiemy już jak wygląda rozkład ról, ale co z tą efektywnością?
Programowanie w parach wymusza najwyższą wydajność obu programistów. Celowo użyłem słowa wymusza, ponieważ nie wyobrażam sobie, aby ktoś z pary mógł zacząć myśleć o czymś nie związanym z aktualnie rozwiązywanym problemem, gdzie w każdej z chwili może zostać poproszony o komentarz, czy radę.
Prawdą jest, że na stworzenie takiej samej ilości kodu przez parę, w porównaniu z pojedynczą osobą, należy poświęcić więcej czasu. To jest oczywista oczywistość jakby powiedział pewien mentor IV RP. Należy od razu dodać, że kod wytworzony przez parę jest bardziej przemyślany, a co za tym idzie – wyższej jakości. Należy sobie odpowiedzieć na pytanie czy chcemy mieć aplikacją napisaną szybko, czy dobrze? Zdaję sobie sprawę, że jest to pewnego rodzaju uogólnienie, jednak odpowiedź pozostawiam czytelnikom.
Tworzenie par i rotacje
Reguły dotyczące tworzenia par są bliźniacze z tymi, które obowiązują w normalnym życiu. Jeżeli osoby tworzące parę nie są ze sobą zgrane – współpraca nie będzie przebiegała prawidłowo lub wręcz nie będzie możliwa. Każda osoba jest indywidualnością. Nie należy w żadnych przypadku naciskać, aby konkretne osoby stworzyły parę. Tworzenie pary powinno odbywać się na drodze selekcji naturalnej osób zainteresowanych.
źródło: http://www.wikihow.com/Image:Pairprogramming_996.jpg, licencja: http://creativecommons.org/licenses/by/2.5/
Osoby w parze zamieniają się miejscami co jakiś czas. Niektórzy zalecają zamianę po 90 minutach twierdząc, że to najlepszy czas. Dobrym wyjście jest również zamiana wtedy, gdy pilot chce coś pokazać lub po prostu ma pomysł na rozwiązanie problemu. Zamiana może również mieć miejsce po wykonaniu sekwencji zadań, np. napisanie kodu do wcześniejszego testu, oraz napisanie kolejnego testu, tak aby osoba, która usiądzie przy klawiaturze musiała napisać kod do tego testu.
Należy pamiętać, że partner nie jest przypisany “raz na zawsze”. Rotacja jest mile widziana, a nawet zalecana. W związku z czym nasuwa się pytanie – kiedy zmieniać partnera? Najprostszą odpowiedzią jest: kiedy zajdzie taka potrzeba! Przykładem może być dłuższe zastanawianie się nad konkretnym problemem. Często jest tak, że świeży umysł zauważy wyjście z problemu dużo szybciej. Drugim ważnym aspektem zmian w parach jest to, że cały zespół wie co się dzieje w systemie, w każdym jego miejscu – mówimy o tzw. współwłasności kodu.
Ergonomiczne miejsce pracy
Dwie osoby to nie jedna. Do programowania w parach potrzebne jest miejsce. Zależy oczywiście od ustaleń między programistami, ale na ogół potrzeba dużo przestrzeni, aby zespół mógł dobrze współpracować. Swoją drogą – cała metodologia Agile wymaga odpowiednich warunków pracy, o czym będzie w innym poście.
Należy wystrzegać się takiego ułożenia, że jedna osoba jest za plecami drugiej. To nie wchodzi w rachubę z powodu czysto psychologicznych spraw. Osoba prowadząca w takim przypadku jest w ciągłym stresie, co nie sprzyja produktywności.
Biurko powinno być odpowiednio duże aby dwie osoby mogły wygodnie siedzieć obok siebie. Monitor powinien być na tyle duży, aby obie osoby miały komfortowy wgląd w kod. Dobrym rozwiązaniem są dwa monitory.
Osobowości i różnice w umiejętnościach
Nie wszyscy programiści są najwyższej klasy specjalistami. Idealnym rozwiązaniem byłoby, gdyby tak było faktycznie, ale niestety nie jest. W takim przypadku należy znaleźć taki element aplikacji, gdzie osoba mniej potrafiąca będzie w stanie szybkim czasie nadrobić zaległości i stać się ekspertem w danym obszarze.
W programowaniu w parach trzeba być delikatnym. Uwagi zwracać konstruktywne i to na ogół w formie pytań, np.: Nie sądzisz, że warto by było wydzielić ten blok do osobnej metody? Kwintesencja grzeczności, kultury, a zarazem dobra sugestia.
Nie należy się obrażać. Być może łatwiej powiedzieć to, niż wcielić w życie, ale w trakcie programowania w parach należy umieć dochodzić do kompromisów – zawsze. Jeżeli charakter danej osoby nie pozwala na prowadzenie programowania w parach należy dokonać rotacji.
Kiedy nie stosować programowania w parach?
Może się wydawać, że programowanie w parach to remedium na wszystkie bolączki wytwarzania oprogramowania. Tak oczywiście nie jest. Jeżeli przykładowo nie zapewnimy odpowiedniego miejsca pracy – programowanie w parach nie przyniesie żadnych korzyści. Jeszcze jedna ważna uwaga – jeżeli programiści mają zmienić dotychczasową organizację pracy na programowanie w parach pod przymusem, to murowanym skutkiem wprowadzenia w życie tej decyzji będzie niepowodzenie, czego skutkiem będzie spadek wydajności. Ewentualne zastosowanie metody programowania w parach powinno być decyzją zespołu, oczywiście po uzgodnieniu z władzami firmy.
Nie należy stosować programowania w parach w zespołach nie znajdujących się w jednym pomieszczeniu. Co prawda są dostępne możliwości techniczne takie jak zdalny pulpit, czy telefonia VOIP, jednak nic nie zastąpi werbalnego kontaktu będącego podstawą programowania w parach.
Podsumowanie
Programowanie w parach jest z pewnością dużym wyzwaniem dla programistów. Jednocześnie jest to praca męcząca, ale dająca zadowolenie, kod wytwarzanego oprogramowania jest lepszej jakości – zawiera mniej błędów. Samo oprogramowanie jest dużo łatwiejsze w konserwacji z uwagi na współwłasność kodu, a dług techniczny (o którym w innym poście) maleje.
Osoby programujące w parach są maksymalnie skoncentrowane na zadaniu. Rozproszenia zgranej pary jest trudne, ponieważ osoby te są pochłonięte pracą, co jest dużą korzyścią dla wszystkich – programistów z uwagi na zdrowe zmęczenie i tworzącą się więź między osobami w zespole, jak i dla firmy – z uwagi na efekty w postaci dynamicznego rozwoju aplikacji posiadającej mało błędów.
Zachęcam do komentowania! Chciałbym usłyszeć Wasze opinie i sugestie na ten temat.
