A folyamathatékonyság értékelése értékáram-elemzésekkel
Értékstream-térkép vagy VSM létrehozásakor segít elemezni az aktuális kiadási ciklus folyamatát. A VSM célja annak vizuális megjelenítése, hogy a csapat a folyamat során hol teremt értéket, és hol tapasztalható veszteség. A cél egy olyan folyamat elérése, amely maximális értéket biztosít a minimális hulladékkal rendelkező ügyfélnek. A VSM segítségével rögzítheti azokat a területeket, amelyek vagy nem járulnak hozzá semmilyen értékhez, vagy ténylegesen csökkentik a termék értékét.
Lássuk, hogyan teljesít a Tailspin e tekintetben.
A csapat újonca, Mara egy VSM létrehozására készül, amelynek segítségével könnyebben megértheti a meglévő folyamatot. A VSM-sel megismerheti, hogy a csapat hol illeszkedik a DevOps-érettségi modellbe. Mint kiderült, az érettebb csapatok általában gyorsabban és nagyobb megbízhatósággal szállítják a kiadásokat, amelyek kevesebb hibát is tartalmaznak.
Mara tudja, hogy még nem ért meg mindent, ezért létrehoz egy gyors VSM-et a tárgyaló tábláján. Lesznek hiányosságok és megválaszolatlan kérdések, de ez rendben van. Ez a kiindulópont. Amikor legjobb tudása szerint elkészült, megosztja munkáját a csapattal. A VSM mindenki számára közös kiindulópontot kínál a Tailspin fejlesztésének és a webhelyek kiadásának javításához szükséges első lépések azonosításához.
Vessünk egy pillantást az ábrára.
Az aktuális folyamat értelmezése
Mara összehívja a csapatot a tárgyalóban, és bemutatja számukra az általa elkészített VSM-et.
Mara: A VSM segít felmérni, hogy egy folyamat hol van érték az ügyfél számára, és hol fogyaszt időt anélkül, hogy értéket termel. Térképünk a bal felső sarokban kezdődik a szoftver funkcionális specifikációjával. Csak egy funkciót követve tekintsük át az aktuális kiadási ciklust.
Néhányan a szemüket forgatják, de Mara nem hagyja annyiban.
Fejlesztési folyamatok
Az új funkció létrehozása jelenleg egy címke forrásvezérlőben 
való létrehozásával kezdődik. Közülünk egyvalaki hozhat létre címkéket, ez pedig Andy. A címkét e-mailben kérjük. Központosított verziókövetési rendszert használunk, így Andy megvárja, amíg az összes meglévő kód be van jelentkezve, és stabil lesz, mielőtt létrehozza a címkét. A címke létrehozását követően egy e-mailt kapunk arról, hogy megkezdhetjük a munkát. Ez a folyamat akár három napot is igénybe vehet, és nem teremt értéket a végfelhasználó számára. A végfelhasználó számára értéket nem teremtő folyamatoknak a lehető legkevesebb időt szabad csak igénybe venniük.
A funkció kódolása körülbelül négy napot vesz igénybe egy személy számára, miután hozzáférünk az összes szükséges fájlhoz 
. A vállalati hálózaton kell dolgoznunk ahhoz, hogy hozzáférjünk a verziókövetéshez. Ez a munkafolyamat értéket teremt a végfelhasználó számára. Elvégre használni szeretné a funkciót.
Tesztelési folyamatok
Miután úgy döntünk, hogy stabil buildünk van, frissítjük a számolótáblát, hogy közöljük Amitával, hogy van egy tesztelésre kész build, és hol találjuk meg 
. Két napba telik Amita értesítése.
Amita manuálisan teszteli a buildet 
. Ez a folyamat egyre hosszabbá válik, ahogy a kódbázis növekszik. Ezúttal mondjuk három napot vesz igénybe. Ezután Amita e-mailben elküldi Andynek a hibajelentéseket. A tesztelés nem teremt értéket, de elengedhetetlen.
Andynek ezután időt kell szánnia a hibák osztályozására és a munka hozzárendelésére . Akár újabb három nap is kellhet ahhoz, hogy Andy megértse a problémákat, majd a megfelelő fejlesztőhöz eljuttassa azokat.
Üzemeltetési folyamatok
Ha Amita jóváhagy egy buildet, Timnek adja át. Timnek üzembe kell helyeznie ezt a buildet az előkészítési kiszolgálókon a további teszteléshez. Az előkészületi kiszolgálók gyakran nem szinkronizálódnak a webhely futtatásához szükséges legújabb javításokkal és frissítésekkel. Tim körülbelül két napig tart, amíg üzembe helyezik az előgyártást, és lefuttatnak néhány tesztet. Az előkészületben való üzembe helyezés során azonban nem ad értéket, ezért szükséges 
.
Miután a build készen áll az éles használatra, a vezetőségnek jóvá kell hagynia a kiadást, mielőtt üzembe helyezhető lenne. A jóváhagyás egy értekezleten történik. Négy napba telik, amíg a vezetőség összeül, és áttekinti a kiadást.
Végül Tim üzembe helyezi a funkciót, és a funkció a VSM jobb felső sarkában található ügyfél számára teszi el. Ha az éles kiszolgáló konfigurációja elsodródott, így nincs szinkronban az előgyártással, Timnek először frissítenie kell, ami egy napot 
vesz igénybe.
A végfelhasználói értékteremtés mérőszámainak számítása
Most már áttekinthetjük a fő teljesítménymetrikákat, és megnézhetjük, hogyan mérjük fel a teljesítményt.
A teljes átfutási idő az az időtartam, amely alatt egy funkció eljut a végfelhasználóhoz. Itt a teljes idő 22 nap. A folyamatidő az az idő, amelyet egy olyan szolgáltatáson töltenek, amelynek értéke van az ügyfél számára. Itt a folyamat időtartama négy napot tartalmaz a kódoláshoz, valamint egy napot a funkció üzembe helyezéséhez, ami összesen öt napot ad.
A tevékenységarány a folyamatidő és a teljes átfutási idő osztva:
$${Tevékenységarány\ =\ }{\dfrac{Feldolgozási\ idő}{Teljes\ átfutási\ idő}}$$
Ez a szám a hatékonysági mutatónk. A hatékonyságot 100-zal szorozva kapjuk meg a százalékos értéket. Az eredmény 0%-nál nagyobb, és jellemzően 100%-nál kisebb. A nagyobb százalékos érték nagyobb hatékonyságot jelez.
Helyettesítsük be a számainkat, és a következőt kapjuk:
$${Activity\ ratio\ =\ }{\dfrac{5\ days}{22\ days}}{\ =\ .23}$$
Szorozza meg az eredményt 100-zal, és 23%.
Ahogy látható, ezen bőven van mit fejleszteni. Túlságosan sok az a 22 nap is, amíg egy funkció fejlesztése megtörténik.
Tim: Szóval, hogyan segít ez nekünk?
Hova juthatunk el innen?
Mara: Segít látni, hogy hol vagyunk most, hogy meg tudjuk határozni a területeket, ahol hulladék van. A lehető legkisebbre szeretnénk csökkenteni azt az időt, ami úgy telik el, hogy közben nem teremtünk értéket a végfelhasználó számára. Úgy gondolom, egy DevOps-megközelítés alkalmazásával jelentősen javíthatnánk a hatékonyságunkon. Egy dolog, tudjuk automatizálni sok ilyen lépést, ami határozottan csökkenti az idő.
Nem azt mondom, hogy vessük el a jelenlegi folyamatainkat, de szerintem kis lépésekben haladva egy hatékonyabb folyamatot valósíthatunk meg úgy, hogy közben nem ziláljuk szét a jelenlegit.
Nézzünk pár területet azok közül, ahol fejlődhetünk.
Andy: Lehet, hogy az elején is kezdjük. Sok időbe telik, mire megkapom a címkét a kódhoz, hogy aztán nekiláthassunk az új funkció fejlesztésének. Egyenként meg kell kérnem a fejlesztőket, hogy adják be amijük van, így létrehozhassuk a buildet, és tesztelhessünk. Ha rá tudsz jönni, hogyan gyorsítsd fel, figyelek rá.
Ezen kívül azt is észrevettem, hogy nem tüntetted fel az ábrán magát a build létrehozásához szükséges időt. Ez jelenleg fél napba telik. Jó lenne ezen az időn javítani.
Amita: És Dev nem mindig frissíti a számolótáblát, hogy tudassa velem, hogy van egy új build, amelyet tesztelni kell. Időt takarítana meg, ha lenne rá mód, hogy a rész elkészüljön.
Mara: Nagy! A DevOps szerintem mindezekre megoldást nyújthat.
Andy: Nincs időnk a folyamat megváltoztatására. Hallottátok Irwint. Most vészhelyzeti üzemmódban vagyunk!
Mara: Megértem. Most csináljuk azt, amit mindig. Mindegyikünk elgondolkodhat azonban a folyamatban betöltött szerepén és a fejlesztési lehetőségeken. Elkezdhetünk kis módosításokat eszközölni, a jelenlegi folyamatokkal párhuzamosan. Ezután láthatjuk, hogy a DevOps segít-e nekünk anélkül, hogy megzavarnánk azt, amink van. Elteszem későbbre ezt az ábrát és a teljesítménymutatókat. Ha végül bevezetjük az Azure DevOps-eljárásokat, újra áttekinthetjük a számokat. Egyszer talán a VSM-et is frissíthetjük.