研发工作流模型¶

结论：研发工作流的价值不在步骤数量。它让每类工作进入合适的对象，并用完成条件推动状态变化。

读者： 需要设计或改进研发协作流程的人。
用途： 用统一模型判断工作应放在哪里、何时可以推进、怎样才算完成。
边界： 本文讨论通用研发协作，不讨论人员绩效和具体行业规范。

1. 研究问题与方法¶

原始流程包含七个步骤。七个步骤连接想法、调研、决策、交付和项目跟踪。

本文不重复操作清单。本文回答一个更基础的问题：

研发流程怎样把不同类型的不确定性，转成可以协作、可以验收的工作对象？

本文采用四步整理：

1. 提取原流程中的对象类型和完成条件。
2. 把连续步骤归纳为状态层。
3. 把规则归纳为推进门禁。
4. 用反模式、度量和边界条件检验模型。

本文是概念研究。本文基于单个仓库流程整理。本文没有开展对照实验。

2. 核心结论¶

研发工作流可以写成一条最小模型：

研发工作流 = 对象分层 + 状态转换 + 完成证据 + 周期反馈

四个条件分别回答四个问题：

关键判断有两点：

1. 流程不是一条固定直线。对象可以跳过不需要的步骤。
2. 跳过步骤不等于跳过判断。省略对象必须由更低的成本或风险支持。

3. 对象模型¶

研发工作流先区分对象，再规定动作。一个对象只解决一类问题。

对象模型使用下图表示。图中的箭头表达状态变化，不要求所有工作经过全部节点。

flowchart LR
    A["问题或想法"] --> B{"未知项是否明确？"}
    B -- "否" --> C["Discussion"]
    C --> D["Research issue"]
    B -- "是" --> D
    D --> E{"需要长期决策？"}
    E -- "是" --> F["ADR"]
    E -- "否" --> G["Feature 或 Task"]
    F --> G
    G --> H["sub-issue / 分支 / PR"]
    H --> I["验收与完成"]

对象分层的核心有两点：

1. 未知项留在研究层，不把猜测写成交付。
2. 长期决策进入决策层，不在多个 issue 中重复解释。

4. 状态转换¶

状态转换由完成条件和证据触发。角色不能只凭主观感觉推进状态。

4.1 理解门禁¶

Discussion 只负责发现问题。达到回复阈值或收到调研请求后，工作转入 Research issue。

Discussion 没有进入 Project 的价值。它不能承担排期和交付跟踪。

4.2 决策门禁¶

Research issue 必须只回答一个问题。研究结论必须写回正文，不能只留在评论里。

Research issue 有两个出口：

• 能直接执行，进入 Feature 或 Task。
• 需要长期保存，进入 ADR。

4.3 交付门禁¶

Feature 只承接足够大的工作。较小工作使用 Task。

Feature 的每个 sub-issue 都必须有验收标准。一个 sub-issue 对应一条分支、一个 PR 和一个可检查的交付结果。

4.4 完成门禁¶

PR 是代码证据，不是完成公告。

PR 至少满足以下条件：

1. 测试通过。
2. 必要评审通过。
3. UI 变更提供真机证据。
4. 没有未关闭的风险。
5. 对应 issue 可以关闭。

Project 只记录状态，不复制完整正文。日期和进度字段只保留一处权威值。

5. 运行循环¶

工作流不是一个一次性项目，而是一个持续运行的控制循环。

flowchart TD
    A["捕获问题"] --> B["限定未知项"]
    B --> C["形成决策"]
    C --> D["拆分交付"]
    D --> E["验证证据"]
    E --> F["更新状态"]
    F --> G["周期检查"]
    G --> A

每一轮循环执行六类动作：

1. 捕获问题、影响和场景。
2. 用时间盒限制研究范围。
3. 把长期决策写入 ADR。
4. 把可交付范围拆成小单元。
5. 用测试、评审和真机证据关闭单元。
6. 用周期检查发现积压、漂移和失效规则。

5.1 研究时间盒¶

Research issue 的默认时间盒是 2 个工作日。

允许延长一次。延长时间不超过原时间盒。

到期评审只决定两件事：结题或结束研究。评审不能让研究无限延长。

5.2 决策回填¶

未确定的决策引用必须在 5 个工作日内回填。

长期决策采用 ADR。旧 ADR 不删除，由新 ADR 标记为 superseded。

5.3 周期检查¶

维护人每周检查以下信号：

• 超过期限的 decision pending。
• 超过时间盒的 Research issue。
• 已合并但仍为 proposed 的 ADR。
• 阻塞关系是否准确。
• Feature 的 sub-issue 进度。
• 等待 UI 评审的时间。
• Project 自动加入是否失效。
• 过期或不真实的 Target date。

6. 流程原则¶

6.1 一个对象只承担一个目的¶

Discussion、Research、ADR、Feature、Task 和 PR 不能互相替代。

一个对象承担多种目的时，状态和完成标准会冲突。

6.2 先降低不确定性¶

未知项进入研究，不进入交付。

研究用于回答问题。研究代码不得直接合并到 main。

6.3 用证据结束阶段¶

每个阶段都写完成证据。动作、工时和会议本身不是完成证据。

6.4 保持短反馈环¶

sub-issue 的工期控制在 1 到 3 天。

时间盒和周期检查限制工作停留在未知状态的时间。

6.5 只维护一处权威信息¶

正文写目标、结论和引用。Project 写状态、日期和进度。

同一信息不复制到多个对象。复制会产生冲突。

6.6 把流程变更当代码管理¶

流程文档通过 PR 修改。PR 需要非作者批准，并记录版本变化。

单人仓库可以自查。自查结论仍要写回 PR。

7. 度量建议¶

度量只用于发现流程问题。度量不能直接评价个人绩效。

指标应结合案例解释。单独看一个数字不能证明流程有效。

8. 失败模式¶

9. 适用边界¶

本模型适合以下场景：

• 团队规模为 2 到 15 人。
• 使用 GitHub issue、PR 和 Project。
• 团队需要保留决策记录和交付证据。
• 团队可以执行每周检查。

本模型不覆盖以下场景：

• 需要 ISO 27001、SOC 2 等外部合规取证的组织。
• 不依赖 issue 和 PR 的工作流。
• 人员绩效评价。
• 超出单一研发团队的组织治理。

10. 与任务收敛模型的关系¶

研发工作流模型管理对象流。任务收敛模型管理单个任务能否执行。

两个模型可以同时使用。工作流模型决定工作放在哪里。任务收敛模型决定当前对象是否已经可以执行。

11. 来源¶

原始材料¶

• 研发工作流源文档
• 质量保证 SOP

关联研究¶

• 任务收敛模型

方法参照¶

• GitHub Docs：About Projects
• GitHub Docs：About issues
• GitHub Docs：About pull requests

12. 局限与未验证项¶

1. 模型来自单个仓库的流程总结。本文没有验证其他团队。
2. 模型依赖 GitHub 的能力和配置。
3. 团队规模 2 到 15 人是经验边界。本文没有确定精确适用范围。
4. 本文没有量化流程对交付速度的影响。
5. 指标用于诊断流程，不用于评价个人。

13. 版本记录¶