Vyhodnocení efektivity procesů pomocí map hodnotového toku
Když vytvoříte mapu hodnotového tokunebo VSM, pomůže vám analyzovat aktuální proces cyklu vydávání verzí. Účelem mapování hodnotového proudu je vizuálně ukázat, kde v procesu tým vytváří hodnotu a kde dochází k plýtvání. Cílem je přijít na proces, který zákazníkovi poskytuje maximální hodnotu s minimálním plýtváním. Virtuální počítač vám může pomoct určit oblasti, které buď nepřispívají žádnou hodnotu, nebo které skutečně snižují hodnotu produktu.
Pojďme se podívat, jak si Tailspin vede.
Mara, která je pro tým nová, vytvoří virtuální počítač, který jí pomůže pochopit stávající proces. Díky mapování toku hodnot získá představu o tom, kde tým zapadá do modelu vyspělosti DevOps. Jak se ukázalo, vyspělejší týmy obvykle vydávají rychleji, s větší jistotou a s menším počtem chyb než méně vyspělých týmů.
Mara ví, že ještě nerozumí všemu, takže na tabuli v zasedací místnosti vytvoří rychlou mapu toku hodnot. Budou tam nějaké mezery a nezodpovězené otázky, ale to je v pořádku. Je to začátek. Až to bude moct, podělí se o to s týmem. VSM poskytuje všem společný výchozí bod pro identifikaci prvních kroků směrem ke zlepšení toho, jak Tailspin vyvíjí a uvolňuje své webové stránky.
Podívejme se na její mapu.
Vysvětlení aktuálního procesu
Mara shromáždí tým v zasedací místnosti, aby představila svůj virtuální počítač.
Mara: VSM nám pomáhá měřit, kde má proces hodnotu pro zákazníka a kde spotřebovává čas bez produkce jakékoli hodnoty. Naše mapa začíná v levém horním rohu funkční specifikací softwaru. Pojďme sledovat jen jednu funkci, abychom viděli, jak prochází naším aktuálním verzovacím cyklem.
Někteří lidé protočí oči, ale Mara pokračuje.
Procesy vývoje
Vytváření nové funkce nyní začíná vytvořením štítku ve správě zdrojového kódu 
. Máme jednu osobu, která může vytvářet štítky, a to je Andy. Požádáme o štítek e-mailem. Používáme centralizovaný systém správy verzí, takže Andy čeká, až je veškerý existující kód zkontrolován a stabilní, než vytvoří štítek. Po vytvoření štítku dostaneme e-mail s informací, že můžeme začít pracovat. Tento proces trvá až tři dny a nemá pro zákazníka žádnou hodnotu. Věci bez hodnoty pro zákazníka by měly trvat co nejméně času.
Kódování funkce trvá asi čtyři dny po získání přístupu ke všem souborům, které potřebujeme 
. Abychom měli přístup ke správě zdrojového kódu, musíme být v podnikové síti. Tento čas má hodnotu pro zákazníka. Chtějí tuto funkci.
Testovací procesy
Jakmile se rozhodneme, že máme stabilní sestavení, aktualizujeme tabulku, abychom Amitě řekli, že je sestavení připravené k testování a kde ho najít 
. Trvá to dva dny, než dostane oznámení.
Amita ručně testuje sestavení 
. Tento proces trvá déle, jak roste kódová základna. Prozatím řekněme tři dny. Poté pošle e-mailem Andy zprávu o chybách. Testování nepřidává hodnotu, ale je to nutné.
Andy pak musí prioritizovat chyby a přiřadit práci . Než Andy pochopí problémy a dostane je správným vývojářům, může to trvat další tři dny.
Provozní procesy
Když Amita schválí sestavení, předá ho Timovi. Tim musí tento build nasadit na předprodukční servery pro další testování. Předprodukční servery se často nesynchronizují s nejnovějšími opravami a aktualizacemi potřebnými ke spuštění webu. Nasazení do předprodukce a spuštění některých testů trvá Timovi asi dva dny. Opět platí, že nasazování do předprodukčního prostředí nepřidává hodnotu, ale je nutné 
.
Jakmile je sestavení připravené pro produkční prostředí, musí vedení verzi schválit, než bude možné ji nasadit. Schválení probíhá ve schůzce. Než se vedení setká a zkontroluje vydání, trvá to čtyři dny.
Nakonec Tim tuto funkci nasadí a tato funkce se dostane k zákazníkovi v pravém horním rohu VSM. Pokud se konfigurace produkčního serveru změnila tak, aby se nesynchronizuje s předprodukčním prostředím, Tim ji napřed musí aktualizovat, což trvá jeden den 
.
Výpočet metrik hodnoty zákazníka
Teď se můžeme podívat na klíčové metriky výkonu a zjistit, jak si vedeme.
Celková doba zpracování je doba potřebná k tomu, aby se funkce dostala k zákazníkovi. Tady je celkový čas 22 dní. Doba zpracování je doba strávená na funkci, která má hodnotu pro zákazníka. V této části zahrnuje doba zpracování čtyři dny pro kódování plus jeden den pro nasazení funkce, která poskytuje celkem pět dnů.
Poměr aktivity je doba zpracování dělená celkovým průběžným časem:
$${Poměr\ aktivity\ =\ }{\dfrac{Doba\ zpracování}{Celková\ průběžná\ doba}}$$
Toto je naše účinnost. Vynásobením efektivity číslem 100 získáte procento. Výsledek je větší než 0% a obvykle menší než 100%. Vyšší procento označuje vyšší efektivitu.
Nahraďte naše čísla a získáme:
$${Poměr aktivity\ =\ }{\dfrac{5\ dnů}{22\ dní}}{\ =\ .23}$$
Vynásobte výsledek číslem 100 a získáte 23%.
Jak vidíte, máme hodně místa na zlepšení. A vývoj funkce, který trvá 22 dní, je příliš dlouhý.
Tim: Jak nám to pomůže?
Kam odsud jdeme?
Mara: Pomáhá zjistit, kde jsme teď, abychom mohli určit oblasti, kde je odpad. Chceme minimalizovat čas strávený zákazníkem, který nemá žádnou hodnotu. Věřím, že můžeme skutečně zlepšit naši efektivitu tím, že přijmeme přístup DevOps. Pro jednu věc můžeme automatizovat mnoho z těchto kroků, které rozhodně zkracují čas.
Nenavrhuji, abychom zahodili naše současné procesy, ale myslím, že můžeme pracovat na efektivnějším procesu v malých přírůstcích, aniž bychom narušili to, co aktuálně máme.
Pojďme se podívat na několik oblastí, kde můžeme zlepšit.
Andy: Můžeme také začít na začátku. Dlouho mi trvá získat popisek na kód, abychom mohli začít novou funkci. Musím se podívat na vývojáře a požádat je, aby zkontrolovali, co mají, abychom mohli vytvářet a testovat. Pokud zjistíte, jak to urychlit, budete mít mou pozornost.
Také jsem si všiml, že tam nepočítáte s časem na samotné sestavení. To teď trvá půl dne. Bylo by hezké vidět, jak se čas zlepšuje.
Amita: A vývoj neaktualizuje tabulku, aby mi dal vědět, že existuje nový build, který potřebuje testování. Ušetřilo by to čas, kdyby bylo nějaký způsob, jak se ujistit, že se tato část dokončí.
Mara: Skvělé! Myslím, že DevOps nám může pomoct se všemi těmito obavami.
Andy: Teď nemáme čas změnit proces. Slyšel jsi Irwina. Jsme tady v krizovém režimu!
Mara: rozumím. Prozatím uděláme to, co děláme vždy. Všichni ale můžeme přemýšlet o naší části procesu a o tom, jak můžeme zlepšit. Můžeme začít provádět malé změny paralelně s našimi aktuálními procesy. Pak uvidíme, jestli nám DevOps pomůže bez narušení toho, co máme. Nechám si tuto mapu a výkonové metriky. Pokud nakonec přijmeme postupy Azure DevOps, můžeme se k číslu vrátit znovu. Možná můžeme v určitém okamžiku aktualizovat VSM.