应该为非构建需求编写用户故事吗？

Question

我正在进行一个项目，该项目正在引入一种新的业务产品，即利用现有系统

从需求的角度来看，它们属于所有这些类型：

1. 需要进行系统更改-->即新字段、字段修改。
2. 现有字段的简单使用
3. 使用现有字段，但是对于特定于该字段的手动处理--> i.e.if，输入的值大于$500，然后从他们的办公桌上打电话给经理，说“去做吧！”在继续之前
4. 完成系统上下文之外的手动处理->即ID，并在电话中验证客户

所有这些场景是否都符合用户故事的条件？当稍后分配任务时，如何最好地标识和隔离生成和非构建故事？

Answer 1

“用户故事”指出要完成工作的业务原因对用户的影响。有些任务需要完成，不会直接影响用户，例如建立基础设施或偿还技术债务。但是，您提供的示例看起来都有用户影响的存在理由。

作为一名用户类型，我想要行动或影响，以便商业原因

例如，假设您需要添加一个新字段来跟踪请求何时完成。例如，用户故事将是：

作为一名主管，我想知道请求何时完成，这样我就可以监视团队当前的工作负载。

当然，拥有用户故事的原因是开始更改产品的过程，而不是其他人的。

您对该产品的所有更改都应该源于希望为您的用户启用某些功能。然而，当您分解用户故事需要完成的工作时，您通常只需要执行任务。当相关任务完成时，用户故事就完成了。因此，您需要能够将这些任务跟踪到所需的父用户故事。

在这一点上，备选办法包括：

• 为父用户故事创建子任务。
• 创建单独的任务，但将它们链接到父用户故事

记住，并不是软件的所有需求都来自最终用户。您可以让需要DevOps管道的开发人员来管理和优化他们的工作。一些团队创建以“作为一个我需要的开发人员.”开头的用户故事。其他团队只是把它们作为任务来追踪。这也没什么。