Perinteisen vesiputousmallin sijasta ohjelmistot kehitetään tänä päivänä lähes poikkeuksetta ns. ketterillä menetelmillä, joissa ohjelmistohanke jaetaan tyypillisesti pienempiin osioihin, kuten sprintteihin. Näin ohjelmistokehitys hoituu riskittömämmin ja tilaa jää nopeille reagoinneille tai muutostarpeille. Oleellinen osa ketterää kehitystä on myös Minimum Viable Product, josta pääset lukemaan seuraavaksi hieman tarkemmin.
Mikä ihmeen MVP – keskeneräinen tuoteko?
Minimum Viable Product eli MVP tarkoittaa ohjelmiston ensimmäistä versiota, joka pystytään jo ottamaan käyttöön. Ohjelmisto koeponnistetaan ensin minimiponnistuksin – erityisesti sen haastavimmat ja kriittisimmät ominaisuudet. Näin ollen ohjelmistosta saadaan ”maistiaisia” ja hankkeen kokonaistoteutettavuutta on mahdollista arvioida huomattavasti realistisemmin. Projektin suuntaa on myös mahdollista muuttaa tai tarkentaa hyvinkin joustavasti toimittaessa ketterillä menetelmillä, eikä suuria riskejä tarvitse ottaa. Lisäksi ominaisuuksia on helppo laajentaa myöhemmin sekä toteuttaa ohjelmistosta laajempi kokonaisuus, jota täydennetään ja kehitetään jatkuvasti.
Käytännössä MVP etenee tyypillisesti niin, että ohjelmistokehityshanke jaotellaan kahden viikon mittaisiin sprintteihin. Näissä sprinteissä kehitetään ohjelmiston yksi osa-alue kerrallaan alkaen kriittisimmistä ja usein samalla myös haastavimmista toimista. Sprinttikehitys sopii tyypillisesti kehityshankkeisiin, joissa ostaja tai tuoteomistaja pystyy osallistumaan sprinttien määrittelyosioihin tai hankkeisiin, joissa on jo olemassa perusmäärittelyjä, jolloin tekniseen kehittämiseen paloissa päästään kohtuullisen nopeasti.
Hankkeissa, joissa vaaditaan merkittävää perustutkimusta ennen teknistä toteutusta, on usein haasteellista lähteä tekemään ohjelmistokehitystä sprinteissä. Usein myös esimerkiksi julkisien hallinnon hankkeissa, joissa vaaditaan tarkkaa määrittelyä ja sen hyväksyntää ennen toteutusvaiheeseen lähtemistä, on järkevää mennä perinteisemmän vesiputousmallin mukaan. Toteutus voidaan sitten tehdä paloissa ketterän kehityksen mallin mukaisesti.
Yhdessä sprintissä voitaisi toteuttaa esimerkiksi ensimmäinen versio asiakas- tai tuotetoiminnallisuudesta tuotantoon asti, minkä jälkeen seuraavissa sprinteissä niiden pohjalta kehitetään muuta toiminnallisuutta paloissa – ikään kuin sipulin kuoria lisäten. Haasteeksi näissä tulee usein takaisinkytkentä eli uusien sprinttien valmistuttua niiden vaikutus jo valmiisiin osiin voi aiheuttaa merkittävää versiointia ja siten vaativaa muutoshallintaa projekteihin.
Huomioitavaa onkin siis se, että vaikka MVP on osa iteratiivista ohjelmistokehitystä, ei iteraatioiden silti tarvitse olla ketteriä. Ketterä kehitys on automaattisesti iteratiivista, mutta siihen kuuluu paljon muutakin. Minimum Viable Product ei siis ole välttämätön ketterän kehityksen ominaisuus, mutta käytännössä ensimmäinen ketterän prosessin milestone on aina MVP. Olisi melko erikoista julkaista tuote, jossa ei olisi ensimmäiseksi kaikkein kriittisimpiä osia.
Osallistu mukaan ohjelmistokehitystyöhön, niin onnistut!
Ketterillä menetelmillä toimittaessa ostajan aktiivinen osallistuminen ohjelmistokehitysprojektiin on suorastaan pakollista hankinnan onnistumiseksi. Jotta koko hanke sujuisi joustavasti ja ketterästi, on ostajan aktiivisesti osallistuttava kehitystyöhön sekä annettava palautetta projektin etenemisestä.
Yksi tärkeimmistä tehtävistä ostajan puolella onkin valita hankkeeseen tuoteomistaja, joka valvoo ohjelmiston täyttävän sille asetetut odotukset ja vaatimukset. Tuoteomistaja on usein myös henkilö, joka on jatkuvasti yhteydessä sekä ohjelmistokehittäjään että koko ohjelmistokehitystiimiin. Sprinttien jälkeen tuoteomistajan vastuulla on joko hyväksyä tai hylätä tuotos. Onnistumisen kannalta tuoteomistajan onkin hyvä olla läsnä sprinttikäytännöissä ja hänellä tulee olla kattava kokonaiskuva koko projektista ja sen etenemisestä. Tuoteomistajan rooli ei missään nimessä ole tekninen, vaan vaatii liiketoimintaymmärrystä.
Erityisesti suuremmissa ohjelmistokehityshankkeissa on lisäksi järkevää varata kokonaan erillinen ohjausryhmä projektiin. Siten varmistetaan riittävä näkemys ja tieto projektin nykytilasta ja tulevaisuudesta. Hanke ei milloinkaan saisi jäädä vain yhden henkilön vastuulle, vaan useamman henkilön on hyvä olla perillä ohjelmistokehityksen etenemisestä.