基于1-线性需求的BDD

Question

在我们的团队中，产品负责人只给我们一个1线的总结.然后，开发人员提出了一个PoC，产品所有者对其进行审查，并重复这个循环。

这里的挑战有两方面：

1. 时间:我们必须尽快创建PoCs，以便对它们进行审查。
2. 开发人员实际上正在定义产品的外观和感觉-很多UI PoC和一些控制器开发来支持它。但是BDD并没有渗透到产品设想的“创造性”过程中。通常，BDD要求您获取一个产品规范，然后使用Jasmine等对其进行编码。

请任何BDD专家提出一种将创造性思维过程与BDD相结合的方法吗？

Answer 1

忘掉"BDD的流行词“，让我们来谈谈我们在过去几十年里所称的”功能规范“。如果你认为你从你的PO得到的规格不够详细，自己写缺失的部分。这给你很大的空间进行创造性的讨论，在实际开始编写代码之前，但也会帮助你记住你在一周前所做的决定。它还可以帮助您规划您必须编写的测试。这也给您留出了一些空间来修复您可能在您的“详细规范”中检测到的错误或不一致之处，当您正在或实际实现相关特性时(可能首先使用一些原型)。因此，在开始编写代码之前，您正在编写一些东西，这与任何“瀑布模型”无关。

只是要小心，保持务实，不要更深入的细节，因为你的团队需要有效的工作。为了找到正确的平衡，你可能需要收集一些经验，这样做。如果你认为"BDD类“的规范写作对你和你的团队来说是正确的工具，那就试试吧。但是要小心，BDD是一种有点正式的编写规范的方式，它有很高的非实用化的风险。如果你觉得它会妨碍你的创造力，不要用它。

Joel写了一个关于软件规范的四部分的系列文章，你为什么需要它们，以及如何无痛地编写它们，以下是第一部分的链接，你也可以找到到其他部分的链接。虽然十多岁(远比术语BDD)，我强烈建议阅读它。

Answer 2

如果可以的话，我会把你的第一点停下来。如果交付品是非常可取的，并将产生切实的利益，自然会有一种要求迅速交付的呼声。

第二点我很感兴趣。在我看来，如果业务需要一个接口以某种方式运行，那么这也应该属于BDD的给定时间流程。

然而，在我看来，他们似乎不确定他们到底想要什么，直到他们看到它，所以我倾向于将它与开发的其他部分分离开来，这样就可以孤立地生成它。然后，一旦业务对界面感到满意，就把它缝到主交付品中，并进行正常的测试。