从IT项目管理看待PMBOK和敏捷开发

陶思俊



从IT项目管理看待PMBOK和敏捷开发

陶思俊

（中国人民大学信息学院，北京 100872）

PMBOK是项目管理界的“圣经”，坚持与时俱进，作为项目管理的基础课程多年以来保持长盛不衰。与此同时，从01年敏捷宣言的发布以来，IT领域掀起了一场“敏捷开发”的变革，它通过适应性的开发和管理模式，试图对40多年来的软件工程进行重新的梳理和流程再造。两者之间是什么样的一种关系呢？敏捷开发对于PMBOK来说，究竟是一种补充，还是一种颠覆，并就此证明PMBOK在IT领域已经失效。通过对两者理论背后的逻辑进行深入剖析，试图揭开面纱背后真正的答案。

PMBOK；敏捷开发；Scrum；极限编程

1 PMBOK

1.1 PMBOK的目的

项目管理作为一门专业，已得到认可，这表明知识、过程、技能、工具和技术的应用，对于项目的成功有显著影响。PMBOK®指南收录项目管理知识体系中被“普遍认可”为“良好做法”的那一部分。“普遍认可”指这些知识和做法在大多数时候适用于大多数项目，并且其价值和有效性已获得一致认可。“良好做法”，则指人们普遍认为，使用这些知识、技能、工具和技术，能够大幅提高项目成功的可能性，但并不意味着这些知识和做法总应一成不变地应用于所有项目；组织或项目管理团队负责确定哪些知识适用于具体的项目。

由此我们可以得出：PMBOK是一门以具体的实践归纳出的“最佳实践”的集合，而并非是演绎出的科学。我们知道：越是所谓“普遍认可”的概念，其抽象层级就越高，因为越具体的概念和实践，其适用性就越受到上下文和情境的制约，而从PMBOK提供的项目管理框架，我们也可以了解到，即PMBOK提供了一系列框架和接口，而并没有提供具体的实现方法。假如在我们做IT项目时，到底选择传统的瀑布模型，还是CMMI模型，或是敏捷开发模型来实现这套框架，PMBOK并不关心。

1.2 PMBOK中的核心概念：十大领域、五大管理过程组

PMBOK核心的概念莫过于十大领域、五大管理过程组，47个管理过程被归纳在内。其内容如图1所示。

图1

PMBOK中非常直接地指明了“任何项目都必须的五大管理过程组”，这个说法从逻辑上可推论出：（1）五大管理过程组对于所有项目来说都是必须的；（2）IT软件项目也是项目；（3）五大管理过程组对于IT项目也是必须的。可见五大管理过程组的概念在PMBOK中的核心地位。

2 敏捷开发

2.1 传统瀑布模式下的问题

传统的瀑布模式开发，起源于1970年温斯顿·罗伊斯的一篇论文，论文中指出了非常分明的几个阶段，正由于此，从概要设计完成的时候开始，后续对于需求的修改都会充满痛苦。作为项目经理，无法自如地调整需求；作为开发团队，对于上游的需求修改也是叫苦连天。因此就产生了一种趋势，在项目开始阶段，双方会对项目的范围进行一场拉锯战，项目经理希望范围更大一些，因为一旦开始开发，再做调整就是不可能的事情，而那个时候再发现当初少了什么，都是项目经理的责任；而开发团队因为自身的生产力有限，不可能承受比自己产能更多的需求，于是希望尽可能地减需求。直到项目范围讨论的Dead line临近，或者双方都已经筋疲力尽的时候，博弈才会取得一个暂时的一致。如果项目出了问题，双方又会对责任划分进行新的一轮争吵。这难道真的就是我们想要的结果吗？最终的结果就是程序员们付出了自己的青春年华和无数个不眠之夜，生产出了大量的没有人用的代码，据统计，真正投入使用的代码其实数量不过半。

所有软件开发的过程都是为了一个目的：尽可能将问题发现在前期，而面对着一堆文档，我们真的可能把程序的问题都发现在纸堆中吗？

