在 第一部分 在這篇分成兩部分的部落格中，我介紹了兩種敏捷能力運算方法：

• 方法1： 無需估算或計算容量。這是一種理想化且最簡單的方法。
• 方法2： 容量僅使用少量參數進行粗略估算（以小時數計）。

在本篇分為兩部分的部落格文章的第二部分中，我將介紹敏捷容量計算的第三種也是最後一種方法：

• 方法3： 容量是使用一套相當全面、可擴展且可自訂的參數集精確計算的（以小時為單位）。

評估每位團隊成員實際操作能力時，會考慮許多因素，例如：

• 迭代週期內可用的周數和工作日：例如，一個為期四週的迭代周期共有 20 個工作天（假設每週工作五天，且不包含公司假期）。如果迭代週期開始時間晚於第一週的星期一，結束時間早於第四週的星期五，則該迭代週期的工作日將少於 20 個。例如，如果迭代週期從第一周的星期二開始（假設星期一遭遇暴雪，公司停工），到第四週的星期四結束（假設星期五安排了迭代評審和回顧會議），則該迭代周期實際上只有 18 個工作日。
• 衝刺時間盒內安排的公司假期數量：如果公司在衝刺時間盒內安排了兩個假期，則該衝刺中的工作日數量將減少兩天，這也將降低個人和團隊的產能。
• 每個團隊成員的個人假期或帶薪休假：例如，如果一個團隊成員計劃在即將到來的衝刺時間盒中休假三天，那麼他的產能將減少三個工作日（團隊產能也將減少相同的天數）。
• 團隊中的全職成員與兼職成員：如果團隊成員不是團隊的全職成員，但計劃只投入 50% 的時間在專案上，那麼他的能力將減少 50%。
• 準備和參加每日站會所需的時間。
• 需要時間處理一般電子郵件和電話，以及參加公司或非專案會議。
• 預留應急時間。
• 任何會降低團隊成員能力的因素，例如：
  • 對先前版本軟體的支援工作
  • 在目前迭代進行的同時，為下一個迭代準備待辦事項清單（所謂的兩級 Scrum 管線）
  • 培訓團隊新成員
  • 透過自我培訓提升跨職能技能

雖然這份清單看似涵蓋了計算容量時需要考慮的所有因素，但它並非詳盡無遺。您可能需要根據組織的實際需求進行增刪、修改和客製化。方法三似乎需要大量的計算工作。然而，這種計算是透過基於 Excel 的範本完成的，幾乎可以立即得出容量數值。

如果您的團隊是配合默契、速度穩定的敏捷團隊，且方法 1 所需的所有假設都已滿足，則應按照文中所述的方法 1 使用。 部分1 本部落格指出，組成一支配合默契、節奏穩定的團隊是非常理想的目標。如果您確實可以使用方法一，則無需計算團隊容量。但是，如果方法一不可行，則需要使用方法二或方法三。

我強烈建議使用方法 3 而不是方法 2。雖然方法 2 可以快速估算產能，但如果您有典型的八小時工作日或 40 小時工作週的實際工作歷史數據，它只能為您提供產能的粗略估計。

方法 3 可以非常精確地計算單一團隊成員和整個團隊的能力，速度非常快，使您能夠… 如果什麼 這種方法不僅能有效進行測試，還能讓所有團隊成員和管理階層完全了解產能計算過程。我看過很多團隊及其成員對低於預期的產能數據感到驚訝；然而，這種方法能讓他們理解產能偏低的原因，以及如何以切實可行的方式提高產能。這種產能運算的透明度使得管理階層和團隊成員能夠就如何平衡產能和工作量展開坦誠的對話。

以下是我在訓練和指導的團隊進行敏捷能力規劃時觀察到的兩個對話範例。

• 敏捷團隊 A 計算了自身的工作能力，發現比產品負責人希望團隊在下一個迭代中交付的工作量（按優先順序排序的功能和缺陷清單）少了 30%。團隊意識到，增加新成員並非提升下一個迭代團隊能力的有效方法。在 Scrum Master 的引導下，團隊成員討論瞭如何透過一系列措施將團隊能力提高 10%（例如，增加兩名兼職團隊成員在迭代中分配的時間，減少另外兩名團隊成員的計劃休假天數等）。團隊成員和產品負責人也討論瞭如何透過將兩個優先順序最低的功能和一個優先順序較低的缺陷從迭代範圍中移除，並縮小其中一個功能的範圍，來減少約 15% 的工作量。此時，團隊能力僅比計畫的工作量低 5%；團隊對這種情況感到滿意，並決定繼續進行迭代。
• 在團隊容量和工作量大致平衡（彼此相差不超過 5%）之後，敏捷團隊 B 會使用以下方法來查看每個團隊成員的容量和個人工作量： Digital.ai Agility公司前身為 VersionOne。 Sheryl（使用者介面開發人員）的工作量過大，而 Tim（Java 開發人員）則有剩餘的開發能力。 Sheryl 和 Tim 討論了 Tim 可以如何分擔 Sheryl 的部分工作（簡單的 UI 開發），並在 Sheryl 的指導下完成。他們都意識到，Tim 在 UI 開發方面的效率不如 Sheryl，因為這並非 Tim 的主要專長。本著跨職能敏捷團隊的精神，Tim 主動提出在 Sheryl 的指導下參與工作。這種負載平衡在某種程度上減輕了 Sheryl 的工作負擔，但她仍然不堪重負。沒有其他可行的方案。團隊與產品負責人討論後，同意將兩個 UI 密集型功能從迭代範圍中移除，並將一個目前在發布待辦事項清單中的非 UI 密集型功能添加到迭代範圍中，以便更好地平衡 Sheryl 和其他團隊成員之間的工作量。

總之，如果您的敏捷團隊配合默契，並且滿足方法 1 的所有假設條件，請使用方法 1；否則，請使用方法 3。讓產能規劃工作指導團隊成員和產品負責人之間的對話，以完成迭代規劃流程。

第一部分－敏捷能力計算