Skumulowany przepływ, czas realizacji i wskazówki dotyczące czasu cyklu

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Diagramy przepływu skumulowanego (CFD) służą do monitorowania przepływu pracy w systemie. Z wykresu można wyodrębnić dwie podstawowe metryki do śledzenia, czasu cyklu i czasu realizacji. Aby skonfigurować lub wyświetlić wykresy CFD, zobacz Konfigurowanie skumulowanego wykresu blokowego.

Możesz też dodać do pulpitów nawigacyjnych wykresy kontroli czasu i czasu cyklu potencjalnego klienta.

Przykładowe wykresy i podstawowe metryki

Przepływ ciągły CFD zapewnia wykres najbardziej faworyzowany przez zespoły, które podążają za procesem lean.

Jednak wiele zespołów zaczęło łączyć praktyki lean z Scrum lub innymi metodologiami, co oznacza, że praktykują w ramach iteracji lub przebiegu. W takiej sytuacji diagram ma nieco inny wygląd i udostępnia dwa dodatkowe i bardzo cenne informacje, jak pokazano na następnym wykresie.

Przepływ ciągły

Określony okres CFD pokazany tutaj jest dla ukończonego przebiegu.

Górna linia reprezentuje zakres ustawiony dla przebiegu. A ponieważ praca musi zostać ukończona do ostatniego dnia przebiegu, nachylenie stanu Zamknięte wskazuje, czy zespół jest na dobrej drodze do ukończenia przebiegu. Najprostszym sposobem myślenia o tym widoku jest wykres spalony.

Dane są zawsze przedstawiane z pierwszym krokiem procesu w lewym górnym rogu i ostatnim krokiem procesu w prawym dolnym rogu.

Stały okres CFD dla ukończonego przebiegu

Metryki wykresu

Wykresy CFD wyświetlają liczbę elementów roboczych pogrupowanych według kolumny state/Kanban w czasie. Z wykresu można wyodrębnić dwie podstawowe metryki do śledzenia, czasu cyklu i czasu realizacji.

---

Metryka

Definicja

---

Czas^{cyklu 1}

Mierzy czas potrzebny na przejście pracy przez pojedynczy proces lub stan przepływu pracy. Obliczanie jest od początku jednego procesu do początku następnego procesu.

Czas^{realizacji 1}

W przypadku procesu przepływu ciągłego: mierzy czas potrzebny na wykonanie żądania (na przykład dodanie proponowanego scenariusza użytkownika) do momentu zakończenia żądania (zamkniętego).

W przypadku procesu przebiegu lub stałego okresu: mierzy czas od momentu rozpoczęcia pracy w żądaniu do momentu zakończenia pracy (tj. czasu od aktywnej do zamkniętej).

Praca w toku

Mierzy ilość pracy lub liczbę elementów roboczych, które są aktywnie wykonywane.

Scope

Reprezentuje ilość pracy przydzielonej przez dany okres czasu. Dotyczy tylko procesów o stałym okresie.

---

¹ Widżet CFD (Analiza) i wbudowany wykres CFD (magazyn danych śledzenia pracy) nie zapewniają dyskretnych liczb w czasie i czasie cyklu realizacji. Jednak widżety Czas realizacji i Czas cyklu zawierają te liczby.

Istnieje dobrze zdefiniowana korelacja między czasem/czasem cyklu realizacji i pracą w toku (WIP). Tym więcej funkcji WIP, tym dłuższy jest czas cyklu, co również prowadzi do dłuższych czasów realizacji. Przeciwieństwo jest również prawdziwe — im mniej WIP, tym krótszy cykl i czas realizacji. Gdy zespół programistyczny koncentruje się na mniejszej liczbie elementów, skraca cykl i czasy realizacji. Ta korelacja jest kluczowym powodem, dla którego można ustawić limity pracy w toku na tablicy Kanban.

Liczba elementów roboczych wskazuje łączną ilość pracy w danym dniu. W ustalonym okresie CFD zmiana w tej liczbie wskazuje zmianę zakresu dla danego okresu. W przepływie ciągłym CFD wskazuje całkowitą ilość pracy w kolejce i ukończoną przez dany dzień.

