Cíl

Každá akce, která přivádí společnost blíže k jejímu cíli, je produktivní. Každá akce, která společnost blíže k cíli nepřivádí, je neproduktivní. […] Produktivita je bez významu, pokud nevíte co je váš cíl.

Pokud chcete opravdu do hloubky pochopit Kanban, následujte mého příkladu a přečtěte si knihu The Goal od Eliyahu Goldratta. Je to šťavnaté čtení, které vás přinutí k zamyšlení.

Pokud jste četli The Phoenix Project, tak vás nepřekvapí styl. Je to napínavý román, kde se hlavní hrdina snaží zachránit továrnu na pokraji krachu. Je to čtivé, ale hlavně jsou tam neuvěřitelně názorné příklady, díky nimž pochopíte z čeho vznikla touha omezovat rozpracovanou práci (WIP), zkracovat stories a podobně. Myslel jsem si že to chápu už před přečtením této knihy, ale nebyla to pravda.

Celé se to točí kolem teorie omezení (theory of constraints (TOC)). Ač to zní vznešeně tak je to jednoduché. Každý netriviální výrobní proces se skládá z více navzájem závislých kroků. Když to převedu na vývoj software, tak mám analýzu, implementaci, vývoj, testování a nasazení. Je evidentní, že každá z těchto fází má jinou kapacitu. Jinými slovy, vždy bude jeden z těchto kroků nejpomalejší. Je jedno který, ale kapacita celého řetězce je shora omezena kapacitou tohoto úzkého hrdla. Takže pokud například vaši testeři dokáží otestovat 2 stories za týden, tak víc než 2 stories za týden nedodáte, ani kdyby se analytici a vývojáři rozkrájeli.

Je to samozřejmé, že? Tak se zamyslete a řekněte mi, co je vaše úzké hrdlo a jaká je jeho kapacita. Víte to? Pokud ano tak gratuluji. Pokud ne, tak to zkuste zjistit. Bez toho totiž nemůžete zvýšit kapacitu celého procesu. Ta se dá totiž zvýšit jenom tehdy, když se věnujete tomuto omezení. Nemá smysl se zaměřovat na cokoliv jiného. Když jsou vaším úzkým hrdlem testeři, tak zvýšeným výkonem při vývoji zvýšíte jenom hromadu práce čekající na testování.

Z TOC plyne také jeden zajímavý důsledek. Pokud máte řetězec závislých činností, tak ty, které nejsou úzkým hrdlem, musejí mít nadbytečnou kapacitu. Jinými slovy, musejí se flákat. Pokud se je budete snažit vytížit na sto procent, tak jenom zvýšíte tlak na úzké hrdlo.

Co s tím? Samozřejmě je potřeba se věnovat vašemu největšímu omezení a buď zvýšit jeho kapacitu, ubrat mu práce, nebo ho obejít. Jednoduché, že?

Musím upozornit, že kniha se nevěnuje vývoji software. Byla napsána před 25 lety, kdy se software ještě tolik neřešil. Je ale zajímavé cvičení porovnávat problémy továrny s našimi problémy a zkoumat, jestli to pasuje. U továrny je například jednodušší poznat co vede k cíli. Když vyrábí něco, co se prodá, tak je to dobře. Když vyrobí něco jenom na sklad, tak to nezvyšuje zisk a je to špatně. Co ale u nás? Jak poznám jestli kód který jsem vyvinul, otestoval a nasadil něčemu pomůže nebo je jenom „na sklad“? Na druhou stranu, u software nehrozí nedostatek poptávky. Backlog bývá obvykle nekonečný. V software také nemusíme řešit materiál. Obvykle pálíme jenom čas, takže nám štosy rozpracovaných výrobků uvnitř „továrny“ vadí z jiných důvodů.

Už musím končit. Knihu vřele doporučuji všem, kteří se zajímají o Lean a Kanban, rozšíří vám obzory. Rozloučím se banálním citátem.

…chceme umět odpovědět na tyto tři otázky: Co změnit? Na co to změnit? Jak tu změnu zařídit? … Pokud manažer nezná odpověď na tyto otázky, má právo se nazývat manažerem?

5 thoughts on “Cíl

  1. Aleš Roubíček

    “Takže pokud například vaši testeři dokáží otestovat 2 stories za týden, tak víc než 2 stories za týden nedodáte, ani kdyby se analytici a vývojáři rozkrájeli.”

    To je provda pouze v případě, že by nefungoval team a analytici s vývojářema by nebyli ochotný/schopný zastávat roli testera.

  2. danaketh

    “nefungoval team a analytici s vývojářema by nebyli ochotný/schopný zastávat roli testera”

    Cožeto? Proč by sakra měl analytik nebo vývojář zastávat roli testera? Jo, možná v týmu kde jsou dva. Ale v normálním týmu má každý svoji práci a svoje místo. Od testování je placen tester, ne programátor nebo analytik. To už bychom to mohli rovnou otočit a když zrovna nebude mít tester nebo analytik do čeho píchnout, můžou programovat. A co teprve uklízečka. Během pauzy na cigáro si může střihnout redesign firemního webu a po nocích fixovat bugy které napáchal analytik. A když bude analytik nemocnej, zaskočí za něj ten příjemnej strejda co nám vozí zásilky u PPL.

    *thumbs up* S váma pracovat to musí bejt normálně tým snů…

  3. Lukáš Křečan

    Aleš má pravdu v tom, že k podobnému stavu směřuje a že to navíc funguje. Stavíme multifunkční týmy, kde jsou všechny profese zastoupeny. To například spěje k tomu, že se testeři nahrazují automatickými testy. Testeři pak mají čas pomáhat analytikům a třeba i vývojářům s jejich testy. Všichni dělají věci spolu a neházejí si je tolik přes zeď. Jenom pořád nevím, jestli to ty závislosti a úzká hrdla ruší nebo jen zamlžuje.

    danakethovi rozumím, po mě chtějí abych dělal operations a staral se o servery. Do toho se mi vůbec nechce. Neumím to a žere mi to energii na dělání něčeho co umím. Na druhou stanu není cílem dělat co nejlepší analýzu, kód nebo testování. Cílem je dělat co nejužitečnější software.

  4. banter

    Multifunkční týmy ano. Ovšem když programátoři testují, tak to není dobře viz článek Top Five (Wrong) Reasons You Don’t Have Testers by Joel Spolsky (který se v brzké době chystám přeložit) http://www.joelonsoftware.com/articles/fog0000000067.html

    Např.: you see how expensive it is to replace that star programmer, at $100,000 a year, who got sick of being told to “spend a few weeks on testing before we release” and moved on to a more professional company

Comments are closed.