敏捷与传统：项目管理的加减法

always_fly

很多从事敏捷的项目经理心中可能都有个问号：“《项目管理知识体系指南》在敏捷中中到底扮演什么角色？”
《项目管理知识体系指南》(以下称《PMBOK ®指南》)是被广泛认可的、关于项目管理的方法和实践的知识来
源。其最新版本严谨地地说明了该如何使用该指南，原文如下：

“《PMBOK ®指南》提供了管理项目的指导。它定义了项目管理及相关的概念，描述了项目管理生命周期及相
关的流程……作为一个基础的参考，《PMBOK ®指南》既不是完整的，也不是包罗万象的。该标准更多的是指
导性的而不是具体的方法。每个人都可以用不同的方法和工具来应用这个框架。”

《PMBOK®指南》介绍的大多数方法都是通用的，适用于所有项目（敏捷或者传统的），但《PMBOK®指南》
毕竟还是来源于传统的计划驱动的开发模式，而且一般来说，人们也是在这个语境下理解它的。如果要将其应
用在敏捷项目中，可能需要更多的解释。

关于敏捷的原理与《PMBOK®指南》中的方法和流程有何关联性。现实中，人们采用互相鄙视、非此即彼割裂
地方式来看待二者。这些看法使得对敏捷与PMBOK地误解雪上加霜。

例如对于《PMBOK®指南》的误解：

1)过多的文档工作。

2)一堆检查表格。

3) 繁重的流程。

4) 你被流程管理而不是你管理流程。

同时，与之恰恰相反的人们对于敏捷的误解：

1) 完全抛弃流程。

2)无序的，失控的。

3)不适用于复杂项目。

4) 不专业

这些大部分都是误解。然而在这些误解背后，也存在一定的真实性。形成这些误解的原因有以下几个。




1.失败的实施与错误的方法：仗打不好怪兵书不好

我们必须区分将PMBOK®背后的原理及方法同它们在现实中的具体实施区分开。有时候，由于某些具体实施不
成功，导致人们认为方法本身是错误的。在很多情况下，问题发生在实施上而不是方法本身。不管是传统方
法还是敏捷方法都有此类情况，由于实施不成功而被冠以恶名。

在有些时候，传统方法由于过多的文档工作、繁重的体系控制，而不能灵活地根据业务环境选择适当的文档
工作水平和控制度而被人诟病。其实在传统方法中并没限制通过适当的方法来减少文档量及控制度。

而敏捷方法被人指责的原因则是另一个极端，因为有时候人们会过快地进入项目执行阶段而只做了很少的甚
至一点都没做项目前期计划。同样地，在敏捷方法中也没限制人们自己决定做多少前期计划是合理的。

上述两种情况，问题都发生在具体的实施上而不是方法本身，然而有时候人们将其归咎于方法。PMBOK®中
的原理同传统方法有很强的关联，在很多时候，这些原理的具体实施并不尽如人意。

2.指导性方法与规定性方法：无套路V.S.有套路

敏捷原理和PMBOK®基于两种完全不同的理念。敏捷方法一般来说只提供非常简单的、价值导向的原理，
而不做出具体规定，留了很大的空间给具体实施人员来决定在特定的环境下如何应用。它希望实施人员在
其上根据实际情况增加新的内容。整个方法体系的设计都是非常灵活及自适应的。

“敏捷项目管理中重要的一点就是，方法都是指导性的而非规定性的。规定性的方法试图规定团队应做的每
件事情。这种方式使人迷失其中。人们要从一堆方法中进行选择而又缺少指导，这导致想要为某个具体项目
剔除无关的方法困难重重。

一组指导性的方法是一个系统的最小集合。它不规定项目团队要做的事情，但是它定义了那些有价值的、基本
适用于所有项目的方法。

从一组最小的方法集开始，然后审慎地根据需要用“加法”增加其他的方法，同从全面的方法集出发之后用“减法
”将其减少到一组适用的方法相比，被证明是更加有效的。敏捷不会用几千页的文档来规定开发上需要的每件
事情……“

相反地，很多传统的以计划驱动的方法采用“减法”。PMBOK®就是一个例子，你需要将其裁剪，只使用你的特
定项目中需要的内容。它的问题在于过度规定做什么，而敏捷方法的问题在于过度不规定做什么。PMBOK®第
5 版差不多有500 页。PMBOK®的原意非常清楚，它提供了一组工具，你可以将这些工具作为参考
，按照你的理解使用它们。然而PMBOK®的写法，很容易让人将其看做权威性的和规定性的文件，虽然这并不
是它的本意。

“敏捷方法制定文档强调最精简化。遗憾的是，大部分传统方法都受累于”减法”方法。这些传统方法都是由专家
制定的，他们希望这些方法可以为使用者提供所有的可预见的情况下的指导。所以专家们制定了非常全面的方
法，并在不重要的和不复杂的项目上做”减法”。这些专家理解如何做”减法”，并经常为其他人提供指导和案例。

遗憾的是，大多数开发人员、用户和项目经理并不具备足够的专业知识和自信心，他们希望看到所有的计划
、规范和标准，他们觉得这样比较安全。非专业人士无法根据需要选择合适的方法而是在项目上直接使用所有
规定的方法。非专业人士很少阅读不断更新的资料，而是错误地认为他们使用了最佳实践方法来保证项目的可
预测性和可控性。不用说，制定方法的专家会非常失望，因为他们的方法被按照字面的意思错误地使用。

