混合项目管理：敏捷与瀑布之间的中间地带

瀑布与敏捷之间的冷战正在解冻吗？ 从本质上讲，两种项目管理方法之间的区别在于可预测性与适应性。 瀑布力求可预测性：仅当所有预定功能都完成并完全实施时，才考虑完成项目。 敏捷力求适应性：交付最小可行产品（MVP）并以迭代方式发布新功能，以收集用户反馈，指导改进路径。

什么是敏捷-瀑布混合？

自从 20 多年前正式推出以来，敏捷一直在流行。 在整个软件开发过程中，这种做法已经蔓延到瀑布方法仍然占主导地位的领域。 混合方法将在更大的瀑布结构中使用敏捷的实验形式化。

“真正的混合是预测性和不确定性工作的结合，”波士顿地区 Toptal 项目经理、Scrum 大师、敏捷教练和讲师 Jim Stewart 说。 在混合模型中，瀑布技术用于项目中易于理解的预测部分，而敏捷技术用于迭代的、更不确定的部分。

通过这种方式，公司可以以敏捷方式创建软件，但在瀑布过程中推出。 一家金融公司可能会开发一种产品，其中包含需要审核的多个大型组件，因此在完成并获得批准之前无法发布。 同时，开发团队可以通过一系列冲刺迭代该较大功能的较小部分以及用户界面的其他方面。

在为您的项目设置正确的混合系统时，灵活性是关键。 “我不相信千篇一律的东西，”位于塞尔维亚贝尔格莱德的项目经理 Miroslav Anicin 说，他是 Toptal 项目管理筛选团队的一员，也是本博客的撰稿人。 “你不能去某个地方按照书本应用方法。 你需要确切地知道如何根据团队成熟度、公司文化、主题文化、项目类型、团队规模和产品规模等不同因素来定制这些方法。”

为什么要使用混合系统？

你可能会想：为什么不完全采用敏捷，因为它已被证明更具适应性、创新性和效率？ 相反，如果组织已经习惯了，为什么不继续在 Waterfall 工作呢？

有时，纯敏捷会遇到障碍，尤其是在高度监管的行业中，产品需要获得外部组织的批准，这些组织需要文档和严格的时间表。 Juan Vilmaux 是阿根廷科尔多瓦的项目经理，也是 Toptal 项目管理筛选团队的成员，他认为 Waterfall 在风险是主要驱动因素的项目中非常有用，例如在公司面临审计的领域。 （由于需要在这些行业的项目规划之前进行风险分析，因此改变分析中的某些内容需要一个新的计划。）“我在一家进行临床试验的公司工作，那里的审计很疯狂，”他说。 “因此，您必须通过 FDA 等外部机构定义的几个流程。 如果你从事敏捷工作，你会不断地调整你的范围或积压工作——重新调整优先级——这可能会干扰这些审计。”

位于比利时布鲁塞尔的 Toptal 项目经理 David Machiels 说，在需要隐私保护的工作中，你必须注意发布时间。 他带领一个混合团队在 Microsoft Azure Active Directory 中为欧洲银行集团开发身份管理平台。 它在一些开发步骤中使用了敏捷，但由于银行需要保护隐私数据并且不愿意将这些信息放在云中，他的团队在本地服务器上配置了系统。 “首先，你需要完成内部部署，”他说。 “您还需要完成云实施。 然后你可以开始做两者之间的连接。 你必须按照一定的顺序执行很多步骤。”

我们在本文中采访的大多数项目经理都曾为金融行业的客户从事混合项目，因为该行业固有地结合了严格的法规和保护数据的需求。 总部位于南非约翰内斯堡的 Toptal 项目经理 Grant Schuleman 曾在金融服务、银行和证券交易所工作。 他说，他交付了一个股票交易引擎和一个衍生品交易引擎，“其中有很多与主数据相关的集成和大量监管要求。”

需要遵守一系列既定步骤，这有助于采用瀑布方法，但您可以通过结合敏捷来改进该过程。 大型史诗可以分解成用户故事以实现更灵活的开发，但完成的史诗可以在更长的时间范围内发布。 “有时你有我所说的大爆炸交付，”舒尔曼说。 团队逐步部署到用户验收测试 (UAT) 环境，一旦在 UAT 中签署所有功能，您就可以将其作为一个大型部署发布到生产环境。 “这可能需要一年时间，具体取决于项目的规模，”他说。

在他最大的项目中，Schuleman 有 120 人从事 10 个项目——一些在 Waterfall 中工作，一些在 Scrum 中工作，还有一些在混合项目中工作。 他还每隔一周进行一次“Scrum of Scrums”，以确保所有较小的团队都为下一个系列的 sprint 保持一致并以互补的速度工作。

混合动力最难的部分

