Jan 03 2018

Informaatika õppekava: good, bad and ugly

Published by Targo under Haridus, Raha

Infoaja kultuurist ja olustikust 

Detsembri keskel toimus gümnaasiumi informaatika ainekava ümarlaud. Kohal oli igasugust huvitavat rahvast: ministeeriumist, ettevõtetest, kesk- ja ülikoolidest, teemaspetsiifilistest asutustest, nagu HITSA ja Innove. Ka mind oli kutsutud, ilmselt seetõttu, et mul on üldiselt kombeks igale poole nina toppida ja erinevatel teemadel jaurata.

Olen viimastel aastatel töötanud peamiselt idufirmades, kus kõigile probleemidele lähenetakse ülipragmaatiliselt ja peamine eesmärk on kõike muud kõrvale jättes „teeme asja ära“. Haridusvalla seltskonda sattudes pidin esmalt kohanema hoopis teistsuguse emotsionaalse õhkkonnaga.

Näide: ettekandele, mis minu arvates oli huvitav, informatiivne ja täiesti neutraalne, järgnes teise asutuse esindaja reaktsioon „Miks te meie tööd maha teete?“. Sarnaseid suuremaid ja väiksemaid solvumisi ja neile järgnevaid silumisi oli päris mitu. Sain ka ise oma esimese sõnavõtu järel kergelt vastu näppe ja olin hiljem ettevaatlikum.

Seetõttu jäi mind kummitama õppekavaväline küsimus: tegu oli ju põhimõtteliselt üsna otsese ja mõneti isegi kuiva teemaga – miks osalised nii pinges on ja miks siin nii suurt umbusaldust ja kriitikahirmu tuntakse?

Lihtsaim selgitus oleks muidugi, et õpetajatel on liiga vähe raha ja see muudab inimesi närviliseks. Samas näen ma võrreldavaid agressiivses kaitseasendis reaktsioone igal tasemel, professorite, akadeemikute ja ministriteni välja. Mul on seetõttu hüpotees, et meie haridus põhineb fundamentaalselt rohkem laitusel kui kiitusel, seda juba lasteaiast alates (võiks kasvõi statistikat teha, kui palju öeldakse koolipäevas kiitvaid sõnu võrreldes laitvatega). Seetõttu on ka õpilased ning lapsevanemad võitlusvalmis, pelgavad seda, mis koolist tuleb, ning hammustavad teinekord juba ennetavalt vastu. Tagajärjena koguvad haridustöötajad endasse kõvasti allergiat ja kasvatavad okkaid.

Kui ma pärast üritust mainisin, et väga huvitavad teemad, refereeriksin neid kusagil, kuulsin ka reaktsiooni:  „Ära tee, inimesed võivad solvuda.“ Keeruline olukord tõesti, kuid leian, et antud teema on siiski väärt laiemalt kui mõnekümnele inimesele valgustamist. Praegu jäävad mitmed teemad selliste pingete pärast üldse arutamata ja lahendamata.

Eelnevat arvestades ütlen seega juba ette ära, et kui ma kellelegi varbale astun, siis see pole minu kavatsus. Eesmärgiks on ikka see, kuidas asju paremaks teha.

The Good 

