Hinnates tundmatut

Eluline probleem tänapäeva Eesti tarkvaraarenduses: “Meil on vaja lisada süsteemile BDOC tugi nii lugemiseks kui ka loomisel. Kaua selleks läheb?”. “Eee… misasi see BDOC on? Kaks päeva? Kaks nädalat? Kaks kuud?”. Ehk siis vahel (või siis üsna tihti) tuleb ette olukordi, kus meile visatakse ette mingi uus tehnoloogia, tundmatu probleem või lihtsalt üks hiiglasuur tükk (“Vajalik aruandemoodul” – heal juhul järgneb sellele 20 lehekülge mingisugusel tasemel nõudeid või kirjeldust). Sellisele asjale on väga lihtne anda kiire ja täpne hinnang, mis ei pea absoluutselt vett (vt ka “Mis on Peipsi järve ruumala?” jms @Targo tarkvara ). Kui aga sõber klient või kallis projektijuht tahab pisut reaalsemaid vastuseid, siis tuleb enne hinnangu andmist pisut eeltööd teha.

Kui meile visatakse ette meile tundmatu küsimus või probleem, siis sõltuvalt detailsuse tasemest on meil neli eeltöö varianti:

• Eelanalüüs
• Uuring (research)
• Väljalöök (spike)
• Trasseer (tracer, tracer bullet)

Eelanalüüs

Kui probleemi kirjeldus on väga hägus, nii et ei ole täpselt aru saada, milles üldse probleem on ja mida tegelikult vaja on, siis lendab peale analüütik ja teeb eelanalüüsi. Eelanalüüsi mõte on jõuda probleemi tuumani ja kirjeldada lahendus vähemalt kasutajaloo/kasutusloo/sooviloo (User Story, need on näited eestikeelsetest vastetest) tasemel, samuti tuvastada olulised tehnilised kitsendused-vajadused (riistvara, liidesed jms).

Uuring

Kui probleem on enam-vähem selge, aga tehniliste lahendusviiside kohta pole jätkuvalt kellelgi aimu, siis tuleb ilmselt asja pisut uurida. Tüüpiline uuring tähendab otsingumootorite, foorumite ja isikliku kontaktvõrgustiku kammimist – kas kellelgi on olnud sarnane probleem ja mida nad selle lahendamiseks teinud on? Tüüpilised näited on mingite uute komponentide lisamine – otsinguserver, tekstituvastus, arhiivimoodul, andmalaod ja äriintelligents. Uuringu järgselt peaksime teadma, milliste vahenditega me probleemi lahendame.

Väljalöök (spike)

Ma olen väga solvunud, et niivõrd olulisele agiilse arenduse terminile ei ole eestikeelset vastet! Seega kasutan elektrotehnilist terminit. Igatahes – kui meil on teada probleem ning enam-vähem ka lahendusviis või -vahend, siis see ei tähenda veel, et me oskaksime lahenduse sobivust tegelikult ka hinnata. Väljalöök on põhimõtteliselt tehniline prototüüp (proof of concept – jälle, mis on vaste?). See on see koht, kus kirjutatakse koodi – mis küll hiljem ära visatakse. Põhimõtteliselt proovitakse järgi, kas valitud lahendus sobib probleemi lahendamiseks – torgitakse keerulisemaid liideseid; tehakse algelised koormustestid vms. Väljalöök ütleb – jah, pakutud lahendus teeb seda, mis meil vaja on. Nagu kasututajaliidese prototüüp, on ka väljalöögi kood mõeldud äraviskamiseks (praktikas – keeruline). Väljalöögi näide on põhimõtteliselt debugimine vea olemuse teadasaamiseks või käsitsi tehtud andmebaasipäringud.

Trasseer (tracer bullet, teine link)

Vt eelmise lõigu esimest lauset. Seekord kasutame sõjandusterminit. Trasseer on mingi kitsa osa toodangukvaliteedile vastavalt realiseerimine. Trasseeri järel teame, mille pihta me laseme ja kaugel me märgist oleme. Ehk näeme ära, milliseid teisi komponente muudatus puudutab ja kui suured need muudatused tegelikult on. Pärast trasseeri peaks olema disain selge, tehnilised ülesanded fikseeritud ja põhimõtteliselt jääb ainult koodi kirjutamise vaev. Trasseeri saab kasutada ka toodangus – näide kuulsusrikka analüüsimooduli puhul võiks olla üks enamkasutatav raport.

