敏捷开发用户故事系列之七：用户故事与MVC

用户故事和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://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在一定程度上具有相同的目的：作为用户需求与开发人员工作的桥梁，只是侧重点有所不同。因此若能将它们联合应用，就可能用一种组织方式贯穿性地管理估算、需求管理、架构设计三者。

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

敏捷开发用户故事系列之八：验收标准

要想不在评审会上得到“惊喜”，Product Owner最好提前约定好用户故事的验收标准，而且每个用户故事可能各不相同。

面向客户价值设定验收标准

简单说，就是客户看到说“完成了”，才算完成了。

从这一点上说，用户眼中的“可工作软件”和我们认为“可以运行，自动化测试了的，没有缺陷的”软件还是有差别的。用户拿到软件，是要使用从而获得价值的，这常常需要多个功能联合运行，前后数据完整一致才可以做到。在“敏捷产品管理”系列中，还会更加深入地探讨这个话题。

下面的例子，很好地表明了客户眼中的完成标准，它是EA（电子艺界，世界最大的游戏发行商和开发商之一）用于判断游戏中不同故事完成标准的。

S =Sufficient for feedback. “可获得反馈的”（第一次能看得见的）

Generally the firsttime something can be seen in software, however incomplete.

W=Working. “能运行的”（能用，但是艺术性欠佳的）

The functionality isbroadly in place but art work (e.g. graphical quality, UI) may be very lowfidelity or placeholder.

T=Testable. “可提交玩家测试的”（可以交给玩家而不会破绽百出的）

(by kids in ourcase). The software is sufficiently done to put it in front of people that havenot seen it before and for them to be able to use it with minimal intervention.

A=Alpha. “可提交Alpha测试的” （改改BUG就可以上线的）

Potentiallyshippable, likely needing some polish and bug fixing.

G=Great. “完美的”（可以上线而且估计反响强烈的）

Shippable and likelyto receive a great review score.

为什么要搞这么复杂呢？因为游戏中有些功能，在开发出来之前策划人员也说不明白怎样才是好，但又急于开发出来看看，因此会采用最低标准S，就是能用就行，不测试，不写文档，不做性能优化……而另外一些功能，则可能比较正式一些，比如需要给某些玩家看到的，就会选择T或A级别；而正式功能，则会选择G。

不同的公司，有不同的客户群，为了不同的目的，需要制定自己相应的完成标准。

客户价值与工程实践的映射

上面是一个完全面向客户价值编写的完成标准，看起来很好，但是实践起来开发人员很难把握。

其实，每个面向客户价值的标准，背后都有相应的工程标准。在熟悉之后，开发人员一望便知。比如下面是上述标准中S和W标准的工程实践描述：

W能运行的 =

编码完成 √

单元测试 √

手工功能测试 √

压力测试

可回归自动测试

使用手册

S可获得反馈的 =

编码完成 √

单元测试

手工功能测试

压力测试

可回归自动测试

使用手册

使用方法

上述面向价值的描述及其工程实践映射，不是在迭代计划会上现场想的，而是早就在项目之初就在项目甚至组织层面设置好了的。

在迭代计划会上，PO每讲完一个故事，都会在团队估算前指出故事完成的标准，这样团队就知道是不是要花费额外的测试、优化等工作量了。

不过，即使事先约好完成标准，若PO与开发组分开一个月，仍然可能得到一个”惊喜“。这就需要下篇提到的用户故事的开发与跟进。

敏捷开发用户故事系列之九：开发与跟进

产品负责人常常被描述成在计划会前准备好用户故事，在计划会上讲解并帮助开发团队估算后就万事大吉，只等月底接收“可工作软件”的样子，其实如果真的这样，很容易出问题。

需求精化

这是发生在迭代周期中间的常规活动，产品负责人会与团队密切接触（确切说如果能经常坐在一起更好），在每个故事开发的前夜或中间，将之前讲解过的用户故事更详细地描述一番（有时候是在看到开发一半的半成品后做一些细化或更正）。

一般认为产品负责人在开发的中间来打扰开发组工作是不令人欢迎的行为，那这两者之间到底区别何在呢？

在以后将会编写的一个《敏捷开发产品管理》系列中将会提到，产品负责人要做到“迭代期内无变更”，必须要做好长周期的研发管理，就是为每个版本每个迭代提前设定好目标。因此落实到具体迭代的时候，这个目标不是那么容易发生变化的，但“如何更好地达到这个目标”，则可能经常在变化。

需求精化的过程，就是产品负责人帮助团队更好地达到目标的过程。

“需求精化到底包含哪些活动？”确切说，只要把产品负责人和团队放在一起，什么事情都可能发生。

可能会对模糊的需求进行细化；可能会根据半成品做一些调整；可能给开发人员讲解一下用户背景……总之试一试，就知道了。

NEC的迭代开发中甚至有一个固定的时间（忘了是一个月中的第10天还是第20天），产品负责人会帮助全组对下一个迭代的故事进行一次提前通告，以帮助团队预测到以后发生的故事，从而略微地为未来做一些准备。这种准备既有提前了解业务的方面，也有潜在的在架构上为扩展做一些有限的准备。

跟进人，渐进评审

若开发组的人数众多，而产品负责人只有一个，他的工作会相当繁忙，顾此失彼。

跟进人制度是在产品负责人团队基础上建立起来的。所谓产品负责人团队，就是多个对产品了解的人组成一个团队，集体行使产品负责人的职责，典型的如软件或嵌入式产品研发中的产品总监-产品经理-产品专员团队，游戏团队中的主策划-策划组长-策划团队。

而跟进人，就是针对某个用户故事，指定相应的产品负责人团队的某个组员，来跟踪故事的开发进展。

跟进人最大的好处，是可以在用户故事一完成的时间点就进行评审、改进，防止了到最后却发现故事实现的不好，一则返工浪费时间，二则影响了上线日期（只能下个迭代修改）。

跟进人制度和渐进式评审在网络游戏的敏捷开发中非常普遍，原因是网游的策划人员比较多能完成跟进，而且对于“影响上线”比较敏感。

个人感觉跟进人制度和渐进式评审在普通研发中也应该推广，无论如何如果用户故事因为“只差一点，需要改进”而不能交付，要延期到下一迭代中，的确令人沮丧。

故事板安排技巧

故事板的一般概念就不多说了，无外乎几个栏目：待开发-开发中-待测试-测试中-待发布-发布之类的，大同小异。

一个技巧则是“开发中”这一列一定要窄，含义是不要同时开发多个故事，最好结束几个再开几个。目的是不要所有故事开始了却都没有结束，导致最后无法交付。

这也使得跟进人不会太忙乱于多个故事，可以一个一个介绍，一个一个评审。