Minu jaoks kõige positiivsem oli see, et kohal oli palju inimesi, kes tõesti soovivad elu edendada ja asju paremaks muuta. Eestis on mitmeid asutusi ja ettevõtmisi, mis vankrit sikutavad, kuigi nende struktuur ja võimalused on väga erinevad. Need, kelle jaoks üritusele kohaletulek polnud otsene tööülesanne, ongi muidugi definitsiooni kohaselt entusiastid, nii mõnigi neist korraldab ainealast ringi või kursust. Ma ise korraldan informaatikaolümpiaadi, mille üle olen ka päris uhke, aga kõige kõvema panuse on minu arvates andnud Eno Tõnisson, kelle juhitud internetikursused (http://programmeerimine.ut.ee) on õpetanud programmeerimist juba tuhandetele ja tuhandetele inimestele.

Eno tegi ka ühe põhiettekannetest, kus oma mass-internetikuruste (MOOCide) kogemusi jagas. Kokku on neil kursustel osaletud üle 15 000 korra, kuigi seal on ilmselt korduvusi, sest paljud on osalenud mitmel kursusel. Arv näitab, et ühiskondlik huvi programmeerimise vastu on kõrge, ületades suuresti kõigis Eesti vastavates erialakoolides õppijate koguarvu.

Eesti Informaatikaõpetuse ajaloost rääkis Urmas Heinaste. Siin saan õnne tänada, et mu enda keskkoolitee jäi selle ajaloo algusjärku, kui keskkoolides õpetatigi konkreetselt programmeerimist. See andis mulle omal ajal päris tugeva tõuke ja nii mõnedki praeguste kõvade IT-firmade juhid on samast perioodist. 1996. aastal eraldi programmeerimise õpe lõppes ning pärast seda on informaatika sildi all õpetatud mitmesuguseid erinevaid asju.

Erinevatest õppemudelitest rääkis Mart Laanpere, kelle ettekandest jäi mulle enim meelde järgmine joonis:

Skeemi mõte on selles, et on kolm peamist jõudu, mis informaatika õppekava erinevates suundades sikutavad. Ülemine neist on ”akadeemiline” suund, mis täidab eelkõige vastava eriala (antud juhul arvutiteadust õpetavate) kõrgkoolide ja ettevõtete tellimust. Parempoolne peaks ette valmistama nö laiatarbe IT-oskusi, selliseid mida nõutakse näiteks arstilt, taksojuhilt või müüjalt. Lõpuks alumine osa täidab eelkõige kooli enda eesmärke, arendades IKT-oskusi lõimitud kujul, näiteks läbi arvuti kasutamise teistes ainetundides.

Ettekandja oli teinud ära huvitava taustatöö, paigutades skeemile selle, kus mitmed riigid praegu asuvad ja kuhu nad liikuda plaanivad. Kui Inglismaa puhul oli määravaks erialaste firmade tellimus ja surve, siis näiteks Soome asus end liigutama kuulujutu tõttu, et Eestis õpivad kõikesimeste klasside lapsed programmeerimist, ega soovinud naabrist maha jääda.

Enamik ürituse diskussioonist keskenduski sellele, milline võiks olla Eesti liikumissuund (A tähistab praegust asukohta).

Headest asjadest edasi rääkides tahan tunnustada Eesti haridusasutusi, eriti Tartu Ülikooli, kus hoolimata spetsiifilise rahastuse puudumisest juba mitu aastat laia avalikkust on programmeerimise juurde toodud. Teiselt poolt lähevad minu tänusõnad paljudele ettevõtetele, kes mitmesuguseid haridusalaseid ettevõtmisi on toetanud, olgu siis tegu õppejõudude hankimise, oma töötajate ülikoolidesse õpetama saatmise või õpilasürituste sponsoreerimisega.

The Bad 

Kuigi üritus oli hästi läbi viidud ja ettekandjad valdasid selgelt teemat, jäid minu hinge kripeldama mitu asjaolu.

Esimene oli see, et vaatlusalune kolme tõmbesuunaga mudel keskendub sellele, mida mingid välised osalised täna soovivad. On selge, et arsti või taksojuhi kutsestandard on suure tõenäosusega koostatud vastava valdkonna juhtide ehk siis eelmise või üle-eelmise põlvkonna esindajate poolt. IKT ettevõtted on pisut paremad, kuid olles viibinud üritustel, kus arutatakse näiteks nende tellimust ülikoolidele, tundub ka seal olevat kahetsusväärselt palju lühiajalist mõtlemist. Kui täna on vaja Java-programmeerijaid, siis seda nõuamegi, kui teatud metoodikat tundvaid süsteemianalüütikuid, siis nõuame neid jne.

Ideaalses maailmas oleks joonisel esindatud ka konkreetselt tulevikku vaatav jõud, kes mõtleks, millistest oskustest on kasu nt 15-20 aasta pärast. Omaaegne keskkoolis programmeerimise õpetamine oli küll nõukogudeaegse kampaania vili ning sai koosviibimisel ka arvestatava sarkasmi osaliseks, kuid see oli siiski oluliselt tulevikku vaatav. Kui toona oleks lähtutud pigem vabrikudirektorite ja kolhoosijuhtide tellimusest, siis kas näiteks 90. aastate alguses keskkoolis käinud Skype’i tegijad oleks samaks ajaks sama kogemuse saanud?

Teiseks olid valikud suuresti kinni mitte sisus, vaid vormis. Kas õpetus peaks olema iseseisva ainena või teistega lõimitult? Kas rühmaprojekti või tunnipõhise kava alusel? Algama kümnendas või üheteistkümnendas klassis?

Nii palju kui sisust juttu oli, jäi mulle tunne, et see on küllaltki eklektiline: samal pulgal 3D-modelleerimine, geoinformaatika, mehhatroonika, programmeerimine, robootika. Programmeerimise kohta öeldi korduvalt, et see on spetsiifiliselt neile, kes seda erialaselt õppima ja hiljem vastavasse ettevõttesse tööle läheks.

Viimases punktis jäin ma eriarvamusele: minu seisukohalt pole programmeerimine sugugi ainult kitsalt erialainimeste pärusmaa, vaid väga praktiline üldoskus ja ka märgatavalt laiema kasutuspinnaga kui teised loetletud oskused.

Kui 90. aastate alguses olid arvutid veel vähelevinud ja programmeerimisoskust raskem rakendada, siis tänapäeval kasutatakse neid igal erialal. Arvuti eripära on aga selles, et ta on masinana universaalne – lisaks tööjuhendis vajalikele ülesannetele saab teda panna tegema ka igasuguseid muid asju. Ning kui sa suudad arvuti enda heaks tööle panna, on see sama võimas kui isiklik assistent, kes osa su tööst endale võtab – sinu efektiivsus ja ühiskonnale toodav lisaväärtus kasvavad hüppeliselt. Siin võivad näideteks olla nii lasteaiaõpetaja, kes kohalolijate märkimiseks lihtsa veebisaidi loob, ametiasutuse asjaajaja, kes skaneeritud dokumentide laialijagamiseks väikese skripti koostab, kui ka põllumees, kes optimaalse väetisekoguse leidmiseks Exceli makro teeb. Need kõik on elust võetud näited ja igaüks neist suurendab mingis pisikeses lõigus ühiskonna toimimise efektiivsust. Tulemusena saavutaksime aga samasuguse sotsiaalse hüppe nagu siis, kui kogu rahvas lugema ja kirjutama õppis.

Selliseid võimalusi panna masinaid tegema ära rutiinseid tegevusi on tuhandeid, kuid enamik neist ei jõua kunagi seda järge ära oodata, et „päris“ programmeerijad suure raha eest vastava töö ära teeks. Analoogiliselt olid kunagi olemas üksikud kirjaoskajad inimesed, kes teiste eest kirju kirjutasid ja neile raamatuid ette lugesid, ilmselgelt jäid siis enamik vajalikest kirjadest kirjutamata ning raamatud lugemata. Praegu kardaks enamik inimesi selliste ülesannete lahendamist isegi üritada, kuid need, kes on programmeerimisega natukegi kokku puutunud, saaks juba kasvõi veebist leitud instruktsioonide varal hakkama. Ka Tartu Ülikooli MOOCide populaarsus kinnitab vastavat vajadust.

Osalejaskond jagunes selles osas kahte lehte, oli nii neid, kes mind toetasid, kui ka neid, kes ütlesid, et koolis programmeerimise õpetamine on sama praktiline kui alpinismi õpetamine – ainult entusiastidele. Mis tegelikult saama hakkab, näitab aeg.

The Ugly 

Räägitud teemadest olulisem oli aga ruumis viibinud elevant, kelle vari kõigile teemadele langes, aga kelle olemasolu sellegipoolest keegi ei maininud. Tõenäoliselt sellepärast, et keegi ei osanud sellega midagi peale hakata, kuid igasugusele plaanile on ta takistuseks ikka.

Tegu on mõistagi informaatikaõpetajate palga teemaga. Kui informaatikaõpetajad saaks riigieelarvest rohkem palka kui teised õpetajad, põhjustaks see ilmselgelt kõvasti nurinat. Kui tal on aga olemas head IT-alased oskused (ja selleks, et lapsi õpetada, võiks need ju olla, lisaks ka pedagoogilised teadmised), aga palka saab vähem kui nooremspetsialist suvalises IT-firmas, on ka narr eeldada, et see eriala teab kui populaarne oleks. Ja tõepoolest, TLÜ sulges hiljuti vastava õppekava nõudluse puudumise tõttu.

Teiseks oleme langenud omaenda „kuvandi loomise“ kampaania ohvriks. Ühelt poolt, nagu eeltoodud Soome näitest näha, teevad naaberriigid ära asjad, millest Eesti puhul vaid pressiteated eksisteerivad. Teiselt poolt on ka kohalikud otsustajad uskuma jäänud, et IT-s ongi kõik juba suurepärane ja vastavasse haridusse pole tarvis rohkem panustada. Drastiline näide: Statistikaameti andmetel olid avaliku sektori kulutused teadus- ja arendustegevusele 2016. aastal väiksemad kui 2008. aastal! (https://www.stat.ee/pressiteade-2017-128).

Silmaga nähtav väljund neile probleemidele ongi, et osalised on vastastikku umbusklikud (olen olnud korduvalt tunnistajaks näiteks olukorrale, kus üldhariduskoolid ja ülikoolid takerduvad koostööd arutades sellesse, kelle kaudu mingi raha peaks liikuma), tirivad õhukesevõitu tekki enda poole ja jagelevad saadaoleva ressursi pärast, kui tegelikult peaks tegelema sellega, kuidas laiem ja paksem tekk hankida, mis kõiki korralikult kataks.

Mis on lahendus?

Õppekava ürituse üks meeldejäänud joon oli veel erinevate osaliste arv – haridusasutused, riigiasutused, sihtasutused, ettevõtted, liidud, seltsid. Igaüks neist korraldab oma üritusi ja projekte, mõnel on raha, teisel on inimesi, mõnel õnnelikul ka mõlemat. Tegevused on aga tavaliselt suhteliselt piiratud, ebastabiilse rahastusega. Ma käin isegi igal sügisel erinevatelt firmadelt olümpiaadi korraldamiseks raha küsimas.

Rääkisin teemast TÜ Arvutiteaduse Instituudi juhi Jaak Viloga, kes kinnitas samuti: „Probleem on Eestis, et kõik käigu justkui õhina-tuhina korras ja projektikestega. Õppekava võimalusi nii ei saa arendada.“

Tõepoolest, entusiastide tegutsemine on väga hea, kuid küsimuse struktuurseks lahendamiseks peaks enim panustama need, kes IT ja programmeerimise õpetamisest ka kõige rohkem kasu saavad. Peamisteks kasusaajateks on ühelt poolt IT-ettevõtted, kelle praegust potentsiaalset käivet ja kasumit kvalifitseeritud tööjõu nappus otseselt piirab, ning teiselt poolt Eesti riik, kellele vastava võimekusega spetsialistid mitmekordse keskmise jagu makse maksavad ja samal ajal riigi üldist infrastruktuuri efektiivsemaks muudavad.

Kahjuks esineb siin aga palju näpuga näitamist: ettevõtjad süüdistavad riiki ja haridusasutusi, et nood ei tee piisavalt õigeid asju, aga riik uriseb vastu, et miks ettevõtted ise ei panusta. Lahendus võiks peituda koostöös.

Esimene koostöötase saaks aset leida eraettevõtete vahel. Selle asemel, et igaüks midagi eraldi teeb, saaks luua Eesti IT-hariduse konsortsiumi, millel on võimalik tuhandete eurode asemel käsutada miljoneid ning sellega midagi tõsisemat korda saata.

Teine koostöö võimalus on ettevõtete ja riigi vahel. Olgu meil vaja palgata ülikoolidesse paar kõva õppejõudu või meelitada hulk spetsialiste koolidesse programmeerimist õpetama – vastastikune hea tahte avaldus ja riske maandav käitumine oleks see, kui näiteks ettevõtete konsortsium panustaks veerandi jagu rahast lõiku, mis neid enim aitaks ja riik kataks vastavatest kuludest ülejäänud kolmveerandi (viimase skeemi soovituse sain samuti Jaak Vilolt).

Veel üks vastus peitub taas pikemaajalises mõtlemises ja tänasest kaugemale vaatamises. Praegu räägitakse palju spetsialistide sissetoomisest. Esiteks ei suuda me sellel turul iial konkureerida selliste industriaalse võimsusega ajuimejatega nagu Silicon Valley või ka London või Berliin, mistõttu Eestisse jõuavad vaid globaalse intellekti teise ešeloni esindajad. Teiseks on see nagu kolmanda maailma riikide majanduskäitumine – selle asemel, et investeerida omaenda tööstusse, ostetakse teiste riikide valmistoodangut.

Nii nagu Saksamaa ehitas 20. sajandi keskel uuesti nullist üles kõva tööstuse ja tagas endale sellega pikaajalise juhtpositsiooni, on ka spetsialistide osas pikas plaanis efektiivsem ostmise asemel „ehitada ajutööstus“ ehk panustada vastavalt haridussüsteemi.

Selleks tuleb aga ettevõtetel mõelda kaugemale järgmise paari aasta kasumiaruandest ning riigivalitsusel kaugemale järgmistest valimistest. Vastasel korral ei jää ei tiigrist ega kuvandist lõpuks midagi järele.

Viimane lahendus on rohkem unistuste vallast, kuid siiski realistlik. Palju on räägitud sellest, kuidas Skandinaavia maade elanikud ei pane pahaks kõrgeid makse maksta, sest nad saavad selle eest vastu häid teenuseid, maksude maksmine on rohkem au- kui häbiasi. Analoogselt võiks Eesti eripäraks olla uhkus tulevikku (eriti haridusse) panustamise üle. Nii riik, omavalitsused kui ettevõtted saaks kiidelda ja võistelda, millise protsendi keegi oma eelarvest/kasumist haridusse ja tulevikuprojektidesse paneb. Maailmas, kus pahatihti elatakse pigem tuleviku arvelt, oleks “IT-riigi” kuvandist veel kõvem sõna “tulevikku panustav riik ja ühiskond”.

No responses yet

May 12 2016

Agiilsus kui kaubakultus ja laiskuse vabandus

Published by Targo under Projektijuhtimine

Kui sa osaled tänapäeval mingis tarkvaraprojektis, on selle osalejad või juhid tõenäoliselt kusagil öeldud, et see on agiilne* projekt. Ütlemise kohaks võivad olla müügimaterjalid, värbamiskõned või muu koht, kus vaja end popi ja tublina näidata.

Võid selle väite kontrolliks teha väikese testi:

1. Kas teil on igapäevased standupid?

Sõltumata vastusest saad 0 punkti. Rituaalsed protseduurid, nagu kindla formaadiga koosoleku pidamine, ei oma mingit tähtsust.

2. Kas teie loodud kood on viimase 2 kuu jooksul päris kasutajateni jõudnud? Tellija projektijuht ei loe, loeb ainult reaalne kasutamine!

Kui jah, lisa 1 punkt. Pidev tarne (ja ka kasutusele võtmine) on agiilse arenduse üks tugisambaid.

3. Kas teie projekti liikmed on sertifitseeritud agiilsete meetodite praktiseerijad?

Vahet pole, punkti ei saa. Sertifitseerimine on sama kõva äri kui kokaiini müümine ja paljudel tublidel inimestel on mitmesuguseid sertifikaate. Ükski paber ei vii aga projekti ellu

4. Kas te saate (vajadusel) muuta nii töö skoopi kui ka tähtaega?

Kui jah, saad punkti. Kui tuuakse vabandusi, nagu „leping/projektiplaan ei luba“, siis pole tegemist agiilse arendusega. Plaani muutmine  vastavalt oludele on agiilse arenduse põhitunnus.

5. Kas teie töö on organiseeritud 2–4-nädalasteks sprintideks?

Taas 0 punkti. Tööd võib organiseerida kuidas iganes, kasvõi nõnda, et iga arendaja tarnib erineval päeval ja erineval viisil. Oluline on vaid see, et tarnimine oleks lühikeste vahedega. Sprintideks jagatud projekt, kus tegelikult antakse üle iga viies ja juurutakse iga viieteistkümnes sprint, ei ole agiilne.

6. Kas te olete saanud viimase 2 nädala jooksul lõppkasutajate tagasisidet (loeb ka automaatsete vahendite abil saadav tagasiside)?

Kui jah, liida veel 1 punkt. Projekti tuunimine  vastavalt kasutajate tagasisidele on üks peamisi vahendeid paindlikkuse ja efektiivsuse saavutamisel.

7. Kas teil on paigas rollid, nagu Scrum Master ja Product Owner?

See on ka nulli-küsimus. Selged rollid projektis tõstavad üldiselt õnnestumise tõenäosust, sest inimestel on selgem pilt, mida teha. Samas see, millised need rollid täpselt on ja kuidas me neid nimetame, ei anna inimestele kompetentsust ja olude mõistmist juurde.

8. Viimaseks kõige olulisem küsimus – kas projekti liikmed saavad vajadusel kehtestatud protsesse eirata ja asju teisiti teha?

Kui jah, pane 1 punkt juurde. Veel üks agiilsuse põhitunnus on see, et ei muututa reeglite orjaks, vaid vajadusel tehakse neid ümber või minnakse neist mööda.

Liida nüüd punktid kokku. Kui said 4 punkti, siis sinu projektis on agiilne arendus. Kui kogusid 2–3 punkti, siis sinu projektis kasutatakse agiilse arenduse olulisi elemente. Kui tulemuseks oli 0–1 punkti – sinu projekt ei ole agiilne. On võimalik, et selles mängitakse agiilsust.

Tegelikult on testimine veel lihtsam – vt http://agilemanifesto.org/ ja kontrolli, kas sinu projektis järgitakse reaalselt neid printsiipe või mitte. Olen aga näinud mitmeid projekte, kus arvestatakse  hoopis neid „põhimõtteid“: http://www.halfarsedagilemanifesto.org/. Riigihangetel ütlevad tänapäeval vist kõik pakkujad, et nad on agiilsed, seda isegi juhul, kui hanketingimused nõuavad fikseeritud skoopi, hinda ja tähtaega.

Mida täpsemalt tähendab agiilsuse mängimine? Klassikaline võrdlus on juba seitsekümmend aastat vana.

Pärast II maailmasõda, kui USA väed olid lahkunud, ehitasid mitmete Vaikse ookeani saarte elanikud puust maandumisradu ja lennukimakette. Rajati ka puust onne, kus sees istus mees, kaks kookospähklikoort kõrvaklappideks, millest bambustorud antennidena välja turritasid. Maandumisraja ääres süüdati lõkketuled ja jäädi ootama lennukeid valgete meeste ja imeliste kaupadega… Samamoodi teevad tarkvaraprojektides tuhanded inimesed entusiastlikult standup’e ja pügavad backloge ning ootavad siis suurepäraseid tulemusi.

Tulemusi aga mõistagi ei saabu, sest just nagu pärismaalased ei mõistnud lennukite saabumise põhjust, ei mõista ka paljud projektijuhid tarkvaraprojektide õnnestumise või ebaõnnestumise põhjuseid.

Reaalselt on hea tarkvara jaoks vaja kliendi vajaduste mõistmist või edukat tundmaõppimist, oma töövahendite ja platvormi head mõistmist, kõrget tööeetikat ning ootamatustega arvestamist. Kui need omadused on olemas (ehk me oskame lennukiga lennata), siis võime kasutada ükskõik millist metoodikat (ehk võime maanduda igal lennuväljal). Ja kui neid ei ole, siis kukume iga metoodikaga puruks või ei tõuse isegi mitte õhku.

Kõik need oskused tulevad enamasti kogemuse ja suures osas ka andega. Kui esineb telekokk Jamie Oliver, tundub hea toidu tegemine imelihtne ­– sortsuke seda, näpuga toda, tuli alla ja valmis. Kui aga mina prooviks lihtsalt tema efektseid liigutusi järele teha, poleks tulemus tõenäoliselt suurem asi. Ma oskan küll üsna hästi mõnesid tarkvara alaseid probleeme lahendada, aga toidu jaoks on minusugusel tarvis detailset retsepti, kus kraadid, grammid ja minutid täpselt kirjas.

Tarkvaraarenduses nimetatakse selliseid retsepte metoodikateks. Kirjutatakse näiteks ette spetsifikatsioonide formaat, koodistandardid ja tööde üleandmise-vastuvõtmise vormid. Kulinaarses maailmas on selle vasteks McDonald’s, kus iga liigutus on spetsifitseeritud, et ka ilma eelneva kogemuseta inimene hakkama saaks. Mingis ulatuses see asi töötab, aga võib erijuhtudel osutuda kohutavalt ebaefektiivseks ja osalised võivad teha palju asjatut tööd. Ja tulemus on ka nagu McDonald’s Jamie Oliveri kõrval – täidab ennustatavalt kõhtu, aga pole mingi kõrgtasemel elamus.

Mõni inimene ei taha aga McDonald’sis mööda nööri käia või range metoodika järgi tarkvara arendada. 15 aastat tagasi leidsid mõned hakkajad mehed, et tarkvaraarenduses on bürokraatiat liiga palju ja võiks saada lihtsamalt. Nende protesti tulemusena sündiski ülalviidatud agiilse arenduse manifest.

Paljud teised tublid inimesed võtsid õppust ja saavutasid häid tulemusi. Veel rohkem oli aga neid, kes vaatasid toimuvat nagu mina vaatan telekokk Oliveri. Nägid, et tehakse mingeid liigutusi, kuid ei osanud neid järele teha ning küsisid retsepti. Vastusena sellele küsimusele tekkisidki agiilse arenduse metoodikad ja eeskirjad. Konsultandid rääkisid, milline on hea koosoleku formaat, kui kaua peaks kestma iteratsioonid, millised rollid peavad olema defineeritud jne. Selline lähenemine on aga juba oma olemuselt vildakas, sest agiilne mõtteviis vastandub just nimelt detailsetele, fikseeritud metoodikatele. Ehk siis mida täpsemalt me oma „agiilset metoodikat“ järgime, seda vähem agiilsed me tegelikult oleme. Ja retsepte järgides ei saaks minust iialgi Jamie Oliveri, selleks peaks mõistma toiduvalmistamise olemust hoopis teisel tasemel.

Vahel tehakse asja isegi halvemaks. Vana ja tuntud waterfall ja sellest tulenevad metoodikad näevad ette mitmesuguseid dokumente. Nõuded, spetsifikatsioonid, testjuhtumid jne. Kõigi nende kirjutamine pole kuigi lõbus, koodi kirjutada on lahedam. Nüüd on aga lihtne vabandada laiskust agiilsusega. Me oleme agiilsed ja meil pole spekke vaja!

Tarkvara korralikult tegemine nõuab aga endiselt arusaamist, mida, miks ja kuidas tehakse. Selle teadmise hoidmiseks võib agiilses maailmas paberdokumentide asemel kasutada teisi vahendeid, nt TDD/BDD, aga enamik mängult agiilseid projekte jätab sellised ebamugavad asjad tegemata. Lõppkokkuvõttes saame halvima mõlemast maailmast: halva kvaliteediga puudulikult dokumenteeritud koodi, mille kohta keegi ei tea, miks ja mida seal tehti ning mis läheb eelarvest ja tähtajast üle.

Milles siis asi? Agiilsus ei ole metoodika, vaid mõtteviis. Kahjuks jõutakse agiilsuse vajaduse mõistmiseni alles pärast paljude kogemuste ja teadmiste omandamist. Agiilse manifesti autorid olid kõik kogenud, targad inimesed ja nad ei tulnud ehk selle peale, et kõigil tarkvaraarendajatel pole võrreldavat pagasit.

Mida aga teha? Vajalike reeglite hulk on pöördvõrdelises seoses inimeste kogemuse ja pädevusega. Kui sul on kompetentne meeskond, siis saad olla agiilne ja head koodi tuleb nagu Jamie Oliveri potist putru. Kui sul on aga vähem kogenud meeskond, siis pead asju tegema täpsete reeglite järgi, nii nagu mina pean piiluma retseptiraamatusse. Sel juhul ei tohiks sa aga nimetada oma tegevust agiilseks arenduseks. Parem on mitte lolli mängida, tunnistada, et oled pigem McDonald’si tüüpi koht, kookoskõrvaklapid peast võtta ning mitte inimesi püstijalakoosolekule kamandada.

*„agiilne“ on eesti keeles paras värdsõna, aga saanud de facto standardiks. Parema puudumisel ja üldise arusaamise huvides kasutan seda ka siin. Tähendusväljalt sobivad vasteteks nt sõnad „väle“, „osav“, „paindlik“, “nobe”.

PS Bondoras me skoorime minu hinnangul praegu 3,5 punkti neljast, töötan ise muuhulgas selle viimase poole punkti saavutamise kallal. Kui sinu sooviks on töötada dünaamilises, kiirelt tegutsevas ja reageerivas ettevõttes ning sul on tugev .NET arenduse kogemus, võid minuga ühendust võtta.

2 responses so far

Jan 15 2016

Külma sõja aegse tuumarünnaku mõjud Eestile

Published by Targo under Maad ja rahvad

(Sellel artiklil pole tarkvaraga midagi pistmist peale selle, et tarkvara abil saab tänapäeval hästi andmeid analüüsida ja visualiseerida)

2007.aastal külastasin ma Arizona osariigis Titan kontinentidevaheliste ballistiliste rakettide muuseumi. Väljapanek on seal muljetavaldav, eriti jäid mulle meelde hiigeljämedad vedrud, millega maa-alune juhtimiskeskus ümbritsevast kivimpinnasest eraldatud on, et lähedase tuumalöögi peale mitte puruneda. Giidiks oli endine raketiväelane, rääkisin temaga paar sõna, et mina ka ex-Soviet ja võibolla oli see rakett kunagi just minu pihta sihitud. Ja eks Eestistki oldi valmis imperialistide pihta tuld andma.

See oli kõik siiski niisama teoretiseerimine. Hoopis õõnsam tunne tuleb aga kõhtu, kui päriselt lugeda militaarstiilis formaaditud masinakirjas dokumenti, kus mitmemegatonniste pommide sihtmärkide nimekirjas on Haapsalu, Võhma, Rakvere, Tartu.

Nimelt avalikustati USAs eelmise aasta lõpus dokumendid, kus on muuhulgas ära toodud mitmesuguste sihtmärkide nimekirjad. Nimekirjad olid koostatud aastal 1956, eesmärgiga saavutada aastaks 1959 nende ründamise täielik võimekus (mis ka saavutati).

Uudist mainis lühidalt ka Päevaleht, kuid kahjuks oli sealne info eksitav. Peamise allikana kasutas Päevaleht kaarti, kus on ära toodud top 20 strateegilist sihtmärki, millest 13.kohal asus Tartu Raadi lennuväli. Siit tehti ekslik järeldus, et rohkem neid polnudki. Tegelikult oli esimese järgu strateegilises nimekirjas enam kui 1100 sihtmärki, millest ma loendasin Eestis asuvateks 16 (number nime ees tähistab prioriteeti üldnimekirjas):

13 – Tartu
78 – Pärnu
103 – Paldiski/Vasalemma (Ämari baas)
152 – Paldiski/Klooga
231 – Tallinn/Lasnamäe
236 – Mõnnuste (Saaremaal)
296 – Rakvere
297 – Haapsalu
351 – Tallinn/Ülemiste
371 – Kuusiku
379 – Tapa
526 – Võru
571 – Kuressaare
940 – Võhma
1010 – Põltsamaa
1105 – Valga
Valikuloogika on lihtne. Ballistilisi rakette oli vähe ja nad ei olnud veel kuigi praktilised. Pommide peamiseks “tarnevahendiks” olid lennukid, USA-l eelkõige B-47 ja B-52. Kuna Nõukogude poolel oli põhilöögirusikaks samuti lennuvägi, moodustasid esimese nimekirja lennuväljad ning muud lennuväe toimimiseks vajalikud objektid – kumb kumma esimesena rivist välja lööb.
Vaata ülaltoodud väljavõtet sihtmärkide nimekirjast – pärast kohanime on seal kaks arvupaari. Esimene on viide ühele teisele (endiselt salastatud) dokumendile, millest arvatakse, et seal on veel täiendavat infot sihtmärkide kohta. Teine on geograafiline laius- ja pikkuskraad, mille saab jagada kraadideks ning minutiteks. On tähelepanuväärne, et asukohad on antud kaareminuti (ehk kilomeetri-paari) täpsusega. Ma ei tea, kas kusagil olid ka täpsemad koordinaadid, aga dokumendis on kirjas, et pommitajate CEP (circular error probable ehk raadius, kui palju arvestati, et pomm võib märgist mööda minna), oli 900 meetrit, ballistiliste rakettide oma 2 meremiili (3,7km). Seepärast tehti vesinikupommid oluliselt võimsamad kui need, mida tänapäeval kasutatakse. Kui kaasaegsed Minuteman raketid kannavad mõnesaja kilotonniseid lõhkepäid, siis 1950.aastate MK15, MK27 ja MK36 pommid olid poolteist kuni 10 megatonni. Põhimõtteliselt tähendab see, et Raadi lennuvälja ründamise tagajärjel kadunuks kaardilt ka kogu Tartu.
Aastal 1956 oli USA-l selliseid pomme kokku natuke alla 10 tuhande, aastal 1960 üle 20 tuhande. Pommide valiku osas olid võimsaimad pommid ette nähtud just lennuväljade jaoks (enamik Eesti sihtmärkidest). Nõukogude Liidu satelliitriike sooviti mingil määral säästa, aga Eesti osas polnud vahet, saanuksime täie rauaga.
Võttes aluseks toonastest vesinikupommidest keskmise, 3,9 megatonnise MK15, saame Eesti sihtmärkidest järgmise kaardi.
Igal plahvatusel on toodud viis kontsentrilist ringi, mis tähistavad vastavalt:
- Plahvatuse tulekera
- 500 rem radiatsiooni ala (üldiselt fataalne)
- Praktiliselt kõik hooned purunevad
- Hooned, mis pole spetsiaalselt kindlustatud, purunevad. Raudbetoonist konstruktsioonidel võivad metallosad paika jääda, kuid lööklaine pühib vaheseinad minema, samuti hoones olevad inimesed.
- Inimesed, kes pole varjatud, saavad tugevaid põletushaavu, tekivad tulekahjud.
Selliseid kaarte saab koostada Nukemap saidil, kus on ka metoodika ära selgitatud, kuidas nende ringide suurust arvutatakse.
Et saavutada militaarsihtmärkide võimalikult efektiivset kahjustamist, oleksid plahvatused toimunud maapinnal (ground burst), mitte õhus, mis tähendanuks suure radioaktiivse pilve õhku paiskumist. Mõju keskkonnale sõltuks tuule suunast ja kiirusest, üks näide on toodud siin:
See on ainult ühe pommi tagajärg, tuleb arvestada, et ümbritsevatele piirkondadele langenuks neid veel kümneid. Radiatsiooni mõju inimestele on keeruline üheselt hinnata. Üldiselt loetakse fataalseks 600 rad või enam, 200 rad põhjustab tugevat radiatsioonitõbe, mõnikümmend suurendab oluliselt vähiriski. Oht sõltub sellest, kui kaua radiatsiooni käes viibitakse ehk kui palju kiirgust jõuab neelduda. Paar nädalat soovitati keldrist üldse mitte välja tulla.
Pärast eelkõige lennuväe võimekusele suunatud esimese laine rünnakut oli kaks võimalust. Kui emb-kumb on alla andnud, olnuks sõda läbi, vastasel korral oleks järgnenud teine rünnakufaas: vastase sõdimisvõime “süstemaatiline hävitamine”. Selleks oli koostatud teine sihtmärkide nimekiri (lingi taga ainult väljavõte, mitte täielik nimistu), kus olid olulisemad tööstuslinnad ning nendes asuvad konkreetsed objektid.
Linnadel oli samuti prioriteedijärjekord, 1. Moskva, 2. Leningrad, …, 34. Tallinn. Lisaks ka Varssavi, Budapest, Ida-Berliin, paljud linnad Hiinas jne. Kokku üle tuhande linna. Mitu pommi spetsiaalselt Tallinnale mõeldud oli, on natuke ebaselge, sest lähestikku asuvaid objekte võis hävitada ka ühe pommiga. Linnade jaoks olid mõeldud väiksemad, MK6 pommid võimsusega kuni 160 kilotonni.
Geograafiliste koordinaatidena on antud viis punkti, üldiste objektide nimekirjas 28 kirjet. Kolmekohaline arv sihtmärgi ees tähistab objekti tüüpi. Tallinna puhul olid objektitüüpideks:
- Õhujõudude kontrollkeskus
- Põllumajandusvarustus
- Naftatöötlus
- Väävelhape
- Sadam
- Laevaremont
- Allveelaevabaas
- Raadio ja televisioon
- Vedelkütusehoidla
- Valitsuskeskus
- Sõjaväeladu
- Sõjaväegarnison
- Mereväestaap
- Elanikkond :(
Erinevalt esimesest lainest pidi teine laine kasutama õhus toimuvaid plahvatusi (airburst), mis annavad Tallinna jaoks järgmise kaardi:
Kokkuvõttes, kui keegi arvab, et praegu on elu kuidagi ohtlik ja maailmas asjad kehvasti, siis vaadake neid materjale ja tänage õnne, et sellised asjad teoks ei saanud.

One response so far

Nov 30 2015

Minu viis kuud Bondoras

Published by Targo under Hea kood, Isiklik, Raha, Töökuulutused

Äsja täitus mul viis kuud Bondoras töötamist.

Kuidas on läinud?

Lühike vastus: suurepäraselt!

Pikka vastust tuleb alustada kaugemalt. Alustasin oma karjääri metsikutel üheksakümnendatel, kui normiks oli kaastöötajatele hambapastasse pliinitraati panna ning vajadusel juhtmejupist voolu lasta (või oli see ainult konkreetse ettevõtte eripära?) Kommertstarkvara loomine oli Eestis lapsekingades ning seda tehti üsna katse-eksituse meetodil. See, et järgmises töökohas APT-s (praeguseks transformeerunud CGI Eesti kontoriks) üldse eksisteeris selline nähtus nagu süsteemianalüüs, oli päris kõva sõna. Edasi viis elu mu juba päris suurde ettevõttesse, rohkete protsesside ning kõrgelt spetsialiseeritud rollidega.

Igas järgmises kohas olid asjad rohkem korras ja süstematiseeritud, sellest tekkis mul ka ettekujutus, et ahaa, nüüd ma tean, kuidas tuleb edukalt tarkvara teha, millised protsessid ja meetodid selleks vajalikud on. Kui aga Eestisse tagasi tulin ja keskmise suurusega ettevõttesse tööle asusin, ei hakanud kogemused siiski nii ladusalt tööle, kui oleksin oodanud. Milles siis asi?

Reaalselt ei eksisteeri paraku mingit garanteeritult edukat meetodit, kuidas tarkvaratootmist korraldada. On mingid üldised printsiibid, kuid detailid olenevad organisatsiooni suurusest, tegevusvaldkonnast ja mitmetest muudest teguritest. Jah, elementaarne, aga inimestel on kord juba kombeks seniste kogemuste haamrit kasutades ka uusi situatsioone samasuguste naeltena käsitleda.

Asi läheb aga huvitavaks, kui meil on tegu väga dünaamilise organisatsiooniga nagu Bondora. Esiteks kasvab Bondora praegu väga kiiresti, ma pole enam kaugeltki kõige uuem töötaja. Teiseks, ma ei tea, mis narkotsi Pärtel täpselt tarbib, aga igal nädalal leiutab ta mõne uue vägeva asja, mida proovida. Sel juhul tulebki protsesse jooksvalt kohandada, vahel ka organisatsioonistruktuuri ja tehnoloogilist arhitektuuri.

Minu strateegiliseks ülesandeks on: kuidas arendada tehnoloogilist platvormi maailma vallutamise eesmärgiga ettevõttes, mis pidevalt muutub?

Selline sõnastus aitab vajadusel ka mõtteid korrastada. Kui on kahtlus, et mida teha, siis tuleb kujutleda, et me saame väga, väga edukaks – mis on sel juhul õige lahendus? Sest kui me edu ei saavuta, mis siis üldse asja point on, eks.

Mis mulle Bondoras meeldib?

Võrreldes eelmise tööga, kus tegu oli suurel määral ikkagi konkreetsete klientide soovide täitmisega, on olulisteks positiivseteks külgedeks:

  • Tarkvara skaleeritavuse ärakasutamise võimalus. Võrreldes majaehitamise või muude inseneridistsipliinidega on tarkvaral suurepärane omadus, et sama tarkvara võib kasutada kuitahes palju inimesi. Tootearendust katsusin ma ka Nortalis korraldada, aga see oli raskem. Nortal on hea ettevõte, kuid kui kogu elu, raamatupidamisest arenguvestlusteni, on orienteeritud pigem arendustundide müügile, on mingit teistsugust lähenemist keeruline tööle panna. Bondoras on kasutajate arvu suurendamine nii loomulik eesmärk, et sellest pole isegi vaja eraldi rääkida, ja milline insener ei tahaks, et tema tööd võimalikult palju kasutataks?
  • Pikaajaline mõtlemine, mis võiks ju olla igasuguse tarkvaraarenduse loomulik osa, kuid kahjuks loob riigihangete struktuur tugeva motivatsiooni lühiajalisele edule optimiseerimiseks. Kui arendaja teab, et tal on vaja selle koodiga tegeleda ka viie aasta pärast, on ta üldjuhul palju hoolikam kui siis, kui on teada, et vastutus kestab vaid lähimate kuude jooksul.
  • No bullshit. Ma tegelen oluliselt rohkem asjadega, mis mulle meeldivad, ning vähem nendega, mis ei meeldi. Tegu mõnes mõttes taas hangete vormist tuleneva probleemiga, kus tellija ja täitja vaheliste konfliktide seemned on juba lepingutesse külvatud.

Boonusena toon ära, et päris hea on taas töötada kohas, kus ettevõtte juht vajadusel ise suudab SQLi lahti võtta ja uurida, mis süsteemis toimub. Mitte, et sellel mingit suurt praktilist väärtust oleks, aga nii ei teki tunnet, et äri- ja tehnikainimesed omaette isoleeritud maailmades eksisteerivad.

Mida Bondoras tehakse?

Kui ma väike olin, laenas naabrimees minu isalt vahel viis rubla ja tõi palgapäeval tagasi. Maailmas on palju inimesi, kellel mitmesugustel põhjustel raha parajasti puudu on, aga on ka inimesi, kellel on seda hetkel üle. Kui esimestel on naaber, kellelt laenata, siis on tore, aga kui ei ole?

Mingi suvaline inimene pole jälle nõus sulle laenama… või siiski? Mittelaenamise põhjuseks on üldiselt see, et me ei tea, kas teine on usaldusväärne ja maksab raha tagasi. Sama probleem on näiteks aktsiatega – kuigi majandus üldiselt tõuseb, siis kust ma tean, et just see ettevõte pankrotti ei lähe, mille aktsiat ma ostan? Aktsiaturul on lahenduseks diversifitseerimine, ostad kas paljusid erinevaid aktsiaid või üldse indeksfondi, siis pole üksik kaotus enam nii oluline.

Laenamise puhul saab teha sama. Kui üks konkreetne inimene võib laenu mitte tagastada, siis enamik inimesi siiski teevad seda. Olgu meil seega näiteks 200 inimest, kellest igaüks soovib laenata tuhat eurot. Teisel pool on 200 inimest, kes saavad tuhat eurot laenu anda. Jagame nüüd kõik tuhanded 5-eurosteks tükkideks, nii et igaüks laenab igaühele viis eurot ja ongi riskid maandatud, konkreetsed kaotused on piiratud 5 euroga.

Pangad on sama põhimõtet rakendanud juba sadu aastaid, kuid üldiselt ei saa inimesed kontrollida, mida nende hoiustatud rahaga tehakse. Arenenud tehnoloogia võimaldab inimestele aga palju suuremat kontrolli, raha liigutamist ja jälgimist saab toimetada kiiremini, lihtsamalt ja odavamalt kui kunagi varem.

Ehk siis suures plaanis ongi asi väga lihtne, laenusoovid jagatakse väikesteks tükkideks, mida rahastavad paljud üksikinvestorid. Reaalselt on seal muidugi palju keerukusi, neist suurim on küsimus, kuidas õigesti hinnata laenaja riski? Riski hindamine on omakorda kinni selles, kui palju on laenusoovija kohta olemas infot. Info tuleb osaliselt kliendilt endalt, aga ka taustakontrollist nagu võlaregistrid jms. Paljude parameetrite põhjal hindabki statistiline mudel, mis on konkreetse laenu risk.

Protsess on üldjoontes järgmine:

Äri kasvatamisel on kaks poolt: ekstensiivne (ehk rohkem külastajaid) ning intensiivne (suurem külastajate protsent, kes joonisel toodud sammud läbi teeb). Siit tulenevad ka tehnilised eesmärgid: ühelt poolt süsteemi skaleeruvus ning teiselt poolt võimalikult sujuv kasutajakogemus.

Kasvu osas on lagi aga nii kõrgel, et pea hakkab ringi käima. Selliste laenude turu suurust hinnatakse TRILJONILE (kaksteist nulli) dollarile.

Mida mina konkreetselt teen?

Viimased 10 aastat olen ma pooleldi tegelenud tehniliste asjade ning pooleldi inimestega, nõnda ka siin. Inimesed on mõistagi tähtsamad.

Igapäevaselt kirjutan ma koodi ja uurin igasuguseid jooksvaid probleeme. Käed on pidevalt mullased, valgeid kindaid pole endale hankinud. Õnneks on abiks ka teisi väga tugevaid tegijaid:

(kes Tarmot tunnevad, siis jah, ta ongi juurde võtnud)

Paralleelselt aitan aga paika ajada viit asja, mis iga organisatsiooni disainimisel tähtsad on:

1. Õiged inimesed

Millised inimesed on õiged, oleneb suuresti ärimudelist. Olenevalt sellest, mida me teeme, võime hinnata näiteks korralikkust, paindlikkust, vastupidavust vms. Bondora-suguses keskkonnas, kus uued väljakutsed on igapäevased, on võtmeks nutikus ja õppimisvõime. Need on ka peamised omadused, mida ma värbamisel katsun silmas pidada.

2. Õige kultuur

Meie eesmärgiks on kasvada suureks oma saavutustelt, aga mitte tingimata inimeste arvu poolest. See tähendab, et tarkvara peab olema võimalikult hooldusvaba ning arendajatel peab olema motivatsioon sellist tarkvara luua. Lihtsaim meetod selleks on läbi võimalikult konkreetse vastutuse ja omanditunde.

3. Õige struktuur

Organisatsiooni struktuuri osas on peamine tegur Conway seadus, mis ütleb, et tarkvarasüsteemi disain hakkab peegeldama organisatsiooni disaini (täpsemalt organisatsioonisisest kommunikatsiooni). Kui meil on väga hierarhiline organisatsioon, saame ka hierarhilise ülesehitusega tarkvara. Kui meil on maatriksjuhtimine, siis tekivad ka tarkvarasse ristsõltuvused. Kui meil on sõltumatud tiimid, saame ka üksteisest sõltumatud komponendid.

Struktuur võib olla ajas muutuv. Kui meil on kolm arendajat, on okei, et kõik teavad kõike ja vastutavad probleemide eest ühiselt. Kui arendajaid on aga kümme, võib tekkida “kollektiivse vastutuse sündroom” ning inimestel kaob ära omanditunne koodi vastu. Siis on mõistlik jagada organisatsioon väiksemateks üksusteks.

4. Õiged protsessid

See on miski, mis muutub aja jooksul pidevalt. Murdekoht võiks olla umbes kahekordse kasvu juures. Kümne tehniku puhul töötab teistsugune lähenemine kui viiega, kahekümne juures on jälle aeg kohandamiseks jne. Vahel olengi pidanud stabiilsemate oludega harjunud kolleege lohutama, et paar korda aastas ümber organiseerumises pole midagi hullu.

5. Õige tehnoloogia

Kuigi sageli vaieldakse arendusorganisatsioonides parima versioonihaldussüsteemi, programmeerimiskeele või one true brace style‘i üle ennast näost siniseks, tulevad tehnoloogilised valikud alles pärast seda, kui eelmised asjad paigas. Lõppkokkuvõttes peame olema suutelised kiirelt ja kergelt muutuma, kui Next Big Thing leiutatakse. Võtmesõnadeks modulaarsus ja sõltumatus.

Mis on karu kõhus?

Algselt ühe arendajaga ja hiljem kasvanud tarkvarasüsteemid teevad tavaliselt läbi järgmised arenguetapid:

1. Spagetiorienteeritud arhitektuur

Pole veel päris head aimdust, mida me teeme, proovime igasuguseid erinevaid asju ja hoiame “ehk-läheb-tarvis” koodi alles. Kiirema katsetamise huvides jääb süsteemi mitmesuguseid häkke ja otselõikeid. Samas teavad esialgsed 1-3 arendajat koodi niikuinii peast ning suudavad iga üksiku spageti alguse ja otsa kergesti üles leida.

2. Lasanjeorienteeritud arhitektuur

Inimesi tuli juurde, kes enam kõigest aru ei saanud, nii et jagame süsteemi loogilisteks kihtideks. Veebiklient-vaated-kontrollerid-sõnumid-domeenimudel-DAOd-SQL või kuidas kellelegi parajasti meeldib. Paljud süsteemid jäävadki kusagile siia pidama.

3. Raviooliorienteeritud arhitektuur

Kui aga süsteemi suurus veel kasvab ja sinna on vaja rohkem muudatusi teha, pole kihid enam piisavalt paindlikud. Ühe stsenaariumi jaoks tehtavad muudatused toovad kaasa tagajärgi ka teiste jaoks, just nagu katse valmisküpsetatud lasanjel keskmine plaat ära vahetada võib kõik muu sassi ajada. Siis tuleb süsteem jagada sõltumatuteks osadeks, mida iseseisvalt muuta saab. Infosüsteemide puhul on realisatsiooniks tavaliselt microservice‘id, seda lähenemist kasutavad paljud maailma edukaimad ettevõtted nagu Amazon või Google. Konkreetselt Bondora juhul saaks ülalpool illustreeritud laenuprotsessi etapid muuta sõltumatuteks teenusteks, millest igaüht võimalik iseseisvalt paigaldada, skaleerida ja ümber teha.

Bondora on hetkel kusagil lasanje ja raviooli vahepeal – on nii kenasti jagatud kui ka üle terve maailma ulatuvaid osi. Kui ma esimest korda koodile tiiru peale sain tehtud, tekkis ka nägemus, mismoodi asjad ideaalis võiksid olla. Kuna senine elukogemus oli näidanud, et äriinimestele tavaliselt “muudame kõik ümber” ettepanekud väga ei sobi, valmistasin mõttes rea igasuguseid argumente ette, miks on tegu hea mõttega. Reaalselt jõudsin öelda umbes kaks lauset, kui Pärtel vastas, et “tehke ära”. Kas tegu oli erakordse usalduskrediidi või hulljulgusega, näitab aeg.

PS Pakume kogenud .NET arendajatele võimalust maailma vallutamises kaasa lüüa. Vastavalt jaksule ka väärilised kullakangid ning pudrumäed. Huvi korral võib minuga ühendust võtta.

3 responses so far

Oct 27 2015

Milleks õppida midagi peale IT?

Augustis kirjutas Sandra Niinepuu Nihilistis, et IT õppimine on üle haibitud ja ei sobi igaühele.

Mõni aeg hiljem vastas sellele Margus Niitsoo, et reklaam on õigustatud, kuna inimesed (eriti keskkoolis) niikuinii ei tea, mida nad tahavad. Eks teismelise iga ongi see aeg, kui sa ei tea, mida sa tahad, aga tead väga täpselt, kuidas seda saada – katsun neid seetõttu hädast välja aidata.

Nimelt jäi esialgses diskussioonis minu meelest kummalgi poolel nägemata tõusulaine, mis kõik muud argumendid varjutab ning küsimuse hoopis teravamasse valgusse seab. Selles laines on aga nii mõnedki vastused.

Tarkvara sööb maailma

(Jaotuse pealkiri pärineb Marc “munapea” Andreesseni vastavast artiklist.)

Inimjõu asendamine tehnoloogiaga on sama vana kui tsivilisatsioon ning viimase arenguga lahutamatult seotud. Vankriga sai vedada suuremat koormat kui seljas ning veskiga jahvatada rohkem jahu kui käsitsi.

Pidevalt on muutunud ka inimeste töö sisu. 200 aastat tagasi töötas 90% eurooplastest põllumajanduses, praegu umbes 5%. 70 aastat tagasi oli enamik arenenud maade tööjõust hõivatud tööstuses, praegu 20-25%. Tehnoloogia asendas inimtööjõu kas otseselt või võimaldas tootmist liigutada odavamatesse piirkondadesse.

Muutused toimusid siiski vähehaaval. Kui külla tuli uus traktor, mis tegi ära kolme hobusemehe töö, hakkas üks neist traktoristiks, teine leidis töö kõrvalpõllul ning kolmas läks linna vabrikutööliseks. Tööpuuduse tase on ajalooliselt püsinud kümnekonna protsendi piires.

Nüüd on muudatuste tempo aga hüppeliselt kiirenenud, kuna peamine innovatsioon toimub tänapäeval tarkvaras. Erinevalt traktorist on meil tarkvarast võimalik kohe teha miljon koopiat, millest igaüks kohe kusagil inimtööaega sööma hakkab.

Võtkem näiteks Uber, mis võimaldab eraisikul pakkuda taksoteenust (eestlased võivad mõelda, et Uber=Taxify+telefoniga maksmine+tagasiside+eraautode võimalus). Tellimine ja tasumine on lihtne ja kiire, samuti saab nii arvestada nii juhi kui reisija kohta eelnevalt jäetud tagasisidega. Seetõttu eelistavad paljud inimesed Uberit tavataksodele, argumentideks odavam hind, suurem mugavus ja parem teenus. Uberi kasutuselevõtt suurlinnas paneb aga silmapilkselt löögi alla tuhanded traditsioonilised taksojuhid, kuigi materiaalselt on kõik sama, liikunud on ainult bitid ja baidid.

Praeguseks tegeleb tarkvara loomisega nii palju inimesi, et uus tehnoloogia kaotab töökohti kiiremini, kui need asenduvad – sotsiaalne koormus ületab ühiskonna seedimisvõime.

Muutuste sümboliks on minu jaoks isesõitev auto. Füüsiline sisu on kõik sama: mootor, käigukast ja rattad nagu igal teiselgi autol. Kaamerad ja radarid muidugi lisaks, aga ka need on maailmas juba ammu eksisteerinud. Kuid lisame tarkvara, mis võimaldab neid kõiki koordineerida piisavalt hästi, et inimest pole sinna enam tingimata vaja, ja mis juhtub? Miljoneid taksojuhte, bussijuhte, kaugsõiduautojuhte pole enam tarvis. Samuti pole tarvis neid miljoneid, kes on tegevad liikluskindlustuses või automüügisalongides. Doominoefekt ulatub kaugele.

Sarnaseid näiteid leiame pea igalt alalt, kuid eriti tavaliste keskklassi töökohtade seast. Kui vaadata tegevusi, mida ma praegu online teen, on nimekiri pikk: reisiplaneerimisest ja lendudele registreerimisest raamatute ostmise ja filmide vaatamiseni. Igaüks neist on kusagil ära söönud mingi tükikese varem inimeste poolt tehtud tööd, kuid see on alles algus. Näiteks enamik tegevustest, mida teevad arstid, õpetajad ja juristid, on tehnoloogiaga asendatav. Perearstile jääb pigem inimliku kontakti roll, kuid diagnoosi panna ja parimat ravimit soovitada suudab arvuti tema eest paremini. Kui üles kasvab põlvkond, kes suhtlebki ainult nutiseadmete vahendusel, võib ka sotsiaalne funktsioon kaduda.

Olles sel teemal erinevate inimestega rääkinud, on mitmetel tekkinud vihane reaktsioon, “kuidas ma julgen nende ametit maha teha!“ Ma ei anna kõnealustele muutustele moraalset hinnangut hea või halva osas. Jah, see võib olla hirmutav. Jah, paljude inimeste elu pööratakse pahupidi. Aga seda protsessi suunavad majandusseadused on sama vääramatud kui loodusseadused, mis näiteks mõne asteroidi Maaga kokku põrkama suunavad. Näppude kõrvadesse surumine ei muuda asja olematuks, kuid me võime nendeks muutusteks valmistuda.

Tulevikuühiskonna struktuur

Tuleme nüüd tagasi esialgse teema juurde – mida võiks inimene õppida, kuidas tulevaseks eluks valmistuda?

Üldised printsiibid on:

  1. Tehnoloogia muudab enamiku töövaldkondadest majanduslikult efektiivsemaks.
  2. Kui mingis vallas keegi tehnoloogiasse investeerib, on konkurentsis püsimiseks vaja seda teha ka teistel. Süsteem saab positiivset tagasisidet ning liikumine kiireneb.

Järeldus 1: Praegune ülisuur nõudlus tehnoloogiaspetsialistide järele kasvab veelgi.

Järeldus 2: Kui on võimalik, et masin saab sinu ametit (või mingit osa sellest) efektiivsemalt teha, siis varem või hiljem see ka juhtub.

Trendi ekstrapoleerides jõuame järgmise kihilise ühiskonnani:

  • Inimesed, kes tehnoloogiat loovad ja käigus hoiavad (liigitan siia alla ka ettevõtjad, juhid ning organisaatorid, kes seda oma tegevuses rakendada suudavad).
  • Traditsioonilised ametid, millest paljusid tehnoloogia ohustab.
  • Sotsiaalsed töökohad, mida luuakse neile, kes uues maailmas muidu kohta ei leia, vältimaks tänavarahutusi.

Valikuid tehes tuleb seega arvestada, et mitte-tehnoloogiliste töökohtade olemus muutub oluliselt. See ei tähenda tingimata, et ametid täielikult kaoks. Näiteks med-õe töö füüsilist aspekti saaks suuresti täita masin. Inimese peaosaks jääks patsiendi käehoidmise osa, mis eeldab aga teistsugust oskuste komplekti. Töötundide koguarv siiski väheneb, mis tähendab, et personali on võimalik koondada.

Globaalne vaade

Mida see kellelegi konkreetsemalt võiks tähendada? Alustame maailmast globaalselt.

Ajalooliselt on riigid käinud läbi kolm majandusmudeli etappi: põllumajanduslik, tööstuslik ja teenustepõhine, vastavalt sellele, millega inimesed eelkõige tegelevad. Euroopa ja Põhja-Ameerika on jõudnud kolmandasse etappi. Riigid, kus valmib enamik meie tarbekaupu (eelkõige Hiina), tegelevad tööstusega. Osad piirkonnad (eelkõige Aafrika) on aga endiselt kinni situatsioonis, kus valdav osa inimestest tegelevad põllumajandusega.

Kui Hiina elatustase tõuseb, liiguvad sealsed inimesed samuti pigem teenuste sfääri ning tööstus suundub mujale. Ajalooliselt pole veel ükski majandus liikunud otse põllumajandusest teenustesse. Alati tehakse vahepeal läbi industrialiseerimise etapp, mis võimaldab kasvatada inimkapitali, tõsta elanikkonna haridustaset ning välja kujundada kaasaegse ühiskonna toimimiseks vajalikke institutsioone.

Globaalne tööstuse raskuskese on odavamat tööjõudu otsides korduvalt ühest kohast teise liikunud, luues uusi tehaseid ja infrastruktuuri. See on omakorda aidanud eri piirkondadel teha hüpet tänapäeva.

Mis juhtub aga siis, kui robotid muutuvad odavamaks kui maailma kõige odavam tööline? Kui igasuguseid plastikust vidinaid on lihtsam kohapeal 3D printida, mitte üle mere importida?

Võib juhtuda, et tööstuse maailmarännak peatub. Rohkem pole vaja midagi outsource’ida ning näiteks Aafrika riigid jäävadki lõksu, kus neil pole võimalik oma majandust moderniseerida. Neist saab sotsiaalseid töökohti vajava ühiskonnakihi globaalne ekvivalent – piirkonnad, mida toetatakse parasjagu nii palju, et mäss liiga suureks ei kasvaks, aga neil on väga raske sealt edasi liikuda.

Riiklik vaade

Tsiteerin Sandra esialgset artiklit: „Nn STEM (science, technology, engineering, math) erialade ebaproportsionaalne ülerõhutamine ei ole jätkusuutlik, sest innovatsiooniks ja dünaamiliseks majandusarenguks vajame erinevate oskuste ja teadmistega inimesi.“

Kui ma muidu olin Sandraga enamikus asjades nõus, siis ebaproportsionaalse ülerõhutamise osaga kindlasti mitte.

Arvudele otsa vaadates näeme, et:

  • IKT sektor toodab kõigis maades võrreldes tööhõivega suurema protsentuaalse osa sisemajanduse kogutoodangust.
  • IKT töökohtade arv on kõikjal kiiresti kasvav. Nende „erinevate oskuste ja teadmistega inimeste“ osas on kohtade täitmine reaalselt palju lihtsam kui hea tehnoloogi leidmine.
  • Eestis on IKT osa tööhõivest väiksem kui OECD keskmine.

Seega oleme ülerõhutamisest väga kaugel. Vastupidi, tegelikult rõhume me liiga nõrgalt, konkurentsis püsimiseks on tarvis oma insenerkonda kasvatada nii kiiresti kui jaksame.

Organisatsiooni vaade

Aga kuidas on ettevõtetega, mille tegevus on midagi muud? Kas pole nii, et nende jaoks on IT lihtsalt tugifunktsiooni rollis? Jah ja ei.

Võime küsida, kas Amazon.com on kaubandus- või tarkvaraettevõte? Kas Netflix on videolaenutus või tarkvarafirma? Kas Pixar on filmi- või tarkvaraettevõte? Kas Transferwise on finants- või tarkvaraettevõte? Kas Skype on telko- või tarkvaraettevõte?

Kõigi nende näidete puhul sööb tarkvara vastavat valdkonda seestpoolt ja on saanud määravaks osaks ettevõtte põhiväärtuse loomise protsessist. (Kõik nad on ka maailmast kaotanud suurel hulgal “vanu” töökohti.)

Ka teistes traditsioonilistes tööstusharudes on tohutult ruumi revolutsiooni läbiviimiseks. Arvatavasti määrab järgmise generatsiooni edukaimate ettevõtete nimekirja ära see, kui efektiivselt suudab keegi tavapärast tootmist tarkvara abil nutikamaks muuta. Isegi poliitikas on andmeanalüüsi võimekus saanud võtmetähtsusega probleemiks.

Isiklik vaade

Tulles veelkord tagasi Sandra artikli juurde, paistis seal silma milleniaanlik optimism, et kui sa vaid tegeled millegagi, mis sulle meeldib, küll siis kõik hästi läheb. Jah, kui sul on tugev kirg millegi vastu, on ilmselt parem seda järgida. Aga kui erilist vahet ei ole, on parem lasta mikroökonoomikal enda kasuks töötada.

Nagu igal teiselgi turul, määrab ka tööturul hinna nõudmise ja pakkumise suhe. Kuna IT alal ületab nõudlus pakkumist, lähevad ka palgad üles, seda isegi tavapäraselt jäigas avalikus sektoris.

Näiteks on Tartu Ülikooli professorite keskmine palk 3000 euro kandis (miinimum samas 1780 eurot). Samas arvutiteaduse professorile pakutakse 5000 eurot.

Või vaatame suurepärast tabelit, kus on kirjas kõik Eesti riigiametnike palgad ja mida vastava veeru järgi sorteerides võib iga riigitöötaja näha, mitmendal kohal ta asub. Kui teiste asekantslerite keskmine põhipalk on 3473 eurot, siis Taavi Kotka, IT asekantsler, saab 4999 eurot.

Erasektorist ei hakka rääkimagi, nii Eesti kui ka maailma rikkaimate inimeste edetabelites domineerivad praeguseks IT-ga seotud nimed. Ka seni ainus inimene, kes on miljard dollarit teeninud mitte ettevõtluses, vaid kellegi teise firmas töötades, oli tarkvaraarendaja. Just tänu suurele nõudlusele kvalifitseeritud inimeste järele sai IT-st ka alguse komme tasustada kõiki töötajaid aktsiaoptsioonidega, mis on tekitanud miljonäre rohkem kui kunagi varem.

Isegi kui raha pole sulle tähtis, tuleb meeles pidada eelpool mainitud tõusulainet. Kui praegu on silmapiiril tehnoloogia, mis võimaldab mingi töö paremini ära teha, siis 5 aasta pärast on see prototüüp, 10 aasta pärast edukaimates kohtades kasutusel, 15 aasta pärast mainstream ning 20 aasta pärast pole inimestel enam mõtet tööavaldusi saata.

Juba praegu toodavad mitmed ülikoolis õpetatavad erialad surnult sündinud spetsialiste, kellel pole erialast väljundit. Milleks siis sinna lõksu astuda?

IT haridus

Eelnevast võib jääda mulje, et IT-s on ainult pudrumäed, liigutad aga näppe ja klotsi kukub nagu tetrises. Päriselt puudutavad kirjeldatud muutused muidugi ka IT-sektorit ennast. Nagu teisteski majandusharudes, on ka IT-s palju tegevusi, mida on võimalik automatiseerida. Hea näide on igasugune „administreerimine“. 20 aastat tagasi oli kasvõi ülikooli arvutiklassi administraator oma asendamatuse tõttu nii kõva mees, et õppejõudki teda kartma pidid, aga nüüd toimib halastamatu vähempakkumine – igasugune IT infraga tegelemine liigub hoogsalt kas odavamatele teenuspakkujatele või siis automatiseeritakse täielikult.

Septembris vaatasin konverentsil ettekannet, kus rääkis Amazon.com’i CTO Werner Vogels. Hoolimata sellest, et Amazonil on miljoneid servereid, pole seal süsadminne, sest kõik on automatiseeritud. Ning aastas liigutavad sajad tuhanded ettevõtted oma andmed Amazoni serveritele. Selgelt väheneb siis ka vajadus igasuguse kohaliku riistvara järele, olgu tegu kas serverite müügi või kaablite vedamisega.

Seega ei söö tarkvara mitte ainult teisi valdkondi, vaid ka omaenda lapsi, vähemalt neid, kes ei suuda loomingulisuselt ja nutikuselt masinast üle olla.

Siin on mängus veel üks oluline asjaolu. Peaaegu igale konkreetsele tehnoloogiale on sisse programmeeritud tema eluiga. Olenevalt oma keerukusest ja paindlikkusest on ta kas kiiremini või aeglasemalt asendatav millegi uuema, abstraktsema ja võimsamaga. Kuna tehnoloogia nõuab uuendamist, siis on vaja ka tehnolooge, kes suudavad seda pidevat asendamist läbi viia.

Vahel küsitakse mult: „mida ma peaksin õppima?“ Andmebaase või veebidisaini? Javat või PHP-d? Millisesse kooli minna? Tartu? TTÜ? IT Kolledž? MIT?

Sisu osas tegelikult suurt vahet pole. Kõike, mis koolis õpetatakse, saab omandada ka ise. Samuti tuleb karjääri jooksul niikuinii palju kordi rada vahetada ning täiesti uusi asju õppida. Seega pole oluline mitte konkreetse asja tundmine, vaid õppimisvõime.

Sellepärast küsin ma ka tööintervjuudel otse ülikoolist tulevatelt kandidaatidelt, mis koolis nad käisid, kuidas neil seal läks, milliseid aineid võtsid ning milliseid õppejõude kuulasid. Konkreetsed ained ei oma tegelikult tähtsust, aga kui inimene on käinud pigem raskemas koolis, võtnud raskemaid aineid ning saanud selle eest paremaid hindeid, demonstreerib see tema suuremat õppimisvõimet ja ennustab seeläbi edasist edukust. Analoogiliselt on tähtis, kas kandidaat tegi näiteks oma lõputöö ära või on veel pooleli – mitte sisu pärast, vaid seetõttu, et see näitab asjade lõpule viimise oskust.

Kokkuvõtteks: maailm keeratakse pea peale, meeldib see meile siis või mitte. Mingil määral on kontrollitav, kas maandud siirupitünni või virtsavaati, aga igaüks saab oma saatuse suunamises ainult iseendale toetuda. Suuremad struktuurid nagu riik ja ühiskond jäävad kaugelt liiga aeglaseks, et nendele loota.

3 responses so far

Aug 06 2015

Tarkvara riknemine

Published by Targo under Hea kood, Raha

Igaüks, kes on puutunud kokku mingi tarkvaraarendusega, on kuulnud või kogenud ka järgmist:

“See on mingi vana kood, mida keegi ei tunne, ära seda parem puutu.”

“See vana süsteem, millest keegi midagi ei mäleta. Mõnikord see ei tööta, siis me lihtsalt restardime seda.”

“Me vajutame siin neid nuppe kindas järjekorras, et asjad töötaks. Me ei tea, mis juhtub, kui teises järjekorras vajutada.”

Tegu on riknenud ehk legacy süsteemiga, pea igas organisatsioonis on mõni selline, vahel ka päris mitu. Kunagi on nende loomiseks kulunud palju raha, aega ja vaeva, aga nüüd tundub, et neist on rohkem tüli kui tulu. Kui uurida, mida teha, on arendajate lemmikvastuseks: “See vana asi on täielik jama ja kõik tuleks nullist ümber kirjutada!” Rahakoti käsutajatele see muidugi ei meeldi ja nii lükatakse “nullist ümber kirjutamist” edasi nii kaua kui võimalik. Eestis on suuremad süsteemid pea eksklusiivselt avalikus sektoris ning sagedaseks lahenduseks legacy probleemile on uue rahalaeva saabumine Euroopast.

Viimasel ajal on ümberkirjutamise idee aga jõudu kogunud ning Eesti avalik sektor soovib sisse viia lausa reegli, mis kohustaks süsteeme teatud aja tagant uuendama (otsi artiklist “no-legacy”).

Kas see ümberkirjutamine on aga parim tee? Kuidas süsteem üldse legacyks muutub? Ja mis elukas see legacy üldse on?

Minu kogemuses on tarkvara sisulise moraalse vananemise peamiseks sümptomiks hirm. Kas programmeerijad kardavad mingeid asju muuta? Kui neid muudatusi siiski tehakse, siis kas tellijad kardavad “kaardimaja efekti”? Hirmu mõõtmiseks on keeruline head joonlauda välja tuua, peamiselt on see hinnatav arendajate küsitlemise kaudu.

Aga miks arendajad kardavad? Sellepärast, et neil pole võimalik kergesti kontrollida, kas nende muudatused teevad midagi katki.

Regressioonide vältimiseks kasutatakse erinevates organisatsioonides mitmesuguseid meetodeid. Kõige tavalisem neist on, et tarkvara vastuvõtja (sageli mingi peakasutaja isikus) käib enda tavalised stsenaariumid läbi ja vaatab, et tema lemmiknupud paigast poleks nihkunud. Kui kontrollimiseks on mingid kirjapandud stsenaariumid ja fikseeritud protseduur, on tegu juba päris kõva sõnaga.

Sageli juhtub aga, et organisatsioonis polegi kedagi, kes suudaks kontrollida, kuidas asi peaks tegelikult töötama, sest “eit teadis, aga eit suri ära” ehk siis lahkus töölt, kaotas vastavad dokumendid ära või lihtsalt unustas. Siis ongi meil klassikaline riknenud tarkvara, kus me ei tea, mis töötab, mis mitte.

Rohkemat on väga raske teha, sest tarkvara regulaarne käsitsi kontrollimine on ausalt öeldes üsna nüri tegevus. Uncle Bob ütleb, et see on lausa amoraalne. Teoreetiline lahendus on mõistagi ilmne – las masin teeb igavat tööd, tema on rauast. Head automatiseeritud unit testid vähendavad süsteemiga seotud hirmu drastiliselt.

See on niivõrd oluline asjaolu, et ma kasutaks sellist definitsiooni: legacy on tarkvara, millel puuduvad efektiivsed unit testid.

Unit testide puudumine viib muudatusteni, mis pole verifitseeritud ja kasvatavad statistilist tõenäosust, et süsteemis on igasuguseid varjatud vigu, kuni lõpuks on olukord täielikult kontrolli alt väljunud.

Kui palju unit teste tegelikult kasutatakse? Minu kogemuses on siin tugev korrelatsioon sellega, kui palju tarkvarast hoolitakse. Oma isiklikud projektid on mul üsna hästi kaetud, mõni neist on 10+ aastat vana ja kannatab ikka üsna hästi arendamist ja täiendamist. Erasektoris on olukord laiguline – kui organisatsiooni eduks vajalikku tarkvara tehakse majas sees, saadakse üldiselt ka aru selle jätkusuutlikkuse hoidmise vajadusest.

Avalik sektor, kus mittehoolimise seemned on külvatud juba sügavale seadusandlusse, lepingutesse ja organisatsioonikultuuri, on vaeslapse osas. Unit testing nõuab ehk 20% ekstra aega (ja see aeg võidetakse tagasi juba esimese suurema muutuse realiseerimisel), kuid tarneahel, kus prioriteetideks on kiirus ja odavus, lõikab selle ekstra viiendiku armutult maha.

Ja nii olemegi olukorras, kus tarkvara on reaalselt riknenud juba esimesest päevast peale ning meil ei jää muud üle, kui peatselt uus süsteem tellida.

Poliitika, mis kohustab asutusi oma süsteeme regulaarselt uuendama, parandab mõnevõrra olukorda, kuid minu meelest ravime me sellega haiguse sümptomeid, mitte põhjust. Samuti on siin oht, et kui me kehtestame reegli, mille kohaselt tuleb iga 10 aasta tagant niikuinii uus tarkvara teha, siis kaob ka motivatsioon disainida tarkvara, mis peaks vastu nt 15 aastat. Viimane on hetkel küll puhtteoreetiline konstruktsioon, praegu oleks tore näha ka tarkvara, millega kasvõi pärast ametliku garantiiperioodi lõppu midagi teha on.

Minu endine tubli kolleeg ja praegune MKMi osakonnajuhataja Aet Rahe uurib, kuidas Eestis legacyga lood on ning milliste probleemidega asutused peamiselt kokku puutuvad. Tegu on tänuväärse tegevusega, sest minu teada pole sellist kaardistust Eestis varem tehtud.

Uurimuses on välja toodud mõned ideed, miks võiks organisatsioon soovida oma tarkvara vahetada. Kui häda käes, on need muidugi pädevad põhjused muudatuste tegemiseks, aga märksa parem oleks neid põhjusi ennetada. Siin väljavõte:

  • Liiga suured haldus- ja hoolduskulud

“Hoolduskulud” tähendab enamasti, et asjad lähevad katki, neid proovitakse parandada, aga edutult, parandatakse uuesti, mispeale lähevad hoopis teised asjad katki jne. Tegu on asjaga, mida unit testid definitsiooni kohaselt peaks parandama.

  • Ärilised või seadusandlikud muudatused

Ma eeldaksin, et kui organisatsioon ei hakka tegelema just mingi täiesti teistsuguse põhitegevusega, puudutab see muudatus siiski vaid väiksemat osa süsteemi loogikast. Ja kui tarkvara on disainitud korrektselt, s.t selle osad ei ole omavahel liiga tihedalt seotud, on võimalik neid osi ka üksteisest sõltumatult muuta.

  • Arhitektuuri keerukuse tõttu ei ole mõistlik enam süsteemi täiendada

Probleemi sõnastus ütleb ette ka vastuse – hea arhitektuur ei ole ülemääraselt keeruline.

  • Vendor lock-in

Vendor lock-in tähendab enamasti, et keegi peale vendori ei tea, kuidas tarkvara päriselt töötab (vendor teab vähemalt natuke) ja seetõttu ei julge keegi seal muudatusi teha. Kui meil on võimalik süsteemi tööd kergesti verifitseerida, kaob ka see oht.

  • Tehniliselt aegunud platvorm

Kui kasutatav tehnoloogia pidurdab süsteemi täiendamist, pole süsteemi osad suure tõenäosusega üksteisest piisavalt eraldatud. Kui kasutajaliideses pole eeldusi äriloogika reeglite kohta, ei takista keegi meil nt uut töövoomootorit kasutusele võtta. Kui äriloogikas pole eeldusi andmebaasistruktuuri kohta, ei takista keegi meil andmebaasi vahetamast. Kui andmebaasi pole sisse kirjutatud veebilehekülgede aadresse, pole ka mõne uue fancy UI toolkiti kasutuselevõtt probleemiks.

  • Puudub korrektne dokumentatsioon

Dokumentatsiooniga on see häda, et me tahaks mõõta tema eluiga kuudes ja aastates, aga reaalselt vananevad dokumendid päevade ja vahel isegi tundidega. Samas, kui meil on olemas korrektne töötavate automaattestide kogum, kajastab see definitsiooni kohaselt meie tarkvara tööd. Maha dokumentatsioon, elagu testid!

Kokkuvõttes:

  1. Tehes asju korralikult, saame enamikku probleemidest vältida ning tarkvara eluiga dramaatiliselt pikendada.
  2. Tarkvara korralikult tegemine ei ole eriti palju kallim (kui üldse).

Korralikkus jääb aga kahe asjaolu taha: lühiajaline mõtlemine ning teadmiste puudumine.

Lühiajaline mõtlemine on suuresti tingitud lepingute struktuurist. Kui ikka täitjale on loodud tugev motivatsioon teha asju võimalikult kiiresti ning pärast meid tulgu või veeuputus, on ka ennast hävitav kuidagi teisiti talitada.

Üks lahendus oleks siin pikemaajaliste raamkokkulepete kasutamine. Eestis on raamlepingud tavaliselt 3 aastat pikad, Soomes sageli nt 10-15 aastat. Teiseks saab paremini lahti kirjutada, millised on hooldusperioodi kohustused.

Teadmiste puudumine on probleemiks nii tellija kui täitja poolel. Kui võtame näiteks test-driven developmenti (TDD), siis ülikoolis seda ei õpetata ja ka enamik tööandjaid ei suuna oma töötajaid selles osas. Nii õpib enamik TDD praktiseerijaid kas kolleegidelt või internetist, enamasti pärast mitmeid põrumisi ja suurt frustratsiooni. Ma ise sain ka asjale alles siis pihta, kui olin kogenud asjatundjaga samasse tiimi sattunud.

Kusagilt tuleb aga siiski alustada. Minu meelest annaks kohustusliku best before tähtaja sisse seadmise asemel hoopis suurema efekti avaliku sektori tarkvaratellijate koolitamine selle osas, kuidas tarkvara rikneb ja kuidas seda välditakse. Hea oleks ka hangete tarvis näidisnõuete ette kirjutamine, kuidas tagada tarkvara paremat verifitseeritavust.

5 responses so far

Aug 07 2014

IOI 2014

Published by Targo under Haridus, Maad ja rahvad

Reportaaž Eesti võistkonna kogemustest 2014 Rahvusvahelisel Informaatikaolümpiaadil Taiwanis. Tekst – Targo, pildid – Simmo, Ahto, Targo

Olümpiaadidest

Hulk aastaid tagasi olin usin olümpiaadidel käija. Pingutus tasus end paljukordselt ära, nii konkreetsete probleemilahendusoskuste, sotsiaalsete sidemete kui lihtsalt laiema silmaringi osas.

Iseenesest need üritused siiski ei juhtu – kui Teaduskool täidab koordineerivat rolli, siis konkreetsete aineolümpiaadide õnnestumisele aitab kaasa veel terve hulk vabatahtlikke. Siinkohal edastan ka tänusõnad oma kunagistele juhendajatele, kes kogu seda vaeva viitsisid näha. Samuti tasun oma kogunenud karmavõlga ja löön ise kaasa olümpiaadide korralduses, eriti informaatikas.

Informaatikaolümpiaadi hooaeg kestab läbi terve õppeaasta. Eesti Informaatikaolümpiaadi toimkond korraldab mitmesuguses formaadis võistlusi, millest tähtsaim on riiklik lõppvoor. Lõppvooru parimad kutsutakse valikvõistlusele, kus selguvad koondise liikmed rahvusvahelistel võistlustel osalemiseks. Tavaliselt lööme kaasa Balti Informaatikaolümpiaadil (millest võtavad osa Läänemere äärsed riigid ja Norra) ning Rahvusvahelisel Informaatikaolümpiaadil (International Olympiad in Informatics, IOI), millel oli sel aastal üle 80 osalejariigi.

Ülesannetest

Informaatikaolümpiaadil tuleb ajapiirangu raames kirjutada programme, mis lahendavad algoritmilise iseloomuga ülesandeid. Lahendused peavad läbima hulga teste, mille eest saab punkte. Testid jagunevad laias laastus kaheks: esimene kategooria teste kontrollivad programmi korrektsust, katsetades mitmesuguseid erijuhtumeid, teine kategooria aga programmi jõudlust, andes sellele ette järkjärgult suuremaid andmehulki. Lahendustel on ajapiirang, mille jooksul nad peavad vastuse andma ning enamik lahendusi ületavad piisavalt suurte andmete juures selle limiidi.

Enamasti eksisteeribki olümpiaadiülesannetel “jõumeetodiga” lahendus, mis töötab suhteliselt väikeste andmehulkade puhul, kuid võtab suuremate puhul liiga kaua aega, ning järkjärgult “kavalamad” lahendused, mis kasutavad efektiivsemaid algoritme või andmestruktuure. Et kavalamat lahendust realiseerida, on esiteks vaja vastava algoritmiga tuttav olla ning teiseks osata ära tunda, et vaja läheb just nimelt seda algoritmi.

Toon näitena ühe keskmise raskusega ülesande käesoleva aasta IOI-lt (täielik tekst siin).

Kividest sein koosneb tulpadest. Igal sammul võime kive seina sisse kas lisada või sealt eemaldada, andes ette a) lõigu, mitmendast tulbast mitmendani me kive lisame või eemaldame, ning b) kõrguse, milleni kive lisatakse või eemaldatakse. Kui lisamisel on mõnes tulbas juba rohkem kive, siis see tulp ei muutu. Samuti, kui eemaldamisel on mõnes tulbas juba vähem kive, siis seda me samuti ei puutu.

Andes ette käikude jada

1. lisa 1-8 kõrguseni 4

2. eemalda 4-9 kõrguseni 1

3. eemalda 3-6 kõrguseni 5

4. lisa 0-5 kõrguseni 3

5. lisa 2 kõrguseni 5

6. eemalda 6-7 kõrguseni 0,

saame järgmisel joonisel kujutatud seisud:

Ülesandeks on leida kivide arv pärast viimast sammu. Jõumeetodil igas tulbas kivide arvu meeles pidamine ja kokkulugemine on muidugi triviaalne, kuid selle eest sai suhteliselt vähe punkte. Maksimaalse suurusega testis oli seina pikkus 500 000 ning sammude arv 2 000 000, mida jõumeetod mõistliku ajaga kokku ei suuda lugeda.

Parim lahendus on kasutada lõikude puu nimelist andmestruktuuri, mis võimaldaks kõrguste meelespidamist ajaga, mis sõltub seina pikkusest logaritmiliselt, mitte lineaarselt. Võimalikud on ka mõned vahepealsed lahendused, mis annaks vahepealse arvu punkte.

Sõidust

Pärast mitmesugustest rõngastest läbihüppamist ja sõeltest läbipugemist kvalifitseerusid käesoleva aasta IOI võistkonda Oliver-Matis, Andres, Siim ja Simmo. Juhendajatena kaasas Ahto ja Targo (ehk mina). Üritus ise toimus seekord üsna kaugel, Taiwanis.

Mõned päevad pärast meie väljumist tulistati vähem kui 10 km kaugusel meie lennutrajektoorist alla sama tüüpi Malaisia reisilennuk, aga sellist asja ei osanud lahkumise ajal veel keegi ette kujutada. Simmo osales ka Rahvusvahelisel Matemaatikaolümpiaadil ning lendas kohale Kaplinnast, ühinedes meiega Dubais. Lend ise oli paras tüütus, koos ooteaegadega üle 24 tunni, mida leevendas natuke Emiraatide lennuliini superkena teenindus ning see, et seal saab lennu ajal oma elektroonikat laadida.

Saabudes seisime peaaegu terve piirivalvejärjekorra ära, kuid siis krabati meid sealt välja ning suunati läbi spetsiaalse diplomaatide ja lennukimeeskondade värava. Piirivalvur kohtles meid aga autentse Hiina põhjalikkusega. Poisil oli nimekiri erinevate passide turvaelementidest ning ta kontrollis need kõik ükshaaval üle, uurides ka spetsiaalse luubiga, kas passipildile kantud mikrokiri ütleb ikka õiget asja.

Teisel pool võtsid meid vastu juba korraldajad, kes tegelesid terve päeva erinevate lendudega saabuvate võistkondade konveieril läbitöötlemisega: lennujaam-buss-registreerimine-kaelakaardid (RFID-ga, seda piiksutati erinevatel üritustel)-giid-hotellijaotus. Sadade eri maailma nurkadest saabuvate kooliõpilaste juhatamine pole kõige lihtsam ülesanne, respekt siinkohal korraldajatele. Paistis ka, et ürituse eelarve pealt polnud kokku hoitud, kasvõi meie majutus oli südalinna Hyattis, kus meie ja Taipei 101 kõrghoone vahele jäi vaid järgmine kubistlik veidrus:

Sellistel olümpiaadidel on igale võistkonnale tavapäraselt ette nähtud giid, enamasti kohalik õpilane või üliõpilane. Meie poiste giid ütles, et tema nimi on Lilian, aga Facebookis kirjutab ta hoopis 林家萱 ja ütleb oma kooliks olevat 臺北市立大安高級工業職業學校.

Juhendajad ja võistlejad majutatakse eraldi, et vältida liigseid kontakte võistluse perioodil, nii et poisse nägime taas järgmisel päeval, harjutusvoorul. Võistlus toimub korraldajate poolt ettevalmistatud riistvaral ning hoolimata sellest, et analoogses formaadis võistlusi on juba pikka aega korraldatud, tekib vahel tõrkeid – kas ei taha mõni printer araabiakeelset fonti trükkida või ei kannata kohalik võrk testfailide korraga sadadesse arvutitesse kopeerimist välja. Harjutusvoor ongi viimane võimalus selliste probleemide ennetamiseks.

Järgnenud avatseremoonia demonstreeris järjekordset tahku kohalikust kultuurist. Kõik sõnavõtjad alustasid pikkade pöördumistega erinevate kohalviibijate poole, hoolitsedes, et keegi vahele ei jääks ega vales järjekorras ei tuleks. Esmajärjekorras nimetati muidugi aukülalist, kelleks oli Taiwani asepresident Wu Den-yih. Kui asepresident ise lavale astus, mängis orkester spetsiaalset tunnusmeloodiat ning lava igasse nelja nurka vudis portfelliga turvamees. Aukülaline kõneles pikalt hiina keeles, mis hiljem umbes 10x lühemalt leninlikus “õppida-õppida-õppida” stiilis kokku võeti.

Hierarhilisus torkas ühiskondlikes suhetes üleüldse silma, isegi kiirtoidukohtade personalid teevad hommikuti rivistuse, kus ülemus neile väikese kõne peab.

Võistlusest

Võistluspäevi on IOI-l kaks, nende vahel puhkepäev. Kummalgi päeval on viis tundi aega, et lahendada kolm ülesannet. Lahenduseks on programmikood, mis saadetakse veebiliidese kaudu automaatsele testimissüsteemile, mis omakorda ütleb, kui palju punkte sa selle eest said. Kui mingi testi vastus oli vale, siis selle detaile sa teada ei saa, aga öeldakse, kui lahendus ületas ajalimiidi. Ülesannetega saab tutvuda IOI ametlikul saidil.

Et minimiseerida ajavahemikku, mil ülesanded laiemalt teada on, avalikustatakse nad juhendajatele eelmise päeva õhtul. Järgneb pikk diskussioon, mis meenutab tähenärimise maailmameistrivõistlusi ning mille käigus tehakse tavaliselt mitmesuguseid sõnastuse parandamise ettepanekuid. Kui ülesanded on stabiliseerunud, saavad juhendajad need tõlkida, trükkida ning vastastikku põhjalikult üle lugeda, et võistlejatel järgmisel päeval võimalikult vähe segadust tekiks.Võistluseelne ettevalmistus kestab juhendajate jaoks tavapäraselt pikalt üle südaöö, lisades sinna juurde ajavahe ning asjaolu, et mõnel päeval algas programm jälle hommikul vara, olin mina enamiku esimestest päevadest üsna kapsas.

IOI ülesannete lahendamise edukus on paljus kinni harjutamises, mistõttu domineerivad tulemustes riigid, millel on pikk ja põhjalik ettevalmistusprogramm, eelkõige Hiina ja USA, nemad said seekord ka neli kuldmedalit. Lisaks said kaks kulda Austraalia, Venemaa, Bulgaaria, Iraan, Korea, Tai ning Singapur. Nendel riikidel, kelle ettevalmistuse võimalused väiksemaks jäävad, pääsevad paremate kohtade löögile tavaliselt üksikud superandekad võistlejad, kelle hulgas on omakorda tähed nagu Gennady Korotkevich Valgevenest, mitmekordne absoluutvõitja. Eesti läbi aegade parim on olnud Martin Pettai, kes võistles aastail 1999-2002. Kultuuritausta rolli illustreerib ka asjaolu, et esimesel päeval said maksimaalsed 300 punkti 5 võistlejat, kellest kolme perekonnanimed olid Wu (USA-st), Xu ja Yu (Hiinast). Zu nimelist võistlejat siiski ei olnud.

Kuna informaatikas on võimalik kasutada automaattestimist, on juhendajate töö võistluse järel mõneti lihtsam kui teistel aladel, aga see ei tähenda, et üldse midagi teha ei oleks. Kui probleemid tekivad, on enamasti asi testide disainis või võistlejale antavas tagasisides. Kui juhtub, et kellelegi raporteeriti võistluse ajal tema lahenduse eest mittekorrektne punktide arv, on ka apellatsioon kindel. Ja nagu öeldud, on informaatikaolümpiaadi koondisejuhendajate seas hulgaliselt tähenärimistšempioneid :) Kokkuvõttes on ka võistlusjärgselt pikad koosolekud garanteeritud.

