Prosessimalli ja laatu ovat synonyymejä

Noin kolme vuotta sitten jouduin head hunterin uhriksi, jossa minua yritettiin rekrytoida erääseen IT-alan yritykseen. Olin noina aikoina vaihtamassa muutenkin firmaa, joten päätin kysellä hieman enemmän tarjolla olevasta paikasta. Eräs kysymykseni koski yrityksessä käytettävää ohjelmistotuotannon prosessimallia ja lähinnä yritin kysyä mikä malli heillä on käytössä. Sain yrityksen edustajalta vastaukseksi, että he keskittyvät prosessin sijasta laatuun, eikä hän pystynyt nimeämään mitään tiettyä prosessimallia. Tämä olikin omalta osaltani melkoinen show stopperi tämän yrityksen kanssa. Mielestäni hyvää laatua on mahdotonta saavuttaa ilman toimivaa prosessia, joten en lähtenyt kokeilemaan onneani tämän yrityksen kanssa. Toki yrityksessä saatetaan tietämättäkin noudattaa hyvinkin säntillistä prosessia, vaikka sitä ei osattaisikaan nimetä. Kuitenkaan henkilö jonka kanssa keskustelin ei osannut tarkemmin selittää mistä heidän yrityksessään laatu rakentuu.
Hyvä prosessi on läpinäkyvä kaikille projektiin osallistuville henkilöille. Jokainen projektin jäsen tietää joka hetki täsmälleen mikä on projektin tila sillä hetkellä - mitä tehdään nyt ja mitä tehdään seuraavaksi. Lisäksi prosessi huomioi vaatimustenhallinan, testauksen ja ohjelmonnin laadun. Prosessi myös varmistaa vähintään niiden ohjelmiston laatu attribuuttien huomioimisen projektissa, jotka yritys kokee toiminnalleen tärkeiksi. Esimerkiksi hyvä käytettävyys ei synny ohjelmistoon itsestään, vaan se on suunniteltava määrätietoisesti tietyssä vaiheessa tietyin lähtötiedoin. Johdon on annettava täysi tukensa prosessille, jotta tarvittavat resurssit laatuattribuuttien täyttämiseksi saadaan.
Monet prosessimallit kuvaavat ainostaan millaisia dokumentteja projektin tulisi tuottaa ja monet pitävätkin prosessia synonyyminä dokumentointiohjeelle. Omasta mielestäni hyvä prosessi ei koodin laadukkaan kommentoinnin lisäksi vaadi välttämättä mitään ylimääräisiä dokumentteja! Projektin on toimittava niin läpinäkyvästi, että jokainen tiimin jäsen tuntee ohjelmiston viimeistä yksityiskohtaa myöden. Tietoisuuden lisäämisellä myös dokumentointia voidaan vähentää huomattavasti. Usein dokumentointi on vain tekstimuotoiseksi kuvaukseksi muutettua ohjelmakoodia henkilöille, jotka eivät varsinaista koodia ymmärrä. Niinpä onkin järjetöntä ylläpitää kahta eri "ohjelmakoodia" rinnakkain. Dokumentointia voidaan tehdä silloin, kun asiakas sitä tarvitsee, mutta yritystä itseään varten sitä ei kannata tehdä.
Eräs varsin kiinnostava prosessimalli on Scrum ja sen eri variaatiot. Tässä on mainio esimerkki prosessista, jonka ohjeet lähtevät niinkin alkeellisista asioista, että miten projektiryhmä vaihtaa tietoa keskenään. Lisäksi prosessimalli edustaa agilea sovelluskehitystä parhaimmillaan, eli on iteratiivinen ja inkrementaalinen. Netti on pullollaan menestyksekästä tutkimustietoa Scrumista. Valitettavasti en ole itse vielä koskaan päässyt mukaan projektiin, jossa Scrumia olisi käytetty, mutta pidän tätä mallia vahvana kandidaattina perustettavalle yritykselle...