Ohjelmistotuotantokäytännöistä

PHZ Full Stack:lla parannamme jatkuvasti ohjelmistotuotanto -käytäntöjämme arvioimalla ja keskustelemalla niistä retrospektiivissä 2 viikon välein. Extreme Programming koostuu paristakymmennestä käytännöstä (meillä laajennettu n. 40 kpl), joista voi löytää listan esim. http://www.extremeprogramming.org/rules.html .

Osa käytännöistä saattaa olla helposti löydettävissä esim. Kent Beck:n Extreme Programming Explained -kirjan otsikoista, mutta osa esim. War Room saattaa olla piilotettuna tekstin keskelle, tai niitä voidaan löytää muista lähteistä esim. tieteellisistä artikkeleista.

Mikä on käytäntö?

Ohjelmistotuotantokäytäntö (Practice) saattaa kuulostaa epämääräiseltä käsitteeltä, ellei sitä ajattele tiettynä tarkkana tapana toimia. Yksi XP-käytännöistä on kerran iteraatiossa pidettävä retrospektiivi, jossa keskustelemme onko käytäntöjä käytetty vai ei. Samalla on XP Coach:n hyvä selittää ja keskustella siitä, mitä tietty käytäntö, esim. Pariohjelmointi tarkoittaa. Osaava XP Coach voi kertoa hyviä ja huonoja käytännön esimerkkejä kunkin käytännön soveltamisesta. Tiimi voi keskustella tämän jälkeen Fix XP When It’s Broken -käytännön mukaisesti ovatko kyseiset käytännöt järkeviä tälle tiimille vai ei, mitä hyötyjä ja haittoja niiden noudattamisesta tai poistamisesta voisi olla.

Käytännöistä on olemassa lukuisia variaatioita, joista löytyy myös paljon tieteellisiä tutkimuksia. PHZ Full Stack:lla yksi retrospektiiviä parantava variaatio, jota ei löydy alkuperäisestä XP-kirjallisuudesta, on Balanced Scorecard:n käyttö. Eräs paljon käytetty perinteinen tapa retrospektiivissa on esim. kerätä post-it -lapuille hyviä ja huonoja (pros/cons) edellistä iteraatiosta.

Olen kuitenkin huomannut että nämä laput eivät juuri koskaan johda mihinkään toiminnan parantamiseen (vuosienkaan jälkeen vaikka niistä keskustellaan joka viikko), ellei tiimillä ole jotain strategiaa ja tavoitetta jota kohti toimintaa yritetään parantaa. Strategiakartoilla pystytään antamaan konteksti retrospektiiville, mihin suuntaan toimintaa tulisi kehittää sen sijaan että keskustelua käydään tiimiläisten henkilökohtaisista preferensseistä ja toimitaan kaikkien mukavuusalueella. Ilman selkeää tavoitetta ja strategiaa ei ole mahdollista saavuttaa erinomaisuutta tiimityössä. Lisäksi Scorecardin Action:eista kannattaa tehdä tehtävät iteraatioon, etteivät ne unohdu tai ole irrallisia varsinaisesta työstä.

Toinen esimerkki käytäntöjen variaatiosta on esim. aika-arvioiden tekeminen, joita voi eri lähteistä löytää tehtäväksi esimerkiksi nallekarkeissa, työpäivissä, Ideaalisina Työpäivinä tai Planning Poker:lla. Toisaalta aika-arvioiden tekemiseen suhtautuu kriittisesti #NoEstimates -koulukunta.

Ohjelmistotuotantoprosessin mittaaminen

Pitkään (15v) PHZ Full Stack:lla käytössä ollut balanced scorecard:n evaluointi alkaa aluksi miettimällä taloudellisia tuloksia projektin omistajien näkökulmasta. PHZ Full Stack:lla käytämme mittarina kuinka monta työtuntia oikeasti kuluu per valmiiksi saatu XP Velocity -piste. Projektin Nopeutta mitataan todellisuudessa (Definition of Done) valmistuneiden käyttäjätarinoiden perusteella, jotka Product Owner/asiakas on hyväksynyt (Acceptance Testing).

Asiakastyytyväisyyttä mittaamme kysymällä asiakkaalta Net Promoter Scorea suosittelisitko tätä tiimiä toiseen projektiin?

Prosessimittarina käymme retrospektiivissa läpi kaikki 40 käytäntöämme subjektiivisesti, ja olivatko ne käytössä tiimin mielestä edellisen iteraation aikana vai ei. Esimerkiksi Sustainable Pace -käytännön mukaisesti tiimi ei saa pistettä jos joku on tehnyt ylitöitä tai alitunteja. 37.5h Työviikko -käytännön mukaisesti Projektin Nopeuden tulee perustua normaaliin työaikaan, vaikka yksittäisinä päivinä jonkun tehtävän tekemiseen voi mennä 8h tai 6h. Jos tehtävät on suunniteltu etukäteen hyvin, kannattaa lähteä kotiin ja tulla seuraavana päivänä tekemään seuraavaa n. 1pv mittaista tehtävää, kuin lähteä väsyneenä aloittamaan mitään uutta.

