Miksi pariohjelmointi on tärkeää PHZ Full Stack:llä

Toisin kuin muissa yrityksissä, pariohjelmointi on monessakin mielessä tärkeä ja keskeinen käytäntö PHZ Full Stack:lla. Viimeaikoina myynnin tehdessä hyvää työtä, keskustelua on syntynyt tuotekehitysprojektiemme resurssoinnista ja osaamisen levittämisestä niissä. Yrityksellämme ei ole ulkopuolisia omistajia omien kehittäjiemme lisäksi, vaan tuotekehitys tapahtuu konsultoinnin rahoitusmallilla, jossa on sekä hyviä että huonoja puolia kehitysprojektien näkökulmasta. Toisaalta nimenomaan toimiston tuotekehitysprojektit erottavat PHZ Full Stack:n muista vastaavista IT-alan yrityksistä. Bonusmallimme mukaisesti toimistolla ei-asiakasprojekteissa työskentelevät saavat yhden kyseisen startupin osakkeen per tuotekehitysprojektiin tehty työtunti. Toisin kuin asiakasprojekteista saatavasta asiakaslaskutusbonuksesta, osakkeista ei koskaan tiedä tuleeko niistä tavoitteen mukaan miljardiluokan yksisarvisia vai minkä arvoisia osakkeet lopulta ovat. Toisaalta kehitystiimi voi itse omalla osaamisellaan ja työpanoksellaan vaikuttaa oman työnsä arvoon kaikkein eniten.

Huono puoli asiakaskonsultoinnista tuotekehitysprojekteille on, että keskimääräinen työskentelyaika tuotekehitysprojektissa on noin 2-3kk, minkä jälkeen usein koko tiimi on vaihtunut uuteen. Uusilla projektiin tulevilla koodaajilla on valtava oppimiskynnys aina tuotekehitysprojektiin tullessaan, sillä johtuen konsulttiemme erinomaisuudesta, kehitysprojekteissa käytetään usein uusinta mahdollista teknologiaa ja asiakasprojekteista opittuja parhaita käytäntöjä. Tämä on sekä uhka että mahdollisuus: kehitysprojekteissa on mahdollisuus oppia jopa vielä enemmän kuin asiakkailla, koska niissä on yhdistetty kaikkien parhaiden konsulttiemme osaaminen. Haaste tulee oppimisen määrässä, sillä juuri mikään ei ole ennalta tuttua edes senioreille.

Oppiminen

Hyvä puoli asiakaskonsultoinnissa on että PHZ Full Stack:lla on todella osaavia Full Stack-ohjelmistokehittäjiä, ja toisaalta kunkin startup:n järjestelmien kehittämiseen on tähän mennessä osallistunut kymmenet koodaajat tai jopa suurin osa meidän 80 kehittäjästä. Toisin sanoen, vaikka kehitystiimi vaihtuu parin kuukauden välein, tämä ei tarkoita että tieto projektin rakenteesta lähtisi firmasta pois. Sen sijaan n. 1-2v syklillä toimistolle palaa asiakasprojekteista konsultteja takaisin, jotka olivat esim. aloittamassa projektia tai ovat suunnitelleet alkuperäisen teknologiastackin, yleensä asiakasprojekteista parhaita käytäntöjä hakemalla tai niitä parantamalla edelleen. Osaamisen vaihtuminen tapahtuu toimistolla, sillä parhaita käytäntöjä ja voi seraavaksi viedä uudelle asiakkaalle. Näin ohjelmoijamme oppivat verrattuna vain yhdessä projektissa olevien kehittäjiin verrattuna.

Tietysti XP:n Move People Around periaatteen mukaan palatessaan toimistolle osaamisen levittämiseksi kunkin ohjelmoijan tulee vaihtaa myös tuotekehitysprojektia. Jos aikaisemmin oli tekemässä esim. PHZ Full Stack:n taloushallintoprojekteja, tulee seuraavaksi siirtyä opettelemaan Unitya pelistudion puolelle ja tämän jälkeen Apprien:iin tekemään big data -pilvipalveluita.

Näin pystymme kouluttamaan Full Stack-kehittäjiä, jotka osaavat sekä frontendin, backendin, devops ja pilviteknologiat. Move People Around-käytännön tavoitteena on estää siilojen syntyminen ja Collective Code Ownership:n mahdollistaminen, että kaikki ohjelmoijat pystyvät tekemään muutoksia niin frontend:iin, backendiin, pilvipalveluihin kuin CI-pipelineihin.

Osaamisen leviäminen pariohjelmonnilla

