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 realizacji i czasu cyklu.

Przykładowe wykresy i podstawowe metryki

CFD przepływu ciągłego zapewnia wykres najbardziej faworyzowany przez zespoły stosujące proces lean.

Jednak wiele zespołów zaczęło łączyć praktyki lean ze Scrum lub innymi metodologiami, co oznacza, że praktykują w ramach iteracji lub sprintu. 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 kontraktu CFD pokazany tutaj jest dla ukończonej iteracji.

Górna linia reprezentuje zakres ustawiony dla sprintu. Ponieważ praca musi zostać ukończona przed ostatnim dniem sprintu, nachylenie stanu zamkniętego wskazuje, czy zespół jest na dobrej drodze do ukończenia sprintu. Najprościej można myśleć o tym widoku jako o wykresie burnup.

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

Okres stały CFD dla ukończonego sprintu

Metryki wykresu

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

---

Metr

Definicja

---

Czas cyklu¹

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 zlecenia¹

Dla procesu przepływu ciągłego: Mierzy ilość czasu od momentu złożenia żądania (na przykład dodanie proponowanej historii użytkownika) do momentu zakończenia tego żądania (zamknięcia).

Dla procesu "sprint" lub procesu stałego okresu: Mierzy czas od momentu rozpoczęcia pracy nad zgłoszeniem do momentu zakończenia pracy (tj. czas od Aktywne do Zamknięte).

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 (Analizy) i wbudowany wykres CFD (magazyn danych śledzenia pracy) nie zapewniają dyskretnych liczb dotyczących czasu realizacji i czasu cyklu. Jednak widżety Czas cyklu i Czas realizacji zawierają te liczby.

Istnieje dobrze zdefiniowana korelacja między czasem/czasem cyklu realizacji i pracą w toku (WIP). Im więcej 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 i należy ustawić limity pracy w toku na tablicy.

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

Podział pracy na konkretne kolumny tablicy pozwala na podgląd postępu prac. 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 progresję) pracy w ostatniej kolumnie tablicy.

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 planowaniu kolejnych sprintó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 ustalenia tego jest przyjrzenie się odległościom 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 kolumna wydaje się pozostawać na stałym poziomie przez kilka 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 CFD pod kątem płaskich linii i wybrzuszeń wspiera kluczową część procesu zarządzania projektami Teorii Ograniczeń. Ochrona najwolniejszego obszaru systemu jest nazywana procesem drum-buffer-rope i stanowi część planowania produkcji.

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 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 się kumuluje w jednej części systemu i nie przesuwa się przez proces.
Na przykład wybrzuszenie może wystąpić, gdy testowanie trwa długi czas, podczas gdy rozwój trwa krótszy okres, powodując gromadzenie się pracy w stanie rozwoju (wybrzuszenia wskazują, że następny krok ma problem, a niekoniecznie ten, 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 e-mailowego dla zespołu.

Problemy systemowe o charakterze stagnacji wskazują na trudniejsze wyzwanie, 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 przenosi się na inne możliwości, które nie są widoczne na tablicy.

Jednym z przykładów systemowej stagnacji 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ą proaktywnie rozwiązywać problemy, które pojawiają się w formie wybrzuszeń 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 rozwoju. 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 przydzielają pracę z powrotem do deweloperów, deweloperzy dziedziczą rosnącą listę aktywnych zadań.

Dwa potencjalnie łatwe sposoby rozwiązania tego problemu to: 1) Przenieś deweloperów z procesu programowania do procesu testowania aż do wyeliminowania zatoru lub 2) zmień kolejność pracy, tak aby praca, którą można wykonać szybko, była przeplatana z pracą, nad którą trzeba dłużej pracować. 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 poinformuje cię, że występuje problem i wskaże jego przybliżoną lokalizację, ale musisz sam zbadać, aby dotrzeć do przyczyny źródłowej. 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. Sprint jest przygotowany 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ą wykresu skumulowanych przepływów, występuje wtedy, gdy tego samego dnia dodana i usunięta zostaje taka sama liczba elementów roboczych. 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 WIP zostały przekroczone na tablicy. Można go również monitorować za pomocą CFD.

Duża ilość WIP zwykle jest wyświetlana jako pionowe 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 sygnał, że WIP negatywnie wpływa na cykl i czas realizacji.

Oto dobra praktyczna zasada dla prac w toku. W danym momencie nie powinno być w toku więcej niż dwa zadania przypadające na członka zespołu. Głównym powodem wyboru dwóch elementów zamiast bardziej rygorystycznych limitów jest to, że rzeczywistość często wkracza w każdy proces 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 którego można się przestawić, daje 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. Kiedy tylko w toku jest duża liczba zadań, osoba pracująca nad tymi zadaniami będzie miała trudności ze zmianą 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 od utworzenia elementu roboczego do osiągnięcia stanu Ukończono. Czas cyklu jest obliczany od momentu pierwszego przejścia do stanu W toku lub Rozwiązano do przejścia do stanu Ukończono.

Ilustracja przedstawiająca czas realizacji i czas cyklu

Jeśli element roboczy przejdzie do stanu Ukończono, a następnie zostanie ponownie aktywowany, to dodatkowy czas spędzony w stanie Proponowany, W toku lub Rozwiązany będzie się liczyć do czasu prowadzenia/cyklu, gdy ponownie znajdzie się w kategorii stanu Ukończono.

Jeśli twój zespół korzysta z tablicy, powinieneś zrozumieć, jak kolumny są mapowane do stanów przepływu pracy. Aby uzyskać więcej informacji na temat konfigurowania tablicy, zobacz Dodawanie kolumn.

Aby uzyskać więcej informacji na temat sposobu, w jaki system korzysta z kategorii stanów — proponowanych, w toku, rozwiązanych i ukończonych — zobacz Kategorie stanów i stanu przepływu pracy.

Planowanie przy użyciu szacowanych czasów dostarczenia na podstawie czasów realizacji oraz cyklu.

Aby oszacować czas dostawy, możesz użyć średnich czasów realizacji i czasów cyklu oraz 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. Im węższe odchylenie standardowe, tym bardziej przewidywalne są twoje 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ą problem leżący u podstaw procesu. Na przykład czekanie zbyt długo na ukończenie przeglądów żądań ściągnięcia lub brak szybkiego rozwiązania zależności zewnętrznej.

Jak widać na poniższym wykresie, który pokazuje kilka wartości odstających, rozwiązanie kilku błędów zajęło więcej czasu 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

Skonfiguruj skumulowane wykresy przepływu lub Skonfiguruj wykres czasu realizacji lub czasu cyklu