Přejít k navigační liště

Zdroják » Různé » Kanban – systém vizualizácie vývoja

Kanban – systém vizualizácie vývoja

Články Různé

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.

Nálepky:

Č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.

Komentáře

Subscribe
Upozornit na
guest
17 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Karel

Kanban je metoda řízení zásob a výroby pro hromadnou výrobu a zásobování. Jeho efektivita roste s objemem skladů a/nebo výroby. Tato metoda je absolutně nevhodná na kusovou výrobu! Kanbanová karta je předtištěná (nic se na ní nedopisuje) a funguje jako jednoznačný signál k nějaké akci. Například jako první uvolníme kartu „židle“. Tu dostanou ti správní lidé a automaticky ví, co se od nich čeká – vydají další kanbanové karty na podsestavy (sedátko, rám), ty dostanou další lidé, kteří vydají karty na materiál. Jakmile dostanou materiál, vyrobí podsestavy, ty se předají montáži a ta sestaví židle. Takže hybným momentem jsou kanbanové karty a fungují právě proto, že každý podle kartičky jednoznačně ví, co má udělat. Ty kartičky jsou jednou vytištěné, předané do výroby/skladu a lidé jsou vyškolení, co každá jedna karta znamená. Jakmile přijde nějaký požadavek, lidí vytáhnou kartičky ze šuplíku a jedou. Je zřejmé, že navržení kartiček nebude triviální a že efektivita systému bude přímo úměrná „životnosti“ kartiček. Pokud se bavíme o zakázkové kusové výrobě (analogie vývoje SW produktu), pak je nesmysl trávit týdny designem kartiček, celé to za pár hodin vyrobit a pak kartičky zahodit.

Takže metoda podobající se kanbanu nemá ve vývoji SW místo. Má smysl u servisních činností, kde skutečně není problém vytipovat několik standardních úloh (nový uživatel, měsíční uzávěrka apod.) a pro ně kanban použít. Ovšem na cokoliv jiného, kde samotné zadání nevede na jednoznačný sled akcí, je kanbanem nepodchytitelné. Nehledě na to, že na to existují lepší nástroje a metody, které jsou schopny sledovat například stav (zadáno, schváleno, v procesu, k testování, zrušeno atd.), historii (kdo to programoval, kdo to testoval atd.) a hlavně umí podat globální pohled (v jakém stavu jsou jednotlivé akce). V kanbanu žádný stav není (karta = akce, buď exituje, nebo ne), historie není v zásadě žádná (je to zásobník práce, kolikrát tam není ani adresnost materiálu) a globální pohled není možný, protože je dán stavem karet na jednotlivých pracovištích (pokud za globální pohled nepovažujete možnost projít se výrobními halami a zapsat si jaké kartičky jsou na jakém pracovišti).

Zkrátka, metoda kanbanu je ve vývoji prakticky nepoužitelná, protože vývojový proces není třeba opakovat (že bych si ze cviku každý den ráno znovu a znovu progamoval přihlašovací dialog?) a většina činností není standardizována. Navíc se na jednom úkolu obvykle podílí malý tým lidí, místo aby se jednalo o sled akcí prováděných v pevně stanoveném pořadí různými lidmi. Na činnosti, které standardizované jsou (založení uživatele apod.), již máme lepší nástroje, například helpdeskové tickety.

A koneckonců něco podobného prezentuje i tento článek. Sice povídá o kanbanu, ale přebírá jen vizuální podstatu věci, že někdo něco napíše na nějakou kartičku a tu někde vystaví. Narozdíl od kanbanu je ovšem každá kartička unikát a dokud se úkol nezačne řešit, tak ani není zřejmé, co to bude obnášet. A v neposlední řadě se očekává, že někdo kartičky bude neustále přepisovat. Jenže to jsme u klasického ticketového systému a ten s kanbanem nemá nic společného. Jasně, můžeme o ticketu hovořit jako o kartičce a dovozovat, že vše, kde je nějaká karta, je kanban. Jenže ta inspirace je asi tak přesná jako tvrdit, že moderní helpdeskové nástroje jsou inspirovány letem vlaštovky. Akorát se místo vlaštovky přesunují data.

Michal Illich

Kanban Software Development samozřejmě nepoužívá fyzické předtištěné karty :) – že se tomu říká Kanban, je přirovnání.
Vývojáři obvykle nemají problém s abstrakcí, proto snad článek pochopí.

Karel

