Udostępnij za pomocą

Wskazówki dotyczące przepływu skumulowanego dla czasu realizacji i czasu cyklu

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Diagramy przepływu skumulowanego (CFD) ułatwiają monitorowanie procesu pracy przez wizualizowanie przepływu pracy przez system. W tym artykule wyjaśniono, jak używać CFD, czasów cyklu i czasów realizacji w celu identyfikowania problemów i poprawy wydajności przepływu pracy.

CFD o ciągłym przepływie jest wykresem, który preferuje większość zespołów podążających za procesem lean management.

Wiele zespołów łączy praktyki lean ze Scrumem lub innymi metodami. Używają praktyk lean podczas iteracji lub sprintu. W tym przypadku diagram wygląda nieco inaczej. Pokazuje dwa dodatkowe elementy, że wykres CFD o ciągłym przepływie jest preferowany przez większość zespołów stosujących proces lean.

Wiele zespołów łączy praktyki lean ze Scrumem lub innymi metodami. Używają praktyk lean podczas iteracji lub sprintu. W tym przypadku diagram wygląda nieco inaczej. Pokazuje on dwie dodatkowe, cenne informacje, jak pokazano na następnym wykresie, stałe CFD. CFD z przepływem ciągłym
Wykres przedstawiający abstrakcyjny przepływ ciągły CFD. Etykiety wskazują czas realizacji, czas cyklu, pracę w toku i elementy w różnych stanach.

Ten okresowy CFD pokazuje ukończony sprint.

Górny wiersz przedstawia zakres ustawiony dla sprintu. Ponieważ praca musi zakończyć się do ostatniego dnia, nachylenie w stanie Zamknięte pokazuje, czy zespół jest na dobrej drodze. Ten widok można traktować jako wykres wzrostu spalania.

Na wykresie pierwszy krok procesu znajduje się w lewym górnym obszarze. Ostatni krok jest w prawym dolnym rogu.

CFD o stałym okresie dla ukończonego sprintu
Wykres przedstawiający abstrakcyjny kontrakt CFD z ustalonym okresem. Etykiety wskazują aktywne, rozwiązane i zamknięte elementy oraz zmianę zakresu.

Metryki wykresu

CfDs pokazują liczbę elementów roboczych pogrupowanych według stanu lub kolumny w czasie. Dwie podstawowe metryki do śledzenia to czas cyklu i czas realizacji. Wyodrębnisz te metryki z wykresu.

Metr

Definicja

Czas cyklu1

Czas potrzebny na przejście pracy przez pojedynczy proces lub stan przepływu pracy. Zmierz długość od początku jednego procesu do początku następnego procesu.

Czas realizacji1

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

W przypadku sprintu lub fi Dla procesu ciągłego przepływu: czas od złożenia żądania (na przykład dodanie proponowanej historyjki użytkownika) do momentu jego ukończenia (zamknięcia).

Dla procesu typu sprint lub o stałym okresie: czas od momentu rozpoczęcia pracy nad zgłoszeniem do czasu ukończenia pracy (na przykład od stanu Aktywny do stanu Zamknięty).

Praca w toku (WIP)

Ilość pracy lub liczby elementów roboczych, które są aktywnie w toku.

Zakres

Ilość pracy zaangażowanej w danym okresie. Ta metryka ma zastosowanie tylko do procesów o stałym okresie.

1 Widżet CFD, który używa danych analitycznych, oraz wbudowane CFD, które można wyświetlić z listy prac zespołu lub tablicy, nie zapewniają dyskretnych wartości czasu realizacji i czasu cyklu. Jednak widżety Czas realizacji i Czas cyklu zawierają te wartości.

Istnieje wyraźna korelacja między czasem realizacji lub czasem cyklu a funkcją WIP. Więcej funkcji WIP prowadzi do dłuższych czasów cyklu i dłuższych czasów realizacji. Przeciwieństwo jest również prawdziwe — mniej WIP prowadzi do krótszych cykli i czasów realizacji. Gdy zespół programistyczny koncentruje się na mniejszej liczbie elementów, skraca cykl i czasy realizacji. Ta korelacja jest kluczowym powodem ustawiania limitów funkcji WIP na tablicy używanej do śledzenia pracy i zarządzania nią.

Liczba elementów roboczych pokazuje łączną ilość pracy w danym dniu. W stałym okresie CFD zmiana w tej liczbie oznacza zmianę zakresu dla tego okresu. W przepływie ciągłym CFD pokazuje łączną ilość pracy, która znajduje się w kolejce i została ukończona przez dany dzień.

