敏捷开发——如何写好用户故事?

原创
🐻
LuLu
发表时间 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): 用户故事是具体的且可被测试的,如果用户故事过于含糊,测试就没有标准可循。
 
当我们真正理解了用户故事的价值,关于如何写出用户故事、用什么格式写等问题自然就迎刃而解了,因为我们已经完成了敏捷用户故事实践的本质——激发讨论、明确价值、达成共识。


附件:
    返回顶部
    刘璐
    高级客户经理
    18562550650
    2845263372
    统一服务热线 4006-8899-23
    我要提问提问有任何问题,您都可以在这里提问。 问题反馈反馈点击这里,让我们聆听您的建议与反馈。