這是敏捷開發績效管理的第五篇。（之一，之二，之三，之四，之五，之六，之七）

度量敏捷開發的生產率一直是個難題，確切說度量任何開發方法的生產率都是一個難題，但它實際上有答案，這個答案是本文的主要內容。

度量敏捷生產率的目的

真正難以回答的是度量生產率的目的是什麼？

很多人都認為是考核績效，發獎金。根據上一篇文章的內容我們可以知道，這完全是行不通的：客戶並不購買我們的生產率，生產率高也並不能證明產品或專案盈利，應該為團隊設立外部目標，否則很可能得到一個生產率很高，但是實際上很爛產品——質量上或易用性上很差，抑或其他想象不到但一定遇到的原因。這是我們說為什麼用外部目標而非內部目標考核團隊的原因。

或許又有人說：“開發得快不快是團隊的事情，產品好不好則是產品負責人的事情。”這樣也不對，相當於我們在自組織之後，當我們享有勇氣，尊重，溝通……這些敏捷的特質之後，我們居然得到了一個只關心自己的開發速度，而置客戶價值和企業利益於不顧的團隊。“受激勵的個體”只被自己小團隊的績效所激勵，並不愛也不關心自己的產品，這絕對不是敏捷開發的初衷。

度量生產率的目的不是績效考核，而是是希望提升生產率績效。將度量結果進行橫向和縱向比較，可以分析造成生產率差異的原因，並進而提升生產率績效。

微觀度量方法-故事點

故事點估算方法

“每月完成的人天數”這個方法不說了，用尺子量尺子，肯定不行的。不過通過統計每月的實際投入天數，可以優化人員利用率，並間接提升生產率。 

“每月完成的故事點”這個是比較好的方法。

所謂故事點法，就是提前選擇一些大家都熟知的、以往做過的、典型的故事，比如：

1. 對單個表進行增刪改查

2. 對父子表的增刪改查

3. 為一個已經存在的資料表增加一個複雜報表

4. 修改一箇中等難度的BUG

……

（實際上這些故事應該是具體的，而不是像上面例子中一樣看起來更像是“分類”）

然後人拿出當年的歷史記錄，將當時所投入的人天數稱為“故事點數”（也有別的做法但這個最簡單）。比如“對單個表進行增刪改查”當年用了4天，那麼標準故事點就是4。

當下次估算時，人們又發現有一個故事也是“對單個表的增刪改查”，於是就先選定基數為4，再討論這次與上次比，到底複雜多少。如果一致認為可能複雜20%，那麼故事點就是5。

如果大家的生產率不變，那麼這個故事應該5天完成，但是如果結果卻是4天就完成了，則表明大家的生產率提高了。當然不是一個一個故事度量，而是把整個迭代內的故事點加起來度量。

通過縱向比較故事點，可以知道大家是否比以前的生產率提高了。

橫向比較故事點比較有難度，因為每個團隊乃至專案都會選定自己特有的標準故事，而且極難說明這個團隊和那個團隊的標準故事的轉換關係。

故事點的侷限性

在推廣故事點這件事情上筆者有所保留，建議嘗試但需注意風險，必要時知難而退。在筆者遇到的這麼多做敏捷的企業和人裡邊，還沒有見到有人提到他們的故事點應用是成功的。

原因在於找到大家都熟知的、以往做過的、典型的故事很難，而讓所有人記住它們當年的詳細情況以便日後對比修訂就更難。

04年筆者去做諮詢的一家企業有他們的故事點模板（他們並不做敏捷開發，但卻使用完全類似的方法），一共有17種標準故事，已經記錄了25個專案的故事點資料和實際工作量資料，每個專案從4個故事到上百的故事不等，他們希望筆者能幫他們計算一下“17個標準故事分別對應多少人天”。終於遇到了又有標準故事又有歷史資料的情況，這比所有一窮二白想使用故事點的企業可樂觀多了。

這是一個所謂“線性規劃”的問題，涉及“最小二乘法”“超越方程”這些玄乎的名詞，但卻在Excel表裡有這個功能，不過是10分鐘的事情並不費力，真正費力的是解釋其結果：求解的答案是——某些標準故事是負數，也就是說如果把這幾種故事當作負數對待，那麼以往發生的25個專案的預測結果與實際結果最符合。

再換一種直白的解釋：用這17種故事預測工作量不準。

或許有人會說他們的17種故事選得不好，或他們的水平很差。怎麼說呢，他們是一家1000多人的電信企業，專職做過程管理的人就有5人，還認真地記錄了這麼多資料，恐怕當年選定故事的過程也是經過思考的。倘若他們都難以建立其故事點，一般的10人團隊想自己做一套恐怕更難。

回過頭來觀察他們公司的失敗原因，是在為新的故事找到對應的標準故事後，沒有根據其差異進行調整，而是機械地選擇了標準故事的故事點，導致誤差很大。在採用故事點的時候應該注意。但他們考慮到某些故事的迴歸結果居然是負數，即使“進行調整”結果也會是血淋淋的，甚至可以說基本扔到了標準故事從頭估算，最終放棄了故事點，採用了另外一種方法，就是下篇文章提到的“功能點估算”。

筆者之前的一篇文章有故事點估算方法的更詳盡的介紹，但角度不同：

故事點為我們提供了一種比較客觀度量敏捷生產率的方法，但其侷限性限制了其應用。下一篇文章將介紹另外一種廣泛應使用的方法：功能點估演算法。 

點選下載免費的敏捷開發教材：《火星人敏捷開發手冊》