arendamine

Kõige lihtsamalt saab arendamise võtta kokku nelja sammuna:

Sisendi kogumine

Töötav versioon

Õigesti töötav versioon (sest elu on selline)

Kiiresti töötav versioon

Sisendi kogumine ja selle põhjal disainimine/valideerimine on praeguseks hetkeks enamjaolt tehtud. Esimese töötava versioonini jõudmine on suur samm, sest selleks hetkeks peab kogu tiim ühes suunas mõtlema ja igapäevaselt toimima. Sellest edasi ehk juba õigesti töötava versioonini jõudmine kulgeb pea igas IT-projektis aga üllatavalt valulikult. Millegipärast selgub sageli alles esimest töötavat versiooni testides, et terve hulk erijuhtusid või täiendavaid kasutajavajadusi on jäänud täiesti tähelepanuta või on terve nimekirja jagu keerukaid-aga-igavaid kohti dokumentatsioonist täiesti puudu. Veel hullemad on olukorrad, kus tekkinud tõrkeid on püütud lahendada viisil, mis on vastuolus mõne muu funktsionaalsusega.

Kui lõpuks jõutakse õigesti töötava rakenduseni, on rõõm muidugi suur - ja põhjusega! Ent me kõik oleme näinud ja kogenud (näiteks tuludeklaratsioonide esitamistega), et lahenduse töötamine madalal koormusel ja lahenduse töötamine tippkoormusega võivad olla väga erinevad olukorrad. Nutikas tiim on selleks kõigeks valmis (loe lisaks ka Tehnilise monitoorimise tegevuse infot).

Kõik tundub töötavat hästi? Kas ka piisavalt kiiresti? Kasutajauuringud, näiteks e-kaubanduse uuringud on selgelt näidanud, et kiirem rakendus teeb kasutaja rõõmsamaks - olgu teenus kuitahes hädavajalik, keskmisel kasutajal on alati midagi huvitavamat, mida ta teha tahaks. Niisiis on teenusega rahulolu hiljem otseses seoses ka sellega, kui vähe tuli kasutajal mõne sammu või tegevuse juures ootamisele aega kulutada.

Kiiruse mõõtmiseks on hea näiteks https://web.dev/measure

Alfa - esimene töötav versioon.

Selles etapis on eesmärk jõuda funktsionaalse lahenduseni, mis ei pea olema ilus ega ideaalne, aga peab olema reaalselt toimiv.

Oma teenust päriselt kasutada proovides tekib see “päris” tunne ja ilmnevad ka potensiaalsed pimenurgad, mis prototüüpimise ja testimise käigus välja ei tulnud. See omakorda võimaldab skoobis kriitilisi muudatusi teha ja teenuse olulisimaid osasid täiuslikumaks lihvida.

Kuna arendustiim ja tööprotsess vajavab samuti sisse-elamist, siis peaks sinu kui teenusejuhi põhirõhk olema sellel, kuidas saada võimalikult sujuvaks tsükkel: idee → Kasutajalugu (user story) → kood→server; ja kuidas teha nii, et iga töönädala tulemusena oleks võimalik midagi uut testida.

Mis on kasutajalugu?

Kasutajalugu on mitteformaalne üldine selgitus tarkvara funktsioonidest, mis on kasutatud kasutaja perspektiivist. Selle eesmärk on sõnastada, kuidas mingi konkreetne funktsionaalsus pakub kasutajale väärtust.

Näide kasutajaloost: Sisseloginud kasutajana, soovin (mida?), et (miks?).

Sinu järgmine samm:

arenda esimene toimiv versioon võimalikult kiiresti.

Beeta - detailne versioon

Nüüd, kus alfa versioon on valmis, on aeg arendada järgmine, detailsem ehk beeta-versioon. Selle versiooni testimisele kaasa ka rohkem kasutajaid!

NB! Ligipääsetavust ei saa lisada valmis rakendusele, selle eest tuleb hoolitseda igal sammul!
Jälgi ja korda üle et nii disainerid kui arendajad oleks kursis ligipääsetavusnõuetega ja testi lahendust regulaarselt ka ekraanilugeritega.

