Slovník

Níže naleznete seznam agilních výrazů a jejich vysvětlení. Seznam postupně doplňujeme. Velké poděkování Lukáši Bednaříkovi za jeho pomoc! Pokud se vám některé vysvětlení nezdá a změnili byste ho, nebo vám nějaký výraz chybí, napište nám na info@agileacademy.cz

Agile
Způsob spolupráce, který okamžitě reaguje na potřeby zákazníka v rychle se měnícím prostředí, a který staví na dodržování sdílených hodnot a principů spolupráce. Slovo agile můžeme přeložit jako adaptabilní nebo přizpůsobivý. Agilně vyvíjený produkt je většinou dodáván v pravidelných intervalech po menších přírůstcích, což umožňuje rychlejší získávání zpětné vazby od zákazníků. Zpětná vazba je vstupem pro další vývoj, který tedy není naplánován detailně od počátku pro celý projekt. Agile vznikl primárně pro vývoj software, původní manifest najdete na webu, ale čím dál tím častěji se používá i v jiných oborech.

Automatické testy
Forma testování, která minimalizuje potřebu manuálních činností. Automatické testy jsou rychlejší a snadněji spustitelné než manuální a jsou 100% opakovatelné. Mají jednoznačný výsledek (OK, nebo není OK).

Backlog Refinement (dříve označováno jako Grooming)
Schůzka, ve které tým společně s Product Ownerem procházejí jednotlivá nezpracovaná zadání (např. ve formě User Story), a dle jejich priorit, určení či závažnosti plánují jejich zařazení do dalšího Sprintu. V terminologii Agile pojem Backlog Refinement znamená vylepšování, zpřesňování. Jedná se tedy o “zlepšování stavu” Product backlogu. Cílem schůzky je pochopení smyslu (proč) a rozsahu Story v celém týmu, případně získání dalších informací od Product ownera či zadavatele, nutných pro řádné vyhodnocení jednotlivých Stories. Někdy to znamená i rozdělování Stories do několika separátních Stories, a případně další úpravy. Frekvence schůzek záleží na týmu, obecným pravidlem je, že Product backlog by měl být v každé chvíli nachystaný na dva až tři Sprinty dopředu.

Kanban

Kanban je nástroj k definování, řízení a zlepšování služeb založených na duševní práci. Mezi takové služby patří vývoj software, design a kreativní činnosti. Kanban, Scrum, Waterfall, Rational Unified Process… to jsou všechno nástroje. Hádat se, který nástroj je nejlepší, je stejné, jako se přít o to, je-li lepší vidlička nebo lžička. Každý nástroj je vhodný na jinou činnost.

Hodnota nástroje k řízení procesů spočívá v tom, že omezuje, co můžeme dělat. Například metoda „udělej vždy správnou věc“ je sice stoprocentně úspěšná, ale vůbec neříká, co vlastně dělat. Pokud při aplikaci této metodiky náhodou selžete, pak jste zřejmě neudělali správnou věc a tedy nedodrželi metodu. Takže ano, metoda „udělej vždy správnou věc“ je sto procentně úspěšná.

Kanban nás omezuje jen velmi málo (a méně než třeba Scrum). Kanban neříká, co bychom měli dělat, kromě základních čtyř principů a šesti praktik. 

Historie

Kanban je japonské slovo pro „vizuální signál“ neboli „kartičky“. Pásoví dělníci v Toyotě používali kanban (malé „k“, zde kanban znamená „kartičky“) aby signalizovali kroky ve výrobě. Vizuální znázornění celého procesu denně pomáhalo lidem při komunikaci a umožnilo další optimalizace – zrychlení výroby a omezení plýtvání.

Druhá vlna použití Kanbanu přišla v roce 2007. Komunita vytvořená pod vedením D. J. Anderson, J. Benson, C. Ladas a dalších ukázala, že Kanban lze úspěšně použít také v oblasti služeb založených na duševní práci.

Principy Kanbanu

Kanban vychází ze čtyř principů:

