View source for Tänapäeva trendid IT arendusmetoodikates ja -protsessides


== Sissejuhatus ==

IT lahendused ja tehnoloogia tervikuna on oma suhteliselt lühikese ajaloo jooksul teinud läbi metsiku arengu. Süsteemide keerukus on kordades kasvanud, süsteemidel on üha laiem kasutajaskond ning sellest tulenevalt ka erinevate süsteemi funktsionaalsused ja nende rakendused on laienenud. Mistahes probleemi lahendamisel vaadatakse alati ka IT ja tehnoloogia poole. Selline kasv aga seab omakorda  üha suurema surve ja kõrgemad ootused tehnoloogia veel kiiremale arengule ning uute lahenduste realiseerimise ja juurutamise kiirusele. Ootustele vastamisest on seetõttu juba toimunud ja ka jätkuval  toimumas olulised muutused selles, kuidas teha tööd muutlikus ja nõudlikus taustsüsteemis võimalikult efektiivselt ja optimaalselt ning kuidas maksimaalselt maandada riske mis seonduvad IT lahenduse, eriti tarkvara lahenduste abstraktsusest. 
	
	Muutused selles, kuidas erinevaid IT lahendusi luuakse, on toimunud väga erinevast tahkudest vaadatest. Esiteks on kindlasti oluline välja tuua, et suured muudatused on toimunud mõttemallides ning metoodikates, mida kasutatakse inimeste töö korraldamisel ning tööde igapäevasel teostamisel.  Teine aspekt on aga igasugused erinevad tehnoloogiad ja töövahendid, mida kasutatakse, et uusi lahendusi realiseerida või välja töötada. Töövahendina võime siin mõelda ka vahendeid, mis on vajalikud ühe või teise metoodika rakendamiseks. Kolmandaks on toimunud olulised muutused inimeste rollides ja vastutusalades ja ootustes nendele, kes uusi süsteeme realiseerivad. Neid aspekte ja muutuseid antud artiklis vaatleme lähemalt. 


== Kose meetodite asendamine agiilsete meetoditega [3]  ==

Esimene aspekt, mida lähemalt vaatleme on seotud inimeste mõtteviisi ja mallidega. Siinkohal võiks esimesena välja tuua selle, et toimunud on oluline areng tehnoloogia ja inimeste ning organisatsioonide koostöös. Teisisõnu on mõistetud, et IT ei ole midagi eraldiseisvat ja eesmärk omaette, vaid teenib alati kas inimese või organisatsiooni huve. IT-d ning tehnoloogiat laiemalt õigesti rakendades on võimalik enda kasuks tööle panna väga võimas ressurss ning luua seeläbi olulist lisaväärtust kas endale või organisatsiooni klientidele. Koostöö paranemisest ja niiöelda “IT ja äri” lõimumisest annab märku see, et nii kooli õppeprogrammide kui erinevate organisatsioonide IT osakondades rõhutatakse seda, kuivõrd oluline on esmalt aru saada, mida ja miks hakatakse tegema, ennem realiseerimist. Samuti on näha trendi, et kõikidele IT lahenduste loomises osalevatele rollidele on kõrgem ootus mõista äriloogikat ning äri vajadusi. Mida tihedam on koostöö ja üksteise mõistmine IT ja äri vahel, seda parem on aga ka loodatavate lahenduste kvaliteet ning nende loodav väärtus. 

