如何从一个系统到另一个系统编写"User"个故事？
How to write "User" Stories from system to system?
注意：我阅读了以下 2 个问题：
- Writing user stories for internal technical tasks
- How to write User Stories for technical implementation details?
这是 "short" 的故事：
我是一名产品所有者助理，与一家银行（客户）的业务分析师团队一起工作。该项目（一个多应用程序系统）为最终用户提供报告。客户希望我们以他们写作的方式帮助他们 "stories"。 （更好的切割）
此时，业务分析师提供时序图。他们写故事的方式介于技术实现和 ("user") 故事之间。
此外，这些故事不是投资，因为它遵循顺序。
一个例子：
特征：
As a FO user (in real life it's a system)
I want to ensure the loaded database contains all mandatory data in a correct format
So that I can generate a valid report for my customer
场景：
Given: I have loaded the database
When: It contains all mandatory data for proper report generation
And: The amounts formats do not fit the report generation rules
Then: I can convert the amounts formats (and go to the next step)
这是我的问题：
- 我们可以将这些故事视为技术用户故事吗？
- 我是否应该考虑我们不能写 "user stories" 但坚持规范？
- 您是否有将序列图转换为用户故事的良好输入？我应该将其视为场景吗？
正如您已经从其他帖子中读到的那样，用户故事不应该是技术性的。我建议与业务分析师坐在一起，帮助他们编写 INVEST 故事，培训他们从用户的角度来看故事应该如何呈现，并展示商业价值。最后，系统到系统的用户故事没有意义，但是客户端系统会有用户，所以故事可以从他们的角度来写（这些用户不需要关心其他系统依赖什么).故事也应该比你的例子多 specific/defined（例如，我在下面将损益作为具体情况）。
我不知道你系统的上下文，但举个例子：
特征
As a user of the client system
I want to be able to format my financial results correctly
So that I can generate a valid report for my customer
场景
Given: Profit-and-loss values have been calculated
And: The amounts formats do not fit the report generation rules
Then: I can convert the amounts formats (and go to the next step)
没有 'technical user story' 这样的东西。这就是为什么：
user stories 背后的想法是产品的最终用户很容易理解它们。在您的情况下，这是需要您的系统生成的报告的用户。
这样做有一个特定的原因：它是为了让产品的最终用户更容易了解进度。如果您的故事包含最终用户不理解的技术细节，那么故事完成这一事实对他们来说意义不大。但是，如果它是用 他们的语言 编写的，那么他们可以看到通过完成故事所实现的价值。将用户故事视为向系统最终用户报告进度的有效方式。
现在很快就会明白，用户故事不足以让技术团队交付所需的工作。这就是交付团队经常将用户故事分解为技术任务的原因。这些技术任务描述了它将如何实施，并且通常在工作开始之前添加。
在您的示例中，用户故事可能是：
As a bank current account customer I want to see an end of year report of my account so that I can do my tax returns
团队可能会添加以下与此用户故事相关的任务：
Load all mandatory data in the required format and convert any data that is in the wrong format
现在想象一下故事已经完成了。我可以走到一个随机的银行客户面前，告诉他们故事已经完成，他们会明白我的意思。他们会立即领会这份新报告对他们的价值。而如果我告诉他们技术任务对他们来说毫无意义。
How to write “User” Stories from system to system?
你不能系统不是用户。
Can we consider these stories as technical user stories?
正如您提到的问题中所述，在 Barnaby Golden 的回答中，没有技术用户故事之类的东西，甚至只是技术故事。
用户故事应该是关于用户和开发者之间的交流。您的示例故事假定有关可能解决方案的实施细节。
Should I have to consider that we cannot write "user stories" but persist with specifications?
不，您和业务分析师应该尽量让开您的开发人员。与其编写用户故事，不如专注于向团队提供您在业务流程方面的专业知识。
理想情况下，开发人员应该能够直接与客户交谈，了解所请求功能的价值并决定最佳实施。
敏捷团队致力于交付功能的垂直切片，这意味着他们应该被授权进行端到端交付。
Do you have good inputs to convert sequence diagram to user stories? Should i consider it as scenarios?
不，这真的没有意义，同样，序列图是关于系统的，而不是关于用户的。因此，它不是用户故事，甚至不是场景。
注意：我阅读了以下 2 个问题：
- Writing user stories for internal technical tasks
- How to write User Stories for technical implementation details?
这是 "short" 的故事：
我是一名产品所有者助理，与一家银行（客户）的业务分析师团队一起工作。该项目（一个多应用程序系统）为最终用户提供报告。客户希望我们以他们写作的方式帮助他们 "stories"。 （更好的切割）
此时，业务分析师提供时序图。他们写故事的方式介于技术实现和 ("user") 故事之间。 此外，这些故事不是投资，因为它遵循顺序。
一个例子：
特征：
As a FO user (in real life it's a system)
I want to ensure the loaded database contains all mandatory data in a correct format
So that I can generate a valid report for my customer
场景：
Given: I have loaded the database
When: It contains all mandatory data for proper report generation
And: The amounts formats do not fit the report generation rules
Then: I can convert the amounts formats (and go to the next step)
这是我的问题：
- 我们可以将这些故事视为技术用户故事吗？
- 我是否应该考虑我们不能写 "user stories" 但坚持规范？
- 您是否有将序列图转换为用户故事的良好输入？我应该将其视为场景吗？
正如您已经从其他帖子中读到的那样，用户故事不应该是技术性的。我建议与业务分析师坐在一起，帮助他们编写 INVEST 故事，培训他们从用户的角度来看故事应该如何呈现，并展示商业价值。最后，系统到系统的用户故事没有意义，但是客户端系统会有用户，所以故事可以从他们的角度来写（这些用户不需要关心其他系统依赖什么).故事也应该比你的例子多 specific/defined（例如，我在下面将损益作为具体情况）。
我不知道你系统的上下文，但举个例子：
特征
As a user of the client system
I want to be able to format my financial results correctly
So that I can generate a valid report for my customer
场景
Given: Profit-and-loss values have been calculated
And: The amounts formats do not fit the report generation rules
Then: I can convert the amounts formats (and go to the next step)
没有 'technical user story' 这样的东西。这就是为什么：
user stories 背后的想法是产品的最终用户很容易理解它们。在您的情况下，这是需要您的系统生成的报告的用户。
这样做有一个特定的原因：它是为了让产品的最终用户更容易了解进度。如果您的故事包含最终用户不理解的技术细节，那么故事完成这一事实对他们来说意义不大。但是，如果它是用 他们的语言 编写的，那么他们可以看到通过完成故事所实现的价值。将用户故事视为向系统最终用户报告进度的有效方式。
现在很快就会明白，用户故事不足以让技术团队交付所需的工作。这就是交付团队经常将用户故事分解为技术任务的原因。这些技术任务描述了它将如何实施，并且通常在工作开始之前添加。
在您的示例中，用户故事可能是：
As a bank current account customer I want to see an end of year report of my account so that I can do my tax returns
团队可能会添加以下与此用户故事相关的任务：
Load all mandatory data in the required format and convert any data that is in the wrong format
现在想象一下故事已经完成了。我可以走到一个随机的银行客户面前，告诉他们故事已经完成，他们会明白我的意思。他们会立即领会这份新报告对他们的价值。而如果我告诉他们技术任务对他们来说毫无意义。
How to write “User” Stories from system to system?
你不能系统不是用户。
Can we consider these stories as technical user stories?
正如您提到的问题中所述，在 Barnaby Golden 的回答中，没有技术用户故事之类的东西，甚至只是技术故事。
用户故事应该是关于用户和开发者之间的交流。您的示例故事假定有关可能解决方案的实施细节。
Should I have to consider that we cannot write "user stories" but persist with specifications?
不，您和业务分析师应该尽量让开您的开发人员。与其编写用户故事，不如专注于向团队提供您在业务流程方面的专业知识。
理想情况下，开发人员应该能够直接与客户交谈，了解所请求功能的价值并决定最佳实施。
敏捷团队致力于交付功能的垂直切片，这意味着他们应该被授权进行端到端交付。
Do you have good inputs to convert sequence diagram to user stories? Should i consider it as scenarios?
不，这真的没有意义，同样，序列图是关于系统的，而不是关于用户的。因此，它不是用户故事，甚至不是场景。