我们正在将我们的门户网站P与另一个第三方Web应用程序W集成.W将在我们的门户中显示一个模态弹出窗口。
一个明显的用户故事（让我们称之为US1）
作为用户U，当点击按钮B时，W应显示为弹出窗口，并且某些信息设置为＆＃39; IS＆＃39;应该预先填充，以便我可以查看信息集＆＃39; IS＆＃39;。
现在要预先填充信息集IS，我们需要创建一组API并在后端集成，以便将来自门户网站P的信息发送到Web应用程序W.
我的问题是，API的创建是系统用户故事还是任务？
工作可以在sprint中完成，但API创建和集成可能是我的多项任务。此集成的完成也会阻止第三方Web应用程序中的后续用户故事。
那么我应该写一个系统用户故事（让我们称之为SUS1）和类似的任务吗？
作为门户网站P，我应该能够将信息集IS发送到第三方Web应用程序W，以便用户U可以查看此信息。
这显然需要创建子任务T，例如
＆＃34;创建API A＆＃34;
或者我应该为用户故事US1创建一个子任务T.
这里的团队更乐于调用所有故事，以便他们可以轻松查看他们在sprint中的活动，特别是沟通并显示后续用户故事US2依赖于系统用户故事SUS1。
答案 0 :(得分：4)
创建API是一种基础设施问题，不应在利益相关方（或最终用户）级别上显示。因此，您应该创建一个任务作为实现用户故事US1的手段。
但是！
您应该垂直地对系统进行分区，即任务应该不需要实现不必要的API来使US1工作。您应该实现API的其余部分，以实现后续用户故事。
一个自然结果是，逐步构建的API将无法实现最佳设计。因此，在每个步骤中，您应该重构，考虑到目前为止实现的所有用户故事。这比BDUF（Big Design Up Front）要好得多。
答案 1 :(得分：2)
User stories是从最终用户的角度编写的，描述了他们希望从产品中获取的内容。 他们没有描述如何实施。
您所描述的不是用户故事，而是多个实施任务的组合。
用户故事的示例可能是：
作为门户网站用户，我想查看今天的天气信息，以便了解今天的天气情况
将此用户故事分配给sprint后，开发团队可能会将其分解为许多技术任务。这将包括创建足以传递用户故事的API 。