Millist agiilse arenduse raamistikku valida ehk Scrumist Scrumbanini

2024. aastal kasutab üle 86% tarkavaraarenduse firmadest toodete ja teenuste loomisel agiilset lähenemist. Meetod on laienemas kiiresti ka teistesse valdkondadesse - näiteks turundusse, tervishoidu, haridusse ja isegi ehitusse - kus on vaja projekte efektiivselt teostada. 

 

Agiilne lähenemine erineb traditsioonilisest oma väärtuste poolest, mis on üles loetletud 2001.aastal kokku pandud Agile manifestos. Kokkuvõtlikult võib öelda, et see meetod põhineb paindlikkusel, kiirel reageerimisel muutustele ja tiimide koostööl. Meetodi rakendamine aitab luua erinevaid lahendusi efektiivsemalt ja kvaliteetsemalt ning tagada, et lõpptulemus vastaks paremini klientide või kasutajate vajadustele. 

 

Agiilses maailmas on erinevaid raamistikke, mis seda mõtteviisi rakendavad. Kõige populaarsemad on Scrum, Kanban ja nende kombinatsioon Scrumban. Igal raamistikul on oma lähenemine, mis sobib erinevat tüüpi projektide läbiviimiseks vastavalt nende olemusele. Järgnevalt selgitame lahti kolme populaarseima raamistiku olemused ja toome välja nende omadused, et aidata sul teha oma projektile parim valik.

 

 

Mis on Scrum?

Scrum on üks esimesi agiilseid raamistikke, mis põhineb tiimide tihedal koostööl kasutajatega. Scrum raamistiku esimene versioon arenes välja 1980. aastatel - seega enne kui sai defineeritud agiilne meetod.

 

Agiilsetest raamistikest on see hetkel populaarseim - seda kasutab umbes 66% agiilset lähenemist kasutatavatest ettevõtetest. Scrumi põhimõtted on koostöö, järkjärguline (iteratiivne) projekti edenemine ning muutustega kohanemine. 

 

Tööd viiakse läbi tsüklitena (sprindid), mis koosnevad väikesteks töödeks tükeldatud funktsionaalsustest ja iga tsükli lõpuks valmib vähemalt üks uus kasutatav osa terviklahendusest (inkrement). Scrumi olemus on defineeritud Scrumi juhendis (Scrum guide). Järgnevalt räägime Scrumi olemusest.

 

 

Scrum raamistik

Scrum on kindlalt piiritletud projekti juhtimise raamistik, mis koosneb järgmistest osadest:

 

• kolmest sambast ja viiest väärtusest;
• kolmest rollist;
• kolmest artefaktist;
• viiest sündmusest.

 

Tuleb märkida, et nagu paljudes teistes populaarsetes raamistikes, ei ole ka Scrum raamistikus defineeritud, kuidas tööülesandeid projektis tükeldada või hinnata. 

 

Scrum raamistiku teadmiste tõendamiseks jagavad erinevad akrediteeritud asutused ka sertifikaate. Seda, kuidas Trinidad Wisemani spetsialistid Scrum Master sertifikaate omandasid, saad lugeda meie artiklist „Mis on Scrum Master sertifikaat ja kuidas seda omandada?“

 

Kolm sammast ja viis väärtust

Scrum raamistik tugineb kolmel sambal: läbipaistvus, kontrollimine ja kohanemine. Need aitavad Scrumi tiimil olla pidevalt samas inforuumis, et nad suudaksid tõhusalt reageerida muutustele ja parandada tööprotsesse.

 

Scrum juhendis on defineeritud ka viis väärtust: pühendumus, julgus, fookus, avatus ja austus. Need väärtused rõhutavad koostöö tähtsust ja parima lõpptulemuse saavutamist. 

 

Rollid

