项目要过阶段评审，团队在阶段内部按迭代推进研发，这已是不少规模化研发团队的常态。麻烦往往集中在评审前一周：文档开始集中补齐，需求、设计、测试记录散在不同人的电脑里，评审会容易变成材料验收会。
更准确地说，敏捷与瀑布融合管理工具要解决的不是两套流程如何摆放，而是让阶段评审有据可依，让瀑布文档要求随交付自然满足。
一、融合管理融合的是什么
1. 定义与边界
敏捷与瀑布融合管理，指在同一个项目或同一组织内，用瀑布的阶段划分、里程碑与交付基线控制整体方向，用敏捷的短迭代完成阶段内部的研发工作，两套节奏运行在同一份项目数据上。
判断它是否成立，不看流程图画了几层，而看边界是否清楚：范围、里程碑时间、合规基线由阶段层锁定，功能细节、优先级与实现顺序由迭代层调整。 边界模糊时，阶段层频繁改范围，迭代层就无法对交付作出承诺；迭代层随意扩大范围，阶段基线也随之失去意义。
2. 两类常见取向
按主体不同，混合模式通常分成两类。融合瀑布以瀑布为骨架，阶段内部用迭代推进，适合交付节点固定、需要对外承诺或接受审计的项目；融合敏捷以迭代为主线，用阶段门或里程碑约束关键出口，适合需求变化快但仍有合规要求的产品。两类取向都保留阶段评审，差别在评审的严格程度与放行口径。
二、阶段评审在混合模式下怎么跑
1. 两类评审同时存在
混合模式里的评审通常不是一套，而是两套并行：阶段门评审看交付物与基线，迭代评审看增量与反馈。
下表用于区分两类评审在对象、节奏与产出上的分工。
| 对比项 | 阶段门评审 | 迭代评审 |
|---|---|---|
| 评审对象 | 阶段交付物与里程碑成果 | 迭代增量与待办调整 |
| 发生节奏 | 阶段出口，次数少 | 迭代末尾，频次高 |
| 参与角色 | 项目管理办公室、项目负责人、质量与合规角色 | 产品、研发、测试 |
| 关键产出 | 放行结论、基线、阶段文档 | 可用增量、待办列表 |
| 未通过时 | 返工后重新提交评审 | 调整待办，下个迭代继续 |
两份记录不是各记各的，迭代评审的结论应当成为阶段门评审的输入。
2. 让两种评审不打架的三条规则
评审对象分开：迭代评审不审文档全集，阶段门评审不追迭代内的实现细节，两边的材料清单各自独立。
节奏绑定：阶段出口需要的文档与证据，在阶段启动时就拆成迭代任务，随迭代产出。
放行条件前置：阶段门的进入条件、退出条件与例外处理，在阶段启动时确定下来，不在评审当天临时商量。
3. 两类常见失败方式
把阶段门评审做成汇报会是常见的一种：材料由各角色口头陈述，意见只留在会后的沟通记录里，没有人核对交付物与基线。另一种是迭代评审的数据不落系统，阶段评审前靠回忆补录，文档齐不齐、准不准，无从判断。
三、瀑布的文档要求具体是什么
1. 文档分类与标准依据
软件文档通常按用途归为三类，这是理解文档全貌的基础：开发文档描述开发过程本身，如需求规格说明、设计说明；产品文档面向使用与运维，如用户手册、操作手册；管理文档记录项目管理信息，如开发计划、测试计划、配置管理计划。
需要说明的是，三类划分是行业协作中形成的归类习惯；下面提到的国家标准，则是逐份规定文档的内容要素与编写要求，两者不是一套东西。GB/T 8567-2006《计算机软件文档编制规范》由国家质量监督检验检疫总局与国家标准化管理委员会于2006年3月14日发布、2006年7月1日实施，代替1988年的同名指南，逐份规定了软件各阶段应编制的文档种类、内容要素与编写要求。
企业实际执行时，除了国家标准，还会叠加CMMI这类过程成熟度体系、ASPICE这类汽车软件过程改进模型，以及等保等安全合规要求，文档条目会更细。
2. 文档过关的五个条件
阶段评审卡住团队，通常不是卡在有没有文档，而是卡在文档是否可用。下表列出五项判断条件与对应的常见失分点。
| 判断条件 | 具体要求 | 常见失分点 |
|---|---|---|
| 齐 | 阶段出口要求的文档一份不少 | 遗漏过程性文档 |
| 准 | 内容与真实交付一致 | 评审前集中补写 |
| 版本清 | 有编号、版本号与修订记录 | 多个副本并存 |
| 可追溯 | 与需求、任务、用例、Bug关联 | 关联只停在标题 |
| 可评审 | 有评审记录、结论与责任人 | 结论散落在会议纪要 |
从实际执行情况看，五条里准和可追溯最难做到。 内容与实际交付不一致，评审就缺少判断基础；关联断裂，变更发生时无法评估影响范围。这也是混合模式下补文档格外吃力的原因：迭代推进快，交付物分散，靠人工汇总很难同时做到这两条。
四、管理工具在这两件事上承担什么
1. 让文档成为链路中的对象
结构化工具与文件共享盘的差别在于：文档不再是附件，而是链路里的一个节点——需求规格说明挂在对应需求下，测试报告关联到具体测试单与Bug，评审时按链路调取，不依赖谁的电脑里存了哪一版。
2. 让评审本身在系统里发生
阶段评审能不能落地，取决于评审是不是系统里的一个正式动作。评审流程、评审参与者、评审意见与结论都应当在系统中留痕：发起人提交评审后，评审人按节点给出意见，结论与责任人记录在案；未通过的事项直接转为任务或变更回到团队，通过后阶段状态才允许放行。禅道的评审流程与工作流支持按角色配置审批节点，评审记录与交付物关联存放，阶段评审时不必临时收集材料。
3. 基线与变更
阶段评审的效力，很大程度上来自基线。对已基线化的项目计划、需求、设计、文档的修改，应当走变更申请、变更评审、变更追溯的流程，并回答四个问题：谁发起的、改了什么、影响多大、谁批准的。
以禅道为例，项目变更功能针对已基线化的交付物，提供变更申请与变更评审；变更与原始基线形成关联，可追溯每次变更对进度与成本的影响，同时为紧急修复保留快速通道。该功能适用于瀑布、融合瀑布、IPD这类集成产品开发流程，变更过程自带完整审计链条，适合需要按CMMI、ASPICE这类过程体系接受审计的项目。
4. 双节奏数据的统一
阶段评审要引用迭代的真实进展，就不能存在两套口径。在同一数据源里，迭代的燃尽与任务完成情况汇总到阶段进度，里程碑状态随迭代推进更新，评审讨论的是数据本身，而不是各角色对数据的解释。这类系统通常需要把迭代数据与里程碑数据放在同一份数据源，并提供甘特图、燃尽图与基线对比等视图，减少阶段与迭代之间的口径差异。
5. 五项要求对应哪些工具能力
下表把文档要求的五条逐项落到工具能力上，便于核对。
| 文档要求 | 工具需要具备的能力 | 检查方式 |
|---|---|---|
| 齐 | 文档按阶段归集，缺失可见 | 阶段出口能否列出清单 |
| 准 | 文档与需求、任务、用例同源 | 能否从文档点到交付物 |
| 版本清 | 版本号与修订记录自动留存 | 能否查看历史版本与修改人 |
| 可追溯 | 变更与基线双向关联 | 能否还原变更的完整链路 |
| 可评审 | 评审流程与结论在线留痕 | 能否导出评审记录供审计 |
五项同时满足时，阶段评审才可能从材料验收回到判断本身。
五、落地顺序与断点信号
1. 建议的三步
第一步，先定清单。 把阶段出口要求的文档与证据逐项列出，标注责任角色与产出时点，再拆进迭代任务的验收标准：需求规格说明随需求澄清任务产出，测试计划与用例随测试设计任务产出，测试报告随最后一轮回归产出，阶段末只做整册确认，不做补写。
第二步，再配流程。 配置阶段门评审与迭代评审两组流程，明确发起权限、评审参与者与例外处理方式。
第三步，单项目试点。 跑通从需求到任务、文档、测试、变更、评审的完整链路，再向其他项目推广。
2. 出现这些信号，说明链路断了
- 评审通过后没有留下放行记录，下一阶段的工作已经开始；
- 文档在系统外流转，本地磁盘、群聊、邮件各存一份；
- 变更只有结果，没有申请与评审记录；
- 迭代数据与里程碑数据口径不一致，开会前要先对数据。
判断一套敏捷与瀑布融合管理方案是否够用，有一个简便的方法：随机挑一个已完成的需求，看能否说清它从提出到验收经过了哪些评审、产生了哪些文档、变更过几次。
六、常见问题
1. 阶段评审的放行结论由谁拍板？
由项目在阶段启动时约定的决策角色拍板，通常是项目负责人或阶段负责人，质量与项目管理办公室角色提供意见但不替代决策。涉及范围、预算的放行，需要按授权层级上移到项目集或管理层。
2. 项目中途需求大范围调整，已经通过的阶段评审还算数吗？
已通过部分的基线继续有效，不必重审。超出阶段基线范围的调整要走变更流程，评估对进度、成本与交付物的影响后，在新的阶段评审中重新确认。
3. 外包或第三方交付的部分，怎么纳入阶段评审？
把外部交付物写进阶段出口清单，按同一套标准检查齐备性与版本。合同里程碑、验收记录与内部评审结论在同一个项目视图里关联，避免形成两套进度口径。
4. 阶段门评审和迭代评审的会，能合并成一次吗？
不建议合并，两者评审对象和参与者不同，合并容易让阶段门失去独立性。可行的做法是在阶段出口那次评审里，把各迭代的结论作为输入一并呈现。
