摘录InfoQ上敏捷开发中用户故事相关的内容

最近我们进行敏捷开发模式试点，对于“用户故事”这一环节不够熟练。由于之前关注InfoQ比较多，把里面相关的内容进行搜集和整理。

用例还是用户故事？    http://www.infoq.com/cn/news/2008/08/use-case-or-user-story

每一个用户故事都包括三方面：

1. 写下故事描述，用作计划和提示
2. 故事的对话为故事细节
3. 以测试作为细节的记录，用来判断故事是否完成实现

1. 用户故事和Backlog上的项目不能提供设计师工作所需要的内容脉络——用户在做什么时候情况下做这事情，这行动的内容前文后理，以及在这一刻的高层目标。
2. 用户故事和Backlog上的项目不能提供项目团队所需要的“完整性”——我发现开发队伍对项目估算的故事点随著工作开始以后不断增加，犹如无止境的一样。开发人员及项目赞助人也为此感到同样的沮丧。到底项目确确实实有多大呢？
3. 跟完整性有关的是，用户故事和Backlog上的项目不能提供一个合适的机制来考虑到未来工作的困难程度（原则上他们可以, 只是实际上他们不行）——我不断收到这样的投诉，「我们问客户 (产品负责人)一条问题，他/她用上两星期时间才回覆我们。我们找错了人吗？」不是，他们没找错人，他们是过程出问题——有些问题需要长时间研究，因为不同部门和用户组要找出什么是正确，平衡各方需要的答案。分析员看著用例中一系列的伸延的形势可以找出那一个较容易，那一个较困难，再进一步进行相关的研 究。用户故事和 Backlog 项目未能及时达到适合作出来那考虑的粒度——伸延的形势通常要在Sprint中才能观察到，这已经太迟。

Scott Ambler 曾经在 <Artifacts for Agile Modeling> 指出两者的分别：

工具	通常应用	什么时候保存
用例	1. 主要使用需求综述 2. 分析现有系统使用需求	使用需求综述
用户故事	1. 探索用户需求 2. 与项目参与者对话的提示	功能实现后扔掉

很明显两者的使用情况和目的都很不同。甚至有需要下，两者可共同使用及存在。这就不存在到底是那个比较好的问题，亦不应该单靠一些报告说那个比那个好就麻木 跟从。重要的是如何更适合当前的情况，这包括项目上的需要，也包括团队的能力。长远来说，是让团队更敏捷。

如何切分用户故事  http://www.infoq.com/cn/news/2011/04/how-to-split-user-stories

 Rachel Davies建议对每个用户故事都要进行切分，从而让产出的软件：

1. 能够工作
2. 交付价值
3. 能有效地得到用户的反馈

Richard Lawrence提供了以下技术，他认为在切分大型用户故事时它们会很有用：

1. 根据工作流程的步骤来切分故事——可能是把简单的首尾循环的用例作为一个故事，然后让工作流中的其它步骤作为单独的故事。
2. 切分故事，让业务规则中的每种变化都是其自身的故事。
3. 把故事切分为“实现第一个[X]”，然后“实现其它[X]”。 当实现第一个[X]的时候所要付出的努力要比实现之后的所有[X]所要付出的都大时，就可以应用这种方法。
4. 当面对复杂故事的时候，把故事最简单的版本切分为单独的故事。
5. 通过故事所操作的数据类型来切分。
6. 通过找到简单数据输入方法和更复杂方法之间的区别来切分故事。
7. 把对当前故事的性能的考虑转移到一个或多个新故事中。
8. 按照创建-读取-更新-删除（CRUD）来切分故事。
9. 最后一种方法，创建一个spike故事，从而描述出如何实现特性。

Rachel Davies提供了关于如何根据输入/输出的数据来切分故事的细节：

• 你可以为每个输入页面创建故事。
• 你可以为输入页面每个可用的元素创建故事。
• 你可以创建简单的（不是很漂亮的）UI。
• 你可以创建一个命令行界面。

此外，Bob Hartman为切分故事提供了以下技术：

• 在涉及到多个角色的故事中，根据角色来对其进行切分。
• 切分故事，使得高风险的部分和低风险的部分分离。
• 切分故事，从而使能够在每个故事上工作的开发者数量最大化。
• 切分故事以有助于测试。

ThoughtWorks咨询师给了我们一些建议：测试驱动的方式，即假定开发将一个“大的用户故事”什么功能都没有做就交给测试人员，测试人员如何发现Bug？将假想的Bug按照顺序切分，就可以得到一个个细分的用户故事。咨询师给出了另一种切分方式：按照流程图中的步骤和参与的角色，以“端到端可交付”的思想，按照流程分支进行划分。比如，条件为真的分支及其后续的步骤划分为一个小的故事，条件为假的分支及其后续步骤划分成另一个小的故事，依次切分，直到满足要求为止。

用故事图为用户故事提供上下文  http://www.infoq.com/cn/news/2009/03/story-map

Mike Cohn把这个叫做“叙事诗”（我记得有的资料上叫做“史诗故事”，英文好像是 Epic，Cheny兄弟的《火星人敏捷开发手册》上提到过）。Jeff把这些当做故事图的骨架。它们从更高的层次上描述了用户需要系统帮助他做的每一件事。这些活动在卡片上记录下来，按照自然发生的顺序从左到 右排列。Jeff建议说，可以假设你要给一个不熟悉系统的人讲述业务流程，你描述这个流程的顺序就是活动排列的顺序。

在每个活动下方放着相关的用户故事，这里故事是从上到下按照优先级高低排列的。于是骨架上长出了肉。每个故事都跟一个用户活动相关联，而且都有个优 先级。在故事图上从左到右画一道水平线，发布计划就出来了。线上方的故事会包含在发布中，下面的就不在。我们可以用这种方式一次规划多个发布，把图就隔成 了多个“泳道”。

正确设定用户故事的大小 http://www.infoq.com/cn/news/2008/02/size-user-stories

用Bill Wake发明的助记词来形容就是，我们为优秀的故事投入时间和精力（INVEST）：它们是独立的（Independent），可以磋商的（Negotiable），有价值的（Valuable），可以估算的（Estimable），短小（Small）而且可以测试（Testable）。

故事离得越远，细节就需要的越少。随着开发的深入，细节逐渐加强。

确定非功能需求 http://www.infoq.com/cn/news/2011/07/nailing-quality-requirements

非功能需求一般和系统的状态有关而与系统需要提供的功能无关。通常是系统的“ ilities”功能，比如可扩展性（scalability）、互操作性（interoperability）、可维护性（maintainability）、移植性（portability）、性能和安全性都包括在此类。敏捷团队经常纠结于定义和估算项目的非功能需求。

Mike Cohn建议几乎所有的非功能需求都能以用户故事表述。而Jason建议不要试图在用户故事级别记录非功能需求，团队应该把它们作为（项目）大图景的一部分，他提到“我喜欢把这些非功能需求（NFR）用户故事写在墙上并在工作区都能看到，这样可以提醒团队在给出估算时考虑这些约束的因素”。

我们试点项目中，Thoughtworks的咨询师将和用户价值相关的需求用浅绿色的卡片来进行标记，称之为“用户故事卡片”。而将非功能性需求，比如持续集成服务器的搭建、网络环境的准备等工作用白色的卡片来标记，称之为“技术卡片”，其中可以包括一些预研性工作。蓝色卡片作为“故障卡”，也就是记载Bug的卡片，还有一些其他颜色的卡片。