本書由本人編寫，於2014-09-09在百度閱讀首發，部落格將轉載試讀部分的20%內容，以及非試讀章節的某些片斷。

第一個月

從用例到使用者故事，從使用者故事到程式碼

在敏捷計劃會上——是的，他們採用敏捷開發，確切說是Scrum——產品經理正在給開發人員講解需求。

他並不是空手來的，而是帶來了幾張圖，比如下面這張收發貨子系統中的“結帳記錄”的“用例-流程圖”。這是他在計劃會前，會同幾個客服、運維以及開發骨幹討論繪製出來的。

這張圖表明對於“結帳記錄”這個資料實體，共有4個不同的業務操作，也大約對應4個不同的頁面——至少多數時候如此。在講解完成整個圖形及單個頁面的詳情之後，產品經理提醒大家，從圖中的業務依賴關係來看，這4個業務操作必須同時被完成，這個功能才得以上線。

開發人員們紛紛點頭，在一個名為CheckRecordsController的類裡邊寫4個方法——Pay（付款），Details（單個詳情），IndexOfShop（檢視所有本店鋪的支付記錄），IndexOfExpress（檢視所有本物流公司的收款記錄）——不是一個非常艱鉅的工作。

簡短估算

圖中的圓圈，做估算的人把他們叫做拗口的EI/EO/EQ（外部輸入/外部輸出/外部查詢），做需求的人喜歡叫用例，做前端的人喜歡叫頁面，不過在習慣了敏捷開發的開發人員眼中，他們更喜歡稱之為4個使用者故事。這4個使用者故事組成了1個必須完整交付的史詩故事——“必須完整交付的一組故事”，這是他們給史詩故事的一個新定義。

每個故事的功能點數是4.3點，上圖中共有4×4.3=17.2點；不過每個史詩故事本身要額外多計算7點，來自背後要設計資料結構、進行聯合測試等工作，一共是24.2點。這比之前說的平均值35點要小一些，不過只是個例。

若干這樣的圖形被講解、分析、估算完成後，500個功能點中的200個被確定在這個迭代內完成開發和測試。為什麼不是500/3=167？根據經驗他們知道第一個迭代應該完成較多的功能，而之後的迭代則會因為功能耦合、聯合測試等原因導致生產率下降，同時也可能會出現修改和刪除功能的情況。