Ocena wydajności procesu za pomocą mapowania strumienia wartości
Podczas tworzenia mapy strumienia wartości lub programu VSM ułatwia ona analizowanie bieżącego procesu cyklu wydania. Celem tego procesu jest wizualne przedstawienie miejsc tworzenia wartości i złego wykorzystania zasobów. Celem jest dotarcie do procesu, który dostarcza klientowi maksymalną wartość z minimalnymi odpadami. Program VSM może pomóc w określeniu tych obszarów, które nie przyczyniają się do żadnej wartości lub które rzeczywiście zmniejszają wartość produktu.
Sprawdźmy, jak wygląda sytuacja w Tailspin.
Nowy pracownik, Mara, zamierza opracować mapowanie strumienia wartości, które pomoże jej lepiej zrozumieć istniejący proces. Dzięki usłudze VSM dowie się, gdzie zespół pasuje do modelu dojrzałości DevOps. Jak się okazuje, bardziej dojrzałe zespoły mają krótszy cykl wydawniczy, większą pewność i generują mniej błędów w porównaniu z mniej dojrzałymi zespołami.
Mara wie, że nie rozumie jeszcze wszystkiego, więc utworzy szybką maszynę VSM na tablicy w sali konferencyjnej. Będą pewne luki i pytania bez odpowiedzi, ale to jest w porządku. To tylko początek. Gdy zrobi tyle, ile da radę, podzieli się wynikami z zespołem. Program VSM zapewnia wszystkim wspólny punkt wyjścia do identyfikowania pierwszych kroków w kierunku poprawy sposobu, w jaki firma Tailspin opracowuje i publikuje swoje witryny internetowe.
Spójrzmy na jej mapę.
Zrozumienie obecnego procesu
Mara zbiera zespół w sali konferencyjnej, aby zaprezentować mapowanie strumienia wartości.
Mara: VSM pomaga nam zmierzyć, gdzie proces ma wartość dla klienta i gdzie jedzie na czas bez generowania żadnej wartości. Nasza mapa zaczyna się w lewym górnym rogu ze specyfikacją funkcjonalną oprogramowania. Przyjrzyjmy się tylko jednej funkcji, aby zobaczyć, jak przechodzi przez nasz bieżący cykl wydania.
Niektórzy przewracają oczami z dezaprobatą, ale Mara kontynuuje.
Procesy deweloperskie
Tworzenie nowej funkcji rozpoczyna się od utworzenia etykiety w kontroli 
źródła. Tylko jedna osoba może tworzyć etykiety i jest to Andy. Żądamy etykiety pocztą e-mail. Używamy scentralizowanego systemu kontroli wersji, więc Andy czeka, aż cały istniejący kod zostanie zaewidencjonowany i stabilny przed utworzeniem etykiety. Po utworzeniu etykiety dostajemy wiadomość e-mail z informacją o możliwości rozpoczęcia pracy. Trwa to do trzech dni i nie generuje żadnej wartości dla klienta. Elementy bez wartości dla klienta powinny zajmować jak najmniej czasu.
Kodowanie funkcji trwa około czterech dni dla jednej osoby po dokonaniu dostępu do wszystkich potrzebnych plików 
. Aby uzyskać dostęp do kontroli kodu źródłowego, musimy być w sieci firmowej. Ten czas ma wartość dla klienta. Potrzebuje on tej funkcji.
Procesy testowania
Po podjęciu decyzji, że mamy stabilną kompilację, zaktualizujemy arkusz kalkulacyjny, aby poinformować Amitę, że jest gotowa kompilacja do testowania i gdzie ją 
znaleźć. Skuteczne powiadomienie zajmuje dwa dni.
Amita ręcznie testuje kompilację 
. Ten proces wydłuża się w miarę rozrastania się bazy kodu. Załóżmy, że zajmuje to trzy dni. Następnie przesyła ona Andy-emu wiadomość e-mail z raportami o błędach. Testowanie nie generuje wartości, ale jest konieczne.
Andy musi zająć trochę czasu, aby sklasyfikować usterki i przypisać pracę . Andy’emu może zająć trzy kolejne dni, aby poznać problemy i przydzielić je odpowiednim deweloperom do rozwiązania.
Procesy operacyjne
Kiedy Amita zatwierdzi kompilację, przekazuje ją Timowi. Tim musi wdrożyć tę kompilację na serwerach przedprodukcyjnych, aby uzyskać więcej testów. Często serwery przedprodukcyjne nie są zsynchronizowane z najnowszymi poprawkami i aktualizacjami wymaganymi do uruchomienia witryny internetowej. Wdrożenie w środowisku przedprodukcyjnym trwa około dwóch dni i uruchamianie niektórych testów. Ponownie, podczas wdrażania w środowisku przedprodukcyjnym nie dodaje wartości, konieczne 
jest .
Gdy kompilacja będzie gotowa do produkcji, kierownictwo musi zatwierdzić wydanie, zanim będzie można je wdrożyć. Zatwierdzenie odbywa się na spotkaniu. Zorganizowanie spotkania liderów i zatwierdzenie wydania zajmuje cztery dni.
W końcu Tim wdroży tę funkcję, a funkcja zostanie udostępniona klientowi w prawym górnym rogu programu VSM. Jeśli konfiguracja serwera produkcyjnego dryfowała, więc nie jest zsynchronizowana z preprodukcją, Tim najpierw musi go zaktualizować, co trwa jeden dzień 
.
Obliczanie metryk wartości dla klienta
Teraz możemy przyjrzeć się kluczowym metryce wydajności i zobaczyć, jak się mierzymy.
Całkowity czas realizacji to czas potrzebny na udostępnienie funkcji klientowi. W tym miejscu łączny czas wynosi 22 dni. Czas procesu to czas spędzony na funkcji, która ma wartość dla klienta. W tym miejscu czas procesu obejmuje cztery dni kodowania oraz jeden dzień na wdrożenie funkcji, co daje łącznie pięć dni.
Współczynnik aktywności to czas procesu podzielony przez całkowity czas realizacji:
$${współczynnik\ aktywności\ =\ }{\dfrac{czas\ procesu}{całkowity\ czas\ realizacji}}$$
To jest nasza wydajność. Mnożąc wydajność przez 100, uzyskamy wartość procentową. Wynik jest większy od 0% i zwykle nie osiąga 100%. Im wyższa wartość procentowa, tym większa wydajność.
Po podstawieniu naszych wartości uzyskamy:
$${Współczynnik aktywności\ =\ }{\dfrac{5\ dni}{22\ dni}}{\ =\ .23}$$
Pomnożyj wynik przez 100, a otrzymasz 23%.
Jak widać, mamy sporo do poprawy. 22 dni na opracowanie funkcji to zbyt długo.
Tim: Więc jak to pomoże nam?
Co możemy zrobić?
Mara: Pomaga to zobaczyć, gdzie jesteśmy teraz, abyśmy mogli wskazać obszary, w których są odpady. Chcemy zminimalizować czas, w którym nie jest generowana żadna wartość dla klienta. Myślę, że naprawdę możemy poprawić naszą wydajność, wdrażając DevOps. Dla jednej rzeczy możemy zautomatyzować wiele z tych kroków, co zdecydowanie skraca czas.
Nie proponuję całkowitego porzucenia obecnych procesów, ale myślę, że możemy popracować nad zwiększeniem wydajności obecnych procesów małymi krokami, bez zakłócania obecnie stosowanych rozwiązań.
Spójrzmy na kilka obszarów, które możemy usprawnić.
Andy: Możemy równie dobrze zacząć od początku. Wygenerowanie etykiety kodu zajmuje mi dużo czasu, a dopiero po tym możemy zacząć prace nad nową funkcją. Muszę prosić deweloperów o dopisanie tego, co już utworzyli, żebyśmy mogli przystąpić do programowania i testowania kompilacji. Jeśli możesz dowiedzieć się, jak przyspieszyć, będziesz mieć moją uwagę.
Widzę też, że nie macie wystarczająco dużo czasu na samą obsługę kompilacji. W tej chwili zajmuje to pół dnia. Dobrze byłoby skrócić ten czas.
Amita: A deweloper nie zawsze aktualizuje arkusz kalkulacyjny, aby poinformować mnie, że jest nowa kompilacja, która wymaga testowania. Zaoszczędziłoby to czas, gdyby był jakiś sposób, aby upewnić się, że część zostanie wykonana.
Mara: Świetnie! Myślę, że DevOps może nam pomóc w tych wszystkich problemach.
Andy: Nie mamy teraz czasu na zmianę procesu. Słyszeliście Irwina. Mamy sytuację kryzysową!
Mara: Rozumiem. Na razie róbmy to co zawsze. Ale możemy zastanowić się nad naszymi rolami w procesie i sposobami ich udoskonalenia. Równolegle do naszych procesów możemy wprowadzać niewielkie zmiany. Następnie możemy sprawdzić, czy metodyka DevOps pomaga nam bez zakłócania tego, co mamy. Zachowam to mapowanie i metryki wydajności. Jeśli w końcu wdrożymy praktyki usługi Azure DevOps, możemy ponownie zapoznać się z liczbami. Może zaktualizujemy też mapowanie.