Tulemuste osas tekkis mul peas hierarhia: kasvõi Eestis on hulk kooliõpilasi, mingi koorekiht neist käib olümpiaadidel. Eesti koondis rahvusvahelisteks võistlusteks on omakorda koorekiht selle eelmise koorekihi sees, seal on umbes võrreldav tasemevahe. Siis aga saame mõelda neist, kes saavad rahvusvaheliselt olümpiaadilt kuldmedali (ülemine 1/12 kõigist võistlejatest, Eestist on informaatikas selle saavutanud Martin Pettai 3 korda, Erik Laansoo ja Oleg Mürk ühe korra) – nemad on jällegi klass omaette. Järgmine kvanthüpe on võistlejad, kes saavad maksimaalse skoori. Sel aastal oli 600 punktiga tulemusi 3, vahel pole neid ühtegi. Ja nende seas oli omakorda poiss, kes peajagu teistest üle – Scott Wu USA võistkonnast (järgmisel pildil parempoolne) saavutas esimesel päeval maksimumpunktid kõigest 2 tunni ja 13 minuti järel, teisel päeval veidi enam kui 3 tunni järel. Kokku siis natuke üle poole kasutada olnud kümnest tunnist. Katsun tal silma peal hoida, huvitav oleks näha, mis temast tulevikus saab.

