管理研發團隊後，我發現用「速率」做度量錯得離譜……

一旦你開始瞭解敏捷開發和 Scrum 方法，就一定會碰到「速率 Velocity」。它表示研發團隊在一個迭代週期內，能完成的所有故事點數之和；常用作度量基準，輔助長期的工作估算和迭代規劃。

幾年後，當我在一個優秀的軟體工程師團隊擔任管理者，我才意識到「速率」在實際度量時存在很大的缺陷。也正因如此，我才得以找到真正正確的研發效能度量指標。

01 為什麼「速率」不好用？

讓我們從速率的計算公式開始：

• 實際速率 = 完成的總點數 / 迭代次數
• 預期速率 = 估算產生的總點數 / 迭代次數（估算故事點數即被新增到迭代中的故事點數）

在管理實踐中，大多數團隊會選用「實際速率」，所以本文也圍繞它展開說明。那麼，實際速率在使用中具體存在哪些缺點？

1. 無法展示浮動空間

實際速率在數值上無法展示研發團隊實際完成工作量的浮動情況。 下面是點數定義相同的兩個團隊在四個迭代內分別完成的故事點數統計：

從結果上看，兩個團隊的速率值都是 20， 但我們能說「兩個團隊都能在一個迭代內完成 20 個點的工作」嗎？

對第二個團隊或許可行，因為它的迭代點數浮動很小（± 2 個點），但第一個團隊的變化就大得多（± 18 個點）。如果只看實際速率值，管理者其實無法瞭解和掌握研發團隊的穩定性。

更進一步地，也無法準確地估算待開發的故事和任務的工作量，或者為史詩（Epic）擬定一個預計釋出日期。

2. 不能靈活適應變化

研發團隊和需求經常會發生變化，成員出勤率、人員變動、緊急 Bug 修復、企業培訓等等都會影響實際可用資源。

但是，實際速率是基於理想的團隊平均運轉能力計算的。如果迭代期間有成員休假外出，那團隊能否完成所有的故事？這對速率又會產生怎樣的影響？團隊還能準確地估算開發容量嗎？

同樣的，如果團隊迎來一名新成員，那實際速率會變大嗎？還是由於我們需要為新成員提供培訓，該迭代的研發速度其實會變慢？需不需要重新評估待辦列表？這些我們都毫無頭緒。

3. 估算本身不準確

用速率管理研發效能難有成效的原因還在於，它依賴於故事點數——一個被人為定義的、很難在團隊內部達成統一共識的估值。 同時，研發團隊也很難保證跨迭代的點數衡量標準一致，這也是當前工作估算的頭號難題。

如果不能用相對標準和準確的方式估算研發工作，就很難維持穩定的開發速率。這不止會影響後續迭代的管理，也限制了估算精度的檢驗和改進。

4. 成員會精疲力竭

最後，基於速率值設定團隊的迭代目標不可避免地會讓成員倍感疲憊。

相信很多團隊都出現過追趕截止日期，緊急交付的情況。在臨近交期的短時間內，成員們超負荷工作，每天工作 15 個小時再加上週六、週日無休，儘可能完成所有的待辦事項，以達成迭代目標。

我們都不希望類似事件發生，但不可否認的是，「極限挑戰」狀態下的團隊速率確實得到了提高。那麼，在下一個迭代規劃時，研發團隊是否可以接受比現在更多的工作量？長此以往，工作量內卷一定會讓成員們疲憊不堪。

速率不該被用來設定團隊目標，而應該被管理者用來設定績效先例並預判未來價值。

既然速率不可行，那應該用什麼指標代替它度量和管理呢？

02 正確的管理指標：承諾方差

使用承諾方差（Commitment Variance，即 CV） ，它有助於增強團隊自組織和提升自驅力。其計算公式如下：

• PointsCompleted-完成總點數：上一個迭代中，研發團隊成功交付的故事點數。
• PointsCommitted-承諾總點數：團隊在迭代計劃中承諾能完成的故事點數，可用被新增到迭代待辦列表中的點數之和表示。

