用户故事可能是捕获产品功能的最流行的敏捷技术:使用用户故事很容易。但讲出有效的故事可能很难。以下十个技巧可以帮助您创建好的故事。
1. 用户第一
顾名思义,用户故事描述了客户或用户如何使用产品,它从用户的角度进行表达。另外,用户故事特别有助于捕捉特定的功能,例如搜索产品或进行预订。下图说明了用户,故事和产品功能(由圆圈表示)之间的关系。
如果你不知道谁是用户和客户,以及为什么他们会想要使用这个产品,那么你不应该写任何用户故事。首先进行必要的用户研究,例如通过观察和访问用户。否则,就有基于自己的想法和信念写出假想的故事的风险,而不是基于数据和经过验证的证据。
2. 使用角色来发现正确的故事
捕捉用户和客户的见解的一个很好的技术就是使用人物角色(Persona)。人物角色是基于目标群体的第一手知识的虚构人物。他们通常由一个名字和一张照片组成,还包括相关的特征、行为和态度、以及一个目标。目标是人物想要获得的利益,或者人物想要通过使用产品来解决的问题。
除此之外还有:人物角色的目标可以帮助你发现正确的故事:问问自己,为了达到人物角色的目标,产品应该提供什么样的功能。正如我在“ 从角色到用户故事” 的文章中解释的那样。您可以从romanpichler.com/tools/persona-template下载一个方便的模板来描述您的角色。
3. 合作创作故事
用户故事旨在作为一种轻量级的技术,使您能够更快。他们不是一个规范,而是一个协作工具。故事不应该交给开发团队。相反,他们应该被嵌入到一个对话中: 产品负责人(PO)和团队应该一起讨论这些故事。这使您只能捕获最少量的信息,减少开销并加速交付。
您可以进一步采取这种方法,让团队协作来写故事,这可以是产品backlog梳理过程中的一个环节。如果你不能让开发团队参与用户的故事工作,那么你应该考虑使用另一种更正式的技术来捕获产品功能,例如用例。
4. 保持你的故事简单和简洁
写下你的故事,以便他们很容易理解。保持简单和简洁。避免混淆和模棱两可的条款,并使用主动语态。专注于重要的东西,而忽略其余的东西。下面的模板将用户或客户建模为一个人物角色,并使其好处明确。它基于Rachel Davies的流行模板,但是我已经用人物角色(Persona)替换了用户角色(Role of User),将故事与相关角色联系起来。
作为<persona>,
我想要<what?>
以便<why?>。
有用时使用该模板,但不要总是使用它。尝试用不同的方法来写你的故事,以了解什么对你和你的团队最有效。
5.从Epics开始
史诗是一个大而粗略,粗糙的故事。它通常会随着时间的变迁而分解成多个用户故事 – 基于用户对早期原型和产品增量的反馈。你可以把它看作是一个标题和一个更详细的故事的占位符。
从史诗故事开始,能够让你在不关注太多产品详细信息的情况下捕获产品的功能。这对于描述新的产品和功能特别有帮助:它可以让您捕捉到粗略的范围,这节省了你了解如何最好地满足用户的需求的时间。
这也减少了整合新想法所需的时间和精力。如果在产品Backlog中有很多详细的故事,那么将反馈和对应的条目关联起来往往是非常棘手和耗时的,并且还有导致信息不一致的风险。
6.细化故事,直到准备就绪
把你的史诗分成更小,更详细的故事, 直到准备就绪:清晰,可用,可测试。所有的开发团队成员应该对故事的意义有一个共同的理解; 这个故事不应该太大且能放到一个Sprint,还必须有一个有效的方法来确定故事是否完成。
7.添加验收标准(AC)
当你把史诗分成更小的故事时,请记住添加验收标准。验收标准补充叙述:它们用来描述故事达到完成必须完成的条件。验收标准丰富了故事,使其成为可测试的,并确保故事可以演示或发布给用户和其他干系人。作为一个经验法则,我喜欢给详细的故事添加三到五个验收标准。
8.使用纸卡
用户故事出现在极限编程(XP)中,早期的XP文献讲述了故事卡而不是用户故事。有一个简单的原因:用户故事被捕获在纸卡上。这种方法提供了三个好处:首先,纸卡便宜且易于使用。其次,他们促进合作:每个人都可以拿一张卡片并记下一个想法。第三,卡片可以很容易地分组在桌子或墙上,以检查一致性和完整性,并可视化依赖关系。即使你的故事是以电子方式存储的,当你写新的故事时,使用纸卡也是值得的。
9.保持你的故事可见和可访问
故事要传达信息。因此,不要将其隐藏在你的服务器和电脑上。你可以把它们放在墙上,使它们可见。这会促进协作,创建透明度,而且你可以很快的发现你过快地添加了太多的故事,因为你的墙面快用完了。
我有一个方便的工具可以帮助你来发掘、可视化和管理你的故事,这就是我的产品画布。
如下所示。
10 不要单靠用户故事
创造出色的用户体验(UX)需要的不仅仅是用户故事。用户故事有助于捕捉产品功能,但不能很好地描述用户旅程和 视觉设计。因此,可以用其他技术来补充用户故事,例如故事地图,工作流程图,故事板,草图和模型。
另外,用户故事不能很好地捕捉技术要求。如果您需要传达像组件或服务这样的架构元素应该做什么,那么请编写技术故事,或者,根据我的偏好——使用像UML这样的建模语言。
最后,在开发可能被重用的软件时,编写用户故事是值得的。但是,如果你想快速创建一个一次性原型或模型来验证一个想法,那么写故事可能不是必要的。记住:用户故事不是关于记录需求; 他们希望能够使您更快并尽快开发软件,而不是强加额外的开销。
英文资料来源: http : //www.romanpichler.com/blog/10-tips-writing-good-user-stories/
作者:罗马·皮赫勒
译者:廖靖斌Eric Liao, Scrum中文网资深敏捷教练、顾问和培训师,CSP