瀑布开发更适合硬件，软件慎用

一、先抛结论：瀑布开发不是“落后”的代名词，它在硬件领域是成本最优解

先讲一个我亲身经历过的场景。

2019年，我参与了一个智能穿戴设备的研发项目。硬件团队和软件团队坐在同一层楼，但工作节奏完全不同。硬件那边，PCB（印刷电路板）设计一旦定稿送厂打样，改一根走线的成本是8000块，周期是两周。软件这边，改一个交互逻辑，推一个hotfix，最快30分钟上线。

当时一个产品经理习惯了互联网的迭代思维，在硬件已经进入EVT（工程验证测试）阶段时提出“把心率传感器的位置向左移1.2毫米”。硬件负责人直接拍了桌子：“你知道这一移，模具要重开、FPC排线要重画、天线匹配要重调、EMC测试要重做吗？这一句话，40万预算、一个半月交期就没了。”

这件事让我深刻理解了一个道理：方法论的选择，本质上不是信仰问题，而是成本结构问题。当修改的边际成本高到无法承受时，“拥抱变化”就是一句空话。当修改的边际成本趋近于零时，“前期穷尽一切需求”反而是对市场机会的浪费。

所以我的核心结论很简单：瀑布开发更适合硬件，不是因为它“传统”，而是因为硬件的物理制造属性决定了后期变更成本极高；软件慎用瀑布，不是因为软件“先进”，而是因为软件的纯逻辑属性决定了它的试错成本极低，瀑布的刚性流程会锁死软件的灵活性优势。

这个结论不是从教科书上抄来的，是我在过去十五年里，经历过嵌入式系统开发、智能硬件创业、企业级软件交付之后，用真金白银和延期惩罚条款换回来的判断。

二、拆解根因：硬件开发的“物理刚性”与软件开发的“逻辑弹性”

1. 硬件开发的四道“物理枷锁”

很多人讲瀑布开发适合硬件，只讲到“需求稳定”就停了。这个解释太浅。硬件为什么需求稳定？不是因为硬件工程师更严谨，而是因为物理世界有四道枷锁，把变更空间锁死了。

第一道枷锁：物理依赖关系的不可逆性。

软件系统中，模块之间的依赖关系是逻辑性的。你改了A模块的接口，B模块调用失败，改一下适配层就行。但在硬件中，依赖关系是物理性的。

举一个真实的例子：在一个手机项目中，天线设计必须放在结构设计之后，因为天线位置取决于金属中框的开缝位置；而金属中框的开缝位置又取决于ID（工业设计）造型；ID造型又取决于屏幕模组的尺寸和电池容量；电池容量又取决于整机厚度目标。这条链路上的每一环都是硬依赖，前面不改，后面才能往下走。这不是“瀑布流程强加给你的”，而是物理规律强加给你的。你把流程换成敏捷，物理依赖关系不会消失。

第二道枷锁：验证成本的阶梯式跳变。

软件开发中，单元测试、集成测试、回归测试的成本增长是线性的，跑一次自动化测试套件多则几小时，少则几分钟。但硬件验证的成本是阶梯式跳变的。

以芯片设计为例：RTL（寄存器传输级）仿真阶段，发现问题改一行代码，成本接近于零。一旦进入综合和布局布线，修改成本开始上升。等到流片（Tape-out）之后发现问题，那对不起，一次重新流片的费用是几百万到几千万人民币，周期是三到六个月。这不是流程效率问题，这是物理世界的制造规律。

第三道枷锁：供应链的长周期锁定。

一个复杂的硬件产品，BOM（物料清单）可能包含几百颗元器件。其中有几十颗是长交期物料，比如特定的传感器芯片、专用连接器、定制电池，交期动辄12周到20周。你一旦确定BOM并下单采购，这批物料就锁定了你的设计空间。项目中期想换一颗主芯片？可以，但这批物料怎么办？报废还是退供应商？供应商愿不愿意接退单？

