Pokud sledujete náš seriál článků o praktických metodách, které mohou zachránit (nejen agilně řízený) projekt v nesnázích, dnes se dostáváme k metodě KANBAN. Z předchozích dílů již víte, jak vytvořit zadání (Lean Canvas) a uřídit detailní požadavky (Impact mapping) i jejich priority (KANO, MoSCoW). KANBAN je nástroj, který vám pomůže neztratit se v množství požadavků, které je potřeba realizovat.

Metoda KANBAN, jako sada nástrojů pro vývojové týmy, pochází z výrobní praxe, z Lean přístupů k výrobě v TPS (Toyota Production System) a Goldrattovy terorie omezení. KANBAN pro projektové týmy se stal v poslední době velmi populární díky snadnému zavedení, využití vizuálních kontrol, schopnosti přizpůsobit se široké škále různých firemních zvyklostí, zapojením stakeholderů a neustálého zaměření na dodání přidané hodnoty.

KANBAN znamená v japonštině „karta“ nebo také „vizuální záznam“. V řeči Lean přístupu se jedná o signální kartu, která reprezentuje část práce ve zpracování. Tato metoda odvozuje svůj název od použití požadavků k realizaci zaznamenaných na kartách pro řízení toku práce napříč pracovním týmem. Počet KANBAN karet ve zpracování je tak ekvivalentní celkové kapacitě, který je schopen tým zpracovat. Tento systém je označován jako PULL – další práce je přijata ke zpracování teprve v okamžiku, kdy se uvolní kapacita po zpracování předchozího požadavku, na rozdíl od běžného řízení práce, kterým je metoda přiřazení požadavku danému pracovníkovi (metoda PUSH), která ale může vést k zahlcení a vytvoření fronty.

Zavedení KANBANu je poměrně jednoduché. Staví na 3 základních pilířích: vizualizaci procesu, omezení množství rozpracované práce a řízení času na průchod procesem (Lead time – jedná se o průměrnou dobu potřebnou pro průchod jedné jednotky všemi kroky procesu, včetně subprocesů a případných čekacích dob. Optimalizace spočívá v zaměření se na omezení v procesu, spolupráci lidí a hledání možných variant.)

KANBAN board

Jedním z klíčových nástrojů vizualizace práce je KANBAN board. Jedná se o přehledovou tabuli nebo nástěnku, na které jsou vizuálně zachyceny všechny požadavky a jejich průchod procesem (stavy). KANBAN board může mít různé podoby podle složitosti agendy, na kterou je použit. Nejjednodušší je použití 3 stavového KANBANu se stavy TO DO (zásobník práce), DOING (rozpracované úkoly), DONE (dokončené úkoly). S touto strukturou si vystačíte u jednoduchých zadání v malém týmu. Pro komplexnější situace má KANBAN poněkud složitější strukturu, například včetně zachycení typu úkolu a zodpovědné osoby, ale stále je vizuálně přehledný (například díky barevnému rozlišení a použitým ikonkám). Pokud využijete některý z nástrojů pro elektronické KANBAN boardy (existuje i řada nástrojů zdarma), překvapí vás množství různých šablon, které jsou pro KANBAN boardy vytvořené. Rozhodně doporučujeme tyto šablony prostudovat, protože v sobě nesou zaznamenané know-how z procesu řízení toku požadavků a mohou vám usnadnit vlastní zavedení.

Je vhodné také rozlišit barevně jednotlivé typy požadavků. Na našem příkladu jsou červeně chyby, modře požadavky, zeleně zlepšení, oranžově rizika.

Obr. 1: Příklad KANBAN boardu

Omezení rozpracované práce a kapacitní omezení

Omezení množství rozpracované práce (WIP – work in progress) přispívá k tomu, aby se tým soustředil na dokončení rozpracovaných požadavků, protože jinak nemůže začít práce na dalších požadavcích. Nastavení omezení množství rozpracované práce vede ke zkrácení celkového času pro průchod procesem (Lead time).

Abychom využili přínos PULL systému KANBANu, doporučujeme nastavit omezení pro jednotlivé korky procesu tak, jak odpovídá maximální kapacitě pracovníků pro daný krok, aby nemohlo docházet k zahlcení systému. Například, pokud máte na projektu 4 vývojáře, víte, že se mohou věnovat maximálně 4 novým požadavkům zároveň a k tomu ještě zvládnou vyřídit maximálně 4 opravy chyb z produkce. Naproti tomu tým 6 analytiků zvládne připravit současně maximálně 12 požadavků (a je tedy otázkou, zda vzhledem k velikosti vývojového týmu není naddimenzovaný). Pokud v procesu zpracování požadavku dojde k situaci, kdy není možný přechod do dalšího stavu kvůli naplnění omezení rozpracované práce, je toto díky KANBAN boardu snadno viditelné. Celý tým se může zaměřit na odstranění tohoto omezení. Zajistí se tak lepší týmová spolupráce i fakt, že jedna část týmu nebude příliš napřed, nebo naopak zaostávat za zbytkem.