Kdo nezná výrobní kanban, ten to nejspíš opravdu pochopí. Kdo ale výrobní kanban zná, tak bude zmaten, protože se tady používají výrazy, které ale znamenají něco jiného. Ano, firmy typu níže uvedeného agilezen.com opravdu používají terminologii jako je „kanban board“ nebo „lean“, ale označují tím úplně jiné věci a jde z jejich strany o hype (chcete něco prodat výrobářům? používejte jejich výrazy). V projektovém řízení se v oblasti IT (a už nejen tam) používá termín „kanban board“ pro nástěnku, na kterou se lepí takové ty „post it notes“, upravují se, přesouvají atd. Jenže když se podíváte na „výrobní kanban board“, tak vypadá úplně jinak – je to defakto skříň s hromadou šuplíčků, ve kterých jsou předtištěné kartičky. Tyhle dva „kanban board“y mají spolu asi tolik společného, jako s kreslicím prknem strojaře. Jo, všechno je to ploché a velké. Nijak nekritizuji kvalitu IT nástrojů, třebas ten „IT kanban board“ je výborná věc, sám ho používám již několik let (naučila mě to jedna z knih E.M.Goldratta a neříkali tam tomu kanban). Jen mi vadí, když někdo tyhle věci začne pojmenovávat úmyslně tak, aby vzbudil zdání, že to má něco společného se zaběhlými metodami z jiných oblastí. Nemá. Jediné, v čem se IT svět u výrobního kanbanu inspiroval, je název. Průměrný člověk z průmyslu si při spojení výrazů „řízení projektu“ a „kanban“ poklepe na čelo.

backup

ja s Vami souhlasim, ze rizeni projektu a kanban je nesmysl a jak rikate, kazdy z te prumyslovky vi, ze kanban ma smysl pouzit v seriove produkci a kdyz zde v clanku autor navic napise, ze vyroba software se da prirovnat k te dilenske (coz je samozrejme uplna pitomina), tak nastava to klepani na celo.
Ale, na druho stranu se nelze divit. Pracovnich mist ve vyrobe ubyva (s rostouci produktivitou) a lide (lidstvo) si musi najit nejake zastupne cinosti. Proto je rada lidi v oblasti planovani, rizeni apod. a pro tyto ‚pracujici‘ zase dodavaji jini ‚pracujici‘ nastroje, jak jeste ‚lepe‘ tyto cinosti planovat. A protoze jist se musi, tak se ty nastroje musi prodat, at uz jsou nesmyslne ci nikoliv a proto je zapotrebi marketingovych triku. A autor clanku je budto jeden z tech, ktery ty marketingove pohadky zere a nebo kope za tu firmu, ktera ty nesmysly prodava. Takze nam to muze vadit, ze nekdo pouziva zavadejich informaci, ale dnesni postkapitalisticka spolecnost je takova a cinkani klicu pred 20 lety rozhodlo, ze to tak bude.

fuzzy

