拥抱变化、快速响应、平等协作、持续改进-- PMI-ACP敏捷项目管理与创新之道文/银联培训中心主管于兆鹏随着首届世界互联网大会召开，“互联网变革”又一次撞击了人们的眼球。

人类历史上曾经发生过许多次伟大的变革，但从来没有一场变革像“互联网变革”一样能触及全球70亿个个体。

不仅仅是互联网让我们在变！随着中国经济的转型和新生代消费群体的崛起，中国乃至世界的社会经济模式正经历着：----以生产为核心到以需求为核心的转变----以商户为核心到以用户为核心的转变----以产品功能为核心到产品体验和个性为核心的转变中国正在进行着由卖方市场到买方市场的重大社会变革，中国经济也因此将由原来的粗放型经济形式转变为集约型经济形式，由原来的世界工厂转变为未来的创新基地。

在这样的时代背景下，变革参与者需要深谙互联网“开放、平等、协作、分享”的精髓，通过互联网、移动互联网等各种工具，使得传统企业的业务具备透明度更强、参与度更高、协作性更好、中间成本更低。

一句话，正如彼得•德鲁克所指出的：“互联网消灭一切基于信息不对称的商业模式”。

在新的商业模式下，作为项目经理的我们需要关注：----如何拥抱变化，抛弃传统模式封闭的弊端，以极限迭代引领客户需求和市场变化；----如何简化流程，最大化客户收益，始终关注组织和客户的核心价值点；----如何将客户拉进团队，让客户之声成为打造制胜产品的真正利器；----如何最大化激发团队潜能和创新力量，摆脱传统管理模式带给人性的束缚和禁锢；----如何将持续改进纳入到团队每天、每小时、每分钟的工作循环，使改进这一词汇不再成为原来项目经理的口头禅，而是每个团队成员心中的戴明环；对于我们而言，尽情享受“这场变革”的同时，正确把握社会的发展方向，才能使之继续造福于全社会。

一、为什么需要敏捷长期以来，受传统项目管理思维的影响，项目计划往往需要很完备才有能开工的理由。

我们往往因为不清楚WBS（工作分解结构）应该分解到何种程度而苦恼，或在一开始就试图将项目的方方面面都考虑得很周全，这在项目真实场景中是不可能的。

许多项目报告，尤其是在项目早期阶段显得过于乐观。

因为让一个项目经理接受他们的进度会落后于时间表是一件非常困难的事情。

在项目分析阶段，想知道总共有多少分析量是不可能的。

那这样问题就来了，你既然不知道总量，又如何知道现在的工作能按部就班完成呢？长久以来，我们一直在接受着这样的教导：项目经理是负责人。

他管理团队，指派任务并且承担整个项目成功的责任。

所有这些压力和以及所有这些期望都指向同一个人，这个人也负责项目的沟通交流工作。

有了这样的场景，我们怎么可能期望项目沟通交流是中立的? 老板如果要求每周多给出一份详细的状态报告，那么这不就是一种不信任吗? 在我十五年来的项目管理职业生涯中，不断看到这种机能失调和不信任。

个人职业生涯有十年是与软件行业有关。

熟知软件模型发展历史的人知道，传统软件开发模型是在20世纪60年代形成的，在那个时候统治IT王国的是大型计算机。

在那个时代所使用的技术并不欢迎变更。

那时候编程的模式是过程化、自上而下的。

如果需要变更，就需要重新编译并组装整个程序或系统。

为了安全起见，每一次编译的成品都需要新的完全测试。

这个模型为其特定的技术服务，人们往往企图像神一样尝试一次性把工作做好。

后来软件行业采纳了新的面向组件的技术，但是底层的开发过程仍旧经常使用相同的传统方法。

相比之下，现代软件开发通常使用面向对象的技术。

这些面向对象的系统是由更小的高度聚合、松散耦合的分块和元素组装起来的。

这就使得开发团队能够以更小的步骤和单元进行开发、测试和集成。

敏捷开发和敏捷项目管理方法更早、更频繁地把变更带入，而且这些方法以小的、循序渐进的步骤来构建软件。

软件行业发展只是时代发展的一个缩影，中国经济三十年来的发展同样也在经历着从传统模式到敏捷模式的演变！20世纪80年代-90年代，中国经济刚刚腾飞，整个社会经济还是以计划经济为主导，市场导向是以厂家或供给方为核心的。

实际上国家经济发展战略是以“出口导向”战略代替“进口替代”战略，以出口“量”的扩张促进经济增长。

这种发展模式下就决定了卖方不需要过多关注用户的需求变化，只需要能生产出能满足市场需求量的产品就可以了，因为整个市场是供大于求的。

20世纪90年代-21世纪初，国家经济发展策略开始实施由“量的扩张”转向“以质取胜”的出口战略，更好地利用外资和技术积极实施“走出去”，从而使出口贸易在国民经济中产生质的飞跃的阶段。

在这个阶段，用户开始有产品“质量”意识，开始不仅仅关注产品的量的满足，而更关注产品的品质。

整个市场开始求大于供，一个重要的用户权利：“选择权”开始回归到用户手中。

21世纪初-至今，国家发展策略注重以科技为主导，使本国经济能够自主进入世界经济并居主导地位的阶段。

在这个阶段，用户对产品的期望已不再满足于“质量”的需求，而是更加注重“体验”，希望产品能包含更加个性化的元素。

这样的需求导致必须保证产品的开发有足够的用户参与度。