Teine ja kergemini hinnatav ja tuvastatav muutus on aga toimunud IT lahenduse loomisel kasutavates töövahendites ja metoodikates. Ja need muutused on toimunud mitte ainult mõne konkreetse rolli, vaid jällegi kõigi loomisprotsessis osalevate inimeste jaoks. Metoodikatest rääkides on suurim muutuse trend, liikumine klassikalistelt kose projektijuhtimise metoodikatelt agiilsemate tööviiside poole. Agiilsus on samuti tihedalt ja võibolla isegi peamiselt seotud mõtteviisi muudatustega, kuid agiilsete põhimõtete rakendamine on nõudnud ka hoopis teisi töövahendeid. Agiilsete metoodikate rakendamine kas osaliselt või täielikult on innustatud sellest, et võimalikult varakult aru saada, kas loodav lahendus on õige, kas see annab oodatud väärtust ning kas tellija ja teostaja saavad üksteisest ühtemoodi aru. See omakorda aitab aga hoida kokku kulusid ja maandada riske, sest isegi kui on tehtud vigu või töö käigus selgub, et vajadus on muutunud, siis ei ole teostatud iteratsiooni kulud nii kõrged kui need oleksid nt suure ja viimistletud infosüsteemi loomisel. Ehk võrreldes varasemalt kasutuses olnud kose metoodikatele, kus tööd teostatakse järjestikkuste faaside kaupa ning töö tulemusi näeb pahatihti liiga hilja, annab agiilne metoodika kiirema tagasiside ning võimaluse tehtud vigu ja möödapanekuid madalamate kuludega korrigeerida. 

Agiilsete metoodikate kasutamine on kas otseselt või kaudselt toonud kaasa ka muudatused kasutatavates töövahendites. Näiteks võib täheldada, et suuremahulisi ja keeruliste seostega projektiplaane luua võimaldavad projektijuhtimise tarkvarad on IT valdkonnas kaduv nähtus. Tihtipeale eeldavad need töövahendid aga kulukaid litsentse ning võimaldavad loodud plaane ja ülesandeid kasutada ainult piiratud seltskonnal inimestest. Näiteks MS Projectis loodud projektiplaani haldamiseks ja täieliku ülevaate saamiseks peab olema kas MS Project arvutisse installitud või peab projektijuht tegema pidevalt ajakohaseid väljavõtteid.  Peale selle on info ajakohasena hoidmine tihtipeale väga ajakulukas ning seetõttu hakkab pärssima põhieesmärki - luua võimalikult kiirelt uusi ja väärtust loovaid lahendusi. Selle asemel kasutatakse töövahendeid, mis võimaldavad jagada infot kõigile huvilistele (tellija ja teostav meeskond) ning hinnata progressi ja teha planeerimist minimaalse vaevaga. Siin võib näitena tuua Atlassiani tööriistad oma lisamoodulitega, kuid kõiksugu töövahendid, mis võimaldavad hoida plaane ajakohasena ning kättesaavana kõigile huvilistele, on teretulnud. 



== Klassikalise IT halduse muutused Dev-Ops tiimide suunas ==
	
	Suure arengu viimasel ajal on ka teinud DevOps, optimeerides ja seega kiirendades programmi arengut. Nagu iga teine projekt saab alguse ideest, olgu see siis, kas ettevõtte sisene või tellib selle keegi väljastpoolt. DevOps on kooslus suuresti agiilsest arendusest, automatsioonist, “hooldusperioodist” jpm’st. DevOps’i idee on tuua arendustöö kokku, nt IT haldus ja arendus, või arendus ja finants jne… Seega ükski vajaminev osakond ei jää arendusprotessist kõrvale. Suur roll DevOps’is on ka IT süsteemiadministraatoritel, kes lõpuks välja arendatud toodet elus hoiavad ja tagasisidet annavad. 
