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

Agile - Pa vendar
Napredni pristopi
admin

AGILE PRI NAS DELUJE. PA VENDAR…

UVOD Ta članek je navdihnjen z lastnimi opažanji, kar malce preroškim opozorilom v knjigi The Lean Startup in zmedo, ki jo je v razvojni cikel prinesla umetna inteligenca. Članek ima dve sporočili, ki sta medsebojno neodvisni, a se funkcionalno navezujeta.

Članek »
Tuckmanov model razvoja timov
Delo s teamom
admin

TUCKMANOV MODEL RAZVOJA TEAMOV

Od razvojnih timov se učinkovitost pogosto pričakuje “Out of the Box”. Vodstvo: “Saj so v našem timu navsezadnje sami  strokovnjaki (in dobro plačani)!”  Pri tem se običajno pozabi, da razvojni timi delovne sinergije ne dosežejo čez noč, ampak je to

Članek »
ZAKAJ VSI RAZVOJNI CIKLI IZGLEDAJO PODOBNO?
Zanimivo
admin

ZAKAJ VSI RAZVOJNI CIKLI IZGLEDAJO PODOBNO

UVOD Agilni svet rad ustvarja nove modele, diagrame in cikle. Scrum ima svoj cikel ceremonij, Lean Startup govori o Build-Measure-Learn, Lean UX o Think-Make-Check, Deming pa o PDSA. Na prvi pogled gre za različne pristope z različno terminologijo in različnimi

Članek »
Približki
Zanimivo
admin

PRIBLIŽKI SM IN PO VLOG V OSTALIH FRAMEWORKIH

Razvojni timi uporabljajo različne Agilne in Lean pristope. Ti v večjem delu temeljijo na skupnih temeljih. Najpomembnejša sta:  inkrementalni razvoj, ki omogoča pogoste povratne informacije in organizacijsko ustvarjanje pogojev za aktivacijo ustvarjalnega potenciala timov. Obstajajo seveda tudi izjeme. Na pamet

Članek »
Shopping Cart
Scroll to Top