Kanban – systém vizualizácie vývoja

Jednou z inšpiratívnych techník, ktorú IT svet objavuje v priemysle, je Kanban. V článku predstavíme tento systém, občas zaraďovaný aj medzi agilné projektové metodiky, ukážeme jeho možné uplatnenie a zmienime sa o nedostatkoch.

Čo je to Kanban

Kanban je systém pre plánovanie výroby (úmyselne sa vyhýbam slovu metodika), založený na reakcii na požiadavky odbytu. V preklade z japončiny znamená štítok, alebo karta, určená na vizualizáciu stavu. Systém hovorí, čo vyrábať, kedy to vyrábať a koľko toho vyrábať. Jeho pôvod sa pripisuje Taiichi Ohnovi, autorovi produkčného systém automobilky Toyota. Cieľom systému je optimalizovať produkciu výrobnej linky, s využitím určitých prvkov „agility“ – vizuálnej komunikácie a zapojenia zamestnancov.

Podstatou Kanbanu je dodržiavanie šiestich hlavných a v celku logických pravidiel:

  • Nepodarok sa nepošle do ďalšieho kroku výrobného procesu.
  • Ďalší krok v procese prevezme z predchádzajúceho iba to, čo potrebuje.
  • Vyrobí sa iba toľko, koľko sa odoberie na konci procesu.
  • Zrovnomerní sa tok výroby.
  • Systém sa bude ladiť Kanban kartami.
  • Stabilizujú a racionalizujú sa procesy.

K dodržiavaniu týchto pravidiel slúži jednoduchý, ale dôvtipný systém indikátorov, ktorým sa prenášajú požiadavky – Kanban karty. Vizualizácia procesu je kľúčovou súčasťou systému, rovnako ako jeho trvalé vylaďovanie. Zlepšenie spočíva v znížení stavu zásob a rozpracovanej výroby medzi jednotlivými výrobnými krokmi, tzv. WIP (Work In Progres). Cielené zmenšovanie WIP a súčasná vizualizácia výrobného toku umožňuje identifikovať problémové miesta, napr. úzke hrdlo, zdržanie, neurčitosti alebo zbytočné činnosti, a tie následne odstrániť.

V priemysle je Kanban ako súčasť Lean Manufacturing pomerne rozšírený a nejedná sa teda o žiadnu novinku. Zmieňujem sa však o tom z dôvodu prenosu znalostí medzi odvetviami. Trvalo viac ako 30 rokov, kým si svet IT všimol, že v priemysle majú inšpiratívny nástroj!

Aplikácia na vývoj software v IT

Systém Kanban je možné aplikovať aj na vývoj software. Väčšina softwarových projektov sa vyrába dielenským spôsobom, kde rozpracovaná výroba je tiež problém. Vzniká napríklad odvolávaním programátorov na iné „dôležitejšie“ úlohy alebo častou zmenou priorít priamo pod rukami. Elimináciou WIP a faktorov, ktoré ho ovplyvňujú, dosiahneme skrátenie výrobného času, zlepšenie kvality, a tým aj väčšiu spokojnosť zákazníka. Tých faktorov môže byť veľa a asi najlepšia poučka na ich rozpoznanie je táto – čokoľvek, čo neprispieva k tvorbe hodnoty pre zákazníka, má byť odstránené. K tomu malú poznámku – ak nevieme rozhodnúť, či akcia prispieva alebo neprispieva k tvorbe hodnoty, má byť tiež odstránená.

Ako Kanban funguje?

Predstavme si štandardný proces výroby, ako je na obrázku. Na začiatku sa zbierajú požiadavky. Môžu to byť samostatné požiadavky na drobnú funkčnosť alebo jednotlivá úloha z väčšieho celku. Nasleduje výber požiadaviek pripravených k výrobe. Ten určuje vlastník produktu alebo správca požiadaviek podľa dôležitosti. Môže sa uplatniť prioritizácia, takže vyššie postavená požiadavka je dôležitejšia. Požiadavka sa rozpadne na úlohy. Tie by nemali byť veľké – z úlohy nad 8 hodín je lepšie urobiť dve menšie. Ďalší krok je Výroba – úlohu si prevzal vývojový tím. Hotový produkt si prevezme Testovanie vo forme dema a prezentuje ho zákazníkovi. Až zákazník produkt prevezme, vyradí sa z procesu výroby.

Příklad tabule Kanban

Příklad tabule Kanban

Teraz si predstavme, že obmedzíme množstvo úloh vo fáze Výroba na maximálne 2  úlohy. Počet môže súvisieť napríklad s počtom vývojárov. Vývojový tím si zo zásobníka požiadaviek vezme prioritizovanú úlohu, presunie štítok na Kanban tabuli a začne na úlohe pracovať. Presun štítku je dôležitý, to je ten vizuálny signál. Správca úloh vidí, že sa uvoľnilo miesto a doplní ďalšiu úlohu zo svojich požiadaviek. Vývojový tím ukončí úlohu a čaká, kedy oddelenie testovania odoberie úlohu, aby si mohol vziať ďalšiu. Pretože v produkcii môžu byť maximálne 2 úlohy, prijať ďalšiu nie je možné.

 Pri správne vyladenom výrobnom toku nebude čakať dlho. Ak sa čakanie pretiahne, povinnosťou voľného tímu produkcie je ísť a ponúknuť pomoc testovaciemu oddeleniu dokončiť ich úlohy testovania. Ak sa takáto situácia vyskytuje často, je zrejmé, že v procese je problém a je potreba navrhnúť opatrenie. Opatrenie navrhujú a implementujú spoločne Výroba a testovacie oddelenie.

