Hinnates tundmatut

Postitatud: 5. juuli 2014 | Autor: | Filed under: tarkvara | Tags: , | Lisa kommentaar

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!

 

Tehniline võlg ja tema intressid

Postitatud: 28. mai 2014 | Autor: | Filed under: tarkvara | Tags: | Lisa kommentaar

Intelligentsed inimesed saavad üldiselt võla ja laenu põhimõttest päris hästi aru – saan praegu palju raha, hiljem maksan rohkem raha tagasi. Ilmselgelt on selline tegevus kõige kasu(m)likum laenu andjale (pangad, eksole:)), kuid teatud tingimustel ka laenajale. Lihtsustatult – laenu on mõtet võtta siis, kui see aitab sul tulevikus rohkem teenida või vähem kulutada.

Tarkvaraarenduses on kasutusel termin tehniline võlg (Wikipedia, Martin Fowler), mis on põhimõtteliselt laen tulevase produktiivsuse/tootlikkusse arvelt. See tähendab, et praegu toodan ühes ajaühikus hästi palju uut funktsionaalsust, hiljem toodan vähem, sest tegelen hoopis varem realiseeritud asjade parandamisega. Võrreldes rahaga on tarkvara tootmise produktiivsus aga suhteline ja mittemõõdetav (Martin Fowler ja technicaldebt.com), mis ajab asja mõnevõrra keerulisemaks. Teatud tingimustel võib produktiivsust ka rahaga mõõta – kui tiim, mis alguses teenis korralikku kasumit muutub pealtnäha põhjuseta vähem kasumlikuks, siis tõenäoliselt võeti millalgi tehnilist laenu (tekkis tehniline võlg) ja nüüd makstakse intresse. Kahjumisse keeramine tähendab, et inkasso tuli ukse taha ka põhiosa välja nõudma.

Tehnilise võla alla käib kõik, mis muudab uute asjade lisamise või süsteemi käigushoidmise järjest kulukamaks/aeglasemaks, näiteks:

Võlg Intressid
lihtsalt halb kood koodist arusaamine nõuab suurt pingutust, muutmisel ootamatud regressioonid
ebapiisav kvaliteet suur osa aega ja energiat läheb vigade parandamisele
sobimatu arhitektuur / suur keerukus sisemine arhitektuuri ei toeta enam edasi arendamist, väike muudatus nõuab fundamentaalseid muudatusi
build’i ja paigalduse keerukus uued paigaldused on mitmenädalased ettevõtmised, sest on palju eel- ja järeltingimusi, et süsteem tööle hakkaks
jagamata teadmus õppimiskõver – mõne süsteemi osa kohta ei tea keegi, kuidas see toimib (Ants teadis, aga ta enam ei tööta meil…)

Ilmselgelt pole see jaotus lõplik ja need kõik omavahel tihedalt seotud, aga soojenduseks käib küll.

Kuidas võlg tekib? Põhjuseid on palju, kuid jagaks need neljaks:

Põhjus Lühidalt Kuidas tekib tarkvaramaailmas? Vaste “päris maailmas”
teadlik risk investeering – oodatav kasu ületab intresse lepinguliste kohustuste täitmiseks (leppetrahvid) või turueelise saamiseks (kiire prototüüp) planeeritud investeeringud
teadmatus ei teata ega osata paremini algaja programmeerija teebki imelikke asju “väikses kirjas tekst” näiteks krediitkaardilepingul
hoolimatus ei huvita arendaja, analüütik või testija, kes vaatab ainult oma kitsast pilti – “mina saan oma linnukese kirja, pärast tulgu või veeuputus” “peaasi, et praegu palju raha on, küll kuidagi tagasi maksan (veel parem – keegi teine maksab)”
tähtajad lihtsalt on vaja asi kindlaks ajaks ära teha lepingust tulevad tähtajad või kindla hinnaga tööd ootamatud väljaminekud või ootamatult vähenenud sissetulekud

