Arendus- ja ärimudelid

Nii arendusmudel kui ka ärimudel on tänapäevaste IT-projektide olulised osad. Tavaliselt tehakse konkreetse mudeli kasutamise otsus enne projekti kallale asumist, nii et peate eelnevalt teadma, milline mudel sobib teile, selle plussid ja miinused. Seetõttu on tänase ajaveebi teemaks ühe tarkvaraarendusmudeli ja ühe ärimudeli analüüs konkreetse projekti näitel.

Arendusmudel - Scrumban

Scrumban on arengumudel, mis on loodud Scrumi ja Kanbani parimate aspektide ühendamisel. Scrumbanist võin rääkida projekti näitel, milles ise osalesin. Ja nüüd väike taust. Eelmisel aastal õppisin juba informaatika eriala (IAIB) esimesel kursusel Tallinna Tehnikaülikoolis. Ja teisel semestril oli meil programmeerimise põhikursuse raames projekt. Õpilased jagunesid võistkondadesse ja iga võistkond pidi tegema oma mängu. Ja lisaks mängu enda nõuetele olid meil teatud nõuded ka planeerimis- ja arendusprotsessile, tolajal ma ei teadnud seda nimetust veel, aga nüüd saan aru, et meid aeti töötama Scrumbaniga väga sarnase mudeli järgi.

Meil olid õppejõud, kes esindsid "kliendi häält". Ning ka oli mentor, kes jälgis Scrumbani põhimõtete järgimist ja juhendas meid, aitas probleeme lahendada. Ja arendusmeeskonna rollis olime ise.

Minu arvates on Scrumban üsna tõhus arengumudel. Tööaja jagamine lühikesteks sprintideks, mis meil kestis kaks nädalat, igaüks oma põhiülesannetega. See võimaldab arengutempot paremini juhtida ja meeskonnal on pidevalt mingi konkreetne eesmärk.

Pärast sprindi arendusfaasi lõppu tehakse järeldused töö õnnestumise kohta, tehakse retro, milles tuuakse välja töö käigus tekkinud probleemid ja otsitakse lahenduse, mis aitab järgmisel sprindil selliseid probleeme vältida. Oma vähese kogemuse põhjal ütlen siiski, et kõiki probleeme pole alati võimalik leida ja lahendada, selleks on meeskonnaliikmete hea suhtlemistasand väga oluline. Kuid isegi kui on võimalik lahendada vähemalt väike osa probleemidest, parandab see oluliselt arenduskvaliteeti.

Aga nüüd veidi tagasi, sprindi ülesannete juurde. Need ülesanded jagunevad omakorda väikesteks ülesanneteks ja saadetakse ühisesse ülesannete kogumisse ning iga arendusmeeskonna liige saab valida ülesande, mida ta saab kõige tõhusamalt täita. Üsna kasulik, töö saab effektiivsemalt tehtud, kui see on jagatud väikesteks osadeks. Kuid on vaja kehtestada piirangud iga meeskonnaliikme jaoks võetud minimaalsele arvule ülesannetele, sest näiteks oli meil probleem sellega, et liikmed ei töötanud võrdselt, keegi võttis ülesannete kogumist rohkem ülesandeid, keegi vähem.

Kui kõik need etapid on lõpule jõudnud ja sprint on suletud, toimub demo. Kliendile või "kliendile" kuvatakse projekti hetkeseis. Kui saab juba midagi näidata, siis valmistatakse ette programmi demoversiooni. Pärast seda väljendab klient oma arvamust ning soove ja nõudeid edasiseks projekti arenguks. Sellele järgneb järgmise sprindi kavandamine, eesmärkide püstitamine ja ülesannete loomine ning siin lõpeb vana sprint ja algab uus.

Samuti tahan öelda, et on väga oluline projekti eelnevalt läbi mõelda, näha, milleni lõpuks jõuda soovite. Vastasel juhul võite silmitsi seista probleemiga, et ühes hilisemas sprindis saate aru, et teil oli midagi kohe alguses puudu ja nüüd on seda väga keeruline projekti integreerida, kuna seal on vaja palju ümber teha. Nii oli ka meiega, kui arenduse teises pooles saime aru, et oleme välja mõelnud sellise mängukoodi struktuuri, millesse me ei osanud multiplayer'i integreerida (aga see oli üks lõpptoote nõue).

Ärimudel - Omandvara koos riistvaraga ehk Tervikplatvorm

Siin on minu näide Sony PlayStation. Oma mängukonsoolide puhul omab Sony täielikult riist- ja tarkvara ning opereerib neid. Kolmandate osapoolte arendajad võivad ainult mänge ja multimeediarakendusi levitada Sony PlayStationi digitaalses poes. Neil pole võimalust levitada programme, mis kuidagi muudaksid süsteemitarkvara, konsooli kasutajaliidese välimust või selle funktsionaalsust. Seda kõike kontrollib Sony. Ühest küljest on see hea, sest konsoli arendamisega tegeleb spetsialistide meeskond, kes tunnevad seda seadet ning teevad oma tööd kindlasti hästi. See jätab aga kasutajad valikuteta ja võib isegi jätta mulje, et te ei ostnud konsooli, vaid rentisite, sest midagi ei saa muuta. Ja tarkvara muutmise katse eest võib konsool igaveseks kaotada ühenduse Sony võrguteenustega.

Samuti kontrollib Sony väga hoolikalt kõiki uusi mänge ja kõiki arendajaid, enne kui lubab mängu oma poes avaldada (ja seega põhimõtteliselt ka PlayStationile avaldada). Selline kontrollimistase on kahtlemata kasulik, sest tänu sellele PlayStationi mängupoes pole nii palju kasutuid ja halbu mänge (autor ei taha kedagi solvata, ükski mäng on raske töö ja loovus), kui näiteks Steamis. Kuid selline lähenemine vähendab loomevabadust.

Ka seda, kes kontrollib kogu oma platvormil olevat tarkvara, takistades alternatiivsete rakenduste poodide loomist, võib mingil määral nimetada tema platvormi monopolistiks. Toon siinkohal teise näite - hiljutine skandaal ja kohtud Apple'i ja Epic Games'i vahel, kus Epic Games kaebas AppleStore'i liiga kõrge komisjonitasu mängude ja rakenduste müümise ning mängusiseste ostude eest. Tõepoolest, selgub, et kuna Apple ei luba iPhone'is AppleStore'ile alternatiivi luua, võib see nõuda mis tahes komisjonitasu maksmist ja mingil põhjusel ei reguleeri monopolidevastased seadused seda kuidagi.

Kuid tervikplatvormil on veel üks pluss - eksklusiivsed rakendused, mis on tavaliselt paremad kui mitmeplatvormilised. Ja siin tuleme tagasi PlayStationi juurde, mille jaoks luuakse eksklusiivseid mänge, ning tänu sellele, et arendajad on selgelt teadlikud kõigist konsooli funktsioonidest, ning ka seetõttu, et neil pole vaja kulutada aega mängude teistele platvormidele teisaldamiseks, saavad nad paremini keskenduda kvaliteedile ja kasutada konsooli võimalusi nii palju kui võimalik.

Kokkuvõtte

Nii arendusmudel kui ka ärimudel on olulised ning need määratakse projekti arendamise suuna ja eesmärgi järgi. Peamine on alati teha õige valik, lähtudes antud valiku variantude tugev- ja nõrk külgetest.