這是敏捷開發績效管理的第六篇。 直接估天數或用故事點估天數，都很“程序員”。如果在項目的甚早期，面臨與客戶相關的報價問題，或高層領導要統計公司績效并想進行項目乃至行業間的比較，這兩種方法都很難使用。 敏捷開發內部之所以沒有進化出來能做**項目間比較、行業間比較、用于早期報價**的估算方法，是因為敏捷的發明者和后來的實踐者多數都不管這些事情。而這三樣事情，比天數、故事點，在老板眼中更接近生產率績效。 這時候就需要功能點估算。 ## 功能點估算 ### 由來 功能點估算是另外一個世界的事情。每100個懂敏捷的人中，可能才有1個懂CMMI；而懂CMMI的人中，可能才有100個懂功能點，而100個懂功能點的人中，也只有1個人懂敏捷……這就是三個世界，但每個世界都和敏捷世界一樣熱鬧，一樣有可操作的方法，只是互相不通信而已——結果是，**每個世界都不知道別人已經早就解決了自己冥思苦想的問題**。 **用功能點度量軟件的目的，是在早期獲知軟件開發的工作量，進而推算開發成本**。 由于這個目的，使得它實際上是與開發工作量的相關性也最強（遠遠超過Delphi/代碼行/故事點/用例點……多個國家的政府使用此估算采購軟件，中國大約2年就后采用），而且居然和用戶故事還有很好的對應關系。 功能點本身很復雜，大家可以在網上查到一些資料，這里不多說了。標準功能點分析尤其復雜，有一次有一個歐美發包商來到中國，問“我們現在已經有100多頁文檔，誰看過之后知道這個項目要多少錢才能開發出來，以及為什么，我們就把這個項目給他。”筆者介入了此事，也知道標準功能點能解決這個問題，但是卻不能在給定的時間內完成（只有2天的時間解決此問題，而用功能點至少需要10～15天）——國外ISBSG也轉發度量Guru Capers Jones的郵件稱“只有極少數的項目采用了功能點估算，因為成本太高”。這件事情促使筆者嘗試找簡單的功能點估計方法，直到后來在另外一個世界發現有人早就解決了大約10年了……那就是NESMA的簡化功能點，如果不嫌麻煩請參閱[http://www.nesma.nl/section/fpa/](http://www.nesma.nl/section/fpa/)（點擊左邊 Advanced 下面的 Early&Fast FPA）。 不過建議直接看下面。下面的概念作了**很大的調整以便于用有限的文字理解**，如果有懂FPA的讀者看出破綻不要奇怪（本人是正規做FPA培訓和研究的）。 ### 什么是簡化的功能點估算 在我們的開發工作中一共有兩類東西要開發，一種是數據，一種是操作。 所謂數據，就是比如要編寫一個CRM，其中有“用戶、角色、權限”這三種東西，就是要管理的數據，這里權且記下用戶有“3個數據”要管理。 所謂操作，就是對用戶，應該有增、刪、改、查、加入角色……這些稱之為操作，這里權且記下對用戶，用戶會做“5個操作”。 倘若角色和權限沒有操作（雖然這是不可能的），那么在NESMA簡化方法中由于每個數據是7點，而每個操作是4點左右，那么就可以算出來一共有： 3 × 7 + 5 × 4 = 21 + 20 = 41點。 ISBSG/IFPUG包括中國的CSBSG等都有**不同行業/不同類型軟件的生產率統計**，如果你在中國，用C#或Java開發一個類似OA/CRM這樣的業務流轉軟件，那么生產率大約是9小時/功能點（來自于10多個學員的課后數據），也就是上面那個小軟件，要用9×41 = 369小時大約是46人天。 “什么？這點內容我不到一星期就能做完。”是，也不是。這一時間的包含了需求分析/設計/編碼/測試/集成/上線部署期間的所有時間，還包括開會討論的時間，和別的功能聯調的時間，培訓的時間，修改萬惡的Bug的時間，提升性能的時間，改善易用性的時間，上網找圖標的時間，上班看博客的時間——總之一個真實項目中可能發生的時間全都平攤在這里。 聽起來夠簡單了，但其實還不夠。 誰能拿出2頁紙的需求文檔（假設昨天老板在酒桌上剛從客戶那記下來的），就猜出有多少個操作？而且還不遺漏？增刪改查好猜，“加入角色”就不好猜了。 怎么辦？請看下文。 點擊下載免費的敏捷開發教材：《[火星人敏捷開發手冊](http://blog.csdn.net/cheny_com/article/details/6616794)》   **** **本人正在參加CSDN博客之星評選，如果讀完并喜歡這篇文章，歡迎投票：**[http://vote.blog.csdn.net/item/blogstar/cheny_com](http://vote.blog.csdn.net/item/blogstar/cheny_com)