User:Eehrbach: Difference between revisions

From ICO wiki
Jump to navigationJump to search
Eehrbach (talk | contribs)
No edit summary
Eehrbach (talk | contribs)
No edit summary
Line 12: Line 12:
Tarvaraarendus on mulle alates keskkooli algusest huvi pakkunud. Tollal kirjutasin oma esimesed HTML failid, mida suure uhkusega veebilehitsejas avasin ja sõpradele näitasin. Nendest hetkedest alates olin kindel, et soovin IT-erialal haridust omandada ja töötada. Nüüd, kuus aastat hiljem olen IT-Kolledžis oma teist infotehnoloogia valdkonna kõrgharidust omandamas ning kogemustepagasisse mahtunud ka 2 aasta jagu elutarkusi digiagentuuri tööst. IT-Kolledž oli loogiline samm edasi, mida olin paar aastat planeerinud ja vaadates veebivahendusel salvestatud avalikke loenguid professionaalidelt, olen selles veendunud.
Tarvaraarendus on mulle alates keskkooli algusest huvi pakkunud. Tollal kirjutasin oma esimesed HTML failid, mida suure uhkusega veebilehitsejas avasin ja sõpradele näitasin. Nendest hetkedest alates olin kindel, et soovin IT-erialal haridust omandada ja töötada. Nüüd, kuus aastat hiljem olen IT-Kolledžis oma teist infotehnoloogia valdkonna kõrgharidust omandamas ning kogemustepagasisse mahtunud ka 2 aasta jagu elutarkusi digiagentuuri tööst. IT-Kolledž oli loogiline samm edasi, mida olin paar aastat planeerinud ja vaadates veebivahendusel salvestatud avalikke loenguid professionaalidelt, olen selles veendunud.