Scrumis on defineeritud kolm rolli, mis võivad erineda „tavarollidest“ nagu IT projektijuht, IT tootejuht või arendaja, millega oleme igapäevaselt harjunud. Näiteks jagunevad IT projektijuhti ülesanded Scrumis tooteomaniku ja Scrum Masteri vahel. Scrum rollid moodustavad Scrum tiimi, mis on Scrumi raamistiku keskmeks. 

 

Scrum tiimi suurus on seejuures raamistikus piiritletud – see peab jääma alla 9 liikme, ideaalis teostatakse suured Scrum projektid 7 liikmega. Raamistiku edukaks rakendamiseks peab Scrum tiim olema pühendunud 100% ühele projektile.

 

• Tooteomanik (Product Owner, PO) esindab kasutajat ja määratleb ning haldab toote tööde loendit (product backlog). Ta lisab kasutuslugusid, prioriseerib vastavalt väärtusele, on toote otsuste tegija, tunneb lõppkasutajat ja annab sisendit arendajatele. Tooteomanik võib oma ülesandeid jagada mõne arendustiimi rollis oleva isikuga, kes näiteks teostab analüüsi või kasutajakogemuse disaini.
• Scrum Master (SM) tunneb Scrumi protsessi läbi ja lõhki, õpetab seda tiimile, toetab tiimi ja aitab tiimil nendest takistustest üle saada, mis projekti käigus tekivad. Sisulistes tegevustes Scrum Master otseselt ei osale, samuti ei pea olema Scrum Master-il tehnilist tausta.
• Arendustiim (Developers) on ristfunktsionaalne grupp, kes vastutab toote või teenuse tarnimise eest. Siia kuuluvad lisaks arendajatele ka erinevad teised sisulised rollid - analüütikud, UX-UI disainerid, testijad, spetsialistid jt rollid. Nemad on pühendunud toote loomisele ja otsustavad omavahel, milliseid töid sprindi tööde loendis igaüks teostab.

 

Artefaktid

Scrumi artefaktid on informatsiooni allikad, mida Scrum tiim ja teised kaasatud huvipooled (stakeholder) igapäevaselt toote loomisel kasutavad. Selle juures on oluline hoida põhiinformatsiooni läbipaistvana, et kõik osapooled oleksid kursis toote loomise detailide ja tegevuste ning protsessidega, mis selle käigus toimuvad.

 

• Toote tööde loend (Product Backlog) on prioriseeritud nimekiri kõigist funktsioonidest, täiendustest ja parandustest, mis on toote jaoks vajalikud. Visuaalselt on tööde loendis ülevalpool detailselt kirjeldatud tööd ning allpool kõrgtasemel ideed.
• Sprindi tööde loend (Sprint Backlog) on toote loendist valitud tööd konkreetse sprindi jaoks vastavalt sprindi eesmärgile. Kui sprint käivitatakse, ei tohi selles loendis olevaid töösid enam muuta ega juurde lisada.
• Inkrement (Increment) on potentsiaalselt tarnimiseks valmis osa terviklahendusest, mida sprindi jooksul luuakse.

 

Scrum sündmused

Scrum sündmused (nimetatakse ka tseremooniateks) aitavad arendustiimil püsida organiseerituna, keskenduda sprindi töödele ja eesmärgile ning arendada end pidevalt tööprotsesside täiustamise ja tagasisidestamise kaudu.

 

• Sprint on kindla ajaga raamistatud arendustsükkel. See kestab tavaliselt 2-4 nädalat ja selle pikkuse otsustab tiim. Sprindis loetakse tööd lõpetatuks kui need vastavad "Valmis" definitsioonile (Definition of Done, DoD).
• Sprindi planeerimise koosolekul arutatakse, mis töid uues sprindis teostatakse vastavalt sprindi eesmärgile ja mis mahus. Maksimaalne ajaraam ühekuulise sprindi jaoks on 8 tundi. 
• Igapäevane Scrum (Daily Scrum) on lühike igapäevane koosolek tiimi edusammude ja takistuse arutamiseks ning päeva planeerimiseks. See on piiritletud 15 minutiga päevas.
• Sprindi ülevaade (Sprint Review) on koosolek sprindi lõpus tehtud töö esitlemiseks ja tagasisidestamiseks. Tihti teostatakse sel ajal ka valminud tööde demonstratsioon. Maksimaalne ajaraam ühekuulise sprindi jaoks on 4 tundi.
• Sprindi retrospektiiv (Retro) on koosolek, kus tiim saab analüüsida oma tööprotsesse ja leida võimalusi selle parandamiseks. Maksimaalne ajaraam ühekuulise sprindi jaoks on kolm tundi.

 

