敏捷開發日常跟進系列之五：使用者故事與MVC

這是敏捷開發日常跟進系列的第五篇。 （欄目目錄）

 

使用者故事和MVC沒有關係，因為MVC是實現方法，因此在思考使用者故事的時候，不要一下就想到實現方法，很容易把故事寫壞。

但是MVC和使用者故事有很大的關係，如果使用者故事寫好了，做MVC的時候，一定要記得參考使用者故事。

本人在C++的年代用過MVC，但那個時候MVC還只是一種編程思想，說用了也行，說沒用也行。但到了C#之後，就出現了正牌的自稱是MVC的東西（現在最新版本是MVC3），本人也在用。Java世界也有MVC的概念，但是沒有見識過，下文中所描述的MVC，若沒有特殊說明，均指Asp.net MVC；但相信對Java中的MVC也有借鑒意義。

利用MVC實現使用者故事的技法

如果您已經認可之六中產生使用者故事的方法，那麼也就得到了這樣的一個使用者故事樹，右邊則是為其量身定做的Controller-Action（來自實際項目）： 

======================================

下面是對應的Controller-Actions UsersController --Users/Index ----什麼也不是 --/Users/Details --/Users/User2Authorities --/Users/Users2Roles --/Users/Freeze --/Users/Edit --/Users/Delete --/Users/BatchCreate RolesController --Roles/Edit --Roles/Details --Roles/Delete --Roles/Index AuthoritesController --Authorities/URA --Authorities/Delete --什麼也不是 --Authorities/Index ----什麼也不是 --/Authorities/Authorities2Roles --/Authorities/URGA =============================================

注意看每個Controller實現了一個史詩故事（要管理的資料），每個Action則實現了一個（偶然多個）使用者故事（使用者的業務操作），有幾個值得注意的地方：

1. 一個Controller幾乎正好可以實現一個史詩故事

2. 一個Action因為正好是一個動詞，所以幾乎正好和一個使用者故事對應。

有兩個地方違反了，如“角色首頁（建立+查看）”和“許可權首頁（建立+查看）”，因為為了方便我們在兩個Index裡邊放了個建立用的TextBox，方便直接建立（因為角色和許可權都只有一個名字而已，所以覺得犯不上做個獨立頁面了）。

為了能記住這一點，我們在故事的縮寫名字上加了（XX+XX）的標記，為了日後能自動計數故事。

3. 使用者沒有“建立”故事，也沒有Users/Create，因為使用者只有兩種正常的建立方法：Register和BatchCreate，我們選擇了後者。因此既沒有“建立使用者”這個故事，也沒有“/Users/Create”這個Action。

4. 幾個綠色箭頭是“增強”類型的故事（詳見之五），它們正好也不對應Action。

 

上面提到的是我們實際的一種用法，未必是普適的，但在我們項目中非常適合，甚至應該稱為“舒服極了”。

這種史詩-故事與Controller-Action之間偶然的巧合，實際上背後有其必然性。

利用MVC實現使用者故事的心法

MVC以往研究的重點，是何為M，何為V，何為C，以及三者之間的關係。

我們在用了一段時間後，發現其中的每一個，都還有更深層次的理念在裡邊，這裡談的就是Controller及其Action。

在MVC三者呆在一起的時候，問：何為Controller？估計還是挺容易回答的。

但如果不提MV，直接問：何為一個Controller？何為一個Action？卻挺難回答的。

如果去一個非MVC的網站或軟體，最令人煩惱的，是網站的每個頁面未必有自己獨立的連結，比如逛了半天，頂上的連結一直是http://xxx.../login=xxxx，想為某個頁面加個收藏夾都不行。MVC在很大程度上解決了這個問題：要操作的資料是Controller，要做的操作是Action，而參數則是具體操作誰，比如/Users/Details?user=cheny或CSDN部落格上常見的：http://blog.csdn.net/cheny_com/article/details/6616794 樣式。

所以如果已經按照之六中提到的資料-操作方法來組織史詩-故事結構了，而且又在使用MVC,則非常推薦編程時將其繼續映射到Controller-Action中。

可能細心的讀者已經注意到本文圖中有些故事後面有個連結符號，那個正是我們在已經實現了的即金色的故事的後面，加上了其超連結（全部是/Controller/Action，一一對應，非常舒服）。這相當於一個Action寫好了，一個故事（偶然情況是多個）就正好也完了；而測試人員就可以點擊那個連結去到Action測試。他測試完了Action，就能說故事被測試完了（而不只是Action被測試完了）。

以這種方式來對應使用者故事和開發內容，產品經理和開發人員很容易溝通，因此非常推薦使用。

 

使用者故事 vs. FPA功能點分析法 vs. MVC

 功能點分析法（FPA）、敏捷開發使用者故事、Asp.net MVC在一定程度上具有相同的目的：作為使用者需求與開發人員工作的橋樑，只是側重點有所不同。因此若能將它們聯合應用，就可能用一種組織方式貫穿性地管理估算、需求管理、架構設計三者。

完整地表述三者的關係，大致如下：

	使用者故事	FPA	MVC
資料	史詩故事	ILF內部邏輯檔案 EIF外部介面檔案	Controller
操作	普通故事（功能）	EI外部輸入 EO外部輸出 EQ外部查詢	Action

 

 

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