這是敏捷開發績效管理的第七篇。 續前文…… ## 功能點估算 ### 第一級簡化 上次說到只用數據+操作就能準確計算規模，聽起來夠簡單了，但其實還不夠。 誰能在剛拿出2頁紙的需求文檔時（假設昨天老板在酒桌上剛從客戶那記下來的），就猜出有多少個操作？而且還不遺漏？增刪改查好猜，“加入角色”就不好猜了。 NESMA早就遇到過這個問題了，他們這么解決：通過統計發現每個數據差不多有7個操作，所以剛才咱們找出了3個數據，那么： 3個 × （數據7 + 操作4×7個操作） = 3 × 35 = 105，嘿，把角色和權限的操作問題也給解決了，不用猜了。 如果有幾個數據要管理也不知道怎么辦？那也太粗糙了吧，再去細化一下吧（別細化報表上有幾個按鈕，按了按鈕后的邏輯是什么……那個和規模無關；只確認是不是數據）。 這樣準嗎？來自課后的10個數據表明，基于這種功能點作出的工作量估算與實際項目數據相比，最大誤差在正負50%左右（本人手里沒有詳細數據所以沒分析，應該取P50就是中值的誤差比較好，可能在30%左右）。雖然聽起來誤差大得乍舌，但是在手里只有2張紙的時候，已經很準確了。某政府部門的要求是到400%以內都可以接受，因為他們在一個項目的招標中，4個供應商報價最大差別是12倍。 總結一下這一級別的簡化方法就是：**每個內部數據35點**。另外如果是外部接口數據（比如要取LDAP），那么每個**外部接口數據15點**。 第一級簡化適合**項目合同期/項目初始計劃**的早期估算。 ### 第二級簡化 如果項目已經完成了，不用猜了，就可以數到底有幾個操作，就不用猜每個數據有7個了。 不過，到軟件界面上面數顯的很不專業，**如果我們的史詩故事是基于數據寫的，用戶故事是基于操作寫的，數史詩故事+用戶故事不就得了**？比如圖中這個：  圖中就是剛才提到的用戶/角色/權限的局部，一共3個數據（小課本是史詩故事），外加19個操作（藍色的是用戶故事，其中兩個“新建+查看”分別代表兩個，要×2），加起來是 3 × 7 + 19 * 4 = 21 + 76 = 97，已經很接近105個了……如果考慮到這個軟件還沒有編完，我們第一級簡化還是蠻準的嘛（歸功于NESMA的長期努力）。 完成這些功能需要 105 × 9 = 945 小時 = 118人天。如果我們有一個迭代，正好要完成這些功能并將其部署上線，那么就按118天計算吧（如果只編寫出來不測試，大約是70%的工作量）。當然這不是說任何一個人都花相同的時間，而是基于現在業界收集上來的數據，團隊人均花費這么多。個體的生產率差異可達5倍，但團隊卻都差不了太多。 另外單個故事的精度也很差，比如如果某人正好編過某功能，可能一小會就完成了。但是如果很多人編寫很多故事，大數定理會起作用。 總結一下這級別的簡化方法就是：**每個內部文件按7點（每個外部接口按5點），每個操作按4點，加起來就是功能點**。 這個級別的簡化**適合每個迭代確定工作量；還可以在項目完成后，總體計算開發效率作為績效管理的依據（算是回到績效管理了）**。 ? ## 遺留問題 正如前言，很多敏捷世界的新鮮事，在別的世界早就不是新鮮事了（當然別的世界也有他們的新鮮事），提出和解決下面這些問題的很多前輩都已經去世了。 本文只是指出有這么一種方法，并非這種方法的操作手冊，這種方法還是需要培訓的（有現成的）。 1. 就這么簡單？ 不是，簡化的功能點大約需要一整天的培訓，后續估算（推導工作量/工期/成本）還需要一整天。里邊有很多細節。 復雜的功能點大約需要2～3天培訓，另外一般5天左右的指導，如果要CFPS證書還有一個3天左右的考前指導。 2. “每個用戶操作 = 一個用戶故事？那修Bug怎么辦？做小的改動怎么辦？提升性能怎么辦？” 可以記錄成不同類型的故事，但是就別計算功能點了。圖中三個綠色箭頭，就是三個對原有故事的“增強”，其特點就是無法描述為完整的用戶操作。 他們不計數，但是在統計時已經被平攤到計數的故事里邊了。 我自己實踐的時候發現，有些故事為了開發方便，極有可能包含兩個操作（如上面的“角色首頁”包含新建和查詢兩個操作），建議可以當作一個故事，怎么舒服怎么來不要太生硬，但是加個記號知道是2個操作，防止數錯。 3. 每個數據都是/才能是史詩故事嗎？ 不一定，我有一個史詩故事叫做“性能優化”，它就不是，也不計算它。 4. 每個動詞都是操作？ 不一定。簡單而言就是只有”主語是用戶“的動詞才是操作。”。 暫時還沒有遇到有些Backlog Item不是用戶操作但是很想當成用戶故事的情況，如果有，可以在史詩故事/用戶故事上設置一個字段，如果是才計數。 5. 非功能性需求怎么辦？ 最早提出來也最早被解決的問題，標準功能點的非功能性調整因子是1970左右（天啊……）提出的有點老了多數都不適用了；個人最喜歡的是韓國標準中的調整因子，大致可以理解為普通的乘1，科學計算之類的乘1.3左右，運營計費乘1.5左右，生死攸關的乘2左右。 非功能性調整因子一般包括規模因子、領域因子（韓國標準包括8大類約50小類）、質量因子（韓國標準包括4個質量因子，每個三個等級）、開發語言因子這幾個。有時候不會覺得他們考慮不周，反而是多慮了…… 6. 準嗎？ 不準。因為這種方法雖然很準，但是那個”9小時/功能點”是業界數據，最好用自己的數據重新回歸一下。 本人正在回歸自己的，可惜只有一個項目在做，所以不得不每個迭代都當作項目來看待。一般稍微大點的企業有一年時間積累20個（子）項目數據就可以了。 7. 有前途嗎？ 有。芬蘭，澳大利亞，韓國，日本……的政府采購均采用這種方法計算價格。中國的國標預計在明年出臺，即政府采購項目均將使用這種方法報價（或指導報價）。 8. 有的項目好壞可不是光看開發的功能多少，還要看創意和…… 是的，**用這種方法度量績效的目的，是為了提升開發績效，加快開發速度，而不是計算工資獎金或評價項目好壞**。在[之四](http://blog.csdn.net/cheny_com/article/details/6713089)里邊已經提到，必須在賺來錢的時候才能發獎金，它是由外部目標驅動的。 在產品開發中，往往收入與功能多少的關系不很直接甚至完全沒有關系，但在一些直接由功能點報價的政府項目、外包項目里邊，這個可以直接作為外部目標考核。 ? **本人正在參加CSDN博客之星評選，如果讀完并喜歡這篇文章，歡迎投票：**[http://vote.blog.csdn.net/item/blogstar/cheny_com](http://vote.blog.csdn.net/item/blogstar/cheny_com) **** 點擊下載免費的敏捷開發教材：《[火星人敏捷開發手冊](http://blog.csdn.net/cheny_com/article/details/6616794)》