KANBAN – štíhlá metoda pro správu a zlepšování práce

Kanban (japonsky: 看板, což znamená „vývěsní štít“, „cedule“ nebo „nástěnka“) je štíhlá (lean) metoda pro správu a zlepšování práce napříč lidskými systémy. Tento přístup si klade za cíl řídit práci vyvážením požadavků s dostupnou kapacitou a zlepšením řešení úzkých míst na úrovni systému.

Pracovní položky (nejrůznějšího charakteru) jsou vizualizovány, aby účastníkům poskytly pohled na postup a proces od začátku do konce. Obvykle prostřednictvím fyzické či virtuální „nástěnky“, tedy Kanbanu. Práce je tzv. „tažena“ (pull) podle priority a toho, jak to kapacita dovoluje a nikoliv „tlačena“ (push) do procesu.

Ve znalostní práci (např. vývoji softwaru, ale nejen tam) je cílem poskytnout vizuální systém řízení procesů, který pomáhá při rozhodování o tom, co, kdy a v jakém množství vytvořit a jak si určit priority.

Základní metoda Kanban vznikla ve štíhlé výrobě (lean manufacturing), která byla inspirována výrobním systémem Toyota. Vznikla koncem 40. let, kdy automobilová společnost Toyota zavedla výrobní systém s názvem just-in-time. Cílem je vyrábět podle poptávky zákazníků a identifikovat možné nedostatky materiálu ve výrobní lince.

David J. Anderson (Inženýr společnosti Microsoft, autor jedné z pěti nejprodávanějších knih o agile) si po nějakém čase uvědomil, že se tato metoda z Toyoty může stát procesem použitelným pro jakýkoli typ společnosti. Lze použít všude, kde je potřeba organizace práce mezi lidmi.

Kanban se dnes běžně používá při vývoji softwaru i v dalších oborech. A to i v kombinaci s dalšími metodami a rámci, jako je Scrum nebo i zcela samostatně, jen jako řízení toku položek ke zpracování.

KANBAN – základní podoba

Obrázek níže ukazuje obecný základní pracovní postup vývoje (např.) softwaru, zobrazený formou Kanbanu.

Pozn.: Kanbany se samozřejmě v různém kontextu i značně liší, zde máme uveden i z prostorových důvodů spíše jednoduchý příklad.

Mohou být použity nejrůznější typy pracovních položek, sloupce vymezující aktivity pracovního postupu (udělat, pracuje se na tom, hotovo, ale i celá řada dalších stavů podle toho, co je pro vás užitečné, včetně dílčích kroků uvnitř některého stavu, v závislosti na konkrétním procesu či toku hodnoty) nebo tzv. plavecké dráhy, což jsou řádky procházející několika sloupci, použité pro seskupení podle nějakého kritéria.

Např. na obr. výše jsou seskupeny úkoly patřící k jedné položce backlogu, což může být v daném kontextu opět téměř cokoliv. Souhrnný úkol v rámci vývoje (třeba funkcionalita), malá úprava pro konkrétního zákazníka, odstranění chyby, krok v administrativním procesu atd.

Cílem struktury KANBANu je srozumitelně objasnit obecný pracovní postup a tok jednotlivých položek účastníkům a dalším zainteresovaným stranám.

KANBAN Praktiky

Kanban na výše uvedeném obrázku zdůrazňuje první tři obecné principy:

• Vizualizuje práci týmu (položky, úkoly).
• Stanovuje limity WIP (Work In Progress) pro vývojové kroky (zakroužkované hodnoty nad záhlavími sloupců, které omezují počet pracovních položek v daném kroku). Je třeba poznamenat, že aby toto dobře fungovalo, je dobré mít přibližně stejnou granularitu úkolů.
• Dokumentuje zásady, použitelné také jako pravidla, co se musí v daném kroku udít a kdy je krok možné považovat za hotový (uvnitř modré popisky pod sloupcem).

Jak to vlastně funguje

Položky jsou na Kanbanu přesouvány v reálném čase, tak jak se dějí. I přesto nebo právě proto dělají některé týmy denní synchronizaci, obdobu Daily Scrum události. Vždy je tak možné vidět aktuální stav, což přináší značnou transparenci pro všechny zainteresované.

Omezení nedokončené práce (WIP limit)je naprosto klíčovým prvkem KANBANu. V podstatě jde o podobný princip, proč se třeba na dálnici nebo v tunelu sníží maximální rychlost a díky tomu se zachová plynulost dopravy namísto popojíždění či stání v zácpě. V našem případě jde o plynulost toku plnění úkolů (což je i jedním z cílů LEANu).

Reflektováno je vlastně také i tuzemské rčení „sto zajíců, myslivcova smrt“.

Limity WIP pro vývojové kroky tak poskytují týmům i ostatním okamžitou zpětnou vazbu o problémech pracovního toku, např. ve chvíli, kdy se někde začnou položky hromadit. Na obr. výše mají všechny stavy krom prvního „plno“. To znamená, že ze sloupce „Identifikované úkoly“ se prostě nic nemůže posunout dál, protože není kam. To brání zahlcení dalších kroků procesu.