这意味着硬件项目存在一个“采购临界点”，过了这个点，变更成本不再只是研发成本，而是叠加了供应链沉没成本。瀑布开发强调的“阶段评审”“基线冻结”，本质是在这个临界点到来之前，把所有不确定性消化掉。

第四道枷锁：合规认证的不可跳过性。

任何面向市场销售的硬件产品，都必须通过一系列强制认证：中国的3C、欧洲的CE、美国的FCC、蓝牙的BQB、Wi-Fi的Wi-Fi Alliance认证……这些认证本身就需要固定的周期和费用。更关键的是，认证测试的是“最终形态的样机”。如果认证之后你改了天线设计，FCC需要重测；改了电源Layout，EMC（电磁兼容）需要重测。重测意味着重新排队、重新付费、重新占用人力。

瀑布流程中把“认证”作为一个明确的阶段门（Stage Gate），这不是为了官僚主义，而是为了确保认证通过的样机就是量产出货的样机。在这个环节搞“迭代”，就是在合规风险上跳舞。

2. 软件“慎用瀑布”的底层原因

说完硬件，再说软件这一侧。我为什么说“软件慎用”，而不是“软件禁用”？因为有一些类型的软件项目，依然适合瀑布，比如航天飞控软件、医疗植入设备固件、核电控制系统。这些软件的修改成本也不低（涉及人身安全、监管重审），所以瀑布的严谨性是有价值的。

但对于绝大多数商业软件和互联网产品来说，瀑布模型是“镣铐”而不是“护城河”。原因有三。

第一，软件需求天然是“熵增”的。

用户看到功能A，会联想到他们需要功能B；竞品推出了功能C，市场倒逼你跟进功能D。软件需求在交付给用户之前，是产品经理脑子里的一团概率云，只有真正交付、让用户用了，这团云才会塌缩成确定的需求。瀑布假设需求在项目初期可以穷举清楚，这在软件世界里是一个“优雅的谎言”。

我在2016年带过一个企业级SaaS项目，产品负责人在项目启动时写了一份198页的PRD（产品需求文档），自以为穷尽了一切场景。结果上线三个月后，真实用户行为数据显示，前20%高频使用的功能，和那198页文档里预测的功能列表，重合度不到40%。大量精心设计的功能根本没人点，而用户真正需要的几个能力反而缺失。这就是“闭门造车式瀑布”的典型后果。

第二，软件的复制成本为零，这意味着试错成本接近零。

这是硬件和软件最本质的区别。硬件每一次“试错”都意味着物理实体的损耗，打样费、物料费、SMT（表面贴装技术）费用、测试治具费用。软件每一次“试错”只是一次构建和部署，服务器资源成本可以忽略不计。当试错成本趋近于零时，最优策略就是多试、快试、低成本试。瀑布却要求你“一次做对”，这在软件场景下是对低成本试错机会的浪费。

第三，软件的市场窗口期远短于硬件。

一款手机的研发周期是9到18个月，上市后生命周期可能还有12个月。一款互联网产品的市场窗口期可能只有3个月，甚至更短。如果软件也走瀑布的“需求分析，概要设计，详细设计，编码，测试，上线”全流程，等到六个月后产品上线，市场早就物是人非了。

我见过太多在传统软件公司里待久了的项目管理者，跳槽到互联网公司后仍然习惯性地要求“PRD冻结”“需求签字画押”，结果就是团队交付了一个“完美符合八个月前需求文档”但“完美错过市场窗口”的产品。

三、常见误区：把“假性瀑布”和“假性敏捷”当真了

1. 误区一：把“混乱开发”当成了“敏捷”

很多团队声称自己在做敏捷，实际做的是“无计划、无文档、无评审”的三无开发。需求口头传达，架构拍脑袋决定，测试靠线上用户当小白鼠。这不是敏捷，这是“假性敏捷”。

真正的Scrum敏捷开发，包含严格的时间盒（Time-box）、明确的完成的定义（Definition of Done）、每日站会检视进度、每个迭代结束时的评审和回顾。PingCode服务的中大型企业客户中，很多团队在落地Scrum的时候，严格按照Scrum Guide的标准流程来走：

