用戶故事的顆粒度一直是一個談論已久的話題，但參加了很多研討會，搜索了很多網絡資源后發現一直沒有定論，只好在這里原創一下。

前言：為何需要討論用戶故事的顆粒度

其實需求顆粒度的問題由來已久，即使是在傳統開發中，也沒有提及在需求分析階段應該把需求做到什么顆粒度才可以開工。所以在下面這些分析之后會發現，其實即使反推到傳統開發中，下面提及的方法也依然有效。
為何要對用戶故事做一個顆粒度約束呢？
筆者在開發實踐中發現，如果大小不一的“用戶故事”堆積在一起，很難看出一個產品到底實現了哪些功能（或一個項目到底有哪些需求）。如果回溯到敏捷開發的源頭就會發現，由于敏捷開發中設定用戶故事是為了描述開發任務（盡管是從客戶價值角度）而非產品功能或項目需求，因此并沒有區分用戶和開發人員到底分別看到什么。
其實各種“用戶故事”中，大致可以分為史詩Epic、故事Story、增強Enhancement、缺陷Defect、技術債務TechDebts、重構Refactor等幾種。其中史詩和故事大致形成樹狀結構，很容易勾勒出產品或項目的結構，是最需要展示給用戶的；增強和缺陷在一定程度上需要展示給用戶，但除了評審中或交付后客戶提出來的之外，都可以不展示給用戶，而且即使展示，“展示”的層次也應該不同于史詩和故事；而技術債務和重構由于太技術化，不適合直接展示給用戶，而更適合展示給Product Owner及開發團隊。
本文所討論的，就是用于“展示產品或項目結構”的史詩與故事的顆粒度問題。

好的用戶故事的標準

先看看好的用戶故事的標準（內容及觀點與《敏捷開發與用戶故事》中大致相同）：
封閉性：完整地交付一個客戶價值
針對性：只包含一個用戶，因為多個用戶常常有細微的差別
獨立性：故事間沒有依賴
這幾條標準中最有價值的觀點應該是獨立、完整地交付一個客戶價值，這在敏捷開發中是至關重要的。傳統的開發會說要交付一個軟件功能，而敏捷開發則認為用戶必須使用這個功能以獲得自己的價值（請回憶一下用戶故事的編寫語法）。
不過僅僅如此就說能方便地劃分故事顆粒度，似乎還有點模糊，下面會引用兩個成熟體系中對顆粒度劃分的標準來做進一步說明。

功能點分析方法與用戶故事

第一個是國際標準功能點分析方法（FPA，Fuction Point Analysis）中對內部邏輯文件及基本過程的定義。
內部邏輯文件-基本過程樹是一個潛在的史詩-故事樹的原型。

一個ILF（ILF，Internal Logical File）就是一組邏輯上的數據，用戶能夠理解和識別它，對其進行的操作都是用戶的業務操作。
比如如果我們要開發一個“Scrum開發管理平臺”，那么有一些明顯的“邏輯”數據：系統用戶，用戶故事，迭代，剩余時間……它們不同于數據庫表或程序中的類，因為遠在程序被設計之前，就可以判斷它們是否存在。
一個基本過程（Essensial Process）就是對用戶有意義的一次業務操作，在完成這次操作后客戶得到其業務價值，而且數據穩定完整。
比如我們“增加一個用戶故事”，需要完成的細節過程很多：顯示輸入界面，在界面中輸入數據，數據校驗，數據寫入數據庫表，顯示“成功”信息……但只有這一切都完成，從用戶角度看才能獲得其業務價值，數據也才穩定完整，因此“增加一個用戶故事”就是一個基本過程，而“數據校驗”等則不是。
在FPA定義中，基本過程還根據分為外部輸入/外部輸出/外部查詢這三種。簡單說，我們常說的“增刪改查”都是基本過程。為了防止總是從技術角度談增刪改查，常常使用用戶業務術語來描述，比如“起草”（輸入）、“編輯”（輸入）、“發送”（輸出）等。

使用FPA中的內部邏輯文件-基本過程樹作為史詩-故事樹的顆粒度原型有下面幾個好處：
基本過程有嚴格的定義，已經形成了ISO標準，歧義少；
基本過程面向客戶價值交付，與敏捷開發的價值觀接近，也很容易用用戶故事描述；
文件和基本過程的數量被業界證實與軟件的工作量有很好的對應關系，已經有多個國家如日韓澳荷芬等將其作為軟件計價標準，工信部也已經進行國標立項，面向政府、銀行、電信等大量軟件外包場景中的造價估算，本文作者是技術專家組成員。

使用FPA中的內部邏輯文件-基本過程樹作為史詩-故事樹的顆粒度原型，將作出以下約束：
只有獨立完整地交付一個客戶價值才算是故事，而缺陷、增強等均不作為有效故事對待；
只有用戶可以直接作為業務操作使用的功能（可以是人-機或機-機交互）才算是有效故事，“開發一個某某函數”（即使這個函數很有客戶價值）等均不算是故事；
多個過程不能合并為一個故事，比如“……，可以對故事進行增刪改查，……”。這樣可以防止過于粗糙的功能描述阻礙用戶價值的有效傳達，也利于合理計算用戶故事的數量。

MVC與用戶故事

第二個是MVC中對Controller和Action的定義。
Controller-Action樹是另一個潛在的史詩-故事樹的原型。
FPA和MVC居然能扯上關系？是的，上面提到的FPA中的內部邏輯文件，與MVC中的Controller有很好的對應（有的不能），而基本過程（輸入輸出查詢）與MVC中Controller的Action有很好的對應關系。比如如果有一個“UserStoriesController”（UserStories可以看作ILF），就會有一堆Create / Edit / Delete / Index……這就是4個基本過程（從前面“增加一個用戶故事”的例子可以看出，Create + [HttpPost]Create兩者一起才組成一個完整的基本過程）。
基本過程對應Action還是好理解的，但為何對應內部邏輯文件的是Controller而非Model？因為Controller是面向用戶寫的，而Model是面向實現技術的。何以見得？因為如果要訪問“增加一個用戶故事”，我們會輸入UserStoriesCreate，而其中可能會用到幾個Model：UserStories, Statuses, Priorities, Owners……用戶無法直接訪問Model，但可以直接訪問Controller。所以MVC的Model更像是DataModel，而Controller才是BusinessModel（有時不是），是“一組邏輯上的數據，用戶能夠理解和識別它”。

使用MVC中的Controller-Action樹作為史詩-故事樹的顆粒度原型有以下幾個好處：
Action是一類特殊的面向用戶業務和價值的函數，還是客戶可以直接感知并調用的函數；
Action的數量多，客戶可感知的功能一般也就多（相對于一般函數）；
Action是一類可單獨演示、單獨測試的函數，很適合作為故事使用；
Action很容易被程序員所理解，使用MVC的程序員更容易回答“你們的軟件有多少真正的用戶故事？”。

使用MVC中的Controller-Action樹作為史詩-故事樹的顆粒度原型，將作出以下約束：
多個過程不能合并到一個故事中（與前面FPA的觀點相同），因為不能用一個Action實現“增刪改查”。
Controller的Action將只包含有意義的用戶故事。有些程序員為了調用方便，會在Controller里定義一些不期待用戶直接調用的函數（尤其是直接定義在controller.cs中），應挪到Model中實現。

限制與風險

實際上在FPA中，文件與基本過程并非樹形結構，一個基本過程完全可能訪問多個文件；而在史詩-故事樹中，很多故事其實也是跨史詩的；只有MVC強制Action必須屬于一個Controller，不過“故事結構 Category-Story”到底應該放在CategoriesController中還是UserStoriesController中？這是一個兩難的選擇。
此外FPA中整體認為Options、Config這類內容均非要被“賣給”客戶的功能，因此不計算內部文件；但在開發中，卻需要為其設計Controller來完成工作，兩者立足點不同，處理問題會有所差異。
就像明明分子-原子-中子-質子-電子就可以組成世界了，但上帝還是“額外”設計了幾百種夸克一樣，關于史詩-故事的正確結構應該如何，與增強、缺陷、技術債務、重構的有機關系應該如何，這些內容的合理展現形式應該如何，還需要同行們更多的討論。

后語：殊途同歸的各流派思想

FPA，大致產生于1970年左右，由IBM的開發人員為了處理銀行業務而產生，其目的是以一種客戶可以理解的方式來描述和計數產品功能或項目需求。
MVC，大致產生于？？？？左右，由一些軟件開發者為了改善軟件結構而產生，其目的是通過分離客戶業務與實現技術，增強在客戶業務變化時軟件的可重用性、可維護性。
敏捷開發，大致產生于1998年左右，由一群資深開發人員為了改善繁重的開發過程而產生，其目的是減少不體現客戶價值的中間環節和文檔，快速適應需求變更，追求客戶價值最大化。
但最后居然大致歸于：

內部文件 ≈ Controller ≈ 史詩
基本過程 ≈ Action ≈ 故事

世界是沒有銀彈的，為了不同的目的不同的人發明了不同的方法，也遺留下不同的懸而未決的問題，只有各種方法互相包容借鑒，才可能發明出更加完善的解決方案。