Esimene on mõistlik, kuid ei tohi unustada, et võlg on võõra oma ja mida varem tagasi maksta, seda parem (liitintress!).

Teine on väikestes kogustes paratamatu – keegi ei sünni targana. Siia alla käivad ka pisemad hooletusvead. Seda aitavad vältida näiteks koodiülevaatused, staatilised analüsaatorid ja kõige rohkem hariv kirjandus. Enamasti on tegemist probleemiga, mida on üsna lihtne kontrolli all hoida ja ajapikku jääb seda vähemaks.

Kolmas on puhtalt pahatahtlik. Jaole saada aitavad samad meetmed, mis teadmatuse puhulgi, kuid aeg seda viga ei paranda. Kui teil sellised “sõbrad” tööl on, siis ilmselt pole vaenlasi vajagi. Soovitan tõsist südamest- südamesse vestlust või eriala vahetust (näiteks juristiks või poliitikuks).

Neljas on kõige salakavalam ja kõige levinum. Tihtipeale maskeerib ta ennast esimeseks, kuid seejärel “unustatakse” võlg ära ning tulevad juba uued tähtajad. Samuti kiputakse just tähtaegade puhul esimesena ohvriks tooma “mitteproduktiivsed” tegevused nagu koodiülevaatused, refaktoreerimine, automatiseerimine, koolitused jms, mis tekitavad hiilgava võimaluse teisele ja kolmandale kategooriale. Teoorias on vältimine muidugi lihtne – tuleb planeerida realistlikud tähtajad! Praktikas on tarkvaraarenduse täpne planeerimine segu raketiteadusest, peenest psühholoogiast, OCD-st ja nunnudest kassipoegadest. Väikelapsed ja Kettamaailma jumalad tulevad esimesena meelde – planeeri mis sa planeerid, lõpptulemuseks võib vabalt olla ka 42.

Ei, tegelikult saab ka tarkvaraarendust üsna täpselt planeerida ning tulebki. Detailid on juba teine ja hoopis pikem jutt, aga näpunäiteid ikkagi:

  • arvesta süsteemi loomulikku riknemist – tarkvara allub termodünaamika teisele seadusele:). Ehk lihtsustatult – et tarkvara oleks sisemiselt korras, tuleb selle nimel pidevalt tegutseda. Siia alla käib refaktoreerimine, arhitektuuri korrastamine, automatiseerimine, samuti dokumentatsiooni ajakohasena hoidmine. See aeg tuleb arendusse sisse planeerida. Kliendile selle aja maha müümine on muidugi kunst.
  • pane tähele väikseid märke – kui arenduste kiirus vaikselt kukub või live-toe koormus tõuseb, siis see võib olla märk tehnilisest võlast.
  • iga ajaline surve tekitab tehnilist võlga – kui tiim peab tähtajaks tarnima, siis tuleb järgmine tsükkel planeerida väiksema koormusega, sest tuleb maksta intresse ning soovitav oleks ka põhiosa tagasi maksta.
  • usalda arendajaid – kui arendaja ütleb, et korralikult tegemine võtab x tundi, siis võtabki (või kauem). Kui survestada lühema aja peale (nt y tundi), siis tuleb see hiljem ümber teha ja aega läheb x-y/2+n tundi, kus n suureneb vastavalt sellele, kui palju hiljem see ümber tehakse.
  • kui miski on liiga ilus, et olla tõsi, siis ilmselt nii ongi – kui tundub, et tiim liigub üle ootuste hästi, siis tõenäoliselt võetakse vaikselt kvaliteedi arvelt laenu.
  • arvesta liitintresse – hilisem tagasimaksmine on märksa kulukam. Samuti võib võla ignoreerimisel minna pankrotti – ühtegi uut arendust ei ole võimalik teha ilma aeganõudvate parandusteta, kuid selleks ei ole raha/aega.

Lõpetuseks temaatiline laul – Eestimaa on võlgu (parafraseerime – tarkvara on võlgu).

Vaata ka: