作者：陳勇

出處：blog.csdn.net/cheny_com

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

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

其實需求顆粒度的問題由來已久，即使是在傳統開發中，也沒有提及在需求分析階段應該把需求做到什麼顆粒度才可以開工。所以在下面這些分析之後會發現，其實即使反推到傳統開發中，下面提及的方法也依然有效。

為何要對使用者故事做一個顆粒度約束呢？

筆者在開發實踐中發現，如果大小不一的“使用者故事”堆積在一起，很難看出一個產品到底實現了哪些功能（或一個專案到底有哪些需求）。如果回溯到敏捷開發的源頭就會發現，由於敏捷開發中設定使用者故事是為了描述開發任務（儘管是從客戶價值角度）而非產品功能或專案需求，因此並沒有區分使用者和開發人員到底分別看到什麼。

其實各種“使用者故事”中，大致可以分為史詩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是面向實現技術的。何以見得？因為如果要訪問“增加一個使用者故事”，我們會輸入/UserStories/Create，而其中可能會用到幾個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 ≈ 故事

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

點選下載免費的敏捷開發教材：《火星人敏捷開發手冊》