• 需求管理：使用史诗（Epic），特性（Feature），用户故事（User Story）三级结构管理需求，产品负责人（Product Owner）为每一条需求设定优先级和业务价值。
• 迭代规划：在迭代计划会上，团队一起从Product Backlog中拉取高优先级条目，拆分为开发任务，明确本次迭代的Sprint Goal。
• 进度透明：通过燃尽图（Burndown Chart）和工作板（Kanban Board）实时暴露进度，任何人在任何时候打开看板都能清楚当前迭代还剩多少工作。
• 持续改进：每个迭代结束，团队通过回顾会议总结“做得好的、做得不好的、改进计划”，记录在迭代回顾板上，形成持续改进的闭环。

这些实践不是形式主义。敏捷的核心是“频繁检视和调整”，而不是“没有流程”。把混乱当敏捷的人，是对敏捷最大的误解。

2. 误区二：把“假装规划、实际救火”当成了“瀑布”

另一个极端是“假性瀑布”。很多团队名义上走瀑布流程，每个阶段都有评审节点、有签字、有文档。但实际上：

• 需求评审会上，没有人认真看需求文档，因为文档太长、读了也记不住。
• 设计评审会上，评审专家给了意见，但没有人跟踪这些意见是否真的被修改了。
• 阶段评审签字时，签字人迫于项目压力，明明知道有问题，还是签了“通过”。
• 等到测试阶段，发现大量前期应该发现的问题，团队开始“救火式加班”，一边改Bug一边改设计。

这不是真正的瀑布。真正的瀑布，是每个阶段的“完成”有严格定义，前一阶段不达标不允许进入下一阶段。“假性瀑布”的本质是把瀑布流程当成了“进度管理工具”，而不是“质量管控工具”。

两者的区别，用一张表说清楚：

3. 误区三：把“方法论”当成了“宗教”

还有一种常见误区，是把某种方法论奉为信仰，非此即彼。敏捷原教旨主义者说瀑布已经死了，瀑布捍卫者说敏捷就是瞎胡闹。

这种争论毫无意义。方法论的唯一评价标准是：在你的业务场景下，它能不能以更低的成本、更短的时间，交付更高质量的价值。脱离业务场景谈方法论优劣，是技术圈最常见的无效争论。

我见过硬件团队被管理层逼着搞“敏捷转型”，结果就是站会变成了汇报会、迭代计划会变成了需求分配会，烧毁图贴了满墙但进度照样延期。因为硬件的物理刚性决定了它不适用迭代式增量开发，生搬方法论只会增加管理摩擦。

我也见过传统软件企业非要坚持完整PRD和签字画押，两个月的需求分析加一个月的设计，三个月过去了代码一行没写，竞争对手已经迭代了四个版本。这不是严谨，这是用流程的勤奋掩盖决策的懒惰。

四、实战拆解：当一个项目同时包含硬件和软件时，怎么选？

真实世界中，越来越多的产品是“软硬一体”的。比如智能音箱、无人机、新能源汽车、工业控制器。这些项目的管理者面临一个核心问题：硬件部分和软件部分，能用同一套流程吗？

我的答案是：不能，也不应该。但关键是找到硬件和软件的“分水岭”，然后分层管理。

1. 确定“分水岭”：硬件-软件接口（HSI）就是那条线

在嵌入式系统开发中，有一个概念叫HSI（Hardware-Software Interface，硬件-软件接口）。它定义了软件可以和硬件交互的全部寄存器地址、中断号、DMA（直接存储器访问）通道、GPIO（通用输入输出）引脚功能分配等。

HSI一旦定下来，硬件团队和软件团队就可以独立工作了。硬件团队按照HSI的定义去实现硬件的各项功能，软件团队按照HSI去写驱动和上层应用。而这个HSI本身的确定，是一个绝对严谨的瀑布过程，因为它涉及到芯片选型、原理图设计、Layout约束等一系列硬依赖。

