Rok se sešel s rokem (skoro), takže je nejvyšší čas, říct si zase něco o
Kanbanu :-) Přiznám se, v těch
minulých článcích jsem to trochu flákal, moc se mi nechtělo do popisu, co to vlastně Kanban je. Tak to napravím.
Co je to Kanban?
Když mám definovat Kanban jednou větou, obvykle říkám:
Kanban je metoda-nástroj na zefektivnění procesu. Kdybych měl přidat druhou:
Kanban lze aplikovat na libovolný proces - je jedno, jestli jde o Scrum, nebo vodopád. A konečně:
Ten proces už musí existovat - Kanban neříká nic o tom, jak vyvíjet software.
Abych pravdu řekl, nikdy jsem nepřemýšlel na tím, jestli je Kanban využitelný i mimo oblast softwarového vývoje - jestli ano, tak mě to asi ani moc nezajímá. Jestliže kdekoliv dál v článku mluvím o procesech, mám na mysli procesy, jejichž smyslem je vytvoření, výroba, doručení software.
Abych vás neochudil o plnokrevnou definici, tak
Wikipedia říká:
"Kanban is a method
for managing knowledge work with an emphasis on just-in-time
delivery while not overloading the team members. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for participants to see and developers pull work from a queue."
A abych vás obohatil ještě o trochu víc, tak David J. Anderson (jeden z duchovních otců Kanbanu a autor
jeho bible) praví:
"In software development, we are using a virtual kanban system
to limit (team's) work-in-progress ... to a set capacity and to balance the demand on the team against the throughput of their delivered work. By doing this we can achieve a sustainable pace of development so that all individuals can achieve a work versus personal life balance."
Co Kanban (určitě) není?
Lidé mají velmi často pomýlené představy, co to Kanban je. Pojdmě si ho proto definovat i negativně:
- Kanban není metodologie. Často se setkávám se snahou srovnávat Kanban a Scrum. To je nesmyslná snaha. Kanban neříká vůbec nic o tom, jak máte dělat software. Neříká nic o tom, jak dělat (a jak často) plánování, nebo releasování. Neříká vůbec nic o tom, kdy máte co(koliv) udělat. Neobsahuje žádné ceremonie (denní meetingy, review, statusy projektu atd.). Chcete-li dělat vývoj software metodicky, najděte si nějakou metodiku, Kanban vám v tom nijak nepomůže.
- Kanban není proces. Pokud děláte software, musíte mít nějaký proces - můžete ho mít definovaný explicitně (třeba pomocí nějaké metodiky), nebo implicitně (což může v lepším případě znamenat intuitivně, nebo v tom horším chaoticky). Každopádně, pokud chcete používat Kanban, musíte už takový proces mít. Kanban se totiž vždy aplikuje na proces, je to taková "poleva".
- Kanban není agilní praktika. Kanban bývá často zmiňován ve společnosti agilního vývoje. Což je daný tím, že on se s agilními metodikami velmi dobře pojí, velmi dobře je doplňuje. Ale Kanban stejně tak dobře můžeme aplikovat na krystalicky čistý vodopád, či libovolný jiný "rigidní" způsob vývoje.
- Kanban není nástroj na project management. Pokud jste projekťák, může vám Kanban pomoci - asi největším přínosem pro vás bude předvídatelnost procesu a dodávek. Ale nijak vám nepomůže projekt řídit. Neřekne vám nic o potřebných zdrojích, o termínech, nijak nezohledňuje rozpočet projektu atd. Platí to samé jako u procesů a metodik - Kanban vám neřekne "jak to máte dělat".
- Kanban není všelék (stříbrná kulka). Kanban může některé vaše problémy vyřešit. Ale jenom některé. Lidé jsou nepoučitelní a tak se pořád najdou tací, kteří čekají na zázrak, který nepřichází. Kanban je dostatečně nový (a neznámý), aby sváděl některé manažery a "decision makery" k nereálným očekáváním. Je to ohraná písnička, ale... ani tentokrát mesiáš nepřijde.
Jaké přináší benefity?
V předešlé sekci jsem popsal, co Kanban není, což může na někoho působit negativně a vzbudit otázky: je to vůbec k něčemu? Nepomůže nám to ani s metodikou, ani s procesem, ani s project managementem. Proč se tím tedy zabývat?
V prezentaci na konci článku těch důvodů najdete víc, já bych z nich vypíchnul tři, které považuji za nejdůležitější:
- Kanban odstraní z procesu neefektivitu. Tohle je jeho kvintesence. Kanban pojímá práci jako proud, plynutí. Vše, co brání plynulosti procesu se snaži odstranit.
- Omezením rozpracované práce se zvýší kvalita. Tím, že se vývojáři (a další role) soustředí (ideálně) pouze na jeden úkol, měla by se zvýšit kvalita jejich výstupů.
- Kanban zavádí změny postupně, inkrementálně. Tohle je zajímavé z "politických" důvodů. Jednak směrem nahoru, k managementu, kdy se drobné změny rozložené v čase prosazují snáze a jednak směrem dolů, k lidem, jež jsou/budou denními účastníky procesu - lidé bývají vůči změnám rezistentní a konzervativní, takže opět - drobné změny se spíše skousnou.
Kořeny Kanbanu
Prapůvod Kanbanu lze hledat v
Toyota Production System (TPS). Součástí TPS je i
kanban system - systém pro řízení
just-in-time produkce, nicméně (softwarový) Kanban se inspiroval i v jiných aspektech TPS, třeba filozofii
kaizen (kontinuální zlepšování), nebo konceptu
muda (odpad, neproduktivní činnost).
TPS je silně inspirativní systém. S ohledem na softwarový vývoj je jednou z jeho prvních adaptací
Lean Software Development (LSD) - agilní metodika, která sice není tak populární, jako
Scrum, ale třeba pro oblast enterprise určitě vhodnější. Kanban přejímá z LSD některé jeho
nástroje, za všechny bych zmínil třeba
teorii front.
Kanban také intenzivně čerpá z teorie omezení -
Theory of Constraints (TOC). Jednou z implementací TOC je metodika
Drum-Buffer-Rope (DBR), která je přímým předchůdcem Kanbanu.
5 základních principů
Kanban je definován pomocí pěti základních (core) principů, které si postupně rozebereme.
- Vizualizuj workflow.
- Limituj rozdělanou práci.
- Měr a spravuj flow.
- Udělej procesní politiky explicitní.
- Používej modely pro rozpoznání příležitosti ke zlepšení.
Vizualizuj workflow
Celý Kanban se hodně točí kolem vizualizace a
vizualizace workflow, patří k tomu nejviditelnějšímu, na co můžeme narazit. Tato technika není ničím specifická, už před vznikem Kanbanu ji využívaly ostatní agilní metodiky.
 |
| Fyzický Kanban board |
Princip je jednoduchý:
- Vezmeme tabuli (Kanban board) a rozdělíme ji na vertikální sloupce (swim-lines) podle jednotlivých stavů našeho workflow (tyto stavy se často kryjí se stavy v issue tracking systému (ITS)).
- Práci, kterou potřebujeme udělat, rozdělíme na části (nazývané tasky) stejné, či podobné granularity. Tasky jsou prezentovány lístečky/kartičkami.
- Každý, takto identifikovaný task, umístíme na Kanban board do odpovídající swim-liny.
 |
| Fyzický Kanban board |
Kanban board může mít buď fyzickou, nebo elektronickou podobu. Fyzický board se většinou řeší klasickou bílou tabulí (
whiteboard), kam lze lístečky přilepit, připnout magnetem apod. Elektronický board je někdy poskytován
ITS (třeba
JIRA Agile (dříve GreenHopper plugin)), nebo lze použít samostatný nástroj (zkuste
zagooglovat, je jich spousta).
Je lepší použít fyzický, nebo elektronický
Kanban board? Záleží na kontextu. Fyzický se dobře vyjímá v openspacu a dobře se před ním dělají
stand-up meetingy. Pozitivní psychologický efekt je, že board je vidět neustále a tak každý člen týmu (i náhodný kolemjdoucí manažer) mají okamžitý přehled o stavu projektu. I z osobní zkušenosti (pokud to jde) doporučuji použít fyzický
Kanban board.
 |
| Elektronický Kanban board (JIRA plugin GreenHopper (nyní JIRA Agile)) |
Omezením fyzického boardu je jeho, ehm fyzičnost, čili jde použít pouze lokálně. Pokud máte distribuovaný tým, bude elektronický board lepší volba - alespoň jako primární zdroj pravdy. Fyzický board se dá nicméně v této situaci také využít, byť jen jako sekundární nositel informace.
Další výhodou elektronického boardu je jeho provázanost s ITS. Kanban board pak bývá "pouhým" snapshotem, pohledem na tasky. Tzn. že odpadá duplikování informace a synchronizace v ITS a na fyzickém boardu.
 |
| Elektronický Kanban board (Redmine) |
Limituj rozdělanou práci
Všichni to ví, všichni to tak nějak tuší, ale Kanban to říká nahlas:
nedělejte na více věcech najednou. Vemte si jednu věc, dodělejte ji a vezměte si další.
Nepřepínejte kontext!
Jak říká David J. Anderson v knize
Kanban:
"As we all know, there really is no such thing as multi-tasking in the office; what we do is frequent task switching".
Přepínání kontextu nemá žádný pozitivní efekt (snad kromě toho, že udržuje mozek v obrátkách). Kanban se k němu staví negativně a otevřeně říká:
nastavte explicitní limit, kolik tasků může být v daném stavu workflow. Tomuto principu se říká omezení
Work-in-Progress (WIP).
Pokud používáme fyzický board, napíšeme limit tasků nad každou swim-line. Kromě maximálního počtu tasků lze nastavit i minimální, tj. pod jaké množství by počet tasků ve flow neměl klesnout. Problém s WIP na fyzickém boardu je zřejmý - jeho dodržování je potřeba kontrolovat manuálně.
 |
| Nastavení WIP na fyzickém boardu |
Výhodou elektronického boardu je, že za vás nastavené WIP hlídá. Buď vám vůbec nedovolí tento limit překročit (prostě task nad limit nejde přesunout do "vyčerpaného" stavu), nebo vás aspoň upozorní, že limit byl překročen.
Ať už hlídáme WIP libovolným způsobem, podstatné je, jak se zachováme při jeho překročení. Můžou nastat tři modelové situace:
- Limit WIP máme dobře nastavený. Jeho vyčerpání nám signalizuje bottleneck ve flow. Ten může být buď dočasný, nebo chronický. V prvním případě by se měl zapojit celý tým, aby dočasný, jednorázový problém ostranil. V druhém případě bychom měli zapřemýšlet o změně procesu, flow apod.
- Limit WIP máme dobře nastavený, ale jeho překročení ignorujeme. V takovém případě je Kanban pouze formální záležitostí a je zbytečné ho dělat. Nebo od něj očekávat nějaké pozitivní výsledky.
- Limit WIP máme nastavený příliš vysoko, nebo nízko. Kanban je adaptivní, takže WIP upravíme na přiměřenější hodnoty.
 |
| Nastavení WIP na elektronickém boardu (JIRA plugin GreenHopper) |
Kruciální otázkou je, jak správně WIP nastavit. Je to podobné, jako s odhady pracnosti. Pokud můžeme, vezme v potaz podobný proces z minulosti. Pokud nemáme s čím srovnávat, vezmeme "expertní odhad". Nastavit WIP podle pravidla 1 vývojář, 1 task, taky není špatný začátek. Podstatné není, jestli WIP nastavíme správně na začátku. Ale že ho v průběhu projektu přizpůsobujeme podle aktuálního vývoje situace.
Měř a spravuj flow
Jedna z věcí, které Kanban převzal z
TPS je filozofie
kaizen, kontinuální zlepšování procesu. Abychom věděli, že se proces zlepšuje, je potřeba ho měřit.
Jednou ze stěžejních veličin, kterou Kanban používá (a měří) je
lead time - čas, za jak dlouho se task dostane z jednoho stavu do jiného, typicky ze stavu
To Do do stavu
Done. Ale jeden task nás na projektu nevytrhne - proto Kanban častěji pracuje s kumulovaným
lead time, tj. za jak dlouho projde flow
průměrný task.
Pokud pracujeme s
lead time, bude nás zajímat, kolik z něj bylo stráveno "produktivní" prací. Protože jeho "neproduktivní" část je to, co Kanban nazývá
waste (a TPS
muda) a tento "odpad", neproduktivní činnost se snaží (postupně) odstranit.
Na druhou stranu, ne vždycky musí být
lead time, který obsahuje
waste, špatnou věcí. Protože to tak může být záměrně. Pokud například máme definovaný stav
To Release, ve kterém nám tasky čakají na... release (protože změny nasazujeme hromadně), může být "neproduktivní" čekání tasku v takovémto stavu v pořádku. Nebo taky nemusí, musíme se zamyslet, jestli třeba změna procesu, která umožní kontinuální nasazování tasků nezlepší jak
lead time, tak kvalitu celého produktu.
Průběh a vývoj flow se v Kanbanu často zobrazuje pomocí
Cumulative Flow diagramu, což je jeden z nástrojů
teorie front. Diagram umožňuje rychlý přehled, jestli jsou dodržováný limity WIP, jestli se v průběhu času zlepšuje lead time a taky "plynulost" našeho systému - pokud Kanban "pracuje" správně, měly by být jednotlivé pruhy v diagramu hladké a s konstantní výškou.
Udělej procesní politiky explicitní
Podstatou tohoto kroku je přesvědčení, že pokud definujeme na projektu
explicitní definice procesních politik a shodneme se na jejich porozumnění; přinese nám to benefit, že budeme schopni racionálně a objektivně diskutovat nad jednotlivými issues a následně zapracovat na jejich zlepšení, nebo mitigování s nimi spojených rizik.
Příklady takových politik může být:
- Definition of Done (DoD),
- Work-in-Progress (WIP),
- adresování issues,
- eskalační mechanizmus,
- zodpovědnost v jednotlivých procesních stavech.
Konkrétním příkladem takové politiky může být např.
zero-bug-policy:
"Když je na projektu nalezen bug (oproti specifikaci), má automatickou prioritu Critical a musí být přednostně opraven. Tj. nezačínáme nové tasky, dokud nejsou opraveny kritické chyby."
To, že jsou politiky explicitní nejspíš znamená, že jsou někde sepsány. To ale nestačí - pokud jsou pohřbený někde na SharePointu apod., tak jsou v podstatě bezcenné. Naopak, měly by být jednodušše dostupné. Ideální místo je například wiki, která je součástí Issue Tracking systému.
Používej modely pro rozpoznání příležitostí ke zlepšení
Poslední (a nejvíc zanedbávaný) krok v Kanbanu je opět o vizualizaci - používá modely procesů a workflow, na základě kterých pak můžeme zlepšit
celkové fungování projektu/procesu. Důvod onoho zanedbávání (já to dělám taky) je prostý, jedná se o dost teoretickou záležitost. Modely, které se běžně používají jsou:
David J. Anderson k tomu v knize
Kanban říká:
"By modeling the workflow of a software development lifecycle as a value stream
and then creating a tracking and visualization system to track state changes of emerging work as it „flowed“ through the system, I could see bottlenecks
. The ability to identify a bottleneck is the first step in the underlying model for the Theory of Constraints
."
Prezentace
Záměr napsat tenhle článek jsem nepojal jen tak z čista jasna. Chystal jsem se na projekt, kde nyní Kanban používáme. A tak, v rámci sdílení znalostí (i pro získání politické podpory) jsem měl o Kanbanu přednášku u nás v práci:
Zdroje
Související články:
