用户故事应该有多精确？
How precise user stories should be?
我刚刚开始使用 SpecFlow。它是一种以 BDD 方式创建业务可理解的测试场景的工具。基本上它将用户故事转换为单元测试。
我是用户故事的初学者，不知道它的长度。这是创建非常精确的用户故事的好做法吗？这是一个例子：
In order to get help
As a Whosebug user
I want to add post
with name and content
and add tags to it
and format the content
and the information about my post edits to be stored in the system
and some more things like that
我的故事应该紧凑吗？如果是这样——我如何管理详细的要求？或者用户故事中非常长且精确的 I want 部分没有错？
我总是提出以下建议：
尝试在场景中剪辑你的故事。场景越多，您就越能查明出现问题的时间。给所有场景主观命名。
现在以你的测试为例。如果第 1 步出错，您的所有其他步骤都不会得到测试。
还可以使用 Given、When 和 Then 标签轻松阅读您的场景。
因此，您可以说：
Feature: As a Whosebug user I want to add a post
Scenario: I go to Whosebug website
Given I open the browser
And I go to the Whosebug website
When I click New Post
Then a new page appears to insert my data
Scenario: I fill in data for my post - Name and content
Given I do not modify this page
When I fill in name
And I fill in content
Then I add tags to it
And I format the content
Scenario: Check if information about post edits are stored in the system
Given...
猜猜你会明白这是怎么回事:-)
用户故事没有正确的详细级别，因为随着时间的推移，用户故事的大小（范围）缩小，细节（规范）增加。这张幻灯片展示了来自 Gojko Adzic 的一个很好的可视化：http://www.slideshare.net/chassa/2015-0214agile-reqend2endcomplete/6
关于小黄瓜场景应该有多精确和详细的问题：场景应该揭示要实现的用户故事的有趣方面。他们应该使用具体（关键）的例子而不是抽象的描述。示例应侧重于应说明的方面。场景标题应该是对规则或方面的抽象描述，并通过场景中提供的示例进行说明。
您通常从一个主要方面（快乐路径）场景开始，然后尝试通过提出探索故事其他方面的新示例（案例）来“打破模型”。你首先要问这样的问题：“当这个故事被实施时，你会如何尝试它？” （快乐之路）和“如果……会发生什么？”收集要考虑的潜在场景（可能定义一些超出本文范围的问题）。
之后，您将尝试回答这些问题（场景标题）并用具体示例（场景步骤）进行说明。这张幻灯片给出了“打破模型”的想法：http://www.slideshare.net/chassa/2015-0214agile-reqend2endcomplete/61
如果你能在几周内开发出一个完整的系统，并且可靠地做到这一点，那么就没有人会担心 "user stories"。他们只会让您开发系统，与您坐在一起，并在进行过程中对其进行调整。
用户故事的存在只是为了从那些不能一直和你在一起的人那里得到反馈，并帮助你了解你的用户（和其他利益相关者）真正想要。
我是这样处理列表的：
In order to get help
As a Whosebug user
I want to add post
with name and content
and add tags to it
and format the content
and the information about my post edits to be stored in the system
您想获得帮助。其中哪些实际上增加了您获得帮助的能力？是你想要帮助，还是你想为其他人提供帮助？您希望因您为他人提供的帮助而得到认可吗？这上面的部分似乎是错误的（这就是为什么很难用虚假需求进行这些对话）。
我认为这里有多个需求，远远超出了一个用户故事的范围。带着分析师的帽子，我可以这样分解：
In order to award great content with appropriate recognition,
as Stack Exchange,
we want people's usernames to appear with their content.
当然，用户也想要这个，但他们不为此付费（除了通过广告）。所以弄清楚谁为此买单，为什么。
In order to get more page impressions and keep people on the site for longer,
as Stack Exchange,
we want users to be able to find similar content really easily.
嗯。这个有点棘手。看，用户并不真的 想要 将他们的整个生命都花在 Whosebug 上。只是如果我们给他们适当的认可，让其他人更容易找到他们的内容，他们可能会那样做。并非所有 "user stories" 都能真正让用户受益。找出谁为他们买单，以及为什么；然后你找到你真正的利益相关者。一个故事让不止一个利益相关者受益也是可以的，并且很容易看出如何从用户的角度重新表述这一点。
format the content
老实说，我对此不太确定。它可能是关于能够强调重点等。有大量的审美理想不适合 BDD 和自动化场景。有时唯一的方法就是尝试并获得反馈。
In order to avoid retyping my request every time
As the user
I want the information about my post edits to be stored in the system
嗯，是的，那就太好了。
问题在于，每一个都可以独立开发。如果您能想到任何功能，任何您可以摆脱但仍然有价值的项目，请将其放在一个单独的故事中。
如果您可以将 "I want to..." 替换为 "I want to be able to..."，那么您所拥有的可能不是故事，而是完整的 能力 。大多数人本能地这样做。很多人称它们为 "epics".
我刚刚向您展示了我是如何分解它们的。这是一个非常简单的过程。
首先，看你的要求。如果有什么你可以说，"I want to be able to..." 或 "Someone wants to be able to..." 那么你知道这是一个完全不同的能力，这意味着它将是一个单独的故事。
然后您可以将它们分成上下文。所以你可能有这样的故事：
In order to free up our junior traders
We want them to be able to generate contracts automatically
So that they can help with the trade analysis instead of typing.
如果这对于反馈周期（通常是两周的冲刺）来说似乎太大了，您可以进一步划分。
In order to free up our junior traders
We want them to be able to generate *orange juice* contracts automatically
So that they can help with the trade analysis instead of typing.
在这里，我们专注于能够交易橙汁，但我们同样可以将故事缩小到 FTSE、美国或纽约证券交易所。这就是我们如何将精力集中在将要交付的东西上：保护收入、降低成本或创造价值。
为了将这些变成场景，我会问，"Can you give me an example of an OJ trade on the NY stock exchange?" 如果我看到任何我不理解的通用内容，我会问，"Can you give me an example of that?"
那个例子成为我的第一个场景。上下文（给定的）由故事的局限性定义。事件（when）是能力的表现。结果（然后）是结果值。
回答您的问题 - 是的，我认为创建精确的用户故事很重要。这意味着知道它为什么有价值，定义您将要涵盖的上下文，并提出一个可能的结果示例。
不过，您举的例子不只是一个故事。不够精确。希望这里的建议能帮助您将故事缩小到有用的范围。一两天对于一个故事来说是一个很好的长度，但如果你开始沿着这条路走，发现它们更长一点，那没关系。
您的更改还有 个故事。
我刚刚开始使用 SpecFlow。它是一种以 BDD 方式创建业务可理解的测试场景的工具。基本上它将用户故事转换为单元测试。
我是用户故事的初学者，不知道它的长度。这是创建非常精确的用户故事的好做法吗？这是一个例子：
In order to get help
As a Whosebug user
I want to add post
with name and content
and add tags to it
and format the content
and the information about my post edits to be stored in the system
and some more things like that
我的故事应该紧凑吗？如果是这样——我如何管理详细的要求？或者用户故事中非常长且精确的 I want 部分没有错？
我总是提出以下建议：
尝试在场景中剪辑你的故事。场景越多，您就越能查明出现问题的时间。给所有场景主观命名。
现在以你的测试为例。如果第 1 步出错，您的所有其他步骤都不会得到测试。
还可以使用 Given、When 和 Then 标签轻松阅读您的场景。
因此，您可以说：
Feature: As a Whosebug user I want to add a post
Scenario: I go to Whosebug website
Given I open the browser
And I go to the Whosebug website
When I click New Post
Then a new page appears to insert my data
Scenario: I fill in data for my post - Name and content
Given I do not modify this page
When I fill in name
And I fill in content
Then I add tags to it
And I format the content
Scenario: Check if information about post edits are stored in the system
Given...
猜猜你会明白这是怎么回事:-)
用户故事没有正确的详细级别，因为随着时间的推移，用户故事的大小（范围）缩小，细节（规范）增加。这张幻灯片展示了来自 Gojko Adzic 的一个很好的可视化：http://www.slideshare.net/chassa/2015-0214agile-reqend2endcomplete/6
关于小黄瓜场景应该有多精确和详细的问题：场景应该揭示要实现的用户故事的有趣方面。他们应该使用具体（关键）的例子而不是抽象的描述。示例应侧重于应说明的方面。场景标题应该是对规则或方面的抽象描述，并通过场景中提供的示例进行说明。
您通常从一个主要方面（快乐路径）场景开始，然后尝试通过提出探索故事其他方面的新示例（案例）来“打破模型”。你首先要问这样的问题：“当这个故事被实施时，你会如何尝试它？” （快乐之路）和“如果……会发生什么？”收集要考虑的潜在场景（可能定义一些超出本文范围的问题）。
之后，您将尝试回答这些问题（场景标题）并用具体示例（场景步骤）进行说明。这张幻灯片给出了“打破模型”的想法：http://www.slideshare.net/chassa/2015-0214agile-reqend2endcomplete/61
如果你能在几周内开发出一个完整的系统，并且可靠地做到这一点，那么就没有人会担心 "user stories"。他们只会让您开发系统，与您坐在一起，并在进行过程中对其进行调整。
用户故事的存在只是为了从那些不能一直和你在一起的人那里得到反馈，并帮助你了解你的用户（和其他利益相关者）真正想要。
我是这样处理列表的：
In order to get help
As a Whosebug user
I want to add post
with name and content
and add tags to it
and format the content
and the information about my post edits to be stored in the system
您想获得帮助。其中哪些实际上增加了您获得帮助的能力？是你想要帮助，还是你想为其他人提供帮助？您希望因您为他人提供的帮助而得到认可吗？这上面的部分似乎是错误的（这就是为什么很难用虚假需求进行这些对话）。
我认为这里有多个需求，远远超出了一个用户故事的范围。带着分析师的帽子，我可以这样分解：
In order to award great content with appropriate recognition,
as Stack Exchange,
we want people's usernames to appear with their content.
当然，用户也想要这个，但他们不为此付费（除了通过广告）。所以弄清楚谁为此买单，为什么。
In order to get more page impressions and keep people on the site for longer,
as Stack Exchange,
we want users to be able to find similar content really easily.
嗯。这个有点棘手。看，用户并不真的 想要 将他们的整个生命都花在 Whosebug 上。只是如果我们给他们适当的认可，让其他人更容易找到他们的内容，他们可能会那样做。并非所有 "user stories" 都能真正让用户受益。找出谁为他们买单，以及为什么；然后你找到你真正的利益相关者。一个故事让不止一个利益相关者受益也是可以的，并且很容易看出如何从用户的角度重新表述这一点。
format the content
老实说，我对此不太确定。它可能是关于能够强调重点等。有大量的审美理想不适合 BDD 和自动化场景。有时唯一的方法就是尝试并获得反馈。
In order to avoid retyping my request every time
As the user
I want the information about my post edits to be stored in the system
嗯，是的，那就太好了。
问题在于，每一个都可以独立开发。如果您能想到任何功能，任何您可以摆脱但仍然有价值的项目，请将其放在一个单独的故事中。
如果您可以将 "I want to..." 替换为 "I want to be able to..."，那么您所拥有的可能不是故事，而是完整的 能力 。大多数人本能地这样做。很多人称它们为 "epics".
我刚刚向您展示了我是如何分解它们的。这是一个非常简单的过程。
首先，看你的要求。如果有什么你可以说，"I want to be able to..." 或 "Someone wants to be able to..." 那么你知道这是一个完全不同的能力，这意味着它将是一个单独的故事。
然后您可以将它们分成上下文。所以你可能有这样的故事：
In order to free up our junior traders
We want them to be able to generate contracts automatically
So that they can help with the trade analysis instead of typing.
如果这对于反馈周期（通常是两周的冲刺）来说似乎太大了，您可以进一步划分。
In order to free up our junior traders
We want them to be able to generate *orange juice* contracts automatically
So that they can help with the trade analysis instead of typing.
在这里，我们专注于能够交易橙汁，但我们同样可以将故事缩小到 FTSE、美国或纽约证券交易所。这就是我们如何将精力集中在将要交付的东西上：保护收入、降低成本或创造价值。
为了将这些变成场景，我会问，"Can you give me an example of an OJ trade on the NY stock exchange?" 如果我看到任何我不理解的通用内容，我会问，"Can you give me an example of that?"
那个例子成为我的第一个场景。上下文（给定的）由故事的局限性定义。事件（when）是能力的表现。结果（然后）是结果值。
回答您的问题 - 是的，我认为创建精确的用户故事很重要。这意味着知道它为什么有价值，定义您将要涵盖的上下文，并提出一个可能的结果示例。
不过，您举的例子不只是一个故事。不够精确。希望这里的建议能帮助您将故事缩小到有用的范围。一两天对于一个故事来说是一个很好的长度，但如果你开始沿着这条路走，发现它们更长一点，那没关系。
您的更改还有 个故事。