Huono puoli toimintamallissa taas on että meillä vaihtuu keskimäärin 3kk välein kaikkien tiimien koko porukka
Osaaminen ei häviä tiimistä kuitenkaan, jos on harrastettu pariohjelmointia ja niin kauan kuin yksi koodaaja on jäljellä joka pystyy parikoodauksella opastamaan seuraavat tyypit sisään
Uudet koodaajat ovat tietysti täysin pihalla miten projekti toimii joten parikoodaus on olennaista että uudet pääsee sisään projektiin

PHZ Full Stack:lla ja Extreme Programming:ssa ei ole sellaista käytäntöä kuin handover, eli että järjestettäisiin erillisiä tiedonsiirto tai -vaihtotilaisuuksia tai varattaisiin sille aikaa. Tiedonsiirron on pakko ja ajatus tapahtua normaalin työnteon ohessa. Parhaimmat XP-käytännöt tämän tukemiseen ovat pariohjelmointi, Move People Around ja Collective Code Ownership. Tiimin tulisi itseohjautua siirtymään jatkuvasti omalle epämukavuusalueelle eli sellaisiin osaamisiin mitä ei ennestään hallitse. Esim. fronttikoodaajien tulisi harjoitella AWS-pilvideployment:ia ja komentorivin käyttöä, sekä backend-dinosaurusten React:ia, Vue.js:ää ja HTML5-flexboxien tekemistä.

Osa-aikaiset työntekijät pariohjelmoinnissa

Kolmas juttu oli että näyttäisi siltä että meillä ei ole juuri ketään osa-aikaista työntekijää tekemässä tunteja ennen seuraavaa toukokuuta, mikä on sekä hyvä että huono.

Pariohjelmointi on ongelmallista osa-aikatyöntekijän kanssa, koska muu tiimi ehtii tekemään välipäivien aikana aika paljon asioita. Osa-aikaisille työntekijöille pariohjelmointi on erityisen tärkeää, koska vähäinen yhteinen työskentelyaika ei muuten riitä tiedonvälitykseen. Aihetta laajentaen tätä TKP-projektin työskentelymallia olisi syytä jalostaa. Projektissa ei ole scrum masteria, PO on paikalla kerran viikossa, tech leadit ovat allokoituina toisissa projekteissa ja handovereissa on hukkunut liikaa tietoa.

Resurssien pysyvyys ja rahoitus

Niin kauan kuin startup-projektit ovat eivät elätä omalla tulovirrallaan tuotekehitystä, ilman ulkopuolista rahoitusta sijoittajilta ketään kegittäjää ei voida kiinnittää, vaan etsimme kaikille jatkuvasti uusia asiakasprojekteja. Toinen sykli mikä näyttäisi toteutuvan tasaisin aikavälein on, että firman johdolla on vain rajattu määrä aikaa käytettävissän ja mitä vähemmän toimistolla on väkeä niin sen enemmän mulla on aikaa fokusoida eri kehitysprojekteihin ja käänteisesti toistenpäin.

Pariohjelmointi asiakkailla

Toimistolla harjoiteltu tiimityö on kuitenkin suuri etu myös asiakasprojekteissa. PHZ Full Stack-koodaaja voivat erottautua positiivisesti tiimityökyvyillään muista kodaajista, sillä pariohjelmoint perustuu hyvään kommunikaatioon, toisten ihmisten auttamiseen, erilaisuuden huomioon ottamiseen ja hyväksymiseen sekä ennenkaikkea tiimityöhön, mikä on myös PHZ Full Stack keskeinen arvo. Jos asiakas ottaa PHZ Full Stackilta parikoodaukseen treenatun full stack-ohjelmistokehittäjän, niin asiakas saa aina kilpailijoita paremman vastineen rahoilleen.

Haluamme lunastaa tämän arvolupauksen päivittäin.
Se että pystyy opettamaan muiden firmojen ja asiakkaiden kollegoille uusia asioita tuottaa huomattavasti enemmän lisäarvoa kuin yksin asioiden tekeminen. Haluamme, että PHZ Full Stack -brändi tunnistetaan nimenomaan hyvästä tiimityöstä.
Meillä on päivittäin hyvä mahdollisuus noudattamalla yrityksen arvoja eli palautteella, jatkuvalla oppimisella, korkealla laadulla ja tiimityöllä erottautua positiivisesti muista firmoista asiakkaiden suuntaa, eli toisin sanoen että PHZ Full Stackilta saa kaikenosaavia tiimipelaajia, jotka opettaa vielä kaupan päälle päivittäin muille uusia taitoja.