研发管理流程汇总

文档说明

本文档是研发管理流程的落地白皮书，整合了从需求到发布上线的全流程标准化管理规范。基于“标准化、规范化、工具化、智能化”的四化建设理念，旨在构建高效、透明、高质量的研发体系。

核心目标：

• • 透明化 (Transparency)：通过 Jira 看板与效能仪表盘，实现全流程可视，消除管理黑盒。
• • 标准化 (Standardization)：在产品、设计、开发、测试、发布各环节建立严苛的准入准出标准。
• • 工具化 (Tooling)：拒绝“口口相传”，将管理意志固化在 Jira、GitLab、Jenkins 等工具链中，流程即工具。
• • 智能化 (Intelligence)：全面拥抱 AI，利用 Cursor/Copilot、AI 代码评审等技术，实现人机协同的研发新模式。

研发管理全流程图谱

1. 研发活动与角色矩阵

角色与职责

研发关键活动

以下是优化后的内容，旨在使目的更明确、表述更专业，同时保持了原有格式：

RAT（需求评审会）【建议】

• • 目的：评估需求价值与技术可行性，确定需求优先级，决策是否准入迭代，并给出粗略排期。
• • 参与人员：研发 PM、产品经理、项目经理、架构师
• • 输出：已确定的需求优先级列表、迭代初步排期计划

需求交底 【强制】

• • 目的：由产品经理详细阐述需求背景、业务目标及功能细节，拉齐产研团队对需求的认知。
• • 参与人员：产品经理、研发全员（开发、测试）
• • 输出：需求交底纪要、需求确认记录（或待确认问题清单）

需求/设计串讲评审 【强制】

• • 目的：由开发人员阐述系统设计方案与技术实现路径，团队共同评审架构合理性、可行性及潜在技术风险。
• • 参与人员：开发、架构师、测试（核心测试人员建议参加）
• • 输出：经评审的设计文档/技术方案、评审决议记录

需求反串讲 【建议】

• • 目的：由测试人员阐述对需求的理解及测试策略/场景，开发人员评估测试点的覆盖度与准确性，协助查漏补缺。
• • 参与人员：测试、开发、产品经理（建议参加以确保业务场景对齐）
• • 输出：测试分析/设计文档、初步测试用例框架

ShowCase 【强制】

• • 目的：开发人员演示已完成的功能实物，直观呈现研发成果，确保交付物符合产品经理的预期与验收标准。
• • 参与人员：开发、测试、产品经理
• • 输出：ShowCase 演示记录、功能预验收确认单或反馈清单

迭代回顾 【建议】

• • 目的：迭代结束后团队共同复盘，基于质量与过程数据分析得失，总结经验教训，制定后续改进措施。
• • 参与人员：项目/研发全员
• • 输出：迭代回顾报告、明确的改进计划（Action Items）

  

2. 各环节标准化流程详述

2.1 产品环节：需求治理与规划

核心理念：Do the Right Thing (做正确的事)。从源头拒绝“一句话需求”和“低价值需求”。

关键活动：

1. 1. RAT（需求评审会）【风控核心】
• • 准入条件：需求文档齐全（含背景、目标、逻辑描述），原型图已完成。
• • 评审维度：
• • 价值分 (Value)：对 KPI/OKR 的贡献度（高/中/低）。
• • 成本分 (Cost)：预计开发人天（高/中/低）。
• • 决策输出：
• • ✅ Go (纳入迭代)：高价值+成本可控。
• • ⏸ Hold (放入池子)：价值一般，待资源空闲。
• • ❌ No-Go (拒绝)：低价值或逻辑不通。
• • 落地动作：在 Jira 中维护 Product Backlog，通过 Rank 字段进行可视化排序。
2. 2. 需求交底 (Handover)【强制】
• • 动作：产品经理进行串讲，确保研发团队理解一致。
• • 产出：需求交底纪要。
3. 3. 需求实例化 (Specification by Example)【防跑偏】
• • 动作：产品经理进行串讲，研发反向复述。
• • 标准：必须定义清晰的 验收标准 (Acceptance Criteria, AC)。
• • AI 玩法：“请将需求描述转换为 Gherkin 格式 (Given-When-Then) 的验收用例。”

2.2 设计环节：标准化与实例化

核心理念：Think before Code (谋定而后动)。用设计文档消除实现的随意性。

关键活动：