敏捷方法如Scrum被批评太过虚无，在一些重要的领域不够具体，尤其是在一些高层次的项目管理方法上面。
另外，PMBOK®和其他的传统方法被批评规定性太强。最理想的方法介于两者之间，西方人喜欢把矛盾的问
题分开看，东方人喜欢对立统一的看问题，其实敏捷的至高境界应该是中庸之道，则其两端而用其中。

3.人性价值导向与流程导向：为项目选择流程而不是相反

另一个很大的区别是人性价值导向和流程导向的区别。PMBOK®没有深度挖掘项目管理中的人性成分，而敏捷
方法则直接谈到了项目人员管理中的人性成分。

PMBOK®第9章和第13张谈到了“项目人力资源管理”与“干系人管理”。这些题目应该更多地依赖原理性理解和
反复实践才能灵活掌握，尤其是要善于反思才能做好，而不是采用一些按部就班的流程就能做好“人力资源管理
”和“干系人管理”。

PMBOK®第5 版附录 X“人际交往技巧”。而在敏捷方法中，这个主题是整个方法体系中的一个有机组成部分，而
不只是作为附录加入的。

当然，一个优秀的项目经理懂得如何管理项目人员。尽管PMBOK®并没有任何具体的介绍，但是敏捷原理更加
深入，在敏捷宣言中将其明确为价值之一。

“依靠自我激励的团队完成项目。为他们提供需要的环境和支持，信任他们可以完成工作。“

两种方法的区别在于：

PMBOK®指南的出发点是以流程导向的，后来开始在流程导向中融入了以人为导向的思想，但依然还是以流程
为主而以人为辅的

敏捷则从一开始就强调以人为本，敏捷宣言中的四大价值之一就是“个体和互动高于流程和工具”。

这两种方法已经日益融合，但这两种思想体系要真正地融为一体尚需时日。

敏捷方法在过去的16年间成熟度大大提升，也越来越多地认识到在以人为本的基础上也需要增加以流程为导向
的内容。

PMBOK®指南已经逐步开始丰富项目管理中软件的部分及更多对人的关注（在PMBOK?指南第6版本中新加入了
敏捷的应用指导，就是很好的例子）

4.强调前期计划和控制与对变化的及时响应

控制与适应决定于项目的不确定性和复杂度

另一个PMBOK®指南的方法同敏捷方法间的重大区别就是，PMBOK®指南一直以来都强调前期计划及控制，自
然而然地会注重对项目范畴的管理和控制。虽然PMBOK®指南中明显地说明对计划和控制的注重，但这确实是
人们对于PMBOK®指南的一种常见解读。在敏捷项目中对项目范畴的控制并非至关重要，敏捷方法持有一种开
放的心态，鼓励和欢迎在项目过程中来自相关人员的各种变化。这在思维方式上大相径庭。

当业务需求非常不确定，随着项目进展很有可能发生变化，要想真的控制改变只是一种妄想。即便是计划非常
完善的项目，可能开始时看起来一切尽在控制，而后期变化非常频繁而导致所谓的控制变成了虚幻的表象。在这
种情况下，试图获得高控制性是徒劳的，而真正需要的则是控制和灵活之间的一种平衡，既有根据计划的一定
的控制，又保持足够的灵活性以应对项目过程中业务需求的变化。

我们必须仔细思考如何实现这样的平衡，而要获得这样的平衡必然要做些权衡。比如说，要想成功获得业务上
的效果，就要在整个开发过程中采用更加协作的方法，允许在开发过程中提出更多的业务上的需求，而这可能
会影响对项目的预测，以及对于成本和时间的控制，这种权衡应该是完全可以接受的。PMBOK®指南中没有任
何地方说不可以做这样的妥协，当然其中也没有特别鼓励去做这样的权衡。

而在另一个极端，敏捷方法则鼓励项目团队尽早地进入执行阶段，不要做过多的前期计划，而这则带来另外的
一些问题：

由于前期计划很少，开始时对于预算和时间的估计非常不可靠，这可能带来意外的“惊喜”。

由于在敏捷方法中，经常采用增量和迭代的方法来开发，没有在前期做好架构设计的工作，而是随着项目进展不
断完善的，这可能导致大量的重构工作。

在很多情况下，项目失败并不是由方法本身导致的，而是由错误的实施而导致的。不管敏捷方法还是非敏捷方法
，从来都没有任何理由阻止我们根据具体的业务情况及项目本身的风险和复杂度来选择和制定好的方法。

比如说，敏捷方法同样可以包括：

通过适当的前期计划来获得一定精确度的成本和时间估计，并随着项目进展不断地完善它。然而，有些比较极端
的敏捷的拥护者则认为对于敏捷项目而言，计划及成本和时间管理已经完全不需要了。

在前期做适当的架构设计并随着项目进展不断修改和完善架构。

结束语

从表面上看，PMBOK®指南同敏捷的方法和实践是水火不相容的。如何能将两者融合起来并不是显而易见的，
但两者却是相互之间非常好的补充。要将两者很好地结合起来需要花费一些时间。而理解这两种方法论，并根
据项目的具体情况准确判断并将两者结合起来，则依赖每个项目经理在管理具体的项目时去实现。