在撰写用户故事时，我与团队中的其他2人进行了几个小时的会谈。
对我来说，这看起来像浪费时间。例如 - 我们正在为用户注册功能编写用户故事。看起来这些是如此简单的事情，这个规范可以由一个人写。
我们还没有像这样编写测试（或者它们是如何调用的）：
给出一个5乘5的游戏当我在（3,2）处切换单元格然后是网格 应该看起来像[graphics]
所以我才给人留下第一印象。
团队将超过3人。因此，如果连接所有团队，它将花费大量的时间。因为 - 我们一次只考虑一件事。现在像3个人 - 一次3件事（例如故事）。
我认为产品所有者可能不高兴，因为在没有获得巨大利益的同时支付工资。
准备好的规范是非常好的事情。但我认为 - 更好的是，尽可能少的人为功能编写规范。然后我们开会讨论这个规范并进行编辑。
我知道以后会比用户注册更复杂的功能。而且我相信这需要更多的时间来准备规范。仍然 - 也许尽可能少的人可以制定规范，然后其他人 - 会见并讨论它。
并非所有开发人员都需要讨论功能。我认为只有真正开发该功能的开发人员才能加入规范创建者并进行讨论。
BDD可以这样做吗？也许我不明白什么，这就是为什么我认为浪费时间？
答案 0 :(得分：1)
BDD没有银弹。您将通过试用/错误和经验不断学习如何进一步平滑过程。没有明确的权利，也没有明确的错误。我想说，首先，没有人应该觉得他们在浪费时间。如果是这种情况，那就是可以改善事物的气味，或者不是每个人都致力于练习BDD。
在你的情况下，作为一个如此小的团队，让每个人都参与到功能的定义中是绝对有意义的。当团队成长时，您需要开始考虑与just合适的利益相关者安排这些讨论。
您必须认为BDD的重点是帮助将业务需求和概念转换为可确保满足这些业务需求的软件。您可以通过描述产品的功能来实现这一点，通过提供具体的示例，您甚至可以使用BDD（我不建议使用维护噩梦）进行完整的UX方法。
谁知道业务如何运作/应该如何运作？让这些专家加入对话。谁将开发该功能？让这些人加入对话。是否会通过手动测试或更新现有测试套件来参与QA？也让他们进入对话。
所有这些利益相关者都是BDD成功的关键和关键。一旦他们成为对话的一部分，业务专家就应该解释他们对需要构建的功能的了解。然后其他利益相关者应该提出问题，澄清，示例等。然后理想情况下，您将开始使用Gherkin或其变体开始绘制该功能的方案。一旦这些场景完整地描述了该功能应该如何工作并且每个人都对它们的编写方式感到满意，那么会话就会结束。
从那里开始，开发人员和QA团队的实施阶段，以及专家等待会话期间描述的所有场景都是可执行的并且正在通过。
现在想想一个开发人员不是该功能的初始对话的一部分，但需要改变其行为或修复错误。该开发人员将完整描述该功能如何以简单的英语工作，并可以快速检测可能引入这些行为变化的位置。为此，该人员应该再次聚集适当的利益相关者并就该功能的新描述达成一致。开发，演示，庆祝。
冲洗并重复。
答案 1 :(得分：0)
BDD的概念是关于“3 amigos”。这些是利益相关者，开发者和Q＆amp; A。这些职位可能有所不同，这取决于项目和公司结构。
利益相关方在讨论中只占1个，但Q＆amp; A团队或开发人员可以按照您的情况描述更多与会者。应该没有规则，团队中必须有每个人。保持最低数量是有效的，但主要是保持最佳状态，以便能够正确理解和描述问题。这取决于功能的复杂性。根据我的经验，大多数最佳数字是2位开发人员。
答案 2 :(得分：0)
BDD最重要的是沟通和对即将实施的内容的共同理解。
获得这种共识的一种方法是召开三次会议。将产品所有者，测试人员和开发人员聚集在一起，让他们讨论用户故事。这可以使用Matt Wynne在此描述的示例映射来完成：https://cucumber.io/blog/2015/12/08/example-mapping-introduction
正式的Gherkin可能不是在三次会议期间写的，可能是后来由开发人员或测试人员写的。如果它写完了。
如果您对会议期间提出的理解感到满意，并且不需要更多能够实现您的功能，您可以跳过编写Gherkin。
如果您要自动化方案，请编写Gherkin，因为这将成为您自动化工作的基础。
我喜欢自动化的东西，所以我可能会自动化这些步骤。您可能会或可能不会找到受益人，因此为您的团队和项目做最好的事情。
必须建立共识，自动化并非强制性。