On oluline märkida, et piletite või tööde täpsustamise arutelud (Grooming/Backlog Refinement) ei ole osa Scrum sündmustest. Toote tööde loendis olevaid töid saab täpsustada ükskõik mil viisil sprindi jooksul (koosolekud, kiirvestlused, telefonikõned jms). See protsess on pidev ega ole piiratud ühe koosolekuga sprindi jooksul.

 

 

Mis on Kanban?

Kanaban raamistik on üks agiilse meetodi, kuid ka näiteks DevOps meetodi, rakendamise viisidest. Alguse sai Kanban Toyota tootmisprotsesside optimeerimisest (Lean meetod) ning tänapäeval kasutavad seda tuhanded agiilset lähenemist kasutatavatest ettevõtetest. Kanbani eesmärk on parendada töövoogusid ja koostööd, et suurendada efektiivsust ja tootlikkust.

 

 

Kanban põhimõtted ja komponendid

Kanban raamistiku keskmeks on visuaalne tahvel, kus tulpades on kuvatud kõik tööd kaartidena, millel on ka üksikasjad – nimi, vastutav isik, tähtaeg jne. Tulpades on projekti tööde erinevad staatused: näiteks valitud tegemisele, töös, peatatud ja tehtud. Kaardid liiguvad tahvlil vastavalt staatusele. 

 

Sellist tahvlit kasutavad ka erinevad projektijälgimise tarkvarad, nagu Atlassian Jira. Sellise tahvli eesmärk on tekitada töödes läbipaistvust, jälgida projekti tööde kulgu ning leida pudelikaelu ja võimalusi töövoo parendamiseks.

 

Iga veerg Kanban tahvlil on piiratud teatud arvu kaartidega, et limiteerida samal ajal töös olevaid funktsionaalsusi (Work in Progress, WIP). See on vajalik töövoo sujuvuseks ning tagab, et tiim ei oleks töödega üle koormatud.

 

Kanban toetab pidevat tööde tarnet ehk reliisi. Kohe kui tööd on valmis, toimub nende reliisimine. Valmis on need siis, kui vastavad "Valmis" definitsioonile ehk kõik vastab kvaliteedistandardile. See aitab vältida ka poolikute tööde kuhjumist töövoos.

 

Kanban raamistik rõhutab pidevat täiustamist, jälgimist ja optimeerimist. Tiimid kohtuvad regulaarselt, et arutada, kuidas saaks tööd paremini teha, ressursse efektiivsemalt kasutada ning õppida. Lisaks on raamistikus oluline kasutajakesksus, mis võimaldab tiimidel keskenduda kõige olulisematele ja rohkem väärtust loovatele töödele.

 

Kanban raamistikus rakendatakse samuti toote tööde loendi (Product Backlog) loomist ja tööde prioriseerimist. Tööd võetakse loendist töösse, viies need Kanban tahvlile. Tööde teostajad valivad loendist ise, milliste töödega tegeleda (pull system).

 

 

Kanban vs Scrum

Kanban ja Scrum raamistikul on palju ühist. Mõlemad rõhutavad oma protsessides kasutajakesksust, tiimide ja töö pidevat tõhustamist ning tööde läbipaistvust. Mõlemas raamistikus on lisaks oluline tööde prioriseerimine, et luua maksimaalset väärtust. 

 

