Súvisí to aj s touto témou „Ako nefunovať agilne“, pretože to, akým spôsobom je Kanban tabuľa nastavená, spôsobuje neskôr problémy pri fungovaní Agile a je príčinou všelijakých pachutí ohľadom Agile. Prečo používate Kanban tabuľu? V praxi na tabuliach chýba “limituje rozpracovanosť”. Prečo by sme vlastne potrebovali limitovať rozpracovanosť? Veď mi predsa potrebujeme dodávať – dodávať viac, dodávať rýchlejšie. My potrebujeme využiť kapacity, my potrebujeme začať na tom ďalšom pracovať. A práve, paradoxne, tabuľa má napomáhať limitovať a maximalizovať efektivitu toku. V preklade, tabuľa by vám mala pomáhať úlohy čo najskôr dokončovať, nie rozpracovávať. Tak, ako tečie rieka, od prameňa až k moru, vy potrebujete urobiť dodávku, ten tok, čo najrýchlejšie, a preto by vám mala pomáhať zvyšovať efektivitu. Akékoľvek ďalšie obmedzenia, napríklad keď kvôli controlling potrebujete doplniť ďalšie položky a pri každej zmene potrebujete tie položky aktualizovať, vám spôsobuje zníženie efektivity toku. Takže treba sa zamyslieť nad tým, v akých momentoch akú informáciu budeme potrebovať. Elementy dobrej Kanban tabule Základné elementy dobrej Kanban tabule sú v podstate veľmi jednoduché. V prvom rade je prevláda nepochopenie na čo slúži Kanban tabuľa. Kanban tabuľa je mnohokrát nazývaná “Task Board”, čiže tabuľa úloh. Mali by ste si nastaviť, či na tabuli budete zobrazovať úlohy, teda aktivity, slovesá “robiť, vytvárať, nasadzovať, dizajnovať, kresliť analyzovať”, alebo tam budete ukladať výsledky, ktoré potrebujete dosiahnuť. Ak poznáte Agile Manifesto, tak viete, že v prvom rade je funkčný produkt, funkčný výsledok. Preto je vhodné mať na tabuli výsledky, alebo v angličtine ouputy. Niektoré agile tímy idú ešte dokonca oveľa ďalej – majú tam dokonca „outcomy“, to znamená nejaké medziciele, medzistavy, ktoré by to pomohli dosiahnúť a na tabuli si nesledujú len aktivity, ale naopak, tie vyššie a dôležitejšie veci. Signálka V neposlednom rade tabuľa, ak ju nevoláte iba task board, ale ju voláte Kanban tabuľa, tak vás privádza práve k tomu slovíčku Kanban, čo v japončine znamená kartička. Kartička je v podstate signál, ktorý môžete používať aj na to, aby ste videli stav, niečo si poznamenali, alebo, ak máte závislosti, mali signálku od iného tímu o stave tejto závislosti. Signálka môže indikovať problém V princípe taká dobrá Kanban tabuľa je pripomienkovací systém, ktorý vám umožňuje uvoľniť hlavu a tých povestných sedem zásuviek, ktoré máme v mozgu. Dovoľuje použiť tie zásuvky na niečo rozumné, nie len na sledovanie si svojich úloh. Ľudia, ktorí používajú Kanban tabuľu, sa vyjadrujú, že im Kanban tabuľa pomáha zabúdať na menej dôležité veci a nezabúdať na tie dôležité. Dobrá tabuľa má aj viacero stĺpcov. Je dôležité koľko má byť stĺpcov a čo stĺpce reprezentujú. V niektorých prípadoch je tých vizuálnych signálov tak veľa, že potrebujete mať tam plavecké dráhy – swimlanes. Vzhľadom na definíciu Kanban tabule, je prirodzené, že posledný element, ktorý nám chýba sú práve limity. Limity pomáhajú obmedziť počet úloh kariet v danom stave, čo nám pomôže dosiahnuť efektívnejší tok. To nám pomôže veci dokončovať a nezačínať. Ako lepšie, transparetnejšie? Veľmi dobrým zvykom Scrum Mastra je pýtať sa: „Ako môžem tento systém spraviť transparentnejší?“. Transparentnosť potrebujete pre rýchle preskúmanie, pre rýchlu adaptáciu, jednoducho potrebujete veci zbadať a nie len vidieť. Na fyzických tabuliach viete používať karty rôznych veľkostí, ktoré môžu reprezentovať rôzne typy informácií alebo môžu reprezentovať hierarchiu požiadaviek. Zároveň môžete používať aj rôzne tvary, takže ak v niektorých prípadoch máte chybu a budete používať nejaký tvar, tak veľmi rýchlo poodstúpením od tabule, spoznáte kde je chyba, v akom je stave a koľko tých chýb máte. Ďalším tipom sú farby. Napr. ak máte pre chyby karty červenej farby, tak veľmi jednoduchým spôsobom zistíte, bez toho, aby ste museli tie karty čítať, koľko vlastne máte chýb na danej tabuli v momentálne akom stave. Veľkosti, tvary a farby sú vynikajúce, ak používate predovšetkým fyzickú tabuľu. Ak máte workshopy, ktoré robíte spolu so svojimi zákazníkmi, tak je to absolútne vynikajúca vec. Ľudia sú sklr zladení, chápu oveľa viac bez toho, aby museli čítať detailné popisy, pretože čo si budeme klamať, ľudia málokedy naozaj čítajú. Ľudia ju skôr skenujú. Práve farby, tvary a veľkosti vám vedia veci opticky objasniť a vyjasniť oveľa rýchlejšie. Stĺpce tabule. Nie je menej viac? Sú dva možné prístupy k stĺpcom. Ani jeden nie je lepší, ani jeden nie je horší, je dobré sa nad tým zamyslieť ktorý z nich potrebujete a prečo. Začal by som možno menej násilným, evolučným prístupom k návrhu layoutu tabule. Je to častý spôsob ako zavádzame Agile v ScrumDesku v tímoch, pre ktoré je Agile pomerne veľkou revolúciou. Mapovanie aktuálneho stavu Prvý prístup je v tom, že stĺpce mapujú aktuálny proces. Od idey až po tú dodávku idey. Proces dodávky rozdeliť do jednotlivých stĺpcov na danej tabuli. Mapujem aktuálny stav systému. Po nejakých iteráciách, zvyčajne je to záležitosť 2-3 týždňov, sa zrazu začne tá tabuľa sama štruktúrovať, čistiť. Začnú vznikať dohody čo budeme dávať na túto tabuľu, či aktivity alebo výsledky. Začneme sa baviť o stĺpcoch, či potrebujeme mať podstavy, alebo nie. Začneme sa baviť ako sa tie stĺpce volajú. Možno prídeme k tomu, že pôvodne sme mali viacero stĺpcov, ktoré reprezentovali jeden stav. Napr. * na zváženie, * aktuálne zvažujem, * vec je zamietnutá alebo povolená Menej stavov je výsledok, ktorý je oveľa lepší. Čím menej stavov, tým rýchlejšie dôjdeme k výsledku. Zároveň, to neirituje toľko ľudí, pretože veľa stavov privádza ľudí k veľmi zásadnej otázke: „Čo vlastne tento stav znamená?“, „Kedy mám tu kartu do toho stavu dať a kedy nie?“. V začiatkoch v roku 2008 som ako mentor zažil aj to, že medzi jednotlivými stavmi boli ľudia nútení uviesť dôvod zmeny stavu. V princípe tie stredné stavy absolútne nenávideli, karty ostávali v stave „To-Do“ aj 250 dní a po 250 dňoch sa zrazu objavili v stave „Done“, ale medzitým museli preskákať cez všetko. Radikálne Druhý prístup k stĺpcom tabule je radikálnejší. Privádza však tím k lepším štandardom. Takýto layout tabule má iba tri stavy: „To-Do“, „In Progress“ a „Done“. Prirodzene to vedie k debatám typu „Ak je nejaká požiadavka v „In Progress“, znamená, že sa momentálne testuje? Znamená, že sa momentálne kreslí? Znamená, že sa momentálne nasadzuje alebo beží tam code review?“ Ako si všimnete, tak odpoveďami budú slovesá. Slovesá, aktivity, je nutné spraviť, aby ste mali výsledok. Zaujíma zákazníkov, používateľov, výsledok alebo ho zaujímajú práve tie jednotlivé aktivity?“ Ak ho zaujímajú aktivity, tak sa pravdepodobne bavíme o tom, že ten zákazník nemá dôveru v ten tím, a teda potrebuje mať mikromanažment, mikrokontrolu. Ak ho zaujímajú výsledky, potom úplne zbytočne zákazník číta o aktivitách, sú pre neho absolútne zbytočné, a on možno potrebuje mať takýto jednoduchší pohľad. A to nás privádza predovšetkým k ďalšiemu kroku, a to k tomu, že je dobré si vybrať layout tej tabule. Rozloženie tabule. Vidíte konzistenciu? Layouty tabule môžu byť v princípe dva. Prvý layout je Kanban tabuľa, kedy tie karty reprezentujú outputy, teda vlastnosti, požiadavky, ale nie sú na nich evidované tie jednotlivé aktivity. Aktivity sú na detaile karty alebo z druhej strany, vo forme či už nejakého kontrolného zoznamu, checklistu, alebo sú tam nejaké ďalšie subtasky, ale tie nevidíte na prednej strane karty. Pozretím sa na ľavú tabuľu teda vidíte, že požiadavka je v nejakom stave „In Progress“ ale neviete v akom stave a ak tá požiadavka je veľká, tak tá požiadavka bude v tom stave „In Progress“ pomerne dlho. To nás privádza k tomu, že nám začne klesať dôvera, začne nám stúpať mikromanažment, a to vedie k tomu, že budete potrebovať sa baviť viac o mítingoch, alebo po nejakom čase budete nepríjemne prekvapení. Bude vám chýbať transparentnosť. S novými tímami, s ktorými pracujeme v ScrumDesku, sa veľmi snažíme aplikovať Scrumban tabuľu. Scrumban tabuľa poskytuje viditeľnosť obidvom stranám. Klientovi aj tímu. Zákazníkom poskytuje viditeľnosť veľkej karty, ktorá je zvyčajne backlog item alebo požiadavka, vlastnosť. V tom istom riadku sú aktivity, ktoré je potrebné spraviť, aby ten výsledok bol doručený. Samozrejme, keď sú všetky aktivity hotové, tak potom tá veľká karta môže byť na fyzickej tabuli, dosť často je to aj takto robené – na fyzickej je celá karta presunutá do „Done“. ScrumBan tabuľa umožňuje tímu vidieť nekonzistnosti, veci, na ktoré zabudli, umožňuje im vidieť štandardy, Zo ScrumBan tabule môžete vydolovať štandardy. Tím s týmto systémom pomerne rýchlo funguje a pomerne jednoducho si dokáže nastaviť štandardy a namiesto toho, aby robil napríklad „Design Backendu“, „Design API“, „Vývoj API“, „Testovanie API“, „Code Review API“, tak časom, si to zjednoduší do karty „Backend“. Takto jednoducho sám zvýši kvalitu svojho fungovania. Kanban vs. ScrumBan layout Vďaka transparentnosti ľudia prekonávajú svoju rezistenciu a obavy pri spracovaní nejasných požiadaviek, požiadaviek, n
