如何为系统内部需求编写用户故事？

Question

系统的某些需求是针对系统本身，或者是对于开发人员，我如何编写用户故事呢？

例如，对系统的要求是：

1. 提供API，以便合作伙伴应用程序能够与其交互，以及
2. API应该是灵活和丰富的，适合各种应用程序。

我可以为第一个用户故事编写如下：

作为合作伙伴，我希望调用系统提供的API，这样我就可以在系统上构建额外的功能。

但是对于第二个问题，我不知道怎么写。这似乎更有利于开发人员，这样他们就不需要为新的合作伙伴开发新的API了。

编辑：

很抱歉，我提供的例子不是很好的用户故事。正如许多人指出的那样，它们过于宽泛或模糊。但是，请注意我的观点，如何为系统内部需求编写故事。

我认为有两种观点与答案相去甚远：

1. 非用户面对一个人不需要一个用户故事。用户故事是关于一个用户的。
2. 非功能性需求或系统约束可以捕获为用户故事。用户是相关的涉众，比如系统开发人员。

你认为如何？

Answer 1

您的示例是与互操作性相关的模糊非功能性需求：

1. 含糊地指出，必须提供互操作性，以及如何提供(API)；
2. 含糊地说明了这种互操作性应该有多好。

但这是真实的生活:在项目开始的时候，人们很少确切地知道他们需要什么，我们的工作就是在这个问题上帮助他们。

对于是否将待办事项处理中的非功能需求作为用户故事，存在一些争议。

迈克·科恩是用户故事的参考，为这种方法辩护解释说，这样的需求会对可能的设计造成限制，应该加以考虑。他建议“用户”不再是最终用户，而是相关的利益相关者。您确定了它们:合作伙伴代表1)，合作伙伴的开发人员识别2)。

当然，你的要求只是暂时模糊的愿望:你不能用它们制造任何东西！这就好像一个用户会说：“作为一个雇员，我想要一个GUI，这样我就可以很容易地使用这个软件”。

实际上，这意味着故事还没有准备好。幸运的是，我们是敏捷的，这不会阻止我们在积压中整理它：

用户故事只是一个会话占位符

因此，将您的初始故事作为占位符放在待办事项簿中，并尽快保持这些对话，以便更清楚地了解真正需要的内容，其准确性足以开发API并对其进行测试。

Answer 2

在您的特定示例中，您既没有好的需求，也没有好的用户故事。从传统或敏捷化的角度来看，简单地说“为合作伙伴应用程序提供API”或“使API足够灵活和足够丰富”并不是很好的需求。

我的建议是不要为不面向用户的事情编写用户故事。用户故事格式并不是捕捉系统的需求、需求和期望的唯一方法。有不同的方式来分割和分解用户故事，但是用户故事应该是关于用户的。一种方法可能是将用户故事分解成更小的任务，但是交付整个用户故事。另一种方法可能是识别可构建的、可测试的、可交付的和可部署的工作单元，即使它们对用户不可见，并将它们视为启用工作。

你应该确定演员(S)是谁。在这种情况下，与API交互的是一个外部系统。首先，我要捕获您希望外部系统(您的合作应用程序)能够做的事情--您希望它们能够查询、读取、更新、删除和创建的东西。如果您愿意，可以将这些表示为用户故事，但也可以考虑其他格式。

一旦您知道了要在API后面公开哪些内容，就可以开始细化和分解。可能有些公开的事情是长时间运行的任务，无法实时完成，您需要构建队列和处理工作人员。也许您需要处理身份验证和授权。其中一些可能是离散的、可构建的和可测试的，应该是您定义和捕获的工作，而其他的工作是作为公开新的API端点的一部分完成的。

Answer 3

我认为这里的主要问题是，您没有将第三方开发人员视为您系统的用户。

有时，您的用户不是最终用户。有时他们是开发人员。一旦您将“用户”重新定义为第三方开发人员，您就可以开始将行为分解为更小、更易于管理的块。

当然，这种行为可能遵循您的主要面向用户应用程序的需求，但这些是针对最终用户的单独的用户故事，而最终用户的先决条件是正在开发的API。

最后，也是最重要的是，不要建立比你迫切需要的更多。构建可以扩展的东西没有什么问题，但是在您有需要扩展的客户之前不要扩展它。保持API故事高度集中，避免像您在问题中提到的一般故事。