提示：本文共有 2267 个字，阅读大概需要 5 分钟。
时间不允许我们回答的一个问题是，如何在规划和开发阶段将产品功能分解为用户故事，以及为什么这些用户故事，而不是更大的产品功能，是更好的发展单位。 这个问题让我们感到非常重要，因此我们决定将整篇博客文章用于回答它！
首先，如果您不熟悉该术语，则用户故事是一个小型的，独立的开发工作单元，旨在完成产品中的特定目标。它描述了一小部分但完整的用户功能块的意图或期望的结果。给定的产品功能可能由几个用户故事组成。
一个故事通常是从用户的角度来编写的，并遵循以下格式：“作为[用户角色]，我希望[执行此操作]以便[我可以实现此目标]。”正如您所看到的，用户故事不会通常不会描述如何实现某个功能，而是需要用户希望实现的功能以及原因。实现细节通常包含或附加为故事的一部分。
“希望在软件开发方面的合作单位是一个细致的用户故事。”
例如，我们的路线图软件的用户故事可能是这样写的：“作为一名产品经理，我想在公司的产品路线图中搜索Notes，这样我就可以快速找到需要我团队资源的举措。
从策略到执行：为什么用户故事与功能相反？
理解从产品功能到用户故事所涉及的工作，以及为什么要走这条路的关键是要首先了解有效的产品管理需要从高层战略开始，然后系统地进行细化。
正如我们在本书“产品路线图：规划和销售策略指南”中所解释的，如果您的组织计划启动新产品，则首先要从最高层开始。
如果你开始头脑风暴的产品功能，用户工作流程或外观的想法，而不首先确定你的产品的战略目的，其原因，你可能会开发一个不专心和不起眼的产品。
但假设您已经完成了产品规划的第一个战略阶段，现在您已准备好将您的路线图的计划（如下面的示例路线图，使用ProductPlan的基于Web的路线图软件构建）转换为您的工程团队的可操作步骤。以下是为什么将这些作品分成用户故事比提出完整功能更有意义的几个原因。
1.故事是垂直的：它们允许开发团队专注于完整的功能（无论多小）。
赞成用户故事的一个原因是它们是小的垂直切片 - 意味着它们代表了整个功能。换句话说，一个故事应该允许用户完成一些任务，即使这个任务很小。
当一个故事通过开发被检入时，你实际上可以用这个故事做一些事情 - 使用它，测试它，验证它。所以它代表了一个很好的增量步骤，您可以完成朝着更大的目标或里程碑。
如果你不是用一个完全形成功能工作任务的工程师，他们更可能的是，在任何给定的时刻，比方说，在当它的时间来审查他们的冲刺结束工作用任何物品只是部分完成，他们正在努力。
这意味着你必须在你的冲刺年底少得多的机会来测试，达成一致，然后推的功能，即使是非常小活新部分的人，如果你的开发者都在“仍在研究”不同程度的各自的特点。如果您的开发人员正在从事长达数小时的用户故事，则通常会有新的功能发布并获得反馈。
2.故事很容易适应冲刺，而功能通常不能。
将产品的所需功能分解为用户故事的另一个好处是，由于它们代表产品的非常小的块，因此故事可以提供更有效的调度和协作。
即使您的公司是一家运行速度很快的敏捷商店，一个典型的故事也会很好地适应这些冲刺时间表，这样您就可以在冲刺结束时总是查看几个完整的故事。
此外，如果优先级改变并且您需要调整您的开发时间表，那么在议程中转换故事要比请求开发团队停止已完成65％的大型功能的进度要容易得多，并且重新关注于 一个全新的，大的功能。
3.故事捕捉意图和期望的结果，将实际的开发指令留给专家：开发者自己。
故事使产品经理有机会非常具体地描述一个功能对于用户来说所期望的结果是什么，这样任何有经验的开发人员都能够理解这个意图，或许只需要一些澄清的问题。
由于以下几个原因，这比提供关于编码或用户工作流程的具体说明更好。首先，它允许开发人员将他们的知识和经验带到项目中。他们通常比PM更了解如何将故事转化为正确的一系列用户步骤或行动。
用期望的结果而不是详细的说明来组织故事的另一个原因是，它可以保留甚至加强与开发团队的关系。开发人员通常不希望被告知如何完成他们的工作，而使用详细开发规范撰写的故事（无论是否有意）可能会使开发人员相信您不相信他们或您不认为他们他们为项目带来了创造性的价值。
措辞恰当的故事会为开发人员提供他们需要的最大呼吸空间，以实现他们的最佳工作。
想要更有效的用户故事？打破他们进一步。
让您的故事尽可能有效 - 对您的开发人员来说很清楚，易于完成，易于测试并获得内部认可 - 您想将它们分解为最小的逻辑单元。
例如，我们假设我们正在撰写“新管理控制台”功能的故事。用敏捷的术语来说，我们可以称之为史诗。你应该走多宽或粒状？
创建一个名为“管理员管理用户”的故事太广泛了。这并不能给开发者足够的细节来说明你想要的结果。在这种情况下，“管理”意味着什么？管理员能够在管理用户方面做些什么具体的任务？
这就是为什么当你提出这种功能的想法时，你需要把它分解成几个故事。例如：
管理员添加一个用户
管理员编辑用户
管理员删除一个用户
现在，您的开发人员有一系列清晰，高度特定的任务，他们知道如何完成。而且，作为奖励，您已将复杂的“管理用户管理”故事细分为足够多的组件，您甚至可以根据需要对其进行优先级排序。例如，您可以发布允许管理员添加和编辑用户的产品的早期版本，但不能删除它们。
如果你坚持原创，复杂的故事，整个事情会花费更长的时间，而这意味着你不能像将它分解成更小的碎片那样快速地将其中的任何一个发送出去。
“因为大事故的复杂性很高，所以它们也有很大的风险。如果你在80％或90％的道路上走下坡路，并意识到这个故事是基于错误的假设？将重要故事分解成更小的故事 。
看到此处说明本文对你还是有帮助的，关于“如何将产品功能分解成用户故事”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