Kanban je výborná věc na řízení neiterativních činností v IT – to je například support kde průběžně přibývají úkoly a nejde definovat nějaké „iterace“ (často se to uvádí jako alternativa ke SCRUMu který je ze své povahy iterativní).
Problém (obecně i tohoto článku) je v tom že existuje více variant Kanbanu které se hodí pro různé oblasti (od sériové produkce po IT), které sice sdílejí cíle a základní principy, ale forma se celkem výrazně liší.
A to je v článku podáno dost zmateně, bohužel :-(

harvie

tak moment… kartičky už hotové jsou v bugzille (nebo ještě lépe v mém oblíbeném flysprayi)… a každá prochází kanbanovými fázemi tak jak se mění její status z NEW/UNVERIFIED až k FIXED/WON’T IMPLEMENT.

Botanicus

Kanban jsme pouzivali na me minule pozici a musim rict ze fungoval velmi dobre i presto ze produkt ktery jsme vyvijeli byl opravdu velky. Pouzivali jsme fyzickou kanban board, pozdeji skvely online system agilezen.com. Fyzicka board byla samozrejme lepsi, ale nehodi se kdyz lidi pracuji remotely.

František Kučera

To už je trochu degenerace takováhle czenglish.

PanPetr

A nehodí se ani když lidé pracují vzdáleně.

fuzzy

… mám dojem že potenciální zájemce článek spíš zmate, resp. nedovedu si představit že bych na jeho základě začal Kanban využívat při vývoji software :-(
Nejdříve jedna konkrétní připomínka ke článku – ve druhém odstavci je uváděno šest „logických pravidel“ jejichž dodržování má být podstatou Kanbanu. Vtip je v tom že minimálně dvě „pravidla“
* zrovnoměrnění toku výroby
* stabilizace a racionalizace procesů
jsou spíše cíle / důsledky Kanbanu.
Existuje spousta různých variant Kanbanu (dle odvětví apod.) ale skutečně základní pravidla Kanbanu jsou IMHO dvě:
* vizualizujte stav práce (štítky aka „kanban karty“ na nástěnce aka „Kanbanu“)
* omezení množství rozpracovaných úkolů „WIP“ (dle stavu, tj. dle sloupců na Kanbanu)
Obecně připouštím že paralely mezi aplikací Kanbanu v průmyslu a v IT jsou zajímavé, ale pro ty kteří o Kanbanu nic neví je to spíš matoucí záležitost protože paralely jsou vidět až ex-post (poté co člověk pochopí o co v Kanbanu vlastně jde a jak se snaží problémy řešit).
Pokud někdo chce Kanban používat (ať už v IT nebo i pro řízení jiných procesů), vřele doporučuji knížku „Kanban and Scrum – making the most of both“ která je zdarma ke stažení na infoq.com, ve které je to skvěle a názorně vysvětleno (principy, použití atd.). BTW stejně tak je tam ke stažení i výborná knížka „Scrum and XP from the Trenches“ o SCRUMu. Obě knížky vřele doporučuji, o SCRUMu i Kanbanu jsem toho přečetl hodně a tyhle dvě všude doporučuji.

panass

mi prijde, ze to celkem pekne zastresuje greenhopper (= mj. implementuje to dobre z kanban) od atlassianu.

deepj

Tento clanek je uplne mimo.
Nevim, proc autor popisuje 6 pravidel kanbanu, ktere jsou oznacovany jako Toyata’s six rules, ktere se pouzivaji v Toyata Production System, ktery absolutne nesouvisi vyvojem software. Tech pravidel je vice, zalezi na konkretni aplikaci kanbanu. Videt, ze autor se seznamil s pojmem kanban, ale v zivote to v praxi nepouzil.
Pan Karel je taky ponekud mimo, protoze mu unika zakladni smysl kanbanu a popisuje tu vesele konkretni aplikaci kanbanu v seriove vyrobe, ktera je nejvice znama na nejpouzivanejsi.
Kanban se pouziva pro rizeni jako planovaci system, ktere rika co, kdy a jak produkovat. Kanban se vyuziva v cele rade pripadu od logistiky pres seriovou vyrobu, vyzkum az po ten softwarovy vyvoj. Kdyz to abstrahujete na ten zaklad, tak kanban je jen prach obycejna informacni tabule a jiny vyznam to ani nema.
Pro pana Karla: Ano, co je na agilezen.com, je kanban board, i kdybyste se stavel na hlave. Protoze je to nic jineho nez informacni tabuli.
Bych to shrnul, kanban je jen obycejna informacni tabule, pak je dulezita aplikace v dane oblasti. Takze kanban urceny pro vyrobu je uplne jiny nez pri vyvoji softwaru.

Karel

Jasně, je to kanban. Je to tabule. Co jsem napadal je marketingový trik uvedený v článku „poučme se kanbanem z výroby“, protože s tím má opravdu společného jen tu tabuli.

mvallo

Knižka „Kanban and Scrum – making the most of both“ je určite zaujímavá. Len je treba dať pozor, pretože tu je systém Kanban v tvare konkrétnej implementácie v konkrétnej firme porovnávaný s metodikou SCRUM. Úvod od Mary Poppendieck to už nezachráni. Voči kapitole 4 Timeboxing mám výhrady, prípadne tiež voči ilustrácii Scrum Nutshell. Ale jedna myšlienka sa mi tam veľmi páči –„Don’t limit yourself to one tool!“ – alebo „neobmedzujme sa iba na jeden nástroj!“. A to je asi to hlavné.
Nesúhlasím s p. Karlom v tom, že by technika Kanban nemala vo vývoji IT čo robiť. Osobne považujem organizáciu práce vývoja software v tíme za veľmi podobnú tej výrobnej linke. Na mnohé projekty, ktorých som sa zúčastnil, sa takýto postup v celku hodí. A v tomto kontexte je Kanban naozaj iba informačná (vizualizačná) tabuľa.
Zrovnávanie s výrobou alebo inými odvetviami považujem za veľmi užitočné. Veľa IT postupov, ktoré sa dnes vo vývoji software používa bolo inšpirovaných výrobou alebo priemyslom. Či je to vodopádové riadenie projektu, alebo SCRUM, a mnohé ďalšie.
Pri príprave článku som však nikde nenarazil na „štandardnú“ definíciu Kanban pre IT. Nejaký nápad? V prípade SCRUM je to totiž jednoduché – Ken Schwaber, SCRUM.

fuzzy

No ale účelem knihy „Kanban and Scrum – making the most of both“ je právě srovnání těch dvou nástrojů, takže nerozumím proč by předmluva Mary Poppendieck měla cokoliv „zachraňovat.“ Pokud znáte alespoň jeden z těch nástrojů tak tohle je ideální způsob jak představit ten druhý – ukázat v čem se liší a naopak jaké ideje mají společné.
Ne, pokud vím tak žádná „jediná správná definice“ pro Kanban není, což má za následek že existuje spousta různých variant pro různé oblasti (od pásové výroby aut kde se produkují stále stejné výrobky stále dokola až po support v IT). Ano, všechny směřují ke stejnému cíli – k plynulosti procesu. To znamená že nic se nikde nesmí hromadit ani chybět, a je jedno jestli jde o části aut v továrně nebo „tickety“ popisující řešené problémy. Všechny to víceméně dělají pomocí něčeho čemu se říká kanban (tabule) a kanbanové karty (dávají se na tabuli a ukazují postup zpracování).
Ale to zdaleka neznamená že by se Kanban z továrny dal vzít a přenést 1:1 do IT, to je nesmysl. Totiž zatímco v továrně se produkují vesměs stále stejné výrobky (a jsou požadovány dodávky stále stejných dílů), v IT jsou úlohy do jisté míry unifikované (tak aby mohly protékat stejným procesem znázorněným na tabuli) ale jinak jsou každá naprosto unikátní. A to je myslím přesně to co měl p. Karel na mysli.
Příklad – před pár dny jsem v televizi (ČT24 nebo Z1) viděl cca 15 minutový díl pořadu věnovanému „lean“ metodikám v podnikání. Tentokrát se jednalo o firmu produkující cosi pro velké kuchyně (roboty, velké sporáky apod.), a kromě použití Kaizenu popisovali i jak používají Kanban pro řízení objednávání zboží, a demonstrovali to na papírech do tiskárny.
Mají polici ve které jsou vyskládány balíky papírů, šipkami od zelené po červenou mají vyznačeno ze které strany se mají balíky brát – berou papíry, až dojdou k červené šipce (tj. zbývá posledních několik balíků papírů které jim vystačí cca na 14 dní) tak se jim pod balíkem objeví kanbanová karta, kterou vezmou a hodí do krabice na dveřích. Jednou za týden to projdou, posbírají karty ze všech krabic (týká se to i dalších kancelářských a dílenských potřeb), a podle karet objednají co je potřeba.
Mají kanban tabuli? Nemají, vystačí si s kartičkami. Je to Kanban? Ano, je to jedna z variant kanbanu. Lze to jednoduše přenést do vývoje SW? Nejde, protože nejde udělat kartičky na „funkční celky.“

mvallo

Možno som topresne nevystihol. Uvedená kniha je v IT svete častokrát považovaná za definíciu Kanbanu, a tou podľa mňa nie je. Aby autor zvýšil kredibilitu, tak si nechal od Mary Popendieck urobiť príhovor. Proste bežné PR. V každom prípade, je to zaujímavá kniha.
V článku som ukazoval, že práve inšpirácia v iných odvetviach, v tomto prípade vo výrobe, je zdrojom inovácie. Prevziať proces vo výrobe a implementovať ho do IT samozrejme možné je, však o tom ten celý Kanban je. Nakoľko je Kanban systém, dá sa očakávať, že si ho implementačné tímy prispôsobia.
Čo sa výroby týka, nepredstavujte si ju ako pásovú veľkovýrobu jednej veci. Dnes je výroba riadená spotrebou a tak sa robia buď malé série alebo každý kus je vlastne zákaznícka modifikácia. Takže proces výroby tiež musí byť dostatočne flexibilný.
Ako implementáciu do IT som ukazoval obmedzenie toku požiadaviek do produkcie a definovanie jasných pravidiel pre prechod výrobou. Vývoj software nie je ničím špecifický, čo by takémuto použitiu bránilo. Ak to niekoho zaujme, nájde si v literatúre alebo na Internete dostatok príkladov pre vlastný experiment. Či bude vizualizovať na tabuli alebo v Bugzille je už v celku jedno.

jezibaba

Nemůžu se zbavit dojmu, že celý článek je poměrně zmatený a je to takový dort od pejska a kočičky.
Ještě, že čtenáři rootu poměrně ochotně doplňují informace i k takovýmto článkům.
Docela by mě zajímalo, zda autor někdy v realném provozu danou metodiku vyzkoušel nebo patří do skupiny „něco jsem si přečet, tak s tím hurá do světa“.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.