145 lines
4.9 KiB
Markdown
145 lines
4.9 KiB
Markdown
# L2 需求管理
|
||
|
||
## PM 目录
|
||
|
||
收到新的 L2 需求后创建：
|
||
|
||
```text
|
||
management/
|
||
└─ PM-<大需求编号>-<需求名称>/
|
||
├─ README.md
|
||
├─ STATUS.md
|
||
├─ 技术侧需求分析.md
|
||
├─ source/
|
||
│ ├─ README.md
|
||
│ ├─ v1/
|
||
│ └─ v2/
|
||
├─ code/
|
||
│ └─ MANIFEST.md
|
||
└─ tasks/
|
||
└─ ST-001-<业务模块>/
|
||
├─ 01.需求分析.md
|
||
├─ 02.技术实现方案.md
|
||
├─ 03.冒烟与逻辑验证.md
|
||
├─ 04.技术实现记录.md
|
||
├─ 05.代码Review报告.md
|
||
└─ 06.验收与交付报告.md
|
||
```
|
||
|
||
测试、上线和上线验证完成后，在大需求根目录新增一份 `归档记录.md`；不移动整个目录。
|
||
|
||
PM 编号由用户决定。尚未提供编号时，可以使用：
|
||
|
||
```text
|
||
PM-待确认-<需求名称>
|
||
```
|
||
|
||
作为需求分析期间的临时目录，并将 PM 编号列为 G1 需求评审的必确认项。用户确定编号后，在进入技术方案阶段前重命名为正式目录，并检查外部链接。Agent 不得自行生成永久 PM 编号。
|
||
|
||
大需求 `README.md` 负责总览和子任务索引。使用相对链接，并维护大需求与每个子任务之间的双向关联。
|
||
|
||
## 原始需求版本
|
||
|
||
将每次收到的需求保存为完整、不可变的版本快照：
|
||
|
||
```text
|
||
source/v1/
|
||
source/v2/
|
||
source/v3/
|
||
```
|
||
|
||
不得覆盖或修改原始文件。在 `source/README.md` 中记录版本、接收时间、来源、主要变化和当前/废止状态。对话中的临时补充在进入正式版本前，应作为补充需求单独记录。
|
||
|
||
收到新版本后：
|
||
|
||
1. 比较新旧版本；
|
||
2. 识别受影响的模块、需求、方案、用例和实现；
|
||
3. 重开失效阶段；
|
||
4. 更新状态历史；
|
||
5. 已通过门禁失效时重新确认。
|
||
|
||
除非变更说明明确，不得假设新版本自动解决了旧版本中的矛盾。
|
||
|
||
## 代码分析副本
|
||
|
||
用户在 `code/` 下维护分析用代码副本，默认基准分支为 `master`，项目另有配置时以项目为准。Agent 可以执行只读 Git 检查和安全的基准分支同步，但不得执行 `git add`、`git commit`、`git push`。
|
||
|
||
更新流程：
|
||
|
||
```text
|
||
检查仓库状态
|
||
→ 确认基准分支和本地无业务修改
|
||
→ 使用只允许安全快进的方式获取更新
|
||
→ 记录工程、分支、最新 Commit 和更新时间
|
||
→ 更新 MANIFEST
|
||
→ 重新判断既有分析是否过期
|
||
```
|
||
|
||
Agent 不得在副本中实现需求。允许使用 `git status`、`git diff`、`git log` 和安全同步命令调查；发现脏工作区、错误分支、历史分叉或无法安全快进时停止并报告，不得强制重置或擅自解决分叉。
|
||
|
||
维护 `code/MANIFEST.md`：
|
||
|
||
| 工程 | 本地目录 | 远端仓库 | 基准分支 | 当前 Commit | 更新时间 |
|
||
|---|---|---|---|---|---|
|
||
|
||
真正的需求开发在独立的项目开发工作区中完成。
|
||
|
||
## 需求矛盾与歧义
|
||
|
||
需求前后冲突、版本描述不一致、语义歧义或关键条件缺失时，禁止猜测。
|
||
|
||
在相关 `01.需求分析.md` 中记录：
|
||
|
||
| 编号 | 描述位置 A | 描述 A | 描述位置 B | 描述 B | 影响范围 | 状态 | 确认结论 |
|
||
|---|---|---|---|---|---|---|---|
|
||
|
||
使用 `RC-001` 等稳定编号。展示两处描述，说明受影响模块和功能，列出可能理解但不代替用户选择，并请求确认。
|
||
|
||
确认前：
|
||
|
||
- 标记为 `待确认`；
|
||
- 不设计或实现受影响的业务决策；
|
||
- 安全时可以继续不受影响的工作；
|
||
- 无法继续时将子任务标记为待确认或阻塞。
|
||
|
||
确认后记录结论、确认人、时间、来源和受影响文档，并同步更新。
|
||
|
||
## 状态历史
|
||
|
||
以 `STATUS.md` 作为当前状态和历史记录的唯一事实来源。阶段和状态分开维护。
|
||
|
||
阶段：
|
||
|
||
```text
|
||
需求接入 → 需求分析 → 技术方案设计 → 冒烟用例设计
|
||
→ 技术实现 → Code Review → 逻辑验证 → 测试 → 发布 → 归档
|
||
```
|
||
|
||
状态：
|
||
|
||
```text
|
||
未开始 / 进行中 / 待确认 / 已阻塞 / 待评审 / 已完成 / 已跳过 / 已取消
|
||
```
|
||
|
||
记录：
|
||
|
||
- 大需求状态摘要；
|
||
- 每个子任务的当前阶段和状态；
|
||
- G1/G2/G3 状态；
|
||
- 阻塞事项；
|
||
- 只追加的变更历史，包括时间、对象、原/新状态、原因、操作者和证据链接。
|
||
|
||
不得删除或改写历史来掩盖返工。旧记录有误时追加更正。验证或测试失败时，重新打开实现阶段并记录回退。
|
||
|
||
门禁记录必须包含确认的原始需求版本、文档及文档版本、用户提供的代码版本标识、确认时间、来源和范围。文档中的“当前状态”字段只作为展示，发生冲突时以 `STATUS.md` 为准。
|
||
|
||
当前状态表：
|
||
|
||
| 子任务 | 业务模块 | 当前阶段 | 当前状态 | 阻塞项 | 最后更新 |
|
||
|---|---|---|---|---|---|
|
||
|
||
历史表：
|
||
|
||
| 时间 | 对象 | 原阶段/状态 | 新阶段/状态 | 原因 | 操作者 | 证据 |
|
||
|---|---|---|---|---|---|---|
|