Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Pair programming, czyli jak się pracuje, gdy ktoś patrzy Ci przez ramię

Dowiedz się, kiedy programowanie w parach zdaje egzamin, jakie są plusy i minusy pair programmingu oraz sprawdź, czy to metoda dla Ciebie.

Wyobraź sobie spokojny, leniwy poniedziałek w pracy. Siedzisz z resztą teamu, spokojnie zajmujecie się każdy swoimi sprawami, powoli się budzisz, pijesz kawę i marzysz o świętym spokoju. Aż tu nagle przychodzi team leader z uśmiechem na ustach, zapałem do pracy i hasłem: A teraz dobierzcie się dwójkami! Patrzysz po reszcie działu, reszta działu patrzy na Ciebie i wspólnie się zastanawiacie, czy ten pomysł nie jest aż nazbyt… ekstrawagancki?

Spróbujmy przeanalizować argumenty za i przeciw programowaniu w dwójkach i odpowiedzieć na pytanie, czy trend na tzw. pair programming (inaczej określany też jako peer programming) jest godny uwagi, czy może to tylko chwilowa moda lub sposób, który sprawdza się tylko w niektórych organizacjach.


Dlaczego programowanie w parach?

Sama praca w parach nie jest spotykana wyłącznie w organizacjach określających się jako “zwinne”, jednak to w tym kontekście spotyka się z nią w obecnych czasach programista. Model agile (zwinnego zarządzania projektami), którego założenia zostały opublikowane w 2001 roku, cieszy się od momentu pojawienia się niesłabnącym zainteresowaniem. To dlatego, że jego założenia sprawdzają się w organizacjach nastawionych na szybki rozwój nowoczesnego produktu i jak najefektywniejsze dostarczenie klientowi tego, czego najpilniej potrzebuje w dynamicznym trybie pracy, w którym zespół nie jest w stanie całkowicie zaplanować przebiegu.

Programowanie w parach sprawdza się w organizacjach, które pracują zgodnie z metodyką agile, a jeśli chcemy być bardziej konkretni, to w szczególności w scrumie. Filozofia agile zakłada, że zamiast na zlecaniu pracownikom niżej w hierarchii organizacji zadań bez podawania im kontekstu, cała organizacja otrzymuje informacje na temat rezultatu, do którego dąży. Zamiast skupiać się na zlecaniu zadań podwładnym, ustalaniu deadline’ów, standaryzacji i kontrolowaniu całości procesu przez małą grupę menedżerów, przekazujemy więcej kompetencji i zwiększamy zakres odpowiedzialności pracowników.

W tym modelu przyjmujemy, że członkowie zespołu posiadają kompetencje, by samodzielnie pracować nad produktem i dostarczyć go klientowi. Team sam organizuje sobie pracę, decyduje kto z kim pracuje i jaką strategią dojdzie do celu – decyduje się na proces i jest odpowiedzialny za wynik (jakość produktu).


Czy trzeba przerobić całą strukturę organizacji, by móc w niej wprowadzić pair programming? 

Niekoniecznie, natomiast musimy być świadomi, że ten model wymaga większego zaufania do pracownika. Na takie rewelacje, czy to w kontekście agile, czy to na pokrewny temat tzw. turkusowych organizacji co poniektórzy zapewne uniosą brwi. Faktem jest, że danie możliwości samoorganizowania się, to bardzo duża oznaka zaufania i zmiany dotychczasowego podejścia do delegowania obowiązków.

Przede wszystkim trzeba mieć z tyłu głowy, że samo posadzenie programistów w dwójkach i zlecenie im zadania będzie przypominało bardziej pracę w szkole niż model pracy, który w zamyśle ma być charakterystyczny dla współczesnych, nowoczesnych, silnie rozwijających się firm ukierunkowanych na pracowników. Dlatego programowanie w parach, gdzie dwójka programistów łączy kompetencje i osiąga lepsze efekty razem niż osobno, ma największy sens, jeśli wspiera ono całość działań i podejścia do pracy, programowania i rozdzielania obowiązków w organizacji. 


Co to jest pair programming?

Nie chodzi wyłącznie o pracę w parach rozumianą jako pogrupowanie pracowników i przykazanie im, by przez wyznaczony czas pracowali wspólnie, a raczej o ukształtowanie całego zespołu w taki sposób, by jego członkowie działali bardziej samodzielnie, organizowali swoją pracę w podgrupach, uczyli się od siebie nawzajem i mieli poczucie, że to oni odpowiadają za realizowany projekt.

W trakcie pracy dwójka programistów korzysta z jednego urządzenia. Jeden piszący przyjmuje rolę drivera, drugi zaś navigatora. Ten pierwszy skupia się na szczegółach i drobiazgach, z kolei drugi, obserwujący, widzi szerszy obraz i kontroluje, czy drobne kroki, które wykonuje programujący, prowadzą do spodziewanego efektu.

Pary z reguły nie są przypisane do siebie na stałe. Dużo częściej zmieniają się w obrębie zespołu tak, by wszyscy jego członkowie mogli dzielić się wiedzą i pomysłami na podejście do poszczególnych problemów. Zespoły często samodzielnie decydują, kto z kim będzie pracował, co pozytywnie wpływa na inicjatywę i zaangażowanie.


Plusy pracy w parach

Przede wszystkim dwie pary oczu to dwa razy większa szansa na wykrycie potencjalnych błędów w kodzie. Czy to zagubiony średnik lub nawias, czy to moment zagubienia w linijkach kodu, czy to podpowiedź, jak można oszczędzić parę linijek dzięki innej formule. Dwie osoby mogą wymieniać się swoimi przemyśleniami, zwracając uwagę na potencjalne trudności, bądź nawet podając anegdotki z wcześniejszych, różnorodnych projektów – dzielić się tym, co się sprawdzało, a co nie.

