瀑布 和 敏捷 经常被描绘成对手:守旧 项目管理 方法论与敏捷的新来者竞争. 从本质上讲，它们之间的区别在于可预测性和适应性. 瀑布法通过在一开始就预先确定功能，并认为只有在这些功能完全实现后项目才会完成，从而争取可预测的结果. 敏捷承诺了适应性，交付了一个 最小可行产品 (MVP)，然后迭代地发布新功能并收集用户反馈来指导改进的路径.

尽管有对立的叙述, 瀑布式和敏捷通常在组织中同时存在. 2021年， 项目管理学会 报告说，信息技术和金融行业是敏捷的主要采用者. 即便如此, 瀑布依旧盛行, 在这两个行业中，几乎有四分之一的项目采用了混合方法, PMI调查显示.

自2001年由软件开发人员正式引入以来, 敏捷越来越受欢迎, 甚至悄悄进入了瀑布方法仍然占主导地位的建筑和能源等行业. A 混合方法 以提高效率为目标，将两种不同的管理框架或系统的各个方面结合起来. 在本文中, 在不同行业中从事过敏捷-瀑布混合项目的项目管理专家反思了混合项目管理的挑战和好处.

什么是敏捷-瀑布的混合体?

“真正的混合是预测和不确定工作的结合，”他说 吉姆•斯图尔特他是波士顿地区的Toptal项目经理， Scrum master, 敏捷教练，顾问. 在混合模型中, 瀑布式的整体结构为大家提供了很好的理解, 项目的预测方面, 和敏捷技术用于迭代, 更多不确定的部分.

以这种方式, 一个公司可以用敏捷的方式创建软件，但在推出过程中遵循瀑布的方法. 一家金融公司可能会开发一种产品，其主要功能在发布前必须经过审核和批准. 仍然, 这些特性的较小部分可以由开发团队通过一系列的sprint进行迭代, 用户界面的其他方面也是如此.

当决定如何在瀑布环境中实现敏捷时，灵活性是关键. “我不相信一刀切，”他说 Miroslav Anicin他是塞尔维亚贝尔格莱德的一名项目经理. “你不能照本宣本地应用方法论. 您需要确切地知道如何根据团队成熟度等不同因素来调整这些方法, 公司文化，主题文化，项目类型，等等 团队规模，以及产品的大小.”

为什么使用混合动力系统?

敏捷已被证明比传统方法更具适应性和效率. 大型跨国公司的高管们普遍同意这一点 敏捷是必要的 实现战略目标. 所以你可能会想:为什么组织要继续使用瀑布?

风险管理 是阻碍组织走向纯敏捷的常见障碍，尤其是在高度敏捷领域 监管的行业 在这种情况下，项目需要外部组织的批准，需要文件和严格的时间表. 因为 风险分析 必须在这些行业的项目规划之前发生吗, 不断变化的分析要素将需要新一轮的规划. “我曾在一家经营临床试验的公司工作，(这个领域的)审计非常疯狂，”他说 胡安Vilmaux他是阿根廷Córdoba的一名项目经理. “你必须经历几个由FDA等外部机构定义的过程. 如果你在敏捷中工作, 您不断调整您的范围或待办事项(重新确定优先级)，这可能会干扰这些审计.”

欧博体育app下载 大卫Machiels, 总部设在布鲁塞尔, 比利时, 请注意，要求隐私保护的项目需要谨慎地定时发布. 他领导了一个混合团队开发身份管理平台 Microsoft Azure Active Directory 一家欧洲银行集团. 他的团队在一些开发步骤中使用了敏捷, 但因为银行出于对数据隐私的担忧，不愿意将信息放到云端, 他们在本地服务器上配置了系统. 然后，团队遵循了一个清晰的瀑布式操作顺序. “首先，你需要完成内部部署，”他说. “你还需要完成云实现. 然后你可以开始做两者之间的联系.”

当敏捷被混合到瀑布环境中时，大型项目可以被分解成史诗和史诗 用户故事 更灵活的开发. 然后，完成的功能可以在更长的时间框架内发布. 他说:“有时你会遇到我所说的‘大爆炸’快递。 格兰特Schuleman, Toptal在约翰内斯堡的项目经理, 南非, 谁在金融服务业工作过, 银行, 股票交易所. 他描述了团队如何增量地部署到 用户验收测试 (UAT)环境. 一旦在UAT中签署了所有特性，产品就会在一个大型部署中发布. 他说:“这可能需要一年的时间，具体取决于项目的规模。.

