用户故事和MVC没有关系，因为MVC是实现方法，因此在思考用户故事的时候，不要一下就想到实现方法，很容易把故事写坏。

但是MVC和用户故事有很大的关系，如果用户故事写好了，做MVC的时候，一定要记得参考用户故事。

本人在C++的年代用过MVC，但那个时候MVC还只是一种编程思想，说用了也行，说没用也行。但到了C#之后，就出现了正牌的自称是MVC的东西（现在最新版本是MVC3），本人也在用。Java世界也有MVC的概念，但是没有见识过，下文中所描述的MVC，若没有特殊说明，均指Asp.net MVC；但相信对Java中的MVC也有借鉴意义。

利用MVC实现用户故事的技法

如果您已经认可之六中产生用户故事的方法，那么也就得到了这样的一个用户故事树，右边则是为其量身定做的Controller-Action（来自实际项目）：

 

注意看每个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://cheny.blog.51cto.com/3988930/1100162 样式。

所以如果已经按照之六中提到的数据-操作方法来组织史诗-故事结构了，而且又在使用MVC,则非常推荐编程时将其继续映射到Controller-Action中。

可能细心的读者已经注意到本文图中有些故事后面有个链接符号，那个正是我们在已经实现了的即金色的故事的后面，加上了其超链接（全部是/Controller/Action，一一对应，非常舒服）。这相当于一个Action写好了，一个故事（偶然情况是多个）就正好也完了；而测试人员就可以点击那个链接去到Action测试。他测试完了Action，就能说故事被测试完了（而不只是Action被测试完了）。

以这种方式来对应用户故事和开发内容，产品经理和开发人员很容易沟通，因此非常推荐使用。

 

用户故事 vs. FPA功能点分析法 vs. MVC

☺ 功能点分析法（FPA）、敏捷开发用户故事、Asp.net MVC在一定程度上具有相同的目的：作为用户需求与开发人员工作的桥梁，只是侧重点有所不同。因此若能将它们联合应用，就可能用一种组织方式贯穿性地管理估算、需求管理、架构设计三者。

完整地表述三者的关系，大致如下：

 用户故事FPAMVC
数据史诗故事

ILF内部逻辑文件

EIF外部接口文件

Controller
操作普通故事（功能）

EI外部输入

EO外部输出

EQ外部查询

Action