Stále platí, že v každej etape procesu môže byť iba toľko úloh, koľko ich je pre danú etapu povolených. Tým sa redukuje rozpracovaná výroba. Prioritné požiadavky do výroby je možné prijímať iba výmenou za inú požiadavku v boxe úloh pripravených k výrobe. Po nabehnutí systému sa dá určiť, ako dlho trvá spracovať jednotlivú úlohu v procese výroby a teda ako dlho bude musieť zákazník čakať, kým jeho požiadavka bude spracovaná. Toto je pomerne efektívny spôsob regulovania záťaže programátorov, sledovania produkcie a poskytovania odhadov pre management a obchod.

Možné príklady použitia

Malé projekty

V prípade malého projektu, tj. rozsah do 100 až 150 hodín, sa väčšinou nepodarí efektívne nasadiť SCRUM alebo inú štandardnú metodiku. To nastáva napríklad u mnohých projektov webových aplikácií. Jednoducho projekt je príliš malý. V takomto prípade je možné prioritizovaný zoznam požiadaviek spracovávať priebežne bez delenia na iteračné etapy. Systém je veľmi flexibilný k realizácii zmien. Zmeny sa môžu realizovať buď zmenou požiadavky v zásobníku požiadaviek, alebo vrátením už spracovanej požiadavky na začiatok. Ak jednotlivé úlohy ohodnotíme náročnosťou, môžeme sledovať objem realizovanej práce. To je výhodné aj pri plánovaní projektu a odhadoch náročnosti, nakoľko máme k dispozícii reálne dáta o výkone produkcie.

Servis a Customer Care

V prípade servisu vznikajú požiadavky na úpravy aplikácií ad-hoc podľa prianí zákazníka alebo podľa objavujúcich sa technických porúch. Väčšinou sa jedná o drobné úlohy s dobou spracovania do 20 hodín. Požiadavky preto môžu byť priebežne prioritizované servisným pracovníkom podľa urgentnosti a najdôležitejšie zakladané do požiadaviek k výrobe. Nevadí, ak sa požiadavky týkajú rôznych projektov. Ich premiešanie nemusí byť na prekážku. Tu je vyladená produkcia výhodou. Zákazníkovi dokážeme pomerne dobre odhadnúť, kedy svoju požiadavku bude mať hotovú.

Nevýhody Kanban

Kanban je v prvom rade systém. Nie je to metodika a preto neobsahuje nástroje na správu komunikácie s klientom, riadenie tímu ani spôsob prípravy zadania pre úlohy. Tieto nástroje je dôležité  doplniť  podľa zvyklostí tímov.

Pretože Kanban je navrhnutý na riadenie toku výroby, efektívne mení vývojové oddelenie na výrobnú linku. V počiatočnej fáze sa proces ladí, a tak sa účastníci nevyhnú agilnému prístupu k riešeniu problémov. Časom sa ale z procesu stane rutina, so súvisiacim poklesom záujmu a teda aj výkonu. Záleží iba na tímoch, ako si nastavia spoluprácu a predovšetkým komunikáciu pri jednotlivých produkčných krokoch. Možným riešením je zaviesť krátky ranný míting, kde by sa prediskutovali problémy toku, ktoré sa objavili v predchádzajúci deň a tiež aby si členovia tímov udržali nadhľad. Riziko rutiny je väčšie v servise.

V systéme Kanban sa neuplatní komunikácia so zákazníkom a jeho zapojenie do tímu. To vnímam ako veľkú prekážku, pretože spolupráca so zákazníkom je dôležitým prvkom vývoja. Poslednou nevýhodou je strata rytmu, ktorý napríklad v agilných metodikách zaisťujú iterácie. V týchto situáciách záleží výhradne na skúsenosti manažéra a vývojového tímu, ako upraví pravidlá, aby tieto prekážky mohli byť prekonané.

Systém Kanban je zaujímavý nástroj, ktorý môže byť výhodný aj v ďalších než v uvedených situáciách. Preto si myslím, že by mal byť zahrnutý do portfólia nástrojov projektových tímov.

ScrumMaster, manažér a tréner agilných metodík. Spoluzakladateľ združenia Agilní Konsorcium, ktoré propaguje agilné projektové metodiky do IT priemyslu v ČR a na Slovensku, organizuje školenia, konferencie a pracovné worshopy.

Věděli jste, že nám můžete zasílat zprávičky? (Jen pro přihlášené.)

Komentáře: 17

Přehled komentářů

Karel Inspirace letem vlaštovky
Michal Illich Re: Inspirace letem vlaštovky
Karel Re: Inspirace letem vlaštovky
backup Re: Inspirace letem vlaštovky
fuzzy Re: Inspirace letem vlaštovky
harvie Re: Inspirace letem vlaštovky
Botanicus Zkusenosti s kanbanem
František Kučera Re: Zkusenosti s kanbanem
PanPetr Re: Zkusenosti s kanbanem
fuzzy Nechci být přehnaně kritický, ale ...
panass pro it
deepj Re: Kanban – systém vizualizácie vývoja
Karel Re: Kanban – systém vizualizácie vývoja
mvallo Re: Kanban – systém vizualizácie vývoja
fuzzy Re: Kanban – systém vizualizácie vývoja
mvallo Re: Kanban – systém vizualizácie vývoja
jezibaba nedobrý článek
Zdroj: https://www.zdrojak.cz/?p=3290