为什么用户故事失败

摘要

用户故事是一种强大的敏捷技术，可以从客户和用户的角度描述需求。 不幸的是，我发现用户故事失败并没有成功应用并且失败的情况并不少见。 这篇文章描述了两种常见的失败原因，并讨论了如何避免它们。

错误的上下文

顾名思义，用户故事就是一个故事：它们用通俗易懂的语言描述了客户或用户如何使用该产品。 用户故事没有指定每个小细节，而是提供了一种非正式的方式来捕获需求。 如果故事得到了产品经理/产品负责人与开发团队之间的对话的补充，则可以奏效。 在对话中，产品人员向团队讲故事； 团队成员提出问题并提出调整建议。 理想情况下，每个人都在同一个房间里面对面地进行对话。 这种非正式和协作方法的好处是双重的：它导致更好的需求，并通过从书面需求转变为隐性知识来节省时间。

不幸的是，即使很难实现有效的对话，我也看到组织会应用用户故事。 与其一起讨论和完善故事，不如将它们交给开发团队。 通常，团队很遥远，对市场和产品的了解有限。 为了解决缺少的对话，产品经理或所有者尝试编写详尽，细节丰富且精确的故事。 这将用户故事变成了他们不被设计的东西：正式需求。

如果您遇到类似的情况，那么您有两种选择：确保进行有效的对话，例如，通过定期举行现场研讨会或使用视频会议与开发团队讨论和调整故事。 或者使用其他需求描述技术，例如用例。 用例提供了更多的结构，并使得更容易精确地描述需求，例如，通过使用前提条件和异常情况。

错误的工作

用户案例描述了最终用户需求。 它们并非旨在捕获技术要求。 当然，您可以讲述有关产品制造方式的故事并使用技术故事。 但是我发现自然语言不太适合满足技术要求，我更喜欢使用UML（统一建模语言）之类的建模语言。 当您可以使用UML人工制品进行建模和可视化时，为什么还要用自然语言描述接口或API？

如果您发现您的团队严重依赖于技术要求，那么这可能表明您与组件团队合作-围绕架构构建块（例如组件，服务和层）组织的团队。 减少对技术要求的一种有效方法是通过组成要素团队来重组团队，这些要素团队以垂直切片的形式端到端实施用户故事。

但是，不应仅将技术要求视为用户案例。 复杂的用户交互（例如工作流和方案）以及用户界面要求也很难描述为用户故事。 以一家要求用户发现产品，选择产品并将其放在购物篮中并付款的网上商店为例。 如果您试图用一个故事来描述这些步骤，那么您要么会遇到一个大的复合故事，要么会使用验收标准来描述工作流程。 在我看来，这都不是可取的。 更好的解决方案是使用故事来描述离散的功能需求，并用其他技术（例如故事地图，场景，工作流图和故事板）来补充它们。 我将在我的文章“ 用户故事不足以创造出色的用户体验”中更详细地讨论这种方法。

翻译自: https://www.javacodegeeks.com/2015/10/why-user-stories-fail.html