Kategoryzowanie pracy w określonych kolumnach tablicy pokazuje ilość pracy w każdym obszarze procesu. Ten widok zapewnia wgląd w to, gdzie praca przebiega płynnie, gdzie występują blokady oraz gdzie praca nie jest wykonywana. Trudno zrozumieć tabelaryczny widok danych, ale wizualizacja CFD pomaga zobaczyć, co dzieje się w procesie pracy i dlaczego.

Identyfikowanie problemów i wykonywanie odpowiednich działań

CFD zawiera odpowiedzi na następujące pytania. Na podstawie odpowiedzi możesz dostosować proces, aby praca przepływała przez system.

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

To pytanie dotyczy tylko kontraktów CFD z ustalonym okresem. Zrozumienie można uzyskać, patrząc na krzywą (lub progresję) pracy w ostatniej kolumnie tablicy.

Wykres przedstawiający półukończone CFD. Przewidywana krzywa ukończonych elementów znajduje się poniżej poziomu zakresu na końcu przebiegu.

W tym scenariuszu można rozważyć zmniejszenie zakresu pracy w iteracji. Ta akcja jest odpowiednia, jeśli jest jasne, że praca nie jest wykonywana wystarczająco szybko, zakładając, że będzie kontynuowana w stałym tempie. Ten scenariusz może sugerować, że praca została niedoszacowana i powinna zostać uwzględniona w planowaniu następnego sprintu.

Jednak mogą istnieć inne przyczyny, dla których praca nie jest wykonywana wystarczająco szybko. Możesz określić te przyczyny, przeglądając 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, aby to ustalić, jest przyjrzenie się odstępom między różnymi kolumnami na wykresie. Czy są w podobnej lub jednakowej odległości od siebie od początku do końca? Czy kolumny wydają się utrzymywać na stałym poziomie przez okres kilku dni? Czy któryś z nich wydaje się wybrzuszony?

Mura, czyli nierówność, jest chudym terminem dla płaskich linii i wybrzuszeń. Mura wskazuje formę odpadów (Muda) w systemie. Każda nierówność w systemie powoduje, że wybrzuszenia pojawiają się w CFD.

Monitorowanie CFD pod kątem płaskich linii i wybrzuszeń wspiera kluczową część procesu zarządzania projektami Teorii Ograniczeń. Proces ochrony najwolniejszego obszaru systemu nazywa się bęben-bufor-lina i stanowi część planowania pracy.

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

Płaskie linie pojawiają się, gdy zespół nie aktualizuje regularnie statusu swoich elementów roboczych. Tablica używana do śledzenia pracy i zarządzania nią 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. Linie płaskie pojawiają się w wielu częściach systemu, dlatego że jeśli tylko jedna lub dwie części mają problemy, widoczne jest wybrzuszenie.

Płaskie linie
Wykres abstrakcyjnego CFD. Linie dla liczby aktywnych, rozwiązanych i zamkniętych elementów są płaskie przez znaczny okres czasu.

Wybrzuszenia występują, gdy praca gromadzi się w jednej części systemu i nie jest przetwarzana.
Na przykład wybrzuszenie może wystąpić, gdy testowanie trwa długo, ale rozwój zajmuje mniej czasu. Wynikiem jest, że praca gromadzi się na etapie rozwoju. Wybrzuszenia wskazują, że następny krok ma problem, a niekoniecznie krok, w którym występuje wybrzuszenie.

Wybrzuszenia
Wykres abstrakcyjnego CFD. Obszar aktywnych elementów wybrzusza się w kierunku prawego dolnego rogu wykresu.

Jak rozwiązać problemy z przepływem?

Problem z brakiem terminowych aktualizacji można rozwiązać, wykonując następujące czynności:

  • Prowadzenie codziennych spotkań
  • Organizowanie innych regularnych spotkań
  • Codzienne zaplanowanie wiadomości e-mail z przypomnieniem dla zespołu

Problemy systemowe o charakterze stagnacji wskazują na trudniejsze wyzwanie, chociaż takie problemy są rzadkie. Płaskie linie wskazują, że praca w systemie jest zatrzymana. Podstawowe przyczyny mogą obejmować następujące problemy:

  • Blokady całego procesu
  • Procesy trwają długo
  • Praca przesuwa się w kierunku innych możliwości, które nie są ujęte na tablicy.