Nagu eelnevast jutust järeldada võib, suudame algsele hägusale probleemile viisakaid hinnanguid anda alles pärast trasseeri. Arendajad võivad nüüd lugemise pooleli jätta ja järgmisel korral BDOC-küsimusele rahulikult vastata “Ma ei oska praegu vastata, aga kui ma seda ühe päeva uurin, siis juba oskan”.

Nendel, kes allkirju jahivad või oma sajalisi luhvitama peavad, tekivad kindlasti küsimused “Kes selle kõik kinni maksab?” ja “Millal ikkagi valmis saab?”.

Teine küsimus on lihtsam. Tavaliselt eraldatakse sellistele eeltöödele kindel aeg, ajakarbistamine või ajalahterdamine (timeboxing) on asja nimi. Ehk siis antakse ette mingi piiratud aeg, mis ülesandele kulutada. Planeerimise (ja näiteks scrumi) mõttes on tegu täiesti tavalise ülesandega – kuluvat aega on kogemusele tuginedes täiesti võimalik hinnata, ülesande realiseerimist saab planeerida ja lõpus hinnata, kas on tehtud või mitte. Pärast seda suudame järgmisele etapile anda juba märksa täpsema hinnangu. Scrumis võib selliseid uurimisi planeerida sprintidesse või lihtsalt eraldada sprindi lõpus mingi aja, et järgmise sprindi ülesandeid täpsustada. Reaalsete projektide puhul (ideaal-maailmas) peaks kõik selle läbi tegema enne kliendile tähtaegade või mahuhinnangute andmist. Aga vaata ka järgmine lõik.

Kogu see eelanalüüs-uurimine-väljalöök-trasseer võib kulutada märkimisväärselt aega (=raha) ja samas on nagu väga vähe reaalseid tulemusi. Ainult trasseer on päriselt ka kasutatav, aga see võib olla ka ainult murdosa kogu lahendusest. Rahanumbrite vaates tegeleb arendaja tundide-päevade kaupa lihtsalt mingi voodooga – öelgu kohe oma hinnang ära, veel parem – tehku lahendus ka kohe ära, kui keeruline see ikka olla saab??? Ideaalmaailmas käivad aga raha ja mõistus käsikäes ja kõik need kirjeldatud tegevused suurendavad tõenäosust, et klient saab ka selle, mida tegelikult vaja on. Kogu tarkvara-arenduse teooria korrutab “mida varem viga avastatakse, seda odavam on parandamine”. Kaks päeva midagi lihtsalt uurida on tundub päris pikk aeg, aga kui alternatiiv on kaks nädalat arendada ja siis avastada, et “nii ikka ei saa”, siis võib-olla ikka tasub uurida (Einsteini arvamus). Uurimisele kulutatud aeg ei ole kunagi mõttetu, see on rubriigist “töötame targemini, mitte rohkem”. Iseasi on selleks reaalselt ka aja leidmine ja eraldamine, kuna

1. tavaliselt on tähtaegadega jube kiire
2. klient maksab töötava tarkvara eest

Tark klient tellib ja maksab muidugi ka uurimise eest, sest ta saab aru, et lõppkokkuvõttes maksab ta siis vähem. Mitte-nii-targa kliendi puhul peab kallis projektijuht mingeid muid kavalusi välja mõtlema, näiteks arveldama järgmise kuu arenduste uurimised eelmise kuu realisatsiooni sisse või midagi muud taolist. Fikseeritud hinna, tähtaja ja skoobiga projektide puhul (näiteks riigihanked) on lugu keerulisem ja üleüldse tuleks sellistest projektidest karjudes kaugemale joosta, aga ka siin on lõppkokkuvõttes odavam kulutada aega uurimisele, kui hiljem ägada ebareaalsete ajahinnangute ikkes.

Head uurimist!

Inspiratsioon:
Chris Sterling – Managing Software Debt: Building for Inevitable Change (Agile Software Development Series)

Research, Spikes, Tracer Bullets, Oh My!