敏捷開發績效管理之七：敏捷開發生產率（下）（簡化功能點分析，NESMA，兩級簡化）
這是敏捷開發績效管理的第七篇。（之一，之二，之三，之四，之五，之六，之七）
續前文……
功能點估算
第一級簡化
上次說到只用資料+操作就能準確計算規模，聽起來夠簡單了，但其實還不夠。
誰能在剛拿出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. 有的專案好壞可不是光看開發的功能多少，還要看創意和……
是的，用這種方法度量績效的目的，是為了提升開發績效，加快開發速度，而不是計算工資獎金或評價專案好壞。在之四裡邊已經提到，必須在賺來錢的時候才能發獎金，它是由外部目標驅動的。
在產品開發中，往往收入與功能多少的關係不很直接甚至完全沒有關係，但在一些直接由功能點報價的政府專案、外包專案裡邊，這個可以直接作為外部目標考核。
本人正在參加CSDN部落格之星評選，如果讀完並喜歡這篇文章，歡迎投票：http://vote.blog.csdn.net/item/blogstar/cheny_com點選下載免費的敏捷開發教材：《火星人敏捷開發手冊》
