我们用规定的标准编写用户故事作为X我想要Y以便Z. 现在随着BDD和Gerkhin语言格式的流行以指定要求，是否有人有将用户故事转换为gerkhin格式的经验。您是否发现以这种格式从业务中获取要求更容易，更直观，并且您是否在此过程中获得了任何好处？
答案 0 :(得分：5)
您仍然可以在Gherkin中使用As an X I want a Y so that Z启动每个功能。然而，这通常被扭转，因此它的好处是其最突出的方面，
例如来自https://github.com/cucumber/cucumber/wiki/Gherkin
Feature: Some terse yet descriptive text of what is desired
In order to realize a named business value /*Z*/
As an explicit system actor /*X*/
I want to gain some beneficial outcome which furthers the goal /*Y*/
完成此部分后，Gherkin功能的其余部分是更易识别的Given When Then部分，但这些只是突出显示功能功能的示例。它们与您的功能定义一起存在，而不是它。
有关详情，请仔细阅读http://dannorth.net/introducing-bdd/
答案 1 :(得分：2)
我会继续在'作为......我想......那样......'的格式中写下用户故事并使用小黄瓜编写你的录取标准。
答案 2 :(得分：1)
纵观我对Agile的经验，我注意到没有适用于所有情况和所有团队的固定规则。敏捷的概念是摆脱不必要的形式主义，这些变化宁愿剥夺真正的敏捷概念（我的战俘！）
在编写用户故事时，它更多地是一种进化的东西，然后被修复。每个新团队都必须尝试测试适合他们的团队。 “不要解决aint打破的问题”所以如果您当前的用户故事遇到一些问题，请在回顾会议期间指出并解决问题。尝试遵循团队建议并同意的更改。您最终会获得更好的用户故事。
答案 3 :(得分：0)
User Stories已经有一个简单的定义格式
As a <Type of User>
I want <To perform some action>
So that <I receive some value>
Gherkin格式（Gherkin是一种用于制作泡菜的黄瓜）通常用于在Cucumber测试自动化工具等软件中记录Acceptance Criteria。得到它？黄瓜用于黄瓜？ Gherkin格式使用Given ... When ... Then ...语句。
Gherkin格式：
Given <A Certain scenario>
When <I perform some action>
Then <I receive some result>
根据我的经验，Acceptance Criteria以不同的格式编写，从项目符号列表到逗号分隔列表和连续句子。因此，Gherkin格式提供了一种标准方式来描述Acceptance Criteria，同时以简化格式防止复杂或复合Acceptance Criteria
使用Acceptance Criteria的简单Gherkin格式还有另一个有趣的好处。由于Acceptance Criteria必须简单，并且在这种格式中，每个细节必须记录在它自己的Given ... Then ... Then语句中。因此，当我们开始查看特定User Story的Gherkin语句的数量时，语句的数量超过15或20，这表明我们的User Story可能是一个伪装成一个Epic或Feature的特征User Story。也就是说，我们应该将User Story切成较小的User Stories，每个Acceptance Criteria使用较少的Gherkin User Story语句。 有关详细信息，请参阅ProDataMan博客下面的相关帖子......