Punktidest veel: aegade jooksul parim Eesti võistleja saavutatud skoor on 680/700 (Martin Pettai, 2000), käesoleval aastal oli meie parim skoor 323/600.

Alates võistlusele eelnevast õhtust kuni lõpusignaalini kestis karantiin, mille jooksul võistlejatel ei tohtinud olla kontakti välismaailmaga, eriti juhendajatega, seepärast pole võistlusest ka pilte. Küll tegime pilte pärast tulemuste selgumist ja autasustamist. Seekord sai võistkonna parima tulemuse Oliver-Matis, kes küündis hõbemedalini – meie jaoks täitsa korralik resultaat.

Toidust

Esimese võistluspäeva õhtuks oli ette nähtud pidulik söögiüritus, kus kohaliku kombe kohaselt tuli inimesi toita, nii et seda nägu.

Söömaaeg oli korraldatud Taipei linnapea poolt, kes pidas alguses kõne sellest, kuidas Taipei on maailma parim ja me peaks kõik sinna elama tulema. Kõne toon kõlas, nagu iga lause lõpus oleks mitu hüüumärki. Taipeis saab tegeleda kõigi huvialadega!!! Ja meil pole praktiliselt üldse mingit kuritegevust!!! Ja meie elanikud on väga abivalmid ja juhatavad teid alati kohale!!! Viimane oli meie kogemuses täitsa tõsi, aga instruktsioon viis kommunikatsioonihäirete tõttu hoopis teise kohta.

