Vesiagiilsus ehk kuidas suured tarkvara arendusprojektid tegelikult käivad

Agiilsed metoodikad on viimase 10 aasta jooksul saanud äärmiselt populaarseks. Kui eelmises artiklis rääkisime interaktsioonidisaineri rollist agiilses meeskonnas, siis seekord otsime vastust küsimusele, kas agiilne arendus on alati õigustatud valik?
 

Traditsioonilise meetodi piirangud

Traditsiooniline ehk waterfall tüüpi arendus on tavapäraselt jagatud käivitamise, kavandamise, realiseerimise ja juurutamise faasidesse. Tarkvara realiseerimise aeg on sageli pikk, kestes pool aastat, aasta või kauemgi.

Just realiseerimise faasis kipub tellija ja arendajate vaheline side nõrgaks jääma. Kui varem käidi üksteisega tihedalt läbi, siis nüüd on see jäänud tunduvalt harvemaks. Kui ka järelevalve on nõrk, siis on väga suur oht, et arendusprojekt ebaõnnestub.
 

Kas agiilne arendus on siis ainuõige lahendus?

Sõltub. Agiilse arenduse mõte on hoida tellija kaasas ja tuua toode võimalikult varakult turule. Nt Scrumi puhul on arendussprindid 1-4 nädalased ning iga sprindi lõpus valmib tarkvara, mis on võimalik kasutajatele proovimiseks anda.

Tulemusena on nii kasutajad kui ka tellija pidevalt projekti lülitatud ja tarkvara võimalikult varakult turul. Agiilses keskkonnas arendamine asetab arendajatele ka teatud piirangud. Ajanappuse tõttu ei ole võimalik üle mõelda, tegutsetakse fokusseeritult ning mittevajalikku ei arendada. Olulisele keskendumine koos iganädalase suhtlemisega aitab kurssi õigel teel hoida.

Seega on agiilne arendus väga hea ja efektiivne lahendus, kuid kõikidele ta siiski ei sobi. Kogemused näitavad, et projektid hakkavad katki minema siis, kui toimub liigne agiilse arenduse pealesurumine keskkondades, mis oma loomult agiilsed ei ole.

Selline tegutsemisviis meenutab pigem härja selga sadula surumist, mille tulemuseks pole õigesse kohta veetud raske koorem ega kerge ja kiire galopp, vaid kõrvaltvaatajate jaoks naljakas ning osalejate jaoks vigastusterohke sportlik tegevus.
 

Kellele agiilne arendus sobib?

Kui võtta aluseks loodava tarkvara funktsionaalsuse maht, siis agiilne arendus üldiselt tarkvara loomist odavamaks ei muuda, kuid ta aitab vähendada mõttetu funktsionaalsuse loomist.

Kui lõppkasutajate vajadused on selgelt teada ja funktsionaalsus hästi määratletav, siis on traditsionaalsed meetodid isegi odavamad. Näiteks, kui tehnoloogilistel põhjustel kirjutatakse ümber kasutajate jaoks „sisse töötanud“ tarkvara.

Agiilne arendus pole ehk parim ka kriitiliste süsteemide loomiseks. Olulisi protsessijuhtimise ja seadmete automaatjuhtimissüsteeme ei saa kahjuks rakendada nii, et teeme midagi valmis, paneme muutujad sisse, lülitame käima ja vaatame, kas protsess jääb seisma või seade plahvatab. Teatud kohtades on põhjalikult kavandatud toote lansseerimine ainuvõimalik lahendus.

Kogemustele tuginedes saame väita, et agiilne arendus toimib hästi teatud tüüpi ettevõtetes ja organisatsioonides, mis on juba loomult agiilsed. Selline lahendus sobib ideaalselt näiteks mänguarendajatele ja iduettevõtetele, samuti kõikidele teistele, kes arendavad mitte-kriitilisi lahendusi.