Dekompozycja pracy w określonych kolumnach tablicy Kanban zapewnia widok, w którym praca jest w toku. Ten widok zawiera szczegółowe informacje na temat tego, gdzie praca jest bezproblemowa, gdzie występują blokady i gdzie w ogóle nie jest wykonywana żadna praca. Trudno jest odszyfrować tabelaryczny widok danych, jednak wizualny wykres CFD dostarcza dowodów na to, że coś dzieje się w określony sposób.

Identyfikowanie problemów, wykonywanie odpowiednich działań

CFD odpowiada na kilka konkretnych pytań i na podstawie odpowiedzi, można podjąć działania w celu dostosowania procesu w celu przejścia pracy przez system. Przyjrzyjmy się każdemu z tych pytań tutaj.

Czy zespół ukończy pracę na czas?

To pytanie dotyczy tylko kontraktów CFD z ustalonym okresem. Poznasz krzywą (lub postęp) pracy w ostatniej kolumnie tablicy Kanban.

W tym scenariuszu może być konieczne zmniejszenie zakresu pracy w iteracji, jeśli jest jasne, że praca w stałym tempie nie jest wystarczająco szybka. Może to wskazywać, że praca została niedoszacowana i powinna być uwzględniona w następnym planowaniu przebiegów.

Jednak mogą istnieć inne przyczyny, które można określić, patrząc na inne dane na wykresie.

W jaki sposób przepływ pracy postępuje?

Czy zespół kończy pracę w stałym tempie? Jednym ze sposobów na powiedzenie jest przyjrzenie się odstępom między różnymi kolumnami na wykresie. Czy są one podobne lub jednolite odległości od siebie od początku do końca? Czy kolumna wydaje się być płaska w ciągu kilku dni? Czy wydaje się, że "wybrzuszenie"?

Mura, chude termin dla płaskich linii i wybrzuszenia, oznacza nierówność i wskazuje formę odpadów (Muda) w systemie. Wszelkie nierówności w systemie spowodują wybrzuszenia w CFD.

Monitorowanie kontraktów CFD pod kątem prostych linii i wybrzuszenia obsługuje kluczową część procesu zarządzania projektami teorii ograniczeń. Ochrona najwolniejszego obszaru systemu jest nazywana procesem perkusyjnym i jest częścią planowania pracy.

Dwa problemy pojawiają się wizualnie jako płaskie linie i jako wybrzuszenia.

Płaskie wiersze pojawiają się, gdy zespół nie aktualizuje swojej pracy z regularnym cyklem. Tablica Kanban zapewnia najszybszy sposób przejścia pracy z jednej kolumny do innej.
Płaskie linie mogą również pojawiać się, gdy praca między co najmniej jednym procesem trwa dłużej niż planowano. Płaskie linie pojawiają się w wielu częściach systemu, ponieważ jeśli tylko jedna część systemu lub dwie części systemu mają problemy, zobaczysz wybrzuszenie.

Płaskie linie

Wybrzuszenia występują, gdy praca tworzy się w jednej części systemu i nie przechodzi przez proces.
Na przykład wybrzuszenie może wystąpić, gdy testowanie trwa długi czas, podczas gdy programowanie trwa krótszy okres, powodując gromadzenie się pracy w stanie programowania (wybrzuszenia wskazują, że udany krok ma problem, a niekoniecznie krok, w którym występuje wybrzuszenie).

Wybrzuszenia

Jak rozwiązać problemy z przepływem?

Problem z brakiem terminowych aktualizacji można rozwiązać za pomocą następujących elementów:

• Codzienne stand-upy.
• Inne regularne spotkania.
• Planowanie codziennego przypomnienia zespołu e-mail.

Systemowe problemy płaskie wskazują na trudniejszy problem, chociaż takie problemy są rzadkie. Płaskie linie wskazują, że praca w całym systemie została zatrzymana. Podstawowe przyczyny mogą być następujące:

• Blokady całego procesu.
• Procesy trwają długo.
• Praca przenosząc się na inne możliwości, które nie są przechwytywane na tablicy.

Jednym z przykładów systemowych płaskich linii może wystąpić z cechAMI CFD. Praca z funkcjami może trwać znacznie dłużej niż praca nad scenariuszami użytkownika, ponieważ funkcje składają się z kilku scenariuszy. W takich sytuacjach nachylenie jest oczekiwane (jak w powyższym przykładzie) lub problem jest dobrze znany i już zgłaszany przez zespół jako problem. Jeśli jest to znany problem, rozwiązanie problemu wykracza poza zakres tego artykułu.

Zespoły mogą aktywnie rozwiązywać problemy, które pojawiają się jako wybrzuszenia CFD. W zależności od tego, gdzie występuje wybrzuszenie, poprawka może być inna. Załóżmy na przykład, że wybrzuszenie występuje w procesie programowania. Może wystąpić wybrzuszenie, ponieważ uruchamianie testów trwa znacznie dłużej niż pisanie kodu. Testerzy mogą również znajdować dużą liczbę usterek. Gdy stale przechodzą pracę z powrotem do deweloperów, deweloperzy dziedziczą rosnącą listę aktywnych prac.

Dwa potencjalnie łatwe sposoby rozwiązania tego problemu to: 1) Przenieś deweloperów z procesu programowania do procesu testowania do momentu wyeliminowania wybrzuszenia lub 2) zmiany kolejności pracy, tak aby praca, którą można wykonać szybko, jest przeplatana z pracą, która trwa dłużej. Poszukaj prostych rozwiązań, aby wyeliminować wybrzuszenia.

Uwaga

Ponieważ wiele różnych scenariuszy może wystąpić, co powoduje nierównomierną pracę, bardzo ważne jest przeprowadzenie rzeczywistej analizy problemu. CFD powie ci, że występuje problem i w przybliżeniu tam, gdzie jest, ale musisz zbadać, aby uzyskać główne przyczyny. Przedstawione tutaj wskazówki wskazują zalecane działania, które rozwiązują konkretne problemy, ale które mogą nie mieć zastosowania do Twojej sytuacji.

Czy zakres uległ zmianie?

Zmiany zakresu dotyczą tylko kontraktów CFD z ustalonym okresem. Górna linia wykresu wskazuje zakres pracy. Przebieg jest wstępnie ładowany z pracą do wykonania w pierwszym dniu. Zmiany w górnym wierszu wskazują, że praca została dodana lub usunięta.

Jeden scenariusz, w którym nie można śledzić zmian zakresu za pomocą kontraktu CFD, gdy ta sama liczba elementów roboczych zostanie dodana co usunięta w tym samym dniu. Linia będzie nadal płaska. Porównaj kilka wykresów ze sobą. Monitoruj konkretne problemy. Użyj opcji Wyświetlanie/konfigurowanie postępu przebiegu, aby monitorować zmiany zakresu.

Za dużo funkcji WIP?

Możesz łatwo monitorować , czy limity funkcji WIP zostały przekroczone z tablicy Kanban. Można go również monitorować za pomocą CFD.

Duża ilość funkcji WIP zwykle jest wyświetlana jako pionowa wybrzuszenie. Tym dłużej, że istnieje duża ilość funkcji WIP, tym więcej wybrzuszenia będzie rozszerzać się, aby stać się owalnym. Jest to wskazanie, że funkcja WIP negatywnie wpływa na cykl i czas realizacji.

Oto dobra reguła kciuka dla prac w toku. W danym momencie nie powinno istnieć więcej niż dwa elementy na członka zespołu. Główną przyczyną dwóch elementów i bardziej rygorystycznych limitów jest to, że rzeczywistość często intruzuje się w każdym procesie tworzenia oprogramowania.