Omezení rozpracované práce má jeden klíčový přínos. Tím je soustředění na vysokou kvalitu dodávky. Díky omezenému množství rozpracované práce je totiž snadno viditelný dopad opravy chyb na celkový čas (Lead time), to vede ke zvýšení kvality vývoje a testování a snížení celkového počtu chyb v produkci. Kombinace průchodu procesem bez čekání a vyšší kvality zkracuje celkový čas, a tím zlepšuje možnost plánování. Stanovení pravidelných termínů releasů a zajištění jejich trvalého naplňování dohodnutým objemem funkčností zvyšuje spokojenost zákazníka a přináší přidanou hodnotu i pro spolupracující útvary, které navazují na výstupy daného projektu.

Tohle není moje práce. Opravdu?

Požadavky nebo User stories, které procházejí procesem zpracování jsou různě velké. Množství práce, kterou zabere analýza, vývoj nebo testování také není jednotné. Snadno se tak může stát, že dojde k situaci, kdy lidé nebudou plně vytíženi, protože budou čekat na dokončení aktivity v procesu před sebou. Jak tomu předejít? Jednou z možností je vytvoření zásobníků práce mezi sloupečky, jakým jsou například požadavky s dokončenou analýzou, připravené jako zadání pro vývoj, případně požadavky připravené pro testování. S těmito zásobníky je potřeba pracovat citlivě (a nastavit omezení množství rozpracovaných požadavků v nich) tak, aby nedocházelo k prodlužování celkového času dodávky.

Další možností, jak lépe využít zdroje, je sdílení určitých činností, pokud to znalostní profil lidí dovolí. Například vývojář může provést analýzu user story, pokud skončil práci na předchozím požadavku. Po dokončení této analýzy může vývojář pokračovat práci na vývoji tohoto požadavku, nebo si vezme ke zpracování další analýzu, podle toho, jaká jsou omezení rozpracované práce a celkový čas.

Poslední možností, jak lépe utilizovat čas, je průběžné začleňování určitých typů požadavků. Uplatní se to hlavně u vývojového týmu. Pokud vývojář dokončil práci na požadavku, může si vzít ke zpracování nový, nebo pracovat na odstranění chyby z produkce, která mezitím přišla. Pro stanovení priorit práce však musí existovat určitá pravidla tak, aby byl dodržený obsah i čas plánovaného release.

Je to hotové! Ale co to znamená?

Věnujte dostatek času jasnému vymezení, kdy je možné přesunout požadavek z jednoho stavu (sloupečku) do druhého. Stanovte si jasná a všemi odsouhlasená kritéria kvality pro tyto přechody. Např. pro přechod z vývoje do testů je zapotřebí, aby byl kód okomentovaný a byly vytvořeny automatizované testy, které bez chyby projdou automatickým buildem. Nejvíce pozornosti věnujte definici, kdy je možné něco označit za zcela hotové, tzn. je možné danou položku přesunout do stavu Hotovo (Done). Tuto dohodu (Definition of Done – DoD) zapište a zveřejněte tak, aby byla všem dostupná. Pomocí kritérií DoD řídíte kvalitu produktu, který vytváříte. Nezapomínejte ovšem na to, že s rostoucími požadavky na kvalitu roste i celková cena dodávky. Do diskuse o požadované kvalitě výstupů zahrňte proto také zadavatele. Doporučujeme také pravidelně vyhodnocovat, zda a nakolik se vám daří kvalitativní kritéria dodržovat a zda jsou správně nastavena. Dobře definovaná kritéria DoD mají ještě další přínos. Je díky nim lépe patrná pracnost, takže zjednoduší diskuse se zadavateli o tom, proč i jednoduché věci stojí více, než jen „pár kliků programátora“.

Kdy je vhodné použít KANBAN?

KANBAN je workflow nástroj pro řízení změny. Při jeho použití začněte s takovým procesem, jaký právě existuje. Vizualizujte ho pomocí jednotlivých sloupečků KANBANu a nastavte úvodní omezení pro množství rozpracované práce podle velikosti týmu a odhadů pracovního vytížení. A poté proces optimalizujte podle toho, kde se vytvoří neefektivity. Hledejte způsoby pro zvýšení spolupráce v týmu a lepší předvídatelnosti výstupů. Klíčovým kritériem je přitom schopnost flexibility a reakce na změnu. Je vhodné věnovat dostatek času týmovým diskusím o tom, jak se nový nástroj osvědčil a průběžně ho upravovat tak, aby vyhovoval vašemu konkrétnímu prostředí a situaci.

http://bit.ly/evamachackova http://bit.ly/zdenekmachacek

Eva a Zdeněk Macháčkovi Autoři článku pracují jako konzultanti ve společnosti Principal engineering. Zaměřují se na strategické poradenství a vzdělávání v oblasti nových trendů businessu a podnikového IT. Stojí také za zrodem projektu www.agileware.eu, který má za cíl zpřístupnit metody a nástroje pro efektivnější práci a úspěch projektů.