这块我可以用一张图来说明：

2. 硬件侧：坚持瀑布，但在局部可以“敏捷化”

硬件开发主体上应坚持瀑布流程，尤其是结构设计、原理图设计、PCB Layout、BOM确认这些强依赖环节。但这不意味着硬件团队完全不能借鉴敏捷的思想。

在几个特定环节，硬件团队可以用“局部敏捷”提升效率：

• 方案选型阶段的快速原型验证：在正式进入硬件设计之前，买开发板、搭原型、跑通关键链路。这个过程可以快节奏迭代，因为成本很低。
• FPGA原型验证：对于ASIC（专用集成电路）类项目，在流片前用FPGA（现场可编程门阵列）做功能验证，FPGA本身就是可重复编程的，天然支持迭代。
• 固件开发：固件是跑在硬件上的底层软件，在硬件板卡到位之前，固件团队可以用仿真器或参考板先行开发。硬件板卡回板后，固件团队可以按照敏捷节奏持续优化。

但核心底线不可突破：一旦进入PCB打样、模具开模、物料采购这些“不可逆”环节，必须切换回瀑布的严谨模式。

3. 软件侧：大概率选敏捷，但也要诚实面对约束

对于软硬一体产品中的软件部分，我一般建议采用Scrum或Scrumban。以PingCode的Scrum解决方案为例，软件团队可以这样跑：

• Product Backlog管理：所有软件需求进入统一的需求池，Product Owner负责优先级排序。硬件相关的需求（比如驱动适配）和非硬件相关的需求（比如应用层交互）都放在一个Backlog里，用优先级来区分。
• Sprint规划：每个Sprint开始前，团队从Backlog顶部拉取高优先级需求，结合HSI已冻结的部分，评估哪些可以开发，哪些受限于硬件进度需要延后。
• 每日站会：同步进展、暴露阻塞。尤其关注依赖硬件联调的阻塞项，如果硬件交付延期，软件团队及时调整Sprint范围。
• Sprint评审和回顾：每个Sprint结束时演示可工作的软件，收集反馈并持续改进。

这里有一个常见坑点：软件团队的Sprint节奏不能和硬件的里程碑完全对齐。硬件的一个阶段可能持续6到8周，软件如果也以这个节奏迭代，敏捷的优势就丧失殆尽。正确的做法是软件保持自己的Sprint节奏（通常2周），硬件里程碑和软件Sprint之间的关系是“信息同步”而不是“节拍锁定”。

五、一个必须回答的问题：硬件真的不能敏捷吗？

写到这里，我必须主动回应一个行业争论：近年来有人提出“硬件敏捷”（Hardware Agile）的概念，主张将敏捷原则应用到硬件开发中。这种方法到底行不行？

我的判断是：局部可行，整体不行。

（1）敏捷在硬件中“局部可行”的地方

在硬件预研阶段，团队可以通过“快速原型”的方式试验多种技术方案。比如用3D打印验证结构可行性，用面包板搭电路验证功能逻辑，用FPGA验证算法。这些行为的成本足够低、节奏够快，和敏捷的“构建-测试-学习”循环是匹配的。

另外，在硬件IP复用场景下，也具有一定的“迭代”特征。比如你公司已经有一个成熟的电源管理模块设计，在新项目中直接复用，只需要针对新需求做少量适配。这类似于软件中的“组件复用”。

（2）敏捷在硬件中“整体不行”的地方

一谈到“交付可工作的硬件增量”，硬件敏捷就遇到了物理世界的墙壁。软件可以每两周交付一个“可工作的软件”，因为软件的部署成本为零。硬件每两周交付一个“可工作的硬件”？那就意味着每两周打一次板、每两周做一次SMT、每两周做一次结构件。先不说成本，光是供应链的响应周期就跟不上。

还有一个更深层的问题：硬件设计中的决策往往是全局耦合的。你换了一个传感器，可能会影响供电方案、信号调理电路、PCB面积、散热设计、结构配合、BOM成本多达六个维度。这种全局耦合性使得硬件不适合“增量式交付”，你没办法先交付“半个硬件”让用户试用，再迭代成“一个硬件”。

