Dnes se dozvíte druhou část ze série srovnání Scrumu a Leanu. Dnes budu po komentářích používat radši termín Lean Software Development (s příznačnou zkratkou LSD). Na konci se dozvíte i nějaké konečné zhodnocení.
Lean startup je neprodejný
Jak je těžké zákazníkovi prodat Scrum s jeho iteracemi, ikdyž si zákazník dokáže spočítat cenu za bod a tím i zpětně náklady na vlastnost a tím dovede i ekonomicky kalkulovat! Je pro něj pořád méně pohodlné než fixed-price u běžného vývoje SW. Minimálně dokud nezjistí, že Scrumové týmy dodávají levněji a rychleji, je obtížné zákazníka převést na platbu po sprintech. Zákazník má sice nástroje, jak řídit náklady (zjistí, že vlastnost je obodována např. na 5 bodů a on ví, že náklady na bod jsou 2 tisíce Kč a tedy ví, že daná vlastnost musí stejných bankovek přinést minimálně deset.
Pokud Scrum je těžko prodejný, pak Lean Software Development je zcela neprodejný! Neexistují časové odhady. Vlastnost, ať už je velká nebo malá, má zprůměrovaný časový odhad a zprůměrovanou cenu. Chcete upravit pár textů nebo chcete přepsat objednávkový systém? Jedna cena. Já tohle považuju za noční můru, ve které je pro zákazníka ekonomicky racionální neustále velikost úkolu zvětšovat (abych ve sdíleném prostředí za fixní cenu za jednotku urval maximum hodnoty) a tím vést k tomu, že cena úkolu a doba zhotovení pořád poroste, protože tým toho bude stíhat pořád méně.
Toto neplatí pro startup nebo firmu, která vyvíjí sama pro sebe – tam totiž taková optimalizace padá. Na běžném trhu mi to ale připadá, jako mít firmu, kde řeknete 1 web = 50 tisíc, ať už budete chtít e-shop s exporty do účetnictví a skladovým hospodářstvím nebo běžnou firemní vizitku s pár texty a kontaktním formulářem.
V běžném štíhlém řízení se samozřejmě cenové odhady počítají. Štíhlé podniky se snaží o enormní efektivitu, s čímž se pojí to, že znají náklady až na úroveň halířů. Něco zprůměrovat a říkat, že se to statisticky vyrovná, to je špatné pochopení principu heijunka – vyrovnání výroby. Ve skutečnosti se při výrobě nikdy nic nevyrovná samo jen tak, ono se to vyrovná proto, že výrobu vědomě a řízeně vyrovnáme. Scrum má spoustu nástrojů, které vyrovnat výrobu umí (fixní backlog, ochrana týmu, fixní čas na vývoj, odstraňování překážek v roli Scrum Mastera, malé User Stories, bodování úloh, procesní řízení a zlepšování procesu, automatizace některých úkonů, jako je např. deployment). Obdobně má plno principů a postupů pro vyrovnávání výroby i tradiční štíhlé řízení – především ve striktní standardizaci výroby, kdy jsou některé úkony rozepsány s přesností na jednu vteřinu nebo pevným nastavením kadence, kdy všechna oddělení pracují stejným tempem a kdy nadprůměrně rychlá oddělení nemůžou fungovat rychleji dlouho, protože mu brzo dojdou díly z předchozího kroku a protože zásoby se udržují na minimální možné úrovni.
Backlog existuje tak jako tak
Zastánci Lean Software Developmentu argumentují, že Scrum je takový malý Waterfall. Že vznikají iterace místo toho, aby do procesu byly úkoly přidávány tak, jak po nich vzniká poptávka. Jak jsem zmiňoval v minulém článku, možnosti různých lidí doplňovat backlog vysokou frekvencí se dost liší. Od přímo project managera, kde bude v Leanu 1 úkol v backlogu až po zákazníka na pracovišti který může mít čas třeba jednou za 2 měsíce a ani ten Lean se nevyhne backlogu s klidně 80 položkami na vstupu.
Ve Scrumu se délka sprintu přizpůsobuje tomu, aby Product Owner stačil přichystat Stories, které pohromadě dávají smysl. Pokud potřebuje dvoudenní sprinty, ničemu to nevadí, Scrum se s tím dovede srovnat. Pokud nemůže častěji, než jednou za dva měsíce, i s tím se Scrum srovná, ikdyž pravděpodobně by si tým zavedl uvnitř „iterací pro zákazníka“ další menší iterace, aby měl šanci lépe poznávat svůj výkon v čase.
V originálním štíhlém řízení je backlog tak velký, jak velké jsou objednávky. Pokud zákazník deklaruje, že koupí miliardu automobilů, bude mít Toyota v backlogu miliardu položek. Umělá omezení na velikost backlogu jsou ve vývoji software běžná. U Scrumu proto, že tým musí každou User Story probrat a obodovat a kde je variabilita mezi návštěvní knihou a vybudováním API daleko větší, než když si zákazník objedná Priuse jednou modrého a podruhé zeleného s klimatizací. U Lean Software Developmentu je to proto, že trh je turbulentní a občas se opravdu může stát, že čekat 14 dni do konce sprintu může znamenat, že konkurence získá na trhu výhodu.
Kontinuální zlepšování nestačí
Zjednodušeně řečeno: Když potkáte amerického manažera, bude ho zajímat inovace – tedy výrazná změna, která skokem překoná konkurenci. Když japonského, bude ho zajímat kaizen – tedy postupné zlepšování po malých krocích. Postupné zlepšování je skvělé a je naprosto nezbytné pro zvyšování produktivity a kvality takovým tempem, že překoná konkurenci. Ale jak chcete do backlogu, kam můžete přidat jen 1 položku, zapsat, že chcete výrazně změnit architekturu? Abyste udrželi u skokové inovace kontext, musíte do backlogu dát všechny položky tak, aby to celé dávalo smysl. Jenže to v Lean Software Developmentu udělat nesmíte. Každá fáze má utažené limity na takovou úroveň, jaká je nejčastější – tedy na úroveň, kdy probíhá kontinuální zlepšování, kaizen.
I ve Scrumu se může stát, že se změna architektury nevejde do jednoho sprintu. Ale máte Product Backlog a z něj je celkový záměr snadno viditelný.
Zhodnocení
Mám-li to zhodnotit, je štíhlé řízení skvělé pro firmy, které vyvíjí dovnitř, které znají své směřování a které hlavně investují čas a úsilí pochopit i skutečné štíhlé řízení a principy, které za ním stojí a které se používají v továrnách. Bohužel co je dobré pro automobilku nebo továrnu na motory, je docela problematické ve světě software, kde je těžké navrhování, ne opakování. Některé z přenesených principů ale skutečně přináší hodnotu a je pravda, že praktické vyzkoušení v praxi podniku spíš pomůže než uškodí.
Scrum je metodika, která bude vyhovovat téměř všem. Její problém je ale v tom, že vyžaduje hluboké pochopení a stoprocentní podporu managementu. To má společné i s původním štíhlým řízením.
Úplně nejlepší, co si zatím umím představit, je kombinace všeho postavená nad Scrumem. Scrum je ekonomicky úspěšný a logický rámec, který by například bez omezení otevřených stories, vyrovnávání výroby a kratších sprintů nebyl zdaleka tak dobrý, jako když si tyto věci z Leanu odnese.
