Ocena wydajności procesu za pomocą map strumienia wartości

Ukończone

Podczas tworzenia mapy strumienia wartości (VSM) , pomaga to w analizie bieżącego procesu cyklu wydania. Celem programu VSM jest wizualne pokazanie, gdzie w procesie zespół tworzy wartość i gdzie występują odpady. 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.

Zobaczmy, jak firma Tailspin się prezentuje.

Mara, która jest nowym członkiem zespołu, stworzy VSM, aby pomóc jej 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 zwykle wprowadzają szybciej, z większą pewnością siebie i z mniejszą liczbą błędów niż mniej dojrzałe zespoły.

Mara wie, że nie rozumie jeszcze wszystkiego, więc narysuje szybką mapę VSM na białej tablicy w sali konferencyjnej. Będą pewne luki i pytania bez odpowiedzi, ale to jest w porządku. To początek. Gdy zrobi wszystko, co może, podzieli się tym 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.

Przyjrzyjmy się jej mapie.

Omówienie bieżącego procesu

Mara zbiera zespół w sali konferencyjnej, by zaprezentować swoje VSM.

Mara: VSM pomaga nam zmierzyć, gdzie proces ma wartość dla klienta i gdzie jedynie pochłania czas bez generowania żadnej wartości. Nasza mapa zaczyna się w lewym górnym rogu ze specyfikacją funkcjonalną oprogramowania. Skupmy się na jednej funkcji, aby zobaczyć, jak przechodzi przez nasz obecny cykl wydawniczy.

Niektórzy przewracają oczami, ale Mara kontynuuje.

Procesy programistyczne

Tworzenie nowej funkcji rozpoczyna się od utworzenia etykiety w systemie kontroli wersji . Mamy jedną osobę, która może tworzyć etykiety, a to Andy. Prosimy o etykietę e-mailem. 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 otrzymamy wiadomość e-mail z informacją, że możemy rozpocząć pracę. Ten proces trwa do trzech dni i nie ma wartości dla klienta. Rzeczy bez wartości dla klienta powinny zająć jak najmniej czasu.

Kodowanie funkcji trwa około czterech dni dla jednej osoby po dokonaniu dostępu do wszystkich plików, których potrzebujemy . Aby uzyskać dostęp do kontroli źródła, musimy być w sieci firmowej. Czas ten ma wartość dla klienta. Chcą 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źć . Dostaje powiadomienie po dwóch dniach.

Amita ręcznie testuje kompilację . Ten proces staje się dłuższy w miarę wzrostu bazy kodu. Na razie powiedzmy trzy dni. Następnie wysyła do Andy'ego e-maile z raportami o błędach. Testowanie nie dodaje wartości, ale jest konieczne.

Andy musi poświęcić czas, aby przeprowadzić triage usterek i przypisać pracę . Zrozumienie problemów przez Andy'ego i przekazanie ich odpowiednim programistom może potrwać kolejne trzy dni.

Procesy operacji

Kiedy Amita zatwierdza 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. Zajmuje Timowi około dwóch dni wdrożenie do środowiska przedprodukcyjnego i przeprowadzenie niektórych testów. Chociaż wdrażanie w środowisku przedprodukcyjnym ponownie nie dodaje wartości, jest konieczne .

Gdy kompilacja będzie gotowa do produkcji, kadra zarządzająca musi zatwierdzić wydanie, zanim będzie można je wdrożyć. Zatwierdzenie odbywa się na spotkaniu. Spotkanie z kierownictwem i przejrzenie 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 odbiegła od preprodukcji, Tim najpierw musi ją zaktualizować, co zajmuje jeden dzień .

Obliczanie metryk wartości klienta

Teraz możemy przyjrzeć się kluczowym metryce wydajności i zobaczyć, jak się mierzymy.

Łączny czas realizacji to czas potrzebny na wprowadzenie funkcji do klienta. W tym miejscu łączny czas wynosi 22 dni. czas przetwarzania 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}}$$

Jest to nasza wydajność . Pomnożyj wydajność przez 100, aby uzyskać procent. Wynik jest większy niż 0% i zazwyczaj mniejszy niż 100%. Wyższa wartość procentowa oznacza większą wydajność.

Zastąp nasze liczby i otrzymujemy:

$${Współczynnik aktywności\ =\ }{\dfrac{5\ dni}{22\ dni}}{\ =\ .23}$$

Pomnożyj wynik przez 100 i uzyskasz 23%.

Jak widać, mamy dużo miejsca na poprawę. Rozwój funkcji, który trwa 22 dni, to zbyt długo.

Tim: Więc jak to pomoże nam?

Skąd idziemy stąd?

Mara: Pomaga zobaczyć, gdzie jesteśmy teraz, abyśmy mogli wskazać obszary, w których są odpady. Chcemy zminimalizować czas, który spędzamy bez wartości dla klienta. Uważam, że możemy naprawdę poprawić naszą wydajność, przyjmując podejście DevOps. Dla jednej rzeczy możemy zautomatyzować wiele z tych kroków, co zdecydowanie skraca czas.

Nie sugeruję, że porzucimy nasze obecne procesy, ale myślę, że możemy pracować nad bardziej wydajnym procesem w małych przyrostach bez zakłócania tego, co obecnie mamy.

Przyjrzyjmy się kilku obszarom, w których możemy się poprawić.

Andy: Możemy równie dobrze zacząć od początku. Naniesienie etykiety na kod zajmuje mi dużo czasu, abyśmy mogli rozpocząć pracę nad nową funkcją. Muszę chodzić do deweloperów i prosić ich, aby zaewidencjonowali to, co mają, abyśmy mogli tworzyć i testować. Jeśli uda ci się dowiedzieć, jak to przyspieszyć, zyskasz moje zainteresowanie.

Zauważyłem również, że nie masz tam czasu na wykonanie kompilacji. To trwa pół dnia teraz. Miło byłoby zobaczyć, że czas się polepsza.

Amita: I 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 Metodyka DevOps może pomóc nam w rozwiązywaniu wszystkich tych problemów.

Andy: Nie mamy czasu na zmianę procesu. Słyszałeś Irwina. Jesteśmy tutaj w trybie kryzysowym!

Mara: rozumiem. Na razie zróbmy to, co zawsze robimy. Ale wszyscy możemy myśleć o naszej części w procesie i tym, jak możemy poprawić. Możemy zacząć wprowadzać małe zmiany równolegle do naszych bieżących procesów. Następnie możemy sprawdzić, czy metodyka DevOps pomaga nam bez zakłócania tego, co mamy. Zachowam tę mapę i metryki wydajności. Jeśli w końcu wdrożymy praktyki usługi Azure DevOps, możemy ponownie zapoznać się z liczbami. Być może możemy zaktualizować program VSM w pewnym momencie.