‘Tarkvaraarendus’ sildiga artiklid

Niisamuti nagu mitmete teiste eesti keelsete sõnadega on ka sõnapaari tarkvara – riistvara tõlkimisega veidi kehvasti läinud. Ja ma ei püüa siin kiruda, et tarkvara on tegelikult rumal.

Asi on nimelt selles, et inglise keelsed väljendid software – hardware ei anna absoluutselt mingit vihjet selle kohta, et üks vara oleks teisest nutikam ega ka seda, et teine vara on tööriistadega seotud.

Minu arvates on tõlkes kaduma läinud mõte, et software-i on võimalik pidevalt muuta ja edasi arendada, seevastu hardware on selline vara, mida muuta ei saa. Seega on minu ettepanek mõelda iga kord tarkvara tehes, et seda võiks, saaks ja peaks tulevikus muutma. Muidu võiks ta olla ka riistvara.

Üks tüüpilisi töövestluse küsimusi on: kas sa oled motiveeritud tööd tegema? Kui inimene on juba nii kaugele jõudnud, et on töövestlusel, siis mingisugune motivatsioon tal on. Variante võib olla mitmeid: keskkonna vahetus; arengu võimaluste  / väljakutsete puudumine eelnevas kohas; suurem palgasoov jms.

Ühes artiklis jäi mulle huvitav seisukoht meelde: ettevõtted ei pea motiveerima enda töötajaid, vaid nad ei tohi seda ära võtta. Seetõttu töövestlusel tasub vastu küsida, et mida nad teevad, et sult seda ära võtta. Esmapilgul tundub see veidi jabur, kuid võib-olla veenab teid ettekanne “Väledate metoodikate mõõdikutest”.

Kui alustame mingi hobiga, siis me teeme seda selle enda pärast. Meil on kirg mingi tegevuse vastu, kuid seda on võimalik lõhestada ning nii juhtub tavaliselt kui hobist saab meie töö, aastate pärast juba vaikselt vihkame seda. Siit väike soovitus: ära tee enda hobist tööd.

Loe edasi »

Väga lihtne küsimus teile: mitu kasutajakontot sul kokku on? Ma ise ei soovi seda väga lugedagi, kuid tean, et nende haldamiseks on mul vaja haldusvahendit. Mõnes kohas on konto ainult selleks, et saaks väga salajasi tegevusi teha (näiteks videot alla laadida, et saaks mõnel vabal momendil seda vaadata).

Kuidas te ennast tunneksite kui toidupoodi minnes kassas küsitakse su käest kliendikaarti ja kui seda pole, siis ei saa ka kahjuks ostu sooritada?

Probleemi osas näen ma kahte lahendust: kasutada BugMeNot häid võimalusi või teavitada analüütikuid ja arendajaid, et igal rakendusel ei pea olema kasutajakontod.

Loe edasi »

On teada üks kutsehaigus, kus igat ettejuhtuvat probleemi püüab spetsialist lahendada vastavalt oma professioonile. Juristid arvavad, et kõik probleemid saab lahendada vettpidavate lepingutega. Programmeerijad arvavad, et iga probleemi lahendamiseks on vaja kirjutada programm. Hiljem kui programm on valmis, tuleb seda hooldada ja käigus hoida, aga administreerimine ei ole arendajatele motiveeriv tegevus. Tutvustan Saikus kasutatavaid teenuseid, mis aitavad meil igapäevaselt oma töödega hakkama saada ilma, et peaksime pool (jah, ma pingutan üle) tööajast toetavate tegevuste tarkvarade haldamisega tegelema. Loe edasi »

26. ja 27. novembril toimub Tartus kolmandat aastat järjest innovatiivse tarkvara tehnika sümpoosium. Üritus miksib kokku akadeemilise hariduse ja ärivaldkonna vaated ja leiab ühisosa. Esinejaid on nii kodu- kui ka välismaalt ning ettekanded jagunevad peamiselt viie valdkonna vahel: Cloud & Services, Security & Privacy, Software Business Models, Software Development Tools ja Modeling Tools & Paradigms. Kohtume Tartus, täpem informatsioon  sümpoosiumi kodulehelt.

