敏捷开发用户故事系列之七：用户故事与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 |
点击下载免费的敏捷开发教材：《火星人敏捷开发手册》
