按故事编写需求规范是个好主意吗？

目前，我们在当前项目中使用的是敏捷方法，并且我们有很多类似的故事：

• 作为助理，我想向客户退款，以便他们可以在要求时获得一些退款

• 作为客户，我想付款以购买商品。

到目前为止，我们的工作方式是在每个冲刺中挑选最重要的故事，并将其详细阐述为许多正式的需求规格（我们将一些在相同规格中相似的故事归为一组）。根据故事的不同，它可能只是屏幕上的按钮或整个工作流程。

现在的问题是，因为故事太多，对于系统中与故事相关的任何部分，现在还不清楚。

它可以在开发人员时发挥作用，开发人员的每一次冲刺都只是获得一个规范，概述他们需要做的事情和需要进行的更改。但是就维护此故事列表和进行测试而言，它开始变得很难跟踪错误，并且通常只是维护规范，因为屏幕上的一项功能可能已经记录在许多不同的地方按故事拆分。

根据故事写规范是个好主意吗？我们写故事的方式有误吗？

这可能会引起争议，但是可以解决！

我们已经开发了一个实时系统，我的一位前任老板建议我们做敏捷！真的很容易赢得管理。但是，说起来容易做起来难。

故事的概念很好-但是要非常先行，它很模糊。真的是一个故事吗？真正的问题是，使用故事alone（以及用例的基本原理也是如此）存在多个问题-如下所示：

1. 需求不能脱离上下文（除非您多次重复执行总重复）。有假设，背景知识和其他要求也与给定要求相关联；它们仅在上下文和特定顺序下才有意义。首先实施最重要的原则具有商业意义，但至少要归档时-收集它们时应从一开始就保持完整的引用。需求词本身很复杂，并不真正局限于用例/故事。确实，故事是可以执行的，但是存在一些可能无法执行的要求，例如性能，要满足的约束，业务规则等。

2. 需求的大小和数量必须适当， 否则您永远都不需要一个以上的大故事！到底是什么构成一个故事？

   • 这是一个完整的详细方案吗？（例如，一个故事，当ATM拒绝交易时）
   • 用户执行的是一组动作吗？（例如，有关提款的完整故事）
   • 还是用户界面中的一个屏幕？（例如，提款屏幕为全文）。
   • 如何用故事真正量化非常清晰的业务规则？ 老实说，可以是上述任何一种。关键是您要走多少密闭和细致是个人风格。如果有效-很好；

3. 领域知识确实是必需的！ 一个简单的例子，一位了解玻璃，钢和木材的各种特性的建筑师。这些知识并不是建筑物要求的一部分！同样，如果您正在编写银行软件，则有很多关于银行的概念。陈述它们，因为 Requirement本身使它变得难以处理，因为它没有告诉您软件应该做什么，而不是世界如何运转。故事是否包括此类领域的复杂性？还是将其排除在外？

4. 对世界建模是没有被完全支持的先决条件。
   关于建模的文献很多，其重点是仅仅了解背景是如何工作的。建模为需求明确含义奠定了坚实的基础；但是这样的事情应该是预先的。不幸的是，为了更快，更精简的交付，大多数敏捷实践都拒绝进行前期建模。但是当事情必须扩展时，我仍然认为这是一个主要的表演障碍。许多项目之所以成功，并不是因为建模无关紧要，而是经验丰富的工程师知道他们的头脑，不需要太多明确的指导。

所以来问你的问题：

根据故事写规范是个好主意吗？我们写故事的方式有误吗？

我认为用户故事确实具有价值，是客户给出的明确结论。但是，如果它们组织得不好并且细节不够（或含糊不清），那就有问题了。除非您具有更大的结构来积累更广泛的理解（领域知识）和范围（总规格）。用户故事仅适用于较大此类系统中的细分或元素。

PS：我对用例有确切的看法（如用椭圆形图所示），除非您将它们放在适当的上下文中和使用适当的粒度，否则它们不会发挥任何作用。（我称它们为无用的情况）。我发现使用例编写真正可扩展且有意义的唯一可靠来源是Cockburn 编写的有效用例。

