Product Backlog 第5组 - xiaochu-dev/online-shopping-group5 GitHub Wiki
在线购物系统 产品订单（Product Backlog）
| 项目 | 内容 |
|---|---|
| 项目名称 | 在线购物系统（挑战升级） |
| 版本范围 | MVP（第 1 次迭代） |
| 项目组号 | 第 5 组 |
| 产品负责人 | 周到（Product Owner） |
| 编制日期 | 2026-10-04 |
| 依据文档 | 《需求规格说明书-第5组》v1.0、《需求澄清结论-第5组》 |
文档说明：产品订单（Product Backlog）是项目的概要文档，包含所有特性的粗略描述与估算。
本文件覆盖 MVP 迭代的完整需求池；后续迭代的新增特性在此表末尾追加，不删除历史条目。
一、优先级定义
| 等级 | 代号 | 含义 | 处理原则 |
|---|---|---|---|
| 高 | P0 | 阻塞级。缺失则主流程走不通，评审演示无法进行 | 本次迭代必须全部完成 |
| 中 | P1 | 完整级。主流程可跑但功能不完整，验收会扣分 | 本次迭代应完成 |
| 低 | P2 | 增强级。体验优化、非基线要求 | 有余力再做，可延后 |
故事点估算：采用斐波那契数列（1 / 2 / 3 / 5 / 8），表示相对工作量，非工时。
二、MVP 产品订单（Sprint 1 范围）
EPIC-A 卖家账号与后台（对应 FR-01）
| ID | 用户故事 | 优先级 | 故事点 | 验收标准 | 认领人 |
|---|---|---|---|---|---|
| A-1 | 作为卖家，我希望用用户名和密码登录，以便进入后台管理商品 | P0 | 3 | 正确凭据可进入后台；错误密码被拒绝并提示；未登录访问后台被拦截 | 胡成溯 |
| A-2 | 作为卖家，我希望修改密码时需先验证原密码，以便保障账号安全 | P1 | 2 | 原密码错误时拒绝修改；新密码少于 8 位时拒绝并提示 | 胡成溯 |
说明：A-2 为 P1——不影响主流程演示，但属于基线明确要求，应完成。本版本不做退出登录。
EPIC-B 商品发布与浏览（对应 FR-02、FR-03）
| ID | 用户故事 | 优先级 | 故事点 | 验收标准 | 认领人 |
|---|---|---|---|---|---|
| B-1 | 作为卖家，我希望发布商品时填写名称、描述、图片、价格，以便把商品挂上货架 | P0 | 5 | 名称/价格必填校验生效；描述可空；价格 >0 且两位小数；发布后状态为「在售」 | 黄程宇 |
| B-2 | 作为卖家，我希望同一时间只能有一件在售商品，以便符合单商品售卖的规则 | P0 | 2 | 已有一件在售时发布新商品被拒绝并提示 | 黄程宇 |
| B-3 | 作为卖家，我希望上传图片时校验格式和大小，以便避免无效文件 | P1 | 2 | 非 JPG/PNG 或 >5MB 时拒绝并提示；未上传时使用占位图 | 黄程宇 |
| B-4 | 作为买家，我希望无需注册就能浏览在售商品，以便快速了解商品信息 | P0 | 2 | 未登录可访问商品页；商品字段完整展示 | 黄程宇 |
EPIC-C 购买意向提交（对应 FR-03）
| ID | 用户故事 | 优先级 | 故事点 | 验收标准 | 认领人 |
|---|---|---|---|---|---|
| C-1 | 作为买家，我希望填写姓名和电话提交购买意向，以便参与购买 | P0 | 3 | 两项均必填，缺一不可提交；电话不做格式校验 | 黄程宇 |
| C-2 | 作为买家，我希望提交后拿到一个口令码，以便后续撤销我的意向 | P0 | 3 | 提交成功即生成并当场显示口令码；口令码与该次意向唯一绑定 | 周到 |
| C-3 | 作为系统，我希望同一号码可重复提交且互不干扰，以便符合"不注册不建号"的规则 | P1 | 1 | 同号码多次提交生成多条独立意向，各有独立口令码，互不覆盖 | 黄程宇 |
EPIC-D 意向队列与排队规则（对应 FR-04）★ 核心难点
| ID | 用户故事 | 优先级 | 故事点 | 验收标准 | 认领人 |
|---|---|---|---|---|---|
| D-1 | 作为系统，我希望多个意向按提交时间正序排队，以便实现先到先得 | P0 | 5 | 3 人以上连续提交后，队列顺序与提交时间严格一致 | 周到 |
| D-2 | 作为卖家，我希望同一时间只有队首能进入交易，以便避免重复成交 | P0 | 2 | 非队首买家不可被选定进入交易 | 周到 |
| D-3 | 作为买家，我希望凭口令码撤销自己的意向，以便临时改变主意 | P0 | 3 | 正确口令码可撤销；错误口令码被拒绝；撤销后该意向从队列消失 | 周到 |
| D-4 | 作为系统，我希望撤销后队列自动顺位前移，以便后续买家不受影响 | P0 | 3 | 撤销第 2 位后，原第 3 位变为第 2 位，依次前移 | 周到 |
| D-5 | 作为系统，我希望队首交易失败后自动递补下一位，以便交易机会不中断 | P0 | 3 | 标记失败后，原第 2 位自动成为队首并可进入交易 | 周到 |
⚠️ 设计前置：D-2~D-5 依赖口令码机制与队列位次算法，须先出设计说明再编码。此项为本迭代技术风险最高的模块。
EPIC-E 卖家后台 · 意向购买人管理（对应 FR-05）
| ID | 用户故事 | 优先级 | 故事点 | 验收标准 | 认领人 |
|---|---|---|---|---|---|
| E-1 | 作为卖家，我希望查看意向购买人列表，以便选择交易对象 | P0 | 3 | 列表展示姓名、联系电话、意向提交时间；按提交顺序排列 | 胡成溯 |
| E-2 | 作为卖家，我希望从列表中选择一位买家进入交易，以便开始线下洽谈 | P0 | 2 | 选定后商品自动转为「已冻结」 | 胡成溯 |
EPIC-F 商品冻结与解冻（对应 FR-06）★ 状态机核心
| ID | 用户故事 | 优先级 | 故事点 | 验收标准 | 认领人 |
|---|---|---|---|---|---|
| F-1 | 作为系统，我希望商品进入交易时自动冻结，以便锁定当前交易 | P0 | 3 | 选定买家后状态自动由「在售」→「已冻结」 | 周到 |
| F-2 | 作为卖家，我希望能在后台手动冻结商品，以便暂停售卖 | P0 | 2 | 手动冻结后状态为「已冻结」，与自动冻结同一状态 | 周到 |
| F-3 | 作为买家，我希望冻结期间仍能看到商品但无法购买，以便了解商品动态 | P0 | 3 | 商品仍可见；显示「商品交易中」；点购买被拒绝 | 周到 |
| F-4 | 作为系统，我希望冻结期间不接收新意向，以便避免交易冲突 | P0 | 2 | 冻结期提交意向被拒绝并提示 | 周到 |
| F-5 | 作为卖家，我希望交易中也能手动解冻，以便应对谈崩等情况 | P1 | 2 | 后台有冻结/解冻开关；解冻后恢复「在售」并可收新意向 | 周到 |
EPIC-G 交易结果标记（对应 FR-07）
| ID | 用户故事 | 优先级 | 故事点 | 验收标准 | 认领人 |
|---|---|---|---|---|---|
| G-1 | 作为卖家，我希望标记交易成功，以便结束交易并撤下商品 | P0 | 2 | 标记成功后商品撤下，转入历史记录 | 胡成溯 |
| G-2 | 作为卖家，我希望标记交易失败，以便商品重新上线 | P0 | 3 | 标记失败后商品恢复「在售」；若队列有他人则自动递补 | 胡成溯 |
| G-3 | 作为系统，我希望只有卖家能标记结果、且无超时机制，以便符合线下交易的规则 | P0 | 1 | 买家侧无标记入口；系统不自动判定结果 | 胡成溯 |
EPIC-H 历史商品记录（对应 FR-08）
| ID | 用户故事 | 优先级 | 故事点 | 验收标准 | 认领人 |
|---|---|---|---|---|---|
| H-1 | 作为卖家，我希望查看历史商品列表，以便回顾已完成的交易 | P1 | 3 | 按时间倒序排列；支持翻页 | 胡成溯 |
| H-2 | 作为卖家，我希望历史商品保留完整信息，以便有据可查 | P1 | 3 | 保留名称、描述、图片、价格、发布时间、最终结果、交易时间 | 胡成溯 |
| H-3 | 作为卖家，我希望点进历史商品能看意向人列表，以便追溯交易对象 | P1 | 3 | 展示姓名、电话、提交时间、每人对应交易结果 | 胡成溯 |
三、汇总统计
3.1 按优先级
| 优先级 | 条目数 | 故事点小计 |
|---|---|---|
| P0 | 20 | 55 |
| P1 | 7 | 16 |
| 合计 | 27 | 71 |
3.2 按认领人
| 认领人 | 条目数 | 故事点 | 主要模块 |
|---|---|---|---|
| 胡成溯 | 10 | 25 | 账号、后台意向人、结果标记、历史记录 |
| 黄程宇 | 6 | 15 | 商品发布、浏览、意向提交 |
| 周到（PM） | 11 | 31 | 口令码、队列排队、撤销递补、冻结解冻 |
⚠️ PM 的故事点偏高（31/71 ≈ 44%）。原因：认领的队列与冻结是逻辑最复杂的两个模块，本身故事点虚高，且属首次实现。
建议：编码阶段若进度吃紧，优先保 D-1/D-3/D-4（队列基础能力），D-5（失败递补）可与 G-2 合并调试。
若仍需平衡，可将 B-3（图片校验）或 H-3（历史意向人）从黄程宇处划转给组长。
3.3 迭代容量判断
三人组、两周迭代（10/4 – 10/8 为首次交付窗口，之后每两周一次）。
本次交付窗口的冲刺订单（Sprint Backlog）应只圈 P0 条目：
| 范围 | 条目 | 说明 |
|---|---|---|
| 本次必交（P0） | 20 条 / 55 点 | 全部 P0，构成可运行 MVP |
| 本次应做（P1） | 7 条 / 16 点 | 时间允许则做，不做不阻塞演示 |
决策建议：以「主流程能完整演示一遍」为交付底线。即：卖家登录 → 发布商品 → 买家提交意向 → 查看意向人 → 进入交易冻结 → 标记成功/失败 → 历史记录。这条链路上的 P0 条目一条都不能缺。
四、本次迭代目标（对应报告 3.4 节）
迭代目标：交付在线购物系统 MVP 基线版本，实现「单商品售卖」的完整业务闭环。
具体到功能需求点，本次迭代需达成以下 8 项：
- 卖家可凭账号密码登录后台（FR-01）
- 卖家可发布商品，同一时间仅一件在售（FR-02）
- 买家无需注册即可浏览商品并提交意向，获得口令码（FR-03）
- 意向按提交时间先到先得排队，仅队首可进入交易（FR-04）
- 卖家可查看意向购买人列表并选定交易对象（FR-05）
- 商品进入交易自动冻结，冻结期不收新意向（FR-06）
- 卖家可标记交易成功/失败，失败后商品恢复并递补（FR-07）
- 历史商品记录完整保留并可翻页查询（FR-08）
可度量的验收依据：见《需求规格说明书-第5组》第 6 章「MVP 功能验收清单」14 条。
五、后续迭代待办池（Backlog Pool）
以下为基线之外、留待后续迭代排入的候选特性（本次不做）：
| 候选方向 | 示例特性 |
|---|---|
| 多商品 / 多卖家 | 商品列表、分类、搜索、多卖家入驻 |
| 用户体系 | 买家注册登录、个人中心、订单历史 |
| 在线支付 | 支付接口、订单状态机、退款 |
| 营销 | 优惠券、满减、限时折扣 |
| 评价 | 买家评价、卖家评分（澄清已明确本版本不做） |
| 库存 | 库存计数、自动补货 |
| 终端扩展 | Android / iOS / 微信小程序（澄清已明确本版本仅 Web） |
六、变更记录
| 版本 | 日期 | 变更内容 | 修订人 |
|---|---|---|---|
| v1.0 | 2026-10-04 | 首版创建，覆盖 MVP 全部 27 条特性 | 周到 |
| v1.1 | 2026-10-07 | 修正汇总统计：P0 20 条 55 点、P1 7 条 16 点、合计 27 条 71 点（原 48/19/67 与分 EPIC 明细不符）；按认领人统计同步更正 | 周到（AI 协助核算） |
本文件由产品负责人周到维护（Product Backlog、需求规格说明书、验收标准均由其负责）。每次迭代评审后，在此表追加新增特性并重新排序优先级，不删除历史条目。