引言：
华为的研发体系-----大研发操作系统
- 以客户需求为导向
- 以 IPD 为主线
- 以敏捷/精益为适配
- 以 DevOps 工具链为支撑
一、总览：一张"华为研发高铁图"
需求→CDCP→PDCP→开发→TR4→TR5→TR6→GA
（客户声音） （立项） （敏捷迭代） （批量测试） （上市）
整条高铁叫 IPD（Integrated Product Development），但车厢里装的是 敏捷 Sprint、DevOps 流水线、精益看板，根据产品类型随时"换车厢"。
二、三张表：不同颗粒度看清"到底怎么干"
表1 生命周期阶段（IPD 主航道，任何产品必须遵守）
|------------|------------|------------|---------------------|
| 阶段 | 中文 | 目标 | 出口准则（关键里程碑） |
| Concept | 概念 | 需求对齐、机会验证 | CDCP（Concept DCP） |
| Plan | 计划 | 商业计划书、资源承诺 | PDCP（Plan DCP） |
| Develop | 开发 | 构建可交付的增量 | TR4（功能完成） |
| Qualify | 验证 | 质量达标、批量可复制 | TR5（性能/可靠性基线） |
| Launch | 发布 | 市场成功、收入兑现 | TR6（量产/发布评审） |
| Life-cycle | 维护 | 持续盈利、版本迭代 | EOL（退市评审） |
表2 开发落地模型（按"产品族"选用不同车厢）
|--------------|-----------------|---------------|--------------------------|----------------------|
| 产品形态 | 首选模型 | 迭代周期 | 关键做法 | 例子 |
| 运营商基站/交换机 | IPD + 大瀑布 | 3--6 个月 | 需求冻结、严格 TR 评审 | 5G RAN 版本 |
| 企业网/云产品 | IPD + 敏捷（Scrum） | 2--4 周 Sprint | Story 优先级动态调整 | FusionSphere、GaussDB |
| 终端 App/云服务 | IPD + DevOps | 1 周以下 | 主干开发、灰度发布、Feature Toggle | HMS Core、华为云 API |
表3 角色与评审机制（RACI 版）
|--------------|------------|--------------|------------------------|
| 角色缩写 | 全称 | 职责 | 关键输出 |
| LPDT | 产品开发团队经理 | 项目 CEO | Charter、PDCP 材料 |
| SE | 系统工程师 | 需求分解、架构 | SRS、接口文档 |
| PQA | 产品质量保证 | 过程审计 | 质量报告、TR 评审纪要 |
| TMG | 测试经理 | 全流程测试策略 | 测试计划、缺陷趋势 |
| CDE | 持续交付工程师 | DevOps 流水线维护 | Dockerfile、Jenkinsfile |
RACI模型是一个用于明确项目或流程中角色与职责的责任分配矩阵。它通过四个关键角色来厘清"谁该做什么"，有效避免职责不清和协作混乱。
三、流程落地"七件套"工具链（内部代号→商用等价）
-
需求管理：RDM → Jira + Confluence
-
配置管理：iSource（Git 企业版） → GitLab EE
-
持续集成：Hos BuildCloud → Jenkins + K8s
-
代码质量：CodeDEX → SonarQube
-
自动化测试：TDE Cloud → TestNG + Robot Framework
-
灰度发布：CSE / ServiceStage → Spinnaker/Argo CD
-
监控回滚：AOM + APM → Prometheus + Grafana + Argo Rollouts
四、关键"华为名词"速译（听到黑话能立刻映射）
- Charter：项目章程，相当于产品经理的 BRD + 商业计划书
在华为的项目管理体系，特别是其核心的集成产品开发（IPD）流程中，Charter（项目章程/商业计划书）被誉为项目的"出生证"和"第一颗纽扣"。它远不止是一纸简单的立项申请，而是决定一个产品"为何而生"以及"能否成功"的战略性文件。正如华为高管所强调的："所有的前端的前端的最前端，就是Charter。如果Charter做错了，那事实上全是错的。"其核心目的在于回答两个根本问题：这个产品值不值得投入？以及怎么做才能让它具有市场竞争力？
一份高质量的华为Charter通常会系统性地阐述以下几个关键模块，以确保论证的全面性和深度
- DCP：Decision Checkpoint决策评审点，投资委员会（IPMT）拍板"继续/终止"
集成产品开发（IPD）流程中的关键质量评审节点，确保产品在概念、计划、开发、验证等各阶段都符合预期，是重要的商业决策关口
这是华为从IBM引入并优化的一套产品开发管理模式中的核心概念。DCP是IPD流程中的关键决策门禁，确保产品在进入下一阶段前，其商业可行性、技术方案和资源准备都经过管理团队的严格评审。
主要阶段：通常包括概念决策评审点（CDCP）、计划决策评审点（PDCP）和可获得性决策评审点（ADCP）等。
核心本质：它强调的不仅仅是技术评审，更是商业决策。目的是在投入大量资源前，确保产品"做正确的事"并且"正确地做事"，最大化产品的商业成功概率
3.TR：Technology Review，技术评审 。TR是其产品开发流程中的核心质量保障机制。
共 6 个阶段，TR4 以后才进入测试主流程简单来说，它是一系列在关键节点设置的"体检站"，目的是尽早发现技术风险，确保产品在进入下一阶段前足够成熟可靠 。
TR4评审发生在开发阶段后期，是一个承上启下的关键节点。
核心目标 ：确保所有基本构建模块（Building Block）的详细设计、单元测试和功能验证已经完成，并且达到质量标准，从而可以进入更高层级的系统集成测试。通俗地说，就是检查各个"零部件"都合格了，才能开始组装成"整车"进行测试。
评审焦点：
设计完整性：详细设计是否准确反映了之前的概要设计，每个模块的实现细节是否清晰
模块验证结果：检查模块的功能测试、单元测试等结果，确保其自身功能正常
技术成熟度与风险：评估是否存在尚未解决的关键技术问题，以及应对策略是否有效
进入系统集成测试的标准：判断是否满足开始系统集成测试的所有前提条件
理解华为的技术评审体系，能让你看到一流企业如何通过流程确保产品质量。
与决策评审（DCP）的区别：技术评审（TR）由产品开发团队（PDT）负责，关注技术可行性，结论是建议性的；而决策评审（DCP）由集成组合管理团队（IPMT）负责，关注商业可行性，决定项目是否继续投资以及资源分配，结论是指令性的
。可以简单理解为：TR回答"能不能做得出来"，DCP回答"值不值得继续投钱"。
核心价值：这套体系通过引入跨部门专家视角，将"英雄式"的个人能力依赖，转化为不依赖英雄的、可复制的结构化流程，从而系统性地降低开发风险，保障产品成功
4.ADR：Architecture Decision Record是一个"把架构为什么这么做"写成"可版本化的短文档"的轻量级实践。
一句话：它不是设计说明书，而是"当时为什么选方案 B"的"决策证据"，让后来者（或自己 6 个月后）能快速知道"如果改，会踩哪些坑"。
（1）典型模板（最流行：Markdown + 四段式，Git 一提交就随代码走）
|--------------|---------------|------------------------------------------------|
| 字段 | 必填/选填 | 一句话说明 |
| Title | 必填 | 50 字内，动词开头："用 Redis 而不用数据库会话" |
| Status | 必填 | Proposed → Accepted → Deprecated → Superseded |
| Context | 必填 | 当时面对什么业务/技术/约束" （数据量暴涨、QPS 1w、预算 5w、团队只熟 Java） |
| Decision | 必填 | "我们决定怎么做" （用 Redis + 8G 内存 + 15 min TTL） |
| Consequences | 必填 | "好处 vs 代价" （+ 性能 3 倍，-- 需运维 Redis、丢会话可接受） |
| ADR 编号 | 可选 | ADR-0001，方便后续 ADR-0007 引用并标记 Superseded |
范例：
（2）放在哪？怎么管？
1 个 Git 仓库一个 /docs/adr/ 目录，文件名 0001-use-redis-for-session.md
合并请求（MR/PR）里把 ADR 当代码一样 review；不接受"口头决策"
工具链：
-- adr-tools（npm 一键生成模板）
-- Log4brains（自动生成本地静态网站，可搜索、可视化决策链）
（3）一条最小可落地的"ADR 工作流"
（4）发现架构岔路口 → 2. 写 1 页 ADR-PR → 3. 架构师+Dev+QA 评论 → 4. 合并即 Accepted
（5）半年后场景变化 → 6. 新建 ADR-0012 标记"Supersedes ADR-0001" → 7. 旧 ADR 状态改为 Deprecated，永不删，形成链式溯源。
总结：
ADR 就是"架构的 Git Commit Message"：不改历史，只追加，让"为什么"永远可回滚、可追踪。
- 3+1 质量目标：现场事故 ≤X、遗留缺陷 ≤Y、一次开通成功率 ≥Z，+ 客户满意度
"3+1"质量目标是华为在 IPD 流程中给产品开发项目设定的统一质量出口准则，用"3 个可量化指标 + 1 个客户主观感受"把"质量合格"变成硬杠杠，任何产品在 TR5/TR6 之前必须全部达标，否则不能放量上市。
|-------------|-----------------|----------------------------------|-----------------------------------------------------|
| 编号 | 维度 | 量化指标（示例值，不同产品基线略有浮动） | 解释 |
| 3-1 | 现场事故 | 立项时设定"0 级事故 ≤ X 起，1 级事故 ≤ Y 起" | 现网运行中出现的致命/严重缺陷，直接决定要不要"召回"。 |
| 3-2 | 遗留缺陷密度 | 每 KLOC ≤ n 个严重以上缺陷（或每功能点 ≤ m 个） | 通过代码扫描、测试、检视发现但未关闭的高等级缺陷。 |
| 3-3 | 一次开通成功率 | 工程开局/批量交付场景下，首次上电/升级成功率 ≥ Z% | 反映产品"可交付性"，低于阈值就判定"不具备规模交付条件"。 |
| +1 | 客户满意度 | 客户验收/试用评分 ≥ 80/100 分（或 NPS ≥ 30） | 由代表处/客户工程部在 Beta、POC、试点局点实测问卷得出，主观但具有一票否决权。 |
一句话总结：3 个数字（事故、缺陷、成功率）必须过关，再加客户点头，才能批量发货。
6."3551" 敏捷：3 级需求（Epic→Feature→Story）、5 层计划、5 类看板、1 套度量
华为内部把"3551"当成"大规模硬件+软件混合产品"落地敏捷的操作说明书，不是理论模型，而是"拆到每一天、能站会直接用"的模板。拆开就是：
①3级需求分层 ②5层计划 ③5类看板 ④1套度量
（1）3 级需求分层------让"客户一句话"到"程序员任务"不断裂
|------------|----------------|--------------|-------------|----------------------------------|----------------------|
| 层级 | 华为内部叫法 | 颗粒度 | 谁来写 | 典型模板 | 出口准则 |
| L1 Epic | 史诗需求 | 可独立带来收入或竞争力 | PM/SE | <需求名称+商业目标+预估收入> | 过 PDT 评审，挂 Charter |
| L2 Feature | 特性需求 | 可独立演示、用户可感知 | SE/PO | <用户故事地图+验收标准> | 过 TR2 架构评审 |
| L3 Story | 用户故事 | 1 周内可开发、测试完成 | Dev/测试 | <As...I want...So that...+DOD> | 过 Sprint 计划会，估点≤8 人时 |
（2）5 层计划------让"公司年度预算"对齐"今天 Task"
|------------|--------------|------------|------------------|--------------------|--------------|
| 层级 | 计划名称 | 周期 | 对齐会议 | 输出物 | 备注 |
| L1 BP | 年度商业计划 | 1 年 | SP/BP 评审 | 年度收入、预算、人力包 | 公司级 |
| L2 Roadmap | 产品路标 | 半年 | PMT 例会 | 发布节奏、重大特性时间窗 | 产品线级 |
| L3 Release | 版本计划 | 3 个月 | Release Planning | 版本 backlog、里程碑 | 大版本 V100R001 |
| L4 Sprint | 迭代计划 | 2 周 | Sprint 计划会 | Sprint backlog、燃尽图 | Scrum 标准节奏 |
| L5 Day | 日计划 | 1 天 | 每日站会 | Task 看板、阻塞问题 | 15 min 站会 |
（3）5 类看板------"谁该看什么"一目了然
|--------------|--------------|---------------------|-----------------------------|--------------|
| 看板类型 | 面向角色 | 物理位置/工具 | 列泳道典型样式 | 更新频率 |
| 需求看板 | PM、SE | Jira Epic Dashboard | 待分析→已批准→已排期→已发布 | 周 |
| 版本看板 | LPDT、PQA | 电子大屏 | 待开发→开发中→测试中→已集成→已发布 | 日 |
| Sprint 看板 | Dev、测试 | 物理墙+Jira | To Do→Doing→Done→Blocked | 日 |
| 测试看板 | TMG | TestRail | 未执行→Pass→Fail→Retest→Closed | 实时 |
| 问题看板 | 全员 | Confluence 页面 | 新提交→定位中→已修复→已回归→Closed | 实时 |
（4）1 套度量------"只留 6 张图，其余全部下墙"
华为把几百项指标收敛成"6 张必挂图"，每周自动化出数据，超标自动邮件+短信。
- 需求 Burn-down（Epic/Story）
- 缺陷趋势（新建/关闭/遗留）
- 代码提交频度（每人日均 Commit 数）
- 持续集成成功率（Pipeline 绿/红）
- 一次编译打包时长（门禁≤30 min）
- 上线缺陷密度（每 KLOC 严重缺陷）
（5）一张"3551"日常落地时间轴（2 周 Sprint 实例）
|------------|------------------|-------------------------|
| 时间 | 活动 | 产出 |
| 周一上午 | Sprint 计划会（4 h） | Sprint Backlog、Task 卡贴墙 |
| 每天 9:15 | 站会 15 min | 更新 Sprint 看板、阻塞问题 |
| 周三晚 | 持续集成门禁 | 代码合并到主干，绿线才能进 |
| 周五下午 | Sprint Demo（1 h） | 可运行软件给客户/PO |
| 周五下午 | 回顾会（30 min） | 改进 Action 进 Jira |
| 周末 | 自动化出 6 张图 | 邮件推送全员，超标红色预警 |
"3551"就是华为把"大兵团作战"切成 2 周一次的小冲刺：
3 层需求拆得清，5 层计划对得齐，5 块看板看得懂，6 张图量得准。
7.Sonar："严重（Blocker/Critical）"不是主观感受，而是平台内置的、会导致生产事故或安全漏洞的代码缺陷。只要扫描报出这类问题，华为/大多数公司的质量门禁就直接判为"不通过"，版本无法集成。一句话：严重问题＝不修复就禁止上线。
官方四级 severity 与"严重"对应关系
|------------|------|-------|------------|--------------------|
| Sonar 级别 | 警示图标 | 中文习惯 | 是否属于"严重问题" | 典型场景 |
| Blocker | 红灯 | 阻断级 | ✅ | 空指针必崩溃、死循环、SQL 注入 |
| Critical | 橙灯 | 严重级 | ✅ | 资源未释放、硬编码密钥、XXE 漏洞 |
| Major | 黄灯 | 主要 | ❌ | 代码坏味道，可延期处理 |
| Minor/Info | 绿灯 | 轻微/提示 | ❌ | 格式、命名，不影响质量门禁 |
总结：在 Sonar 世界里，只要级别显示 Blocker/Critical，就属于"严重问题"------零容忍，不改完不让上线。
8.Feature Toggle： 特性开关是一种"在运行时通过配置或代码开关，快速启用/禁用某个功能，而无需重新部署"的持续交付技术。
一句话：把"功能"做成可远程拉闸的电灯，而不是"一次性砌死的墙"
为什么要用？------"主干开发 + 快速上线"的刚需
• 未开发完的功能也能合并到主干，保持小步快跑
• 灰度发布：先让 1% 用户尝鲜，出问题秒级关闭
• A/B 实验：同一套代码，给不同用户返回不同逻辑
• 回滚提速：现网事故不用重新打包发版，改配置即可止血
四类常见开关（Martin Fowler 分类）
|-------------------|--------|---------|-------------|
| 类型 | 生命周期 | 场景 | 示例 |
| Release Toggle | 几天~几周 | 开发中功能隐藏 | 新支付通道默认 off |
| Ops Toggle | 降级/限流 | 降级/限流 | 关闭 CPU 密集算法 |
| Experiment Toggle | 几周 | A/B 测试 | 蓝色 vs 红色按钮 |
| Permission Toggle | 长期 | 付费功能 | 会员可见 4K 清晰度 |
华为/大厂落地要点
• 配置中心统一托管，开关变更审计日志留存 3 年
• 命名规范：产品线.模块.功能.环境，例如 bss.order.coupon2025.prod
• 代码里只写**"读开关"**，禁止写死 if(true)；MR 必须 Review
• 上线后 7 天无异常，创建"清退任务"把开关从代码里物理删除，防止腐烂
Feature Toggle 就是"把功能装进 if 语句，用配置当遥控器"，让"发版列车"与"功能曝光"彻底解耦，实现主干开发、灰度发布、秒级回滚的核心技术。
9.灰度开发
灰度开发是一种软件部署策略，其核心思想是将新版本软件分批次、逐步地推向用户，而非一次性全量发布。这种方式就像在纯黑（旧版本）和纯白（新版本）之间增加了一个灰色过渡地带，从而实现平滑、可控的版本迭代。它也被形象地称为"金丝雀发布"，这个典故源于矿工用金丝雀来预警有毒气体，寓意让小部分用户先行测试新版本，以便提前发现潜在问题
灰度发布的关键要素
一个成熟的灰度发布体系通常包含以下几个核心环节，它们共同构成了风险控制的闭环：
可灰度（Gradual Rollout）：这是基础。系统需要具备将流量或用户按特定策略进行划分的能力。常见的策略包括按用户ID/设备ID打标、按地理区域、按渠道来源，或简单地按百分比放量。技术上可以通过网关、负载均衡器或服务网格（如Istio）的流量路由规则来控制。
可监控（Comprehensive Monitoring）：这是眼睛。在灰度过程中，必须对新版本的运行状态了如指掌。监控应是全方位的，包括系统指标（如CPU、内存）、应用性能（如接口响应时间、错误率）、业务数据（如订单成功率）以及用户反馈等。一旦发现异常指标，便能及时干预。
可回滚（Quick Rollback）：这是安全的底线。如果监控到新版本存在严重问题，必须能够快速撤回变更，使系统恢复到之前的稳定状态。回滚方案应事先经过演练，确保在紧急情况下能高效执行，最大限度减少对用户的影响。
主要应用场景
灰度发布在实践中应用非常广泛，主要包括：新功能或产品上线：在全面推广前，先让小部分用户（如内部员工或种子用户）体验，验证功能效果和稳定性。
A/B测试：同时灰度发布两个或多个不同版本的功能（A版本和B版本），通过对比用户行为数据来选择更优方案。
微服务架构下的部署：在容器化、微服务环境中，灰度发布是进行服务版本更新的标准方式，常通过Kubernetes和Istio等服务网格工具来实现精细化的流量控制
10. RCA 分析方法
在华为的运营和质量管理体系中，**根本原因分析（RCA）**是一项至关重要的核心流程。当产品、项目或网络出现故障或问题时，团队会运用RCA方法，遵循一套结构化的步骤：
- 问题定义：清晰界定问题及其影响。
- 数据收集：收集与问题相关的所有信息。
- 原因分析：使用诸如鱼骨图、5个为什么等工具，层层递进地分析，直至找到问题的根本原因。
- 制定措施：针对根本原因制定并实施纠正和预防措施。
- 验证有效性：跟踪并确认措施是否真正解决了问题。
这套方法的目的是从系统上防止问题的再次发生，而不仅仅是"救火"，体现了华为对质量的高度重视。
五、可复制"最小化华为 IPD-DevOps"模板
-
立项：用一页《Charter》回答 5 个问题（客户是谁、痛点、竞争对手、盈利模式、退出条件）。
-
需求：建立 3 层 Backlog（Epic/Feature/Story），每周优先级动态刷新。
-
架构：SE 输出《系统架构说明书》+ 接口契约，用 ADR（Architecture Decision Record）保持轻量。
-
迭代：2 周 Sprint，每天 10 min 站会，Sprint 末开 Demo & Retrospective。
-
质量：
-
门禁：单元测试覆盖率 ≥80%、Sonar 严重问题 =0、安全扫描 =0。
-
TR 轻量评审：用"架构看板"替代重型文档，评审时间 ≤1 h。
-
发布：主干开发 + Feature Toggle特性开关，灰度 5%→30%→100%，自动回滚窗口 5 分钟。
-
复盘：现网事故 24 h 内给出 RCA，采用"5 Whys + 改进 Action 责任人"。
一句话总结：
华为研发管理=IPD 做"投资管控" + 敏捷/DevOps 做"快速交付" + 工具链做"质量门禁"，再用全员 KPI 对齐"商业成功"而非"功能上线"，从而把"重型坦克"开出"跑车速度"。