故事卡要尽量简洁，而不是什么都写得很详细；同时也要尽可能的完整准确，而不是缺乏细节，含糊不清。 　　

　　

　　这是我的基本观点，我的考虑如下： 　　

　　

　　简洁是指读者获取的信息经过提炼，读者阅读效率更高。简洁意味着BA可以更高效地写卡，把更多的精力投入到其他更有挑战性的工作中。完整和准确意味着故事卡经过讨论并达成一致。完整性和准确性意味着故事卡有明确的验收标准。完整准确意味着故事卡便于追溯和传递。基于以上观点，再次分类。大家说说吧。 　　

　　

　　页面交互描述 　　

　　

　　上图显示了添加新账户功能的UI设计。该功能要求的描述可以是： 　　

　　

　　用户可以通过主菜单进入“权限管理”模块，选择“账户管理”标签页，可以看到“添加账户”按钮。点击“添加账户”按钮，系统会弹出添加账户窗口(也可以写“灰色背景”)。用户可以在窗口中填写自己的姓名，登录自己的邮箱……如果用户没有填写必填字段，点击“确认”时会给出错误提示：“请填写所有必填字段！”点击“确认”按钮，将弹出第二个确认窗口。第二条确认消息是“您确定要创建此帐户吗？”一旦成功创建账户，将通过电子邮件通知相应的用户”。如果用户再次选择“确认”，账号将被创建；如果用户选择“取消”，将返回账号填写窗口。这些描述没有错误，应该还是能满足很多Dev同学或者QA同学的胃口，但是在我看来太臃肿了。尝试考虑简化哪些信息不会影响开发人员编码和理解每个角色的业务： 　　

　　

　　详细的操作步骤描述是否必要？ 　　

　　

　　通常没有必要。一般这些内容在设计图或者简单的交流中很容易表达，主要路径可以简单的用故事卡表达。细节描述制约了设计和实现，让故事卡臃肿不堪。 　　

　　

　　描述所有字段是否有必要？ 　　

　　

　　通常是需要的，但是应该从业务的角度来描述，后面会详细讨论。 　　

　　

　　详细地描述用户操作后的系统反馈是否有必要？ 　　

　　

　　通常没有必要，因为绝大多数系统反馈是公知的或显而易见的。比如，弹窗底部的页面变灰，弹窗上的“取消”按钮点击后会关闭窗口，等等。什么是“不寻常”的情况？根据业务目标期望来自系统的反馈是很常见的。比如我会注明“用户创建成功后页面要跳回列表页面”，因为我知道管理员一般都是批量创建多个用户，这样效率更高。 　　

　　

　　二次确认功能中的文案是否有必要详细描述呢？ 　　

　　

　　很多时候是需要的，因为这些文案通常是想表达一个特定的商业意义。用完美的文案表达这种商业意义是巴的职责。反过来的情况呢？比如一些常规删除操作的确认副本，就不需要一一描述了。可以和团队约定，所有的删除操作都需要二次确认，所有的二次确认副本都是“确认删除这个xx？删除后无法恢复”，如有特殊情况，另行说明。 　　

　　

　　那么对于上面的要求，我的描述会是这样的： 　　

　　

　　「 　　

　　

　　管理员可以创建新用户。 　　

　　

　　路径：后台管理-权限管理-账户管理-“添加账户”按钮添加账户所需的字段名称…登录邮箱，一旦成功创建账户，将会通过邮件通知相应的用户 　　

　　

　　综上所述，在我看来，故事卡通常不应该过多描述页面交互，这样可能会束缚设计和实现，容易让故事卡失去业务重心。然而，如果一个预期的交互是独特的，或者交互本身是一个重要的接受点，那么就有必要简明准确地表达它们。 　　

　　

　　业务逻辑的描述这里的业务逻辑可以狭义地理解为功能需求中的规律或规则，我认为就是“如果有，一定要体现在故事卡中”的内容。我的理由如下： 　　

　　

　　它们通常适用于特定的业务场景，不能从一般认知中推导出来。它们通常是核心，直接决定了需求能否实现预期收益。它们通常很复杂，很难记忆。所以我们可以直接讨论如何简洁准确地描述这些规则。 　　

　　

　　我已经处理了一个预定交货的要求。背景：客户购买“我们的”商品，物流承运商负责将商品送到客户的仓库。但是，在客户的仓库中经常会出现没有可用位置的情况，导致承运人将货物交付到仓库，但无法卸载货物进行仓储。解决方案是客户端开发预留仓库空间的功能并提供接口。我们调用接口来告诉客户端期望的交货信息。客户系统会预留仓位并反馈预计发货时间，承运商确认后按照预计发货时间发货。 　　

　　

　　这种业务场景的特点是每个节点都有多种不确定性，会对后续流程产生不同的影响。在业务已经梳理清楚的前提下，这其实是一个如何表达结构化信息的问题。 　　

　　

　　首先，尝试给出的表达式，然后： 　　

　　

　　「 　　

　　

　　AC01预约日期在窗口范围内。 　　

　　