1. 指標管理目標

使用承諾方差時，研發團隊要儘可能準確地估算研發工作量，並使用相同的標準承諾一個完成目標。

而優化承諾方差的目標是儘可能將其絕對值降為 0；團隊要努力完成所有任務，並使燃盡圖在迭代結束時變為 0。

2. 結果解讀

如果承諾方差的值

• 大於 0，說明超額完成目標。 團隊可以根據承諾值和迭代過程，決定是否提高下一迭代的承諾值；或者結合迭代覆盤，分析超額交付的具體原因，例如故事點數被高估、有計劃外的人手增加等等。
• 小於 0，說明承諾預期過高。 基於當前的數值基準，剖析過度承諾的原因，在下一個迭代中重新調整。
• 等於 0，意味著團隊能夠準確地估算研發任務並評估交付能力。 保持這個節奏，向前衝吧！

3. 優勢分析

用承諾方差代替速率管理研發交付能力，團隊會得到以下收穫：

• 結合每個迭代的實際情況，靈活地制定迭代承諾和目標。
• 正確定義故事點數，專注準確的工作估算。
• 正確地評估團隊交付力，有的放矢地設立承諾和目標。
• 圍繞自設定的承諾，調整工作狀態，減少迭代衝刺中疲勞的風險。

對團隊管理者而言，承諾方差也同樣意義非凡，主要體現在:

• 有機會與團隊合作，共同完成新功能和/或產品複雜性的估算，獲得安全感和信心。
• 向利益相關者提供更準確的預計交付期限。
• 放心授權成員自組織，激勵團隊自驅成長。

4. 潛在風險

當然，使用承諾方差管理也存在一些潛在風險。

• 自我施壓和內卷/內耗。 一旦成員（們）將交付工作量與績效評估等聯絡起來，就可能產生過大的內部/個人壓力，過度承諾和過度交付。管理者需要創造一個充滿安全感的環境，避免成員們內耗；也要敏銳識別過度承諾，以維護團隊長期健康的穩定發展。

• 故意減少承諾。 有些團隊可能會人為地減小承諾值或只完成承諾部分的工作。管理者需要甄別偽模式的存在，避免資源浪費。

一個小建議：可以先使用承諾方差管理工作，在建立相對準確的估算標準後，再嘗試用速率設立能力基準，在承諾方差的基礎上建立提速緩衝區。

03 案例分析

下面我們通過示例，進一步講解承諾方差的實際應用。還是開頭提到的兩個團隊，假設他們現在使用承諾方差來完成任務估算和能力評估。

上表中，團隊「迭代實際完成的平均工作量」就是實際速率。兩個團隊「平均承諾的故事點數」都非常接近 22（± 0.25）個點，但實際完成量卻非常不同。

第一個團隊在使用承諾方差後發現，當前定義的「點數」無法支援正確的工作量估算和能力評估。

於是在第四個迭代中，他們調整了「一點數工作」的定義並在內部達成共識。由於度量顆粒度變細，他們給出 28 個點的承諾值（儘管資料顯示，他們在上個迭代中只完成了 12 個點）。

通過繪製兩個團隊的承諾方差趨勢圖，可以看到，優化故事點數也是一個持續改進的過程。

04 LigaAI 總結

基於相同的點數標準，承諾方差將工作量估算與能力評估有機結合，解決了速率管理中存在的靈活性和準確性不足的問題。

承諾方差的管理目標是使其絕對值儘可能降為 0。既不過度承諾，讓團隊耗費心力，也要避免承諾低估，造成浪費資源。

（原文作者：Michel C；文章出處：Medium）

---

擊碎增長瓶頸，LigaAI 將持續分享研發效能度量體系的搭建經驗，以及科學的度量指標管理方法。瞭解更多效能優化與增長乾貨，歡迎關注LigaAI@oschina，我們一起做大做強！

也期待您點選 LigaAI - 新一代智慧研發協作平臺，與我們交流 :)

LigaAI 助力開發者揚帆遠航，期待與你一路同行！