Close

Kanban

Vztah metodologie kanbanu k vývoji softwaru

Co je kanban?

Kanban je populární rámec, který se používá k implementaci agile vývoje softwaru. Vyžaduje komunikaci o kapacitě v reálném čase a plnou transparentnost práce. Pracovní položky jsou vizuálně reprezentovány na kanban boardu a členové týmu tak mohou kdykoli vidět stav každé položky práce.

Kanban articles

[CONTINUED]

Kanban is enormously prominent among today's agile software teams, but the kanban methodology of work dates back more than 50 years. In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.

When Toyota applied this same system to its factory floors, the goal was to better align their massive inventory levels with the actual consumption of materials. To communicate capacity levels in real-time on the factory floor (and to suppliers), workers would pass a card, or "kanban", between teams. When a bin of materials being used on the production line was emptied, a kanban was passed to the warehouse describing what material was needed, the exact amount of this material, and so on. The warehouse would have a new bin of this material waiting, which they would then send to the factory floor, and in turn send their own kanban to the supplier. The supplier would also have a bin of this particular material waiting, which it would ship to the warehouse. While the signaling technology of this process has evolved since the 1940s, this same "just in time" (or JIT) manufacturing process is still at the heart of it.

Kanban pro softwarové týmy

Agile software development teams today are able to leverage these same JIT principles by matching the amount of work in progress (WIP) to the team's capacity. This gives teams more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle.

Kanban Board | Atlassian agile coach

I když jsou základní principy tohoto rámce nadčasové a použitelné pro téměř jakýkoli obor, týmy vývoje softwaru dosahují s tímto postupem agile obzvláště významných úspěchů. Částečně je to proto, že softwarové týmy ho po pochopení základních principů mohou začít používat prakticky hned s minimální režií. To je jiné než implementace kanbanu ve výrobě, kde to zahrnuje i změny fyzických procesů a k přidávání dalších materiálů. Softwarové týmy potřebují fyzicky jen tabuli a karty, a i to může být virtuální.

Kanban boardy

Práce všech kanbanových týmů se točí kolem kanban boardu, což je nástroj pro vizualizaci práce a optimalizaci toku práce mezi týmy. Přestože jsou fyzické tabule u mnoha týmů oblíbené, virtuální tabule (boardy) jsou důležitou funkcí agilního nástroje pro vývoj softwaru. Je to kvůli jejich sledovatelnosti, snadnější spolupráci a přístupnosti z různých míst najednou.

Bez ohledu na to, zda je tabule týmu fyzická nebo digitální, její funkcí je zajistit vizualizaci práce týmu, standardizaci workflowu a okamžitou identifikaci a vyřešení blokování a závislostí. Základní kanban board obsahuje workflow o třech krocích: Udělat, Probíhá a Dokončeno. V závislosti na velikosti, struktuře a cílech týmu však lze workflow namapovat, aby odpovídal jedinečnému procesu libovolného konkrétního týmu.

Metodologie kanbanu spoléhá na úplnou transparentnost práce a informování o kapacitě v reálném čase. Proto je na místě brát kanban board jako hlavní zdroj informací pro týmovou práci.

Agile Kanban Board | Atlassian agile coach

Kanbanové karty

V japonštině pojem kanban doslova znamená „vizuální signál“. V případě kanbanových týmů je každá pracovní položka představována samostatnou kartou na boardu.

Hlavním účelem znázornění práce jako karty na kanban boardu je umožnit členům týmu sledovat průběh práce prostřednictvím vizuálního zobrazení workflowu. Kanbanové karty obsahují důležité informace o konkrétní pracovní položce a poskytují tak celému týmu úplný přehled o tom, kdo je za tuto pracovní položku odpovědný, krátký popis prováděné úlohy, odhad času potřebného na dokončení dané práce atd. Karty na virtuálních kanban boardech často obsahují také snímky obrazovky a další technické podrobnosti, které mají pro pověřenou osobu význam. Když mají členové týmu možnost kdykoli vidět stav každé pracovní položky a k ní přidružené podrobnosti, mohou se lépe soustředit na práci, položky lze neustále sledovat a je možné rychle identifikovat blokování a závislosti.

The benefits of Kanban

Kanban patří mezi nejoblíbenější metodologie pro vývoj softwaru, které si dnes agile týmy osvojují. Kanban nabízí několik dalších výhod pro plánování úkolů a výkonnost týmů všech velikostí.

Pružnost plánování

A kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there's no need for the fixed-length iterations you find in scrum.

PRO TIP:

Savvy product owners always engage the development team when considering changes to the backlog. For example, if user stories 1-6 are in the backlog, user story 6's estimate may be based on the completion of user stories 1-5. It's always a good practice to confirm changes with the engineering team to ensure there are no surprises. 

Shortened time cycles