Czasami potrzeba czasu na uzyskanie informacji od uczestnika projektu lub uzyskanie niezbędnego oprogramowania zajmuje więcej czasu. Istnieje wiele powodów, dla których praca może zostać wstrzymana. Posiadanie drugiego elementu roboczego do przestawienia w celu zapewnia pewną swobodę działania. Jeśli oba elementy są zablokowane, nadszedł czas, aby podnieść czerwoną flagę, aby coś odblokować — nie tylko przełączyć się na kolejny element. Gdy tylko w toku jest duża liczba elementów, osoba pracująca nad tymi elementami będzie miała trudności z przełączaniem kontekstu. Jest bardziej prawdopodobne, że zapomną, co robią, a mogą wystąpić błędy.

Czas realizacji a czas cyklu

Na poniższym diagramie pokazano, jak czas realizacji różni się od czasu cyklu. Czas realizacji jest obliczany na podstawie tworzenia elementu roboczego do wprowadzania stanu Ukończono. Czas cyklu jest obliczany od pierwszego wprowadzenia kategorii Stanu w toku lub Rozwiązano, aby wprowadzić kategorię Ukończono stan.

Ilustracja przedstawiająca czas realizacji i czas cyklu

Jeśli element roboczy przejdzie w stan Ukończono, a następnie zostanie ponownie aktywowany, dodatkowy czas spędzony w stanie Proponowany, W toku lub Rozwiązany przyczyni się do czasu realizacji/cyklu po wprowadzeniu kategorii Ukończono po raz drugi.

Jeśli twój zespół korzysta z tablicy Kanban, warto zrozumieć, jak kolumny Kanban są mapowania na stany przepływu pracy. Aby uzyskać więcej informacji na temat konfigurowania tablicy Kanban, zobacz Dodawanie kolumn.

Aby dowiedzieć się więcej o sposobie korzystania z kategorii stanów — proponowanych, w toku, rozwiązanych i ukończonych — zobacz Stany i kategorie stanów przepływu pracy.

Planowanie przy użyciu szacowanych czasów dostarczania na podstawie czasów realizacji/cyklu

Aby oszacować czas dostawy, możesz użyć średniego czasu cyklu/cyklu i odchyleń standardowych.

Podczas tworzenia elementu roboczego możesz użyć średniego czasu realizacji zespołu, aby oszacować, kiedy zespół ukończy ten element roboczy. Odchylenie standardowe twojego zespołu informuje o zmienności oszacowania. Podobnie można użyć czasu cyklu i jego odchylenia standardowego, aby oszacować zakończenie elementu roboczego po rozpoczęciu pracy.

Na poniższym wykresie średni czas cyklu wynosi osiem dni. Odchylenie standardowe wynosi +/- sześć dni. Korzystając z tych danych, możemy oszacować, że zespół ukończy przyszłe historie użytkowników o 2–14 dni po rozpoczęciu pracy. Węższe odchylenie standardowe, tym bardziej przewidywalne oszacowania.

Przykładowy widżet czasu cyklu

Identyfikowanie problemów z procesem

Przejrzyj wykres kontrolny zespołu pod kątem wartości odstających. Wartości odstające często reprezentują podstawowy problem z procesem. Na przykład oczekiwanie zbyt długo na ukończenie przeglądów żądania ściągnięcia lub szybkie rozwiązywanie zależności zewnętrznej.

Jak widać na poniższym wykresie, który pokazuje kilka wartości odstających, kilka usterek trwało dłużej niż średnia zespołu. Badanie, dlaczego te błędy trwały dłużej, mogą pomóc w odkryciu problemów z procesem. Rozwiązywanie problemów z procesem może pomóc zmniejszyć odchylenie standardowe zespołu i poprawić przewidywalność twojego zespołu.

Przykładowy widżet czasu cyklu przedstawiający kilka wartości odstających

Możesz również zobaczyć, jak zmiany procesu wpływają na czas prowadzenia i cyklu. Na przykład 15 maja zespół podjął wspólne wysiłki w celu ograniczenia funkcji WIP i rozwiązania nieaktualnych usterek. Widać, że odchylenie standardowe zawęża się po tej dacie, pokazując lepszą przewidywalność.

Następne kroki

Konfigurowanie skumulowanych wykresów blokowych lub Konfigurowanie wykresu czasu realizacji lub cyklu