Jeden z przykładów stagnacji systemowej może wystąpić w funkcjach CFD. Praca z funkcjami może trwać dłużej niż praca nad scenariuszami użytkownika, ponieważ funkcje składają się z kilku scenariuszy. W takich sytuacjach nachylenie jest oczekiwane (jak we wcześniejszym przykładzie) lub problem jest dobrze znany, a zespół już go zgłosił. Jeśli jest to znany problem, rozwiązanie problemu wykracza poza zakres tego artykułu.

Zespoły mogą proaktywnie rozwiązywać problemy, które pojawiają się w formie wybrzuszeń CFD. Odpowiednia poprawka może zależeć od miejsca, w którym występuje wybrzuszenie. Załóżmy na przykład, że wybrzuszenie występuje w procesie rozwoju. Możliwe, że wybrzuszenie występuje, ponieważ testowanie trwa dłużej niż pisanie kodu. Testerzy mogą również znajdować dużą liczbę usterek. Gdy stale przydzielają pracę z powrotem do deweloperów, deweloperzy dziedziczą rosnącą listę aktywnych zadań.

Istnieją dwa potencjalnie łatwe sposoby rozwiązania tego problemu:

  • Przenieś deweloperów z procesu programowania do procesu testowania aż do wyeliminowania przeciążenia.
  • Zmień kolejność pracy. W szczególności przeplatają pracę, którą można wykonać szybko z pracą, która trwa dłużej.

Poszukaj podstawowych rozwiązań, aby wyeliminować wybrzuszenia.

Uwaga

Ponieważ mogą wystąpić różne scenariusze, które powodują nierównomierną pracę, bardzo ważne jest przeprowadzenie rzeczywistej analizy problemu. CFD może powiedzieć, że problem istnieje. Może również powiedzieć, gdzie występuje problem, ale należy zbadać, aby uzyskać główne przyczyny. Te wskazówki zawierają zalecane akcje, które rozwiązują konkretne problemy, ale rozwiązania mogą nie dotyczyć Twojej sytuacji.

Czy zakres uległ zmianie?

Zmiany zakresu mają zastosowanie tylko do kontraktów CFD z ustalonym okresem. Górna linia wykresu wskazuje zakres pracy. Sprint jest wypełniony pracą na pierwszy dzień. Zmiany w wierszu nagłówka wskazują dodanie lub usunięcie zadań.

W jednym konkretnym scenariuszu nie można śledzić zmian zakresu za pomocą CFD. Ten scenariusz występuje, gdy ta sama liczba elementów roboczych jest dodawana i usuwana w tym samym dniu. Linia pozostaje płaska w tym przypadku.

Aby śledzić zmiany zakresu w tym przypadku, wykonaj następujące czynności:

  • Porównaj kilka wykresów ze sobą.
  • Monitorowanie określonych problemów.
  • Użyj postępu przebiegu , aby monitorować zmiany zakresu.

Czy jest za dużo funkcji WIP?

Możesz łatwo monitorować tablicę, aby określić, czy przekroczono limity WIP. Możesz również monitorować poziomy WIP przy użyciu CFD.

Duża ilość WIP zwykle jest wyświetlana jako pionowe wybrzuszenie. Im dłużej jest duża ilość WIP, tym bardziej wybrzuszenie przybiera kształt owalu. To zachowanie wskazuje, że funkcja WIP negatywnie wpływa na cykl i czas realizacji.

Oto dobra zasada dotycząca WIP: W danym momencie nie powinno być więcej niż dwóch zadań w toku dla każdego członka zespołu. Głównym powodem używania limitu dwóch elementów, a nie bardziej rygorystycznego limitu, jest to, że rzeczywistość często intruzuje proces tworzenia oprogramowania.

Czasami potrzeba czasu, aby uzyskać informacje od uczestnika projektu lub uzyskać niezbędne oprogramowanie. Istnieje wiele powodów, dla których można wstrzymać pracę. Utrzymywanie drugiego elementu roboczego zapewnia elastyczność operacyjną podczas nieoczekiwanych opóźnień. 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, pracujący nad nimi może mieć trudności z przełączaniem kontekstu. Prawdopodobnie zapominają, co robią, co mogą prowadzić do błędów.

Czas realizacji a czas cyklu

Na poniższym diagramie pokazano, jak różni się czas realizacji i czas cyklu. Czas realizacji rozpoczyna się po utworzeniu elementu roboczego i kończy się po wejściu elementu roboczego do kategorii Stan ukończony. Czas cyklu rozpoczyna się, gdy element roboczy wchodzi w kategorię stanu W toku lub Rozwiązany i kończy się, gdy wchodzi w kategorię stanu Ukończony.

Diagram przedstawiający sposób użycia kategorii stanów do mierzenia czasu cyklu i czasu realizacji.