Kanbani eelis on see, et selle omandamine on arendustiimile lihtne, kuna see kasutab visuaalseid vahendeid ega ole piiratud erinevate rollide, sündmuste ega ajaliste piirangutega. See ei nõua keerukaid reegleid ega rangeid protsessikirjeldusi. Iga tiim saab selle raamistiku kohandada vastavalt toote/teenuse või tiimi vajadustele. 

 

Scrum rõhutab järk-järgulist ja kindlates ajavahemikes arendust, mis aitab tiimidel regulaarselt tehtud tööd ja protsesse tagasisidestada ning parendada. Rõhk on ka tiimide iseorganiseerumisel. Tööde teostamine kindlates raamides loob protsessi selgust ja eesmärgipõhisust. 

 

 

Scrum sobib pigem projektidesse, kus...

• on selge eesmärk;
• on vaja arendust kiiresti teostada ja toode valmis saada;
• Scrum tiim ja erinevad projekti huvipooled on valmis intensiivseks arendusprotsessiks;
• tiimi suurus jääb alla 9 liikme;
• tiim saab 100% pühenduda ühele projektile;
• tiim saab töötada igapäevaselt lähestikku ja samas ruumis; 
• tiim on varem Scrumiga tuttav või valmis keerukat Scrum raamistikku kiiresti õppima töö käigus;
• tegemist on keeruka toote või teenuse arendusega, mida tuleb väiksemateks tükkideks teha; 
• ei ole pidevalt prioriteetide muutusi töödele;
• fookus on tähtaegade saavutamisel;
• on vajadus saavutada väga head ennustatavust ja planeerimist.

 

Kanban sobib pigem projektidesse, kus...

• tiimi suurus ei ole piiratud;
• tiim ei tööta igapäevaselt samas ruumis;
• tegijad teostavad töid ka teistes projektides samal ajal;
• töö ülesandeid ei saa ennustada ette ja need on pidevas muutumises;
• tööde prioriteedid muutuvad tihti;
• tööd tehakse pidevas voos;
• ei ole vaja teostada töid kindlates ajaraamides;
• tuleb pidevalt läbi rääkida erinevate sidusrühmade ja huvipooltega.

 

Scrumi ja Kanbani vahel saab valida ka olenevalt projekti faasist. Aktiivses arendusfaasis saab kasutada Scrumi ning hoolduste või väiksemate jätkuarenduste ajaks minna üle Kanban raamistikule.

 

 

Scrumban – parim kombinatsioon kahest

Kanbani kasutatakse tarkvaraarenduses ka sageli koos Scrumiga ning seda hübriidi nimetatakse Scrumbaniks. Scrumban raamistiku kasutuselevõtt muutub erinevates asutustes järjest populaarsemaks.

 

Esialgu sai see loodud selleks, et Kanban raamistikku rakendavatel tiimidel oleks lihtsam Scrum raamistikule üle liikuda. Hetkel on see raamistik veel täpselt defineerimata, seega on tiimidel võimalik ka ise luua projekti juurde põhimõtteid, millest lähtuda.

 

 

Scrumban põhimõtted ja komponendid

Scrumban ühendab kahe lähenemise eelised ehk selle kasutusele võtmisega luuakse projekti nii paindlikkust kui struktureeritust – tööde voogu juhitakse paindlikult, see on visualiseeritud tahvlil, aga toimuvad ka töötsüklid (sprindid) ja planeerimise sündmused. 

 

Scrumban sobib hästi projektidesse, kus nõuded ja prioriteedid pidevalt muutuvad, kuid samal ajal on oluline regulaarselt jälgida protsesse, mis võimaldab probleeme ennetada. Töid on võimalik vajadusel töötsüklisse juurde lisada või muuta ning tiim ei pea ootama tsükli lõpuni, et uusi töösid ette võtta. Regulaarsed koosolekud tagavad, et kommunikatsioonis ei teki puudujääke.

 

Töötsükleid hallatakse tööde piiramisega (WIP). Kui tööde hulk tahvlil „valmis arenduseks“ tulbas langeb alla teatud piiri, on aeg uueks planeerimise koosolekuks. Töötsüklid hoitakse väikestena, et kohanduda muutustele. Ideaalis on need 2-nädalased. 

 

