Water-Scrum-Fall 怎么用于软件开发？适用场景和常见说法
很多团队听说过 Water-Scrum-Fall，但不太清楚它具体描述的是哪种开发方式，以及它和纯 Scrum、纯瀑布有什么区别。
Water-Scrum-Fall 是一种混合式交付模式
Water-Scrum-Fall 指的是在一个项目中，前期需求、规划和立项更偏瀑布式，中间开发阶段采用 Scrum 或敏捷迭代，而发布、上线、审批和运维又回到偏瀑布的流程。它并不是一种标准方法论名称，更像是对现实中“混合流程”的描述。很多企业会在组织层面保留传统管控方式，同时在研发层面引入敏捷实践，因此形成这种组合式模式。
不是所有项目都会采用这种方式，哪些类型的团队或业务更容易落入这种混合流程？
强管控、重协作、流程复杂的项目更常见
Water-Scrum-Fall 常见于大型企业、金融、政企、医疗、制造等场景，这些环境往往对需求审批、合规检查、测试验收和上线发布有较强要求。业务部门可能希望快速迭代，研发团队也在使用 Scrum，而组织层面的预算、审计、发布窗口、变更管理仍然维持较强的阶段性控制。在这种情况下，就容易形成前后偏瀑布、中间偏敏捷的混合结构。
很多团队会想知道，这种模式是折中方案，还是会给项目带来额外成本与风险？
它既能兼顾控制，也可能放大流程摩擦
Water-Scrum-Fall 的优势在于，它能让团队在既有组织制度下引入迭代开发，减少一次性大交付的压力，也便于管理层进行阶段性审批和风险控制。问题在于，不同阶段如果目标不一致，就容易出现需求传递失真、节奏断裂、等待时间长、上线周期慢等情况。团队在迭代中积累的成果，可能因为后段审批和发布流程过重而难以及时释放价值。
在讨论这种模式时，大家通常会用哪些表达来描述它，方便在会议或文档中沟通？
常见说法多围绕“前瀑布、中敏捷、后瀑布”
常见说法包括“前期瀑布、开发敏捷、交付瀑布”“需求和审批走传统流程，研发用 Scrum”“敏捷只存在于开发阶段”“披着敏捷外衣的瀑布流程”等。也有人把它称为“伪敏捷”或“混合敏捷”，不过这些说法带有一定评价色彩。实际沟通时，更建议直接说明流程在哪些环节是阶段式管理，哪些环节是迭代式协作，这样更容易让业务、研发和测试达成共识。