Kolmteist ja reede - Scrumban ja Raamleping

Scrumban

Mina puutusin kokku Scrumban-iga arvatavasti ebatraditsioonilisel moel. Viimasel ajal on paljud kliendid end harinud või siis kopeerivad selliseid nõudeid arendustele, nagu "Agiilne arendus", vahest ka täpsemalt tahetakse SCRUM-i.

SCRUM-i kasutamine pikemates projektides põrkub aga pahatihti planeerimisprobleemidega. Hange on tehtud pikaks ajaks, võiks öelda, et koskmeetodil "selle funktsionaalsuse jaoks on meil kokku lepitud nii palju raha" ja väga tihti tahetaksegi saada selel valmimise täpset ajakava väga pikaks ajaks, näiteks kaheks aastaks või pikemaltki. Minu arvates läheb see vastuollu agiilse arenduse sisuga, kus iga sprindi tulemused lepitakse eraldi kokku ja seetõttu on pikemaid plaane raske pidada. Oma esimeses SCRUM-projektis hakkas seetõttu valmimistähtaeg pidevalt kaugesse tulevikku liikuma algsest plaanist.

Aga mitte SCRUM-ist ei tahtnud ma rääkida. Ühel järjekordsel sisekoolitusel tutvustati muu hulgas ka Kanban-i arendusmudelit, millest mina lugesin välja eelkõige tööde prioritiseerimise. Sellega sai SCRUM-i mudelit selliselt tuunida, et Tellija pidas seda vajalikuks SCRUM-iks, aga efektiivsus kasvas Kanban-ist pärit meetoditest. Võiks öelda, et see oligi meie jaosk SCRUM. Saime oma Backlogi haldamisse vajaliku osa - prioritiseerimise. Või oli see BANSCRUM ? SCRUM, mida on täiendatud mõningate Kanban elementidega, jäädes siiski Tellia valitud arendusmudeli SCRUM  juurde. 

Tegelikult tegin ma selle kaudu endale selgeks, et arendamine saab olla palju peenhäälestatum kui mingid metoodikad seda suudavad pakkuda. Juba enne projekti tuleks kontrollida üle kliendi haldusvõimekus ja mugandada projekti tulemeid vastavalt sellele. Liiga keerulised dokumendid võivad oluliselt pidurdada arendusprotsessi, liiga pealiskaudses aga võivad olulised nõuded arendusele üldse välja jääda või kirjeldatud liiga hilja.

Kokkuvõtteks võib öelda, et ärge olge kinni mingites konkreetsetes arendusmudelites, vaid püüdke leida nendest selline kooslus, mis ühelt poolt tagaks afektiivse arenduse ning samal ajal oleks ka ülevaatlik ja hallatav. 

Raamleping

Loengumaterjalides loetletud ärimudelites ei leidnud ma selliseid, mida meie ettevõte kasutab. Meie ettevõttel on kaks põhilist ärimudelit, üks on projektipõhine fixed price mudel , kus Tellija kirjeldab hankedokumendis, mida ta tahab saada ja erinevad pakkujad püüavad selle alusel hinnata, kui suur töömaht ja rahahulk selle arendamiseks vajalik oleks. Selle mudeliga esineb probleeme, kus üks pakkuja pakub tunduvalt alla reaalse võimaliku ja püüab hiljem raha juurde kaubelda hanke dokumentatsiooni lisakeerukuse arvelt. Tellijatele see aga ei meeldi, seetõttu on tugevamad Tellijad hakanud koostama raamlepinguid mitme tunnustatud arendusettevõttega, kelle taust on neile teada, kus lepitakse kokku erinevate tööde (analüüs/disain/programmeerimine/projektijuhtimine jne) tunnihinnad ja konkreetne pakkumus tehaksegi minikonkursi raames piiratud hulga partnerite vahel töötundides. Tulemus on paljudel juhtudel parem, kuigi ka seda ärimudelit saaks ilmselt oluliselt efektiivsemaks muuta. Mõlema mudeli puhul tehakse Tellijale nö rätsep-lahendus, mille kõik õigused lähevad üle Tellijale. Tootega kaasneb tavaliselt ka 6-kuuline garantii. Standartsed arendusega kaasnevad reeglid partnerite vahel aitavad Raamlepingu arendusmudelit oluliselt efektiivsemana hoida kui Fixed Price mudeli puhul. Samuti on paremini kaetud projekti ebaõnnestumise riskid.