Esimese IT-kolledži avaliku loengu vaatasin vahetult peale kooli kandideerimist. Loenguks oli Meelis Langi etteaste teemal “Agiilse arenduse psühholoogia ja DNA”. Hr. Langi poolt esiletoodud jutupunktid olid mulle isiklikult väga teemakohased, kuna tööalaselt olen agiilse arenduse protsessidest osa võtnud ja presenteeritud probleemid olid äratuntavad. Loengu käigus rääkis Helmese tarkvaraarendusjuht agiilse arenduse tekkeloost ning ühest suurimast veast selle rakendamisel, milleks on liigne protsessidesse takerdumine. See tähendab, et meeskonnad üritavad väga täpselt järgida protsesside järgimist ilma, et ise oldaks piisvalt agiilsed selle käigus. Isiklikult olen selle väitega sajaprotsendiliselt nõus, kuna olen olnud osa meeskonnast, kus kindlaid osapooli häirivad ja demotiveerivad muutuvad asjaolud ning ei mõisteta loodava lahenduse väärtust lõppkasutaja jaoks.  
Esimese IT-kolledži avaliku loengu vaatasin vahetult peale kooli kandideerimist. Loenguks oli Meelis Langi etteaste teemal “Agiilse arenduse psühholoogia ja DNA”<ref name="loeng1">[http://www.itcollege.ee/blog/2016/03/10/it-kolledz-kutsub-avalikule-loengule-agiilse-arenduse-psuhholoogia-ja-dna/ Meelis Lang "Agiilse arenduse psühholoogia ja DNA" ]</ref>. Hr. Langi poolt esiletoodud jutupunktid olid mulle isiklikult väga teemakohased, kuna tööalaselt olen agiilse arenduse protsessidest osa võtnud ja presenteeritud probleemid olid äratuntavad. Loengu käigus rääkis Helmese tarkvaraarendusjuht agiilse arenduse tekkeloost ning ühest suurimast veast selle rakendamisel, milleks on liigne protsessidesse takerdumine. See tähendab, et meeskonnad üritavad väga täpselt järgida protsesside järgimist ilma, et ise oldaks piisvalt agiilsed selle käigus. Isiklikult olen selle väitega sajaprotsendiliselt nõus, kuna olen olnud osa meeskonnast, kus kindlaid osapooli häirivad ja demotiveerivad muutuvad asjaolud ning ei mõisteta loodava lahenduse väärtust lõppkasutaja jaoks.  


Nimetatud agiilsus peaks väljenduma kõigi projektist osavõtvate isikute puhul. See tähendab, et lahenduse tellija ja nendepoolsed esindajad, projektijuht, analüütikud, testijad ning ka arendajad peaks väga täpselt olema süvenenud lisaks oma tööle, ka üksteise töösse. Kommunikatsioon, läbipaistvus, kvaliteedi tagamine ja lõppkasutajale väärtuse loomine on vaid mõned märksõnadest, mida Meelis Lang oma loengus mainis. Kõige olulisemaks ise pean kommunikatsiooni, millele Hr. Lang otseselt ei toetunud, aga oma loengu algusminutitel ära mainis. Usun, et tihe osapooltevaheline suhtlus on tähtis, kuna selle puudumise tagajärjel on suur risk, et tekivad möödarääkimised, skoobist mööda arendamine ja olulise mitte tähelepanek. “Hakka rääkima, et ma sind näeksin”, olevat öelnud Sokrates ning see väide sobib esile tuua ka agiilse arenduse protsesside iseloomustamiseks, et tagada projekti ajal pidev läbipaistvus ja ühine arusaam.
Nimetatud agiilsus peaks väljenduma kõigi projektist osavõtvate isikute puhul. See tähendab, et lahenduse tellija ja nendepoolsed esindajad, projektijuht, analüütikud, testijad ning ka arendajad peaks väga täpselt olema süvenenud lisaks oma tööle, ka üksteise töösse. Kommunikatsioon, läbipaistvus, kvaliteedi tagamine ja lõppkasutajale väärtuse loomine on vaid mõned märksõnadest, mida Meelis Lang oma loengus mainis. Kõige olulisemaks ise pean kommunikatsiooni, millele Hr. Lang otseselt ei toetunud, aga oma loengu algusminutitel ära mainis. Usun, et tihe osapooltevaheline suhtlus on tähtis, kuna selle puudumise tagajärjel on suur risk, et tekivad möödarääkimised, skoobist mööda arendamine ja olulise mitte tähelepanek. “Hakka rääkima, et ma sind näeksin”, olevat öelnud Sokrates ning see väide sobib esile tuua ka agiilse arenduse protsesside iseloomustamiseks, et tagada projekti ajal pidev läbipaistvus ja ühine arusaam.


Kommunikatsiooni kõrval tähtsuseks järgmiseks peab projektmeeskond aru saama loodava lahenduse väärtusest. Hoolimata äriotsustest ja tehnoloogiaotstustest, tuleks alati silmas pidada sihtgruppi - inimesi, kelle jaoks loodakse midagi, mis nende elu kergemaks teeb, olgu see töötegemist efektiivsemaks muutev või eraelule lisamugavust andev lahendus. Väärtuse loomise sõnumile keskendusid oma loengus "Tarkvaraarendus - teooria ja tegelik elu" Mait Poska ja Sven Peekmann. Netgroupi tarkvaraarendusjuhi Sven Peekmanni mainis, et äärmiselt oluline on, et igal arendusmeeskonna liikmel oleks huvi aru saada loodava lahenduse ärilisest poolest. Olen temaga nõus ja usun, et tähtis on ka selle kõrvalt näidata välja proaktiivsust - arendajana välja pakkuda oma ideid, kuidas lõppkasutajate kogemust mugavamaks teha. Selle rakendamiseks soovitas Hr. Peekmann arendajate kaasamise projekti kohtumistele, kus saavad kokku äripool ning IT-pool.
Kommunikatsiooni kõrval tähtsuseks järgmiseks peab projektmeeskond aru saama loodava lahenduse väärtusest. Hoolimata äriotsustest ja tehnoloogiaotstustest, tuleks alati silmas pidada sihtgruppi - inimesi, kelle jaoks loodakse midagi, mis nende elu kergemaks teeb, olgu see töötegemist efektiivsemaks muutev või eraelule lisamugavust andev lahendus. Väärtuse loomise sõnumile keskendusid oma loengus "Tarkvaraarendus - teooria ja tegelik elu" Mait Poska ja Sven Peekmann<ref name="loeng1">[http://www.itcollege.ee/blog/2016/03/10/it-kolledz-kutsub-avalikule-loengule-agiilse-arenduse-psuhholoogia-ja-dna/ Mait Poska ja Sven Peekmann "Tarkvaraarendus – teooria ja tegelik elu" ]</ref>. Netgroupi tarkvaraarendusjuhi Sven Peekmanni mainis, et äärmiselt oluline on, et igal arendusmeeskonna liikmel oleks huvi aru saada loodava lahenduse ärilisest poolest. Olen temaga nõus ja usun, et tähtis on ka selle kõrvalt näidata välja proaktiivsust - arendajana välja pakkuda oma ideid, kuidas lõppkasutajate kogemust mugavamaks teha. Selle rakendamiseks soovitas Hr. Peekmann arendajate kaasamise projekti kohtumistele, kus saavad kokku äripool ning IT-pool.


Agiilse arendusmetoodika edukal rakendamisel on väga oluline roll retrospektiivil, millest rääkis oma loengus Meelis Lang. Olen üllatunud, et sellest protsessist Netgroupi esindajad oma etteastes palju juttu ei teinud ja seda eriti seetõttu, et retrospektiivi teostamine oli Helmese tarkvaraarendusjuhi üks põhilisi soovitusi SCRUM’i ja agiilse metoodika kasutuselevõtmise puhul. Ta soovitas alustavatel ning ka juba kokku töötanud meeskondadel iganädalaseid retrospektiive teha kas kliendi, arendusmeeskonna või läbivalt terve ettevõttega, et lahendada probleeme ning jõuda lõpuks täisagiilsuseni. Retrospektiiv on väga tihti üks nendest protsessidest, mida tehakse lihtsalt protsessi pärast ja mille järgselt ei tehta konkreetseid järeldusi ega muudatusi, et probleeme lahendada. Hr. Lang soovitas selle vasturohuks tegevust, mis seisneb iga retrospektiivist osavõtja puhul suulisi lubadusi teiste kuuldes ja nähes, et parandada probleeme.
Agiilse arendusmetoodika edukal rakendamisel on väga oluline roll retrospektiivil, millest rääkis oma loengus Meelis Lang. Olen üllatunud, et sellest protsessist Netgroupi esindajad oma etteastes palju juttu ei teinud ja seda eriti seetõttu, et retrospektiivi teostamine oli Helmese tarkvaraarendusjuhi üks põhilisi soovitusi SCRUM’i ja agiilse metoodika kasutuselevõtmise puhul. Ta soovitas alustavatel ning ka juba kokku töötanud meeskondadel iganädalaseid retrospektiive teha kas kliendi, arendusmeeskonna või läbivalt terve ettevõttega, et lahendada probleeme ning jõuda lõpuks täisagiilsuseni. Retrospektiiv on väga tihti üks nendest protsessidest, mida tehakse lihtsalt protsessi pärast ja mille järgselt ei tehta konkreetseid järeldusi ega muudatusi, et probleeme lahendada. Hr. Lang soovitas selle vasturohuks tegevust, mis seisneb iga retrospektiivist osavõtja puhul suulisi lubadusi teiste kuuldes ja nähes, et parandada probleeme.
Line 30: Line 30:


:Alates teisest õppeaastast toimuvad kordussooritused  aine toimumisele järgnevas semestris ja järgmise õppeaasta eelnädalal kokku kahel korral.<ref name="KKK9"/>
:Alates teisest õppeaastast toimuvad kordussooritused  aine toimumisele järgnevas semestris ja järgmise õppeaasta eelnädalal kokku kahel korral.<ref name="KKK9"/>


=====Kellega kokku leppida, et kordussooritust teha?=====
=====Kellega kokku leppida, et kordussooritust teha?=====

Revision as of 11:06, 22 October 2016

Õpingukorraldus ja erialatutvustus (I020) aine arvestustöö

Autor: Erik Ehrbach

Rühm: DK14

Esitamise kuupäev: 19.10.2016

Kirjalik töö

Tarvaraarendus on mulle alates keskkooli algusest huvi pakkunud. Tollal kirjutasin oma esimesed HTML failid, mida suure uhkusega veebilehitsejas avasin ja sõpradele näitasin. Nendest hetkedest alates olin kindel, et soovin IT-erialal haridust omandada ja töötada. Nüüd, kuus aastat hiljem olen IT-Kolledžis oma teist infotehnoloogia valdkonna kõrgharidust omandamas ning kogemustepagasisse mahtunud ka 2 aasta jagu elutarkusi digiagentuuri tööst. IT-Kolledž oli loogiline samm edasi, mida olin paar aastat planeerinud ja vaadates veebivahendusel salvestatud avalikke loenguid professionaalidelt, olen selles veendunud.

Esimese IT-kolledži avaliku loengu vaatasin vahetult peale kooli kandideerimist. Loenguks oli Meelis Langi etteaste teemal “Agiilse arenduse psühholoogia ja DNA”[1]. Hr. Langi poolt esiletoodud jutupunktid olid mulle isiklikult väga teemakohased, kuna tööalaselt olen agiilse arenduse protsessidest osa võtnud ja presenteeritud probleemid olid äratuntavad. Loengu käigus rääkis Helmese tarkvaraarendusjuht agiilse arenduse tekkeloost ning ühest suurimast veast selle rakendamisel, milleks on liigne protsessidesse takerdumine. See tähendab, et meeskonnad üritavad väga täpselt järgida protsesside järgimist ilma, et ise oldaks piisvalt agiilsed selle käigus. Isiklikult olen selle väitega sajaprotsendiliselt nõus, kuna olen olnud osa meeskonnast, kus kindlaid osapooli häirivad ja demotiveerivad muutuvad asjaolud ning ei mõisteta loodava lahenduse väärtust lõppkasutaja jaoks.

Nimetatud agiilsus peaks väljenduma kõigi projektist osavõtvate isikute puhul. See tähendab, et lahenduse tellija ja nendepoolsed esindajad, projektijuht, analüütikud, testijad ning ka arendajad peaks väga täpselt olema süvenenud lisaks oma tööle, ka üksteise töösse. Kommunikatsioon, läbipaistvus, kvaliteedi tagamine ja lõppkasutajale väärtuse loomine on vaid mõned märksõnadest, mida Meelis Lang oma loengus mainis. Kõige olulisemaks ise pean kommunikatsiooni, millele Hr. Lang otseselt ei toetunud, aga oma loengu algusminutitel ära mainis. Usun, et tihe osapooltevaheline suhtlus on tähtis, kuna selle puudumise tagajärjel on suur risk, et tekivad möödarääkimised, skoobist mööda arendamine ja olulise mitte tähelepanek. “Hakka rääkima, et ma sind näeksin”, olevat öelnud Sokrates ning see väide sobib esile tuua ka agiilse arenduse protsesside iseloomustamiseks, et tagada projekti ajal pidev läbipaistvus ja ühine arusaam.

Kommunikatsiooni kõrval tähtsuseks järgmiseks peab projektmeeskond aru saama loodava lahenduse väärtusest. Hoolimata äriotsustest ja tehnoloogiaotstustest, tuleks alati silmas pidada sihtgruppi - inimesi, kelle jaoks loodakse midagi, mis nende elu kergemaks teeb, olgu see töötegemist efektiivsemaks muutev või eraelule lisamugavust andev lahendus. Väärtuse loomise sõnumile keskendusid oma loengus "Tarkvaraarendus - teooria ja tegelik elu" Mait Poska ja Sven Peekmann[1]. Netgroupi tarkvaraarendusjuhi Sven Peekmanni mainis, et äärmiselt oluline on, et igal arendusmeeskonna liikmel oleks huvi aru saada loodava lahenduse ärilisest poolest. Olen temaga nõus ja usun, et tähtis on ka selle kõrvalt näidata välja proaktiivsust - arendajana välja pakkuda oma ideid, kuidas lõppkasutajate kogemust mugavamaks teha. Selle rakendamiseks soovitas Hr. Peekmann arendajate kaasamise projekti kohtumistele, kus saavad kokku äripool ning IT-pool.

Agiilse arendusmetoodika edukal rakendamisel on väga oluline roll retrospektiivil, millest rääkis oma loengus Meelis Lang. Olen üllatunud, et sellest protsessist Netgroupi esindajad oma etteastes palju juttu ei teinud ja seda eriti seetõttu, et retrospektiivi teostamine oli Helmese tarkvaraarendusjuhi üks põhilisi soovitusi SCRUM’i ja agiilse metoodika kasutuselevõtmise puhul. Ta soovitas alustavatel ning ka juba kokku töötanud meeskondadel iganädalaseid retrospektiive teha kas kliendi, arendusmeeskonna või läbivalt terve ettevõttega, et lahendada probleeme ning jõuda lõpuks täisagiilsuseni. Retrospektiiv on väga tihti üks nendest protsessidest, mida tehakse lihtsalt protsessi pärast ja mille järgselt ei tehta konkreetseid järeldusi ega muudatusi, et probleeme lahendada. Hr. Lang soovitas selle vasturohuks tegevust, mis seisneb iga retrospektiivist osavõtja puhul suulisi lubadusi teiste kuuldes ja nähes, et parandada probleeme.

Tarkvaraarendusfirmade Helmes ja Netgroup esindajate loengud mõjusid mulle inspireerivalt ning tõid valgust pikka aega mu mõtteis esinenud probleemidele, mis olid seotud agiilse arendusmetoodikaga. Sain nendest loengutest motivatsiooni ning häid juhiseid edasiseks toimimiseks nii tööalaselt kui ka enesetäiendamise perspektiivist.

Õpingukorralduse küsimused

Küsimus B

Kukkusid arvestusel läbi. Kaua on võimalik arvestust järele teha? Kellega kokku leppida, et kordussooritust teha? Kuidas toimub kordussooritusele registreerimine? Mis on tähtajad? Kui palju maksab, kui oled riigi finantseeritaval (RF) õppekohalkohal? Kui palju maksab, kui oled tasulisel (OF) õppekohal?

Kaua on võimalik arvestust järele teha?
Esimesel õppeaastal toimuvad kordussooritused aine toimumise semestris, aine toimumisele järgnevas semestris ja järgmise õppeaasta eelnädalal kokku vähemalt kahel korral – kui tudeng kolledži poolt väljapakutud ajal kordussooritustel ei osale või sooritused ebaõnnestuvad, tuleb aine läbimiseks seda korduvalt deklareerida.[2]
Alates teisest õppeaastast toimuvad kordussooritused aine toimumisele järgnevas semestris ja järgmise õppeaasta eelnädalal kokku kahel korral.[2]


Kellega kokku leppida, et kordussooritust teha?
Kordusarvestuse läbiviimise viis sisaldub aineprogrammis, mis tehakse õppuritele teatavaks õppetöö alguses.[3] Kordussoorituste ajakava avaldatakse õppeinfosüsteemis.[4]
Kuidas toimub kordussooritusele registreerimine?
Kordussooritusele regristreerumine toimub läbi ÕIS-i, klikates enda andmete lehel lingile “Kordussooritused”.[4]
Mis on tähtajad?
Loe vastust küsimusele Kaua on võimalik arvestust järele teha?.
Kui palju maksab, kui oled riigi finantseeritaval (RF) õppekohalkohal? Kui palju maksab, kui oled tasulisel (OF) õppekohal?
RE/RF õppekohal oleva tudengi jaoks on kordussooritusel osalemine tasuta. REV/OF õppekohal õppival õppuril tuleb maksta kordussoorituse tasu 20 €.[4]


Küsimus 1

Teisel või kolmandal õppeaastal avastad, et teine õppekava sobib paremini ja sa otsustad õppekava vahetada. Millised on tegevused ja mis ajaks tuleb need teha, et vahetada õppekava? Kas deklareeritud, kuid tegemata jäänud valikaine tuleb kolledži lõpetamiseks tingimata sooritada? Millega pean arvestama, deklareerides valikaineid üle õppekavas ette nähtud mahu (sh. deklareeritud, kuid sooritamata jäänud valikained)?

Millised on tegevused ja mis ajaks tuleb need teha, et vahetada õppekava?
Õppekava saab vahetada kaks korda õppeaastas enne akadeemilises kalendris märgitud semestri punase joone päeva.[5] Eesti Infotehnoloogia Kolledži-sisese akadeemilise liikumise puhul tuleks kirjutada vabas vormis kirjalik avaldus õppeosakonda rektori nimele hiljemalt 1 päev enne punase joone kuupäeva. Antud avalduses peaks olema esile toodud ka nimekiri õppesooritustest, mille arvestamist uue õppekava osana taotletakse.[6] Külalisüliõpilaseks kandideerijal (ehk EIK-välise akadeemilise liikumise puhul) tuleb esitada EIK õppeosakonda hiljemalt 1 tööpäev enne semestri punase joone päeva vormikohane avaldus-ankeet, tõend teises kõrgkoolis õppimise kohta, 1 dokumendifoto ning ID-kaart või pass.[7]
Kas deklareeritud, kuid tegemata jäänud valikaine tuleb kolledži lõpetamiseks tingimata sooritada?
Deklareeritud, kuid tegemata jäänud valikaine puhul ei ole selle kindla valikaine edukas läbimine kolledži lõpetamise eelduseks. Oluline on, et õppekavale määratus mahus valikaineid oleks tehtud.[8] Mahu saab vajadusel täidetud, kui võtta teisi valikaineid.
Millega pean arvestama, deklareerides valikaineid üle õppekavas ette nähtud mahu (sh. deklareeritud, kuid sooritamata jäänud valikained)?
Deklareerides tuleb arvestada, et nominaalmahtu ületatavate õpingute eest esitatakse õppemaksu arve.[8]


Ülesanne

Kui mitme EAP ulatuses tuleb õppekulud osaliselt hüvitada aasta lõpuks, kui esimese semestri lõpuks on olemas 28 EAPd ja teise semestri lõpuks 25 EAP? Kui suur on teile esitatav arve?

Õppekulude osalise hüvitamise kohustuse (vt. ÕKE p. 1.2.19) tekkimise aluseks oleva õppekava täies mahus täitmise määr on vastavalt Eesti Infotehnoloogia Kolledži nõukogu otsusele (protokoll nr 3C-1/13-2, 27.02.2013) 2016/2017 õppeaastal 27 EAP semestris ja õppekulude osalise hüvitamise määr on 50 € 1 EAP kohta[9] ja õppekulude osalisele hüvitamisele kuuluva summa arvutamine käib kumulatiivselt [10].
Arvutus:
Miinimum vajalik EAP'de arv semestris: 27
1. semester: 27 - 28 = -1 EAP ehk miinimum on ületatud ja 1. semestri lõpus arvet ei esitata
2. semester: 54 - (28+25) = 54 - 53 = 1 EAP ehk kahe semestri peale kokku on kogutud alla miinimumi.
Hüvitamisele kuulub: 1 EAP
Maksma peab: 1*50 = 50€

Viited