想问一下您将如何编写用户故事，其中您的初始任务是分析或收集需求。
一点背景知识，假设客户有一个旧版应用程序，他们希望将其转换为在线应用程序。旧版应用程序仅使用 Excel 工作表 + 宏。现在，在编写用户故事时，您将如何编写以下内容？
我可以做类似的事情吗 - 作为一名业务分析师，我想要 yaddi-yadda 吗？
听起来不太对劲……
你们能帮我举几个用于需求收集的敏捷用户故事的例子吗？谢谢。
【问题讨论】：
标签： agile scrum requirements
你不应该写故事来写故事。建立积压的任务是没有意义的，因为这绝不是用户故事的意图。
所以从对产品/系统意图的非常快速、非常高级的描述开始，这应该足以让您开始工作，现在将每个高级描述细化为故事集。
应该不需要创建故事来跟踪这项工作，积压工作本身的状态应该是足够的指示。
由于使用用户故事，您将在一切都还不清楚（还）时开始工作，实际构建的部分工作将是提取确切的业务规则，或分析 excel 文件以确保正确的测试用例将被建造。这不是构建积压工作所必需的，因为详细程度会很深。
【讨论】：
无需为此类任务编写用户故事，但我会建议您为每个工作组创建任务。可能是现有系统的每个模块/功能的分析任务。
分析任务完成后，您可以继续根据确定的工作开始编写用户故事。
【讨论】：
“一点背景知识，假设客户有一个旧版应用程序，他们希望将其转换为在线应用程序。旧版应用程序仅使用 Excel 表格 + 宏。”
好的，那么为什么客户希望遗留应用程序成为在线应用程序？例如：
“作为用户，我希望能够在线访问 ABC 应用程序，而不是必须在本地安装它，因为这样可以让我以更高效的方式工作”
现在这听起来像是一个伟大的故事（甚至是史诗）。所以也许下一阶段是分解它。也许是一个时间限制的峰值来调查现有的应用程序并派生一些关键特性。然后可以将这些转换为故事，例如：
“作为用户，我希望能够上传我的数据集以便对其进行处理”
“作为用户，我希望能够对数据集进行 XYZ 分析，以便计算出因子 X 值”
在这个阶段，团队可以开始着手生产第一个可交付的产品。与客户互动以确保正在构建的内容满足他们的要求（而不是简单地复制以前的应用程序）。
我们的目的是首先产生最有价值的功能，并尽早将它们制成可行的产品。这比花费大量时间从遗留应用程序中提取需求并因此在客户看到任何东西之前花费很长时间更可取。
【讨论】：