敏捷开发——如何写好用户故事?
原创- 发表时间 2020-11-19
- 阅读数 7842
- 最后编辑:程一凡 于 2024-06-13 09:52:48
用户故事的起源
用户故事最早是极限编程里面提出的概念,并在scrum中也得到了广泛地应用。和需求文档或者原型图相比,用户故事以条目化的方式组织,维护起来简单,容易估算和排序,方便研发团队以小迭代的方式来完成交付。能否将产品拆分成粒度合适的用户故事,是整个团队能否实现敏捷的前提。
用户故事是什么?
用户故事是从用户的角度,来描述用户渴望得到的功能。一个好的用户故事包括三个要素:角色、活动和商业价值。- 角色是谁要使用这个功能;
- 活动是需要完成什么样的功能;
- 商业价值是为什么需要这个功能,这个功能可以带来什么价值。
通常,用户故事可以用一个简单的模板来概括:作为一名<某种类型的用户>,我希望<达成某些目的>,这样可以<带来哪些开发价值>。
比如“作为一名部门经理,我希望系统能有一个每日待办功能,这样我就可以了解到部门各个员工的工作进度了。”
为什么要写用户故事?
用户故事可以帮你将功能需求传达给研发团队。这样研发团队就会更容易理解,为什么要构建这个功能,用户将如何使用它。关于用户故事,通常可以用3个C来描述它:
- 卡片(Card)
- 交谈(Conversation)
- 确认(Confirmation)
用户故事怎么写才标准?
要写一个好的用户故事可以遵循Invest原则。- 独立的(Independent): 每个用户故事之间应该相互独立,尽可能避免故事间的相互依赖。
- 可协商的(Negotiable): 用户故事无需太过详尽,只是需求的简短描述,并且是可讨论的,具体细节是客户和开发团队在沟通阶段产出的。
- 有价值的(Valuable): 每个用户故事是对用户具有价值的,因此应站在用户角度进行编写。
- 可估算性(Estimable): 要进行开发的用户故事可进行粗略估算,以便团队了解工作量,并由PO决定是否需要重新设计用户故事或进行任务拆分。
- 短小的(Small): 一个好的用户故事要短小,至少确保在一个迭代或Sprint中完成。用户故事越大,在安排计划、工作量估算等方面的风险就会越大。
- 可测试性(Testable): 用户故事是具体的且可被测试的,如果用户故事过于含糊,测试就没有标准可循。
当我们真正理解了用户故事的价值,关于如何写出用户故事、用什么格式写等问题自然就迎刃而解了,因为我们已经完成了敏捷用户故事实践的本质——激发讨论、明确价值、达成共识。