值得多说一句的是，任何一个返回头来看一下温斯顿·罗伊斯那篇论文的人，都会为罗伊斯叫一声屈，因为后人的人云亦云让他的这篇论文饱受争议。这篇论文在开篇提到了软件开发的阶段，但下面的一段话却是：“我相信这种方式，但上面列出的这种方法其实是会导致失败的。”论文中他说，原因就在于我们总是一厢情愿地认为在下一个阶段就能把这个阶段的问题全部修订，列车总会一直向前开，但实际上我们总是在项目的中后期发现设计的问题，在编码完成之前，我们是看不到软件运行的样子的。为了解决这个问题，他提出应当把交付分开来完成，一个12个月的项目，至少应当在3-4个月的时候交付一版，干系人看过之后再继续进行，另外应该加强和客户的联系和合作。他的这个观点其实是和2001年敏捷宣言的内容是不谋而合的。

2.2 敏捷开发的起源

正是由于以上提到的种种问题，在上世纪90年代，各种先锋者的尝试和方法百家争鸣，Scrum、Crystal、RUP、极限编程都提出了自己的方法。在各家尝试了近10年之后，2001年有十几位大师级的程序员相聚在美国的雪鸟滑雪场，在进行了几轮讨论之后，大家发现虽然我们的方式不尽相同，但核心理念是一致的：我们希望更有效地生产代码，所以这次大会上产生了在这十几年中熠熠生辉的敏捷宣言：

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

（1）个体和互动 高于 流程和工具

（2）工作的软件 高于 详尽的文档

（3）客户合作 高于 合同谈判

（4）响应变化 高于 遵循计划

也就是说，尽管右边的项目有其价值，但我们更重视左边的项目价值。

敏捷开发以Scrum、极限编程为代表。

Scrum是一种轻量级的产品开发框架，它将一个发布分为若干个迭代，每一个迭代完成之后都会生产出“潜在可交付”的软件，整个的项目都在不断地和客户沟通、演示、确定优先级中进行。

极限编程是一个轻量级的、灵巧的软件开发方法，同时也是一个非常严谨和周密的方法。它体现的价值观是：交流、朴素、反馈和勇气。任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。极限编程是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。其中包括13种具体的实践，诸如：团队协作，规划策略，结对编程，测试驱动开发，重构，简单设计，代码集体所有权，持续集成，客户测试，小型发布，每周40小时工作制，编码规范，系统隐喻等。

2.3 敏捷开发的主要理念和框架

敏捷开发主要以迭代式增量交付为基础，小批量地交付可工作的软件，其基本框架如图2。

图2

其中一切都是从产品待办事项列表开始的，我们都知道，大批量的工作同时展开是浪费之源，所以从源头就需要将大块头的任务进行拆解，借助persona、场景分析、MVP梳理等过程进行用户故事的拆分，并进行排序和评估，从而安排每一个迭代的工作。迭代增量式交付一开始看上去总会很美，但很快就会遇到问题，其一是增量式的交付会带来无止境的回归测试，其二是不可避免的代码腐化，其三是尽管需求可以拆分得很小，但由于固定的人只能做固定的事，在调配资源的时候就会捉襟见肘，这也是很多大公司面临的问题。

对于这三个问题，敏捷开发都给出了自己的解决方案，它倡导将质量内嵌在开发过程中，质量保障工作是贯穿始终的，技术水平的提升也让自动化测试、持续集成成为可能,同时敏捷开发认为代码总是动态修改的，所以我们应当掌握的技能就是重构和测试驱动开发，好的架构是生长出来的，而非几个架构师用PPT画出来的,最后提倡学习型组织，技能扩展，一专多能的人才是现代软件开发中最需要的，所以以特性团队的方式取代老的组件团队，一切以交付优先，而这也就是PMBOK中提到过的强矩阵和弱矩阵之间的关系。

3 PMBOK的十领域，五大过程和敏捷项目管理的对比

