写好用户故事的10个技巧

用户故事可能是最流行的捕捉产品功能的敏捷技术：使用用户故事很容易。但讲述有效的故事可能很难。以下十个技巧可帮助您创作好故事。

1 用户至上

顾名思义，用户故事描述了客户或用户如何使用产品；它是从用户的角度讲述的。此外，用户故事对于捕捉特定功能特别有用，例如搜索产品或进行预订。下图说明了用户、故事和产品功能（用圆圈表示）之间的关系。

如果你不知道谁是用户和客户，以及为什么他们会想要使用的产品，那么你应该没有写任何用户故事。首先进行必要的用户研究，例如，通过观察和采访用户。否则，您将冒着写基于信念和想法的投机故事的风险，而不是基于数据和经验证据。

 

 

 

2 使用角色来发现正确的故事

捕捉您对用户和客户的洞察力的一种很好的技术是使用角色。角色是基于目标群体的第一手知识的虚构角色。它们通常由名称和图片组成；相关特征、行为和态度；和一个目标。目标是角色想要实现的利益，或者角色希望通过使用产品解决的问题。

但还有更多内容：角色目标可帮助您发现_正确的_ 故事：正如我在从角色到用户故事的文章中解释的那样，问问自己产品应该提供哪些功能来满足角色的目标。

 

 

 

 

3 合作创作故事

用户故事旨在作为一种轻量级技术，可让您快速移动。它们不是规范，而是协作工具。故事永远不应该交给开发团队。相反，它们应该嵌入到对话中： 产品负责人和团队应该一起讨论这些故事。这使您可以仅捕获最少量的信息、减少开销并加速交付。

您可以进一步采用这种方法，将协作编写故事作为产品待办列表整理过程的一部分。这可以利用团队的创造力和知识，并产生更好的用户故事。

如果您不能让开发团队参与用户故事工作，那么您应该考虑使用另一种更正式的技术来捕获产品功能，例如用例。

 

 

 

 

4 保持你的故事简单明了

写下你的故事，使它们易于理解。保持它们简单和简洁。避免混淆和模棱两可的术语，并使用主动语态。专注于重要的事情，而忽略其余的事情。下面的模板将建模为角色的用户或客户放入故事中，并使其利益明确。它基于 Rachel Davies 的流行模板，但我已将_用户角色_替换_为角色名称，_以将故事与相关角色联系起来。

作为 ，我想要 <what?>  所以 <why?>。

在有用时使用模板，但不必总是应用它。尝试用不同的方式来写你的故事，以了解什么最适合你和你的团队。

5 从史诗开始

史诗是一个宏大的、粗略的、粗略的故事。随着时间的推移，它通常被分解为几个用户故事——利用用户对早期原型和产品增量的反馈。您可以将其视为标题和更详细故事的占位符。

从史诗开始，您可以勾画产品功能，而无需承诺细节。这对于描述新产品和功能特别有帮助：它允许您捕捉粗略的范围，并为您争取时间来了解更多关于如何最好地满足用户需求的信息。

它还减少了整合新见解所需的时间和精力。如果产品待办列表中有许多详细的故事，那么将反馈与适当的项目相关联通常是棘手且耗时的，并且存在引入不一致的风险。

6 细化故事直到它们准备好

将您的史诗 (Epic) 分解成更小、更详细的故事， 直到它们准备就绪：清晰、可行且可测试。所有开发团队成员都应该对故事的含义有共同的理解；故事不应该太大，并且可以轻松地适应冲刺；并且必须有一种有效的方法来确定故事是否完成。

 

 

7 添加验收标准

当您将史诗分解成更小的故事时，请记住添加验收标准。验收标准补充叙述：它们允许您描述必须满足的条件，以便故事完成。这些标准丰富了故事，使其可测试，并确保故事可以演示或发布给用户和其他利益相关者。根据经验，我喜欢对详细故事使用三到五个验收标准。

8 使用纸卡

用户故事出现在极限编程 (XP) 中，早期的 XP 文献谈论的是故事_卡_而不是用户_故事_。原因很简单：用户故事被记录在纸卡上。这种方法提供了三个好处：首先，纸卡便宜且易于使用。其次，它们促进协作：每个人都可以拿一张卡片记下一个想法。第三，卡片可以轻松地在桌子或墙上分组，以检查一致性和完整性并可视化相关性。即使您的故事以电子方式存储，在编写新故事时使用纸卡也是值得的。

9 保持你的故事可见和可访问

故事想要传达信息。因此，不要将它们隐藏在网络驱动器、企业 Intranet 丛林或许可工具中。例如，将它们挂在墙上，使它们可见。这促进了协作，创造了透明度，并且在您过快添加太多故事时变得显而易见，因为您将开始耗尽墙壁空间。一个方便的工具来发现、可视化和管理你的故事是我的产品画布 如下所示。

 

10 不要仅仅依赖用户故事

创建出色的用户体验 (UX) 需要的不仅仅是用户故事。用户故事有助于捕捉产品功能，但它们不太适合描述 用户旅程和 视觉设计。因此，用其他技术补充用户故事，例如故事地图、工作流图、故事板、草图和模型。

此外，用户故事不能很好地捕捉技术需求。如果您需要传达像组件或服务这样的架构元素应该做什么，然后编写 _技术故事，_或者——这是我的偏好——使用像 UML 这样的建模语言。

最后，当您开发可能会重复使用的软件时，编写用户故事是值得的。但是如果你想快速创建一个一次性原型或模型来验证一个想法，那么写故事可能没有必要。请记住：用户故事与记录需求无关；他们希望让您能够快速行动并尽快开发软件——而不是强加任何开销。

 

 

posted on 2021-11-09 15:06  Lynch_Warren  阅读(577)  评论(0)    收藏  举报

导航