Kanban board je jedním z nástrojů, který lze použít při implementaci metody řízení vývoje Kanban .
Tyto desky lze považovat za variaci na tradiční kanban karty. Místo signálních karet, které obvykle indikují poptávku nebo propustnost, se spolu s tabulí používají magnety, plastové žetony, barevné puky nebo nálepky, které představují pracovní položky a procesy. [1] Každý z těchto objektů představuje fázi výrobního procesu a pohybuje se v průběhu celého plánu. Tento pohyb odpovídá pohybu výrobního procesu. [2] Tabule je obvykle rozdělena do tří logických částí: „čekání“, „probíhající práce“ a „dokončená práce“. Zaměstnanci přesunou poznámky do části nástěnky, která odpovídá stavu úkolu. [3]
Metodika Kanban může být použita k uspořádání mnoha oblastí života. Existuje mnoho variant desky Kanban.
Nejjednodušší nástěnky se skládají ze tří sloupců: „to do“ ( anglicky to-do ), „in progress“ ( in progress ), „done“ ( done ). [čtyři]
Nejoblíbenější interpretace kanban boardu pro agilní vývoj nebo tzv. štíhlý vývoj obsahuje tyto sloupce podle stavu úkolů: projednáno ( backlog ), dohodnuto ( připraveno ), kód napsaný ( kódování ), testováno ( testování ), potvrzeno ( schválení ) a hotovo ( hotovo ). Je také běžnou praxí pojmenovávat sloupce jinak, například: další, vývoj, hotovo, schválení klientem, odeslání změn na produkční server [5] .
Kromě možnosti přejmenovávat sloupce / stavy na Kanban boardu je také možné zvýšit počet sloupců, ale to se děje s podmínkou rozdělení stávajících.
Ačkoli kanban board byl původně implementován ve fyzické podobě, mnoho týmů, zejména distribuovaných, pochopilo použitelnost online boardů [12] .
Vývoj online nástěnek ve stylu Kanban dostal nedávno nový impuls. Důvodem je nutnost pracovat na dálku pomocí metodiky Kanban .
Ve vývojových procesech, stejně jako v jiných oblastech činnosti, není vždy možné okamžitě „nahmatat“ správnou cestu, často musíte zažít spoustu trnů. Budoucí životnost produktu nebo služby závisí na volbě vhodné metodiky vývoje. Shrnuli jsme 13 výhod implementace Kanban pro vývoj softwaru.
Pojďme analyzovat následující příklad, uvažujme dvě situace.
První situace – představme si továrnu na dopravníky v sovětských dobách, jejíž činnost přímo závisela na státním plánu. Tento plán jasně definoval množství výrobků pro výrobu. V důsledku toho přeplněné sklady kvůli tomu, že navrhovatelé Státní plánovací komise mohli často chybovat s poptávkou. Produkt se nestihl prodat.
Druhou situací je v těchto dnech showroom Toyota. Kupující si vybere model a zaplatí. Toyota však v tuto chvíli nemá barvu vašeho vozidla skladem. Objednávka je odeslána do centrály Toyota. Budete informováni, kdy bude auto předáno. Teprve od té chvíle se vůz začal vyrábět. Speciálně pro vás. Platí zásada: nejprve prodej, pak výroba. Jinými slovy, just in time (JIT) funguje. Nejprve cíle a termíny, pak plán a práce.
Zásoby Toyoty nebudou přeplněné, protože v první situaci nebudou muset držet předem vyrobené díly po dlouhou dobu. Je to proto, že to, co se právě vyrábí na lince, je požadovaná sazba pro některé nedávno prodané stroje.
Jednou z klíčových součástí principu JIT je Kanban. Kanban desky a karty jsou jakési semafory v systému just in time. Kanban umožňuje podnikům reagovat na potřeby zákazníků namísto předvídání potřeb, jak tomu bylo v první popsané situaci.
Můžete promítnout podobný příklad jako oblast vývoje softwaru:
Místo náhradních dílů - vývojové úkoly nebo chyby. Tester obdrží několik úkolů ke kontrole. Když QA dojdou úkoly ke kontrole, musí upozornit programátory, aby od nich dostal nové úkoly. Pokud programátoři nemají čas dokončit nové úkoly, tester prostě zůstane nějakou dobu bez práce.
Nastává i opačná situace: QA má hodně úkolů a on/ona nestíhá vše včas zkontrolovat. V tomto případě je také zpožděno datum vydání produktu.
Při vývoji softwaru je vyvážení Kanban mnohem obtížnější než ve výrobě. Ovlivňuje specifika práce: pokud stroje vyrábějí stejný typ dílů, pak programátoři pracují s kódem vlastním úsilím mozku, ve kterém je asi 100 miliard neuronů a jeden, ale významný lidský faktor.
Výhody Kanbanu jsem naplno objevil v roce 2008, poté používám Kanban desky všude: od osobního plánování, vývoje až po implementaci Kanbanu v keramické dílně.
Zde je 13 důvodů, proč byste měli implementovat Kanban v IT společnostech, které se zabývají vývojem softwaru:
Přechod na Kanban boardy z běžných seznamů úkolů nám okamžitě ukázal úzký profil: velká fronta úkolů nahromaděná ve sloupci Testování. Naše kontrola kvality si nedokázala poradit s kontrolními úkoly. Úkoly k ověření bral s velkým zpožděním. Poté, co tester vrátil úlohu k přepracování, programátor ji již stihl zapomenout. Musel jsem se znovu podívat na kód a zapamatovat si podrobnosti. Jak si dokážete představit, je to vzácný čas. Tým potřeboval dalšího testera.
Kanban board vám umožňuje vidět úzká místa ve vašem procesu, kde se tvoří fronty. V Hygger.io s tímto úkolem pomáhají limity WIP. Pokud máte více nebo méně úkolů, než potřebujete, sloupec je zvýrazněn červeně nebo žlutě.
Často je důležité pořadí, ve kterém jsou funkce vydávány. V prioritních seznamech je obtížné přesně řídit objednávku. Pokud má programátor pět úkolů s hlavní prioritou současně, bude pro něj obtížné zjistit, který z těchto úkolů má vzít jako první.
Kanban board jen nabízí východisko ze situace, kdy na pořadí záleží. Toto vizuální řešení je vertikální sloupec s úkoly. Čím vyšší je úkol, tím je důležitější. Kanban mimochodem zahrnuje stanovení priorit jako jeden z důležitých aspektů metodiky. Požadavky se neustále mění, mnoho úkolů může ztratit svou relevanci a „klesnout“ dolů. Některé úkoly mohou naopak prudce „vzrůst“. Manažer musí neustále „držet prst na tepu“, aby programátoři udělali to nejnutnější.
Kanban vás naučí soustředit se na hlavní věci. Něco, co skutečně přidává hodnotu produktu. Dokázali jsme „snížit“ spoustu zbytečných chyb a vylepšení. To přineslo výsledek.
Rozlišení důležitých chyb od těch menších není pro produktového manažera snadný úkol, ale právě zde přichází na pomoc funkce Swimlanes. Toto jsou vodorovné sloupce na desce Kanban. Programátoři mají na desce zpravidla takové Swimlanes:
Systém je podobný Eisenhowerově kvadrantu. Důležité a naléhavé záležitosti jsou blokátory. Důležité, ale ne naléhavé – Úkoly a chyby. Nedůležité a naléhavé, stejně jako nedůležité a nenaléhavé - to je někdy. Mimochodem, absence vodorovných sloupků je jedním z faktorů potvrzujících to, co Trello pro Agile vývoj chybí.
Programátor se musí soustředit na svou práci. Proto je dobré, když dostane frontu úkolů a nemusí přemýšlet, co dál, na to už manažer myslel. Stačí se chopit dalšího úkolu nebo chyby.
Někdy Kanban zahrnuje nezávislý výběr jakýchkoli úkolů programátory shora. Pak by měla být odborná úroveň všech lidí rovná, aby se nestalo, že ten nejtěžší úkol „padne“ na juniorského specialistu.
Filtr Moje úkoly vám pomůže zaměřit se na vaše úkoly. Pomůže vám rychle zobrazit úkoly na tabuli.
Před očima - celý obraz projektu. Otevřením nástěnky můžete rychle získat odpovědi na důležité otázky:
Kanban vám pomůže stát se flexibilnějšími. To je zvláště nutné, když je produkt uveden na trh a dostává mnoho užitečné zpětné vazby. Jedná se o podpůrné zprávy, analýzy chování, výsledky a/b testů, recenze atd. Jakmile „nahrajeme“ novou funkci do produkce, okamžitě ji začneme měnit na základě zpětné vazby. Dříve programátor nechtěl dělat „levé“ úkoly a bál se „zaplnit“ termíny sprintů. Podle Kanbanu pracuje programátor jako procesor: jeden cyklus – jeden úkol.
Čím častější cykly, tím flexibilnější se vývojový tým stává. Pro náš tým je ideální takt 8-12 hodin. Velké úkoly je třeba rozložit.
Scrum zabral hodně času vyhodnocení funkcí před začátkem sprintu. S Kanbanem není potřeba hodnocení. Když to uděláme, pak to bude hotovo.
Scrum zahrnuje hodně komunikace. Začátek sprintu je doprovázen plánováním: analýzou a hodnocením úkolů. Stojany jsou vyžadovány každý týden. Po skončení sprintu se koná retrospektiva. Výsledkem je, že veškerá komunikace zabere asi 30 % času. Tentokrát ale mohl tým věnovat práci.
S Kanbanem začíná tým pracovat důsledněji. Nyní tester zkontroluje funkci téměř okamžitě poté, co ji programátor vytvořil. Podobně i v dalších oblastech: designéři, UX, redaktoři, prodej.
Dříve QA nekontrolovala funkci, když ji vytvořil programátor, ale po dlouhé době. Během této doby se programátorovi podařilo zapomenout na vše na světě, včetně detailů tohoto úkolu.
Ve Scrumu „nahráváme“ funkce do produkce až na konci sprintu. Cca jednou za 3 týdny. V Kanbanu téměř okamžitě po přijetí testerem. Jednou za pár dní.
Rychle tedy zjistíme, zda se funkce mezi uživatele dostala nebo ne. Pokud ne, někde se stala chyba. A pro nás je důležité, abychom byli první, kdo chybuje. To neznamená, že rádi děláme chyby. Pokud se ale o chybě dozvíme jako první, budeme první, kdo se dozví a rozhodne, co dělat.
Není potřeba neustále „tahat“ programátory. Otevřeli jsme Kanban nástěnku, rychle se podívali, kdo a co dělá, všechny stavy a můžete se klidně vrátit do managementu. A programátor je i nadále ve stavu neustálého pohybu a v očekávání nových výšin.
Dříve programátoři nevěděli, co jejich kolegové dělají. Nyní s Kanbanem může programátor, stejně jako manažer, jít na tabuli a podívat se, co dělají kolegové. Tyto informace potřebují ke koordinaci společného úsilí na projektu.
Dříve se programátor zabýval několika úkoly najednou paralelně. Mohl jsem si vybrat úkol podle nálady, nebo jsem mohl úplně zapomenout na to, co jsem dělal v pátek v pondělí.
Nyní limity WIP a panoramatický pohled správně omezují programátora: nemůže dělat více než jeden úkol najednou.
Jako závěrMůže se zdát, že trváme na tom, že Kanban je lepší než Scrum. Ale není. Vše má svůj čas. Zkušenosti Hyggera naznačují, že Scrum se dobře hodí na začátku vývoje produktu a Kanban je vhodný, když produkt již vstoupil do arény.
Kanban není všelékem pro každý byznys. Pokud postavíte žebřík ke špatné stěně, bez ohledu na to, jak strmě po něm lezete, stejně skončíte na špatném místě. Kanban je tedy nezbytnou, ale ne postačující podmínkou úspěchu produktu nebo projektu.