所以我不建议硬件团队盲目追求“敏捷转型”。踏踏实实把瀑布的每个阶段做扎实，在可控的低成本环节引入快速原型验证，这才是硬件的务实路线。

六、企业级实践观察：翻过车的团队都有什么特征？

过去几年，我通过PingCode服务过的中大型企业客户群体，观察到了一些规律。PingCode的客户以100人以上的研发组织为主，覆盖软件开发、硬件制造、软硬一体等多个行业。这些企业在方法论选择上的得失，具有一定的参考价值。

1. 翻车类型一：软件团队被瀑布流程“憋死”

某传统软件企业，产品主要面向政企客户，交付模式以私有化部署为主。管理层从硬件制造行业转过来，坚持要求“PRD完整度必须达到95%以上才能进入开发”。

结果是：一个版本的需求分析耗时3个月，设计耗时1个半月，等到开发真正启动时，竞品已经迭代了两个小版本。更糟糕的是，因为前期没做任何可运行的代码验证，PRD中的很多“理所当然”在开发阶段被发现技术上不成立或者实现代价极高，团队被迫在开发阶段改需求。这3个月的需求分析工作，有相当一部分价值被后期变更消解了。

这个案例后来踩过的坑，我总结起来就是一句话：在需求不确定的项目上用瀑布，相当于用高精度地图去勘探未知地形，地图画得越精美，偏离现实越远时损失就越大。

2. 翻车类型二：硬件团队被“敏捷指标”逼疯

某智能硬件创业公司，CEO是互联网背景，要求硬件团队“每两周交付一个可演示的硬件版本”。

硬件团队硬着头皮上，第一个Sprint展示了PCB的3D渲染图，第二个Sprint展示了打样的裸板，第三个Sprint说“还在贴片，这周交不了”。到第六个Sprint，板子终于跑通了基本功能，但因为前期为了赶“迭代交付”压缩了DFM（面向制造的设计）评审时间，SMT良率只有72%，量产阶段问题爆发，项目延期三个月。

复盘的时候，硬件负责人说了一句很扎心的话：“我们不是不配合敏捷，我们是做不到两周交付一个实体。每一个实体都有固定的物理生产周期，这不是团队努力能压缩的。”

这个案例告诉我们：硬件的物理生产周期是刚性的，不对任何一个管理框架让步。强制在硬件上套敏捷的“迭代交付”概念，只会倒逼团队牺牲质量换取“可演示”，最终在量产阶段加倍偿还。

3. 做得好的团队有什么共性？

反过来，我观察到的那些在方法论选择上做得比较成熟的团队，有几个共性特征：

• 承认客观差异：团队内部达成共识，硬件和软件就是两种不同的“物种”，不强行统一流程，而是在关键接口处对齐。
• 管理层懂技术规律：CTO或VP级别的管理者，能够向老板解释清楚为什么硬件不能敏捷、为什么软件不宜瀑布，而不是被CEO的“全面敏捷”口号牵着走。
• 工具链支撑分层管理：使用像PingCode这样能够同时支持瀑布和敏捷混合模式的项目管理平台，硬件团队按里程碑管理，软件团队按Sprint迭代，双方共享需求池但保持独立节奏。
• 在HSI上投入充足资源：舍得在硬件-软件接口定义上花时间、安排资深架构师把关。HSI定义得越清晰，两个团队之间的互相等待和扯皮就越少。

七、决策框架：五步判断你的项目该选哪一种方法论

说了这么多，落到操作层面，项目经理怎么判断自己的项目适合瀑布还是敏捷？我总结了一个五步判断框架，过去带团队做项目管理的时候一直用这个框架，没有出过大的方法论选择失误。

1. 第一步：判断需求的可预知程度

问自己一个问题：“如果今天让我把全部需求写下来，一年后回头看，这个清单能覆盖真实需求的百分之多少？”

