3、需求到功能的转化：从用户故事到功能列表、功能拆分的粒度控制、功能优先级划分（MoSCoW方法）

好，我们继续往下走。前面我们聊了怎么从业务需求里提炼出用户故事，那接下来呢？说白了，就是要把这些故事落地成真正的功能。

这一步，我见过太多团队栽跟头。要么功能拆得太粗，开发一脸懵；要么拆得太细，光看列表就晕了。嗯，这里咱们好好捋一捋。

3.1 从用户故事到功能列表

用户故事是站在用户视角说的「人话」。比如：「作为一个采购员，我想在提交订单前看到库存预警，这样能避免下单后才发现缺货。」

但开发团队需要的是「机器能懂」的东西。这时候就要做转化。

我个人习惯的做法是：一个用户故事，至少拆出 3-5 个具体功能点。举个例子：

用户故事	拆解出的功能点
采购员提交订单前看到库存预警	实时查询商品库存量 库存低于阈值时弹出警告框 警告框提供「忽略并继续」和「返回修改」按钮 记录用户对预警的响应行为

你看，一个故事就变成了四个功能点。每个点都是可测试、可估时的。

3.2 功能拆分的粒度控制

这是个大坑。我曾经在一个项目里，把「用户登录」拆成了 12 个功能点——包括「输入框获得焦点时边框变蓝」、「密码输入框显示/隐藏切换」……结果呢？光评审就花了半天，开发还嫌我管得太细。

那到底拆到什么程度算合适？我总结了一个「三句话原则」：

1. 一个功能点，能不能在 2-3 天内开发完？ 如果不行，说明拆得太粗。
2. 一个功能点，能不能用一句话说清楚？ 如果不行，说明拆得太细。
3. 一个功能点，是不是独立可测试的？ 如果不行，说明边界没划清。

举个例子。你想想看，「实现订单列表」这个描述，太粗了。它至少应该拆成：

• 查询订单列表（支持分页）
• 按状态筛选订单
• 按时间排序订单
• 点击订单行跳转详情页

每个点都能独立开发、独立测试。这才是好的粒度。

3.3 功能优先级划分（MoSCoW方法）

功能列表出来了，但资源有限啊。不可能所有功能都一起做。这时候就需要排优先级。

我比较推崇 MoSCoW 方法。这名字有点怪，其实是四个单词的首字母：

缩写	含义	解释
Must have	必须有	没有这个功能，系统无法上线或核心流程走不通
Should have	应该有	很重要，但暂时没有也能凑合用
Could have	可以有	锦上添花，有更好，没有也不影响核心
Won't have	这次不做	明确告诉所有人：这个版本不包含

怎么用呢？我一般会拉上产品、开发、测试三方一起过。每个人给功能点投票，然后讨论归类。

举个例子。一个电商系统的第一版，优先级可能是这样：

• Must have： 商品浏览、加入购物车、提交订单、支付接口
• Should have： 订单取消、退款申请、物流查询
• Could have： 商品收藏、历史浏览记录、价格提醒
• Won't have： 多语言支持、社交分享、积分商城

你看，这样一划，团队就知道先做什么、后做什么。不会出现开发到一半，产品突然说「哎呀，那个积分功能也很重要」的情况。

好了，总结一下今天的内容。从用户故事到功能列表，核心是「翻译」——把用户语言翻译成开发语言。功能拆分要控制粒度，别太粗也别太细。优先级用 MoSCoW 方法，让所有人对「做什么、不做什么」达成共识。

下一章，我们会聊聊这些功能怎么映射到软件的分层架构上。嗯，那才是真正考验架构师功底的地方。