如何化解敏捷与瀑布的二元冲突？

不久前，一个项目管理交流群里的朋友在群里提了一个问题，他问：在项目需求明确的情况下，该用瀑布还是用敏捷？你觉得这是一个小问题吗？但让我没想到的是，这个问题在交流群里却激起了惊涛骇浪，没过几分钟，明显看出这个人数不多的群就分成了势不两立、水火不容的两派，你应该猜得到，一边是瀑布，一边是敏捷，甚至有人提出没有敏捷就活不下去的论断。好吧，今天我们就来谈谈这样一个话题，并看看组织级项目交付框架Praxis是怎样看待这样一个问题的。

在上一篇文章中我们谈到，作为组织级、集成式框架的Praxis使用一个独特的方式来看待项目、项目群和项目组合。Praxis认为，三选一不是一个好的做法，我们没有办法界定一个复杂的项目和一个不复杂的项目群的界限，并因此引入了“范围复杂度”这样的一个概念。更多内容可以参考上一篇文章《项目管理的三分世界与不连续性思维》。为了解决这个问题，在Praxis框架中首先提供了功能或流程在一般情况下的处理方式，然后使用一个单独的部分来阐述在“范围复杂度”逐渐增加的情况下，需要如何应用这个方法。

同样的，将项目管理分为敏捷与瀑布的二元世界就合适了吗？在预测型方法（比如瀑布）作为标准方法的年代，一群勇于创新的人在IT开发中勇敢地尝试自适应的开发方法，并将这种方法称为“敏捷”，我们不得不说这是一个伟大的创举，但是很不幸的是，越来越多的人似乎将敏捷作为宗教一样来崇拜，他们认为敏捷无所不能，但我想说的是，对于一个真正的专业人士来讲，不应该有敏捷与瀑布之争。

正如我们在前文用“范围复杂度”这样一个概念来解决项目、项目群和项目组合这个三元冲突一样，那么有没有一种方式能够解决瀑布与敏捷这个二元冲突呢？为了回答这个问题，我们需要在项目、项目群和项目组合这个连续的频谱上添加另一个维度，我称之为“范围不确定性”。这同样是一个连续体，在敏捷与瀑布之间还有很多“不那么敏捷和不那么瀑布”的范围，因此我想，可以将“范围不确定性“作为敏捷的衡量单位，”范围不确定性“越大，意味着我们越需要敏捷。至此我们为项目管理构建了一个包含”范围复杂度“和”范围不确定性“的二维模型。

为了进一步说明瀑布和敏捷这两个术语过于二元化，无法真实地表示适用于项目、项目群和项目组合范围的不确定性。我们在上面这个二维模型之上添加一些举措的样例，如下图所示，根据鸽子洞原理，肯定有一些举措会涵盖瀑布与敏捷这两个范围上的每个点。因此，我们说敏捷与瀑布的二元划分过于狭隘，我们需要提供一个更加全方位的视角。

那么，当前主流的项目管理知识体系指南或最佳实践在这个二维模型上该如何分布呢？我们不妨用下图来展示。

最后让我们回归到Praxis，作为组织级项目交付框架，Praxis的目标是确保涵盖该模型的整个范围，而不是受限于某个局部。基于上述原则，Praxis针对其框架的相应组成部分，使用单独的篇幅来说明如何根据相关的场景将敏捷性应用于其中。

总之，Praxis通过这样一个二维模型突破了项目管理世界三元和二元划分的束缚，我们不必纠结于三选一或者二选一，我们更应该关注的是项目范围有那么复杂和多么的不确定。