现在的位置: 首页 > 综合 > 正文

[转帖]敏捷开发，Use Case 还是 User Story——本人感觉像是“用户需求”和“需求规格说明书”的区别

2012年02月16日 ⁄ 综合 ⁄ 共 2409字 ⁄ 字号小中大 ⁄ 评论关闭

[转帖]敏捷开发，Use Case 还是 User Story

2009-9-24

敏捷开发，Use Case 还是 User Story

Murali Krishna告诉我们：

未能彻底明白用户故事的性质往往都是未能有效地转变到敏捷开发的重大问题。用户故事最重要的特点在於每一个用户故事都是一个“可独立分配”的需求（特徵）单位。要达到“可独立分配”，就要从“用户”如何使用系统来表达用户故事。这样才让你实现到一个能让用户交流，端到端（用户界面到后端）的功能单位。

Murali想的跟众多敏捷社区的人仕一样——用户故事是最好的选择，并引用Mike Cohn写的一篇文章Advantages of User Stories for Requirements。文中指出：

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

2. 写下故事描述，用作计划和提示

3. 故事的对话为故事细节

以测试作为细节的记录，用来判断故事是否完成实现

如此看来使用用户故事比较好。但又是否如此呢? Alistair Cockburn，另一位敏捷社区内的名家，仍然使用用例，并从他过往使用用户故事的经验中指出所遇到的问题：

1. 用户故事和Backlog上的项目不能提供设计师工作所需要的内容脉络——用户在做什么时候情况下做这事情，这行动的内容前文后理，以及在这一刻的高层目标。

2. 用户故事和Backlog上的项目不能提供项目团队所需要的“完整性”——我发现开发队伍对项目估算的故事点随著工作开始以后不断增加，犹如无止境的一样。开发人员及项目赞助人也为此感到同样的沮丧。到底项目确确实实有多大呢？

3. 跟完整性有关的是，用户故事和Backlog上的项目不能提供一个合适的机制来考虑到未来工作的困难程度（原则上他们可以, 只是实际上他们不行）——我不断收到这样的投诉，「我们问客户 (产品负责人)一条问题，他/她用上两星期时间才回覆我们。我们找错了人吗？」不是，他们没找错人，他们是过程出问题——有些问题需要长时间研究，因为不同部门和用户组要找出什么是正确，平衡各方需要的答案。分析员看著用例中一系列的伸延的形势可以找出那一个较容易，那一个较困难，再进一步进行相关的研究。用户故事和 Backlog 项目未能及时达到适合作出来那考虑的粒度——伸延的形势通常要在Sprint中才能观察到，这已经太迟。

Alistair说了「为何不使用用户故事」后，进一步集中讨论「为什么使用用例」。

1. 目标名称列表将系统对业务和用户的贡献进行了最简短的概括，提供给行政人员。这也提供了一个项目计划框架，可用作建立初始优先次序、估计、团队分配，以及时间的选择。这也是“完整性”的第一部份。

2. 每个用例的主要成功场景能提供各参与者有关系统基本功能的协议，有时候更为重要的是，它可以告诉人们，哪些事情它不能做。给每一项需求提供脉络，这是其他工具很难办到的。

3. 每个用例的扩展条件可以给需求分析员提供一个框架，可以找出那些可能会用上 80% 的开发时间成本的烦琐细微之处。它提供一个考虑未来的机制，从而客户、产品负责人、业务分析员可以察觉到一些可能用上时间研究的问题。这些问题应优先处理，让开发团队开始工作时这些资料也同时准备好。这用例伸延形势分析就是 "完整性" 的第二部份。

4. 用例扩展场景提供一些仔细而然往往也是难处理的细节，像编程员常常问到：「你想我如何处理这情况？」（通常回覆却是：「我不知道, 我未想过会有这情况。」）换言之，这是一个思考、文档纪录的框架，跟“如果……那么……否则”的情况作配对，帮助编程员思考不同的问题。分别在於这是在研究阶段进行，不是到要开始编程时才进行。

5. 整套用例系列反映出研究人员有详细思考不同用户需要，不同用户在这系统上使用目的，以及一些业务上的差异。这是“完整性”的最后部份。（的确如是，我曾跟客户详细讨论长达 240 个用例，到最后，我去问她：「这是全部了吗？」她确认了。我们架建这系统，付运，收到应得的费用，而十年后这系统仍在使用。）

一如很多人所料，这回事不是黑白分明。我们该如何做好？我们现时在做的到底有用么？只有一个正确方法呢，还是有两个不同的正确方法呢？或者视乎实际情况而定？会不会是有些情况下用用例较好，而有些情况下用用户故事较好呢？还是其实没太大分别呢——像用例中（或许）包含多个用户故事而该用例因为一个用户情节内外都貌似用户故事呢）

译者附注：

用户故事好还是用例好的问题，其实不像作者前面提到用户故事为大多数偏爱使用的工具，像 ICONIX、FDD、OpenUP都很依赖或者支持用例的使用，不过明白两者分别极为重要。知道分别才可以作出合适的决定。 Scott Ambler 曾经在指出两者的分别：

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