Seejärel kanti aga kõik kümme söögikäiku üksteise järel ette. See “geoduck” pildil toodud menüüs pole muuseas mitte maapart, vaid hoopis üks mereloom. Üldse oli Taiwanis viibimine üks suur söömaorgia, sest kõik katsusid meid alatasa toita ja söök oli minu meelest ka päris hea. Krooni pani viimasel päeval meie giidi ema, kes kutsus meid terve kambaga ühte kohalikku fancysse restorani ning tellis meile nii kaua igasuguseid asju, kuni me lõpuks nutu äärel kinnitasime, et tõepoolest rohkem ei jaksa. Isegi suvalistes külakohtades, kus me pärast ametlikku osa omal käel käisime, kanti laud igasugust kraami täis.

Ahto katsus lisaks leida kohta, kus mingeid praetud ämblikke müüdaks, aga edutult, nii et ta pidi neid ise loodusest püüdma.

Taiwanist

Võistlusvälisel ajal korraldati meile mitmesuguseid ekskursioone, kuid siin põrkuvad korraldajad probleemi otsa, et atraktsioone, kuhu saaks korraga viissada inimest komandeerida, on üsna raske leida. Tavapärasteks sihtmärkideks sarnastel üritustel on vabaõhumuuseumid, loomaaiad ja lõbustuspargid, kuid olles neid elus juba üksjagu näinud, katsusime ka võimalikult palju omal käel ringi vaadata. Kuna iga päev sinnakanti ei satu, jäime pärast üritust ka paariks ekstra päevaks omal kulul kohalikke olusid uurima.

