文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

关于编写故事卡的一些经验

2024-12-02 03:32

关注

故事卡应尽量简练,而非事无巨细应写都写;同时,应尽量完整、准确,而非缺少细节、模棱两可。

这是我的基础观点,我的考虑如下:

基于以上观点再分类别展开聊下。

关于对页面交互的描述

上图展示了一个添加新账号功能的 UI 设计。一种对该功能需求的描述可能是:

这些文字描述没有任何错误,应该还符合不少 Dev 同学或 QA 同学的胃口,但在我看来过于臃肿。尝试思考简化哪些信息不会影响 Dev 编码和各角色理解业务:

(1) 详细的操作步骤描述是否必要?

通常是不必要的。一般情况下设计图或简单的沟通是很容易表达这些内容的,故事卡中简单地表述主要路径即可,详细的描述反而约束了设计和实现,并且让故事卡变得臃肿。

(2) 描述所有字段是否有必要?

通常是需要的,但应该是从业务角度描述,后文有详细聊到。

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

通常不是必要的,因为绝大多数的系统反馈是约定俗称或显而易见的。比如 popup 窗口下方的页面是被置灰的,popup 窗口上的“取消”按钮点了后会关闭窗口,等等。那什么是“不通常”的情况呢?常见的是期望系统根据业务目标给出的反馈,比如我会注明“创建用户成功后页面应跳转回列表页”,因为我知道管理员通常会批量创建多个用户,这样效率更高。

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

很多时候是需要的,因为这些文案通常是想表达特定的业务含义的,用完美的文案将这层业务含义表达出来是 BA 的职责。那反过来的情况呢?比如一些常规的删除操作的确认文案就不需要一一描述,可以与团队约定好所有的删除操作都需要二次确认,所有的二次确认文案都是“确认删除该xx?删除后不可恢复”,如有特殊情况再单独表述。

那么对于上面的需求,我的描述会是这样的:

权限管理员可创建新的用户:

(1) 路径:后台管理端 - 权限管理 - 账号管理 - “新增账号” button

(2) 新增账号所需字段

(3) 确认创建账号需二次确认,文案“确认创建该账号?账号一旦创建成功即会邮件通知对应用户”

简单总结一下,在我的观点中,故事卡通常不应对页面交互做过多描述,这样可能会约束设计和实现,还容易让故事卡失去业务焦点。但若某个期望的交互具有独特性或交互本身就是重要的验收点,那么将他们简练、准确地表述出来也是必要的。

关于对业务逻辑的描述

这里的业务逻辑可以狭义地理解为功能需求中的规律或规则,是我认为“如果有则必须体现在故事卡”的内容。我的理由如下:

所以我们可以直接讨论下如何简洁、准确地描述这些规则。

曾经处理过一个关于预约送货的需求。背景是客户采购“我们”的商品,物流承运商负责将货物运送到客户仓库,但客户仓库常出现没有可用仓位而导致承运商送货到库却又无法卸货入库的情况。解决方案是客户侧开发预约留库位功能并提供接口,我们调用该接口,告诉客户方系统预计送货信息,客户系统对应预留仓位并反馈期望送货时间,承运商确认后按该时间送货。

这个业务场景的特点在于每个节点都有多种不确定性,由此为后续流程带来不同的影响。在业务已经梳理清晰的前提下,这其实就是一个如何表达结构化信息的问题。

首先试下 Given When Then 的表达方式:

AC01 预约日期在窗口范围内

When 客户系统返回了“在预约窗口范围内”的预约日期

Then 邮件通知承运商确认,变更预约单状态为“待承运商确认”

AC02 预约日期在窗口范围外

When 客户系统返回了“不在预约窗口范围内”的预约日期,且未人工确认

Then 邮件通知销售负责人协调处理,变更预约单状态为“待销售确认”

AC03 预约日期已人工确认

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

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

……

看起来能把每个细节表达清楚,但可读性比较差,读者可能需要额外的 effort 才能理清各场景间的逻辑关系。

然后尝试下 “BA 式” 的伪代码:


If 约定时限内获取到了客户系统反馈的预约日期
{
if 日期在预约窗口范围内
邮件通知承运商确认,变更预约单状态为“待承运商确认”;
else if 日期已人工确认
预约成功,变更预约单状态为“预约完成”
else
邮件通知销售负责人协调处理,变更预约单状态为“待销售确认”
}
else…


逻辑关系表述清楚了,但阅读大段满载逻辑的文字的体验仍然不好,似乎可以再简洁点。

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

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

另外,团队需要就如何理解这些新的表达方式达成一致。

关于对列表和表单的描述

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

列表类需求常见的几要素:

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

AC01 查看发货单列表:

(1) 路径:主菜单 > 发货单列表

(2) 功能权限:权限管理中新增“查看发货单”权限,仅具有该权限的用户可见“发货单列表”菜单并访问列表数据

(3) 数据权限:承运商用户仅可查看他负责的发货单,销售用户仅可查看他负责的客户的发货单,其他角色可见所有发货单

(4) 排序规则:按发货单创建时间倒序排列

(5) 分页规则:15个/页

(6) 字段详情及顺序

关于表单类功能需求

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

所以某个表单的描述可能是这样的:

(1) ……

(2) 字段详情及顺序

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

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

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

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

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

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

关于对接口的描述

个人最喜欢的就是接口类的故事卡了,无他,但简单尔。

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

最后,对用户故事业务价值的描述和故事卡的拆分也简单分享下我的理解

我非常赞同每个故事卡都应该产生业务价值,并且我们应当将这个价值显式地表达出来。而实践下来,我发现一段“freestyle” 式的描述常常比“作为一个 <角色> , 我想要 <功能> , 以便于 <业务价值> ”这样的表述方式更容易上手。

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

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

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

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

文章的最最后,再总结下我的观点

来源:Thoughtworks洞见内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