敏捷能力計算－第 1 部分（共 2 部分）

容量 敏捷 團隊績效是一項重要的衡量標準，應該用它來告知團隊在工作期間應該承擔多少工作。 衝刺計劃會議 針對即將到來的迭代週期，如果產能和工作量不平衡，團隊成員應該與產品負責人進行充分溝通，並探討如何實現平衡。

我將介紹三種容量計算方法：

• 方法1： 無需估算或計算容量。這是一種理想化的簡化方法。
• 方法2： 團隊容量（以小時為單位）的估算僅需少量參數。這是一種快速但近似的方法，可用來估算敏捷團隊在一個迭代周期內的產能。
• 方法3： 團隊產能（以小時為單位）的精確計算採用一套相當全面、可擴展且可自訂的參數集。這是一種計算敏捷團隊衝刺產能的準確方法。實際計算使用 Excel 範本即可快速完成。

在本系列部落格文章的第一部分中，我將介紹方法 1 和方法 2。我將在第二部分介紹方法 3。 部分2在第二部分結尾，我將根據您敏捷團隊的具體情況，就您可以選擇哪種方法提出建議。

方法一：無需估算或計算容量。

讓我們考慮一個最簡單（也有些理想化）的、磨合良好的敏捷團隊的方法；也就是說，團隊成員過去已經以敏捷團隊的形式合作過幾個迭代周期，並且實現了穩定的速度。例如，一個敏捷團隊在過去的四個迭代週期中，速度都保持在一個較小的範圍內（誤差在正負 10% 以內），例如 19、21、20、19 個故事點。在這個例子中，團隊的平均速度（過去四個迭代週期的平均值）= (19+21+20+19)/4 = 19.75 ≈ 20。

如果同一個團隊（完全相同的成員）計劃在下一個迭代中繼續合作，並且下一個迭代中可用的工作日數量與前幾個迭代相同，並且預計不會有任何團隊成員因任何重大工作而被抽調出項目，那麼在這種理想情況下，敏捷團隊可以輕鬆地在即將到來的迭代中計劃 20 個故事點的工作量。

在這種方法中，由於假定滿足若干理想化假設，例如：因此無需估算或計算團隊在即將到來的衝刺階段的實際能力。

• 一個配合默契的敏捷團隊已經達到了穩定的速度；過去四個迭代周期中測得的平均速度是即將到來的迭代周期預計速度的領先指標。
• 下一個迭代週期將沿用原有的默契團隊；也就是說，團隊成員將完全相同。
• 下一個迭代周期可用的工作日數量與過去幾個迭代周期的工作日數量非常接近；也就是說，下一個迭代周期不會有異常多的公司假期，預計不會有團隊成員休長假，預計也不會有團隊成員因為迭代周期工作以外的其他任務而損失工作能力。
• 下一個迭代周期的技術平台將保持不變（與上一個迭代周期相比沒有變化）。
• 下一個迭代週期不需要任何團隊成員來掌握新的領域知識。

方法 2：使用少量參數以小時數估算產能。

當方法 1 所依據的一個或多個假設不成立或至少值得懷疑時，本方法適用。如果存在以下一個或多個情況，則不應使用方法 1：

• 敏捷團隊目前還不是一支配合默契的團隊；過去，他們的開發速度在每個迭代週期中都經歷了不穩定的變化。
• 敏捷團隊的組成在下一個迭代周期中可能會與上一個迭代周期有所不同；這肯定會改變團隊的動態和團隊的生產力。
• 由於即將到來的假期、暑假或寒假等原因，預計團隊在即將到來的衝刺階段的產能將與上一個衝刺階段有所不同。
• 團隊成員需要在下一個迭代週期中使用不同的技術平台。
• 一個或多個團隊成員需要學習並應用新的領域知識，以備下一個迭代週期之需。

在這種情況下，我們不能將過去的平均速度作為預測即將到來的迭代速度的領先指標。我們需要估算團隊在即將到來的迭代期間可用於實際操作的工作時間。本方法採用簡化模型，參考組織內典型的八小時工作日中的「實際操作時間」（如果存在且可用）。根據歷史數據，團隊可能會將八小時工作日的 60% 到 80% 用於實際操作。剩餘時間（40% 到 20%）則用於處理一般郵件和電話、公司會議以及準備和參與日常工作。 混戰 會議等等。因此，預計每位全職團隊成員每天有 4.8 到 6.4 小時（或每週 40 小時工作制下為 24 到 32 小時）的時間用於實際操作。例如，如果一個敏捷團隊有八名全職成員，並採用四周迭代周期，那麼它預計下週的工作能力為 8 x 4 x 24 = 768 小時（假設 60% 為實際操作），或高達 8 x 4 x 32 = 1,024 小時（假設 80% 為實際操作）。

請注意，這只是對敏捷團隊能力的粗略估計，因為它僅基於一個參數（可用於實際操作的時間百分比，通常為 60% 到 80%，根據組織的歷史數據而定）。如果沒有歷史數據，有些組織會根據經驗或自身對該數字的接受程度，使用一個估計值（例如 75%）。

預估產能用於指導敏捷團隊規劃即將到來的迭代周期（Sprint）的工作量（待實現的使用者故事或功能，以及待修復的缺陷）。例如，如果團隊的預估產能為 800 小時，那麼其預估工作量也應接近 800 小時；團隊可以超出產能，但超出幅度不得超過 5%；也就是說，在本例中，預估工作量不應超過 840 小時。

敏捷團隊現在需要根據其優先順序排序的迭代待辦事項清單來估算或計算計畫工作所需的工時。每個使用者故事和缺陷的工作量需要以理想工時（而非實際耗時）來估算。團隊可以根據其對相關工作的集體認知，在使用者故事或缺陷層級進行估算。或者，也可以將每個使用者故事和缺陷分解為任務和測試；分別估算每個任務和測試的理想工時，然後將這些估算值匯總，從而得到使用者故事或缺陷的理想工時估算值。

由於方法 2 僅基於單一或少數幾個參數提供容量估算，因此它只是一個近似值。如果您需要基於一套全面的參數精確估算團隊容量（以小時為單位），則需要採用方法 3。該方法將在下文中介紹。 第二部分 這篇文章分為兩個部分。