Folyamathatékonyság felmérése értékáram-leképezésekkel
- 8 perc
A VSM létrehozásakor segít elemezni az aktuális kiadási ciklus folyamatát. A VSM célja, hogy vizuálisan bemutassa, hogy a folyamat során a csapat hol hoz létre értéket, és hol van hulladék. 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 nem járulnak hozzá semmilyen értékhez, vagy ténylegesen csökkentik a termék értékét.
Nézzük meg, hogyan áll helyt a Tailspin.
Mara, aki most ismerkedik a csapattal, létrehoz egy VSM-et, amely segít neki megérteni a meglévő folyamatot. A VSM-sel megismerheti, hogy a csapat hol illeszkedik a DevOps-érettségi modellbe. Kiderült, hogy az érettebb csapatok általában gyorsabban, magabiztosabban és kevesebb hibával adják ki munkáikat, mint a kevésbé érett csapatok.
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. Ez rendben van, ez egy kezdet. Ha mindent elvégez, amit csak lehet, megosztja 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 a térképére.
Az aktuális folyamat ismertetése
Mara összegyűjti a csapatot a tárgyalóban, hogy bemutassa a VSM-et.
Mara: A VSM segít felmérni, hogy egy folyamat hol rendelkezik értékkel az ügyfél számára, és hol fogyaszt időt anélkül, hogy értéket állítanának elő. Térképünk a szoftver funkcionális specifikációjával kezdődik. Csak egy funkciót követve tekintsük át az aktuális kiadási ciklust.
Vannak, akik feltekerik a szemüket, de Mara rányomja a gombra.
Fejlesztési folyamatok
Az új funkció létrehozása jelenleg egy címke létrehozásával kezdődik a forrásvezérlő 
. Van egy emberünk, aki képes címkéket létrehozni, 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ása után e-mailben értesítjük, hogy megkezdhetjük a munkát. Ez a folyamat legfeljebb három napot vesz igénybe, és nincs értéke az ügyfél számára. Az ügyfél számára értéktelen dolgoknak a lehető legkevesebb időt kell 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 forráskövetés eléréséhez a vállalati hálózaton kell dolgoznunk. Ez az idő értéket ad az ügyfélnek. Ezt a funkciót szeretnék.
Tesztelési folyamatok
Miután úgy döntünk, hogy stabil buildünk van, frissítünk egy 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, hogy értesítést kapjon.
Amita manuálisan teszteli a 
buildet. Ez a folyamat a kódbázis növekedésével tovább tart. Egyelőre mondjuk három napig. Ezután e-maileket küld Andynek hibajelentésekkel. A tesztelés nem ad értéket, de szükséges.
Andynek ezután időt kell szánnia a hibák osztályozására és a munka hozzárendelésére. Andynek további három napba telhet, hogy megértse a problémákat, és a megfelelő fejlesztőkhöz juttassa őket.
Műveleti folyamatok
Amikor Amita jóváhagy egy verziót, átadja Timnek. 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. Timnek körülbelül két napba telik, hogy üzembe helyezze az előgyártási rendszereket, és lefuttasson néhány tesztet. Habár az előgyártásban való üzembe helyezés nem ad értéket, 
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 napig tart, amíg a vezetőség találkozik és áttekinti a kiadást.
Végül Tim üzembe helyezi a funkciót, amely eljut az ügyfélhez ide, a VSM jobb felső sarkába. Ha a produkciós szerver konfigurációja el van csúszva, és nincs szinkronban a tesztkörnyezettel, Timnek először azt kell frissítenie, ami egy napot vesz igénybe 
.
Az ügyfél értékmetrikáinak kiszá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, amíg egy funkció eljut az ügyfélhez. 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égi arány úgy számolható ki, hogy a folyamatidőt elosztjuk a teljes átfutási idővel:
$$Aktivitási\ arány\ =\ \dfrac{Folyamatidő}{Teljes\ átfutási\ idő}$$
Ez a mi hatékonyságunk. Szorozza meg a hatékonyságot 100-zal a százalékérték eléréséhez. Az eredmény nagyobb, mint 0%, és általában kevesebb, mint 100%. A nagyobb százalék nagyobb hatékonyságot jelez.
Helyettesítsük a számokat, és a következőt kapjuk:
$${Tevékenység\ arány\ =\ }{\dfrac{5\ nap}{22\ nap}}{\ =\ 0,23}$$
Szorozza meg az eredményt 100-zal, és 23%kap.
Mint látható, sok lehetőségünk van a fejlesztésre. A funkció fejlesztéséhez szükséges 22 nap túl hosszú.
Tim: Miben segít ez nekünk?
Hová megyünk innen?
Mara: Segít látni, hogy hol vagyunk most, hogy meg tudjuk határozni a területeket, ahol hulladék van. Minimalizálni szeretnénk azt az időt, amelyet az ügyfél számára értéktelenként töltünk. Úgy gondolom, hogy a DevOps-megközelítéssel javíthatjuk a hatékonyságunkat. Az egyik dolog, hogy sok ilyen lépést automatizálhatunk, ami határozottan csökkenti a szükséges időt.
Nem azt javaslom, hogy vessük el a jelenlegi folyamatainkat. Úgy gondolom, hogy kisebb lépésekben hatékonyabb folyamaton dolgozhatunk anélkül, hogy megzavarnánk a jelenlegi működést.
Tekintsünk meg néhány területet, ahol javíthatunk.
Andy: Akár az elején is elkezdhetjük. Sok időbe telik, amíg lekérem a címkét a kódra, hogy elindíthassuk az új funkciót. Körbe kell mennem a fejlesztőkhöz, és megkérnem őket, hogy ellenőrizzék, mit készítettek el, hogy elkészítsük és teszteljük a kódot. Ha rá tudsz jönni, hogyan gyorsítsd fel, figyelek rá.
Azt is észrevettem, hogy nem szánt(ak) időt az építésre. Ez most fél napot vesz igénybe. Jó lenne látni, hogy az idő múlásával javul.
Amita: Dev nem mindig frissíti a számolótáblát, hogy tudjam, 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: Nagyszerű! Azt hiszem, a DevOps segíthet nekünk az összes ilyen aggályban.
Andy: Nincs időnk a folyamat módosítására. Hallottad Irwint. Válsághelyzetben vagyunk!
Mara: Értem. Egyelőre azt csináljuk, amit mindig csinálunk. De mindannyian gondolhatunk a folyamatban való szerepünkre, és arra, hogy hogyan tudunk fejlődni. A jelenlegi folyamatokkal párhuzamosan kisebb módosításokat is el tudunk kezdeni. Ezután láthatjuk, hogy a DevOps segít-e nekünk anélkül, hogy megzavarnánk azt, amink van. Megtartom ezt a térképet és a teljesítménymetrikákat. Ha végül bevezetjük az Azure DevOps-eljárásokat, újra áttekinthetjük a számokat. Lehet, hogy valamikor frissíthetjük a VSM-et.