　　当客户系统返回“在预订窗口内”的预订日期时 　　

　　

　　然后通过电子邮件通知承运商进行确认，更改预订单的状态为“待承运商确认” 　　

　　

　　02 AC02的预约日期在窗口之外。 　　

　　

　　当客户端系统返回一个“在预约窗口之外”的预约日期并且它没有被手动确认时。 　　

　　

　　然后给销售负责人发邮件，协调并更改预订表格的状态。 　　

为“待销售确认”

　　

AC03 预约日期已人工确认

　　

WHEN 客户系统返回了“不在预约窗口范围内”但被标记为“已人工确认”的预约日期

　　

Then 预约成功，变更预约单状态为“预约完成”，邮件通知承运商按预约日期送货

　　

……

　　

」

　　

看起来能把每个细节表达清楚，但可读性比较差，读者可能需要额外的effort 才能理清各场景间的逻辑关系。
然后尝试下“BA 式”的伪代码：

　　

「If 约定时限内获取到了客户系统反馈的预约日期{ if 日期在预约窗口范围内 邮件通知承运商确认，变更预约单状态为“待承运商确认”； else if 日期已人工确认 预约成功，变更预约单状态为“预约完成” else 邮件通知销售负责人协调处理，变更预约单状态为“待销售确认”}else…」逻辑关系表述清楚了，但阅读大段满载逻辑的文字的体验仍然不好，似乎可以再简洁点。

　　

最终我将这些规则用状态转换图描述出来，然后与Dev 和QA 同学沟通是否可以用这张图当做验收条件。在与他们讲解了这个图后，大家认为只要对图中各节点的业务意义达成一致并约定好Scope（而这些是比较容易的），这样的表述是更清晰、更友好的，于是我们愉快地接受了这种方式。

　　

　　

简单总结一下，在我看来，对业务逻辑的表述是写故事卡的重点和难点，BA 应该结合项目和需求特征选择最佳表达形式，不用拘泥于固定的格式，其中图表经常是不错的选择。关于图表的使用有以下tips 供参考：

　　

复杂条件组合产生不同系统行为 （比如积分判定规则）> 判定表、判定树或事件 - 响应表复杂状态规则（比如订单状态规则）> 状态流转图或状态表复杂业务流程 （比如采购流程）> 业务流程图……另外，团队需要就如何理解这些新的表达方式达成一致。

　　

　　

　　

关于对列表和表单的描述列表和表单是最常见和最基础的需求，往往套用固定的模式就可以将其表述清楚。

　　

列表类需求常见的几要素

　　

功能权限：谁在什么条件下可以使用该表单数据权限：数据范围的控制通常体现在列表上，比如用户仅可见owner 是他自己的订单记录。排序规则：列表中的记录通常需要按一定的规则进行排序以便查看分页规则：如果某些列表中可以预见地记录不会太多，那么不一定需要分页，Dev 可以更简单地处理这样的列表。字段清单：对列表中所有字段的描述。UX 的设计图中会有这部分内容的体现，但经验看来设计图中不容易也不需要很及时地反馈字段的变化，在某些条件下设计图也无法体现所有字段。字段属性：字段对应的业务含义，告诉读者这个字段的值从何而来，如果某字段有特殊规则也可以在这里体现。比如【持续时长】字段是为了方便用户查看，实际不对应数据库字段，那这里就可以描述它的取值规则为“【当前时间】 - 【开始时间】，向上取整天”；再比如【门店名称】通常较长但又很重要，我会描述“鼠标hover 在【门店名称】时可查看其完整信息”。

　　

一个有关列表的验收条件参考如下：

　　

「

　　

AC01 查看发货单列表

　　

路径：主菜单 > 发货单列表功能权限：权限管理中新增“查看发货单”权限，仅具有该权限的用户可见“发货单列表”菜单并访问列表数据数据权限：承运商用户仅可查看他负责的发货单，销售用户仅可查看他负责的客户的发货单，其他角色可见所有发货单排序规则：按发货单创建时间倒序排列分页规则：15个/页字段详情及顺序【发货单创建时间】系统接收到承运商TMS 系统推送的发货单的时间，精确到分钟【发货单号】承运商TMS 系统的发货单号【门店订单号】发货单对应门店订单的编号【门店名称】发货单对应的收货门店名称，鼠标 hover 可查看完整名称……」

　　

关于表单类功能需求

　　

表单通常是用于创建记录、更新记录、查看记录的详细信息，相比列表类需求对字段属性的描述有以下几点需要注意：

　　

是否必须。数据类型：比如对于时间类型字段，前端同学会处理为日期&时间选择器。校验规则：比如对用户名格式或对密码复杂度的校验。若是pick list，那么选项是什么：选项可能是一些枚举值，也可能是自另外的一个业务实体（比如为订单选择客户），需要详细说明。字符长度：从业务角度给出字段长度建议。所以某个表单的描述可能是这样的：

　　

「

　　