• začněte tam, kde jste teď s tím, co víte,
• domluvte se na provádění postupných, evolučních změn,
• podporujte vedoucí osobnosti na každé úrovni.
• porozumějte a zaměřte se na zákaznické potřeby a očekávání

Praktiky Kanbanu

Kanban se „točí“ kolem šesti praktik:

• vizualizujte,
• omezte rozpracovanou práci,
• řiďte tok hodnoty,
• mějte jasná a psaná pravidla,
• dávejte si zpětnou vazbu a
• neustále se zlepšujte.

Vizualizujte

Kanban neříká, co a jak vizualizovat. Začněte tedy tam, kde jste teď: snažte se porozumět současnému procesu tak, jak se opravdu děje v praxi.

Jako příklad si můžeme vzít vývoj software. Zákazník zadá požadavek, ten je schválen, je navržena patřičná změna architektury produktu, změna je implementována, testována a předána zákazníkovi. Zde máme šest stavů, ve kterých se můžeme nacházet: požadavek, schválení, návrh architektury, implementace, test, předání zákazníkovi.

Kanban respektuje všechny role, tituly i zodpovědnosti lidí ve firmě. Nejdříve porozumějte současnému procesu. Kolik úkolů je průměrně v jednotlivých stavech? Jak dlouho a kde úkol čeká? Kde je úzké hrdlo? Můžeme nějak rozšířit vizualizaci, abychom získali ještě více informací? Co blokuje některé úkoly? Vytvořte vizualizaci, která vám umožní vidět skutečné problémy a dělat lepší rozhodnutí.

Omezte rozpracovanou práci

Přepínání kontextu je zlo. Kanban to ví. Kanban chce omezit rozdělanou práci. Kromě zmenšení ztráty z přepínání kontextu má tato změna ještě další pozitivní efekt.

Limit na rozpracovanou práci může vypadat takto: „Tým A nebude mít nikdy otevřeny více než dva tikety současně.“ Jakmile tým A jeden tiket zavře, automaticky si otevře další. Tímto dochází ke změně „push“ systému, kdy týmu A zadáváme práci, na „pull“ systém, kdy si tým A aktivně sám práci bere z připravené hromádky.

Nakonec, méně rozpracovaných úkolů znamená, že to, co se jednou otevře, je rychleji doručeno zákazníkovi. Firma má méně rozpracovaných úkolů „skladem“ a doručené dodávky generují zisk.

Limit rozdělané práce, tzv. „Work In Progress“ limit, se obvykle označuje zkráceně WIP limit.

Řiďte tok hodnoty

Ne všechny úkoly jsou si rovny:

1. Dodávka zákazníka nemusí být hotova příliš brzy, ale musí být dokončena ve smluveném termínu. V opačném případě by zákazník nemusel zaplatit.
2. Refaktoring a redukce technického dluhu nikdy nespěchá, ale pokud se neprovede, někdy v budoucnu můžeme na nekvalitní kód velmi tvrdě doplatit.
3. Bug v produktu blokující podepsání nového kontraktu musí být řešen s nejvyšší prioritou. 

Z příkladů je patrné, že některé úkoly ztrácí svou hodnotu rychleji než jiné. Cena, kterou zaplatíme za zpožděné doručení, se nazývá Cost of delay (CoD).

Kanban rozlišuje čtyři archetypy (typické příklady) CoD: expedite, fixed date, standard, intangible (intangible = nespěchá, ale v delším časovém horizontu se může vymstít). Maximalizovat tok hodnoty znamená být schopen správně prioritizovat a doručit maximum možné hodnoty.

Mějte jasná a psaná pravidla

Stanovte explicitní pravidla pro svůj proces. Pravidla by měla být jednoduchá, dobře definovaná, viditelně umístěná, měla by se vždy dodržovat a současně být připravena být okamžitě změněna.

