Metoodilisest tarkvaraarendusest ehk millega peab arvestama, kui väikesest projektist saab suur
Kõik tarkvaraarendusprojektid ei ole tingimata suured, vähemalt mitte kohe. Mis aga juhtub siis, kui väikesele projektile, mida üks-kaks arendajat ja disainer koos kliendiga mõõdukas tempos ehitanud on, leitakse kordades eelarvet juurde ning tööde ulatus oluliselt kasvab? Kas piisab lihtsalt tiimiliikmete arvu korrutamisest 3 või 5-ga?
Läbi aja oleme selles vallas päris mitut ämbrit kolistanud ja kuigi kõik asjad said lõpuks lahendatud, oli osapoolte aja- ja närvikulu oluliselt suurem, kui oleks võinud. Selles kirjatükis räägimegi oma kogemuste põhjal potentsiaalsetest komistuskohtadest, millega tuleks kindlasti arvestada.
Kuidas tavaliselt projekt algab ja mis on MVP?
Klient pöördub meie poole lähteülesande ehk visiooniga luua MVP (minimum viable product). MVP ehk minimaalne töötav lahendus (toode, teenus) on esimene versioon süsteemist, mida enam-vähem mõistlikult kasutada saab.
MVP abil saame hinnata, kas idee on vettpidav ja kas lahendus kasutajale meeldib. MVP loomiseks paneme kokku väikese agiilse tiimi, mis koosneb tüüpiliselt kahest arendajast ning enamasti ka ühest disainerist ja testijast. Kusjuures kaks viimast rolli ei pruugi olla täisajaga.
Seda pilootprojekti juhib klient ise, kes kirjeldab ka funktsionaalsused (kasutajanõuded). Selle käigus pannakse kokku rakendus, mille puhul pööratakse põhitähelepanu lõppkasutajale suunatud funktsionaalsusele.
Juhul kui see töömahtu oluliselt suurendab, pühendatakse igasugu administratiivsete funktsioonide mugavale toimimisele ning arhitektuuriliste lahenduste kestlikkusele ja skaleeruvusele vähem aega.
Eesmärk on kiirus ja efektiivsus ning esimene versioon sünnib tavaliselt loetud kuude ja piiratud eelarvega. Selline pilootprojekt aitab kaasa ka usalduse ja edasise hea koostöö tekkimisele.
Mis saab peale MVP-d ja kuidas väike projekt suureks kasvab?
MVP-st edasi on kaks suunda, kuhu liikuda:
- lahendust ehitatakse sama või väiksema tiimiga tasapisi edasi. Seda näiteks juhul, kui tegemist oligi väga piiratud mahuga teenusega ning suuremad investeeringud ei ole majanduslikult mõistlikud. Või siis vajab teenus veel täiendamist, et selle võimalikku edu hinnata ja/või rahastust leida. Selliselt võidakse toimetada aastaid ning võib olla üsna kindel, et väljakujunenud koostöös suuremaid probleeme ei teki.
- toode või teenus on osa suuremast (maailmavallutus)plaanist. MVP osutus edukaks ning kliendil on olemas rahastus (pole suurt vahet, kas enda, investorite või toetusfondi vahenditest), et asuda kiiresti realiseerima MVP-le põhinevat, aga oluliselt suurema funktsionaalsusega süsteemi. Nii meie kui ka klient ootame õhinaga uut projekti faasi – lootust on ju ehitada suur, põnev, majanduslikult edukas ja/või suure mõjuga lahendus. Paraku aga just siin on kõige suurem oht probleemide tekkimiseks koostöös.
Probleemide ennetamiseks tuleb
- läbi analüüsida olemasoleva lahenduse tehnilise platvormi sobivus ja vajadusel viia sisse muudatused ning
- panna kokku sobiv tiim või tiimid, kes hakkab uut lahendust metoodiliselt arendama ning kus on esindatud kõik vajalikud rollid.
Vaatamegi nüüd neid järjekorras.
