Milloin pariohjelmointi pitää lopettaa

Aika ajoin Extreme Programming coachina havaitsen tasaiseen tahtiin uusissa tiimeissä (myös tai etenkin senioreilla), jotka eivät ole aikaisemmin tehneet pariohjelmointi:a, tyypillisiä käyttäytymismalleja, jotka ovat haitallisia tiimityölle. Siksi kirjoitinkin vastaisuuden varalle yleisempään tietoon jaettavaksi parikoodauksesta, että sitä ei pitäisi harjoittaa, jos se ei toimi Fix XP When It’s Broken -käytännön mukaisesti. Usein eri tiimeissä on mahdollista observoida dysfunktionaalista pariohjelmointia, mikä pitäisi heti lopettaa vaikka olemalla tekemättä sitä lainkaan.

Pariohjelmoinnin ongelmat

Tyypillinen havainto parikoodauksessa on, että toinen parista, joka ei tiedä joko projektia tai tekniikkaa (eli kuski joka vääntää näppistä tai rattia) on vieressä ottamassa muistiinpanoja tai seuraamassa muuten vain kun se, joka tietää mihin ollaan menossa (kartturi) on ratissa/näppiksellä. Tälläisestä pariohjelmoinnista ei ole mitään hyötyä vaan se vain maksaa tuplakustannuksen ja toinen parista tylsistyy pidemmän päälle. Oppiminen on heikkoa, vaikka tiimityö ja päivittäinen oppiminen ovat PHZ Full Stackin keskeiset arvot.

Pari vaihtoehtoa miten tilanne voidaan korjata:

Kartturi ajaa kuskin sijasta

1) Jos kuski ei pääse ajamaan autoa, vaan kartturi pitää jatkuvasti rattia (näppistä), niin ilman töitä jääneen kuskin kannattaa ottaa oma auto, eli vaihtaa toiselle työpisteelle (tietokonelle), pyytää scrum masterilta uusi taski ja alkaa tehdä sitä yksin. Olen huomannut että tämä on itseasiassa lähtökohtaisesi parempi tapa aloittaa pariohjelmointi:a, sillä kokematon kuski luultavasti ei tiedä parin minuutin päästä mihin suuntaan pitäisi lähteä ajamaan, ja voi pyytää kartturin paikalle antamaan nuotteja. Huono ja tyypillisempi tapa kuitenkin taas kuskille jolla ei ole karttaa (eli tietoa mihin pitäisi ajaa), on lähteä harhailemaan johonkin suuntaan. Tätä tapahtuu vielä useammin kuin huonoa pariohjelmointi:a, tai se on oikeastaan it-alan myöskin epätehokas perustyöskentelytapa. Ainoastaan kokeneimmat kuskit tietävät ulkomuistista tai vanhasta kokemuksesta kyseisen projektin tieverkoston tai MVC-frameworkkien tyypilliset toteutustavat ja löytävät perille isoimmitta ongelmitta. Oppimisen, projektin etenemisen ja tiimityön kannalta on kuitenkin järkevää kysyä heti apua kartturilta, jos tiimissä parin metrin päässä on fyysisesti istumassa toinen koodaaja, joka tuntee tieverkoston kuin omat taskunsa.

Vaadi ratti itsellesi pariohjelmoinnissa

2) Toinen vaihtoehto on käyttää ”voimaa” ja napata kartturilta näppäimistö itselleen ja vaatimalla vaatia, että kuskilla on oikeus ajaa autoa, sekä antaa palautetta, että kartturi tekee hommansa huonosti, jos ei pysty suullisesti lukemaan tai kertomaan nuotteja (eli selittämään mitä pitää tehdä), vaan ajaa autoa itse pelkääjän paikalta. Tämä päivittäinen epäonnistumismoodi on kaikkea muuta kuin hyvää tiimityötä. Kartturille, eli suurimmalle osalle kokeneista ohjelmoijista, on yllättävän vaikeaa pystyä kertomaan edes toiselle koodaajalle oma ajatuksenjuoksunsa. Pariohjelmoinnissa senioreiden nimenomainen harjoitus on pystyä jäsentämään omat ajatuksensa järkeviksi ohjeiksi. Oppimisessa usein toisten opettaminen auttaa itseasiassa omaa oppimista kaikkein eniten. Kolmanneksi ohjelmistokehitys on ennen kaikkea tiimityötä ja kommunikaatiota. Yksi seniori pystyy tekemään vain tietyn verran asioita päivässä, ja yksin sooloilemalla tiimin kokonaistulos ei parane.

Jos kartturi hermostuu siihen, että kuski ei pysy tiellä, niin kartturin kannattaa silloin meditoida rauhallisuutta ja muistuttaa itseään siitä, että PHZ Full Stack :llä ei ole tarkoitus päästä maksimaaliseen tehokkuuteen vaan mahdollisimman monen uuden asian oppimiseen per päivä.

Prototyypit ja pariohjelmointi

3) Kolmas tilanne, jossa pariohjelmointi kannattaa lopettaa heti, ovat prototyypit, eli tilanne, jossa kartturikaan ei tiedä mihin suuntaan kannattaisi ajaa. Kartturille on tärkeää tunnistaa itsestään tämä tilanne, ja kuski voi auttaa kartturia eksymisen havaitsemisessa. Tällöin Extreme Programming -ohjeiden mukaisesti parin tulisi heti lopettaa pariohjelmointi ja kutsua kolle Parineuvottelu toisten tiimin parien kanssa eli käytännössä tekninen suunnittelu war room:n sohvalla. Tässä neuvottelussa ideoidaan hypoteettisia ratkaisuehdotuksia ja luodaa niistä tehtäviä Big Visible Chartille. Tämän jälkeen parin tulisi hajaantua hiljaisen työn tiloihin tekemään yksin prototyyppejä ilman automaattitestausta, tavoitteena pienentä teknistä riskiä eli toisin sanoen kartoittaa edessä olevaa maastoa. Kun eri reittivaihtoehdot on saatu tiedusteltua ja vertailtua, prototyypit tulee heittää pois, ja toteuttaa varsinainen toteutus pariohjelmointina sekä testiautomaatiolla.

Yhteenvetona huono pariohjelmointi on aina huonompi vaihtoehto kuin hyvä yksinkoodaus. Kuitenkin usein ohjelmoijat luonnostaan välttelevät tiimityötä, koska on aina helppoa oleilla omalla mukavuusalueellaan vastamelukuulokkeet korvissa ja olla kommunikoimatta kenenkään kanssa viikkoihin. Kuitenkin, saatat yllättyä siitä kuinka paljon opit, kun annat pariohjelmoinnille (ja kuskille) mahdollisuuden, ja kuinka paljon se parantaa tiimin tuottavuutta pitkällä juoksulla.