Kanban na kratko
KANBAN NA KRATKO

Definicij Kanban sistema je veliko. Zmeda je še večja, ker se za skrbništvo nad tem frameworkom borita dve organizaciji. A to ni tema trenutnega članka, če vas zanima, si lahko več o ozadju preberete v tem članku.

Osebno mi je najbolj všeč naslednji opis:

“Kanban (system) is a strategy for optimizing the flow of value through a process that uses a visual, pull-based system.”

Kanban (sistem) je preprost in je opisan na petih straneh dokumenta, ki se imenuje Kanban Guide. Ta je trenutno v svoji 2020 izdaji. Zgornja definicija je prevzeta iz tega dokumenta.

Različni viri nadvse odločno navajajo 3, 4,… ali 7 osnovnih Kanban principov, elementov in zapovedi. Vsakdo torej Kanban interpretira po svoje. Iz tega razloga se bom v članku oprl na knjigo od Davida J.Andersona, ki je leta 2010 prvič opisal uporabo Kanban sistema v razvojnih dejavnostih in se s tem pozicioniral kot avtor omenjenega frameworka.

Po Andersonu Kanban temelji na petih lastnostih dela, ki katalizirajo vpeljavo Lean principov v organizacijo. Citiram:

  • Visualize Workflow
  • Limit Work-in-Progress
  • Measure and Manage Flow
  • Make Process Policies Explicit
  • Use Models to Recognize Improvement Opportunities

Oglejmo si primere vsakega posebej.

Visualize Workflow

To lastnost pooseblja Kanban tabla na kateri je predstavljena sekvenca razvojnih faz.

Kanban na kratko

Limit Work-in-Progress

Vsaka Kanban tabla ima na razvojnih fazah WIP limite. Te omejujejo število funkcionalnosti, ki se lahko naenkrat nahajajo v posamezni razvojni fazi*.

|

*Opomba: WIP limite se lahko določajo tudi za classes of service, swimlanes ali celotno tablo.

Measure and Manage Flow

Če se razvite funkcionalnosti začnejo kopičiti v neki razvojni fazi, je faza, ki ji sledi verjetno ozko grlo. Pretok lahko optimiziramo na tri načine:

  • Razvojnika iz hitrejše faze premaknemo v fazo, ki zamuja.
  • Razvojnika iz hitrejše faze umaknemo iz razvojne skupine.
  • Fazi ki zamuja, dodamo dodatnega razvojnika.
|
Kanban na kratko
Kanban na kratko

Poleg Kanban table obstaja še nekaj vizualnih orodij, ki nam pomagajo pri nadzoru pretoka funkcionalnosti skozi razvojni proces. Slike štirih najkoristnejših so vzete iz aplikacije Nave, ki deluje kot dodatek Jire.

Na Cumulative Flow diagramu enakomerno široki pasovi razvojnih faz pomenijo enakomeren (brez ozkih grl) pretok funkcionalnosti skozi razvojni proces.

|

Cycle Time Scatterplot graf je orodje za planiranje. Graf na sliki nam prikazuje, da bojo funkcionalnosti trenutno v razvoju zaključene s:

  • 70% gotovostjo v 14 dneh oz.
  • 85% gotovostjo v 29 dneh oz.
  • 95% gotovostjo v 57 dneh.
Kanban na kratko

Aging graf nam pove v katerih razvojnih fazah se funkcionalnosti v povprečju najdlje zadržujejo.

Kanban na kratko

Flow Efficiency graf nam pove koliko časa so funkcionalnosti zaključene v neki fazi v povprečju čakale na prevzem v naslednjo razvojno fazo.

|

Make Process Policies Explicit

Ker Kanban nima formalnih demo dogodkov, so teami, ki ga prakticirajo (poleg izgube stika z naročnikom) nagnjeni tudi k nižanju kvalitete. Da bi se temu izognili, Kanban teami določijo pravila, ki jim funkcionalnost mora zadostiti, da se lahko smatra za zaključeno v neki razvojni fazi. Primeri takšnih “step level policy” so na primer opravljen refactoring, opravljeni unit testi, validacija s strani stranke ipd.

Ekvivalent v Scrumu je Definition of Done (DoD), ki je interni teamski standard kvalitete in določa katere funkcionalnosti se na koncu Sprinta predstavijo naročniku.

Kanban na kratko

Use Models to Recognize Improvement Opportunities

Validacijo idej in konceptov je potrebno z naročnikom opraviti čim hitreje in s čim manjšimi stroški. Validacija MVP je običajno vsaj 10x dražja od validacije z modelom ali (kartonastim, wireframe?) prototipom. Modeli so torej orodje, ki nam pomaga hitro in poceni potrditi razvojno usmeritev, predno smo zašli predaleč v napačno smer.

Povzetek

In to je Kanban. Ena od njegovih pomembnejših značilnosti je, da ne zahteva globokih organizacijskih sprememb in se ga da implementirati preko obstoječe hierarhične organizacije. Kanban sam po sebi torej organizacije ne bo naredil agilnejše in vitkejše (Lean). To se bo zgodilo kot posledica konstantne optimizacije pretoka funkcionalnosti skozi razvojni proces in širjenja prvotnega procesa na vhodne (upstream) in izhodne (downstream) procese. Vsaka sprememba bo namreč podprta z empiričnim dokazom učinkovitosti. Poleg tega bojo spremembe postopne, kar bo zagotovilo minimalni odpor v organizaciji.

Ostale objave

Daily standup in 3 vprašanja
Orodja
admin

DAILY STANDUP IN 3 VPRAŠANJA

Mnogo razvojnih timov ne prakticira Daily Standup oz. Daily Scrum. Do zavračanja praviloma pride zaradi nerazumevanja funkcije dogodka in njegovih napačnih izvedb. Posledica je prepričanje, da je Daily Scrum zapravljanje časa – in v takšnih okoliščinah pogosto tudi je. Po

Članek »
Scrum vzorci - duh Scruma
Napredni pristopi
admin

SCRUM VZORCI – DUH SCRUMA

“Scrum is a light-weight process framework which is simple to understand but difficult to master.” Zgornja trditev je uveljavljena mantra Agilnih praktikov, konzultantov in evangelistov. Je resnična, a sama po sebi ne prinaša vrednosti. Scrum vzorci nadgrajujejo framework s praktičnimi

Članek »
Scrumban
Osnove
admin

KAJ JE SCRUMBAN

Člani teamov, nezadovoljni s Scrumom, včasih pravijo, da bodo “kar prešaltali na Scrumban”, ker tam ni potrebno planirati. To je pogosto prepričanje. Scrumban bo nekako ohranil vse prednosti Scruma, rešil pa nas bo dolgočasnega ocenjevanja velikosti uporabniških zgodb in planiranja

Članek »
Adaptive leadership
Delo s teamom
admin

ADAPTIVE LEADERSHIP SKOZI RAZVOJ TEAMA

V nedavnem članku smo spoznali Tuckmanov model razvoja teamov. Prispevek se je osredotočal na sam model in značilnosti teamske dinamike v določenih fazah. Tokrat bomo temo nadgradili z vpogledom v to, kako razvoj teama izgleda s stališča “servant leaderja“. Adaptive

Članek »
Shopping Cart
Scroll to Top