实施敏捷-瀑布混合系统可能是一项非常依赖于情境的工作。 作为此过程的指南，项目经理必须找到适合产品、团队和将要使用它们的人员的正确方法组合。 “如果你试图按原样应用其中一些方法，而不进行任何调整，”Anicin 说，“这将是 100% 的失败。”

Schuleman 试图将敏捷流程集成到遗留应用程序的更新中，但不得不在项目中间恢复为纯瀑布。 实验失败是因为它没有被开发者所接受，他们都习惯于在 Waterfall 中工作，并且不明白为什么将工作分解成史诗，然后进一步分解成用户故事。 Schuleman 说，他们会在 sprint 中看到一个用户故事，但不明白为什么“还有 10 个其他用户故事也与此应用程序相关，但尚未纳入范围。” 他们想同时处理所有事情。

那么混合动力系统成功的最重要因素是什么？ 人民。 有些人乐于改变，乐于尝试新事物； 有些不是。 当他们不是时，他们的抵抗通常归结为缺乏理解。 斯图尔特说，团队成员和管理层“不一定对项目管理有肤浅的理解”。 “他们一直在使用 Waterfall，他们知道这是一个敏捷流行语。” 由于他们不熟悉新流程，他们可能想做他们过去做过的事情。

混合动力并不适合所有人。 一些项目经理发现，桥接对立的方法导致的问题多于解决的问题。 “混合动力通常不是一个好方法，”Vilmaux 说。 “你正在增加失败的机会，因为你正处于两全其美的境地。 你限制了敏捷，但敏捷的本质是拥抱变化并保持灵活性。 如果您在一个以线性方式（固定和确定性）工作得最好的瀑布环境中工作，您就会开始失去所有这些，并且更改并非不可能，但代价可能非常高昂。 在添加敏捷之后，您开始在瀑布世界中推动非线性事物。”

也就是说，尽管它很复杂，但正确完成的混合肯定可以得到回报。 Anicin 最近为 IFC（世界银行集团成员）在波斯尼亚和黑塞哥维那的塞族共和国领导了一个成功的混合项目。 “作为一个 IFC 项目，”他说，“它完全是由计划驱动的，但我们同意我们将采用混合方法。 要求和规范——一切——都非常详细，但我们的团队在敏捷中工作。”

这一过程的受益者是斯普斯卡共和国政府，它在更短的时间内以更低的成本获得了更好的产品。 Anicin 说，“涉及许多组织——政府组织，完全不同的组织”。 “这很难，但它奏效了。”

使用混合作为敏捷升级

如今，随着每个行业都在经历数字化转型，越来越多的公司开始对敏捷感到好奇。 “人力资源正在变得有点敏捷，”斯图尔特说。 “另外，我知道荷兰有一个警察组织使用任务板来清理积压的犯罪案件。”

即使您正在与之合作的公司还没有准备好双脚投入，随着时间的推移逐渐引入敏捷可以带来红利。 一个主要原因是敏捷非常擅长处理不确定性。 “在我看来，当存在未知数时，敏捷性要好得多，”舒勒曼说，“而且 99% 的时间都存在未知数。”

另一个优势是敏捷固有的透明度。 “我更喜欢敏捷，因为我可以看到变化，”他说。 “有了瀑布，可能会有很多烟雾和镜子：‘我们完成了 20%’、‘我们完成了 30%’，但随后你又被困在 80% 上八个月。 隐藏问题要容易得多。 使用敏捷，您每天都有站立会议，如果用户故事在那里停留的时间超过了应有的时间，很容易说，'这件事没有动静； 有什么问题？'”

将敏捷融入任何系统都可以节省金钱和时间，同时提供更符合客户实际需求的价值。 当一个项目失败时，斯图尔特问这是不是因为它应该更敏捷。 “我打赌，每年有 35% 到 40% 的 IT 项目失败，”他说，“其中很大一部分属于瀑布式的项目应该是敏捷的——而这并没有发生。”

通过混合系统慢慢融入敏捷可以提供某些优势，尤其是当瀑布式思维方式的某些方面可以为您的团队带来好处时。 对于 Anicin 来说，一个好的混合系统的重点是“发现部分”。 当我们谈论混合方法时，我们提供了更详细的产品待办事项”——比他为纯粹的敏捷项目创建的内容要广泛得多。 在一个混合项目中，他使用这个更详细的待办事项，让他的团队对成品的长期期望有一个更详细的瀑布式视角。 然后，Anicin 将他的团队加入“产品，而不仅仅是项目”，他说。 “我希望整个团队都了解产品细节，因为他们需要拥有这种产品所有权，这非常重要。”

您的公司和您的团队可能还没有准备好采用纯敏捷，但至少，您可以从添加敏捷实践（如每日站会和更短、更频繁的交付期限）中获得可观的好处。 如果您在如何实现它时严谨、聪明且谨慎，那么混合系统可能正是您升级项目所需要的。