Cycle time is a key metric for kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team’s workflow–from the moment work starts to the moment it ships. By optimizing cycle time, the team can confidently forecast the delivery of future work.

Překrývající se sady dovedností zkracují časy cyklů. Pokud určitou sadu dovedností ovládá pouze jedna osoba, stává se taková osoba kritickým bodem workflowu. Týmy proto využívají základní osvědčené postupy, například kontrolu kódu nebo mentorskou pomoc, aby své znalosti rozšiřovaly. Sdílené dovednosti znamenají, že členové mohou zastávat různorodé práce, což dále optimalizuje čas cyklu. Znamená to také, že pokud někde dochází ke zpomalování práce, celý tým se na ni může vrhnout a proces bude zase hladce pokračovat. Testování například neprovádějí pouze technici QA. I vývojáři přikládají ruku k dílu.

V kanbanu je odpovědností celého týmu zajistit, že práce bude postupovat hladce v rámci celého procesu.

Méně kritických bodů

Multitasking zabíjí efektivitu. Čím více pracovních položek máte právě otevřených, tím častěji musíte přecházet mezi kontexty, což je na překážku soustředění na úspěšné dokončení práce. Proto klíčovým prvkem kanbanu je omezit objem probíhající práce (WIP). Limity probíhající práce upozorňují na úzká hrdla a záložní varianty v týmovém procesu z důvodu nedostatku soustředění, lidí nebo kombinací pracovních dovedností.

For example, a typical software team might have four workflow states: To Do, In Progress, Code Review, and Done. They could choose to set a WIP limit of 2 for the code review state. That might seem like a low limit, but there's good reason for it: developers often prefer to write new code, rather than spend time reviewing someone else's work. A low limit encourages the team to pay special attention to issues in the review state, and to review others work before raising their own code reviews. This ultimately reduces the overall cycle time.

Vizuální metriky

Jednou ze základních hodnot je zaměření na neustálé zlepšování efektivity týmu a efektivity každé iterace práce. Grafy týmům nabízejí vizuální mechanismus, který zajišťuje, že se budou průběžně zlepšovat. Když tým data vidí, může snáze rozeznat kritické body procesu (a odstranit je). Kanbanové týmy používají dvě základní sestavy: kontrolní grafy a diagramy kumulativního průběhu.

Kontrolní graf ukazuje délku cyklu pro každý požadavek a průběžně aktualizovaný průměr pro celý tým.

Pro Tip:

The team's goal is to reduce the amount of time an issue takes to move through the entire process. Seeing the average cycle time drop in the control chart is an indicator of success. 

Agile control chart | Atlassian agile coach

Diagram kumulativního průběhu zobrazuje počet požadavků v jednotlivých stavech. Tým může snadno odhalit bariéry v procesu tím, že uvidí zvýšený počet požadavků v určitém stavu. Požadavky v mezistavech „Probíhá“ nebo „Kontrola“ ještě nejsou dodány zákazníkům a zablokování v těchto stavech může zvýšit pravděpodobnost masivních konfliktů při integraci, když v následných krocích dochází ke slučování pracovních výstupů. 

Cumulative Flow Diagram

Kontinuální dodávání

We know that continuous integration–the practice of automatically building and testing code incrementally throughout the day–is essential for maintaining quality. Now it's time to meet continuous delivery (CD). CD is the practice of releasing work to customers frequently–even daily or hourly. Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value.

The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And kanban teams focus on exactly that: optimizing the flow of work out to customers

Scrum vs. kanban

Kanban and scrum share some of the same concepts but have very different approaches. They should not be confused with one another. 

 

SCRUM

KANBAN
Tempo

Pravidelné sprinty s pevnou délkou (například 2 týdny)

 Kontinuální běh
Metodologie vydávání verzí Na konci každého sprintu, pokud to schválí vlastník produktu Kontinuální dodávání, nebo jak tým rozhodne
Role Vlastník produktu, scrum master, vývojový tým Žádné existující role. Některé týmy využívají pomoc agile instruktora.
Klíčové metriky Rychlost Délka cyklu
Filozofie změny Týmy by se měly snažit neprovádět změny předpovědi sprintu v průběhu sprintu. Znehodnocovalo by to poznatky související s odhadem. Ke změně může dojít kdykoli

 

Některé týmy spojují ideály kanbanu a scrumu do „scrumbanu“. Ze scrumu si berou sprinty pevné délky a role a z kanbanu zaměření na limity WIP (probíhající práce) a délku cyklu. Ale týmům, které s agile teprve začínají, doporučujeme zvolit jednu z těchto metodologií a po nějakou dobu se jí držet. Vždycky si to můžete později nějak vylepšit. 

Dan Radigan
Dan Radigan

Agile has had a huge impact on me both professionally and personally as I've learned the best experiences are agile, both in code and in life. You'll often find me at the intersection of technology, photography, and motorcycling. Find me on Twitter! @danradigan

Up Next
Boardy