Muda aneb 7 typů plýtvání při výrobě softwaru

Kdo z vás se někdy zabýval Leanem, pravděpodobně jste se setkal se sedmi typy plýtvání (Muda). A protože Lean vznikl původně pro průmyslovou výrobu (Toyota), zpočátku se mi obtížněji hledalo, jak se tyto typy plýtvání přenesou do výroby softwaru.  

Mně osobně před pár lety velmi pomohl článek na stránkách kanbanize.com. Po jeho přečtení jsem sbíral další příklady plýtvání a postupně jsem je zařadil do jednotlivých kategorií. Došel jsem k tomu, že by se takový přehled hodil každému Scrum masterovi (a nejen jemu). Pokud si popřemýšlíte nad strukturou typů plýtvání, bude pro vás hledání výskytů ve vašich týmech jednodušší.

Podívejte se na tabulku 7 druhů plýtvání, ke každému typu tu vždy najdete několik příkladů ze světa IT.

Čekání

Čekání je jedním z nejrozšířenějších a zároveň nejhůře viditelných typů plýtvání při vývoji softwaru. Na rozdíl od výrobní linky, kde je prostoj stroje snadno měřitelný, čekání ve vývoji softwaru se schovává v e-mailových vláknech, ticketovacích systémech a statusech „blocked“. Tým často ani neví, kolik času tráví čekáním, vnímá to jako normální součást procesu. Přitom právě čekání je hlavní příčinou dlouhého lead time.

Pokud chcete zkrátit dobu dodání, začněte měřením toho, kde a jak dlouho vaše požadavky stojí.

• čekání, než se požadavek dostane na řadu u subdodavatelského týmu
• čekání na výsledky prioritizace
• čekání na dostupnost testovacího prostředí
• čekání na přístupy
• čekání na release

Zásoby

V Lean manufacturing jsou zásoby fyzicky viditelné, stojí ve skladu a vážou kapitál. Při vývoji softwaru mají zásoby podobný efekt, ale jsou neviditelné. Představují investovanou práci a peníze, které ale nepřinášejí žádnou hodnotu.

Zásoby navíc stárnou: analýza zpracovaná před půl rokem už nemusí odpovídat realitě. Řešením je omezit rozpracovanost (WIP limit), dodávat v menších dávkách a pravidelně revidovat, co skutečně potřebujete.

Příklady

• Analýza do šuplíku
• Hotový, ale nenasazený kód
• Nepoužívané nástroje a licence
• Příprava rozsáhlé nebo duplicitní dokumentace, která se nepoužívá

Defekty

Defekty jsou typ plýtvání, který většina týmů zná nejlépe: produkční chyby, bugy nahlášené zákazníky, nefungující integrace. Méně viditelný, ale stejně destruktivní je technický dluh:

• špatně navržená architektura,
• chybějící testy
• nebo obcházená pravidla, která se postupně hromadí.

Klíčové je, že čím později defekt odhalíte, tím dražší je jeho oprava. Tým, který investuje do průběžné kvality, code review, automatizovaných testů a párového programování, ušetří násobně více, než kolik investoval.

Příklady

• Produkční chyby
• Technický dluh

Co zařadit do Nadprodukce?

Nadprodukce je v Lean přístupu považována za nejhorší typ plýtvání, protože způsobuje všechny ostatní. V softwarovém vývoji to znamená vyrábět funkcionality, které nikdo nepotřebuje nebo nepoužívá.

Příčinou bývá chybějící zpětná vazba od zákazníka, přesvědčení „víme, co uživatel chce“ a nechuť zastavit projekt, do kterého se už investovalo. Řešením je validovat hypotézy dříve, než začnete stavět, a nebát se říct „stop“.

Příklady

• Výroba dalších a dalších funkcionalit bez průběžné zpětné vazby zákazníka
• Nezrušení projektu/aplikace, který nepřináší hodnotu

Přeprava

V tradiční výrobě přeprava znamená zbytečné přesouvání materiálu mezi pracovišti. Při vývoji softwaru jde o předávání informací mezi lidmi, týmy a systémy. Každé předání s sebou nese riziko ztráty kontextu, zpoždění a nedorozumění. A naopak čím méně předávek, tím plynulejší a rychlejší dodávka. Cross-funkční týmy s end-to-end odpovědností jsou jedním z nejúčinnějších způsobů, jak přepravu minimalizovat.

Příklady

• Přehazování chyb mezi systémy při hledání řešení, někdy i bez další analýzy (teď to není na mně,…)
• Časté přepínání pozornosti mezi mnoha paralelními projekty a paralelními tasky, rozbitý focus
• Předávání požadavků mezi mnoha subdodavateli (interními i externími)

Nadměrné zpracování

Nadměrné zpracování nastává, když děláme více práce, než je potřeba k dosažení výsledku. Ve vývoji softwaru to často vypadá jako příliš složité procesy, nebo rigidní workflow v nástrojích jako JIRA, které lidé obcházejí. Také přehnaný důraz na reporting a metriky na úkor skutečné práce jsou považovány za plýtvání.

Paradoxně se nadměrné zpracování často maskuje jako „kvalita“ nebo „best practice“. Klíčem je pravidelně se ptát: přidává tento krok skutečnou hodnotu? Pokud ne, zjednodušte ho nebo ho odstraňte. Dobrým testem je zeptat se týmu, které kroky v procesu by jim nechyběly.

Příklady

• Příliš utažená pravidla pro vývoj (procesy, metodika)
• Moc složité workflow v JIRA, které všichni přeskakují až když je požadavek hotový a chtějí ho zavřít
• Příliš velká pozornost na měření a reporting

Pohyb

Pohyb jako typ plýtvání se v softwaru projevuje zbytečnými kroky, schůzkami a kolečky, které nepřidávají hodnotu. Schvalovací procesy, kde se hotová věc vrací několikrát tam a zpátky jsou typickým zástupcem. Schůzky bez agendy a jasného výstupu jsou také velmi častým zdrojem plýtvání. Patří sem i neustálé vyrušování od práce.

Na rozdíl od přepravy (předávky mezi lidmi) jde u pohybu spíše o zbytečnou aktivitu uvnitř jednoho týmu nebo jednoho člověka. Řešením je zkrátit feedback smyčky, zapojit správné lidi od začátku a chránit čas pro soustředěnou práci.

Příklady

• Schvalovací kolečka, kdy se připomínkuje až hotová věc a ta se několikrát vrací tam a zpátky
• Schůzky, které nepřinášejí hodnotu
• Vyrušování od práce

Může vás také zajímat

• Chcete se o typech plýtvání dozvědět víc? Přihlaste se na naše Školení Kanban – Flow Mastery.
• Value Stream Mapping – krok za krokem k vyšší efektivitě týmu
• Nastavení Kanban boardu: praktický postup pro efektivní workflow