累計流程、前置時間和週期時間指引

發行項
04/04/2024

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

您可以使用累積流程圖（CF）來監視透過系統的工作流程。您可以從圖表擷取要追蹤的兩個主要計量、週期時間和前置時間。若要設定或檢視CFD圖表，請參閱設定累計流程圖。

或者，您可以將潛在客戶時間和週期時間控制圖表新增至儀錶板。

範例圖表和主要計量

連續流程CFM提供遵循精簡程式的小組最青睞的圖表。

不過，許多小組已開始將精簡實務與 Scrum 或其他方法相結合，這表示他們在反覆專案或短期衝刺的範圍內練習精簡。在此情況下，圖表的外觀稍有不同，並提供兩個額外且非常有價值的資訊片段，如下一張圖表所示。

連續流程
CF計量的概念影像。

此處顯示的固定期間為已完成短期衝刺。

頂端線代表短期衝刺的範圍集。而且，由於工作必須在短期衝刺的最後一天完成，封閉狀態的斜率會指出小組是否正軌完成短期衝刺。將此檢視視為燒毀圖表最簡單的方式。

數據一律會以進程中的第一個步驟描述為左上方，而進程中的最後一個步驟則描述為右下角。

已完成短期衝刺的固定期間
CF計量，固定期間。

圖表計量

依狀態/工作流程看板數據行分組的工時圖表顯示一段時間的計數。您可以從圖表擷取要追蹤的兩個主要計量、週期時間和前置時間。

計量

[定義]

週期時間¹

測量透過單一進程或工作流程狀態移動工作所需的時間。計算是從一個進程的開頭到下一個進程的開始。

潛在客戶時間¹

針對連續流程程式：測量要求提出時所花費的時間量（例如新增建議的用戶劇本），直到該要求完成（已關閉）。

針對短期衝刺或固定期間程序：測量要求的工作開始到工作完成的時間（也就是從作用中到關閉的時間）。

進行中工作

測量正在積極處理的工作項目數量或工時數。

範圍

表示指定期間所認可的工時量。僅適用於固定期間進程。

小工具（分析）和內建的CFC圖表（工作追蹤數據存放區）不會在潛在客戶時間和周期時間上提供離散數位。不過，前置時間和週期時間小工具會提供這些數位。

潛在客戶時間/週期時間與進行中工作之間有妥善定義的相互關聯性（WIP）。 WIP 越長，週期時間越長，也會導致較長的前置時間。相反的是，WIP 越少，週期越短，前置時間就越短。當開發小組專注於較少的專案時，它們會減少週期和潛在客戶時間。此相互關聯是您在工作流程看板上設定 [進行中工作] 限制的主要原因。

工作專案的計數表示指定一天的工作總數。在固定期間，此計數的變更表示指定期間的範圍變更。在連續流程中，它表示佇列中的工作總數，並已完成一天。

將工作分解成特定的工作流程看板數據行，提供工作正在進行中的檢視。此檢視提供工作順利移動、發生封鎖和完全沒有工作之處的深入解析。不過，可視化的CFD圖表很難解密數據的表格式檢視，但提供證據表明某個方式發生什麼事。

識別問題，採取適當的動作

CF回答數個特定問題，並根據答案採取動作來調整程式，以移動工作通過系統。讓我們來看看這裡的每個問題。

小組是否會按時完成工作？

此問題僅適用於固定期間 CFD。您可以藉由查看工作流程看板最後一欄的工作曲線（或進展）來取得瞭解。

具有半已完成圖表的範例CFC，虛線顯示工作將不會完成

在此案例中，如果工作速度很穩定，可能就適合減少反覆專案中的工作範圍，但速度不夠快。這可能表明工作被低估了，應該納入下一個短期衝刺計劃。

不過，在圖表上查看其他數據，可能會有其他原因可以決定。

工作流程如何進行？

小組是否以穩定的速度完成工作？其中一個判斷方法是查看圖表上不同數據行之間的間距。它們是否與彼此有相似或統一的距離，從頭到尾？一個數據行在一段多天的時間里是否顯示為平面線？或者，似乎「膨脹」了嗎？

穆拉，扁平線和浮凸的精簡詞彙，意味著不均衡，並表示系統中的一種廢物（Muda）。系統中的任何不均度都會造成凸起出現在CFC中。

監視平面線條和凸起的CFD支援限制專案管理程序理論的關鍵部分。保護系統最慢的區域稱為鼓緩沖繩過程，是規劃工作的一部分。

兩個問題以可視化方式顯示為平面線條和凸起。

當小組不定期更新其工作時，就會顯示一般線條。工作流程看板提供將工作從一個數據行轉換成另一個數據行的最快速方式。
當跨一或多個程式的工作花費的時間比計劃長時，也可以顯示平面線。平面線會出現在系統的許多部分，因為如果系統只有一個部分或兩個部分有問題，您就會看到凸起。

平面線條
CF計量，平面線。

當工作建置在系統的一個部分中，且不會經過程式時，就會發生凸起。
例如，當測試需要很長的時間，而開發需要較短的時間，導致工作累積在開發狀態時可能會發生（凸起表示成功步驟發生問題，不一定是發生膨脹的步驟）。

凸起
CF 計量，凸起。

如何修正流程問題？

您可以透過下列方式解決缺乏及時更新的問題：