Flexibilita v rámci týmu

Členové týmu pracující na identifikaci úkolů toho tedy v danou chvíli nechají a mohou jít např. pomoci s odbavením položek ve sloupci „Realizace – krok 2“, protože odsud něco musí odejít, aby se cokoliv dalšího mohlo následně posunout zleva doprava. Respektive, jakmile něco zmizí ze sloupce „Realizace – krok 2“, lze si vybrat něco ze sloupce „Realizace – krok 1: Připraveno jít dál“ a následně si do „Realizace 1“ vybrat něco ze sloupce „Připraveno k realizaci“.

Může nastat i situace, kdy se sloupec „Připraveno k realizaci“ vyprázdní. Třeba když z něj budou všechny položky vytaženy do realizace a postupně odbaveny.

Jakmile pak nějaký úkol přejde do stavu „Hotovo“, jiný do „Realizace – krok 2“ a následně ve sloupci „Realizace – krok 1“ bude místo, ukáže se, že není co tahat z „Připraveno k realizaci“. Členové týmu tedy budou motivováni pomoci s přípravou položek pro realizaci.

Toto řízení pracovního postupu funguje podobně pro každý krok. Problémy jsou vizuální, viditelné v reálném čase a přeplánování či přeskupení sil lze provádět průběžně.

Někdy lze plynulost toku řešit pouze přeskupováním členů týmu, jindy jde možná o systémovější problém. Pro dostatečnou plynulost je pak potřeba změnit omezení WIP nebo tým posílit o kolegy, jejichž primárním zaměřením bude krok, na kterém to drhne.

Metriky KANBANu

Kanban používá specifické metriky k měření kapacity týmu a odhadu doby realizace.

Rychlost týmu definuje, kolik úkolů (zhruba stejné náročnosti) může tým splnit v daném časovém období, například za týden nebo iteraci. Rychlost se počítá pravidelně. Aby tato metrika dobře fungovala, je třeba se snažit hned od začátku vytvářet úkoly podobné velikosti. Znalost rychlosti týmu pak pomáhá lépe předvídat, kdy bude potřebná práce dokončena.

„Dodací lhůta, doba trvání“ (lead time) a „čas cyklu“ (cycle time) definují dobu potřebnou k dokončení úkolu.

Doba trvání se počítá, od chvíle, kdy tým dostane požadavek od „klienta“, a „doba cyklu“ se počítá od momentu, kdy tým začne pracovat na úkolu.

Zajímavé je pak sledovat poměr mezi těmito dvěma metrikami a snažit se, aby se pokud možno blížil ideálu, tedy hodnotě 1.

A to je všechno?

A to je vlastně všechno… KANBAN je jako rámec opravdu jednoduchý. Samozřejmě, šlo by jít i velmi hluboce do detailu, jak popisovat jednotlivé požadované položky, jak si mapovat smyčky zpětné vazby, jak pracovat s týmem. Existují i velmi silné knihy o KANBANu a rozsáhlé kurzy. I my věnujeme KANBANU v rámci našeho kurzu Agilních přístupů náležitý prostor.

Základní princip je ale opravdu jednoduchý. Zmapujete příslušný tok hodnoty (což je, pravda, disciplína sama o sobě), rozdělíte jej do kroků. Následně sestavíte adekvátní cross-functional tým tak, aby byl celý myšlený tok hodnoty dobře pokrytý. Poté zaškrtíte množství rozpracovaných položek v jednotlivých krocích, doplníte pravidla a hurá do práce…

S tím, že se to vše (limity WIP, pravidla, podoba a počet kroků, …) může průběžně měnit, děláte retrospektivy apod. Ale jako celek se snažíte, aby to prostě „plynule teklo“ (a nebylo z toho peklo 😉).

Předpoklady úspěchu

Na druhou stranu… to je na tom právě to složité. Někteří popisují KANBAN jako agilitu pro zkušené týmy. Ne, že by zvládnutí SCRUMu bylo úplně jednoduché, ale je tam alespoň ten základní rytmus Sprintu a jeho událostí, který to drží nějak pohromadě a dává tomu směr. KANBAN je prostě tok a nezkušený tým se v něm může snadno ztratit, utopit.

Pro dobře fungující KANBAN je potřeba mít skutečný tým (kmenová úroveň 4), který je nejen cross-functional, ale ve kterém je i značná zastupitelnost a profesní přesah. A i když nejsou fundamentálně určené žádné role, adopce KANBANu si většinou vyžádá nějakého Kanban Mastera, agilního kouče apod. Zkrátka někoho, kdo bude řešit systém a snažit se dělat z týmu tým. Což je ale další obsáhlé téma a nebo i celý kurz.

Nicméně, nic vám nebrání začít experimentovat hned teď, zkusit si zmapovat svůj tok hodnoty, stanovit pracovní kroky a zkusit si k nim svůj KANBAN vytvořit. Asi to nebude hned napoprvé zcela správně a bude potřeba to upravit. No a co? O tom je přeci agilita – neustálé zlepšování na základě zpětné vazby. Tak hodně zdaru! A kdybyste to chtěli probrat, ozvěte se. Rád si nad tím s vámi sednu.