/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
大厂研发流程全景图
0. 为什么程序员要懂这些
面试被问"你们团队怎么协作的"，入职后发现周会上全是 Sprint、Backlog、RPN 这些词——如果你一脸茫然，就会非常被动。
这一套名词本质上是**流程（怎么组织开发）+ 方法（怎么做决策和质量）+ 工具（用什么承载）+ 合规（有什么门槛）**四个维度的集合。
这篇文章把它们全部串进一条研发主线里讲清楚。
1. 大厂研发全流程：六个阶段
无论用什么方法论，一条主线是固定的：
需求与规划 → 方案与设计 → 迭代开发 → 质量与测试 → 发布与运维 → 反馈改进（再回到需求，形成闭环）
每个阶段的典型活动：
- ① 需求与规划：产品经理产出 PRD、用户故事，用 Roadmap 排期，需求进 Jira Backlog；
- ② 方案与设计：架构设计、技术方案评审，用 Functional Map 拆功能范围、Pugh Matrix 选型、DFMEA 预判风险；
- ③ 迭代开发：敏捷 Sprint 内完成开发，Code Review + 单测是两道质量闸门；
- ④ 质量与测试：CI 自动构建跑测试，QA 跟进，Six Sigma 管缺陷度量；
- ⑤ 发布与运维：CD 流水线发布，灰度放量、监控告警、一键回滚；
- ⑥ 反馈改进：线上数据复盘，产出下一轮需求。
2. 流程模型：瀑布 vs 敏捷
2.1 瀑布开发（Waterfall）
来历：
1970 年 Winston Royce 在论文《Managing the Development of Large Software Systems》中描述了这种线性模型——有趣的是他本人是在批评这种"一步到位"的做法，但后人把它命名为"瀑布模型"并广泛采用。
阶段：
需求分析 → 系统设计 → 编码实现 → 系统测试 → 部署维护，每阶段有正式交付文档和阶段评审门（Gate），上一阶段没验收就不能进入下一阶段。
优点：
计划性强、文档完备、阶段目标清晰、便于审计和人员交接。
缺点：
变更代价随阶段指数上升（改需求≈返工整个下游）；
用户直到最后才能看到可用产品；风险后置。
适用：
需求稳定、强监管行业（医疗、汽车安全件、航天）、外包合同制项目——这些场景下"过程可审计"本身就是硬要求。
2.2 敏捷开发（Agile）
来历：
2001 年 2 月，17 位软件开发者在犹他州雪鸟滑雪场发布了《敏捷宣言》，核心是四条价值观：
Scrum 是敏捷最主流的落地框架，三者缺一不可：
敏捷的优点：
拥抱变化、持续交付可用软件、风险早暴露（每 2~4 周就能看到成品）、团队自驱。 敏捷的缺点：
文档偏轻、范围容易蔓延、对团队成熟度和 PO 能力要求高，纯敏捷在强监管行业很难过审。
适用：
互联网产品、需求易变、探索型项目。
2.3 大厂实际怎么用
现实中几乎没有"纯瀑布"或"纯敏捷"，主流是敏捷为主干 + 工程化质量闸门：
- 需求用 Backlog 管理，Sprint 迭代开发；
- 但每个合入都有 Code Review、CI 检查、自动化测试（这部分是硬门禁，和瀑布的 Gate 异曲同工）；
- 阶段性的技术评审、架构评审仍然保留；
- 强监管环节（医疗/汽车）保留瀑布式的文档和认证流程。
一句话：互联网节奏用敏捷，审计要求用瀑布，两者混搭。
3. 规划层：Roadmap 与 Functional Map
3.1 需求导入・QFD（质量功能展开）
定义：
Quality Function Deployment，1970s 由日本学者水野滋、赤尾洋二提出，核心工具是质量屋（House of Quality）—— 把客户模糊的需求翻译成工程可执行的参数。
质量屋结构：
- 左墙：客户需求（VOC）及其重要度权重；
- 天花板：工程特性（可测量的技术参数）；
- 房间：需求 — 特性关系矩阵（强 ○ / 中 △ / 弱空白）；
- 屋顶：工程特性之间的相关矩阵（正相关 / 负相关，如 "重量" 与 "耐用性" 可能冲突）；
- 地下室：工程特性的目标值与重要度排序。
例子：
客户说 "手机要耐用" → 工程语言是 "1.5m 跌落无损坏、按键寿命 10 万次、防水 IP68"。
产出：
质量屋矩阵、关键质量特性（CTQ）清单。
衔接：
QFD 的产出直接成为 01 Pugh 的评估准则、02 BasicStatics 的量化对象 ——没有 QFD，后面所有环节都在 "凭感觉" 做。
3.2 Roadmap（产品/技术路线图）
定义：
按时间轴排布版本发布、里程碑和关键特性的规划图，回答"什么时间做什么、优先级怎么排"。
两种类型：
- 产品路线图：面向用户/业务，排版本功能（Q1 做登录体系，Q2 做社区，Q3 做商业化……）；
- 技术路线图：面向工程师，排架构演进、技术债清理、平台能力（如"Q2 完成微服务拆分""Q3 上容器化"）。
写法要点：
目标 → 时间桶（Quarter/Month）→ 主题（Theme）→ 特性；
常用 NOW / NEXT / LATER 三档排优先级。
它的本质是沟通工具：
向上对齐战略，向下统一节奏，让所有人知道"为什么现在做这个"。
3.3 Functional Map（功能地图）
定义：
从用户需求出发，把产品逐层拆解成"模块 → 功能 → 子功能"的功能树，也叫功能结构图。
怎么拆：
作用：
明确范围边界（防范围蔓延）、是 PRD 的骨架、直接映射到 Backlog 的用户故事拆分。
它和 Roadmap 的关系是：
Roadmap 决定"什么时候做"，Functional Map 决定"到底做哪些"。
4. 决策与风险：Pugh Matrix 与 DFMEA
4.1 Pugh Matrix（普氏矩阵）
定义：
由英国设计工程师 Stuart Pugh（1960s）提出的概念选型矩阵，用于在多个候选方案中客观选优。
五个步骤：
示例打分表（示意）：
| 成本（0.3） | 0（基准） | + | − |
| 性能（0.3） | 0 | + | S |
| 可维护性（0.2） | 0 | S | + |
| 风险（0.2） | 0 | − | + |
| 汇总 | 基准 | +1（略优） | +1（略优） |
优点：
客观、透明、可追溯——评审时不会变成"谁嗓门大听谁的"；
缺点：
准则和打分仍带主观性，需要团队共同校准。
4.2 DFMEA（设计失效模式与影响分析）
定义：
在设计阶段**系统性预判"哪里会失效、后果多严重、多难发现"**的风险分析方法。起源于 1949 年美国军方 MIL-P-1629，1960s 被 NASA 用于阿波罗计划，1977 年福特引入汽车行业；现在遵循 AIAG-VDA FMEA 手册（2019 第一版）。
核心三因子（各 1~10 分）：
- S（Severity）严重度：失效后果有多严重，10 = 安全/法规问题；
- O（Occurrence）发生度：失效发生的可能性，10 = 几乎必然发生；
- D（Detection）探测度：现有手段发现它的难度，10 = 极难发现。
RPN（Risk Priority Number）= S × O × D，取值 1~1000，越高越优先处理。
注意：
新版 AIAG-VDA 手册已改用 AP（Action Priority） 高/中/低来排序，但 RPN 在业界仍被广泛使用
DFMEA 的价值：
它强迫团队在设计阶段就把"最坏情况"想清楚，而不是等量产/上线后炸雷。
强监管行业做认证时，DFMEA 文档是必须的审计证据。
5. 质量与交付：DevOps 与 Six Sigma
5.1 DevOps（开发运维一体化）
来历：
2009 年 Patrick Debois 在比利时组织了第一届 DevOps Days，"DevOps"一词由此流行。它不是工具，而是文化 + 实践 + 工具的组合。
核心理念 CALMS：
- Culture：开发与运维打破部门墙，共同为产品负责；
- Automation：一切可自动化的都自动化；
- Lean：精益思想，消除浪费；
- Measurement：用数据度量交付和稳定性；
- Sharing：知识共享、共同承担 on-call。
工程落地（一条典型流水线）：
提交代码 → CI（自动构建 + 单元测试 + 静态检查）→ 产物打包 → CD（自动部署到测试/预发环境）→ 灰度发布 → 监控告警 → 反馈。
关键实践：
- 基础设施即代码（IaC）：Terraform / Ansible；
- 部署策略：蓝绿部署、金丝雀（灰度）发布、滚动更新；
- 监控：Prometheus + Grafana、链路追踪、日志聚合；
- DORA 四指标：部署频率、变更前置时间、变更失败率、服务恢复时间——大厂评估研发效能就盯这四个数。
5.2 Six Sigma（六西格玛）
来历：1986 年由摩托罗拉工程师 Bill Smith 提出，1990s 被通用电气 CEO 杰克·韦尔奇发扬光大。
定义：以数据驱动的质量改进方法论，目标是缺陷率低至 3.4 DPMO（百万次机会中仅 3.4 个缺陷）——对应正态分布 6σ 水平。
核心流程 DMAIC（改进现有流程）：
（设计新流程用 DMADV / DFSS。）
角色体系：
Champion（高层推动者）→ 黑带（全职专家）→ 绿带（兼职执行）。
在软件研发里，Six Sigma 常被用来做缺陷治理专项：
定位缺陷密度高的模块 → 分析根因 → 改进 → 用度量持续监控。
6. 工具与合规：Jira 与法规认证
6.1 Jira（项目管理工具）
简介：
Atlassian 于 2002 年推出的项目管理工具，是敏捷研发的"事实标准"。
国内大厂还常用禅道、腾讯 Tapd、阿里云效，但 Jira 概念是通用的。
核心概念：
- 工作项类型：Epic（大需求）→ Story（用户故事）/ Task（任务）/ Bug（缺陷），可再拆 Sub-task；
- 看板：Scrum 板（按 Sprint 管理）/ Kanban 板（按流程持续流动）；
- 工作流：To Do → In Progress → In Review → Done，状态流转就是研发进度；
- 报表：燃尽图（Burndown，看 Sprint 进度）、累积流量图（看队列健康度）。
和前面概念的关系：
Roadmap 的季度计划落到 Jira 的 Epic；
Functional Map 的功能树拆成 Story 进 Backlog；
Sprint 计划会就是把 Backlog 拖进 Sprint 板。
Jira 是整个研发流程的"数字神经系统"。
6.2 法规认证（强监管行业的上市门槛）
为什么软件行业也讲认证：
医疗、汽车、航空软件的 bug 可能直接危及生命，因此法规要求过程可追溯、证据可审计。
典型标准（按行业）：
| 医疗器械 | NMPA（中国）、FDA 510(k)/PMA（美国）、MDR/CE（欧盟） | 软件作为医疗器械（SaMD）要单独审 |
| 汽车 | ISO 26262（功能安全）、ASPICE（过程评估） | ASIL A~D 安全等级，D 级最严 |
| 航空 | DO-178C（软件）、DO-254（硬件） | 按 DAL A~E 等级控制 |
| 通用质量 | ISO 9001、ISO 13485 | 质量管理体系认证 |
对开发流程的影响：
认证要求设计文档、测试证据、变更记录、风险分析（含 DFMEA）全程留痕——这就是为什么这些行业保留瀑布式阶段门。
做医疗器械/汽车软件的程序员，写代码只是工作的一小半，另一半是"为审计写证据"。
7. 一张图串起来 + 学习路线
一条完整的主线：
季度初定 Roadmap → 需求评审进 Jira Backlog → 用 Functional Map 拆功能范围 → 每个 Sprint 迭代开发（设计关口用 Pugh Matrix 选型、DFMEA 预判风险）→ 代码合入触发 CI/CD 流水线（DevOps）→ 灰度发布 + 监控反馈进下一轮；
Six Sigma 负责专项质量改进；
合规产品发布前过法规认证闸门。
面试问题准备
敏捷开发和瀑布开发的区别？各自的优势是什么？
先从两种开发流程进行解释吧。
敏捷开发是通过使用将项目开发分解为子系统进行验证，确保是在需求的规范下进行的实现。在子系统开发完毕后需要及时跟需求方进行沟通、展示，进而确保开发的过程是符合客户需求而不是闭门造车。
而瀑布开发就完全不同，在需求导入结束后就需要对需求进行冻结。然后按部就班的进行开发工作，依次确保每子功能模块都完成验证后才能再继续开发，整个流程是单向的一旦在开发的过程中发现了前期的需求出现了问题就基本上很难再做调整，大概率要重新开始。
根据上述的两种流程也能体现出各自的优势。
敏捷的优势主要体现在对于产品的开发是非常灵活的，需求的变动基本上很难影响到开发进度；但是过度的需求变更会导致项目范围蔓延，需求方会陷入既要又要的状态。同时缺点也很明显，对团队的整体水平要求比较高，需要用最短的时间实现最关键的技术路径。而且对于项目经理的技术理解能力要求也比较高，要能准确的带领团队向着最快最短的技术路径进行攻克，及时把控进度跟方向。
瀑布开发的优点在于对团队的整体水平要求就没有敏捷那么高，适用于产品本身就趋于稳定的状态进行开发。能确保开发的过程难度是相对线性的，对产品经理的水平要求就没有那么严格了；缺点就是一旦需求发生变更，返工成本非常高。而且因为流程是一步一步实现的，测试位于开发之后。这样就会导致一旦在测试中发现问题和错误，就会造成返工和浪费。