Eksisteerib ka teist tüüpi ettevõtteid, mis võivad olla suurettevõtted või avaliku sektori asutused, kus räägitakse palju agiilsusest, kuid tegutsetakse korporatiivses ja seadustega määratletud keskkonnas, kus agiilset arendust ei ole võimalik teha. Samas ollakse agiilsusest vaimustuses. 
 

Vesiagiilsus – segu agiilsest ja traditsionaalsest arendusest

Nii jõuamegi arendusmeetodini, mida nimetatakse kas waterscrumiks või waterscrumfall-iks ehk vesiagiilsuseks, kus küll räägitakse palju agiilsusest, kuid tegelikku agiilset arendust ei toimu. Tegemist on metoodikate kombinatsiooniga, mis pakub kõneainet ka väljaspool Eestit.

Selline arendusprojekt algab selgelt eraldatud kasutajanõuete analüüsist ja realiseerimise käigus rakendatakse agiilsete meetodikate põhimõtteid. Nt toimub töö mõnenädalaste sprintidena.
 

Erinevalt päris agiilsest arendusest lähtutakse kasutajavajaduste mõistmise osas pigem esialgsest kasutajanõuete analüüsi tulemusest, mitte ei leita nõudeid jooksvalt töö käigus. Tarkvara juurutatakse arenduse lõpus ühe korraga või mitme etapina.

Tegemist ei ole tingimata sobimatu meetodiga. Vesiagiilsus on tavaliselt suurtes organisatsioonides ka agiilsuse tegelik definitsioon. Oluline on mõista, et teatud kohtades töötavad mitte-agiilsed meetodid väga hästi ja agiilsed metoodikad ei sobitu.

Kusjuures avalike sektori projektides on viimasel ajal väga tore kuulda, et „ärme lähtu olemasolevate õigusaktide piirangutest, vaid mõtleme asja sisuliselt läbi ja teeme õigusaktid ümber". Selline mõtlemine on iseenesest väga hea ja tervitatav, kuid kahjuks on õigusloome väledusest kaugel.

Ühtegi õigusakti ei õnnestu järjest mõne nädalaste sprintide kaupa vastu võtta.  Seega tuleb kogu tervik esmalt läbi mõelda, et erinevad osapooled saaksid kokkulepitud põhimõtete alusel hakata tegema tööd just neile sobivate meetoditega.

Ideaalis võiks alati liikuda kiirema kohandumise poole ning kasutada interaktsioonidisainerite ja analüütikute poolt pakutavaid võimalusi. Just nemad saavad aidata kaasa projekti õnnestumisele ning heale lõpptulemusele.
 

Kuidas Trinidad aidata saab?.

Suurte tarkvaraarendusprojektide jaoks sobiliku meeskonna kokkupanek võtab aega, kuna arendajatel on sageli aastased projektid juba töös ja kogenud koodikirjutajate leidmine on keeruline.

Kuna meie töömaht on sellises projektis arendusmeeskonna omast väiksem, siis oleme tavaliselt valmis juba paari kuu jooksul alustama. See on piisav, et alustada kasutajanõuete määratlemise ja kasutajaliidese prototüüpimisega.

Prototüübi loomine kuulub tegelikult iga suurema arendusprojekti juurde. Kuna prototüüpi on võimalik reaalsete kasutajatega testida, siis tähendab see seda, et kirjapandud nõuded on ka tegelikult läbiproovitud. Testimise ärajätmisel võivad olla väga kulukad tagajärjed.

Me näeme, et kasutajad saavad süsteemi kasutamisega hakkama ning kui ei saa, siis muudame prototüüpi nii kaua kuni nad saavad. Selline töödega alustamine võimaldab panna tarkvara tellijal rattad liikuma, arendusmeeskonna moodustamisega seotud peavaludest sõltumata.  
 

Kokkuvõtteks

Paneksime veel südamele, et ka tarkvaraarenduse planeerimisel ja hangete koostamisel võiks kaaluda põhjalikumalt erinevate arendusmeetodite plusse ja miinuseid. Kui peate valima moodsama ja sobivaima arendusmetoodika vahel, siis kahtluste korral tasub valida just viimane.