用户故事与需求

Question

“用户故事”在较高的级别捕捉用户希望对系统所做的事情。据我所知，用户故事将进一步推动一些低水平的要求。用户故事是否与系统的高层次要求相同？

Answer 1

老实说，在投入敏捷开发将近两年的时间后，我仍然认为“用户故事”只是“功能需求”的一个花哨术语。

这在表面上是不同的，例如，它总是采用某种形式(“作为X，我想要Y以便Z.”)，但是关键的元素--识别涉众和理论基础--也是写得很好的功能需求所固有的。写一个糟糕的用户故事和编写一个糟糕的需求一样容易(“就像我们公司的名称一样，我想要模糊特征，这样我就可以做一些显然是我工作的一部分，比如“多卖给顾客”了”)。

在我的经验中，用户故事几乎从来没有捕捉到像性能和安全性这样的非功能性需求。这些类型的需求很难正确地编写，用户故事的格式对捕获它们来说也不是很好，因为它们更多地是关于一般产品质量和减轻(但不是消除)风险，而不是满足特定用户的需求。

所以，我真的认为用户故事是需求的一个子集，有一个特定的公式，并且仍然可以交替使用这些术语。

用户故事相对于需求有一个主要的优势，那就是“需求”一词意味着在通常需要的地方需要一个特性。理论上，任何版本都可以对用户故事进行排序和编排，而需求似乎是每个版本的先决条件。

当然，要使上述区别变得重要，您的客户和/或高级管理人员必须接受它；如果您将30个用户故事组合成一个必须同时完成的“项目”，这对您没有任何好处。在这种情况下，您最好将它们称为“需求”，因为它们实际上是必需的。

Answer 2

罗恩·杰弗里斯( Ron )很久以前就写过3Cs的用户故事(http://xprogramming.com/articles/expcardconversationconfirmation/)，重点放在卡片(简短的描述)、客户和送货团队之间的对话(一旦用户故事变得可行时)，以及在对话之后对一个故事的一致确认。

从本质上讲，在对话之前，用户故事只是计划好的范围--关于我们可能做什么的粗略想法。谈话结束后，你应该有一个方法来确认故事是完整的。因此，取决于你在这个时间线上看故事的时间，一个故事可能只是一个关于范围的宽泛的概念，或者是一个详细的要求。

如今，“用户故事”的含义似乎缩小到了Jeffries‘s3CS的“卡片”部分。在这种情况下，用户故事不是一项要求，而是承诺举行一次关于需求的对话。

你可以在c2 wiki (http://xp.c2.com/UserStory.html)上找到大量关于用户故事的智慧金块。

Answer 3

对我来说，用户故事的一个关键要素是它捕捉用户使用系统的原因和方式。它特别有用，因为它没有详细说明系统如何交付所需的功能。当需要用户界面和可用性测试时，用户故事可能是最重要的文档。

当然，您可以让selenium验证HTML中是否存在某些节点，或者截取屏幕快照，或者验证某些像素是否在您希望的位置。但是，如果有误导性文本，或者不清楚用户应该如何使用系统，或者用户很难理解如何实现他们的目标，那么突然之间，您就没有了一个完整的系统。现在需要培训才能使用该系统。根据用户场景检查已完成的系统是手动测试的重要组成部分。

在用户故事/场景中有一个思想集合，它应该会影响到有关实现的许多详细的设计决策。除非开发人员直接与用户交谈或观看他们使用系统，否则用户场景可能是唯一允许他们理解用户需求的链接。

最后，它们允许业务人员指定他们需要什么，而不建议应该如何实现这一点。描述解决方案要比描述需求容易得多，并且用户场景提供了一个框架来描述需求，而不需要提出特定的解决方案。我所听到的最常见的业务需求是，“我希望它像Excel一样，但在网络上”，这从来都不是他们真正需要的。

因此，我想说，一个好的故事不应包括任何具体的细节，如何实施该制度。应该说，“每月一次，系统A需要更新来自系统B的任何新数据。这些数据可能需要修改。客户端有输入无效数据的历史，并且在数周内没有意识到问题。”它不应该说，“系统必须每月至少接受一次latin1 CSV文件，如果第3列不是数字，则抛出NumberFormatException。”你看到区别了吗？该场景描述的是需求，而不是任何特定的解决方案。然后，在测试中，返回到场景，以确保解决方案符合需要。需求可能将某些需求与某些解决方案相结合，甚至完全集中在解决方案上。