Świadomość, że obok jest navigator, który zawsze może zareagować zanim dojdzie do potencjalnej katastrofy w kodzie sprawia, że osoba, która akurat “ma klawiaturę” może się skupić na pisaniu, nie skupiając się tak mocno na tym, że może popełnić błąd. Jednej osobie trudniej jest myśleć jednocześnie nad szczegółami i mieć ogląd całości, a w parze jest to dużo łatwiej wykonalne.

Praca w parach będzie dla wielu osób przyjemnością. Co się oszukiwać – dyskutanci i ekstrawertycy entuzjastycznie reagują na możliwość spędzenia większej ilości czasu na rozmowach. W dodatku wymiana partnerów raz na jakiś czas sprawi, że team lepiej się zintegruje, lepiej pozna i będzie czuł się swobodnie w swoim towarzystwie.

Programowanie w parach sprzyja skupianiu się na niewielkim elemencie całości – programu, projektu, produktu. Dzięki temu nie tylko można szybko wdrożyć nowych członków zespołu, ale i zmniejsza się ilość “rozgrzebanej” pracy. Poza tym różnorodność perspektyw, stylów pracy, doświadczenia czy sposobu opisu tych samych czynności, może sprawić, że druga osoba w parze zobaczy coś z innej perspektywy, wpadnie na inny pomysł. Właśnie fakt, że wychodzimy ze swojej strefy komfortu sprawia, że zaczynamy poszukiwać nowych możliwości – a przecież cała idea programowania w parach ma służyć wytworzeniu nowatorskiego, działającego kodu i zwiększeniu tempa realizacji nowych pomysłów.

Konieczność jasnego określania, czy coś jest gotowe, czy nie, sprawia, że cały zespół wie, na czym stoi. W sytuacji, gdy nad projektem pracuje tylko jedna osoba, z reguły na etapie pracy nad kodem zdarzają się skróty myślowe czy fragmenty, które odkładamy “na później”. Kiedy obok siedzi druga osoba, która często dopytuje, czemu coś jest niedokończone lub nierozwiązane, liczba takich problematycznych fragmentów znacznie spada.

Kiedy czujemy, że pracujemy nad czymś bezpośrednio, to automatycznie staramy się bardziej, bo wiemy, że nasza praca przekłada się na dostarczane klientom rezultaty. 


Minusy pracy w parach

Oczywistym minusem dla pracownika jest potencjalne ciągłe poczucie, że ktoś zerka nam przez ramię i wyszukuje nasze błędy, co może stresować i obciążać psychicznie. Dlatego ważne jest, by para zamieniała się miejscami, by nie było tak, że tylko jedna osoba pisze, a druga kontroluje i nigdy na odwrót. 

Minusem tego modelu jest też fakt, że pracować w dwójkach cały czas po prostu się nie da. Jest to obciążające. Zaleca się odcinki czasu od dwóch do dwóch i pół godziny programowania w parach poprzedzielane innymi czynnościami. Problematyczna może być sytuacja, gdy cały team ma w różnym czasie w ciągu dnia spotkania, ponieważ dla efektywności pracy w parach ważne jest, by dwójki miały wydzielony czas pracy tylko dla siebie, w którym nie będą odrywane od samego kodowania.

Z punktu widzenia organizacji trzeba pamiętać, iż celem programowania w parach jest wzajemna pomoc, a nie ciągłe, przedłużające się szkolenie. Nie w tym rzecz, by doświadczonego programistę połączyć z początkującym i traktować pair programming jak okres wdrożenia. Połączenie doświadczonej i początkującej osoby może być świetnym sposobem na wdrożenie nowego w zespole, ale fatalnym rozwiązaniem na dłuższą metę. 

Idea pracy w dwójkach wyda się uciążliwa, przynajmniej na początku, tym przyzwyczajonym do kodowania samodzielnie, w ciszy i spokoju. Jeszcze gorzej, jeśli w parze wylądują dwie osoby, które zwyczajnie się ze sobą nie dogadują. Problemem może stać się nawet ustalenie odpowiednich warunków pracy jak jasność monitora, bo co innego przysiąść się na chwilę do innej osoby, co innego musieć wypracować takie stałe warunki, w których obie osoby czują się komfortowo przez dłuższy czas.


Pair programming – dla kogo i kiedy?

Cofnijmy się do wspomnianej metodyki agile, bo to z niej wywodzi się idea programowania w parach. Otóż zarządzanie zwinne może być wprowadzone w całej organizacji lub tylko w jednym zespole. Może być tak, że organizacja działająca w stosunkowo tradycyjny sposób przeprowadza, nazwijmy to, eksperyment, i wprowadza inny sposób pracy w jednym z zespołów. 

Dlatego jeżeli masz poczucie, że chcesz wprowadzić w zespole programowanie w dwójkach, to nic nie stoi na przeszkodzie, by spróbować i ocenić samodzielnie, co się zmienia i czy na lepsze.

Błędem i dużym skrótem byłoby jednak założenie, że tylko dlatego, iż jakiś model pracy jest nowoczesny i atrakcyjny, sprawdzi się w każdej organizacji. Gdy już na początku pracy nad projektem wiemy, co stanie się w kolejnych etapach, stosowanie modelu agile (który wspomaga częste modyfikowanie pomysłów i dynamiczne reagowanie na zmiany i prośby klientów) trochę mija się z celem. 

Najważniejsze jednak, to spróbować zastosować to podejście i odkryć jego wady i zalety w swoim własnym zespole, a potem wyciągnąć wnioski i zdecydować, czy warto kontynuować pracę w dwójkach.

Rozpocznij dyskusję
Zobacz więcej na Bulldogjob