Kirjoittanut Raine Kelkka

Reaalimaailman projekteissa käytetylle ajalle ja rahalle täytyy saada tuottavaa vastinetta. Kun ohjelmistotuotteen kehittämistä tehdään projektiluonteisesti, on tunnistettava, mitkä keinot mahdollistavat parhaiden ratkaisujen löytämisen ja mitkä estävät sen. Tarkoitus ei ole käyttää enempää resursseja vaan saada resursseista paras mahdollinen irti.

Tuotekehityksessä lopullinen tuote voi olla hyvinkin koukeroisen polun takana ja tarkkarajainen projekti ei tällöin sovellu. Usein projekteissa lyödään ensimmäisenä lukkoon aikataulut ja resurssit vaikka lopullinen tuote on vielä sarastava visio. Jos ei tiedetä kohdetta, on hyvin vaikea ennustaa matkan kestoa.

Laajojen kokonaisuuksien arviointi on vaikeaa ja riski aikataulusta lipsumiseen kasvaa. Jos etukäteen päätetystä aikarajasta pidetään kiinni väkisin, on projekti pakotettu tuottamaan jotain, mikä ei välttämättä vastaa lainkaan tarpeita.

Tuotekehityksen jakaminen pieniin askeliin, jotka keskittyvät tuottamaan aidosti arvokkaita ominaisuuksia, pienentää riskiä isosta pettymyksestä kovan deadlinen ääressä.

Ohjelmistokehitys on oppimisprosessi

Ohjelmistokehitys ei ole suoraviivainen valmistusprosessi vaan se muistuttaa enemmän oppimisprosessia. Oppiminen tapahtuu pienin askelin, kun reaalimaailman kokemuksesta havaitaan, miten toteutus vastaa arvioituun ongelmaan.

Ketterissä menetelmissä kehityksen ja palautteen välinen sykli pidetään lyhyenä, sillä mitä kauemmin palautteen saamiseen menee, sitä vaikeampi siihen on reagoida ratkaisusssa.

Kehityssyklin viiveen vaikutus tuotekehitykseen:

• Pieni viive ➡️ harha-askel saadaan korjattua nopeasti ➡️ mahdollistaa paljon kokeiluja ➡️ uskallus innovoida ➡️ löydetään parhaat ratkaisut jalostettavaksi lopulliseen muotoon.
• Suuri viive ➡️ harha-askel on kallis ➡️ rajoitettu määrä kokeiluja ➡️ pelko innovoida ➡️ otetaan varman päälle ja tyydytään pienimpään mahdolliseen riskiin.

Ketterät menetelmät eivät auta, jos sykli ideasta käyttökokemuksiin on liian pitkä suhteessa projektin elinkaareen. Vastaavasti iteratiivinen, eli pala palalta toteutusta jalostava, kehitysmalli ei auta, jos on keskimäärin yksi mahdollisuus saada ominaisuudet tehtyä allokoidun projektin puitteissa. Näin muodostuu väkisinkin vesiputous, jossa varovaisuus voittaa ja innovaatio katoaa.

Kehityssyklin lyhentäminen vähentää hukkaa

Varsinkin raskaalla ohjelmistoprosessilla idean vieminen koko tuotekehityspolun läpi formaaleista vaatimuksista hyväksyntätestauksiin on kallista. Tällöin heikosti arvoa tuottavien ratkaisuiden karsiminen mahdollisimman aikaisessa vaiheessa parantaa kokonaistehokkuutta.

Yksi tapa pyrkiä lyhentämään kehityssykliä on jakaa yksittäisten ominaisuuksien toteutusta eri vaiheisiin, jolloin tuotekehityksen paukut tuottaisivat mahdollisimman vähän hukkatavaraa.

Tällä ajatuksella olen mukaillut Kent Beckin 3x-mallia tuotekehityksen triathlonista:

1. aluksi laaditaan useita ratkaisuja mahdollisimman kevyesti ja nopeasti
2. seuraavaksi potentiaalisin ratkaisu laitetaan koetukselle ja yritetään kaikin keinoin tunnistaa mahdolliset ongelmat, jotka estävät sen toteutuksen
3. toteutuskelpoiseksi arviotu ratkaisu toteutetaan projektissa käytettävän ohjelmistokehitysprosessin mukaisesti

Rohkea ideointi mahdollistaa oivallukset

Uutta ominaisuutta tehdessä voi vapaasti kokeilla kenties älyttömiäkin ideoita esimerkiksi käyttöliittymäprototyypeillä. Nopeallakin demolla voidaan saada ahaa-elämyksiä, jotka johtavat oikean ohjelmistoratkaisun äärelle.

Kustannus epäonnistumisesta pidetään pienenä kevyellä prosessilla ja nopealla palautteella. Kun kehittäjätkin osallistetaan ideointivaiheeseen, saadaan laajempi kirjo ajatuksia ja vältetään yhden suunnittelijan pullonkaula.

Potentiaalisen ratkaisun löydyttyä yritetään paljastaa mahdolliset loogiset puutteet tai ongelmat, jotka estäisivät sen käytön arvioidussa toimintaympäristössä. Jos kyseessä on esimerkiksi isoa datamäärää käsittelevä toiminto, se voidaan käytännössä toteuttaa prototyypin muodossa oleellisilta osin ja altistetaan arvioitua käyttöä vastaavaan kuormaan.

Tämän vaiheen tarkoitus on suhteellisen nopeasti joko validoida idean toteuttamiskelpoisuus tai hylätä se. Tavoite on karsia pois kalliit ja mahdolliset käytön estävät yllätykset tuotekehityksen loppupäässä.

Hyvin suunniteltu on ennustettavampi

Näiden vaiheiden jälkeen voidaan olla melko luottavaisin mielin, että valittu ohjelmistoratkaisu on hyödyllinen ja se toimii myös käytännössä. Seuraavassa vaiheessa on aika laatia toteutus huolellisesti ja viedä laadunvarmistuksen kautta tuotantoon. Varsinainen toteutus on ennustettavampi verrattuna tilanteeseen, jossa lopullista koodia ruvetaan tekemään tyhjältä pöydältä.