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 a) läbi analüüsida olemasoleva lahenduse tehnilise platvormi sobivus ja vajadusel viia sisse muudatused ning b) 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.
Arhitektuuriliste lahenduste sobivus ja tehniline võlg
MVP'd luues tehakse tehnilised (arhitektuurilised) valikud lähtuvalt sellest, mis on kõige kiirem ja efektiivsem, et rakendus ruttu valmis saada. Pikas perspektiivis aga ei pruugi need valikud olla piisavalt skaleeruvad ega suurel tiimil mugavad edasi arendada.
Samuti tekitatakse MVP loomise käigus tihti märkimisväärne kogus tehnilist võlga, kus kiiruse ja korrektsuse vahel valides kaldutakse esimese poole. See on täiesti aktsepteeritav, sest MVP eesmärk on näidata, et idee on kasutatav ja toimib.
Arhitektuurilistest valikutest metafooride keeles: ehitustehnilised lahendused ei pea garaaži ehitamisel olema nii võimsad kui ehitades korterelamut. See oleks raha raiskamine. Kui aga hiljem selgub vajadus ehitada garaaži peale korterelamu, on mõistlik läbi mõelda, kas konstruktsioonilised valikud jätkuvalt sobivad ning vajadusel alustada algusest.
Alustades oluliselt suurema edasiarendusega, on vaja võtta alustuseks samm tagasi ja vaadata üle rakenduse arhitektuur. Seejuures tuleks läbi mõelda: a) kas tehniliselt on detaile, mis tuleks kohe korda teha, vähendades tehnilise võla aktsepteeritavale määrale ja b) kas loodud tehniline arhitektuur üldse mõistlikult skaleerub, arvestades uut lähteülesannet. Kui mitte, tuleb see enne funktsionaalsuste arendamisega edasi minemist ümber ehitada (refaktoorida).
Ausalt refaktoorimisest: agiilses arenduses on tavapärane, et arenduse käigus refaktooritakse väga ulatuslikult olemasolevat tehnilist lahendust. Miks? Kuna „teeme kohe õigesti“ ei pruugi olla kas üldse võimalik (vajadused muutusid ning tänu sellele pole algselt valitud lahendus enam sobiv) või siis on kallim ja aeganõudvam.
Probleem seisneb selles, et tehnoloogiliselt raskesti edasiarendatav rakendus võib väliselt väga hea välja näha ja kenasti töötada. Kui nüüd äripoole esindaja juurde minna jutuga, et järgmise kuu jooksul ei tule ühtegi uut funktsionaalsust, kuna tiim tegeleb refaktoorimise ja tehnilise võla likvideerimisega, on vaidlused kerged tekkima. Kõik see tuleb ju kinni maksta ning boonusena tekitame alguses veel mõned vead juurde.
Üks lahendus on teha seda paralleelselt uute funktsionaalsuste realiseerimisega, kui süsteemi olukord seda võimaldab. Oluline on aga jälgida, et see ka päriselt toimub, sest vastasel korral võib lõpuks jõuda olukorda, kus pole muud valikut, kui rakendus tehnilistel põhjustel nullist uuesti kirjutada.
Kuigi arendajate jaoks on ahvatlev, soovitame seda iga hinna eest vältida. Ajaloos on palju juhtumeid, kus uue süsteemi nullist ehitamise käigus rakenduse turuosa jäädavalt kadus.
Mida arhitektuuriliste valikute juures silmas pidada? Need peavad sobima lähteülesande ja tellija eesmärkidega. Kui on teada, et süsteemi planeeritav eluiga on 10 aastat ja esimese versiooni avalikustamisega ei ole väga kiire, võiks vaadata modernsemaid tehnoloogilisi lahendusi, näiteks mikroteenused + micro front-end.
Ja vastupidi, kui suur ajasurve on peal, siis võiks valida ennast tõestanud skaleeruvad lahendused. Mida uudsemate lahenduste peale minna, seda rohkem aega ja mahtu see alguses kulutab. Boonuseks aga on (loodetavasti) parem edasiarendatavus tulevikus.
Miks on oluline suure projekti puhul rakendada süstemaatilist arendusmetoodikat?
Tarkvaraarendus on inimlooming. Suurem hulk funktsionaalsust vajab ühelt poolt suuremat tiimi, et see mõistliku ajaga realiseerida. Teisalt on vaja selle funktsionaalsuse eri osade vahelisi seoseid ja sõltuvusi mõista ja hallata, mis vajab aega ja kogemust.
Inimeste ja funktsionaalsuse lisandumisel kasvab süsteemi loomise keerukus eksponentsiaalselt. Hetkest, kui tiim on suurenenud 5 või rohkema inimeseni, on oluline rakendada metoodilist tarkvaraarenduse protsessi (tavaliselt Scrum). Sellest tulenevate rituaalide ja struktuuri mõistliku rakendamisega saab hoolitseda selle eest, et tiimis info liiguks ning meeskonnaliikmed üksteise järel ootama ei peaks.
See omakorda tähendab, et tuleb teostada vastavaid tegevusi, mida protsess ette näeb ning tiimil peavad kindlasti olema ka vastavad võimekused. Kui tellija hakkab ise kogu projekti vedama ja funktsionaalsusi kirjeldama, siis tuleb arvestada, et see on täiskohaga (või rohkem) töö ning eeldab tugevat tarkvaraarenduse ja analüüsi kompetentsi. Mängu tulevad ka rollikonfliktid.
Reaalsus näitab, et suuremate süsteemide arenduses on Scrumis ettenähtud kolm rolli (Product Owner, Scrum Master ja Team Member) mõnevõrra ülelihtsustatud – vajalik on spetsialiseerumine. Muuhulgas on oluline projekti kaasata ka testija(d) ja süsteemianalüütikud.
Arendajad ei ole kunagi nii head testijad, kui seda on spetsialiseerunud testijad. Süsteemianalüütikutel aga on võime kokku panna suurt pilti, tükeldada see loogilisteks osadeks, kirjeldada detaile ja sõltuvusi ning olla seeläbi tellijale funktsionaalsuse kirjeldamisel, hindamisel ja järjestamisel partneriks.
Samuti näitab meie kogemus, et problemaatiliseks võib osutuda, kui tellija asub ise täitma nii toote omaniku (Product Owner) kui projektijuhi (Scrum Master) rolli. Scrum Masteril peab olema hea tarkvaraarenduse juhtimise kompetents ning piisavalt aega kõikide metoodiliste tegevuste teostamiseks.
Ta peaks olema ühelt poolt takistuste kõrvaldaja, teiselt poolt hoolitsema, et tiim teeks tööd jätkusuutlikult. Sealhulgas tuleb Scrum Masteril selgitusi jagada toote omanikule, kui tolle soove pole võimalik soovitud eelarve ja ajaraami piires täita. Olles kahes rollis korraga, on oht asuda tiimi liigselt survestama, millega on üsna lihtne saavutada vastupidine tulemus, sest motivatsioon kaob ja tiim laguneb.
Eelnevat kokku võttes soovitame klientidele suuremates projektides üldjuhul:
- moodustada tiim, kus on esindatud kõik vajalikud rollid ja spetsialiseerumised (sh UX/UI disainer, arhitekt, süsteemianalüütik, testija, arendajad, projektijuht)
- rakendada süstemaatilist tarkvaraarendusmetoodikat
- võtta endale toote omaniku roll, kelle ülesandeks on vajaduste kirjeldamine üldisel kujul ning prioriteetide seadmine. Koos süsteemianalüütiku (ja arhitekti) panusega moodustub toote omaniku tiim, kes selle kogu muule tiimile vajalikul kujul ära kirjeldab.
Kuigi alguses tundub, et selline lähenemine nõuab rohkem raha ning võiks proovida väiksema tiimiga, on see reeglina enesepett, mis toob varem või hiljem tüli majja.
Produktiivsus ja tähtajad
Nagu rääkisime, on tarkvaraarendus inimlooming, kus keerukus inimeste ja funktsionaalsuse lisandumisel kiiresti kasvab, sest tööd ei ole lõputult tükeldatavad ning täiesti paralleelselt ellu viidavad.
Sellest tuleneb järgmine reegel: 5 korda rohkem töötunde (eelarvet) ei tähenda 5 korda rohkem funktsionaalsust. Osa sellest kulub lisandunud keerukuse ehk nii äriloogika kui inimestevahelise suhtluse haldamisele.
Mida suurem on tiim ja lühem tähtaeg, seda rohkem ekstra raha kulub. Üritades sama funktsionaalsust kiiremini valmis saada, pole teatud piirist edasi mõtet tiimi suurust enam kasvatada. Sellel puudub igasugune positiivne netomõju ja eelarvet kulub lihtsalt rohkem. Ei tasu unustada ka Brooksi reeglit: Adding human resources to a late software project makes it later.
Samuti ei saa üks tiim olla liiga suur: meie soovitus on, et mõnus ideaalne arendustiim on 7, teatud juhtudel 9 inimest. Kui funktsionaalsust on ühe tiimi jaoks liiga palju, et seda soovitud ajaga valmis ehitada, peab rakendust ehitama mitme tiimiga korraga. See on täiesti tehtav, lihtsalt tuleb leppida, et efektiivsus (ehk mitu ühikut funktsionaalsust ühe euro eest saab) veel mõnevõrra langeb, kuna keerukust tuli taas juurde.
Brooksi reeglist metafooride keeles: kas tuleb tuttav ette? Tulevad külalised ja proovite mitmekesi köögis toitu valmistada. Keegi on sul pidevalt ees, sahtlist-kapist midagi kätte ei saa. Kiire on ja ajab tigedaks, aga söögitegemine sellegipoolest kiiremini ei edene.
Ühel hetkel saadad enamiku abilistest veini nautima ja teete rahulikult toimetades söögi päris kiiresti valmis. Nii on ka tarkvaraarenduses, et ühel hetkel on köögis liiga palju kokkasid, kes paratamatult kõik sinna tulemuslikult toimetama ei mahu.
Räägime nüüd veidi ka tähtaegadest. On oluline mõista, et ükski tähtaeg ei ole kunagi 100% kindel: iga tähtajaga käib alati kaasas selleks ajaks valmimise tõenäosus. Mida suuremat kindlust soovime, seda suurem peab olema ettenägematute asjaoludega toimetulekuks planeeritud puhver. 100% kindlust soovides oleks see lõpmatus.
Millist tõenäosust siis valida? Kui sõltuvusi on palju ning hilinemise mõjud suured (näiteks just-in-time tootmises), tasub olla konservatiivsem. Samas on ka konservatiivsusel oma hind – mitme arendava osapoolega süsteemide loomisel väheneb nende arenduskiirus.
Reeglina valmivadki asjad varem, kuid plaanid on tehtud tähtaegade järgi. Samuti tuleb tagada, et meeskonna töös ei tekiks auke ka siis, kui asjad varem valmis said. Üldjuhul on see kõige mõistlikum osapoolte vahel läbi arutada, nt stiilis kas piisab, kui seame eesmärgiks, et 80% arendusiteratsioonide lõpuks on kõik planeeritud asjad tehtud?
Tähtaegade reegel: kui projekt on ajagraafikust maas, ei ole võimalik seda mahajäämust reeglina tagasi teha. Kui projekt läheb käima, õnnestub parimal juhul mahajäämust hoida samal tasemel. Erandjuht: projekt ei olnud eriti prioriteetne ei tellija ega teenusepakkuja jaoks, kuid nüüd tõstetakse see mõlemas majas esikohale ja suurendatakse ka eelarvet.
Kui tähtaega muudetakse lühemaks, on oluline, et sellega kaasneks ka reaalsed muutused tööde teostamises (muide, meeskonnale rõhutamine, et see tähtaeg on väga oluline, ei ole muutus). Vastasel korral muutsime ainult kokkulepitud ajaks valmimise tõenäosust, mitte tegeliku valmimise aega.
Viga, mida tavaliselt tehakse, ongi liiga agressiivsete (väikse valmimise tõenäosusega) tähtaegade seadmine. Paberil võivad need välja näha head, kuid reaalsuses frustreerivad nii meeskonda kui tellijat. Hea nõks asjade kiiremini valmis saamiseks on mitte kulutada projekti aega liigselt administratiivsete tegevuste peale.
Kui näiteks aega on pool aastat ja sellest 2 nädalat kulub lepingu edasi-tagasi põrgatamisele ning veel nädal-paar vajalike ligipääsude tegemiseks, on seda aega pärast väga kulukas tagasi teha. Teatud piirist see enam ei õnnestugi.
