【在线研讨】《敏捷开发用户故事分类与组织结构（三期-3）》

一期：活动描述，之一，之二，之三，之四，之五

二期：活动描述，之一，之二，之三，之四，之五，之六

三期：活动描述，之一，之二，之三，之四，之五

之三：用户故事树与MVC中Controller和Action的关系

陈勇-创业-北京(**9107533) 13:26:18
当然，只解决模块设计，还是不够的。不过，再仔细看看两张图：

代码图：

故事树：

对比上面最近的两张图
下图SprintCalendars = 上图SprintCalendarsController，下图Sprints = 上图SprintsController……
我们上次提到的那种“文件故事”，也就是用户可以理解的“业务数据”，其实和MVC里边的Controller可以很好地一一对应（并非完全如此）
这就大大简化了“一个系统里边，有哪些Controller？”这个设计问题。
再细看：

上图是用户故事的“业务数据-业务操作”对应关系

陈勇-创业-北京(**9107533) 13:31:28

而上图，则是用户故事的Controller（它复用了ItemsController，可以认为StroiesController = ItemsController）及其方法
上图查看所有故事 = 下图Index，上图查看用户故事详情 = 下图 Details……
下面还有很多函数没有展示出来，他们也是一一对应的。
这样就解决了：“我的Controller里边应该有多少个Action，分别是什么啊？”这个设计问题出。
所以，若用户故事树合理安排，则MVC常见的三个层次：Area-Controller-Action，可以直接借用用户故事的结构，而无需重新设计。这是MUP里边一个很重要的概念。 

 tinny-PM-深圳(**722310) 13:36:32
没太明白，如何解决确定有多少个action的问题。
是设计同学自行合并来解决的么？

陈勇-创业-北京(**9107533) 13:35:26
比如原来问：这个用户故事的代码在哪里？如果不靠脑子记，多半需要个什么跟踪矩阵。但现在基本上不需要了，按照用户故事的结构挖下去，直接可以找到。
这也是为什么我们现在在用户故事后面加上英文的原因，这个英文，就是对应的Areas/Controller/Action的位置。

比如下图中“编辑用户故事”，代码在哪里？

现在问题简单了，“编辑用户故事”，位于Products/Stories/Edit，代码自然就找到了。
@tinny：有多个个“业务操作”类型的用户故事，就有多少个Actoin 

又比如：

将分别对应 Stories/Index, Stories/Edit, Stories/ChangeType, Stories/ChangeStatus, Stoires/Hide....

有几个故事没写英文，原因是后来发现直接写在Title上不好，会导致某些用户故事名字太长还信息冗余，所以未来会做个字段，可以显示或不显示。