靈活開發使用者故事系列之九：使用者故事早期估算

這是靈活開發使用者故事系列的第九篇。（欄目目錄）

本文适合聽過MPD上《靈活開發需求管理：使用者故事分類、顆粒度及組織結構》，或參加過《火星人靈活開發教育訓練》聽過第一天下午課程的讀者。

若您閱讀過程中感覺缺少鋪墊的資訊，請先閱讀：

靈活開發績效管理之六：靈活開發生産率（中）（功能點分析，FPA，簡化的功能點）

靈活開發績效管理之七：靈活開發生産率（下）（簡化功能點分析，NESMA，兩級簡化）

若需要更詳細情況，請閱讀：【線上研讨-現場文字】《靈活開發使用者故事分類與組織結構（一期-1）》2012-06-26 

及一期其他所有文章。

與早期估算相關的兩類使用者故事

之前已經提到過，盡管使用者故事規模、種類差異很大，但最終與項目開發規模直接相關的，是兩大類。

第一類是檔案故事（File Story），就是使用者需要管理的業務資料。

比如一個人員管理系統，要管理使用者/角色/權限這三個業務資料，那麼就可以寫下3個檔案故事：使用者，角色，權限。

如果不深究或來不及深究其中的細節（比如老闆隻拿回來一張紙上面寫着這六個字，問“大約”多久可以完成），那麼可以簡單地這樣估算：

1檔案故事 = 40人天 = 2人月。（中國-政府行業軟體生産率）

是以上述“人員管理系統”，需要6人月。

這可能和直覺感覺大相徑庭，“這麼簡單的事情，把需求告訴我，我一個下午就能做完。”

那麼這6個人月包含什麼呢？這個資料可以用來做什麼？（亦即不可以用來做什麼？）

使用檔案故事做估算時的工作量包含

1. 需求分析/架構設計/編碼/測試/部署（至初驗款結帳），所包含範圍的工作量大約是純編碼期的兩倍略多

2. 需求模糊所需的讨論/測試/返工/修改缺陷/響應客戶提出變更/乃至部署後提出的變更（在初驗結賬前），所包含的範圍大約是“一次完成”的1～N倍。

4. 由于有多個人參與項目，是以由分工造成的文檔/交流/溝通時間/修改别人Bug/人員離職時閱讀别人的代碼……等時間。

國内的20多個資料表明，若将團隊控制在2人，生産率就能達到業界水準的2倍。但很可惜，“2人團隊”一般需要至少一個業務和技術均過硬的高手參加，而除非一家公司1/2的人都具備這個素質，否則不可能全部變成2人團隊。

5. 人員盡管定編在此項目中，但需要參加其他日常會議/上司前來打攪/緊急缺陷的修複/閑聊/上網……一切最終實際上會被填報在日志中的工時。某些時間看上去很不應該參與到生産率計算中（比如“閑聊/上網”），但因為永遠不會有人單獨填報“閑聊/上網”時間，是以它們實際上都被填報到日報中參加計算了；“上司前來打攪”的工作量，也不可能計算到其他項目中，是以也計算在人員所定編的項目中。

6. ……

這個資料可以用來做什麼？

審視上面工作量的内容，會發現這個資料不是面向開發本身的，而是面向“成本”本身的，即若有任何工作量被計入成本（需要發工資或獎金的），而有沒有其他項目可代為承擔的，那麼就計算到這個項目中。

是以，1檔案故事 = 40人天 = 2人月這個計算方法，适合早期項目造價估算。

也就是企業隻有提供2人月的成本，才能完成1個檔案故事。

作為在項目初期想知道全貌的高層上司，“6個人月的成本才能從頭到尾完成這3個檔案故事”，要比“告訴我需求，我一下午就能開發出來”要有意義得多。

第二類是操作故事（Function Story），就是使用者對業務資料進行的業務操作。

比如對一個人員管理系統，要管理使用者，就要有增删改查等操作，這些操作都是業務語境中面向業務資料的，和我們平時說的資料操作不是一個東西。

FPA有一些方法，能根據業務操作估算出比僅僅知道業務資料時更準确的資料，但很可惜，這些操作的數量很難在項目早期估算出來，比如我問：除了增删改查，對“使用者”還有哪些操作？在項目的初期，很難說的清楚。但實際工作的時候，就會發現落下了“批量操作”“當機”這兩個操作，而且，每次都隻會落下而不會多估，反而不準确。

是以，在項目的初期，不要嘗試用操作故事進行估算，而隻使用檔案故事。

不過，操作類故事可以被用于做生産率度量，因為在項目結束後，計數工作就不會有偏差了。這個，在日後會再談。

火星人工具中，将來會推出利用使用者故事度量生産率的功能，其前提之一是使用者利用火星人中對使用者故事的定義進行描述。這一點在本文文初列出的研讨中描述。

非功能性需求造成的生産率波動

由于行業差異/品質要求/軟體規模等，會造成生産率的差異，并非每個檔案故事都要花費2個人月完成。

影響生産率的因素很多，按南韓的統計資料（南韓現在擁有全世界1/3的FPA專家），主要因素是應用領域差異，南韓的分類統計很細，簡單說差異系數大約分别是：

1. OA/MIS類應用：1.0（即每檔案故事 = 40 × 1.0人天，下同）

2. 科學計算類：1.4 （簡單的财務軟體/計算軟體）

3. 實時控制類：1.7 （電信計費軟體/生産管理軟體）

4. 指揮管控類：2.2 （交通/核能/武器/航空等）

這些數字具體應用時并不準确，需要企業用自己的積累。

其他影響因素還包括品質要求、軟體規模等，但影響率都隻有0~20%左右，與應用領域相比不足為慮。

注：檔案故事和操作故事及其英文File Story / Function Story，都是筆者自己臨時起的名字，在國際上尚沒有對使用者故事絕對顆粒度進行讨論的先例。

檔案故事得名于FPA中提到的内部邏輯檔案（Internal Logical File），但與之對應的操作故事在FPA中被稱為“交易”（Transaction，來自早期銀行軟體）過于難以了解，還是稱之為操作故事（英文名Function Story則來自于我們日常所說的“功能性需求”）。

這種命名的混亂還會持續一段時間，取決于未來參與此話題讨論的結果。由于Agile和FPA都來自國外，很多讨論将照顧到國外的用語。