敏捷与瀑布融合管理工具的双模治理：稳态与敏态的边界与度量口径

同一套研发管理体系里，敏捷和瀑布往往同时存在：核心系统按年度做里程碑评审，创新业务每两周交付一个版本。很多团队把难点归结为工具能否同时支持两种模型，但真正决定成败的是另外两件事——稳态与敏态的边界划在哪里，以及两套节奏用什么口径来衡量进度。这也是敏捷与瀑布融合管理工具之外，更值得先想清楚的双模治理问题。

可以把双模治理理解为一种治理方式：在同一组织内让稳态与敏态两套交付逻辑各自成立，又能在关键节点对齐。它要回答的不是选敏捷还是选瀑布，而是哪些工作该走哪条路、两条路上的进度如何换算成可比较的结果。

一、双模治理：稳态与敏态从何而来

1. 从双模IT到双模治理

稳态与敏态并非国内原创的说法。咨询机构Gartner提出的双模IT（Bimodal IT）概念，把企业IT分成两种模式：模式1面向可预测、边界清晰的领域，强调稳定与可靠；模式2面向不确定、需要探索的领域，强调尝试与快速调整。这一划分后来被广泛沿用。

监管层面也有对应表述。银保监会2022年1月发布的《关于银行业保险业数字化转型的指导意见》（银保监发〔2022〕2号）提出，要建立能够快速响应需求、适应稳态与敏态的全周期线上交付管理流程。这意味着双模并非少数技术团队的自选动作，而是被写进数字化转型要求的一种交付组织方式。

落到工具与流程上，就形成了双模治理：稳态承接规范管控，敏态承载灵活迭代，两者并非各自独立运行，而是在需求、发布、质量几处必须对上。

2. 稳态与敏态不是快与慢的区别

一个常见误解是把稳态等同于慢、敏态等同于快。更准确地说，两者的差别在于所面对的不确定性程度，速度只是结果之一。可以从几个维度拆开看。

下表把两套模式在关键维度上的差异并列展示，用来判断一项工作更接近哪一态。

对照可见，稳态要的是可预期的过程，敏态要的是可调整的过程，两者并不存在优劣之分。把两套逻辑放进同一套体系时，先划边界，再谈工具。

二、边界怎么划：把工作分派到正确的模式

1. 三条初判依据

边界不宜按团队或部门来切，而应按工作项本身的性质来切。可以综合三条依据做判断，其中合规约束通常起决定性作用。

第一是变更频率，看需求是否在开发过程中高频调整。第二是合规约束，看交付物是否受外部标准、审计或阶段门控约束。第三是可预测性，看范围与验收标准在启动时是否已经清晰。

三条综合下来，如果工作项明显偏向某一态，就先归到那一态，再考虑混合处理。

2. 边界之外，还要有衔接

划完边界，容易出现另一个问题：两条路径各自推进，需求在中间失去衔接。真正需要共享的是三类对象，即统一的需求池、统一的发布记录、统一的质量门禁。

稳态的基线变更与敏态的迭代需求都从同一个需求池进出，版本发布走同一套记录，质量门禁用同一组标准。做到这一步，两套模式才算在一个体系里运行，而不是两套并行的小系统。

三、度量口径：两套模式各看什么、共看什么

这一部分是双模治理中容易出问题的环节。用稳态的指标考核敏态，或用敏态的口径评价稳态，往往难以反映真实情况。

1. 分层看指标，而不是维护两套指标

把指标按结果层、流动层、质量层分层，再分别映射到稳态与敏态，是相对稳妥的做法。结果层回答交付是否达成，流动层回答过程是否顺畅，质量层回答交付是否可靠。同一层内，两态只改变关注点，不改变指标类别。

下表把三个层面在两态下的常用口径并列展示，便于对照选择。

从对照可以看出，两态在每一层都有对应口径，差别只在关注点，而不是有没有指标可用。表中逃逸Bug比例指上线后才被发现的Bug占全部Bug的比例。这也是避免用一套口径硬套两种模式的前提。

2. 稳态：衡量偏离，而不是速度

稳态的度量围绕基线与阶段展开，关注的指标共同指向一个问题，即计划之外的偏离有多少，而不是做得多快。用它去考核探索型工作，容易让团队倾向于制定保守的计划。

3. 敏态：衡量流动，而不是阶段完成度

敏态更关心需求从进入到交付的流动情况。这里用到的两个口径需要先说明：流动效率指需求在流程中被有效处理的时间占总时长的比例；在制品数量指同一时间处于处理中、尚未完成的需求数量。这些指标衡量的是价值流动，而非阶段里程碑。把它们直接套在强合规的阶段交付上，容易让评审节点被视为阻碍，从而弱化管控。

4. 双模共用的基线

两态各自的口径之外，还需要一组共用基线，让两条路的结果能放在一起看。可共用的包括需求前置时间，即从提出到上线的总时长；交付质量，即上线后的返工与故障情况；以及按需求数或故事点衡量的有效产出。共用基线的价值在于换算，它让稳态的里程碑与敏态的迭代可以用同一套口径对齐。

四、工具如何承载双模治理

要让边界与口径真正运转，工具需要同时具备几项能力。以敏捷与瀑布融合管理工具为例，判断它能否承载双模治理，关键看三点：是否在同一个需求池与发布记录下支持多种管理模型，是否能把稳态的计划数据与敏态的过程数据汇入同一套报表，是否让质量门禁对两种模式使用同一组标准。

禅道等研发管理工具的做法是，在一个平台内融合业内九大主流项目管理模型框架和方法，包括Scrum、看板、瀑布、融合敏捷、融合瀑布、IPD、SAFe、CMMI与DevOps，并提供稳态和敏态双模管理。

这类设计的价值不在模型数量，而在于需求、任务、Bug、测试用例与发布记录共用一套对象，两态的数据可以在同一口径下横向比较，也可以从禅道各版本功能对比看到不同模型在同一平台内的承载方式。

需要注意的是，模型再多，也要先划清边界、定好口径，否则工具只是把两套割裂的流程搬进同一个界面。

五、常见问题

1. 稳态团队与敏态团队的考核会不会互相不服气

有可能，问题通常出在互比速度。两态应各自考核偏离与流动，再用共用基线做横向对齐，而不是让稳态团队和敏态团队比谁的交付更快。

2. 需求在两态之间迁移，历史数据如何衔接

关键是保留同一个需求编号与完整的阶段记录。迁移时冻结原模式下的基线，再按新模式的节奏重设目标，做到数据不断点、口径可追溯，避免历史数据在两侧各存一份。

3. 双模治理需不需要单独设一个统一负责人

不一定设专职岗位，但需要一个能同时读懂两态口径的角色，负责边界裁定与指标维护。重点不是有没有敏捷与瀑布融合管理工具，而是有人能同时看懂两态的数据并做出判断。