Taiwan, Portugali meresõitjate poolt nimetatud Ilha Formosa – ilus saar, on väga mägine, kuid samas roheline. Tüüpiliselt peaks seal alatasa troopilist vihma sadama, kuid meie kogemuses oli ilm enamasti selge, kuigi palav ja niiske.

Pindalalt 20% Eestist väiksem, aga 23 miljoni elanikuga saar on meie mõistes muidugi väga tihedalt asustatud.

Tänavapildis jääb silma eelkõige Jaapani mõju, valdav enamik autosid on Jaapanist, rongisüsteem on sealse eeskujuga ning üle on võetud muidki kultuuritehnilisi uuendusi.

Mõistagi ei puudunud ka mitmesugused “lost in translation” efektid:

Kaugeima ekskursiooni tegime Taroko rahvusparki, kuhu meie giidi ema ei lubanud meiega kaasa tulla, sest sõita tuli mingit mägiteed mööda.

Reaalselt oli tee täitsa korralik, mujal maailmas olen palju hullemal sõitnud, aga kohalikud paistsidki meiega võrreldes väga ettevaatlik rahvas olevat (välja arvatud rolleritega linnatänavail sõites). Näiteks oli seal tavaline, et veepargis kantakse päästevesti ning rahvuspargis mägede vahel kiivrit. Eriti pani aga kukalt kratsima silt hotellis, mis kohustas personali informeerima, kui sul peaks ükskõik milline haigus kallal olema.

