Joseph Flahiff有超过15年的敏捷和传统项目管理经验。在过去的5年中，他致力于企业中的敏捷项目管理工作。最近Flahiff在为一家医疗保险公司做敏捷项目的管理和培训，该项目价值2千万美元，预计为期3年，共有超过100名团队成员。Flahiff有项目管理专家（Project Management Professional）、六西格玛绿带和Scrum专家等认证，经常在世界各地传授有关敏捷和瀑布模式整合的经验。在2011年5月于爱尔兰都柏林举行的PMI Global Congress上，他将就此话题进行演讲。有关当前企业敏捷项目管理趋势的资料，比如视频、专题讨论和其他免费资源等，都可以从Flahiff的Whitewater项目博客上获取。

　　也许你曾经从IT部门那听说过敏捷项目管理，可能有这样的描述：“这是一种推进IT项目的新方法，能够更快更好地保证你达成目标，而且成本也较低。”另一个角度的说法是：“敏捷项目不需要任何文档工作”或者“敏捷项目的计划是可以灵活变化的。”

　　上面这些说法正确吗？敏捷到底是什么？其适用的场景是什么呢？

　　简单地说，敏捷项目管理就是团队成员在开发软件的过程中和客户保持紧密协作，对于客户的需求变更给予快速地响应。

　　传统的项目通常以这样的模式进行：定义需求、架构设计、实现、测试和最后的发布。至少在敏捷的圈子看来，这就是所谓的瀑布式项目管理模式。在大多数情况下，人们采用的敏捷模式是这样的：将项目分解，形成众多的小模块，然后进行快速交付（通常2到4周），以此加速功能的实用并为下一次迭代获取足够的反馈。这就是敏捷模式和传统模式最显著的区别：多次而不是仅有一次交付。

　　我当时正在做一个医疗保险的报表项目，在规划下两个礼拜的工作（即敏捷术语中的iteration）时，有过这样一次网上交谈：

　　就这样我们开始了PDF打印功能的开发。Project sponsor很清楚她这个要求带来的影响，而我们团队对此也没有异议。这对我们来说没有任何问题，因为前两个礼拜的工作完全是自包含的，已经完成并可以交付。我们可以马上开始PDF打印功能的开发而不会落下什么工作。这就是敏捷方法所带来的适应性，尤其适用于与客户紧密交流的软件开发工作。

　　敏捷模式的起源？

　　敏捷是在多年的项目失败经历之后由软件开发人员和思想先驱们发起的革命。当时，IT项目尤其是软件项目普遍面临延迟和超支的问题。作为应对，上世纪90年代中期涌现了诸多轻量级的新方法：测试驱动设计（test-driven design）、功能驱动设计（feature-driven design）、动态系统开发方法（Dynamic Systems Development Method）、Crystal Clear、Scrum和极限编程（Extreme Programming）等等。

　　2001年，17位来自上述各个领域的代表举行了一次会议并发表了敏捷开发宣言（每次离经叛道都会伴随着一个宣言的诞生）。宣言的作者之一Jim Highsmith表示，这是对文档驱动型传统软件开发流程的一次颠覆。

　　我见过的对于敏捷核心本质最经典的描述来自于Jim Highsmith所记载的这段历史文字中。根据Highsmith的记载，在当时会议的最后，宣言的作者之一Bob Martin这样谈到自己的看法：“与团队成员和谐共处，齐心工作 … 基于相互之间的尊重和信任，在协作的基础上提升模型，共同构建大家所期望的团队环境。”

　　这就是敏捷的核心所在：一系列将人放在首位的特性。无论是什么工作，人都是最重要的，超过其他任何因素。

　　对于上面提到的各种软件开发新方法，敏捷宣言总结了共有的4个价值和12条规则。宣言这样声明：通过总结这些特性，我们力图发现更合理的软件开发方式。在工作中我们要重视下列方面：

• 个人和相互沟通高于流程和工具
• 软件高于文档
• 客户协作高于合同条款
• 应对变化高于墨守计划

　　下面我们逐一对这四点进行解析：

　　1. 个人和沟通高于流程和工具

　　敏捷方法认为软件最终是人编写的，而不是流程和工具。无论是统一建模语言或者每天的进度汇报都无法构建优秀的软件，代码最后还是由人写出来。团队成员的协作一致是构建高质量软件的最重要因素。如果忽视人的重要性，开发流程就是空谈。这一点不是最为典型的问题，很多企业都会宣称“人力是我们最重要的资产”，尽管可能没有什么实际举措。

　　2. 软件高于文档

　　在敏捷环境中，软件是流程的唯一衡量物。在代码完成预期的功能之前，你不会有任何基础来构建流程。以文档和计划为基础，你可能就希望得到所预期的软件，但是，你还没有实际的经验和证据。

　　3. 客户协作高于合同条款

　　基于第一波互联网浪潮那几年的软件开发经验，敏捷宣言的作者们都认识到在合同条款协商上耗费的大量时间不如花到软件开发上去，因为在软件最终交付时合同中的很多假定都会发生变化。即便合同在某种程度上不是很明确，只要在整个过程中和客户保持紧密地协作和交流，也可以推动工作快速向前。

　　如果只是内部项目而没有合同的话，你可能会认为这样做是没有意义的。但是别忘了，项目章程其实就是项目的合同。你可以自己来检验这一点：是否有管理项目变更的流程？是否需要很多审批来促成项目变更？如果答案是肯定的，那么你就可以把项目章程作为合同来看待。

　　4. 应对变化高于墨守计划

　　对变化的应对并不意味着就要抛开先前的计划，而是摆脱以繁杂的变更控制流程为基础的僵化计划，从而转向一种更加灵活、能够适应变化的方法。无论是试图提升灵活性的软件开发者还是竭力贬低敏捷的传统项目经理，这一点通常是首先被提及的。或许这一点是二者最大的分歧所在，也有可能是开发人员受尽了墨守成规的经理的责难，后者在变化无可避免时仍然会把事情弄得极为烦琐。

　　总之，尽管流程、文档和计划都有自己的价值，但是人始终是软件开发的核心因素。记住这一点，你就已经是在向敏捷迈进了。