Vyhodnocení efektivity procesů pomocí map hodnotových toků
Když vytvoříte mapu hodnotového toku nebo VSM, pomůže vám to analyzovat aktuální proces cyklu vydávání verzí. Účelem mapy hodnotového toku je vizuálně ukázat, kde tým v rámci procesu 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.
Podívejme se, jak si vede firma Tailspin.
Mara, který je v týmu nová, bude vytvářet mapu hodnotového toku, která jí pomůže pochopit stávající proces. Díky virtuálnímu počítači získá představu o tom, kde tým zapadá do modelu vyspělosti DevOps. Ukazuje se, že vyspělejší týmy obvykle vydávají nové verze rychleji s větší jistotou a s menším počtem chyb, než je tomu u méně vyspělých týmů.
Mara ví, že ještě nerozumí všemu, takže na tabuli v místnosti pro schůzky vytvoří rychlý virtuální počítač. Budou tam nějaké mezery a nezodpovězené otázky, ale to je v pořádku. Je to jen začátek. Když ji dokončí tak, jak to dokáže, bude mapu sdílet s týmem. Virtuální počítač poskytuje všem společný výchozí bod pro identifikaci prvních kroků směrem ke zlepšení vývoje a vydávání webových stránek společnosti Tailspin.
Pojďme se podívat na její mapu.
Porozumění současnému procesu
Mara shromáždí tým do jednací místnosti, aby jim představila svou mapu hodnotového toku.
Mara: A VSM nám pomáhá měřit, kde má proces hodnotu pro zákazníka a kde se jí čas bez produkce jakékoli hodnoty. Naše mapa začíná v levém horním rohu funkční specifikací softwaru. Pojďme sledovat jenom jednu funkci, abychom viděli, jak prochází naším aktuálním cyklem vydávání verzí.
Někteří lidé kroutí očima, ale Mara pokračuje.
Procesy vývoje
Vytvoření nové funkce v současné době začíná vytvořením popisku ve správě zdrojového kódu 
. V týmu máme jednoho člověka, který může vytvářet označení, a to je Andy. Požádáme o popisek e-mailem. Používáme centralizovaný systém správy verzí, takže Andy čeká, dokud se veškerý existující kód nekontroluje a stabilní, než vytvoří popisek. Po vytvoření označení dostaneme e-mail s informací, že můžeme začít pracovat. Tento proces trvá až tři dny a nemá žádnou hodnotu pro zákazníka. Procesy, které nemají žádnou hodnotu pro zákazníka, by měly trvat co možná nejkratší dobu.
Kódování funkce trvá asi čtyři dny po získání přístupu ke všem souborům, které potřebujeme 
. Abychom mohli přistupovat ke správě zdrojového kódu, musíme být v podnikové síti. Tento čas přináší hodnotu pro zákazníka. Zákazník tuto funkci požaduje.
Procesy testování
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 . Než dostane oznámení, trvá to dva dny.
Amita ručně testuje sestavení 
. Tento proces se prodlužuje s tím, jak roste základ kódu. Momentálně jsou to řekněme tři dny. Amita pak pošle Andymu e-mail se zprávou o chybách. Testování nepřidává hodnotu, ale je nezbytné.
Andy pak musí nějakou dobu trvat, než provede třídění chyb a přiřadí práci . Může to trvat další tři dny, než Andy porozumí příslušným problémům a přiřadí je správným vývojářům.
Provozní procesy
Když Amita sestavení schválí, 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ředprodukčního nasazení a spuštění některých testů trvá Tim asi dva dny. Při nasazování do předprodukčního prostředí se opět nepřidá hodnota, je to nezbytné 
.
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í sejde a vydávanou verzi zkontroluje, trvá to čtyři dny.
Nakonec Tim tuto funkci nasadí a tato funkce ji provede u zákazníka v pravém horním rohu virtuálního počítače. 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 metriky hodnoty pro zákazníka
Teď se můžeme podívat na klíčové metriky výkonu a podívat se, jak měříme.
Celková doba realizace je doba potřebná pro doručení funkce 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 předstihem:
$${Poměr\ aktivity\ =\ }{\dfrac{Doba\ zpracování}{Celková\ doba\ realizace}}$$
To vyjadřuje naši efektivitu. Když efektivitu vynásobíme hodnotou 100, získáme výsledek v procentech. Výsledek je větší než 0 % a obvykle menší než 100 %. Vyšší procento indikuje vyšší efektivitu.
Když doplníme naše hodnoty, získáme následující:
$${Poměr aktivity\ =\ }{\dfrac{5\ dnů}{22\ dní}}{\ =\ .23}$$
Výsledek vynásobíte číslem 100 a 23 %.
Jak vidíte, máme spoustu prostoru pro zlepšení. Doba 22 dnů, která je potřeba pro vývoj nějaké funkce, je příliš dlouhá.
Tim: Tak jak nám to pomůže?
Jaké jsou další kroky?
Mara: Pomáhá zjistit, kde jsme teď, abychom mohli určit oblasti, kde je odpad. Chceme minimalizovat dobu strávenou aktivitou, která nemá žádnou hodnotu pro zákazníka. Věřím tomu, že můžeme skutečně zlepšit naši efektivitu tím, že budeme postupovat podle postupů DevOps. Pro jednu věc můžeme automatizovat mnoho z těchto kroků, které rozhodně zkracují čas.
Nenavrhuji, abychom opustili naše současné procesy, ale myslím si, že můžeme proces postupně malými kroky zefektivňovat, aniž bychom narušili to, co už máme zavedené.
Pojďme se podívat jen na několik oblastí, kde se můžeme zlepšit.
Andy: Můžeme také začít na začátku. Dlouho mi trvá, než získám označení kódu, abychom mohli začít pracovat na nové funkci. Musím obcházet vývojáře a žádat je, aby vrátili kód se změnami, abychom mohli vytvořit a otestovat sestavení. Pokud zjistíte, jak to urychlit, budete mít mou pozornost.
Taky jsem si všiml, že tam nemáš čas pro samotné sestavení. To teď zabere půl dne. Bylo by hezké, kdyby se tenhle čas zlepšil.
Amita: A vývoj neaktualizuje tabulku tak, 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 s těmito potížemi může pomoct.
Andy: Teď nemáme čas změnit proces. Slyšeli jste Irwina. Máme tu teď krizový režim.
Mara: Rozumím. Pojďme prozatím dělat to, co vždycky. Můžeme ale všichni přemýšlet o své části procesu a jak ji můžeme zlepšit. Můžeme začít dělat malé změny souběžně s našimi současnými procesy. Pak uvidíme, jestli nám DevOps pomůže bez narušení toho, co máme. Já schovám tuto mapu a metriku výkonu. Pokud nakonec přijmeme postupy Azure DevOps, můžeme se k číslu vrátit znovu. Možná budeme moct mapu hodnotového toku v nějaké chvíli aktualizovat.