+372 56 21 1146 info@agilecoach.ee

Merle Randlepp

Agile Coach

Merle Randlepp

Agile Coach

Kanban vs Scrum

juuli 8, 2020 | Tarkvaraarendus

2,694 Views

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

        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

           

          Scrum Kanban
          Tsükkel Fikseeritud pikkusega sprindid Pidev töövoog
          Piirangud Sprindi tööde maht Käsil olevate tööde arv
          Tahvel

          Taasluuakse iga sprindiga

          Kasutab üks meeskond

          Prioritiseerimine on tähtis

          Püsiv

          Jagatud mitme meeskonna vahel

          Prioritiseerimine pole nõutud

          Muutused Sprindi ajal muutusi ei tehta Muutused igal ajal
          Väljalasked Iga sprindi lõpus Pidev tarne
          Rollid Tooteomanik, Scrum meister, Arendusmeeskond Nõutud rollid puuduvad
          Meeskond Multifunktsionaalne ja terviklik Välised spetsialiseerunud meeskonnad lubatud
          Sündmused Daily, Planning, Review, Retrospective Nõutud sündmused puuduvad
          Mõõdikud Velocity Lead time, Cycle Time, WIP
          Hindamine Töödel on punktiväärtused Hindamine pole kohustuslik

           

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

          Subscribe
          Notify of
          guest
          0 Comments
          Oldest
          Newest Most Voted
          Inline Feedbacks
          View all comments

          Samal teemal

          Mis on RICE mudel tootearenduses?

          Mis on RICE mudel tootearenduses?

          Tootearenduses ei ole meil kunagi piisavalt aega ega raha, et kõiki soove ellu viia. Tooteomanikud kaaluvad pidevalt, milliseid arendusi teha ja millised tegemata jätta ning õigeid otsuseid ei ole sugugi lihtne teha. RICE mudel aitab meil tööde prioriseerimisel kiiremini õigemaid otsuseid teha.

          596 Views

          Tooteomaniku 8 suurimat viga

          Tooteomaniku 8 suurimat viga

          Tooteomaniku roll on kõige tähtsam roll tarkvaraarenduse meeskonnas. See roll ei ole kaugeltki lihtne, vastutusvaldkond on suur ja kirju, töökoormus tavaliselt samuti ja nii võibki juhtuda, et kuskilt hakkavad “õmblused kärisema”. Olen kokku pannud kaheksa enim levinud tooteomaniku viga, mis on tootearenduses kõige suurema mõjuga.

          2,655 Views

          Agiilne mõtteviis ja müüdid selle ümber

          Agiilne mõtteviis ja müüdid selle ümber

          Mõistet “agiilne” on ilmselt paljud inimesed kuulnud erinevates kontekstides – nii koerte treeningutest rääkides, IT ja tarkvaraarenduse juttudes, organisatsiooni juhtimise teemades, ja mujal. Kirjutan lahti 9 müüti, mis mõiste “agiilne” ümber ringlevad ja mida olen oma töö käigus tihti kohanud.

          3,190 Views

          Merle profiilipilt väike

          Iga uus kontakt on võimalus uueks ja põnevaks koostööks - kirjuta või helista mulle ja arutame kuidas saaksin Sind aidata. 

          Esimene konsultatsioon ja pakkumise tegemine on alati tasuta. 

          Ole kursis agiilse maailmaga - liitu uudiskirjaga

          Ole kursis agiilse maailmaga - liitu uudiskirjaga

          Teavitan Sind värsketest blogipostitustest, uuringutest ja trendidest agiilse tarkvaraarenduse teemadel.

          Aitäh, et liitusid!