Viimasel täielikult Taiwanis veedetud päeva lõpetuseks saime aga mälestuseks vaat sellised pildid. Ookeanilained olid jalustrabavad, nii visuaalses kui ka sõna otseses tähenduses.

Järgmise aasta olümpiaad toimub juba hoopis vastupidises kliimas, ookeanist peaaegu nii kaugel kui vähegi võimalik, Almatõ linnas Kasahstanis. Paras aeg harjutama hakkamiseks on just praegu :)

No responses yet

Nov 30 2013

A* intervjuu

Published by Targo under Intervjuud, Isiklik

Sain hiljuti kirja mehelt nimega George London, kes katsub leida maailma parimat programmeerijat. Tema meetod on inimeste intervjueerimine, kus iga intervjueeritav soovitab 2 parimat oma tuttavat programmeerijat, kellega rääkida. Mingil hetkel jõudis ta minuni, mis on muidugi äärmiselt meelitav. Maailma parimani on mul ilmselt veel pikk tee käia, aga see andis hea võimaluse oma mõtete kogumiseks ning väljendamiseks. Ja nüüd olen ma samas nimistus kõrvuti Eric Lippertiga, woot!

Aga intervjuu ise on siin:

http://www.youtube.com/watch?v=hHcvh-9AEzM

Vabandan kehvavõitu kvaliteedi pärast, koduse asünkroonse internetiühenduse häda.

No responses yet

Jun 28 2013

Neli küsimust Eesti haridussüsteemile

Published by Targo under Haridus

Eesti hariduse ümber toimuv ringtants on minus viimasel ajal tekitanud mitu eksistentsiaalset küsimust. Tegu pole retooriliste küsimustega, ma tõesti soovin, et mõni haridussüsteemi asjatundja midagi öelda oskaks. Ja öelda võiks midagi sisulist, mitte ainult loosungeid stiilis „Eesti valitsus on meid kõiki maha müünud“.

Õpetamise efektiivsus

Minu 12-aastasel pojal on konkreetne ambitsioon asutada arvutimänge tegev ettevõte, just nagu tegi tema iidol Markus „Notch“ Persson. Entusiastliku lapsevanemana toetan tema üritust ja õpetan talle programmeerimist. Kui tahta põnevamat mängu teha, puutume peagi kokku geomeetria, vektorite ja siinustega. Mis seal siis ikka, õpime selgeks. Võtsin abiks põhikooli matemaatika lõpueksamiks valmistumise käsiraamatu, see tundus kõige mõistlikuma tasemena, mida konkreetse projekti juures vaja võiks minna. Käisime materjalid (natuke algebrat, geomeetriat, trigonomeetriat) läbi ja tegime ülesanded ära. Siinuse kontseptsioon sai selgeks, programm valmis ning kõrvalefektina suudaks ta nüüd ka põhikoolieksami ära teha, kui vaja peaks olema. Aega kulus kokku umbes 15-20 tundi õpetamist ning kaks korda nii palju iseseisvat tööd. Kui keegi nüüd arvab, et minu poiss on kuidagi eriline, siis ma pole nõus. Olen kindel, et suudaksin sama tulemuse saavutada iga lapsega, kellel on esiteks motivatsiooni ja keda pole teiseks lapsevanemate poolt ära rikutud jutuga, et „matemaatika on igav, raske, nõme jne“.

Samas 7-9 klassis, kus neid asju õpetatakse, on minu arvestuse kohaselt kokku 400-500 matemaatika tundi, lisaks kodutööd. Minu esimene küsimus on seega – mida seal koolis tehakse ometi kõik see aeg?

Veel – kui praegune haridusreform teoks saab ning esimese klassi katsed kaotatakse, kaob põhikoolilastel üldse ära võimalus midagi süvendatult õppida ning efektiivsusvahe on veelgi suurem. Praegugi on Eesti koolides PISA testi tipptasemel sooritajate arv madal, aga just need tipud on vajalikud majanduse uuele tasemele tõstmiseks. Eestlastele meeldib kiidelda, et nad on näiteks targemad kui ameeriklased, kuid ei panda tähele, et USA koolid on omavahel äärmiselt erinevad. Kui filmidest nähtud getokoolid on tõesti häbiplekiks ja keskmine jänki maailma asjadega eriti kursis ei ole, siis on USAs ka palju koolipiirkondi, mille tase on Eesti omadest kõrgem. Süvaõppega koolid ning tippülikoolid rebivad Eestiga juba väga suure vahe sisse ning tulemuseks ongi, et rahvusvahelisest suurfirmast Eestisse tööle tulles pidin kasvõi tööintervjuude küsimusi arvestatavalt lihtsustama, et siinsed ülikoolilõpetajad (võrreldes USA, Hiina, India ja Venemaa parematest koolidest tulijatega) nendega hakkama saaksid.

Lati langemine

Wikmani poisid õppisid 1930. aastatel humanitaarkoolis. Õpetuse rõhk oli keeltel, aga sellegipoolest oli neil lahe aine nimega kosmograafia ning veel lahedam kosmograafia õpetaja Trump, kes oskas tahvlile perfektseid ringjooni joonistada. Millalgi nõukogude ajal nimetati see õppeaine astronoomiaks, aga siis kadus see ka tavaõppest üldse ära, humanitaaridest rääkimata. Kui eeldada, et keskkooli eesmärk on anda noorele inimesele arusaam sellest, kuidas maailm toimib, on tegu traagilise kaotusega. Selle asemel, et iga elluastuja teaks, milliste reeglite põhjal planeedid Päikese ümber tegelikult tiirlevad, loevad nad hoopis ajalehesabade horoskoope ja muud umbluud.

Tagasi põhikoolieksami juurde: mäletan, et kui ma ise varastel 90.aastatel põhikooli lõpetasin, sirvisin üht 1940. aastatest pärit geomeetriaõpikut. Ülesanded tundusid päris rasked, aga vaatasin kaanele ja avastasin, et tegu oli 7. klassi õpikuga! Ehk siis minu äsjatehtud eksam oli kõvasti lihtsam kui nõukogude aja alguse materjal. Samamoodi olid minu poja harjutatud eksamiülesanded palju lihtsamad kui need, mida ma ise kunagi tegin. Üldise reeglina oleme iga põlvkonnaga kaotanud 1-2 aasta jagu koolitarkust.

Samas on arvamusruum pidevalt täis seisukohti, mille kohaselt „antakse lastele kogu aeg nii kohutavalt palju õppida“, nii et neil pole enam aega süüa ja magadagi. Murelikud lapsevanemad helistavad jutusaadetesse, mul endal on mitu tuttavat, kes „liiga rangeid õpetajaid“ kiruvad ning riigiraadio mängib korrapäraselt õpetajaid ja kodutöid pilavat lasteraamatut „Sirli, Siim ja saladused“. Õpetaja Allar Veelmaa kritiseeris Õpetajate Lehes tasemetööde nõrka läbiviimist, kuid möönab samas, et ta ise osales ka õppekava väljatöötamises ja „tekstülesanded on 6.klassi jaoks ikka liiga rasked, viisime need 7.klassi programmi“.  Ka Vigala vallavanem, kes muidu Postimehes madalaid eksamilävendeid kirub, ütleb teiselt poolt, et „õpilaste koormus on ebanormaalselt suur“.

Minu teine küsimus: millega on selgitatav, et ühelt poolt on koolis käimine tänapäeval hirmus raske, aga koolilõpetajate teadmised on järjest väiksemad?

Õpetuse kohustuslikkus

Ene Ergma kirjutas kevadel, kuidas bakalaureuseõpe ei annagi mingit korralikku ettevalmistust ja õige hariduse saab alles magistrikraadiga. Aga mõtleme nüüd natuke koolisüsteemi ajaloo peale.

Kunagi oli koolis käimine üleüldse vabatahtlik. Kes hakkama sai, oli tubli mees. Siis selgus, et ühiskonna üldist haridustaset tuleb tõsta ning tekkis kohustuslik põhikool, mis andis teatud baasteadmised, süvendatud õpet sai gümnaasiumis ning ülikool oli juba päris kõva sõna. Seejärel leiti aga, et ühiskonna teadmiste tase peaks ikkagi kõrgem olema ja ka keskkool muudeti üldiseks. Loomulikult ei saanud kõik lapsed sellega võrdselt hakkama ning tulemuseks oli õppekava oluline lihtsustamine. Sel ajal kui ma ise ülikooli läksin, tegeleti esimese aasta jooksul peamiselt keskkooli puudujääkide likvideerimisega. Ja nüüdseks on ka ülikooli põhiõpe muutunud massiürituseks, kust ühiskonna arvamusliidrite sõnul „polegi midagi oodata“.

Ehk siis toimib tsükkel: ühiskondlik haridusalane konkurentsivõime on madal => muudame järjekordse kooliastme kohustuslikuks => kõik lapsed ei saa sellega hakkama => lihtsustame õpetust => selle kooliastme tulemused kahanevad => ühiskondlik haridustase on sama madal edasi, aga me oleme veel enam ressursse ja noorte aega ära raisanud.

Lugesin kunagi ulmekat, kus tulevikuühiskonnas antakse igale 21 aastaseks saajale automaatselt bakalaureusekraad, et „keegi ei peaks ennast halvasti tundma“. Raamat oli kirjutatud paarkümmend aastat tagasi ja tundus toona jaburana, aga ilmselgelt oleme hoogsalt sinnapoole teel.

Minu kolmas küsimus: milleks see lapsepõlve igavene pikendamine vajalik on?

Ühiskondlik vajadus

Eestis on viimasel ajal lõpuks selgelt teadvustunud IT-spetsialistide puudus. Lihtsa ja mugava lahendusena pakuvad ettevõtjad  välja sisserännu lihtsustamist. Plaan on vildakas, sest tippspetsialistidel pole mingit huvi siia viletsa kliimaga kanti tulla, selle asemel peaksime võtma mitmekordse hulga keskmikke ehk siis tuhandeid ja tuhandeid võõramaalasi. Samal ajal on meil suur noorte tööpuudus – miski nagu ei klapi selles pildis?

Tüüpiline vastuväide on, et igaühest ei saagi programmeerijat kasvatada. Võib-olla igaühest tõesti ei ole võimalik, aga neid saab kindlasti olla palju kordi rohkem. Võtmeks on siin kasvõi needsamad „hirmsad“ tekstülesanded – programmeerija töö on suures osas tekstilisest lähteinfost konkreetsete lähteandmete identifitseerimine ning selle põhjal formaalse, arvutile arusaadava lahenduskäigu koostamine. Ja kui meie vanaisade ajal saadi tekstülesannetega suurepäraselt hakkama, siis võiks seda saada ka tänapäeva lapsed. Tulemusena saaksime mitmekordse tööjõuturul konkurentsivõimelise noorte arvu, täiesti oma rahva seast, selle asemel, et tuua riiki hulk sisserändajaid, kellelt kohalikud noored sotsiaaltoetusi hakkavad nuruma. Vt ka Andres Arraku sarnaseteemalist artiklit.

Üldine soovitus on seega hariduse juhtimine vastavalt ühiskondlikule vajadusele ja tuleviku nõuetele. Selle asemel annavad aga tooni mitmesugused kasvatusteadlased ning arengupsühholoogid, kes tegelevad eelkõige probleemsete lastega ning püüavad leida neile võimalikult sobivaid lahendusi.

Ehk siis kui teatud rühmal lastest on koolis stress, lahendatakse seda eelkõige nõuete vähendamisega, tuues selle juures ohvriks andekamate laste arenguvõimalused ning rahvastiku konkurentsivõime tervikuna.

Minu neljas küsimus: kas hariduses peaks tähtsam olema igaühe individuaalne rahulolu või ühiskondlik huvi?


20 responses so far

Jan 22 2013

Kuidas tellida tarkvaraprojekti

Published by Targo under Projektijuhtimine, Raha

Eelmise aasta lõpupoole korraldas Äripäev seminari Kuidas korraldada edukaid tarkvarahankeid, kuulajaskonnaks mitmesugused avaliku ja erasektori esindajad, kellel aeg-ajalt vaja tarkvara tellida. Tegin ise ettekande agiilse arenduse teemal, refereerin nüüd ka siin. Osaliselt on kasutatud kaastöötajate Tiit Anmanni ja Aet Rahe koostatud materjale.

Aga kõigepealt väike viktoriin. Andke igale järgnevatest küsimustest vastusena 2 arvu: alampiir ja ülempiir. Püüdke teha nii, et olete 90% kindel, et õige vastus on nende 2 arvu vahel.

  1. Mis on Päikese pinna temperatuur?
  2. Mis on Šanghai laiuskraad?
  3. Mis on Aasia pindala?
  4. Mis aastal sündis Aleksander Suur?
  5. Kui palju on ringluses eurosid (sularaha)?
  6. Mis on Peipsi järve ruumala?
  7. Kui palju teenis film Titanic kinodes?
  8. Mis on Vaikse Ookeani rannajoone pikkus?
  9. Kui palju raamatuid on USA ajaloo jooksul välja antud?
  10. Kui palju kaalub raskeim sinivaal?

Väliseid abivahendeid ei tohi mõistagi kasutada. Kui vastused kirjas, võib neid kontrollida siit.

Kui vastata nii, et iga küsimuse puhul on 90% tõenäosus, et õige vastus jääb antud alam- ning ülempiiri vahele, peaks saama keskeltläbi 9 õiget vastust. Samas olen seda viktoriini aga päris mitu korda tegelikus elus korraldanud. Olukorras, kus inimesed häbenevad teiste kuuldes väga ebamääraselt vastata, on tavapärane õigete vastuste arv pigem 2.

