Kanban vs Scrum

Sissejuhatus

Agiilseid metoodikaid on mitmeid erinevaid – Scrum, Kanban, XP (Extreme Programming), Lean, Crystal, FDD (Feature Driven Development), omavahelised hübriidid, jt.
Kaks kõige enamlevinud metoodikat on Scrum ja Kanban: erinevate uuringute järgi on Scrumi kasutamise osakaal üle 50%, Kanbanil ja erinevatel hübriididel ca 15% ringis.
Kanban vs Scrum ei ole kindlasti omavahelises võistluses, nende põhimõtted on lõviosas samad ja neid kasutatakse ka omavahelise hübriidina (ScrumBan). Mõlema raamistiku eesmärk on sama – aidata valmistada toodet või osutada teenust võimalikult efektiivselt ja suurima väärtuspakkumisega kliendile. Mõlemad metoodikad jagavad agiilseid põhimõtteid ja väärtuseid.
Konkreetse agiilse metoodika valik sõltub konkreetsest olukorrast ja organisatsiooni vajadustest.

Ajalugu

1990. aastatel alustasid Dr. Jeff Sutherland ja Ken Schwaber objektorienteeritud programmeerimise ühildamist Jaapani tootearenduse meetoditega. Nimetus „Scrum“ on pärit ragbi spordimängust ja tähendab mängijate kogunemist ringi, peade kokkupanemist ja mänguplaani kiiret arutamist.
Scrum hakkas maailmas laiemalt levima 2002 aastal koos Agiilse Manifesti populariseerimisega.

Kanbani juured ulatuvad 1940. aastatesse Toyota tootearenduse aegadesse, laiema leviku saavutas ta kümmekond aastat hiljem kui Scrum, pärast meetodi arendustöö jaoks kohandamist David Andersoni poolt. Nimetus “Kanban” tähendab Jaapani keeles „visuaalne silt“, mis tähistas autotööstuses visuaalset tööde jälgimise tahvli kasutamist.

Kanban vs Scrum: peamised erinevused

Töövoog

Scrumi ja Kanbani peamine erinevus on arendustsükli pikkus – Scrumis töötatakse 2-nädalaste (1-4 näd.) tsüklitega, mida nimetatakse sprintideks. Ühe sprindi sisse võetakse kindel hulk töid ja meeskonna eesmärk on tööd sprindi lõpuks valmis saada.
Kanbani töövoog on pidev ja ajaliselt piiramata, meeskond nopib töid vastavalt vajadusele pidevalt muutuvast ootel tööde nimekirjast.

Piirangud

Scrumis on piiratud kui palju töid ühte sprinti mahub, et tagada kõigi tööde valmimine sprindi lõpuks.
Kanbanis on piiratud korraga töös olevate ülesannete arv (WIP – Work In Progress), mis aitab kontrollida, et töös ei oleks liiga vähe ega liiga palju ülesandeid.

Tahvlid

Scrum ja Kanban tahvlid (boards) võivad mõlemad sisaldada vabalt valitud veerge, tavaliselt on kasutusel “ootel”, “töös”, “testimises” ja “tehtud” staatused.

Scrum tahvlil on korraga näha vaid ühe sprindi tööd ning ootel tööd (Backlog) on eraldi vaates.
Kanban tahvlil on ootel tööd esimeses veerus koguaeg olemas ja näha.
Scrum tahvel tehakse iga sprindi lõpus tühjaks ja luuake järgmisel sprindil uuesti, Kanban tahvel on püsiv.

Scrum tahvel kuulub korraga ühele pühendunud Scrum meeskonnale.
Kanban tahvel võib olla jagatud erinevate tiimide või inimeste vahel vastavalt vajadusele.

Scrumis on väga olulises kohas tahvlil tööde prioritiseerimine – kõrgema prioriteediga tööd paiknevad üleval pool. Kanbanis ei ole prioritiseerimine otseselt kohustuslik, aga sageli on see siiski kasutusel.

Muutused

Scrumis välditakse käimasoleva sprindi sees olevate tööde muutmist. Uusi töid saab lisada alles järgmisesse, ootel sprinti.
Kanbanis võib töid muuta ükskõik milllal ja nii palju kui vajalik.

Väljalasked

Scrumis toimuvad väljalasked (releases) toodangukeskkonda iga sprindi lõpus. Viimasel ajal on siiski hakanud levinud ka ad-hoc väljalasete kasutamine.
Kanbanis toimub tarnimine jooksvalt, pideva protsessi osana.

Rollid

Scrumil on kolm selgelt määratletud rolli:

• Tooteomanik (Product Owner), kes haldab uusi töid ja seab prioriteete
• Scrum meister (Scrum Master), kes aitab meeskonnal järgida agiilseid Scrum põhimõtteid ja eemaldada takistusi
• Arendusmeeskond (Development Team) kes teostab töid ning on tugeva kollektiivse vastutusega.

Kanbanis ei ole kindlaid rolle määratud.

Meeskond