• 如果你能在脑海中完整地“运行”一遍产品使用场景，且这些场景相对固定（比如一个工业控制器、一个医疗检验设备、一个基站电源模块），那么瀑布可行。
• 如果你自己都无法说清用户到底会怎么用、功能优先级应该怎么排（比如一个社交媒体App、一个智能家居的用户端应用），那么敏捷更合适。

2. 第二步：判断修改的边际成本曲线

画一条曲线：横轴是“项目阶段进度”，纵轴是“修改一个功能需求需要的额外成本”。

• 如果这条曲线在项目中期就出现陡峭跳变（比如进入模具开发后修改结构），说明你的边际成本增长很快，需要瀑布来前置质量管控。
• 如果这条曲线一直很平缓，甚至趋于水平（比如一个容器化部署的微服务应用），说明你的边际成本很低，可以大胆用敏捷来多试错。

3. 第三步：判断“可交付单元”的粒度

敏捷要求每个迭代结束都能交付一个“可工作的增量”。问自己：你的产品能拆分出独立可用的增量吗？

• 软件可以：一个只有登录功能的App是“可工作”的，用户可以注册登录；下一次迭代加上首页信息流，又是可工作的。
• 硬件很难：只完成电源模块的一台无人机，它“飞不起来”，不构成可工作的增量。硬件的可工作增量往往要到系统集成阶段才能产出。

如果你能在早期就拆分出独立可用的“片断”，敏捷适用；否则，瀑布更务实。

4. 第四步：判断合规与监管约束强度

你的产品需要通过哪些外部认证？这些认证对“变更”的态度是什么？

• 医疗器械、航空航天、核电控制，这些领域的软件都需要通过严格的法规审核（如FDA的510(k)、DO-178C适航认证），每次变更都可能触发重新审核。这类软件适用瀑布或带有瀑布特征的高度结构化敏捷。
• 通用互联网产品，几乎不受外部强制性审核约束，敏捷可放心用。

5. 第五步：判断团队能力和组织文化匹配度

这个因素经常被忽视，但其实非常重要。敏捷对团队的自组织能力、沟通效率、技术工程化水平都有较高要求。如果一个团队长期习惯了“任务被拆好、文档给齐、照着做就行”的工作模式，突然切换到敏捷，大概率会出现“站会开了三个月、交付能力没半点提升”的局面。

同理，一个习惯了“快速试错、持续重构”的软件团队，突然被丢进一个要求“每一行代码都要追溯到需求文档”的瀑布项目里，也会非常痛苦。

方法论的落地效果，取决于团队能力和方法论的匹配度。选方法论时，除了看项目特征，也要诚实地评估团队现状。

八、特殊场景补充：这些软件项目也应该考虑瀑布

上文反复说“软件慎用瀑布”，为了避免误解，我必须补充几个例外场景。在这些场景下，软件项目不但可以用瀑布，而且应该用瀑布。

1. 生命攸关的嵌入式软件

心脏起搏器的固件、汽车制动控制器的软件、民航客机的飞控系统代码。这些软件的Bug可能导致人员伤亡。监管机构（FDA、EASA、NHTSA等）对这类软件有严格的开发流程要求，包括需求追溯矩阵、代码审查记录、测试覆盖率报告等。瀑布流程中的阶段门和文档体系，天然契合这些合规要求。

在这类项目上谈“拥抱变化”，是拿人命开玩笑。

2. 大规模、多分包商的系统集成项目

某省会城市的地铁信号系统，涉及十几家分包商，硬件、软件、通信、土建都有。各分包商的接口必须在招标阶段就明确下来，写入合同。这种情况下，需求是不可能“迭代演化”的，一演化，合同就变了，多方重新谈判的成本是天价。瀑布的“基线冻结-变更控制”机制，是管理多方接口复杂性最有效的手段。

3. 交付物包含“不可修改”介质的项目

