虽然两者的结合看起来很怪，但是业内人士指出传统项目管理与敏捷开发并不是互相排斥的关系，实际上这两者是互相补充的。

PMBOK与敏捷：朋友还是对手

麻省剑桥Forrester研究所的Dave West在一份关于项目团队的研究报告中指出：“灵活的敏捷项目经理会做出许多PMBOK实践，但他不会把它们称为PMBOK实践；而灵活的PMBOK项目经理会做许多敏捷实践，他同样也不会称它们为敏捷。”

在Forrester最近的一份报告《PMBOK与敏捷：朋友还是对手？》中有这样建议的：用两者的优点来促进项目的成功。并且，报告更主张企业要根据情况选择最合适的实践与方式，而不能期望找到一种可以解决所有问题的方式。

Jim Johnson是位于波士顿的项目管理咨询公司Standish集团主席。他对此持有相同意见：“管理者需要分析自己的企业和环境，了解需要的部分和可持续运行的部分。所谓项目管理其实也就是根据情况选择合适的对策。”

在West看来，人们对敏捷和PMBOK都有一些误解，而这些误解使他们认为两者是无法相容的。其中一个误解就是，他们认为传统项目管理是高度有组织性、不灵活的，而敏捷则是高度无组织性的。但West认为，敏捷项目其实比人们想像的要有组织性、和纪律性得多。通过持续的计划与透明度，人们可以更多地对敏捷进行控制。而PMBOK也不是僵化的，它是一系列优秀、明智技术的结晶。

PMBOK与敏捷：互不相同、互为补充

当然，这两者也有一些迥然不同的因素。比如，根据Forrester研究报告，传统项目管理相对更倾向“命令与控制”的方式，项目经理是项目的最终负责人；而敏捷则更倾向于自行管理、自主活动的方式。两者在工作组织与分配上也不相同，敏捷团队是自己决定由谁做哪一部分工作，这与传统的PM分配任务正好相反。

此外，在传统项目管理中是由项目经理向团队成员和项目利益相关人或客户分发进度报告；而在敏捷开发方式下进度是对所有团队成员透明的，而利益相关人或客户则是团队的一部分。另外，文档的多少也是两者的不同点之一。

许多人会对传统项目管理产生误会，可能关键是PMBOK描述的是一个瀑布模型。而事实上，PMBOK的内容是相当了不起的。West认为：“因为人们都是按照顺序把它读完，所以自然地也按这个顺序进行实际应用，所以大家认为它是瀑布式的。但是实际上它并没有提倡某种具体的过程流程。”

另一位咨询师Michele Sliger，她是《软件项目经理的敏捷之路》一书的著者之一。她正在负责为项目管理协会（PMI）筹建一个敏捷论坛，希望藉此让更多的人了解敏捷。PMI的此举表明，敏捷并没有被当作一时的潮流，而是一种进行软件项目管理的有效方法。做为该论坛筹划委员会的一员，Sliger认为PMI的敏捷项目可能会在今年的第二个季度启动。

Forrester的研究表明，PMBOK确实能够弥补敏捷的一些不足。这包括：

· 为项目启动和结束提供清晰的指导

· 沟通与项目集成管理

· 项目经费管理

· 风险管理

而另一方面，敏捷也为PMBOK提供了补充。这包括：

· 交叉功能的团队

· 使整个项目更灵活、易于调整

· 鼓励与客户建立密切的关系

· 适当的严格标准与文档

项目经理的角色转变

Johnson和West都认为，虽然项目经理的角色在敏捷环境下已经发生转变，但这并不等于敏捷项目不再需要领导。Johnson说：“我认为项目经理是一个重要的角色。多年的实践证明项目经理这个职位和其技巧是有用的。”不过他也补充到，项目经理的作用已经改变，“他更像是一个管道经理，主要负责保持项目向前流动。他要保证这个管道不会堵塞。可以说基本上只是保证项目可以进行地更快。”

West认为，“大部分敏捷项目都有一个类似项目经理的职位，虽然他们可能并没有称之为项目经理。他可能是Scrum M a s t er，也可能是产品负责人，但不管是谁，肯定需要一个起领导作用的人。不同之处在于领导方式。敏捷不提倡命令与控制的方式，项目通常是自主进行，因此项目经理这一职位基本上只是起到一个指导的作用。”

网络内容管理公司Vignette已经转向敏捷开发方式，类似传统项目经理的是计划经理的职位，但是他们的职责稍微有些不同，除了那些大型的、涉及多个团队合作的工作，计划经理并不做针对项目开发的计划与协调工作。他们的主要职责是“管理软件发布过程，包括初期版本/beta程序，为销售、服务和售后提供技术支持，负责与外部供应商的协调工作（比如本地化）等。

Basab Dattaray是TurboTax集团负责新业务启动的工程经理，他认为转向敏捷之后对项目经理的需求明显减少。“我们确实还有项目经理，他的职责主要是设计用户体验。我们也有轮番上任的。通常我们只用一小部分时间来处理项目管理上的问题。敏捷使团队成员感觉自己有更多的权力做出决定，让他们更有责任感，因此对项目经理的需求也就减少。”