Olulist tähelepanu tuleks pöörata ka lahenduse välimusele ja toimivusele juhul, kui selle kasutamine mingil põhjusel ebaõnnestub. Kaasa disainer ja arendaja ning leppige kokku (ja vormistage nii disaininäidete kui dokumentatsioonina), kuidas näevad välja:

Tühi olek. Mida näidatakse juhul, kui nimekirja pole veel midagi lisatud, sisu on täitmata vms?
Laadimisolek. Näiteks mida näeb kasutaja peale nupu vajutamist ja vahetult enne soovitud järgmise sammu ette laadimist?
Osaline laadimine. Milline on ekraanipilt siis, kui kasutajal on väga aeglane internetiühendus?
Süsteemiviga. Mis saab siis, kui süsteemis sees tekib tõrge? Kui järgmist sammu ei saa laadida, mõni päring ei saa vastust jms?
Kasutusviga. Milline on vaade siis, kui kasutaja eksib vormi või teenuse kasutamisel? Kui tema poolt sisestatav tekst on liiga pikk, sisestatud vales formaadis või unustatud midagi lisamata?
Ideaalseisund. Erinevates keeltes võivad teksti pikkused väga erinevad olla, samuti toovad erinevad keeled kaasa erinevaid nõudeid kirjavahemärkide ja sümbolite kasutamisele.

Sinu järgmine samm:

Arenda esimene versioon, mida saab piiratud ringis testida. Ära unusta lisada nähtavale kohale ka teavitust, et tegemist on testimisel oleva Beeta-versiooniga, mitte lõpliku lahendusega!

Testimine

Arenduse testimine on oluline osa protsessisst ja eeldab üldiselt erioskustega tehniliste testijate kaasamist. Nende esmane ülesanne on veenduda, et lahendus töötab tehnilises mõttes korrektselt, et funktsionaalsuses ei esine probleeme ja et võimalikud kasutusvead ei põhjustaks suuremaid süsteemitõrkeid. Juhul, kui lahenduses ilmnevad vead (bug'id), saadetakse vastav tehniline osa lahendusest arendajatele paranduseks tagasi.

Ühtlasi on testimise käigus oluline veenduda, et valminud lahendus vastaks algselt kirja pandud nõuetele. Kõikidest pingutustest hoolimata võib juhtuda, et kogu projekti jooksul on teenuse omanike ja tehniliste inimeste vahel esinenud möödarääkimisi, mõne olulise asja dokumenteerimata jätmise tõttu on osapooled erinevaid järeldusi teinud või on projekti käigus selgunud uusi asjaolulisid, mida pole taibatud algses dokumentatsioonis korrigeerida. Kõik sellised situatsioonid võivad põhjustada olukordi, kus valminud lahendus erineb tellitud-oodatud lahendusest. Tehniline testimine aitab need erisused üles leida ja edasine otsustamine, kuidas tekkinud olukorda lahendada, jääb projektimeeskonnale.

Taolisi ebakõlasid aitab ennetada, kui:

Nõuete dokument on piisavalt põhjalik ja süsteemselt ajakohastatud.
Kas algne sisend oli piisav? Kas kõikidel osapooltel oli sellele ligipääs? Kas uued otsused või tähelepanekud muutsid algset infot? Kas muutunud info põhjal on korrigeeritud kõiki seotud dokumendi osasid?
Tihe kommunikatsioon kogu arendusprotsessi vältel.
Kas ja kuidas vahetatakse omavahel infot? Kas koosolekutest tehakse kokkuvõtteid? Kas kõigil osapooltel on võimalus õigel ajal olulistele küsimustele vastused saada? Kuidas toimub muudatuste kinnitamine?
Vastutus- ja otsustuskohad on täpselt paigas.
Kes vastutab millise töölõigu eest? Kes vastutab info eest? Kelle ülesanne on selle lõigu kohta dokumentatsiooni luua ja/või ajakohastada? Kes teostab järelvalvet nii tööde kui dokumentatsiooni üle?

Üldjuhul tegeleb teenusejuht äriloogika testimisega ning veendub, et kõik vajalik on olemas. Ning tehnilised inimesed (näiteks testjuht) viivad läbi tehnilisemat laadi testimised. Uuri oma asutusest, milline on testimise kord teie organisatsioonis.

Sinu järgmine samm:

Veendu, et valminud lahendus vastab algselt soovitule ning see töötab korrektselt.