系统用户故事vs任务

Question

我们正在将我们的门户P与另一个第三方Web应用程序W集成.W将在我们的门户中显示在模式弹出窗口中。

一个明显的用户故事（姑且称之为US1）

作为用户U点击一个按钮B时，W应显示为弹出并设定特定信息的“是”，应预先 - 填充以便我可以查看设置'IS'的信息。

现在预填信息集，我们需要创建一组API和后端集成到我们的门户P将信息发送到Web应用程序W.

我的问题是，API的创建应该是系统用户故事还是任务？

这项工作可以在冲刺完成，但API创建和整合将可能我多任务。此外，完成此集成还会阻止第三方Web应用程序中的后续用户故事。

所以我应该写一个系统用户故事（让我们称之为SUS1）和类似的任务？

作为门户P，我应该能够将信息集IS发送到第三方Web应用程序W，以便用户U可以查看此信息。

这显然需要分工作T的创作，如

“创建API A”

或者我应该只是为用户创造故事US1子工作T。

的团队在这里是更舒适的调用一切的故事，让他们可以轻松地查看自己在冲刺活动烧毁，尤其是沟通，表明后续用户故事US2是依赖于系统的用户故事SUS1。 API的

Answer 1

User stories被但从最终用户的角度编写，并说明它是什么，他们希望从产品中获得。 他们没有描述如何执行。

您描述的内容不是用户故事，而是多个实施任务的组合。

用户故事的一个例子可能是：

，因为我想看看今天的天气信息，这样我就可以知道天气会像今天

一旦这个门户网站用户用户故事被分配给冲刺，开发团队很可能将其分解为若干技术任务。这将包括创建足以提供用户故事的API 。

Answer 2

创建是一个基础设施的关注，不应该是利益相关者（或最终用户）的水平可见。因此，您应该创建一个任务作为实现用户故事US1的手段。

但是！

你应该垂直分区您的系统，即任务应该要求执行不超过必要的API，使US1工作。您应该在实施后续用户故事时实施其余的API。

一个自然的结果是增量构建的API不会有最佳的设计可能。因此，在每一步你都应该考虑到迄今为止实现的所有用户故事。这比BDUF好得多（Big Design Up Front）。