……字段详情及顺序【姓名】必填，50字符【出生年月】必填，日期类型【省份】必填，单选，从基础数据 region 表中取值【城市】必填，单选，从基础数据 region 表中取值，与【省份】联动【家庭成员数量】必填，正整数【联系邮箱】非必填，100字符，校验为邮箱格式……」

　　

这里面也有几个可以探讨的问题：

　　

1、对于【联系人邮箱】字段，通常会有对于邮箱格式的校验。那么BA在故事卡里是否需要详细描述校验规则？

　　

我的建议是没必要。因为邮箱的格式校验是一个有着“普遍认同”的规则，并不具备独特的业务价值，不该因为BA 的表述不同而不同。所以，这种问题可以交给Dev 同学。

　　

2、是否需要以及如何描述字符长度/数值范围？

　　

我的建议是可以描述。以字符长度为例，大多数字段其实是比较容易推断出字符长度的，比如“订单状态”，10个字符足矣，Dev 和BA 从各自视角判断通常也偏差不大。那既然如此，BA 就顺手写出来吧，更何况存在某些字段在特定业务场景下有特殊要求的可能。

　　

可能还有其他问题可以进一步讨论，但总而言之，对于列表和表单类需求通常可以复用一套模板，再结合业务场景调整就可以搞定。

　　

关于对接口的描述个人最喜欢的就是接口类的故事卡了，无他，但简单尔。

　　

对于接口类需求，我通常做法是

　　

BA 定义好接口业务上的数据结构、业务主键与Dev 线下讨论达成一致Dev 补充技术细节形成接口文档把接口文档附在故事卡里，补充业务场景、调用频率（对于主动拉取数据类接口）、错误处理机制（比如提交订单失败后应重试还是立即报错）、接口获取/提供的信息的特殊处理（比如外系统给到的订单我们要按照自己的规则生成新的订单编号）等必要信息。最后，对用户故事业务价值的描述和故事卡的拆分也简单分享下我的理解我非常赞同每个故事卡都应该产生业务价值，并且我们应当将这个价值显式地表达出来。而实践下来，我发现一段“freestyle” 式的描述常常比“作为一个 <角色> , 我想要 <功能> , 以便于 <业务价值> ”这样的表述方式更容易上手。

　　

比如，某个需求是从主数据系统定时获取最新的产品主数据，那么我会用这样的一段文字来描述：

　　

Summary：当前条件下，系统中的产品数据来自于每月客户侧产品经理给到的Excel 文件更新。客户自主研发的主数据平台已与上个月正式上线，并对外提供了数据分发接口，我们可以通过它提供的产品主数据接口每天获取产品主数据的更新，以解决手工更新带来的更新不及时、手工处理出错等问题。

　　

基于这种更自然的表达方式，我可以轻松地描述更多有价值的信息。

　　

最后是我对INVEST 原则（好的用户故事的编写应满足的几个原则）的一些理解：

　　

独立性（Independent） ：应尽量避免故事间的强依赖，但若必须有强依赖，那么这些卡片应该可以在同一个迭代中完成。非独立的故事会造成估算、排优先级和制定技术方案的难度。避免强依赖的方法可以有合并故事卡、换个维度拆分故事等，实在不行也不用强求，按依赖排好优先级即可。可讨论的（Negotiable）：实现方案是可讨论的，但业务目标应是明确的；讨论是必要的，对方案达成一致更不可缺少；可讨论不是BA 不去提前思考具体解决方案的借口，更不是卡片中验收标准不明确的说辞。有价值（Valuable）：我想不出我们去做一个没有价值的需求的理由…… 姑且把这一条理解为在写下这张卡片时我们应该已充分了解它能解决的问题或带来的收益，并且所有角色已经对此达成一致。可以估算（Estimable）：估算通常是为了排期，为了可以估算故事的规模应该足够小，团队对故事应该有充分的了解，并可以就故事内容对技术实现方案基本达成一致。足够小（Small）：更小的故事有助于更准确的工作量评估或多人并行工作，可以让故事卡在卡墙上更快流动起来，但也不必过分追求小故事，不少情况下 Dev 一次代码提交同时处理两个关联需求要比先后处理这两个需求要更简单、高效，如果Dev 经常说“这几张卡我一起开了吧”或“关了吧”时，BA 可以请教一下他的想法，也许能发现值得改进的地方。可测试（Testable）：故事卡中描述的输入和输出是明确的、可度量的。文章的最最后，再总结下我的观点我认同故事卡里非常详细的描述可以带来价值，但我也相信“简练的表述 + 充分的沟通”可以更高效、更灵活。我认同故事卡不是契约或合同，但我也相信完整、准确的表述可以显著降低各角色间的沟通成本。我认同可工作的软件高于详尽的需求文档，但我也相信高质量的需求文档可以带来很多收益。我认同最佳实践和个人经验（包括本文以上所有内容）的参考价值，但我更相信因地制宜、团队共建的实践才是最好的选择。文/Thoughtworks李响

　　

原文链接：https://insights.thoughtworks.cn/how-to-story-card/