Jeśli twój zespół używa tablicy do śledzenia pracy i zarządzania nią, zrozumienie sposobu mapowania kolumn na stany przepływu pracy pomaga efektywniej zarządzać pracą. Aby dowiedzieć się, jak skonfigurować tablicę, zobacz Zarządzanie kolumnami na tablicy.

Aby dowiedzieć się, jak system używa kategorii stanów — Proponowane, W toku, Rozwiązane i Ukończone — zobacz Informacje o stanach przepływu pracy na listach prac i tablicach.

Jak czas cyklu obsługuje ponownie uaktywnione elementy robocze

W przypadku elementów roboczych, które są ponownie aktywowane (przeniesione ze stanu Ukończono z powrotem do stanu W toku), czas cyklu rozpoczyna się od pierwszego momentu, gdy element roboczy wchodzi w kategorię stanu W toku lub Rozpoznano i kończy za ostatnim razem, gdy przechodzi do kategorii Ukończony. Czas cyklu obejmuje cały aktywny okres pracy, w tym czas po ponownym uaktywnieniu.

Przykładowy scenariusz:

  • Nowa → aktywna → rozwiązana → zamknięta → nowa → aktywna → zamknięta
  • Obliczanie czasu cyklu: Od pierwszego przejścia do Aktywne do ostatniego przejścia na Zamknięte
  • Całkowity czas cyklu: Obejmuje zarówno aktywne okresy pracy, jak i czas w stanie Zamknięty przed ponowną aktywacją

Ta metoda obliczania przedstawia pełny obraz całkowitego czasu potrzebnego do ukończenia elementu roboczego, w tym wszelkich ponownych prac lub dodatkowych wysiłków po ponownym uaktywnieniu. Obliczenie czasu realizacji jest zgodne z tą samą zasadą — obejmuje cały okres od utworzenia elementu roboczego do końcowego ukończenia, niezależnie od wszystkich stanów ukończonych pośrednich.

Szacowanie czasów dostawy na podstawie terminów realizacji i cykli produkcji

Użyj średniego czasu realizacji zamówienia i cyklu oraz odchyleń standardowych, aby oszacować czasy realizacji.

Podczas tworzenia elementu roboczego użyj średniego czasu realizacji zespołu, aby oszacować datę ukończenia. Odchylenie standardowe zespołu pokazuje zmienność oszacowania. Podobnie użyj czasu cyklu i odchylenia standardowego, aby oszacować, kiedy element roboczy zakończy się po rozpoczęciu pracy.

Przykładowy widżet czasu cyklu

Na poniższym wykresie średni czas cyklu wynosi osiem dni, a odchylenie standardowe wynosi sześć dni. Dzięki tym danym szacuj, że zespół ukończy przyszłe historie użytkowników o około 2 do 14 dni po rozpoczęciu pracy. Węższe odchylenie standardowe sprawia, że oszacowania są bardziej przewidywalne.

Zrzut ekranu przedstawiający widżet Czas cyklu. Wykres punktowy przedstawia kropki dla elementów roboczych, linię średniej ruchomej i przedział odchylenia standardowego.

Identyfikowanie problemów z procesem

Wartości odstające często oznaczają, że występuje podstawowy problem z procesem. Na przykład zbyt długie oczekiwanie na przejrzenie żądań ściągnięcia lub powolne naprawianie zależności zewnętrznej. Sprawdź wykres kontrolny swojego zespołu pod kątem wartości odstających.

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

Na poniższym wykresie przedstawiono kilka wartości odstających, ponieważ rozwiązanie niektórych błędów zajęło więcej czasu niż przeciętnie. Sprawdzanie, dlaczego te usterki trwały dłużej, mogą pomóc w znalezieniu problemów z procesem. Rozwiązywanie problemów z procesem pomaga zmniejszyć odchylenie standardowe zespołu i poprawić przewidywalność twojego zespołu.

Zrzut ekranu przedstawiający widżet czasu trwania cyklu. Niektóre punkty odpowiadające elementom roboczym znajdują się znacznie powyżej linii średniej ruchomej oraz przedziału odchylenia standardowego.

Zobaczysz również, jak zmiany procesu wpływają na czasy realizacji i czasy cyklu. Na przykład 15 maja zespół pracował nad ograniczeniem WIP i naprawieniem zaległych błędów. Odchylenie standardowe zawęża się po tej dacie, pokazując lepszą przewidywalność.

Następne kroki

Wyświetlanie i konfigurowanie diagramu przepływu skumulowanego

Widżety Czas realizacji i Czas cyklu

  • Last updated on