Milles on point? Mõistagi mitte inimeste vaaladealaste teadmiste kontrollis. Pigem on asi selles, et enamvähem sellise metoodikaga antakse mahuhinnangud ka enamikule maailma tarkvaraprojektidest. Kuidas nii? Väga lihtne – iga projekt on tegijate jaoks uus. Kui järgmine projekt oleks täpselt samasugune nagu eelmine, poleks seal vaja midagi teha, vaid võiksime lihtsalt võtta olemasoleva koodi ja selle kopeerida. Väga tihti sisaldab uus projekt ka mingeid uusi tehnoloogiaid ja ärivaldkonda, mille kohta teostajatel pole vähimatki aimu.

Siiski leiab iga päev kusagil aset stseen, kus projektijuht näitab vanemarendajale mingit umbmäärast kirjeldust ja küsib, kui kaua sellega läheb. Vanemarendaja ei taha muidugi välja näidata, et tal on sellest sama vähe aimu kui Peipsi ruumalast, ning käibki mingi arvu välja. Sealjuures enamasti ühe arvu, mitte alam- ja ülempiiri.

Hinnang läheb pakkumisse, sealt lepingusse ja aasta-paari pärast kakeldakse, miks asjad õigeks ajaks valmis pole saanud. Samuti võivad tellija ja täitja esialgsed hinnangud olla radikaalselt erinevad.

Mis on tarkvaraprojekti tüüpilised mured?

  • Asjad ei saa planeeritud eelarves ja ajakavas valmis.
  • See, mida telliti, ei ole see, mida vaja oli.
  • Projekti käigus muutuvad ja täienevad nõuded pidevalt.

Halvemal juhul võib juhtuda, et:

  • “Teine pool” on laisk, loll jne.
  • Projekt ei saagi valmis!
  • Ja isegi raha juurde makstes ei saa valmis!!

Mispärast? See pole ju ometi esimene projekt, mida “te” teete? Te olete ju oma ala asjatundjad?! Professionaalid!?

Vaatleme järgnevat illustratiivset näidet (NB! Tegemist on üldistusega. Igasugune kokkulangevus reaalse elu sündmuste või tegelastega on juhuslik).

Oletame, et oled ehitusfirma omanik. Kui palju maksab see maja?

Pakkumise esitamise tingimused:

  • Esitada fikseeritud hinnaga pakkumine 05.02.2013.
  • Valmimise tähtaeg 15.06.2013.
  • Täpsustavaid küsimusi saab esitada kirjalikult, vastame 3 tööpäeva jooksul.
  • Maja hind peab sisaldama kõike eluks vajalikku, s.h. siseviimistlust ning kogu vajalikku mööblit, kommunikatsioone jmt.
  • Tööde käigus hinda suurendada ei ole võimalik, küll aga on Tellijal õigus vajadusel hinda vähendada.
  • kaasas 10 lk-line maja „detailne“ kirjeldus.
  • Kirjeldus sisaldab enamasti maja välimuse kirjeldust väljastpoolt vaadates. Erilist tähelepanu on pööratud detailse maja eestvaate kirjeldamisele (kuna see on tellija arvates eriti oluline osa!).
  • Kirjelduses ka üldandmed. Näiteks: elamispind 200 m², maja taga terrass, 3 korrust jne.
  • Kirjelduse on koostanud ehitusalase hariduseta ja kogemuseta isik.

Ainsaks valikukriteeriumiks on hind.
Hankega käib kaasas lepingu projekt.

  • Lepinguks on Tellija tüüpleping, mis ei kuulu arutluse alla!
  • Tellijal on õigused, Täitjal kohustused.
  • Tähtajad on kivisse raiutud ning nende ületamisega kaasnevad märkimisväärsed sanktsioonid Täitja suunas.

Kui keegi nüüd arvab, et ma liialdan, siis valdav enamik tarkvarahankedokumente, mida ma olen elus lugenud, vastavad sellele kirjeldusele.

Esialgse ettekande väline kommentaar: enne seda seminari olin vahel imestanud, kust sellised hanked ometi tulevad? Üritusel hakkasin asjale pihta saama – paljudes asutustes on tööl spetsiaalne hankespetsialist, kes hangibki ühel nädalal ekskavaatoreid, teisel tarkvara, kolmandal põrandakütet jne. Selline spetsialist tunneb hästi riigihangete seadust ja oskab nt õiges vormis maksuvõlgnevuste puudumise tõendeid küsida, kuid asjade reaalsest sisust ta enamasti ei tea ja projekti elluviimisega kokku ei puutu. Siit tuleb ka hangete hinnapõhisus – hindu on palju lihtsam võrrelda kui pakkujate sisulist võimekust.
Minu jaoks kõige nutusem asjaolu oli aga mõnede kohalviibinute suhtumine – et mis sellest siis on, kui hange on ähmaselt sõnastatud? Las pakkujad lähevad riigihangete vaidlustuskomisjoni ja räägivad seal, kui mingi probleem on! Avaliku sektori töötaja käest sellist repliiki kuulda oli kahekordselt valus – esiteks on kahju oma maksuraha pärast, millega kõigi osalevate ametnike vaidlemiseks kuluv aeg kinni makstakse, teiseks aga on kummastav see mõistmatus. Erafirmale läheb riigihanke vaidlustamine juba õigusabikuludena maksma tuhandeid eurosid, rääkimata spetsialistide ajast, kes selle asemel millegi kasulikuga võiksid tegeleda. Nii tõstab see teenuse turuhinda ja lõppkokkuvõttes jällegi maksumaksja kulusid.
Mõistagi püüab ka täitja oma juriidilist tagumikku kaitsta. Tavaliselt koostatakse selleks mitmesuguseid lepingulisasid, kus on kirjas ka tellija kohustused, näiteks kohustus ise täpseteks tähtaegadeks teatud sisendid anda jne. Ehk toimub võidurelvastumine, mille käigus kumbki pool katsub endale võimalikult palju laskemoona varuda.

Aga egas midagi, hakkame tööga pihta!

Projekti käigus selgub, et:
  • 10 lk-ses dokumendis kirja pandu oli enam-vähem korrektne.
  • Küll aga on palju detaile, millele keegi hanget ega pakkumust kokku pannes ei tulnud.
  • Pole hullu! Hind on ju lukus ja õnneks mahub lause „Maja hind peab sisaldama kõike eluks vajalikku, s.h. siseviimistlust ning kogu vajalikku mööblit, kommunikatsioone jmt.“ taha palju, isegi väga palju!

Ainsateks muredeks on mõistagi vaid asjaolud, et kõik kaasatud osapooled on õnnetud ning ka lõpptulemini jõudmine ei tee kedagi õnnelikumaks.

Kirjeldatu oli praegu standardsituatsioon. Kui selline projekt juba alanud on, juhtub enamasti üks kahest variandist:

Esimene võimalus on see, et täitja projektijuht hoiab raudhammastega skoobist kinni. Aset leiavad järgmised tüüpilised dialoogid:

“Aga me tahaks seda ka.”
“Ei saa.”
“Aga kuidas sellega oleks?”
“Ei saa.”
“Aga…”
“Ei saa.”

Ja loomulikult kurdab tellija, et täitja on mõistmatu.

Siiski tuleb tähele panna, et see on pigem hea variant!

Alternatiiv on tavaliselt selline:

Kõigepealt tekivad haldamatud muudatused. Pärast mitmeid tähtaegadest üleminekuid on kaks võimalust: projekt ei valmigi mitte kunagi või siis tuleb seda saneerida, suurest osast ideedest (ja poolvalmis tööst) loobuda ning see, mis toodangusse antakse, võib olla isegi väiksem kui esialgne skoop ette oleks näinud.

Kõik tarkvaraprojektidega kokku puutuvad inimesed on ilmselt seda kolmnurka näinud. Samas keegi ei kasuta seda. Alati, kui kellegagi rääkida, et mida neist valida, saab sama vastuse nagu Karupoeg Puhhilt, kui küsiti, kas too soovib mett või kondenspiima: “Mõlemat!”

Tulemus on mõistagi selge: kui kolmnurga igat tippu väljapoole tirida, käriseb see seest ning ohverdatakse see, mida on kõige raskem mõõta – kvaliteet. On ka täiesti loomulik, et kui lepingusse ikka tähtaegade ületamise eest on trahv sisse kirjutatud, lükatakse kliendile ette mida iganes, et sellest pääseda – eks pärast jõuab klaarida.

Kuna senikirjeldatud probleemid on äärmiselt tavalised, on neile mõistagi ka mitmesuguseid vastumeetmeid leida püütud.

Üks levinumaid “lahendusi” on võimalikult põhjaliku nõuete loetelu koostamine enne projekti algust. Tavaliselt käib see nii, et tellija poolelt on keegi saatnud laiali ringkirja ja palunud kõigil huvilistel oma mõtted kirja panna. Tulemus copy-paste’itakse hankedokumenti ning öeldakse, et vaat, täpselt neid asju ongi vaja.

Selle lähenemise probleemid on muidugi ilmsed:

  • Kirjapandu on prioritiseerimata – kuna igaühel on hirm, et tema soovid võivad välja jääda, fantaseeritakse kokku pigem rohkem kui vähem. Tulemuseks on süsteem, mille võimalustest rohkem kui 50% ei hakka keegi kunagi kasutama – enam kui pool tellija rahast läheb lihtsalt raisku! Halvemal juhul võib hankedokumendist leida ka omavahel risti vastu käivaid soove…
  • Me välistame kõik head ideed, mis meil projekti käigus võivad tulla.
  • Lõplikul süsteemil on kõik “design by committee” omadused.

Teine võimalus on, et lepingus fikseeritakse keerukas muudatuste haldamise protseduur. Iga muudatus tuleb kõigiga kooskõlastada, projektiplaani täiendada jne. See on natuke parem variant, aga toob kaasa äärmiselt koormava bürokraatia. Kui iga ettepanek nõuab projektiplaani mõjuhinnangut ja spetsifikatsioonide ümberkirjutamist enne muudatuse heakskiitu, võtab plaanide ümberjoonistamine ja kooskõlastamine lõpuks inimeste kogu aja ära ja keegi ei taha seda teha. Lõpuks jõuame olukorrani, kus muudatuste haldamise protseduurist on saanud muudatuste vältimise protseduur.

Täitja poolt pakutakse muidugi omi võimalusi. Raudhammastega projektijuhist oli juba juttu, aga kõige tüüpilisem on kõigi ajahinnangute korrutamine mingi konstandiga (näiteks π). Siin on muidugi tulemuseks, et tegelik ajakulu tuleb tõenäoliselt hoopis midagi muud, kui esialgu planeeritud, ning üks või teine pool tunneb paratamatult, et on pügada saanud.

Arendajate lemmikalternatiiv on mõistagi Time&Material – tellija maksab kogu aja eest, mis arendajal kulus. See on tellijaile tihti hirmutav ning õigusega – kulude kontrolli alt väljumine on arvestatav oht.

Kokkuvõttes jõuame arusaamisele, et:

  • Mittetriviaalsed tarkvaraprojektid on põhimõtteliselt ennustamatud.
  • Muudatused on vältimatud.
  • Tarkvaraprojekti ei ole võimalik ega praktiline detailselt ette planeerida.
  • Kombinatsioon “fikseeritud hind, skoop ja tähtaeg” lõpeb enamasti ebaõnnestumisega.

Järeldus: muudatustesse tuleb suhtuda nagu paratamatusse ning protsess tuleb üles ehitada nendega arvestamiseks, mitte nendega võitlemiseks.

Aga mida konkreetselt teha?

Peamine rohi, mida kirjeldatud probleemide vastu välja pakutakse, on agiilne arendus. Peaaegu kõigile tarkvaraorganisatsioonidele meeldib kirjeldada ennast kui agiilseid. Mis värk sellega aga tegelikult on?

Agiilse arenduse alustalad on:

  • Suhtlemine on tähtsam kui protsess.
  • Töötav tarkvara on tähtsam kui dokumentatsiooni täielikkus.
  • Kliendi ja täitja koostöö on tähtsam kui lepinguläbirääkimised.
  • Muudatustele reageerimine on tähtsam kui plaani järgimine.

Vaatlen siin lähemalt Scrumi, aga nimetatud printsiibid kehtivad ka kõigi teiste metoodikate (nt Kanban) puhul.

Scrumi peamine omadus on Product Backlog – tööde hulk, mille võiks ära teha. Kõik uued ideed lisatakse lihtsalt backlog’i. Iga alametapi ehk sprindi alguses valitakse tööde nimekirjast (tellijaga koostöös!) kõige olulisemad asjad, mida ära teha, ja tarnitakse selle tulemus mõned nädalad hiljem.

Siit on ka selgelt näha, et projekti lõplik skoop ja tähtaeg ei saa olla korraga fikseeritud! See tähendab ka loobumist konkreetseks tähtajaks valmivast detailsest projektiplaanist (ning selle pidevast ümberjoonistamisest).

Teine peamine omadus on sagedased (mõõdetavad nädalates, mitte kuudes) tarned ning see, et iga tarne tulemus peab olema kliendile kohe kasutatav.

Ja kolmas peamine omadus on kiire klienditagasiside. Siit tuleneb ka nimetus “agiilne” ehk väle. Asi pole mitte selles, et programmeerijad liigutaksid kiiremini näppusid, vaid selles, et klient vaatab tööde tulemusi kiiremini ja sagedamini üle!

Scrumi õnnestumise või ebaõnnestumise määrab üldjuhul see, kas tellija läheb metoodikaga kaasa või mitte. Tean paljusid projekte, kus tiimiliikmed ütlevad, et oh, meil on Scrum, sest nad teevad igapäevaseid koosolekuid, aga tegelikult on projektil ikka fikseeritud skoop ja tähtaeg. Kui projekti üks pool on agiilne ja teine mitte, on tulemus nagu absurdianekdoot:

K: “Mitut sürrealisti on vaja, et lambipirni vahetada?”
V: “Kaelkirjak.”

See, et skoop pole fikseeritud, peab olema ka arenduslepingus kajastatud, vastasel korral ei tule asjast midagi välja.

Lisaks tagasisidele on vajalik ka tellija aktiivne osalus backlogi prioritiseerimises, mis nõuab detailset süvenemist ning inimesi, kellel on tegelikult ka võimalik panustada aega ja pingutust ning samas võtta vastu otsuseid prioriteetide osas. Kui iga otsust mingi komitee või juhtrühm kinnitama peab, ei tule jälle midagi välja.

Kuidas Scrumi hinnastada?

Heaks mudeliks on fikseeritud skoobi ja T&M vahepealne variant. Iga sprindi alguses lepitakse kokku mingi tulem ning vastava sprindi lõpus tasutakse selle eest. Enam pole vaja maagilisi konstante, millega hinnanguid korrutada ja mis emmale-kummale poolele kaotuse kaasa toovad!

Süsteem on õiglane, sest tellija maksab parasjagu selle eest, mis on kätte saadud (iga sprindi tulemus peab olema kasutatav!), ning täitja saab parasjagu nii palju raha, kui palju on tööd tehtud.

Siiski võib jääda kahtlus, et milleks see kõik? Tundub kangesti hirmutav, et kuidas me siis ei kirjelda kõiki nõudeid, kuupäevi ja eurosid algusest peale ära…

Agiilse arenduse konkreetsed kasutegurid, mida igaüks oma tuttavatele tarkvaratellijatele võib presenteerida, on:

  1. Tellija saab selle, mida ta tegelikult tahab – pool tööst ei lähe enam raisku!
  2. Arendus on efektiivsem – pidevatele plaanimuutustele läheb vähem auru -> suurem kasu nii tellijale kui täitjale
  3. Ebaõnnestumisel pole vaja kogu projektist loobuda – suur eelis klassikalise waterfalli ees!
  4. Dramaatiliselt kõrgem kvaliteet – enam pole vaja nui neljaks konkreetseks tähtajaks midagi tarnida.
  5. Ning last but not least, vähem inimestevahelisi konflikte – projektijuhid ei pea enam pärast projekti lõppu otsejoones Anonüümsetesse Alkohoolikutesse suunduma.

12 responses so far

Next »