Programowanie w parach jest prostym i starym pomysłem, kojarzonym z technikami zwinnymi, w szczególności z extreme programming. Posiada sporo zalet, a mimo to obecnie jest omal nieużywane w projektach zdominowanych przez scrum. Czy słusznie?
Nie trzeba chyba pisać, że programowanie w parach polega na programowaniu w parach. Dwóch programistów siada przed jednym komputerem i razem pracują nad fragmentem kodu. Zwykle jeden więcej pisze, a drugi komentuje, ale nic nie stoi oczywiście na przeszkodzie, by wymieniać się klawiaturą i myszą od czasu do czasu. Co w tym takiego interesującego? Otóż ciekawe rzeczy dzieją się, kiedy posadzi się dwóch koderów obok siebie…
Po zerowe – rosną koszty “w Excelu”. Dwóch programistów siedzi nad jednym zadaniem! Toż to przecież jakby dwóch glazurników, dwóch hydraulików sobie rury, kafelki podawało i jeszcze gawędziło przy tym, zamiast robić równolegle. Koszmarna strata czasu, z perspektywy zarządzających, którzy nie dość dobrze znają specyfikę pracy programistów. Tylko, że jednak nie do końca tak jest, bo kodząc w parach programiści…
…obserwują się wzajemnie podczas pracy. To znaczy, że się uczą. Czasami rzeczy przydatnych, czasami trików. Swego czasu z kolegą w jednej z firm programowałem w parze. Zauważył on, że zamykam okno w Windows dwoma kliknięciami w lewy górny róg. Tak go to zaskoczyło, że zaczął chodzić po biurze i pytać innych, czy znali ten sposób. Co dla mnie dziwne niewiele osób go kojarzyło, co tym mocniej zachęcało go do odwiedzania kolejnych biurek. Nie jest to rzecz jasna przykład chwalebny, ale anegdota pokazująca, że pracując nawet wiele lat z jakimś narzędziem możemy nie czegoś nie dostrzegać. Wielokrotnie miałem okazję coś u kolegów i koleżanek podpatrzyć. I zawsze wpływało to pozytywnie na moje umiejętności.
Obserwowanie własnej pracy to nie tylko uczenie się trików. To także korygowanie szkodliwych nawyków. Sami możemy nie zauważyć, jak wiele czasu marnujemy na pewne czynności, dopóki ktoś inny nie zwróci nam uwagi, że można to zrobić lepiej, szybciej, prościej, wydajniej. Programując w parach uczymy się sprawności w działaniu, korygujemy się wzajemnie. To wielka wartość. Naprawdę. Programowanie to nie pisanie literek na klawiaturze, ale myślenie i nauka. Dlatego im szybsza edukacja, tym lepszy programista, tym sprawniejszy zespół.
Po drugie (pierwsze było po zerowym oczywiście) co dwie głowy to nie jedna i szybciej można wyłapać błąd. Błąd to taki nowotwór jest. Jak jest mały, no dwie komórki, trzy linie kodu, to cyk skalpelem, dwa kliknięcia, spacja i po kłopocie. Jednak jeśli się rozrośnie, jak poczekamy dwa lata to już będzie nie lada operacja. A jak przetrwa piętnaście lat, to już nikt go nie ubije, tego buga, za to bug może ubić produkt, czyli nosiciela. Po to robimy zresztą code review – żeby szybko bugi ubić. Jednak nic nie ubija buga szybciej, niż zauważenie go w momencie pisania kodu. Do tego trzeba jednak pisać kod we dwójkę.
Po trzecie kod jest jak podręcznik. Nikt nie lubi niezrozumiałych, bełkotliwych książek, z których nie idzie się dowiedzieć o co chodzi. Tak samo programiści nie lubią kodu, którego nie można zrozumieć po pierwszej lekturze, ale trzeba nad nim ślęczeć jak na wierszami Norwida. Jak mamy akurat Cypriana w zespole, to trzeba go okiełznać, bo się za pół roku nie połapiemy i będziemy jęczeć, że ideał naszego kodziku sięgnął bruku. Oczywiście code review da radę, ale można tam dyskutować dniami i sprintami, a we dwójkę przy kawie i jednej klawiaturze jest szybciej.
Po czwarte motywacja. Miałem w jednej pracy kolegę, który opanował do mistrzostwa sztukę zasypiania na siedząco. Oczywiście trzeba być empatycznym i jak ktoś ma akurat małe dziecko albo problemy życiowe, to niech śpi, na zdrowie, ale akurat ów koder był dość młody, bezdzietny i jego problemy polegały na grze do późna na plejce. Generalnie ciężko jest spać, jak ktoś siedzi przy naszym biurku. Ciężko też oglądać filmiki na YouTube, kupować na OtoMoto auto, a już najciężej wysyłać CV, bo i to podobno niektórzy robią. Programowanie w parach motywuje. Chcemy się wykazać, nie możemy się obijać – działamy sprawniej. Dlatego też zresztą trzeba stosować z umiarem, a nie osiem godzin dziennie, bo każdy potrzebuje odrobiny samotności w tłumie openspace’u przy własnym biurku. Natomiast godzina, dwie, może trzy dziennie mogą być zdrowo pobudzające.
Dużo zalet, mówiąc krótko. Czemu tak mało popularna ta technika? Sądzę, że scrum ma tu coś do rzeczy – nie można się choćby o ile mi wiadomo przypisać we dwójkę do jednego zadania. Również perspektywa nietechnicznego product ownera może być negatywna – z pozoru we dwójkę programiści zrobią więcej. Praktyka pokazuje, że zrobią więcej, ale bugów, ale to już ciężko zauważyć nie będąc na linii frontu. Wydaje się także, że sami programiści często nie przepadają za pracą w parach – boją się konfrontacji, nie chce im się tak aktywnie spędzać czasu, nie widzą takiej potrzeby, nie lubią tego. W sumie przywykliśmy wszyscy do pisania w pojedynkę. Osobiście jednak zachęcam, gorąco zachęcam do programowania w parach. Daje to zaskakująco wiele i zdecydowanie warto jest przynajmniej spróbować.
Argumenty które podajesz nie przekonają “biznesu”.
Programowanie w parach ma wiele zalet:
* jest chyba najlepszym sposobem na transfer wiedzy co jest szczególnie ważne podczas okresu próbnego i okresu wypowiedzenia.
* Podnosi bus-factor w organizacji i sprawia że jednostki nie-zwalnialne przestają takie być.
* Wymusza interakcje między członkami zespołu, stereotypy o programistach nie wzięły się z nikąd. Jeżeli ludzie ze sobą rozmawiają trudniej jest im się potem rozstać, a to podnosi poprzeczkę konkurencji próbującej podkupić danego specjalistę.
Należy też wspomnieć o wadach.
Po pierwsze pracując w parach robi się wolniej, nie 2 razy ale jakieś 1,5 raza.
Ludzie nie są w stanie pracować na pełnych obrotach cały czas i potrzebują odpoczynku. Obie osoby z pary muszą znaleźć czas na OLX.
Są też problemy przy pracy zdalnej, a przy asynchronicznej jeszcze większe – trzeba się synchronizować i dobrać odpowiednie narzędzia.
Ostatecznie praca w parach, podobnie jak testy automatyczne, jest jak polisa ubezpieczeniowa: obniża w sposób przewidywalny zyski dzisiaj na rzecz uniknięcia dużych i nagłych kosztów w przyszłości.
Bardzo dobre uwagi. Świetnie to wypisałeś w zwarty, krótki sposób.
Niektóre z rzeczy, które opisałeś poruszałem (o czasie na OLX i odpoczynku (“Dlatego też zresztą trzeba stosować z umiarem, a nie osiem godzin dziennie, bo każdy potrzebuje odrobiny samotności w tłumie openspace’u przy własnym biurku. Natomiast godzina, dwie, może trzy dziennie mogą być zdrowo pobudzające.”), ale o bus-factor nie pomyślałem. Co do wolniejszej pracy, to ponieważ moim zdaniem więcej się jednak poprawia bugów, chodzi na spotkania i robi innych pobocznych spraw niż samo kodzenie, to moim zdaniem jest to pomijalna wada, aczkolwiek racja, warto o tym wspomnieć.
Generalnie, bardzo słuszne uwagi. Dzięki za komentarz 🙂
@Wojtek w znakomitej większości się zgadzam, bo to są argumenty które są zrozumiałe dla biznesu.
Mam trochę inne zdanie odnośnie tego że jeżeli team że sobą częściej rozmawia to mniejsza szansa, że się rozstaną.
Uważam że to jest prawda w pewnym zakresie, natomiast praktycznie żaden (< 5%) team nie jest stabilny na dłużej niż 5 lat.
Ludzie odchodzą szukając czegoś innego, aby się dostosować do zmian w rynku i technologii.
Nie ma znaczenia, że masz super zgrabny team, jeżeli codzienne masz 300 bugów i produkt zbudowany 10 lat temu, a teraz team 6 osobowy w trybie support i trochę dev.
Zdrowo rozsądkowi wybiorą zmiany, nawet kosztem zespołu, bo to nie jest sztafeta tylko maraton.
"Podkupić przez konkurencję" w praktyce oznacza dać cokolwiek lepszego. Więcej pieniędzy, ciekawy projekt, cokolwiek.
W sytuacji w której od pewnego poziomu umiejętności mówimy tylko o kontaktach pojęcie podkupowania w ogóle się rozmywa.
W przypadku konsultantów, to jest ich definicja.
Coraz więcej scrum masterów i scrum coachy dostrzega potrzebę stosowania elementów XP takich jak pair-programing. Pobudki są jednak inne, najczęściej jest to forma magicznej pre optymalizacji velocity.
Drugą sprawą jest to istotna część deweloperskiego gremium preferuje pracę samodzielnego dłubacza i wolą zrobić coś za ciebie niż z tobą posiedzieć bo to “strata czasu” i “ja to sam zrobię w 1h”.
To ta część właśnie ma najwięcej do zaoferowania w ramach tego ćwiczenia.
Cześć,
Co do zasady to jak najbardziej się zgadzam, ale warto dorzucić jeszcze swobodę działania.
Są zadania, nad którymi lepiej posiedzieć razem.
Natomiast czasem warto przepracować tematy w pojedynkę.
Co najlepsze, jedno drugiego nie wyklucza, bo po głębokiej rozkminie jeżeli z kimś pogadasz to pewnie znajdziecie pewne luki w proponowanym rozwiązaniu