×
登录
注册
简体
繁體
English
首页
资讯专栏
视频
活动专区
禅道官网
更多
文章专栏
敏捷
DevOps
项目管理
资源下载
报告
电子书
公开课
禅道公开课
敏捷夜话
创新实干派
冬哥有话说
科普系列
项目管理
Scrum
极限编程
程序员修炼之道
程序员英文发音
禅道教程
禅道使用
常见问题
交流群
活动合作
关于我们
敏捷开发——如何写好用户故事?
2021-04-13 10:28:00
LuLu
10668
原创
用户故事的起源
用户故事最早是极限编程里面提出的概念,并在scrum中也得到了广泛地应用。和需求文档或者原型图相比,用户故事以条目化的方式组织,维护起来简单,容易估算和排序,方便研发团队以小迭代的方式来完成交付。
能否将产品拆分成粒度合适的用户故事,是整个团队能否实现敏捷的前提。
用户故事是什么?
用户故事是从用户的角度,来描述用户渴望得到的功能。一个好的用户故事包括三个要素:角色、活动和商业价值。
角色是谁要使用这个功能;
活动是需要完成什么样的功能;
商业价值是为什么需要这个功能,这个功能可以带来什么价值。
通常,用户故事可以用一个简单的模板来概括:作为一名<某种类型的用户>,我希望<达成某些目的>,这样可以<带来哪些开发价值>。
比如“作为一名部门经理,我希望系统能有一个每日待办功能,这样我就可以了解到部门各个员工的工作进度了。”
为什么要写用户故事?
用户故事可以帮你将功能需求传达给研发团队。这样研发团队就会更容易理解,为什么要构建这个功能,用户将如何使用它。
关于用户故事,通常可以用3个C来描述它:
卡片(Card)
用户故事可以写在卡片上,内容包括用户故事的简短描述、验收标准等。
交谈(Conversation)
用户故事背后的细节,来源于跟客户或产品负责人的交流沟通。
确认(Confirmation)
通过验收测试,确认用户故事被正确完成。
用户故事怎么写才标准?
要写一个好的用户故事可以遵循Invest原则。
独立的(Independent): 每个用户故事之间应该相互独立,尽可能避免故事间的相互依赖。
可协商的(Negotiable): 用户故事无需太过详尽,只是需求的简短描述,并且是可讨论的,具体细节是客户和开发团队在沟通阶段产出的。
有价值的(Valuable): 每个用户故事是对用户具有价值的,因此应站在用户角度进行编写。
可估算性(Estimable): 要进行开发的用户故事可进行粗略估算,以便团队了解工作量,并由PO决定是否需要重新设计用户故事或进行任务拆分。
短小的(Small): 一个好的用户故事要短小,至少确保在一个迭代或Sprint中完成。用户故事越大,在安排计划、工作量估算等方面的风险就会越大。
可测试性(Testable): 用户故事是具体的且可被测试的,如果用户故事过于含糊,测试就没有标准可循。
当我们真正理解了用户故事的价值,关于如何写出用户故事、用什么格式写等问题自然就迎刃而解了,因为我们已经完成了敏捷用户故事实践的本质——激发讨论、明确价值、达成共识。
©
SQL查询:
70
次内存占用:
4.00MB
PHP 执行时间:
0.38
秒
鲁ICP备18054969号-21
ZSITE
8.6