系统用户故事与任务
System user Story vs Task
我们正在将我们的门户 P 与另一个第三方 Web 应用程序 W 集成。W 将显示在我们的门户中的模式弹出窗口中。
一个明显的用户故事（我们称之为 US1）
As a user U when click a button B, W should be displayed as a popup and the certain information set 'IS' should be pre-populated so that I can review the information set 'IS'.
现在要预填充信息集 IS，我们需要创建一组 APIs 并在后端集成以将信息从我们的门户 P 发送到 Web 应用程序 W。
我的问题是，API 的创建应该是系统用户故事还是任务？
这项工作可以在冲刺中完成，但 API 创建和集成可能会涉及多项任务。此集成的完成还会阻止第三方 Web 应用程序中的后续用户故事。
那么我应该写一个系统用户故事（我们称之为 SUS1）和这样的任务吗？
As a portal P I should be able to send information set IS to third party web application W so that the user U can view this information.
这显然需要创建子任务T，例如
"Create API A"
或者我应该为用户故事 US1 创建一个子任务 T。
这里的团队更愿意将所有内容称为故事，这样他们就可以轻松地在冲刺燃尽图中查看他们的 activity，尤其是沟通和展示后续用户故事 US2 依赖于系统用户故事 SUS1。
API 的创建是一个基础设施问题，不应在利益相关者（或最终用户）级别上可见。因此，您应该创建一个任务作为实现用户故事 US1 的一种方式。
但是！
您应该垂直划分您的系统，即该任务需要实施的 API 不超过使 US1 工作所需的数量。您应该在实施后续用户故事的同时实施 API 的其余部分。
一个自然的结果是增量构建的 API 不会有最好的设计。因此，在每一步重构时，您都应该考虑到目前已实现的所有用户故事。这比 BDUF (Big Design Up Front).
好多了
User stories 是从最终用户的角度编写的，描述了他们希望从产品中获得什么。 他们没有描述如何实施。
您描述的不是用户故事，而是多个实施任务的组合。
用户故事的示例可能是：
As a portal user I want to see today's weather information so that I can know what the weather will be like today
一旦将此用户故事分配给冲刺，开发团队很可能会将其分解为多个技术任务。这将包括创建足以交付用户故事的API 。
我们正在将我们的门户 P 与另一个第三方 Web 应用程序 W 集成。W 将显示在我们的门户中的模式弹出窗口中。
一个明显的用户故事（我们称之为 US1）
As a user U when click a button B, W should be displayed as a popup and the certain information set 'IS' should be pre-populated so that I can review the information set 'IS'.
现在要预填充信息集 IS，我们需要创建一组 APIs 并在后端集成以将信息从我们的门户 P 发送到 Web 应用程序 W。
我的问题是，API 的创建应该是系统用户故事还是任务？
这项工作可以在冲刺中完成，但 API 创建和集成可能会涉及多项任务。此集成的完成还会阻止第三方 Web 应用程序中的后续用户故事。
那么我应该写一个系统用户故事（我们称之为 SUS1）和这样的任务吗？
As a portal P I should be able to send information set IS to third party web application W so that the user U can view this information.
这显然需要创建子任务T，例如
"Create API A"
或者我应该为用户故事 US1 创建一个子任务 T。
这里的团队更愿意将所有内容称为故事，这样他们就可以轻松地在冲刺燃尽图中查看他们的 activity，尤其是沟通和展示后续用户故事 US2 依赖于系统用户故事 SUS1。
API 的创建是一个基础设施问题，不应在利益相关者（或最终用户）级别上可见。因此，您应该创建一个任务作为实现用户故事 US1 的一种方式。
但是！
您应该垂直划分您的系统，即该任务需要实施的 API 不超过使 US1 工作所需的数量。您应该在实施后续用户故事的同时实施 API 的其余部分。
一个自然的结果是增量构建的 API 不会有最好的设计。因此，在每一步重构时，您都应该考虑到目前已实现的所有用户故事。这比 BDUF (Big Design Up Front).
好多了User stories 是从最终用户的角度编写的，描述了他们希望从产品中获得什么。 他们没有描述如何实施。
您描述的不是用户故事，而是多个实施任务的组合。
用户故事的示例可能是：
As a portal user I want to see today's weather information so that I can know what the weather will be like today
一旦将此用户故事分配给冲刺，开发团队很可能会将其分解为多个技术任务。这将包括创建足以交付用户故事的API 。