Süsteemide loomisel tuleb igal meeskonnas oleval inimesel viia läbi hulgalisi otsuseid. Valed otsused jäävad tihti kummitama ning viivad meid seisu, kus järgnevad otsused on mõjutatud oluliselt eelmistest. Sellest tulenevalt võime teha parima otsuse, kuid valik otsustest ei pruugi enam nii laialdane olla.

Arendajad otsustavad lähtekoodi tasemel, analüütikud kliendiga koos olles, projektijuhid ajaplaani loomisel, arhitektid süsteemi üldkontseptsiooni tasemel – on näha, et rollide põhiselt teeme otsuseid vastavalt tööspetsiifikale. Mõned otsused hõlmavad kogu meeskonda ja tihti ka tellijat, kuid see on igapäevaste tööga seotud otsuste puhul väike osa ja samas väga oluline.

Loe edasi »

Ekstreemprogrammeerimisest on saanud alguse kasutajalood (User Story). Neid on nime järgi lihtne segamini ajada kasutuslugudega (Use-Case), kuid sisu poolest on need vägagi erinevad.

Esmane kasutus kasutajalugudel oli seda võtta märkmena, et sellisest funktsionaalsusest on vaja rääkida ja ehitada. Neile lisati märkuseid ja hinnati punktisüsteemis keerukuse järgi või ideaalsetes päevades. Kasutajalood jagati ülesanneteks, millele lisati reaalsem ajakulu juurde.

Loe edasi »

Enne sai kirjutatud, et iteratsioonid on kasutud ning pidev voog on oluline. Siiski kõik see vastab tõele, kuid vaatleks veidi teise nurga alt iteratsioone.

Iga iteratsiooni alguses lepitakse kokku, mis funktsionaalsus süsteemi lisatud saab ehk hulk tööd. Lean tarkvaraarenduses märgitakse seevastu piirangud töö staatustele, et pooleliolevat tööd (WIP) liiga palju ei tekkiks. Mõlemal puhul üritatakse pooleli oleva töö hulka minimeerida, kuid iteratsioonil on juures ka ajaline piirang.

Loe edasi »

Läbi aegade on mudelid aidanud meil probleeme lahendada. Enne Bohri mudelit oli Rutherfordi mudel ja kuubi mudel – kõik kirjeldasid sama asja, kuid erinevatest vaatenurkadest ja täpsusastmest ning sellest tulenevalt oli võimalik teooriaid nende peale luua, mis üks hetk võisid vähem vajalikuks muutuda.

Bohri mudel võib olla vägagi täpne, kuid vahel meile piisab ka kuubi mudelist. Teisisõnu mudelid ei pea täielikult peegeldama reaalsust. Võtame mudelisse need osad reaalsusest, mis rajatava süsteemi jaoks olulised on ja ka neid vääname enda nägemise järgi abstraktsioonidega. Näiteks rakuehituse uurimisel pole meile aatomite maailm väga oluline.

Loe edasi »

Suhtlus on tähtsal kohal projektis. Suur osa probleeme, mis tekkivad, on tingitud vähesest suhtlusest. Sellest pikemalt või lugeda eelnevast postitusest “Miks projektid ebaõnnestuvad”. Selle postituse raames vaatlen, millised suhtluse liigid on ja mis nende eripärad on.

Esimese hooga võib suhtlust liigitada kaheks: sünkroonne ja asünkroonne. Scott W. Ambleri artiklis oli toodud ära suhtluse efektiivsuse kurv, mis algas e-postiga ja lõppes näost näkku suhtlusega tahvli juures. Kui x-teljel vahetada suhtluse rikkalikus ära sünkroonsusega, siis see näeks sama välja.

Loe edasi »