在他最大的项目上, Schuleman有120个人在10个项目中工作，其中一些人在瀑布工作, 有些在Scrum中, 还有一些混合的. 他还经营了一家 Scrum of Scrum 每隔一周，以确保较小的团队为下一系列的冲刺和互补的速度工作. 不同方法的编排引入了灵活性，同时仍然适应组织的需求，这阻碍了他们走向完全敏捷.

混合动力车最难的部分

敏捷-瀑布混合模式的成功取决于项目经理如何定制给定情况下的过程. 项目经理必须为产品找到正确的方法组合, 团队, 最终用户——然而杂交很少遵循预设的公式.

通常，决定敏捷能否成功地融入现有瀑布系统的最重要因素是团队成员和其他涉众的认可程度. 一个团队必须对变化持开放态度，并乐于尝试新事物. 如果团队成员不熟悉新的流程, 或者只把敏捷当作一个流行词, 他们可能看不到改变的理由. 渴望将瀑布和敏捷结合起来的项目经理必须这样做 促进理解 并鼓励团队和组织考虑产生最佳结果的方法.

当Schuleman试图将敏捷过程集成到遗留应用程序的更新中时, 例如, 他发现这个实验并没有被开发者所接受, 他们已经习惯了在瀑布中工作，并且不理解为什么工作被分成史诗和用户故事. 团队成员想要同时处理所有的事情. 基于这种阻力和其他因素, 他意识到混合方法并不合适, 中途敏捷地改变航线, 指导团队使用纯瀑布完成项目.

Vilmaux在项目上也有类似的经历, 尤其是那些考虑到风险管理的公司. 有时候，混合会增加你失败的几率，“因为你得到了两个世界中最糟糕的部分。. 你限制了敏捷，但敏捷的本质是拥抱变化和灵活. 在瀑布式环境中，你开始失去所有这些, 哪一种在线性模式下(固定和确定)效果最好?在这种模式下，改变并非不可能，但代价可能非常高昂. 在加入敏捷的过程中，你开始在瀑布世界中推进非线性的东西.”

在Schuleman和Vilmaux的经历中, 希望遵循混合软件开发方法的项目经理需要这样做 教练。 他们的团队通过新的概念. 然而，他们也必须愿意承认这种杂交 不是 适当地工作和适应.

考虑到这些因素，即使在规避风险的环境中，混合动力车也能取得成功. Anicin最近为国际金融公司(世界银行集团的一个成员)在波斯尼亚和黑塞哥维那领导了一个成功的混合项目. 计划驱动的项目非常详细 需求 和规范，并涉及许多组织和政府利益相关者. 然而，团队从一开始就在敏捷中工作, 客户最终以更快的时间以更低的成本获得了更好的产品. Anicin说:“这很难，但它成功了.”

使用敏捷混合作为升级

随着行业的不断发展 数字转换越来越多的公司开始对敏捷感到好奇. 即使一家公司还没有准备好投入其中, 随着时间的推移，逐步引入敏捷可以带来回报. 一个主要原因是敏捷适应不确定性，这是任何项目的特征.

敏捷还提供了透明性. “我更喜欢敏捷，因为我可以看到变化，”Schuleman说. “瀑布, 可能会有很多障眼法:‘我们只完成了20%,“我们完成了30%。,’但接下来的8个月里，你还得支付80%的费用. 隐藏问题要容易得多. 和敏捷, 你每天都要开会, 如果一个用户故事被搁置了很长时间, 说起来容易, ‘This thing’s not moving; what’s the problem?’”

将敏捷慢慢地结合到瀑布中可以提供优势, 特别是当瀑布式思维方式的某些方面目前适用于团队时. 例如，瀑布法在发现和计划阶段就能发挥出色. “当我们谈论混合方法时, 我们正在提供更详细的产品待办事项列表,Anicin说. 在一个混合项目中, 他使用这些待办事项为他的团队提供更详细的, 瀑布式的对成品长期期望的看法. 然后，他将自己的团队“融入到产品中，而不仅仅是项目中，”他说. “我希望整个团队都能了解产品细节，因为他们需要这些 产品的所有权这是非常重要的.”

公司和团队可能还没有准备好采用纯敏捷, 但至少, 项目经理可以从增加敏捷实践和缩短敏捷实践中获得可观的收益, 更频繁的交付期限. 如果一个项目经理是严格的, 聪明的, 要注意执行, 敏捷-瀑布混合方法可能正是组织升级项目所需要的.

本文最近进行了全面的更新和重写，以纳入最新和最准确的信息. 我们要感谢格雷格·奥布莱恩对原文的贡献. 请注意:下面的评论可能早于此更新.