比如游戏主机上的光盘游戏。光盘一旦压盘出货，就无法在线更新（或更新成本极高）。所以这类项目的开发流程高度瀑布化：Alpha版本、Beta版本、Gold Master版本，每个阶段都有严格的交付标准，一旦压盘，Bug就只能等到下一代产品修复。Switch、PlayStation平台的很多游戏依然沿用这种开发节奏。

九、如果你正在推进团队的方法论转型，我有三个具体建议

如果读完这篇文章，你觉得自己团队的当前方法论有问题、需要调整，以下三个建议来自我在实际推动转型过程中的经验。

1. 建议一：不要搞“一刀切”的全面转型

我见过最失败的管理指令就是：“从下个季度开始，全公司推行敏捷。”这种一刀切的命令，结果是软件团队做得不错，硬件团队苦不堪言，测试团队无所适从。

正确的做法是以项目为单位，按照本文第七部分的五步法逐一评估，然后允许多种方法论在公司内共存。用PingCode这类工具来看，就是不同项目可以选择不同的管理模板，有的项目用Scrum模板，有的用瀑布模板，有的用混合模板。

2. 建议二：先解决“假性瀑布”和“假性敏捷”，再谈方法论升级

如果你的团队当前是“假性瀑布”（评审走过场、文档不维护、变更不可控），我建议先把真正的瀑布做扎实，而不是跳到敏捷去。如果你的团队在“假性敏捷”（无计划、无DoD、无回顾），那就先从Scrum的基础纪律做起，固定时间盒、明确DoD、坚持回顾。

在虚假的基础上叠加新方法论，只会多一层混乱。

3. 建议三：选一个能和团队流程一起演进的工具

工具本身不解决问题，但不合适的工具会放大问题。如果你的团队需要同时管理硬件瀑布和软件敏捷，选择一个能够同时支持两种模式、且数据能在两种模式之间流通的平台至关重要。

在PingCode的实践中，我观察到那些用得好的团队有一个共同做法：用一个统一的Product Backlog管理所有需求（包括硬件需求和软件需求），但在执行层面，硬件需求分配到里程碑计划中管理，软件需求分配到Sprint Backlog中管理。统一的Backlog保证了全景视图，分层的执行机制保证了各自节奏。这种“和而不同”的配置思路，比简单选一个“纯敏捷工具”或“纯瀑布工具”要实用得多。

十、结语：方法论是手段，不是目的

写到最后，我想把这篇文章的底层逻辑再往上拉一个层次。

当我们在争论“瀑布好还是敏捷好”的时候，真正应该讨论的问题是：我的项目、我的团队、我的业务场景下，哪种流程能以最低的总成本、最快的速度、最可控的风险，把价值交付到用户手中。

硬件项目修改成本高、物理依赖强、验证周期刚性，所以瀑布。软件项目试错成本低、需求演化快、市场窗口短，所以敏捷。这不是价值观之争，这是成本收益分析。

当你的软件项目修改成本也极高时（飞控系统、心脏起搏器固件），瀑布同样有价值。当你的硬件预研环节试错成本也很低时（开发板原型、FPGA验证），敏捷同样有空间。

所以，我给你的最后建议是：

• 如果你正在管理一个硬件项目，不用因为“敏捷很火”而焦虑。踏踏实实做好需求评审、基线冻结、阶段门管控，在对的时间点把对的事情一次做对，这是硬件工程师对项目最大的负责。
• 如果你正在管理一个软件项目，不要用瀑布的“全套文档”麻痹自己。接受不确定性，构建快速验证能力，用两周一个迭代的节奏把产品推到用户面前，让真实反馈而不是精美的PRD来驱动产品演进。
• 如果你同时在管硬件和软件，学会“分而治之”。在HSI上花足功夫，然后让两个团队用各自的节奏奔跑，保持信息同步但不强求节拍一致。

我见过太多团队在方法论选择上犯了“跟风”的错误，付出了真金白银的代价。希望这篇文章能帮你少踩一些坑。如果你想继续深入讨论软硬一体项目的管理方法，或者想了解PingCode在混合项目管理中的具体实践，欢迎留言交流。