319 lines
10 KiB
Markdown
319 lines
10 KiB
Markdown
# 全流程分步说明：产品 → 开发 → 测试 → 发版
|
||
|
||
> 把整条链路拆成**按顺序执行的步骤**，每步说清：谁做、做什么、云效上变成什么、下一步谁接。
|
||
> 读完应能照着口令/动作走完一轮（标准路径）。
|
||
> 日期：2026-07-24
|
||
|
||
---
|
||
|
||
## 先记住三件事
|
||
|
||
1. **需求状态 = 阶段真相**
|
||
看需求状态就知道现在卡在哪一段（分析中 / 待开发 / 开发中 / 待测试…）。
|
||
2. **每条需求只有 1 个【交付】容器**
|
||
分析、设计、开发、测试都挂在这个交付下面（子项），不要再建第二个【交付】。
|
||
3. **编号说话，不靠标题查**
|
||
口令尽量带 `ONEOS-xx`；改标题不影响关联。
|
||
|
||
```text
|
||
需求（状态主轴）
|
||
└─【交付】（容器，关联到需求）
|
||
├─【分析】【设计】 ← 产品建
|
||
├─【开发】… ← 开发建
|
||
└─【测试】 ← 开发提测时建
|
||
【发版】另建，挂迭代 + 范围内需求
|
||
```
|
||
|
||
---
|
||
|
||
## 总步骤一览（共 18 步）
|
||
|
||
| 阶段 | 步骤 | 一句话 |
|
||
|---|---|---|
|
||
| **产品** | 1～6 | 从记诉求到交棒给何斐 |
|
||
| **开发** | 7～12 | 从拆任务到提测 |
|
||
| **测试** | 13～15 | 从接测到测试完成 |
|
||
| **发版** | 16～17 | 从建发版到发布结果 |
|
||
| **收口** | 18 | 产品验收关闭 |
|
||
|
||
---
|
||
|
||
## 阶段 A｜产品（步骤 1～6）
|
||
|
||
### 步骤 1｜记录需求
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 产品 / AI（YunxiaoPMapp） |
|
||
| **做什么** | 把聊天、录音、口述先洗成 AutoRDO，再建一条**产品类需求** |
|
||
| **需求状态** | **待处理** |
|
||
| **云效任务** | 不建任何任务 |
|
||
| **描述里写** | `## 原始诉求（AutoRDO）`；编号区先空着 |
|
||
| **口令例** | `记录需求：…；推进至=暂不推进` |
|
||
| **为什么** | 先落盘，避免口头需求丢；还没确认值不值得做 |
|
||
|
||
---
|
||
|
||
### 步骤 2｜受理确认
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 产品 |
|
||
| **做什么** | 确认要做：定优先级、打标签（从云效标签里点选） |
|
||
| **需求状态** | **已确认** |
|
||
| **云效任务** | 仍不建任务 |
|
||
| **口令例** | `受理确认：ONEOS-xx` |
|
||
| **为什么** | 和「还没想清楚」的待处理分开；确认后才进分析/设计 |
|
||
|
||
---
|
||
|
||
### 步骤 3｜开始分析
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 产品 / AI |
|
||
| **做什么** | ① 建 **【交付】**（整条需求的唯一容器，关联到需求）② 建 **【分析】**（挂在交付**子项**下） |
|
||
| **需求状态** | **分析中** |
|
||
| **云效任务** | 【交付】+【分析】 |
|
||
| **口令例** | `开始分析：ONEOS-xx` |
|
||
| **验收** | 打开【交付】→「关联项」有需求；「子项」有【分析】 |
|
||
| **为什么** | 分析要有落点；后续设计/开发/测试都挂同一棵树 |
|
||
|
||
---
|
||
|
||
### 步骤 4｜开始设计
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 产品 / AI |
|
||
| **做什么** | 建 **【设计】**（子项挂交付）；收口【分析】计划时间 |
|
||
| **需求状态** | **设计中** |
|
||
| **云效任务** | 新增【设计】 |
|
||
| **口令例** | `开始设计：ONEOS-xx；交付=…；分析=…` |
|
||
| **为什么** | 进入原型/方案设计；分析阶段收口 |
|
||
|
||
---
|
||
|
||
### 步骤 5｜设计完成
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 产品 / AI |
|
||
| **做什么** | 收口【设计】；跑 AutoPRD，把**产品说明**灌进【交付】描述；挂原型 ZIP/截图等附件 |
|
||
| **需求状态** | **设计完成** |
|
||
| **口令例** | `设计完成：ONEOS-xx；设计=…；原型=…` |
|
||
| **为什么** | 开发接手时看的是【交付】里的产品说明，不是聊天记录 |
|
||
|
||
---
|
||
|
||
### 步骤 6｜交棒开发（产品终点）
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 产品 / AI |
|
||
| **做什么** | 需求改为待开发；**【交付】负责人改为何斐**（不新建开发/测试任务） |
|
||
| **需求状态** | **待开发** ★ |
|
||
| **交出什么** | 需求编号 +【交付】编号 |
|
||
| **口令例** | `交棒开发：ONEOS-xx；交付=…` |
|
||
| **为什么** | 产品部到此结束；技术经理从这里拆开发 |
|
||
|
||
> 旁路：急单可用**快轨**（跳过分析、直接待开发），仍交到同一终点「待开发 + 交付→何斐」。
|
||
|
||
---
|
||
|
||
## 阶段 B｜开发（步骤 7～12）
|
||
|
||
### 步骤 7｜分配开发任务
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 开发主管何斐 / 开发 Skill |
|
||
| **做什么** | 输入**交付任务编号** → 自动建 **【开发】**；标题=`【开发】`+需求标题；**描述人工补**；指定开发人；自动写计划时间 |
|
||
| **关联** | 子项挂【交付】；关联项挂需求 |
|
||
| **需求状态** | 仍为 **待开发**（确认即可，一般不用再改） |
|
||
| **口令例** | `分配任务：交付=ONEOS-a；开发人=张三` |
|
||
| **为什么** | 一条需求可拆多个开发任务；都挂在同一交付下 |
|
||
|
||
---
|
||
|
||
### 步骤 8｜开始开发
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 开发人员 |
|
||
| **做什么** | 口令带上**开发任务编号** |
|
||
| **开发任务** | → **处理中** |
|
||
| **需求状态** | → **开发中** |
|
||
| **口令例** | `开始开发：ONEOS-d` |
|
||
| **为什么** | 看板一眼能看出「正在写代码」 |
|
||
|
||
---
|
||
|
||
### 步骤 9｜写代码 / 提 MR
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 开发人员 |
|
||
| **做什么** | 按【交付】里的产品说明实现；分支/MR 建议挂上开发任务编号与需求编号 |
|
||
| **需求状态** | 仍为 **开发中** |
|
||
| **为什么** | 代码可追溯到哪条开发任务、哪条需求 |
|
||
|
||
---
|
||
|
||
### 步骤 10｜AI 自测门禁（开发侧草案）
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | AI（开发完成后触发） |
|
||
| **做什么** | 找与**需求同标题**的测试计划 → 按用例自测 → 不过则自动提缺陷（标题含开发任务编号）并尝试修复，直到本计划用例全过 |
|
||
| **需求状态** | 仍为 **开发中**（未全过前） |
|
||
| **为什么** | 在正式提测前先挡住明显问题（属草案，规则可再收紧） |
|
||
|
||
---
|
||
|
||
### 步骤 11｜开发任务完成
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 系统 / AI（用例全过之后） |
|
||
| **做什么** | 该条【开发】标为**已完成** |
|
||
| **需求状态** | → **开发完成**（若有多条开发，建议等**全部**完成再改，避免过早） |
|
||
| **为什么** | 标记「代码+门禁」这一段结束 |
|
||
|
||
---
|
||
|
||
### 步骤 12｜完成开发 · 正式提测
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 开发人员（自测也完成） |
|
||
| **做什么** | 口令「完成开发」→ 自动建 **【测试】**（标题=`【测试】`+任务名）；子项挂【交付】；建议再关联需求；指派测试（如谢佳伟） |
|
||
| **需求状态** | → **待测试** ★ |
|
||
| **口令例** | `完成开发：ONEOS-d` |
|
||
| **为什么** | 开发交棒给测试；测试侧开始接单 |
|
||
|
||
---
|
||
|
||
## 阶段 C｜测试（步骤 13～15）
|
||
|
||
### 步骤 13｜接测试任务
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 测试（谢佳伟等） |
|
||
| **做什么** | 打开【测试】任务；确认关联的需求与交付；准备/核对测试计划与用例包（建议按**需求编号**分包，比「同标题」更稳） |
|
||
| **需求状态** | **待测试** → 开始执行后改为 **测试中** |
|
||
| **为什么** | 正式测试以计划用例为准，不靠口头「测过了」 |
|
||
|
||
---
|
||
|
||
### 步骤 14｜执行用例 · 缺陷回流
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 测试执行；失败时回流开发修 |
|
||
| **做什么** | 按用例执行；失败建缺陷 → 开发修复 → 再测 |
|
||
| **需求状态** | **测试中** |
|
||
| **为什么** | 质量关口；未绿不能进发版 |
|
||
|
||
---
|
||
|
||
### 步骤 15｜测试完成
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 测试 / AI 辅助判定 |
|
||
| **做什么** | **本需求**相关用例全绿 →【测试】收口；通知发版对接人 |
|
||
| **需求状态** | → **测试完成** ★ |
|
||
| **注意** | 只卡本需求，不卡同迭代里别的需求 |
|
||
| **为什么** | 发版范围以「测试完成」的需求为准 |
|
||
|
||
---
|
||
|
||
## 阶段 D｜发版（步骤 16～17）
|
||
|
||
### 步骤 16｜建发版任务
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 发版对接人（时生亮）· 手工或 AI |
|
||
| **做什么** | 建 **【发版】**；关联**迭代** + 本期内要上的需求（建议再挂交付/测试）；汇总更新说明 |
|
||
| **需求状态** | 进入发布流程时 → **发布中** |
|
||
| **为什么** | 一次发版可能含多条需求；要有明确范围清单 |
|
||
|
||
---
|
||
|
||
### 步骤 17｜发布结果回写
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 发版对接人 / 流水线 |
|
||
| **做什么** | 执行发布 |
|
||
| **结果** | 成功 → **发布完成**；失败 → **发布失败**（可重试再进发布中） |
|
||
| **为什么** | 成败要回写云效，避免「以为发了其实没发」 |
|
||
|
||
---
|
||
|
||
## 阶段 E｜收口（步骤 18）
|
||
|
||
### 步骤 18｜业务验收 · 关闭
|
||
|
||
| | |
|
||
|---|---|
|
||
| **谁** | 产品 |
|
||
| **做什么** | 业务验收通过后，关闭需求，并收口【交付】 |
|
||
| **需求状态** | → **已关闭** |
|
||
| **为什么** | 全链路结束；树上任务与需求一致收口 |
|
||
|
||
---
|
||
|
||
## 状态主链（串起来看）
|
||
|
||
```text
|
||
待处理 → 已确认 → 分析中 → 设计中 → 设计完成
|
||
→ 待开发 ← 产品交棒给何斐
|
||
→ 开发中 → 开发完成
|
||
→ 待测试 → 测试中 → 测试完成
|
||
→ 发布中 → 发布完成（或发布失败可重试）
|
||
→ 已关闭 ← 产品验收关单
|
||
```
|
||
|
||
---
|
||
|
||
## 四个交棒口（最重要）
|
||
|
||
| 交棒 | 交出人 | 接棒人 | 交出物 | 状态落点 |
|
||
|---|---|---|---|---|
|
||
| ① 产品→开发 | 产品 | 何斐 | 需求号 + 交付号 | 待开发 |
|
||
| ② 开发→测试 | 开发人 | 测试 | 【测试】任务已建好 | 待测试 |
|
||
| ③ 测试→发版 | 测试 | 发版 | 本需求用例全绿 | 测试完成 |
|
||
| ④ 发版→产品 | 发版 | 产品 | 发布完成 / 更新说明 | 发布完成 → 已关闭 |
|
||
|
||
---
|
||
|
||
## 谁在什么时候动（对照表）
|
||
|
||
| 步骤 | 产品 | 开发主管 | 开发人 | 测试 | 发版 |
|
||
|---|---|---|---|---|---|
|
||
| 1～2 记需求/确认 | ● | | | | |
|
||
| 3～5 分析设计 | ● | | | | |
|
||
| 6 交棒 | ● | 接 | | | |
|
||
| 7 分配任务 | | ● | | | |
|
||
| 8～9 开始写码 | | | ● | | |
|
||
| 10～11 AI门禁/完成任务 | | | ●/AI | | |
|
||
| 12 提测 | | | ● | 接 | |
|
||
| 13～15 测试 | | | 修缺陷 | ● | |
|
||
| 16～17 发版 | | | | | ● |
|
||
| 18 关闭 | ● | | | | |
|
||
|
||
---
|
||
|
||
## 相关文档
|
||
|
||
| 文档 | 用途 |
|
||
|---|---|
|
||
| `docs-四角色泳道流程图.md` | 泳道图总览 |
|
||
| `docs-产品部流转流程图.md` | 产品 1～6 细规 |
|
||
| `docs-开发侧流转草案.md` | 开发 7～12 细规与待拍板 |
|
||
| `yunxiao-pipeline-handbook` | 云效规则与配置 |
|