翻译自 http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/
用户故事可能是在捕获产品功能方面流传最广泛的敏捷实践。
利用用户故事来工作是容易的,但是讲述有效故事却是有困难的。
如下的10个提示能帮助到写好用户故事。
如同名字所说明,一个用户故事描述了一个顾客或者一个用户如何使用产品;它是从用户角度来书写的。更重要的是,用户故事对于捕捉一个特定的功能特别有帮助,如,搜索产品或预订。
如果你不知道用户和客户是谁,以及他们为什么要使用该产品,那么你不应该写任何用户的故事。首先进行必要的用户研究,例如,通过观察和访谈用户。否则,你就是冒险写故事,那些故事只是基于信念和想法,而不是数据和经验证据的。
用于捕获你对于用户和客户的见解的一个伟大技术是人物角色刻画(Persona方法)。Persona是虚构的人物,是基于目标群体的第一手知识。Persona通常由一个名字和一张图片,相关的特点,行为和态度,和一个目标。目标是角色想实现的利益,或者角色想通过使用产品解决的问题。
但还有更多:人物角色的目标帮助你发现正确的故事:问自己的产品应提供什么样的功能来满足人物角色的目标。可以下载一个方便的模板来描述人物角色,参见 romanpichler。
用户故事不是一个规范,而是一个沟通和协作工具。故事不应该仅仅是交给一个开发团队,而是他们应该被嵌入在对话中:产品主管和团队应该一起讨论故事。
你可以采取进一步的合作来写故事,例如,作为你的产品待办列表优化过程的一部分。这充分利用了团队的创造力和知识,并得到更好的用户故事。
如果你不能在用户故事工作中让开发团队参与,那么你应该考虑使用另外更正式的技术来捕获产品的功能,例如,用例。
写故事,让他们容易理解。保持简洁明了。避免混淆和模棱两可的术语,并使用主动语态。专注于什么是重要的,放下其余的。
下面的模板将用户或客户建模为一个人物角色的故事,并使其利益显式。它是基于Rachel Davies的流行的模板,但我已经用人物角色的名字取代了用户角色,用于连接故事与相关的人物角色。
作为<人物角色名字>,
我想要<什么?>
那么<为什么?>。
使用模板时,它是有帮助的,但不觉得有义务总是适用于它。尝试不同的方法来写你的故事,了解什么是最适合你和你的团队。
史诗是一个大的、粗略的、粗粒度的故事。随着时间的推移,利用用户对于早期原型和产品增量的反馈,它通常会被分解成多个用户故事。你可以认为它是更详细的故事标题占位符。
从史诗开始,让你勾勒出产品的大功能而不是细节。这对描述新的产品和功能是特别有帮助的:它可以让你捕捉到粗糙的范围,它需要你后续时间来了解更多关于如何最好地满足用户的需求。它也减少了用于整合新见解的时间和精力。如果你在产品待办列表中积累了许多详细的故事,那么它往往是棘手的,并且需要耗费更多时间来获取反馈修改到适当的故事,你必须小心,不要引入不一致。
打破史诗到较小的、具体的故事,直到他们准备好:明确的,可行的,和可测试的。所有的开发团队成员应该有一个共同对故事意义的理解;这个故事不应该太大,适合放在一个冲刺中,并有一个有效的方法来确定故事是否完成。
当你为小故事打破史诗,记得加接受标准。接受标准可以用叙述来说明,描述故事完成的条件,只有这些条件达成了,故事才能判断为完成。接受标准使得故事更加丰富,变得可测,保证故事可以展示或发布给用户和其他利益相关者。作为一个经验法则,我喜欢用三到五的接受标准来详细的故事。
用户故事是在极限编程(XP)中出现的,早期的XP文字谈论多的是故事卡片而不是用户故事。有一个简单的原因:用户故事被写在纸上。这种方法提供了三个好处:一是,纸卡便宜,使用方便。第二,促进合作:每一个人都能拿出一张卡片,写下一个想法。第三,纸片可以很容易地分组在桌上或墙上,检查一致性和完整性,并且把依赖可视化。即使你的故事是以电子方式储存的,当你写新的故事时,也值得使用纸质卡片。
【译者说明:对于拥有Story工具+触摸屏的团队而言,纸卡不再是需要了,Story工具+触摸屏组合能够获得以上的所有好处,并且实时同步版上拖动操作与Story工具中操作,也便于异地合作,这2个方面是优于纸质卡片的,当然工具+触摸屏需要更多的成本】
故事要传达信息。因此不要将它们隐藏在网盘、企业内部网丛林或许可的工具上。使他们可见,例如,把他们放在墙上。这促进了合作,创造了透明度,并使它很明显,当你添加太多的故事太快,可能很快用光了墙壁空间。
【译者说明:如果使用了Story工具,它应当是线上工具,团队成员和干系人,无论身在何处,都能随时访问。】
创造一个伟大的用户体验(UX)需要更多的用户故事。用户的故事有助于捕获产品的功能,但他们不适合描述用户的体验流程和视觉设计。因此,补充用户故事与其他技术,如故事地图,流程图,故事板,素描,和模型。
此外,用户故事并不是很好的需求捕获技术。如果你需要沟通一个什么架构元素,比如组件或服务,那么写技术故事或是建模语言UML。
最后,当你开发的软件很有可能被重用,编写用户故事是值得的。但是如果你想快速创建一个一次性的原型或模型来验证一个想法,然后写故事可能不是必要的。记住:用户的故事并不是关于文档的需求,他们想让你快速移动和开发软件,尽快不施加任何开销。