这里其实有一个问题，即敏捷开发模型并没有直接提到PMBOK中所述的十大领域、五大管理过程，只是提出了一系列的实践方法，那这套实践方法究竟和PMBOK之间是否存在着什么关联呢？换句话说，敏捷开发模型这只“孙猴子”究竟有没有跳出PMBOK的“五指山”呢？

PMBOK中并没有规定适用的项目生命周期，阶段式（瀑布）和敏捷所倡导的迭代增量式的两种生命周期在POBOK中都被提及，PMBOK中所述适用迭代增量的项目特征是这样的：“组织需要管理不断变化的目标和范围，组织需要降低项目的复杂性，或者，产品的部分交付有利于一个或多个干系人，且不会影响最终或整批可交付成果的交付。大型复杂项目通常采用迭代方式来实施，这使项目团队可以在迭代过程中综合考虑反馈意见和经验教训，从而降低项目风险。”

只能说PMBOK中描述的具有这种特征的项目，目前看来软件开发是最合适不过的，它的目标和范围变化速度很快，复杂性很高，最重要的是采用迭代、增量式的交付“不会影响最终或整批可交付成果的交付”，这恰恰是软件中的“软”所具备的特征。

我们可以逐项去看一下，敏捷项目管理是采用了什么样的方式来实现了PMBOK的框架，见表1。

表1

PMBOK敏捷项目管理敏捷开发典型实践 整合以迭代方式进行开发，小步快跑迭代 范围价值驱动；根据市场、技术变化及时增减需求，并对需求进行优先级排序。产品/迭代backlog、用户故事、迭代计划会议 时间开发过程被分割成1～4周的迭代；发布在迭代交付上按需定义。燃尽图、累积流图、迭代、持续交付 成本评估为预算服务；随时都需要对投入产出作出衡量。迭代、用户故事、精益需求管理 质量内嵌质量于开发过程中：只有业务人员验收了才算开发完成；持续提升软件的可上线成熟度。质量驱动开发、持续集成、持续交付 人力资源和最好的人、团队合作；鼓励追求卓越。建设学习型组织、回顾会议、读书会 沟通通过让团队一地工作来消除沟通隔阂；经常快速给客户展示成果；简单化管理报告。每日站会、验收和展示、结对编程 风险交付风险高的优先考虑；软件可上线成熟度提升减少交付风险。风险驱动开发

4 结论

任何一种理论框架我们都应当辩证地去看，没有放之四海而皆准的所谓“银弹”，我们既不能把前人总结的理论抛之不顾，也不能照搬生套所谓的理论框架，前者会让我们重复造轮子而无法站在前人的肩膀之上，后者的行为无异于刻舟求剑、按图索骥。

既然是管理项目，我们应当因地制宜，每一个项目因为它规模大小、产品面对的市场都有所不同，例如移动APP和大型通信类产品，300人的项目和10人的项目，在项目立项之时我们就应当确定项目管理的策略，究竟应当采取什么样的管理方式、工具、过程，而这个过程恰恰是在PMBOK所处的理论层面上进行，进一步我们可以采用敏捷开发所提供的工具库来实现我们的管理框架和策略，双方应当是一个和谐共生的关系。PMBOK为敏捷开发提供了前人的知识结晶，敏捷开发为PMBOK提供了价值驱动、灵活应变的思维方式，我相信在未来一段时间当中，两者在软件项目管理中只能进一步融合，双方都会吸纳对方的观点和理论，因为两者根本目的是一致的。

[1](美)Project Management Institute.项目管理知识体系指南(PMBOK指南 第5版)[M].北京:电子工业出版社,2013.46-61.

[2](美)肖尔(Shore,J.),活登(Warden,S.).敏捷开发的艺术[M].南京:东南大学出版社,2008.26-38,431-439.

[3]张海藩.软件工程导论(第5版)[M].北京:清华大学出版社,2012.15-16,25-28.

2014-11-19

陶思俊（1981-）,男,辽宁大连人,中国人民大学信息学院IT项目管理专业硕士研究生,研究方向为IT项目管理.

TP311.5

A

1672-4658(2015)02-0180-04