借助用户故事，我们可以将调研所获得的用户需求描述给开发人员。那么，用户故事应当遵循什么样的格式？我们不妨结合案例，来看看作者的分享。

一、用户故事的概念

在敏捷开发中产品负责人 (Product Owner），要创建和管理产品待办事项列表（Product Backlog），产品待办列表中的事项是什么呢，本质就是用户需求，但是以用户故事（Story）的形式展示，用户故事是要用最简单的方式来将调研获得的用户需求描述给研发人员。

二、用户故事的格式

它的常见形式是在卡片上写上“谁”+“做什么”+“为什么”，如下所示：

作为___________；

我想/我能______________；

从而/以便我能_________________；

示例：

作为___商家________；

我想/我能___方便的发布店铺信息___________；

从而/以便我能____吸引潜在客户_____________；

再在卡片背后写上验收标准。

为什么要有验收标准，因为我想/我能，这个只是粗略的业务需求，还达不到研发需求，我们要借着用户故事跟研发了交流，我们要以什么的方案来实现需求，具体方案怎么落地，怎么验收，跟研发共同确认验收标准，这个验收标准也就是测试的验收用例。验收标准的常见格式是由“前提条件”+“出发点”+“期望结果”组成。

假设/给定___________；

当______________；

那么_________________；

示例：

假设/给定___商家输入完整的店铺信息________；

当______商家点击发布按钮________；

那么_____用户可以在网站查看到对应的店铺信息____________；

PS：一个故事，不是只有一个验收标准，可以有多个，支持1对多。

三、用户故事案例

下面用一个例子来讲述一下用户故事。

假设我们收到需求，要做一个财务系统，我们已经完成前期的用户调研，并了解到其中一个财务的工作内容为：

1. 收集原始凭证
2. 编制财务凭证

因近期业务发展，收集并核对原始凭证占用财务过多时间，希望能以更便捷的方式收集。

原始凭证：

是指经济业务发生或完成时取得或者填制的，用以记录或证明经济业务的发生或者完成情况的原始凭据。像等下场景中的会提到的订单，还有提到国家税务总局统一印制的全国通用的增值税专用发票，除此之外还有像制造型企业生产使用的领料单，当然我们最熟悉还是打工人发起的差旅费报销单等；

记账凭证：

记账凭证又称记账凭单，是指会计人员根据审核无误的原始凭证，按照经济业务的内容加以规归类，并据以确定会计分录后添置的会计凭证，作为登记账簿的直接依据。

业务场景一：

张三（打工人1号）：“我新人入职，购买了一台电脑，要报销”

李四（财务）：“这么多， 填下报销申请，申请人、申请日期、购买单据，发票这些都填好，报销申请表发你了”

张三（打工人1号）：“行，这个是我购买单据，我直接截图贴上去”

李四（财务）：“嗯，填好了再发我”

有了原始凭证之后，财务就要跟据原始凭证编制记账凭证，如下图所示；

这是一个记账凭证，使用的是借贷记账法，当前先不展开讲；

收集原始凭证的用户故事：

作为[财务人员] ；

我想要 [能够方便地收集原始凭证]；

以便 [确保财务数据的准确性和完整性，便于后续的财务处理和审计（生成记账凭证）]。

明确用户故事后，就可以展开讨论，逐步明确验收标准：

• （系统输入-系统加工逻辑-系统输出）
• 怎么方便收集原始凭证：对接自研业务系统
• 要收集原始凭证哪些信息：要有满足记账凭证所需信息，【“会计主体”、“业务名称”、“凭证字段”、“业务日期”、“业务金额”、“往来对象”】
• 是接收所有的业务单据吗：不是，要收集的单据类型有销售订单、采购……
• 需要业务人员做操作吗：可以查看收集到的原始凭证
• 系统响应时间、实时、容量有要求吗……

验收标准1：

假设接收到自研业务系统传来的原始凭证；

当原始凭证单据类型符合要求，且满足的字段要求【“会计主体”、“业务名称”、“凭证字段”、“业务日期”、“业务金额”、“往来对象”】时；

提醒自研业务系统原始凭证接收成功。

验收标准2：

假设接收到自研业务系统传来的原始凭证；

当原始凭证根据单据类型符合要求，并不满足财务凭证生成的字段要求【“会计主体”、“业务名称”、“凭证字段”、“业务日期”、“业务金额”、“往来对象”】时；

提醒第自研业务系统原始凭证字段缺失，请重新复核原始凭证。

验收标准3：

假设接收到自研业务系统传来的原始凭证；

当原始凭证单据类型不符合要求时；

提醒自研业务系统单据类型不符合要求，请重新确认单据类型配置。

你会怎么编制财务凭证这个用户故事及对应的验收标准呢？

结束语

用户故事是很便捷，也比较方便变更，但请注意它的适用场景，不是所有开发流程都适用。

在实际操作的过程中，可能考虑的问题还有很多，比如变更需求引起的研发成本、时间变更等等。你还会发现一开始的用户故事比较少，等进入研发阶段的是，又能拆解出很多小的用户故事，这都是很正常的，用户故事怎么拆解，怎么落地，这些都是要在实战中思考的，也再看看Invest法则，怎么才算一个好的用户故事。