> Writing specs by stories? a good idea?

是的，如果您可以管理故事的相互依赖性和优先级。

这是一篇有关故事地图的文章，可以帮助您订购和管理许多用户故事。

在撰写此答案时，我已经意识到这与测试无关，而与文档有关。您应该先阅读敏捷宣言：

[我们重视] 工作软件胜于完整的文档

因此，您应该使您的规范可执行，即将它们编写为一套全自动测试。

根据故事写规范是个好主意吗？

是的，恕我直言，是的。它被称为“行为驱动的开发”或“示例规范”。在红宝石中，有一个很棒的工具黄瓜可以帮上大忙。

现在的问题是，因为故事太多，对于系统中与故事相关的任何部分，现在还不清楚。

您为什么要弄清楚？我的意思是，您真的需要“测试/代码”可追溯性矩阵吗？将测试写为规范的优点是您不需要单独的“需求/测试”可追溯性，因为测试成为了要求。为了进行集成测试，您应该将软件视为一个整体，而不是单独的部分。

您可能需要使用覆盖率工具来查看是否存在“死”模块，即规范测试未涵盖的系统部分。但是您真的不应该在乎此特定代码对应什么规范。反之亦然：从特定的规范中，您应该知道系统的哪一部分对应于它。您不必担心规范中的某些重复。而且，如果将DRY原理应用于您的代码，将有数十个规范执行同一代码。

它可以在开发人员时发挥作用，开发人员的每一次冲刺都只是获得一个规范，概述他们需要做的事情和需要进行的更改。但是就维护此故事列表和进行测试而言，它开始变得很难跟踪错误，并且通常只是维护规范，因为屏幕上的一项功能可能已经记录在许多不同的地方按故事拆分。

数百个集成测试因关键模块中的一点改动而中断，这种情况并不少见。这就是单元测试的步骤。

您应该这样构造测试，以便可以判断特定测试是否满足高级别要求，或者仅满足其细微的细节。如果是后者，则应将此测试与集成测试套件分开。单元测试的目的是本地化错误。这样，如果您引入一个错误，将只有一个测试失败。

我们写故事的方式有误吗？

我认为，您只需要按用户（例如“客户”，“助手”）或功能/屏幕/工作流程（“购买”，“退款”）将故事组织成史诗。

同样，规范测试不能代替单元测试。阅读更多

您提到了一个问题以及解决问题的方式，但是您忘记提及一些规格和分组示例，以及它与产品开发方式的关系。

通过故事编写规范？一个好主意？

敏捷并不禁止它。在敏捷中，您可以做任何事情，以可持续的速度交付最大的业务价值。因此，如果编写规范是您需要提供更多业务价值的事情，那么绝对可以做到这一点。

您的示例显示了两个用户故事。它们可能与您的业务逻辑有某种联系，但这是非常常见的情况。

如果您需要为用户故事提供功能，则可以再次使用最适合您的内容，包括文档，一些图表或“规范”，但您必须做好准备，随着开发应用程序的复杂性增加，维护这些工件会花费更多。因此，在这种情况下，您必须回答的唯一问题是：如果我不使用我的规格，会花更多的钱吗？如果答案是肯定的，那么您选择了一个更好的选择。

对于团队规模较小的中小型项目而言，敏捷是最有效的方法，因为整个体系结构是作为团队中的默认知识共享的。在迭代计划期间，您将浏览您选择的故事，讨论对当前实现的影响，并编写一些完成故事所需的任务。在这种情况下，真正的文档将是测试套件，其中包含自动验收和集成/单元测试。一旦您的软件工程师或团队成长，隐性知识将不得不部分移至某些文档。

现在，这里是抽象的主要角色。您需要从相关角度看故事。收集陈述中的名词和动词并进行确认。您不能基于个人假设来建立模型。也请注意细节。

根据用户故事编写规范可能不准确。您需要挖掘额外的细节，有时会忽略不相关的细节。分析师确认后，应在模型完整且准确时编写规格。