每日站立。
其他定期會議。
排程每日小組提醒電子郵件。

系統性平面問題表明一個更具挑戰性的問題，雖然這些問題很少見。平面線表示整個系統的工作已停止。根本原因可以是：

全進程封鎖。
進程需要很長的時間。
工作轉移到未擷取到面板上的其他商機。

有一個系統式平面線的範例，可能會有一個特徵為CFD。功能工作可能需要比用戶劇本工作更長的時間，因為功能是由數個故事所組成。在這些情況下，可能是預期斜率（如上述範例所示），或問題已由小組提出作為問題。如果這是已知問題，問題解決範圍超出本文的範圍。

Teams 可以主動修正顯示為「加價」的問題。視發生膨脹的位置而定，修正程式可能不同。例如，假設在開發程式中發生膨脹。可能會發生此膨脹，因為執行測試所花費的時間比撰寫程式代碼還要長。測試人員可能也會發現大量的 Bug。當他們持續將工作轉換回開發人員時，開發人員會繼承日益增多的作用中工作清單。

解決此問題的兩個可能容易的方法如下：1）將開發人員從開發程式轉移到測試程式，直到消除或 2）變更工作順序，讓可快速完成的工作與需要較長時間的工作交織在一起。尋找簡單的解決方案來消除凸起。

注意

因為可能會發生許多不同的案例，導致工作不平均地繼續，因此您必須執行問題的實際分析。 CF會告訴您，有問題，大約在哪裡，但您必須調查，以找出根本原因。此處提供的指引指出建議的動作，可解決特定問題，但可能不適用於您的情況。

範圍變更了嗎？

範圍變更僅適用於固定期間 CFD。圖表的頂端線表示工作範圍。短期衝刺會預先載入第一天要執行的工作。頂端線的變更表示已新增或移除工作。

當相同數量的工作專案新增為同一天移除時，就會發生一個案例，其中您無法追蹤使用CFC的範圍變更。線條會繼續是平面的。比較數個圖表與彼此。監視特定問題。使用檢視/設定短期衝刺燒毀來監視範圍變更。

WIP 太多了？

您可以輕鬆地監視 WIP 限制是否已超過工作流程看板面板。您也可以從CFC監視它。

大量的 WIP 通常會顯示為垂直膨脹。有大量的 WIP 越長，膨脹就越大，成為橢圓形。這表示 WIP 對週期和前置時間有負面影響。

以下是進行中工作的良好經驗法則。每個小組成員在任何指定時間應該不超過兩個項目進行中。兩個專案與更嚴格的限制的主要原因，是因為現實經常侵入任何軟體開發程式。

有時需要時間才能從項目關係人取得資訊，或需要更多時間來取得必要的軟體。工作可能停止的原因有很多。有第二個工作項目可樞紐以提供一些餘地。如果這兩個專案都遭到封鎖，是時候引發紅色旗標來解除封鎖，而不只是切換到另一個專案。一旦有大量的項目進行中，處理這些項目的人員將很難切換內容。他們更有可能忘記他們在做什麼，錯誤可能發生。

前置時間與周期時間

下圖說明前置時間與週期時間有何不同。前置時間是從工作專案建立到進入已完成狀態計算。週期時間是從第一次輸入 [進行中] 或 [已解析] 狀態類別到輸入已完成狀態類別所計算。

前置時間與週期時間的圖例

測量週期時間和前置時間的概念影像

如果工作專案進入已完成狀態，然後重新啟用，則第二次進入已完成狀態類別時，任何花費在 [建議]、[進行中] 或 [已解決] 狀態的任何額外時間，都會造成其前置/周期時間。

如果您的小組使用工作流程看板面板，您會想要瞭解工作流程看板數據行如何對應至工作流程狀態。如需設定工作流程看板的詳細資訊，請參閱新增數據行。

若要深入了解系統如何使用狀態類別—建議、進行中、已解決和已完成—請參閱工作流程狀態和狀態類別。

根據潛在客戶/週期時間規劃使用預估傳遞時間

您可以使用平均潛在客戶/週期時間和標準偏差來估計傳遞時間。

當您建立工作專案時，您可以使用小組的平均潛在客戶時間來預估小組何時完成該工作專案。小組的標準偏差會告訴您估計值的變異性。同樣地，您可以使用週期時間和其標準偏差來估計工作專案完成一旦工作開始。

在下圖中，平均週期時間是八天。標準偏差為 +/- 六天。我們可以使用這項數據，估計小組將在工作開始 2-14 天后完成未來的用戶劇本。標準偏差越窄，估計值越可預測。

識別進程問題

檢閱小組的極端值控制圖表。極端值通常代表基礎進程問題。例如，等候太久而無法快速完成PR檢閱或無法解決外部相依性。

如下列圖表所示，其中顯示數個極端值，數個 Bug 花費的時間比小組的平均值還要長。調查這些錯誤花費的時間較長的原因，可能有助於發現程序問題。解決程式問題有助於降低小組的標準偏差，並改善小組的可預測性。

您也可以查看程式變更如何影響潛在客戶和週期時間。例如，在 5 月 15 日，小組一致努力限制 WIP 並解決過時的錯誤。您可以看到標準偏差在該日期之後縮小，顯示改善的可預測性。

下一步

設定累計流程圖或設定潛在客戶時間或週期時程圖表