DevOps’i juurutamine võtab aega, kuid seda võib ka öelda kõige kohta ettevõtetes. Soovituslik on alata väikeste tükkidena, näiteks, esimesena võtta proovida saada terve tiim paremini ühise tulemi jaoks tööle panna. Seegi nähtavalt lihtne asi vajab ka päris pikka aega, et täis efektiivsuseni jõuda. Ning seejärel uue osa juurutamisega alustada ja läbida sama protsess. 
Suur osa DevOps’is on ka automatsioon. Nimelt arenduses olev programm läbib pidevalt automaatteste, et valideerida kas programm vastab sellele, mida talt oodatakse, kas ta on piisavalt turvaline. See on ka üks suur boonus, kuna arvutid suudavad teste rohkem ja kiiremini läbi viia, siis leitakse probleemid kiiremini üles ja arendustiim saab koheselt sellele reageerida ja probleemid ära kõrvaldada. Ning kui kõik testid on läbitud, pannakse kokku “lõplik” pakk. Seejärel algab kogu protsess uuesti. Hakatakse uuesti planeerima, arendama, pannakse pakk kokku, mis seejärel hakkab “production” liinil tööle, kust tuleb ka tagasiside, et mida ja kuidas edasi arendada jne... Et DevOps saaks korralikult töötada, tuleb seda pidevalt jälgida. Seega vaadatakse pidevalt, kui kaua arendustöö aega võtab, kuni see töövalmis on. Ning sealt vigadest õppida ja väikesed muudatused/optimeerimised sisse viia. Ei vaada mitte ainult, kui kaua mingiarenguperiood kestab, vaid vaadatakse ka seda kui tihti mingi probleem esines ja kui kiirelt sellest jagu saadi. Minnakse isegi nii kaugele, vaadata kui paljud seda toodet üldse kasutavad. Seega saadakse hinnata, kui palju rõhku ja ressurssi peaks sinna projekti alla panema. [1]



== Projektijuhtimisesest tootejuhtimise suunas ==

Üha enam on IT arendusmaailmas kuulda sõna tootejuhtimine ning võiks ju kohe mõelda, et on silmas peetud projektijuhtimist. Paraku on tootejuhtimine veel midagi suuremat, kui projektijuhtimine. Peamine erinevus nende kahe vahel on see, et projektil on kindel eesmärk ning kindlaks määratud algus- ja lõpukuupäev. Tootel aga teisest küljest on oma elutsükkel, mis kestab nii pikalt, kuni toodet enam ei vajata ning see kaob turult.  Toode võib olla mingi tarkvara või teenus kuni miks mitte ka mõne füüsilise käega katsutava objektini välja. Kõik algab kliendi vajaduste väljaselgitamisest ning arendusest ning lõppeb alles siis, kui lõppkasutajaid ei ole piisavalt, et asja elus hoida. Teisest küljest, nagu ka juba mainitud on projektidel oma kindel eesmärk ning lõpp-punkt, kus võib õelda, et antud projekt on nüüd sooritatud. Samas võib tootejuhtimine endas sisaldada mitmeid projekte. Arenduses on aga üha enam tarvilik tootejuhtimine, sest terve toote eluea jooksul tuleb hoida toode või tarkvara ajakohane ning turvaline. Ajakohasuse juures pean silmas seda, et tarkvara oleks võrreldav ka teiste turul olevate alternatiividega. Näiteks tänapäeval ei ole võimalik (kui just idee ei ole metsikult hea) läbi lüüa 2010 aastal loodud veebilehtedega. Ka arendusplatvormid muutuvad, tekib juurde võimalusi jne. Lisaks mainisin turvalisust – tarkvaras leidub alati mitmeid turvaauke, mida tuleb parandada. Kui miski on aktiivselt arenduses, tekib pidevalt juurde ka buge ning turvaauke. Tihtipeale kutsutakse tootejuhte antud toote CEO’ks, ehk põhimõtteliselt saaks pidada tootega tegelevat tiimi omamoodi ettevõtteks.
 
Projektijuhid on projekti tagajärgede, ehk projekti eesmärgi eest suuresti vastutavad. Nad juhivad toote või teenuse arengut olemasolevate ressursside (sh projekti meeskonna) abil. Projektijuht annab meeskonnale ülesandeid, vahendid ja prioritiseerib projekti kulgu vastavalt sätestatud ajalistele ning materiaalsetele piirangutele.
 
Tootejuhid see-eest vastutavad klientide rahuldamata vajaduste pideva rahuldamise eest effektiivsel viisil. Tööülesanded sisaldavad lisaks: toote- ja kliendinõuete kogumine ja prioriteetide seadmine, toote visiooni määratlemine tehes tihedat kostööd arendajatega. Tähtis on tagada klientide rahulolu. Tootejuhtimine määratleb strateegilised ärieesmärgid, millest omakorda algatatakse projekte, millega tegelevad projektijuhid. [2]



