Pomyśl o tym jak pracuje programista. Co widzisz? W naszej wyobraźni powstaje obraz, na którym widać całkiem spore biurko z ustawionym komputerem i dwoma wielkimi monitorami. Na biurku leży stos papierów, na których są narysowane różnego rodzaju schematy, strzałki, wykrzykniki oraz pojedyncze słowa. Obok stoi kubek z napisem „Insert coffee to get code”, wypełniony do połowy zimną kawą, a przy tym biurku siedzi pochylony jeden gość w okularach i koszuli w kratę. Słowem klucz jest w tym opisie słowo: jeden. Bo jakby to było możliwe, że przed jednym komputerem z jedną klawiaturą i jedną myszką siedziałyby dwie osoby? Każdy z nas przecież jest w stanie wyobrazić sobie sytuację kiedy kolega/współpracownik lub ktoś postronny zagląda nam przez ramię i tylko samym zaglądaniem wzbudza w nas agresję i chęć mordu – nikt przecież nie lubi gdy inna osoba zagląda mu przez ramię. I tutaj właściwie można byłoby zakończyć nasze dywagacje – gdyby nie to, że w ostatnim czasie bardzo mocno na popularności zyskuje idea, która sprzeciwia się temu co przed chwilą napisaliśmy. Chodzi o pair programming – czyli programowanie w parach.
Jeżeli nie jesteś zaznajomiony z tematem pewnie pierwsze o czym pomyślałeś to coś w stylu „Dwóch programistów przy jednym komputerze? To brzmi jak całkowita strata roboczo godzin i potencjału tych dwóch osób! Przecież każdy z nich mógłby pracować nad innym projektem i w tym samym czasie wytworzyć dwa razy więcej gotowego produktu!”. Nic bardziej mylnego! W niniejszym artykule postaramy się przedstawić inny punkt widzenia, związany z programowaniem w parach – jego plusy (których jest całkiem sporo!) oraz minusy – wszystko poparte doświadczeniem oraz badaniami, które zostały przeprowadzone wśród programistów.
Zacznijmy może od krótkiej historii tej metody pracy. Pair Programming w obecnej formie istnieje jako element metodyki zwinnej (Agile). Same korzenie PP sięgają jednak znacznie głębiej – termin „Dynamic Duo” został użyty już w roku 1992 przez Larryego Constatina, który podczas raportu na temat firmy Whitesmiths Inc. Wspomina o tym, że 
przy jednym terminalu znajdowało się dwóch programistów. Sama firma istniała w latach 1978-1988 (czyli więcej niż dwadzieścia lat przed publikacją manifestu na temat metodyki Agile). Następnie w roku 1995 wzór programowania w parach ma swój krótki opis w rozdziale „A generative Development-Process PAttern Language”, pierwszej książki na temat wzorów programowania „Pattern Languages of Program Design”. Najbardziej znanym jednak przykładem jest wykorzystanie programowania w parach z roku 1998. W załodze C3 (Chrysler) jako jedna z dwunastu praktyk opisanych jako paradygmatu ekstremalnego programowania, wykorzystywanego w kreacji systemu, który byłby odpowiedzialny za wypłacanie pensji pracownikom Chryslera. Od tego czasu idea programowania w parach nie uległa już większym zmianom – w 2000 roku zostały przyjęte określenia „drivera” oraz „nawigatora” (utrzymywane do dziś). W następnych latach powstały liczne odmiany jak Ping-Pong programming, tri-programming.
A więc czym tak dokładnie jest programowanie w parach? Jak już przedtem nadmieniliśmy, jest to jedna z metod używanych w procesach zwinnych. Tak jak sama nazwa wskazuje przy jednym stanowisku pracy znajduje się dwóch różnych programistów, którzy w tym samym momencie skupiają się na rozwiązaniu jednego problemu. Wyróżnione są tutaj dwie role – drivera – czyli osoby, która aktualnie „posiada” klawiaturę i zajmuje się pisaniem kodu, oraz nawigatora – który prowadzi osobę piszącą kod oraz zwraca uwagę na istotne błędy, które mogą się pojawić podczas tworzenia aplikacji (a które mogą umknąć osobie na stanowisku drivera). Ważnym elementem jest to, że role nie są przypisane na stałe do poszczególnych osób – idealnym rozwiązaniem jest sytuacja, w której role są wymieniane w krótkich interwałach czasu (15-30 minut). Dodatkowo warto odróżnić programowanie w parach od mentoringu, w którym bardziej doświadczony kolega pomaga wdrożyć się osobie mniej doświadczonej (mimo, iż jest to też pewna istotna wariacja programowania w parach). Będąc przy mentoringu warto wspomnieć o rodzajach par, które można stworzyć:
- senior – senior (mid) – takie pary mogą zajmować się najbardziej skomplikowanymi zagadnieniami. Dzięki wysokiemu poziomowi doświadczenia jaki wnoszą obydwie osoby powstaje możliwość wzrostu wydajności pisanego kodu (gdyż nawigatorowi łatwiej dostrzec usprawnienia, które można wprowadzić). Wzrost wydajności zazwyczaj występuje w takich parach – aczkolwiek programiści z dużym doświadczeniem często są pracownikami w dużej mierze samowystarczalnymi.
- mid – mid – osoby, które według badań najwięcej czerpią z programowania w parach (i osiągają największy wzrost wydajności). Jest to skutkiem wymiany doświadczenia, którego u osób na tym poziomie jest już całkiem dużo, aczkolwiek nie jest to taka biegłość jaką reprezentuje osoba na stanowisku seniora.
- junior –junior (lub dwójka studentów) – takie pary również czerpią bardzo dużo z programowania dwójkami. Dzięki wymianie doświadczeń są oni w stanie rozwiązywać problemy nie tylko szybciej, ale również bardziej efektywnie (przy okazji ucząc się). Problemem stanowi natomiast sytuacja, w której obydwie osoby nie są w stanie zauważyć tego, iż podążają złą drogą w rozwiązywaniu problemu (coś, o czym bardzo często, myślą wcześniej programiści z większym doświadczeniem).
- senior(mid) – junior – połączenie zdecydowanie najbardziej korzystne dla osoby z mniejszym doświadczeniem. Dzięki współpracy z osobą o większych umiejętnościach proces uczenia się jest znacznie przyspieszony – dodatkowo starszy stażem kolega jest w stanie dostatecznie wcześnie zauważyć błędne rozumowanie udzielić istotnych rad. Senior natomiast może zrewidować swoją wiedzę i poprawić jakość kodu, dzięki pytaniom zadawanym przez juniora. Z drugiej strony jednak , osoba starsza stażem może odczuwać frustrację spowodowaną spowolnieniem pracy i tłumaczeniem trywialnych zagadnień młodszemu koledze.
A więc czy praca w parach może pozytywnie wpływać na jakość tworzonego oprogramowania? Zacznijmy przede wszystkim od czynników, które mogą wpływać na jakość pracy. Jak już wspomnieliśmy wcześniej – ważnym punktem jest dobranie osób pod względem doświadczenia. Z reguły najlepiej funkcjonują pary, które posiadają zbliżoną ilość wiedzy – dzięki temu pisanie odbywa się na zasadzie współpracy, nie zaś na zasadzie mentoringu. Dodatkowo, warto zauważyć, że największy wzrost produktywności odnotowują pary na średnim i niskim poziomie doświadczenia. Kolejnym istotnym czynnikiem są umiejętności socjalne i świadomość tej metody pracy u osób zaangażowanych w programowanie. Poważnym problemem są sytuacje, w których jedna z osób odcina się od pracy drugiej, przyjmując rolę obserwatora (a nie aktywnego uczestnika) lub na odwrót – przyjmuje zasadę, że tylko on jest w stanie rozwiązać to zagadnienie i zdecydowanie wydłuża czas bycia driverem. Na produktywność wpływa również to, jakim poziomem sympatii darzą się obydwie osoby – kiedy jest on zbyt niski, praca może powodować konflikty oraz narastającą frustrację. Kiedy będzie zbyt wysoki, istnieje możliwość, że osoby bardziej skupią się na socjalnym aspekcie współpracy. Dochodzą do tego też czynniki bardziej prozaiczne, jak np. miejsce przy biurku, które pomieści dwie osoby, monitory, które nie będą ograniczały widoczności, poziom hałasu w biurze czy chociażby takie podstawowe czynniki jak higiena osobista.
Co na ten temat mówią więc badania? Zacznijmy od końca – spójrzmy na początek na wykres, który przedstawia opinie z różnych badań ilościowo:
Rys. 1 Tabela, która przedstawia ilościowo ogólne wyniki badań na temat programowania w parach.
Jak widać, wyniki są całkowicie jednoznaczne – znacząca część badań przedstawia kodowanie w parach, jako proces, który usprawnia tworzenie oprogramowania we wszystkich dziedzinach – produktywności technicznej, jakości programu, poprawy osiągnięć naukowych (w przypadku studentów) oraz poprawy satysfakcji. Tylko jedne badanie wykazało pogorszenie produktywności programistów.
Aby znaleźć pozytywne skutki programowania w parach wystarczy, chociażby, odwołać się do pracy „The Collaborative Software Process” autorstwa Laurie Ann Williams. Wspomniane w tej pracy czynniki pozytywnie wpływające na proces to, między innymi:
- Presja partnera – sprawia, że poświęcamy mniej czasu na rzeczy niezwiązane z programowaniem – rozmowy telefoniczne, sprawdzanie e-maili oraz przeglądanie sieci,
- wspólne myślenie – ułatwia znajdywanie łatwiejszych oraz wydajniejszych rozwiązań,
- wspólne sprawdzanie napisanego kodu – ułatwia szybsze wyłapanie błędów,
- debugowanie poprzez tłumaczenie – pomaga w zrozumieniu działania napisanego kodu
Wyniki badania przedstawione są na wykresie:
Rys. 2 Ilość zaliczonych testów dla napisanego kodu. Niebieski słupek przedstawia pojedynczych programistów, natomiast jasno-fioletowy pary.
Z wykresu widać, że kod dostarczony przez pary był o wiele lepszej jakości – w każdym zadaniu występuje co najmniej 10% poprawa ilości spełnionych testów oprogramowania. Wraz z przeglądaniem kolejnych wykresów, przedstawiających wyniki badań, możemy zaobserwować pozytywny wpływ, nie tylko w zmniejszeniu ilości błędów:
Rys. 3 Wykres przedstawiający czas spędzony nad rozwiązywaniem danego problemu.
Rys. 4 Ilość linii kodu w poszczególnych programach.
Kolejne wykresy przedstawiają kolejne zalety programowania w parach – po pierwsze zauważamy, iż programy stają się bardziej wydajne i zwarte – warto zauważyć, że dzięki programowaniu w parach programiści zaoszczędzili nawet 25% linii kodu, co jest wynikiem wyższej optymalizacji danego programu. Wykres numer 3 przedstawia natomiast średnią ilość czasu przypadającą na wykonanie zleconego zadania. Można zauważyć, że czas oczekiwania na gotowy produkt skrócił się nawet o 40%. Badania podają również, że czas roboczo-godzin wymaganych na dostarczenie produktu wydłużył się o około 15% – nie mamy tutaj w takim razie podwójnego kosztu wytworzenia produktu. Mówiąc o kosztach (bo przecież o to nam najbardziej chodzi) możemy zajrzeć na kolejny wykres przedstawiający jak zmieniają się koszty w czasie:
Rys. 5 Oszczędności zmieniające się w czasie.
Jak widać w t=0 koszty są wyższe – jest to związane z zatrudnieniem dwóch programistów do rozwiązania jednego problemu. Wraz z upływem czasu zauważamy jednak drastyczny wzrost oszczędności. Skąd się one biorą? Głównie z oszczędności na naprawiania bugów pojawiających się w naszym produkcie. Powołując się na światowego lidera w dziedzinie IT – IBM – koszt błędu w oprogramowaniu rośnie bardzo szybko – jeżeli złapiemy go w fazie testowania reprodukcyjnego kosztuje on nas zazwyczaj 4-5 razy więcej niż w fazie developerskiej. Jeżeli natomiast nasz błąd prześlizgnie się do strefy produkcyjnej – jego koszt może wzrosnąć aż 100-krotnie! Pomijając już sam aspekt błędów w oprogramowaniu, możemy również zwrócić uwagę na optymalizację działania – im lepiej nasz produkt działa w swojej pierwszej wersji,tym mniej mamy „bólu głowy” w przyszłości.
W takim razie, dlaczego programowanie w parach nie jest absolutnym przymusem w każdym miejscu pracy?
Problemem, na który zwraca uwagę autorka badania, są predyspozycje programistów do pracy w parach. W idealnym świecie, każdy programista potrafi odnaleźć się w roli drivera oraz nawigatora, natomiast w naszym, nieidealnym świecie, pojawia się sporo problemów z implementacją tego sposobu pracy. Autorka zwraca uwagę na typy charakterów osób współpracujących ze sobą – niektórzy z nich mogą być zbytnimi myślicielami, przez co w roli nawigatora nie starają się zabierać głosu. Inni natomiast mogą nie czuć się swobodnie w obecności drugiej osoby zaglądającej jej przez ramię – powoduje to wzrost frustracji i niezadowolenia z pracy.
Podsumowując – programowanie w parach może być świetnym rozwiązaniem, jeżeli jest dobrze zaimplementowane. Role, które są przydzielane wymagają jednak od pracowników pewnej dyscypliny oraz wzajemnego szacunku i zrozumienia, ponieważ opierają się one na socjalnej interakcji dwóch specjalistów. Ta interakcja przynosi natomiast wymierne korzyści – w zależności oczywiście od wielu czynników, na które pracując w pojedynkę nie zwracamy najmniejszej uwagi. Jeżeli programowanie w parach zostanie wprowadzone w dobry sposób, może przynieść znaczne korzyści finansowe i jakościowe produktu. Warto jednak przy takim rozwiązaniu zaopatrzyć się w dodatkowy zapas dobrej kawy – jeżeli jej konsumpcja wśród programistów wzrasta wraz z jakością pisanego kodu, to bardzo szybko możemy spotkać się z jedenastą plagą Egipską – brakiem kawy ;).
IT-Leaders.pl to pierwsza na rynku platforma łącząca Specjalistów IT bezpośrednio z pracodawcami. Anonimowy, techniczny profil i konkretnie określone oczekiwania finansowe to tylko niektóre z cech wyróżniających platformę. Zarejestruj się i zobacz jak Cię widzi p