1. 1. 需求/设计串讲 (Design Walkthrough)【建议】
• • 目的：开发讲解技术方案，架构师与测试评审。
• • 关注点：数据库设计合理性、接口定义完整性。
2. 2. SDD (Spec Driven Development) 规约驱动【强制】
• • 定义：使用标准化规约（Spec）来描述软件行为，而非单纯的文档（Software Design Document）。这是实践 AI 设计确定性 的核心做法。
• • 核心工具：OpenSpec。
• • 落地价值：
• • 消除歧义：Spec 是机器可读（Machine-Readable）且强类型的，避免了自然语言文档的模糊性。
• • AI 完美的输入：Spec 是最高质量的 Context。AI 基于 OpenSpec 定义，能精准生成 100% 可用的代码骨架、Mock 数据和测试用例。
• • 内容规范：
• • API Spec：使用 OpenSpec/Swagger 定义接口契约。
• • Domain Spec：定义实体关系（ER）。
• • Flow Spec：使用 Mermaid/DSL 描述状态流转。
3. 3. 接口先行 (Contract First)
• • 动作：编码前优先定义 Swagger/OpenAPI 契约。
• • 工具：OpenSpec / Swagger。

2.3 开发环节：工业化生产

核心理念：Quality Built In (质量内建)。即使是新手，在规范和工具约束下也能写出合格代码。

关键活动：

1. 1. 代码规范化 (Linting)
• • 配置：项目根目录强制检查 .editorconfig, .stylelintrc, .eslintrc。
2. 2. AI 代码评审 (Aireview)【第一道防线】
• • 机制：GitLab Webhook 触发 AI Bot。
• • 落地：ai-codereview-gitlab 自动在 MR 中发表评论。
3. 3. 单元测试 (Unit Test)
• • 红线：核心业务层 (Service/Domain) 行覆盖率 > 50%。
4. 4. ShowCase (功能演示)【强制】
• • 目的：开发完成功能后，现场向产品经理和测试演示。
• • 标准：演示流程必须打通，UI 还原度符合要求。
• • 结果：产品验收通过后，方可转测试。

2.4 测试环节：智能防控体系

核心理念：Automate Everything (自动化一切)。让人回归到探索性测试和复杂场景设计。

关键活动：

1. 1. 需求反串讲 (Reverse Presentation)【建议】
• • 目的：测试人员复述需求逻辑，开发和产品确认，消除理解偏差。
• • 产出：测试点确认。
2. 2. 冒烟测试 (Smoke Test)【准入红线】
• • 要求：提测时，开发必须演示主流程跑通，或提交自动化冒烟通过报告。
• • 后果：冒烟失败 = 提测打回 + 通报批评。
3. 3. 用例标准化
• • 管理：使用 MeterSphere 或 Jira Xray。
• • AI 生成：基于 Markdown 需求文档，让 AI 生成思维导图格式的测试点。
4. 4. 缺陷管理闭环
• • SLA：P0 (24h修复), P1 (迭代内修复)。

2.5 发布环节与反馈

核心理念：Release is Boring (发布是无聊的)。如果发布让你心跳加速，说明流程有问题。

关键活动：

1. 1. 发布流水线 (Pipeline as Code)
• • 工具：Jenkins + Jenkinsfile。
• • 卡点：Sonar 质量门禁失败 -> 自动停止发布。
2. 2. 发布评审 CheckList
• • DB 变更、配置灰度、一键回滚检查。
3. 3. 迭代回顾 (Retrospective)【建议】
• • 时间：迭代结束后。
• • 内容：回顾做得好的（Keep）、需要改进的（Improve）、具体的 Action Item。
• • 输出：改进计划。
4. 4. 金丝雀发布 (Canary Release)
• • 策略：通过 K8s Ingress 或 Service Mesh 控制流量。
• • 过程：切 5% 流量 -> 观察 10 分钟（无报错）-> 切 50% -> 观察 -> 全量。

3. 工具落地体系矩阵

4. 研发效能看板 (DORA 指标)

管理层通过以下指标驱动改进：

1. 1. 交付效率：
• • 需求交付周期 (Lead Time)：需求提出 -> 上线。 目标：< 2周
• • 部署频率 (Deployment Frequency)：每天/每周发布次数。 目标：按需发布
2. 2. 交付质量

•   • 缺陷DI、遗留DI：迭代版本的缺陷数、版本发布遗留的缺陷数。按等级计算
•   • 变更失败率 (Change Failure Rate)：发布导致回滚或热修复的比例。 目标：< 5%
•   • 平均恢复时间 (MTTR)：故障发生 -> 恢复服务的时间。 目标：< 1小时

1. 4. 代码质量：
• • 千行代码缺陷率：Bug 数 / KLOC。
• • 代码重复率：Sonar 扫描结果。 目标：< 3%