== Kokkuvõte ==

Põhilised viimase aja trendid IT arendusmetoodikates ja -protsessides on suunatud infotehnoloogide ärianalüüsi ja protsessidesse kaasamises ning juhtimise suurem läbipõimumine IT lahenduste arendusega. Vanamoodne tootearendus kose meetodit rakendades on järjest enam asendunud agiilsete arendusmetoodikatega. See tähendab omakorda ka kliendi / tellija kaasamist arendusprotsessi ning arendajate tihedamat suhtlemist kliendiga. Lõpptulemusena peaksid tänapäevases agiilses arenduses kogu protsessi vältel kõik osapooled omavahel varasemast palju sagedamini suhtlema, et täpsustada tellija vajadusi ning kooskõlastada neid tarkvara arendajate võimetega ja sellise koostöö läbi projekt eduka lahenduseni juhtida. Sedamoodi arendusmetoodikaid toetavad ka järjest põhjalikumad arenduskeskkonnad ja muud paindlikumad töövahendid.

Agiilsete metoodikate üks enim mainitud eeliseid traditsioonilise kose meetodil arenduse ees on palju odavam vigade parandus. See tuleneb kõigi huvitatud osapoolte tihedast suhtlusest, mille läbi on võimalikke probleeme palju lihtsam arenduse varasemas faasis ennetada ja parandada. Kose meetodi rakendamisel läheb üksteise mittemõistmine väga kalliks, kui tellijale esitatakse IT firma poolt nende mõistes valmis lahendus, mis samas tihtipeale ei vasta ikkagi kliendi ettekujutusele sellest, mida ta tellida tahtis. Sellisel juhul tekivad kulukad vaidlused ning kogu arendus peab suures osas otsast peale hakkama. 

Esmapilgul võisid agiilne arendus ja haldus ning projektijuhtimise asendumine devOps-iga tunduda üksteisest võrdlemisi kauged teemad, aga kokkuvõtteks selgus, et need arengusuunad on rajatud väga sarnastele printsiipidele. Võib üldistada, et varasemalt tellis klient firmalt IT lahenduse ning veidi utreeritult andis projektijuht selle sama ülesande infotehnoloogidele arusaadavamas keeles tarkvaraarendajatele edasi ning siis peale pikka omaette nokitsemist esitasid arendajad lahenduse projektijuhile kes näitas seda kliendile ning esitas arve. Agiilsetel printsiipidel põhinevas arenduses peavad arendajad palju tihemini pooleliolevat tööd teistele tutvustama ning tagasisidet nõudma, et lahendus vastaks kliendi äriloogikale ning soodustaks vastavaid protsesse. Samuti ei saa erinevalt projektijuhi tööst DevOps stiilis juhi töö seista eraldi arendusprotsessist ja jätta kliendi äriprotsesside ning vajaduste arenguga arvestamata. Sisuliselt peaks tootejuhtimine kestma kogu antud IT lahenduse elutsükli lõpuni, mil kasutajad enam seda ei vaja. Sealjuures ei öelda enam mingis etapis, et nüüd on projekt valmis ja tellimus täidetud, vaid IT firma peaks osaliselt täitma ka ärikonsultantide rolli ning aitama kliendil ka oma ootuseid edasi arendama ning äriprotsesse üha rohkem infotehnoloogia abil automatiseerida. 



�

== Kasutatud kirjandus ==

[1] What Is DevOps?, kasutatud 15.05.2019, https://www.atlassian.com/devops
[2] Project Manager vs Product Manager, külastatud 14.05.2019 https://brainmates.com.au/brainrants/project-manager-vs-product-manager/
[3] How to Manage Modern Software Projects: Waterfall vs. Agile
https://medium.com/@lizparody/waterfall-vs-agile-methodology-in-software-development-1e19ef168cf6