Reading Guide
同一份计划，五个不同问题
五个按钮不是五套需求，而是对同一批项目资料的五种观察方式。数量不同，是因为每种视图统计的对象和筛选边界不同。
- 端到端 Journey
- 8
- User Story
- 76
- 已排期任务
- 57
- 全量任务
- 71
先建立统一心智模型
计划里同时存在“用户要完成什么”和“团队要交付什么”。这两类对象通过映射关系连接，但不是一一对应。
Journey
用户从触发到完成目标的一段完整经历，共8条。
Step / Story
Journey中的步骤、分支和可验收需求，共65步骤、76 Stories。
交付任务
UI、View、DTO/API、DM、算法、工程和测试工作，共71项。
验收证据
测试结果、截图、日志、数据库断言和双方验收记录。
8条 Journey → 65个用户步骤 → 76条 User Story
76条 Story ↔ 71个交付任务节点
71个任务 = 57个已排期 + 14个未排期
为什么不是一一对应？
一条 Journey 会拆成多个界面、接口、模型和测试任务；同一个登录、权限、审计或集成测试任务，也可能同时服务多条 Journey。
三个互相独立的维度
| 维度 | 回答的问题 | 示例 |
|---|---|---|
| 业务层级 | 这是什么对象？ | Journey、Story、实现任务、验收任务 |
| 范围分类 | 当前是否承诺交付？ | IN、PENDING、DELTA、3RD、OUT |
| 执行信息 | 何时做、做到哪一步？ | D3-D6、待澄清、开发中、已验收 |
因此，一个节点可以同时是“PENDING范围”“D3-D6已排期”“状态为待澄清”。这表示排期完成澄清，不等于已经承诺实现全部功能。
⌁
01 · Time Plan
时间计划
核心问题：45天内什么时候做、谁先谁后、什么会阻塞什么？
主要统计对象已排期交付任务，以及少量会阻塞已排期工作的未排期 PENDING 依赖。
主要布局横轴是D1-D45，纵轴是UI、View、Journey、Contract、Domain、Platform和Acceptance。
适合使用排期评审、并行工作判断、里程碑检查、阻塞依赖定位。
不能据此判断需求全集是否完整，或者某条 Journey 的用户步骤是否完整。
阅读顺序
- 先看里程碑和D1-D45时间位置。
- 再看同一业务颜色在不同泳道上的并行任务。
- 最后看前后依赖，确认前置产物是否能在后续任务开始前交付。
时间轴上的 PENDING 不等于承诺开发
它可能只是要求团队在指定日期前完成业务规则、第三方条件或责任边界的澄清。
⌘
02 · Requirement Trace
需求追踪
核心问题：一条业务切片是否从需求贯通到实现和测试？
主要统计对象无筛选时为57个已排期交付任务，不统计Journey卡片数量。
主要布局按在线订场、教练、会员、抽卡、线下履约等业务切片组织。
适合使用检查 Journey → View → DTO/API → DM/算法 → Test 是否断层。
不能据此判断完整需求全集和未排期候选项，因为本视图默认隐藏未排期任务。
它与时间计划的区别
| 视图 | 横向组织方式 | 主要关注点 |
|---|---|---|
| 时间计划 | D1-D45 | 什么时候完成、依赖是否来得及 |
| 需求追踪 | 业务切片 | 每个切片是否覆盖需求、数据、界面和测试 |
示例：Journey目录中的“在线订场”只有1张卡
用户路径
J-BOOK 在线订场Journey视图与界面
V-BOOK、V-ORDER、UI-BOOK契约与领域
API-BOOK、API-ORDER、DM-RES、ALG-AVAIL验收
T-BOOK-API、T-BOOK-E2E、T-M1◎
03 · Journey Catalog
Journey目录
核心问题：用户是谁、想完成什么、经历哪些步骤和异常分支？
主要统计对象固定8条端到端用户旅程，不是开发任务数量。
内容规模65个步骤、38个分支、76条 User Story。
适合使用产品对齐、场景评审、Story溯源、从实现任务反查用户价值。
不能据此判断某个开发任务是否已经排期、完成或具备正式验收证据。
当前8条 Journey
| 01 在线订场 | 02 预约教练 | 03 线下到店打球 | 04 会员充值与资产 |
| 05 营销抽卡 | 06 智能体内容服务 | 07 取消改期退款与异常 | 08 运营配置发布与回滚 |
Journey目录只展示8张“用户目标卡”。进入某张卡后，才展开步骤、Story、角色子轨和映射的实现任务。因此目录数量与需求追踪数量不应相等。
Journey是用户结果的容器
它说明为什么做、谁在使用、怎样才算完成。具体怎么实现，应继续追踪到View、DTO/API、DM/算法和测试节点。
✓
04 · Acceptance
验收模式
核心问题：用什么证据证明某项交付已经完成？
主要统计对象验收泳道中的任务，以及与这些验收任务直接连接的前置或后置节点。
主要布局仍使用任务和依赖图，但过滤掉与验收入口无直接关系的节点。
适合使用里程碑验收、UAT准备、证据缺口检查、阻断问题复核。
不能据此判断勾选复选框不等于自动执行测试，也不等于双方正式签收。
一项完整验收至少回答四个问题
- 验收对象对应哪个版本、Commit或构建产物？
- 通过条件来自哪条 Story、业务规则或接口契约？
- 证据是自动化报告、截图、日志、数据库断言还是人工记录？
- 失败后能否复现，并追踪到责任节点和修复结果？
计划页面保存的是验收状态，不是验收证据本身
页面中的勾选和进度保存在浏览器本地。正式验收仍应挂接测试报告、截图、日志、数据断言和双方确认记录。
◇
05 · Scope Ledger
范围差集
核心问题：所有已识别事项中，哪些承诺做、哪些待决定、哪些依赖外部、哪些不做？
建议把它理解为“全量范围边界”，而不是严格数学差集
当前视图会同时显示IN和非IN内容，用于对照当前承诺与边界项。真正相对IN的差集是PENDING、DELTA、3RD和OUT。
全量范围 = IN + PENDING + DELTA + 3RD + OUT
当前基线：71 = 50 + 12 + 5 + 2 + 2
排期关系：71 = 57个已排期 + 14个未排期
| 分类 | 数量 | 准确含义 | 当前动作 |
|---|---|---|---|
| IN | 50 | 已纳入当前基础交付范围 | 排期、实现并提供验收证据 |
| PENDING | 12 | 规则、责任或边界尚未决定 | 先澄清，随后转为IN、DELTA或OUT |
| DELTA | 5 | 相对基础范围识别出的新增候选 | 评估工期、成本和变更单 |
| 3RD | 2 | 结果依赖第三方设备、接口或供应商 | 确认责任、账号、环境和失败兜底 |
| OUT | 2 | 当前明确排除，不作为基础验收前提 | 留痕，防止被静默纳入交付 |
范围和排期是两条独立轴
| 范围 | 已排期 | 未排期 | 如何理解 |
|---|---|---|---|
| IN | 50 | 0 | 当前承诺范围已进入计划 |
| PENDING | 6 | 6 | 部分澄清工作已排期，部分仍在候选池 |
| DELTA | 0 | 5 | 新增候选，尚未进入45天计划 |
| 3RD | 1 | 1 | 部分第三方协调已排期，部分仍待条件 |
| OUT | 0 | 2 | 仅留痕，不排入基础计划 |
如何解读一个容易误判的节点：J-DRAW
业务对象
营销抽卡 Journey
范围
PENDING，概率、保底、库存、补偿及合规规则未冻结状态
待澄清时间
D3-D6安排规则澄清工作
正确结论
现在需要完成决策，不代表D3-D6必须完成抽卡功能开发
为什么顶部“当前节点”会不断变化
“当前节点”不是整个项目的固定总数，而是当前模式和筛选条件下正在显示的对象数量。相同标签在不同模式里承担了不同统计口径。
| 位置 | “当前节点”的口径 |
|---|---|
| 时间计划 | 当前筛选下的已排期任务，加关键未排期依赖 |
| 需求追踪 | 当前业务切片、范围、状态和搜索条件下的已排期任务 |
| Journey目录 | 固定8条 Journey |
| Journey详情 | 该 Journey 的步骤数 + Story数 + 映射实现任务数 |
| 验收模式 | 验收节点和与其直接连接的任务 |
| 范围差集 | 当前筛选下的全量任务，包括未排期任务 |
比较数量前先检查筛选器
业务切片、范围、状态和搜索词都会改变可见数量。Journey目录会禁用这些筛选器，因为它统计的是固定8条用户旅程。
建议的对齐与验收顺序
五种模式不是互相替代，而是一条从需求到交付证据的检查链。
Journey目录：先确认用户结果参与者、触发点、主流程、异常分支和Story是否完整。
范围差集：再确认承诺边界逐项决定IN、PENDING、DELTA、3RD或OUT，并明确责任人。
需求追踪：检查实现链是否断层每条关键Story是否有View、契约、DM/算法和测试映射。
时间计划：确认45天能否执行依赖、并行度、第三方条件和里程碑是否现实。
验收模式：冻结通过条件与证据把代码版本、自动化报告、截图、日志和签收记录关联起来。
常见问题
为什么Journey目录是8，需求追踪却是57？
Journey目录统计8个用户目标容器；需求追踪统计为了实现这些目标而拆出的57个已排期交付任务。两者是多对多映射。
PENDING出现在时间轴上，是不是代表已经承诺开发？
不是。它通常表示澄清、决策或外部条件确认工作已经排期，最终开发范围仍待结论。
DELTA和PENDING有什么区别？
PENDING尚未决定如何分类；DELTA已经识别为相对基础范围的新增候选，需要单独评估排期、成本和变更。
验收条件被勾选，是否等于正式验收通过？
不等于。勾选是本地进度记录，正式验收还需要可复核证据，并与明确版本绑定。
计划HTML是不是DM、DTO和接口契约的最终定义？
不是。计划用于范围、依赖和追踪；详细定义应以DataModel、契约代码、Schema、测试和对应版本化文档为准。