【在线研讨-现场文字】《敏捷开发用户故事分类与组织结构（二期-2）》2012-07-03...

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

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

非功能性需求的用户故事描述（增强，重构）

陈勇-创业-北京(139107533)13:14:08
基于这个出发点，我们就可以看看另外的几种”细枝末节“的故事怎么写了。
比如这个增强：突出显示本次/上次/下次意向表
增强是说：一个产品经理做计划的时候，如果能同时看到本次/上次/下次迭代的内容，就能更好地做出计划。而不是只计划这次迭代有什么内容。
所以，我们决定在界面上做一个增强，显示出本次/上次/下次的计划让他参考。
先不管怎么个显示法，大家认为应该怎么写比较好？
这个故事，无法直接套用”作为……可以……以便……“，但如果不这么写，怎么写才能突出其价值呢？（可以自己创造语法）
这个是实际的写法：突出显示本次/上次/下次意向表
–实现后，作为一个产品经理，可以在查看意向表时，突出地看到本次和上次迭代的意向表，以便连贯地思考本次迭代的需求规划。

陈勇-创业-北京(139107533)13:19:15
早期我们的增强不是这么写的，都是每个有每个的写法，但后期的，就都有语法了。
这个 增强的语法：
–实现后，作为一个……（角色），可以在……（被增强的以前的功能）时，……（增强的功能），以便……（增强后的价值）。
–实现后，作为一个产品经理，可以在查看意向表时，突出地看到本次和上次迭代的意向表，以便连贯地思考本次迭代的需求规划。
为什么要费劲造个语法呢？其实好处很显然：它 迫使每个产品经理或程序员在做增强的时候，要思考用户故事的实际价值，乃至能达到文字化的程度，才开始干活。

陈勇-创业-北京(139107533)13:22:39
下面是另外一些语法：
重构：重构界面及ViewModel
–实现前，原来的中间为树两侧为迭代的展示方式较为占用空间，树的高度太大导致难以完整看到；实现后，以故事树为主体配合左侧的当前迭代故事，查看和操作更加快捷。
重构语法是：实现前，……（业务上的困难）；实现后，……（业务上的改进）。
注意这个很奇怪，一般认为重构，是一件技术的事情，很难描述出来”用户价值“的，因为用户不懂技术，其实不然。
有一次去金山推广敏捷，有个人问：“如果一个PO（他们叫策划）不理解一个重构的价值，而这个重构又很重要，该怎么办？”
我还没回答，他们的项目经理（现在是分公司的副总了）很厉害，他说：
“一个重构都说不明白对用户的价值，为什么要做？如果对用户有价值，为什么又会说不明白？”
l这个话很好，其实， 即使像性能增强、技术重构之类的，都应该面向用户价值来描述，而不能只在技术层面描述。
这个是我们总结的一个重要概念。

后面发现，“增强”未必是针对业务操作的，也可能直接针对业务数据，比如重新改变了数据库表，使得整个业务数据 增加了信息量，若干个相关的业务操作都得到增强。
下面是一个例子，其增强的是“意向表”，而不是“查看意向表”。
支持多产品
–实现后，将支持多个产品的讲解，并能查看多个产品的工作量、是否都讲完等信息。