关于用户故事这件事

呵呵，当我们尽可能的去容纳不同来源的需求时，就必然处于一个产生矛盾的环境中。
每个具体的用户代表往往都只代表了客户一部分的利益，而这些利益之间的相互冲突往往会体现在很微小的设计细节中，包括一个字段是必需还是非必需，会话超时是30分钟还是2小时……

clamp兄可以看看gigix翻译的《与熊共舞》，其中有一章说到客户团队的，当然那本书里面没有提客户团队这个名词。
书中说客户（真实的客户代表）所能做到的极限是评估产品每个组成部分的价值。评价价值是极限，客户不可能作模块优先级评估、日程安排等工作，开发计划更不可能由客户安排。这是由于关注点不同造成的。客户的关注点决定了客户对能产生直接价值的部分最感兴趣，但一个软件系统中有相当一部分功能属于支撑性功能，例如软件的基础架构（这东西只对乙方有直接价值）、一些基础参数配置模块，这些东西，你对客户说，他可能都不理解，也不关心，但它们对软件开发就很重要。

比较现实的做法是：客户评估模块的价值，然后由乙方结合自己的情况（技术力量、软件实现的先后依赖关系，甚至可能还包括公司的产品策略）来进一步安排开发、提交、验收计划。这个过程是迭代进行的。

我想这是对“客户团队”所起作用较公正的定义：客户评估模块的价值，其他由乙方决定。整个软件开发活动中，乙方起主导作用，甲方予以必要的配合。

以前一切乙方说的算，现在好像突然要一切客户说的算了，有点矫枉过正。

xp中的好多实践一定要结合自己的实际情况予以酌情修正，像客户团队、简单设计、不断重构、结对编程这几个，如果不加以localization而直接照搬，肯定死得很惨。

如果有两个用户代表来评估某个功能，一个说这个功能优先级很高，一个说这个功能优先级很低，怎么办？

说实话，不知道，呵呵。
我们没有碰到过这样的情形，模块价值评估是非常重要的事情，需要双方的项目经理各带上几个懂具体实践的手下，在会议桌上正式地讨论。很明显讨论之前客户方面肯定有他们的想法，而且已经内部统一了。

clamp兄说的情形，是不是在私下里说的。我很难想象客户会在会议桌上一会说这个重要，一会说那个重要。这说明客户方面有内部矛盾，具体怎么办，要看具体情况了，可能是找客户方面的高层？不清楚，没有亲历。

另外每次讨论都有备忘录的，难道客户方面的人完全不顾及这个备忘录么？那客户方面内部矛盾可真不小 

这正是利用矛盾的好时机，让他们达成一致，否则，不进行开发。

clamp兄说说你的经验吧，真遇到这种客户时你们是怎么做的。

正统做法是找他们的领导，然后由领导做出决策，把矛盾消除后进行开发。

但是这样做有几个问题：
1、进度。领导不总是有空的，一周的延误是很正常的，所以除非极重大的问题，一般还是不要麻烦领导的好。（有些情况是两个部门的用户代表，因此他们的领导还是两个人，要到更高层，那就更麻烦了，而且通常更高层不会理睬这种‘小’问题）

2、和用户代表的关系。把问题贸然提交到用户领导，往往是把两个用户代表都得罪了，因为用户领导会认为他们办事不力。

根据我个人的经验，有以下几种措施可以采取，不过每种措施都是有一定风险或者成本的：
1、直接“站队”，但是避免冲突。也就是只听取一方意见，对于另一方意见置之不理，但是尽量不在会议上明确表态，只是私下和其中一方沟通好，然后交付开发执行。这样做就是每次公开会议都没有什么明确结论，但是进度仍然可以保证。
目的是在验收之前把另一方的权力直接抹掉（到了合适的时机，要求对方领导把不合作的那个人换掉）。
风险高，成本低。

2、技术中立。通过在程序中设置开关参数的办法，避开这个矛盾，把操作权给用户，对于类似必填/非必填这种矛盾比较有效。
风险低，设计成本会加大。

3、搁置。大家屏住，客户没结果就不动，做好项目拖延的准备。当然可以把无矛盾的一些功能先做。
成本低，商务目标可能会完不成，需要得到己方领导的认同。

其他还有一些非正规的手法，我就不多说了

其实“用户故事”，重点是故事，而不是用户，开发人员的交流，一样可以用故事来解决。

故事的好处比其用例，最根本的特征就是比较完整，一般跨越了多个用例，然后有一个模拟情景，让人可以比较有趣味的读完，读完对某个模块的功能有完整的了解，做功能测试也就心里有谱，可以提前开始，而不是象用例一样，枯燥难读，边看边打哈欠。

但是它不要求面面俱到，要突出关键和重点流程，细节方面，我倒是觉得可以使用用例来补偿，而不是说写小的用户故事，那样就没什么意义和趣味了。

用户故事强调“用户”是为了，体现用户/客户价值。所有敏捷开发都遵循围绕客户价值，构建有用软件的理念。

用户故事的好处不仅仅是能表达跨越多个用例的概念，而且也可以表达某个用例中的部分概念。
实际上，用户故事的一大好处就是任意粗细的粒度，和任意多的层次。
这样就可以很方便的组织需求。
因为用户故事可以是任意粒度，所以有时候你会发现它比用例大，甚至比前景里面的特性大，这样就能够更宏观的掌握概览。有时它又比用例小，以保证在迭代实现中能够评估。

粗：对于宽带上网系统,可以通过一个故事来表达“用户能通过宽带上网”。这是最高层的“目标故事”。

细：“用户能够改变付费方式为现金支付”

能够评估的用户故事，细节不需要书面补充（象用例那样），通过交谈能够传递更多的信息，通过验收测试，记录这些细节的要点。
如果感觉用户故事没有意义，那说明它确实太小了，需要组合成更大的故事。