Všimněte si, že dodržování pravidel a připravenost pravidla změnit, spolu souvisí. Velmi špatnou aplikací principů Kanbanu je nastavit WIP limity a nikdy se nepokusit tyto limity překročit nebo snížit. Pravidla jsou pevně dána právě proto, abychom odlišili, kdy dodržujeme proces a kdy už experimentujeme a inovujeme.

WIP limity jsou jen jedním typem pravidel. Mezi další pravidla patří definice přechodů mezi stavy na kanban tabuli (kdy je úkol připraven, kdy je dokončen…), způsob alokace kapacit na úkoly, způsob doplňování nových lístečků na tabuli, a například také kdy některý úkol můžeme prohlásit za zrušený a lísteček zahodit.

Neustále se zlepšujte

Zlepšujte se společně pomocí drobných experimentů. Prvním krokem může být zlepšení zpětné vazby, další opatření mohou cílit na problémy odhalené pomocí zpětné vazby.

Příležitostem pro zpětnou vazbu se v Kanbanu říká kadence (cadences). Kadence jsou pravidelné meetingy, které pomáhají dělat postupné změny a zefektivňovat proces. Druhý význam slova „kadence“ je časová perioda těchto meetingů, tj. jak často se daný meeting opakuje.

Ideální perioda meetingů vždy závisí na kontextu. Příliš časté meetingy je mrhání časem zaměstnanců, málo časté meetingy a změna nereflektuje aktuální potřeby nebo je příliš pomalá.

Kritika

Porovnáme-li Kanban s jinou Agilní metodikou (Scrum, XP, …), bude Kanban vypadat minimalisticky. Kromě čtyř základních principů a šesti praktik Kanban vlastně nic neříká. Když si tyto principy přečte člověk poprvé, rozhodně neví, co dělat. Právě proto je Kanban zpočátku obtížný.

Certifikace

Za Kanbanem stojí komunita lidí vedená D. J. Andersonem. Kanban nikdo nevynalezl, ale vznikl na oddělení vedeném D. J. Andersonem za příhodných podmínek v roce 2007. Později vznikla komunita lidí Limited WIP Society.

Jednou z nejrespektovanějších certifikačních autorit v rámci Kanbanu je Kanban university.

V roce 2018 začal Scrum.org nabízet certifikaci Scrumu s Kanbanem.

Lean
Termín pochází z anglického jazyka a znamená štíhlý. Nejčastěji se vyskytuje ve spojení lean production – tedy štíhlá výroba, nebo lean processes – štíhlé procesy. Cílem lean přístupu je odstranění zbytečných a neproduktivních činností v rámci procesů tak, aby výsledný produkt bylo možné realizovat co nejjednodušším způsobem, pouze s nezbytným minimem činností. Nutnými předpoklady pro využívání lean přístupu jsou: schopnost pracovníků v procesu flexibilně řešit situace procesem neošetřené a vysoká míra osobní odpovědnosti. Lean je inspirací pro agilní metodiky. Ty jsou lépe přizpůsobené potřebám vývoje softwaru, kde se vyskytuje méně standardních a pravidelně se opakujících činností, a kde je naopak třeba častěji flexibilně reagovat na nastalé změny.

Scaling agile
Česky škálovatelný/rozšiřitelný agilní přístup. Obecná agilní pravidla (např. v metodice SCRUM) se zaměřují na popis agilního fungování jednoho týmu. Ve větších firmách je obvykle potřeba, aby na produktu spolupracovalo více týmů. Scaling agile se cíleně zaměřuje na nastavení účinných a efektivních mechanismů spolupráce mezi agilními týmy organizace, zejména pokud se tyto týmy podílí na tvorbě společného produktu. Existuje několik způsobů/přístupů škálování. Mezi nejrozšířenější patří např. SAFE (Scaled Agile Framework), Spotify model, LeSS (Large-scale scrum), DAD (Disciplined agile delivery) nebo Parallel Agile.

SCRUM
Agilní procesní rámec určený pro řízení práce a dodávek v agilním prostředí. Jedná se o nejčastěji využívanou agilní metodiku. Hlavním principem SCRUM je využívání jednoduchých a efektivních procesů, které umožňují tvorbu produktu v menších přírůstcích (inkrementech), v pravidelných iteracích. Klíčovými rolemi jsou dle metodiky SCRUM: tým, Product Owner a SCRUM Master.