Scrum meeskonnal pole otsest juhti ega projektijuhti, nad on iseorganiseeruvad ja võrdsed, hoolimata erinevatest kohustustest. Scrum tiimid on multifunktsionaalsed (cross-functional) ehk tiimi sees on kõik arendamiseks vajalikud oskused olemas.
Kanban meeskond töötab samuti iseorganiseerumise põhimõtetel, aga ei pea olema multifunktsionaalne vaid on lubatud ka koostöö teiste spetsialiseerunud tiimidega.

Sündmused

Scrumis on kasutusel kindlaksmääratud sündmused:

• Igapäevane Scrum (Daily Scrum)
• Sprindi planeerimine (Sprint Planning)
• Sprindi ülevaade (Sprint Review)
• Sprindi tagasivaade (Sprint Retrospective)

Kanbanis otseselt sündmuseid defineeritud ei ole, aga tihti on kasutusel laenud Scrum raamistikust nagu igapäevased koosolekud ja tagasivaated.

Mõõdikud

Scrumis on meeskondade keskne mõõdik kiirus (velocity), mis tähistab ühes sprindis valminud tööde punktide kogusummat (nt 35 punkti). Kiirus aitab ennustada, kui palju tööd valmib tulevastel sprintidel ja millal on eeldatav arenduse valmimise tähtaeg.

Kanbanis kasutatakse enamasti kahte mõõdikut:

• Lead time – aeg, mis kulus töö kirjeldamisest kuni töö valmimiseni
• Cycle time – aeg, mis kulus töö alustamisest kuni töö valmimiseni

Lead time mõõdab aega kliendi vaatevinklist, Cycle time meeskonna tööprotsessi vaatest.

Hindamine

Scrumis on oluline tööde mahu ja keerukuse hindamine ning neile punktiväärtuste omistamine. Kanbanis ei ole hindamine rangelt kohustuslik, aga soovi korral seda tehakse.

Scrum raamistiku oluline komponent on Burndown graafik. Kanbanis ei ole otseselt kindlaksmääratud graafikuid, kuigi neid muidugi kasutatakse – nt kumulatiivne voodiagramm (CFD – Cumulative Flow Diagram).

Kanban vs Scrum: millist metoodikat valida?

Tihti tehakse nende kahe metoodika kirjeldamisel üldistusi nagu “Scrum on mõeldud toote meeskondadele, Kanban on teenuse meeskondadele” või “Scrum on keeruka töö jaoks, Kanban on lihtsa töö jaoks”.
Tegelikult ei ole need üldistused eriti pädevad, sest paljud tootetiimid arendavad Kanbanil väga efektiivselt tooteid, mis ei ole kaugeltki lihtsad.

Meetodi valimiseks tasub küsida järgmiseid kontrollküsimusi.

“Kas meeskonnale on see esimene agiilne projekt?”

Kui vastus on “jah”, siis on mõistlikum valida Scrum, mida on agiilsesse maailma sisenemisel kiirem ja arusaadavam omandada.

“Kui kiiresti peab meeskond muutustele reageerima?”

Kui vastus on “väga kiiresti, tundide või päevade jooksul”, siis on soovitav valida Kanban, mille abil saab muudatussoovid kiiresti meeskonnani viia ja ei pea ootama 2-nädalase sprindi lõpuni. Teisest küljest on hea meeles hoida, et igasugused kiireloomulised tööd lõhuvad meeskonna töövoogu ja keskendumist ning vahest on targem nö magada öö ära, sest järgmisel päeval võib kriitilisuse aste juba oluliselt väiksem tunduda.
Kanbani kasutavad pea alati erinevad hooldustiimid ja DevOps tiimid.

“Kui tihti on vaja teha väljalaskeid?”

Kui vastus on “igapäevaselt või iga paari päeva tagant”, siis vali Kanban, mis töötab pidevas patch-režiimis.

“Kas tegu on uue rakenduse või toote arendamisega?”

Kui vastus on “jah”, siis vali Scrum, mis annab sulle paremad tööriistad minimaalse elujõulise toote (MVP – Minimum Viable Product) valmistamiseks, tehes seda kõrge kvaliteedi ja minimaalsete kuludega.

“Kas tegu on olemasoleva toote jätkuarenduste ja hooldusega?”

Vali Kanban, mis sobib hooldustöödeks paremini.

“Kas ma pean tingimata just nende kahe metoodika vahel valima?”

Absoluutselt mitte. Kui oled juba agiilse mõtteviisi omandanud ja seda mõnda aega praktiseerinud, on paras aeg alustada eksperimenteerimisega. Paljud tiimid töötavad väga edukalt erinevate hübriididega nagu nt ScrumBan, Scrum/XP, valides oma tingimustele ja soovidele sobivaimad praktikad.
Kõik agiilsed meeskonnad on erinevad ja eksperimenteerimine ning pidev edasiareng on võtmetähtsusega.

Kanban ja Scrum erinevuste kokkuvõttev tabel

Artikkel ilmus esmakordselt Äripäeva Teabevaras märtsis 2020:  https://teabevara.ee/et/app/it-juhtimine/metoodikate-scrum-ja-kanban-vordlus