Menetelmä on kokoelma käytännöistä

Tein toisen lopputyöni Aalto-yliopiston ohjelmistotuotannon instituutissa (SoberIT), jossa tutkimuksen aiheena olivat nimenomaan, mitä käytäntöjä eri firmoissa sovellettiin. Tutkimuksen tarkoituksena oli löytää tuloksia siitä, miten eri käytännöt (esim. Pariohjelmointi) toimivat esim. laadun tai tuottavuuden suhteen. Yksi havaintoni käytännön tutkimuksista oli, että tyypillisestä ohjelmistoyrityksessä oli käytössä 70-75 eri käytäntöä (esimerkiksi Viikkopalaveri). Haastattelututkimuksessa kuitenkin havaittiin omassa lopputyössäni olleella pienellä otoksella, että yksikään tutkituista yrityksistä ei käyttänyt mitään kirjallisuudesta löytyvää menetelmää, vaan käytännöt olivat ilmeisesti tulleet käyttöön orgaanisesti ajan saatossa tarpeiden mukaan.

Menetelmä (olkoon se emergentti, suunniteltu tai kirjallisuudesta löytyvä) on kokoelma yksittäisiä käytäntöjä. Käytännön soveltamisessa voidaan lisäksi ajatella ideaalista menetelmää (esim. Scrum), ja sitten tarkastella kuinka hyvin ideologiaa sovelletaan käytännössä (esim. 15/40 ideaalisesta käytännöstä on oikeasti käytössä). Ohjelmistotuotannon tutkimuksessa voidaan sitten tutkia myös miten eri kombinaatioilla käytäntöjä eli menetelmillä saadaan aikaan minkälaisia tuloksia?

Extreme Programming PHZ Full Stack:lla

Yli 15 vuoden kokemuksella voin sanoa Extreme Programming:sta, että se on kenties huonoin mahdollinen menetelmä ohjelmistotuotantoon, jos tiimi on kokematon tai uusi. Kaikissa tiimeissä menetelmän soveltaminen alkaa aina uudestaan, ja tyypillinen ensimmäisen iteraation jälkeinen käytäntömäärä on noin 13 käytäntöä, ja tiimin suorituskyky asiakkaan näkökulmasta on surkea. Minkä tahansa menetelmän oppiminen vie aikaa, esimerkiksi aikoinaan PHZ Full Stack:n edeltäjältä CMAX-tiimillä kului lähes 5 vuotta päästä lähes täydelliseen prosessimalliin (silloin 31.5/32 käytäntöä). Kokeneella ketteriä menetelmiä ennenkin käyttäneellä tiimillä asiakasprojekteissamme henkilökohtainen ennätykseni tähän mennessä on ollut valmentaa tiimi 30 käytäntöön 6 viikkossa. Toisin sanoen jatkuva parantaminen riippuu paljon sekä XP Coach:sta että tiimiläisten osaamisesta ja sopeutumiskyvystä.

Verrattuna tutkimuksissa havaittuihin 70-75 käytäntöön per yritys, XP on toisaalta huomattavasti kompaktimpi menetelmä, joten teoriassa se on näitä helpompi ottaa käyttöön ja kouluttaa. Toinen XP:n etu esimerkiksi emergenttiin defacto-menetelmään verrattuna on, että kaikki 30-40 käytäntöä on tarkkaan mietitty sellaisiksi että ne tukevat toisiaan. Toisin sanoen Extreme Programming on oikeastaan ns. super-kombo toisiaan tukevia käytäntöjä. Tämän takia myös ns. Scrum-But -menetelmä saattaa olla huono idea, jos kombosta poistaa jotain itselleen epämiellyttäviä käytäntöjä niin koko menetelmä saattaa rampautua niin ettei sillä tavoiteltuja hyötyjä pystytä koskana realisoimaan.

Kokemukseni mukaan asiakkaan näkökulmasta tiimi pääsee ns. break even:iin eli tuottaa yhtä paljon kuin palkkoja joutuu maksamaan n. 25 käytännön kohdalla (PHZ XP:n 40 käytännöstä). Tämän jälkeen tiimi alkaa muuttumaan supertuottavaksi. Nämä XP:n käytännöt ovat alkuun epäintuitiivisia eivätkä välttämättä helppoja ottaa käyttöön, sillä ne ovat päinvastaisia ihmisten mukavuusalueille. Kuitenkin, mitä paremmin tiimi ymmärtää, kuinka eri käytännöt esim. pariohjelmointi ja Full Stack-kehitys tukevat toisiaan, sitä nopeammin tiimin tuottavuus kasvaa erinomaiselle tasolle. Tiivis tiimityö lisäksi lisää työtyytyväisyyttä huomattavasti onnistumisten seurauksena.