Scrumban raamistikus on endiselt oluline tööde prioriseerimine ja nende detailsuse tase toote tööde loendis. Rakendatakse tõmbamise süsteemi (pull system) töödele ehk teostajad valivad endale ise tööd „valmis arenduseks“ tulbast.

 

 

Näited erinevate raamistike kasutamisest

Scrum sobib kõige paremini olukorras, kus algusest peale on vaja luua ärikriitiline infosüsteem, mis baseerub konkreetsetel ärilistel vajadustel ning tooteomaniku kindlal visioonil.

 

Näiteks ühe aasta pärast on plaan liikuda tootega uuele müügiturule ning tarvis on luua iseteeninduskeskkond, mis võimaldab mugavamalt koostada regulaarseid ja keerukaid tellimusplaane. Või on soov arendada uut tehnoloogiat või täiendada olemasolevat - näiteks drooni, mis peab tänasega võrreldes suutma lennata kaks korda kõrgemale ja kaugemale ning teha kvaliteetsemaid pilte.

 

Trinidad Wisemanis oleme loonud Scrum raamistikku kasutades suuri infosüsteeme ja iseteeninduskeskkondi. Näiteks lõime Tööinspektsiooni infosüsteemi, mida kasutatakse Tööinspektsiooni siseselt menetluste läbiviimiseks ja millesse kuulub ka kliendiportaal ning tööandjatele suunatud töövahendid. 

 

Kuula ka meie taskuhäälingu episoodi TEISI (Tööinspektsiooni) projektist või loe intervjuud, kus räägime kõigi osapooltega tiimitunnetuse loomisest ja koostöömotivatsiooni hoidmisest, aga ka kliendi rollist arendusprojektides.

 

Kanban sobib näiteks süsteemidele, kus visioon toote osas on veel hägune ja selgineb tööde käigus. Näiteks eksisteerib olemasolev infosüsteem, millele on planeeritud regulaarne edasiarendustsükkel.

 

Kasutajatelt kogutakse uuele loodavale funktsionaalsusele tagasisidet, pannakse paika soovidest lähtuvad vajadused ning rakendust arendatakse edasi iteratiivselt. Uute funktsioonide lisamisel tootesse on küll regulaarne rütm ning laiem eesmärk, kuid puudub konkreetne ajaline kriitilisus ja täpselt defineeritud eesmärk.

 

Trinidad Wisemanis oleme loonud lisaarendusi mitmele projektile. Näiteks on valminud Eesti Liikluskindlustuse Fondile liiklusõnnetusest teavitamise süsteem. Kui projekt sai valmis, liikus see edasi lisaarenduste faasi.

 

Vahest võib ka vastavalt arendusfaasile raamistik muutuda. Näiteks lõime Kvatrole Haldusnet infosüsteemi Scrumban lähenemist kasutades. Kui aktiivne arendusfaas oli läbi, liikus projekt vahepeal Kanban raamistiku peale hooldamise režiimi. Mõne aja pärast tekkisid infosüsteemil uued vajadused ja nende ärikriilisusest lähtudes teostati need taaskord Scrumban raamistikul.

 

 

 

Kokkuvõtteks

Scrum, Kanban ja nende kombinatsioon Scrumban on populaarseimad agiilsel metoodikal põhinevad raamistikud. Need raamistikud ei konkureeri omavahel ja loovad igaüks omamoodi väärtust. Iga tiim saab valida vastavalt eesmärgile, projekti nõuetele, töö iseloomule ja tiimi harjumustele sobiva raamistiku. Oluline on mõista iga raamistiku eeliseid ja miinuseid, et teha projekti raamistiku valikul õige otsus ning saavutada toote või teenuse loomisel parim tulemus.

 

See ingliskeelne küsimustik aitab leida sinu projektile sobiva raamistiku.