从项目需求管理的角度来说，用户的参与可以有效降低需求的“二义性”（即用户对同一种需求有不同的理解），同时通过引入用户的参与可有效提升其满意度与项目的可视性。

而敏捷非常强调用户的参与，经常要求干系人对项目成果进行确认，可消除需求二义性，并提升用户体验。

二、什么是敏捷敏捷方法是一种能够容纳变更的产品开发框架。

比如，通常对于复杂的产品开发工作，需求在项目开始的时候尤其是未知的或模糊的。

所以，敏捷框架必须要有内在的机制使项目得以处理并减少这些不确定因素。

敏捷也意味着框架本身也是灵活的，并可以适应许多情况。

因此许多人把敏捷方法描述成“经验性”(Empirical)的方法，因为项目本身必须适应其环境。

敏捷源于敏捷宣言（Agile Manifesto）。

敏捷宣言是2001年在美国犹他州的Snowbird滑雪胜地召开的一次会议提出的结果。

17个与会者定义了敏捷过程并签署了宣言，这些成为了今后人们对敏捷的衡量标准。

敏捷宣言只有短短的四句话，却为所有敏捷实施者提供了一个共同的基础：----个人和交互优先于过程和工具(Individuals and Interactions Over Processes and Tools)----可工作的软件优先于完备的文档 (Working Software Over Comprehensive Documentation)----顾客协作优先于合同协商(Customer Collaboration Over Contact Negotiation)----响应变更优先于遵循计划(Responding to Change Over Following a Plan)请注意每个句子的左边比右边更有价值。

这并不意味着右边的没有价值，只是说左边的更有价值。

因此每个敏捷项目团队必须找到团队的正确平衡点。

PMI-ACP全称Agile Certified Practitioner，是由美国项目管理协会（PMI）于2011年推出一门敏捷项目管理的认证。

PMI-ACP涵盖了目前主流的敏捷方法论，包括Scrum、XP、Lean：----Scrum：Scrum是Ken Schwaber和Jeff Sutherland在20世纪90年代开发的，他们将其定义为一种敏捷项目管理框架而不是一个敏捷过程。

Scrum源于精益制造(Lean Manufacturing)、迭代-增量式开发(反复与渐进式开发)和Smalltalk工程工具。

Scrum提供了一套简单的规则：首先，Scrum中有三种角色：产品所有者(Product Owner)、Scrum队长(Scrum Master)以及团队(Team)；其次，使用两种不同的待办事宜(Backlog)来对范围进行管理：产品待办事宜(Product Backlog)-捕获产品的范围和冲刺待办事宜(Sprint Backlog)-包含当前迭代的详细工作。

冲刺(Sprint)是Scrum称呼迭代的同义词，每次冲刺为4周时间。

整个Scrum团队每天碰面15分钟，以便让每个成员之间相互快速更新信息。

----XP：极限编程（Extreme Programming，XP）是Kent Beck、Ward Cunningham和Ron Jeffries 在20世纪90年代开发的一套动态编程实践。

现在XP是高技术行业最常采用的敏捷方法。

XP中最值得关注的实践是结对编程(Pair Programming)和测试驱动开发(Test-driven Development)。

----Lean：精益开发源于Bob Charette，它是精益制造在软件开发上的应用，它是由22个工具组成的工具箱，“消除浪费”就是精益开发中有名的工具。

三、敏捷工具与方法敏捷有许多工具，像我们熟知的迭代-增量开发、测试驱动开发、持续集成、每日例会、自适应团队等等，虽然工具方法很多，但这些万变不离其宗，其本质思想都是不断拥抱环境变化，快速响应客户需求，以开放平等的精神进行团队协作，以及不断持续改进产品。

下面我们介绍迭代-增量开发、每日例会、自适应团队这三个敏捷中最核心的工具和方法：----迭代-增量开发：迭代-增量开发可以说是对传统项目管理的颠覆。

它实施的是重复和半并行化的开发活动，而不是在整个项目中只对每个产品开发周期（需求、设计、开发）执行一次（这是传统的瀑布模式）。

这意味着项目活动极为窄小而且相互之间极为接近，他们的顺序也可以变更。

作为一个经验方法，迭代越短越好，这也是敏捷过程每个迭代只需要大约2-6周的原因。

这个工具中第二个方面是实际的增量。

迭代带来项目的节奏，而增量说明了项目的实际进展。

在敏捷中，进展以可工作的软件为衡量基准。

敏捷项目管理有点像切蛋糕，项目必须切成块，我们在开始的时候不知道我们需要多少块，也不知道这个会是哪种蛋糕。

我们会随着项目的进行，一块一块地弄明白。

这样在一个迭代的末期，一个优先级排序比较高的需求中的一块，就完成了，这是迭代-增量开发的真正的亮点：在项目启动两周（一个迭代）之后，一项需求就被转化成了可工作的软件并且可以向顾客展示。

而这种方法最大的有价值之处在于，我们为客户打开了一个项目早期的反馈环，客户可以在现在做出变更并且按照他们所期待的正确方向指引项目，而这是许多客户在传统项目管理模式中无法想象的。

迭代开发不仅仅有上述优点，它的优势还在于：在早期的迭代中就可以减少或消除高风险；根据以往的迭代效果，可以越来越精准地预测完成日期的趋势；团队士气通过不断的客户反馈而增加，生产率成倍提高等等。

迭代-增量开发对于习惯于传统项目管理模式的人或机构来说是一个巨大的改变。

然而，这种改变是值得的，因为它几乎可以立即带来不可估量的效益。