SCRUM board
Elektronická nebo fyzická tabule, která v grafické podobě zobrazuje aktuální stav Sprintu. Jednotlivé úkoly jsou reprezentovány kartičkami (často post-it papírky), které tým přesouvá mezi sloupci – stavy. Na první pohled je vždy vidět, jestli postup práce odpovídá fázi Sprintu a původnímu plánu/očekávání. Před tabulí probíhají tzv. denní scrum (pravidelné, krátké schůzky; často se používá výraz „daily stand-up“), ve kterých probíhá hodnocení minulého dne a plánování dodávek v dalším dni. Díky grafickému zobrazení stavu jednotlivých úkolů mají členové týmu přesnou představu, jak jsou jednotlivé úkoly zpracovávány, kým a jaký je jejich aktuální stav.

Sprint
Ohraničený, opakující se časový úsek (zpravidla 1-3 týdny), ve kterém tým dodá hotovou verzi produktu, rozšířenou o předem dohodnuté a odsouhlasené funkcionality (nebo o změny již existující funkcionality). Princip sprintů pochází z metodiky SCRUM. Všechny sprinty by měly být stejně dlouhé. Každý sprint začíná plánováním (Sprint planning) a končí Sprint review a společnou Retrospektivou.

Sprint backlog
Seznam požadavků (položky Product backlogu) vybraných a odsouhlasených v rámci Sprint planningu k realizaci v daném Sprintu. Výběr položek/požadavků do Sprint backlogu je prováděn na základě priorit jednotlivých požadavků a kapacitě/schopnosti týmu tyto požadavky v rámci Sprintu realizovat. Od začátku Sprintu je tedy zcela jasné, na čem bude tým pracovat a co má být na konci Sprintu hotovo. Sprint backlog je fixní a v průběhu Sprintu jej nelze měnit. Je-li to přeci jen třeba, pak se Sprint musí přeplánovat společně s týmem (tzn. původní Sprint je uzavřen a po přeplánování se otevírá Sprint nový).

Sprint planning
Plánování Sprintu. Schůzka probíhající na počátku každého Sprintu, v jejímž rámci Product owner a realizační tým posuzují jednotlivé požadavky/Stories, a na základě priority požadavků, jejich náročnosti, a s ohledem na kapacitu a schopnosti týmu požadavky realizovat rozhodují, které požadavky budou v nadcházejícím Sprintu realizovány. Odsouhlasením Sprint backlogu (tj. obsahu sprintu – jednotlivých požadavků, které budou realizovány) se tým zavazuje, že naplánované a do Sprint backlogu zařazené požadavky budou do konce Sprintu skutečně realizované/dodané.

Sprint review
Schůzka na konci Sprintu, na které tým prezentuje svoji práci Product ownerovi a dalším stakeholderům. Jedná se o efektivní způsob, jak prezentovat novinky v produktu všem, kteří o nich potřebují vědět. V průběhu Sprint review je kontrolováno, zda všechny požadavky byly vypořádány. Výstupem je pak odsouhlasení realizovaných dodávek a identifikace těch dodávek, které nebyly dokončeny nebo nebyly zpracovány dle požadavku zadavatele (ty jsou vstupem do Sprint planningu nadcházejícího Sprintu).

(Sprint) Retrospektiva
Pravidelně se opakující hodnotící schůzka, jejímž cílem je zhodnotit průběh realizovaného Sprintu a nalézt příp. oblasti budoucího zlepšení. A to nejen z pohledu tvorby vlastního produktu, ale i z perspektivy fungování týmu, projevených slabin či nedostatků, fungování podpůrných procesů, spolupráce a komunikace v rámci týmu atd. Retrospektivní schůzky vychází z agilní metodiky SCRUM, a účastní se jich celý tým, vč. Product ownera a SCRUM mastera.