发展现状

国际软件过程领域的敏捷运动源于 2001 年敏捷联盟在美国成立和《敏捷宣言》的正式发表。敏捷软件运动代表了 21 世纪互联网时代软件开发模式的一种先进理念和价值观，相比传统过程，敏捷更强调快速灵活反应，主动迎接和适应变化，主张更紧密的客户与开发商协作和以人为本的企业可持续发展。典型的敏捷过程模型有 XP（极限编程）、FDD（特性驱动开发）、Scrum 以及敏捷的统一过程（AUP）等。

我国软件人员了解、尝试敏捷大概始于 2002 年前后一批 XP 敏捷系列图书在国内的引进出版以及早期相关文章的探讨和报道。总体上敏捷过程在我国发展得还比较缓慢，可以说是刚刚起步。当前采用敏捷方法的企业以外资、成熟、领导型企业居多，大部分国内企业目前可能还处在了解、观望的阶段，对敏捷过程、方法的认知接受程度也偏低。这种媒体热、企业冷的犹豫现象一方面可能与五年来的 CMM 考级热有关，另一方面也可能与市场上某些对 XP 极端做法、敏捷功效神乎其神的夸大宣传有关。

软件过程改进是我国软件企业提升竞争力、获得可持续发展的一条重要途径。一方面，大多数以快速短迭代为特征的敏捷过程有助于消除错误实施 ISO、CMM 带来的官僚主义、形式主义等消极后果。另一方面，许多软件客户和技术主管们对有些 XP 拥护者鼓吹几乎不留设计文档、主要依赖源代码说明的做法存有很大的疑虑，这种工作方式与强调过程文档化、数字化的 ISO 9000、CMM 理念有着显著差别，却得到了我国许多本来就不善于抽象表达设计的程序员们的热烈“拥戴”。

关于国内企业具体采用的典型过程种类，虽然偶尔有零星的 XP 案例报道，但我们发现实际采用类 RUP/UP 过程的远比 XP 多，FDD 偶尔有听说，Scrum 则很少。有一种比较流行、可能比较接近现实的说法是：70% 甚至更多的国内软件企业实际上采用的既不是 RUP、XP，也不是 TSP、PSP，而是一种“什么都像、什么也都不像”的自酿过程。

据说目前国内已有 500 多家软件企业通过了各级 CMM 评估，而 2005 年标志着 CMM 时代的结束，取而代之的是 CMMI（集成的过程能力成熟度模型）。 CMMI 框架相比 CMM 更加成熟、更加健全，也更加灵活和敏捷。 CMMI 的敏捷化以及原本实施 CMM、CMMI 的软件企业过程的敏捷化是一个值得我们关注的方向。

在看到 CMM 由热趋冷、敏捷由冷转热的同时，我们还应看到以 RUP 为代表的统一软件过程（UP）家族的兴起。 RUP 的独特之处在于它采用 OO 技术对软件开发过程本身进行业务建模，在一个成熟灵活的抽象框架之内统一、集成了迭代开发、用例驱动、UML 可视化建模、OOAD、架构设计、变更配置管理、质量管理、项目管理等许多主流先进的当代软件工艺。在统一过程基础上结合敏捷实践的敏捷统一过程（AUP，Agile UP）也成为很多企业的现实选择。

问题与挑战

在学习、传播和实践敏捷的过程中，我们发现国内对敏捷过程存在着以下一些误区。有不少人误认为“敏捷就是 XP ”。事实上，敏捷并不等于“极限”。 Kent Beck 等人发明的 XP 只是众多敏捷方法中的一种，国际上除 XP 外还有 Agile UP、Scrum、FDD、DSDM 等许多成熟的、著名的敏捷过程和方法。 XP 获得了更多的媒体曝光度和影响力，可能与其推广者的积极努力，有关机构投入了更多的媒体公关、市场资源有关。 “敏捷”代表了一整套价值观、原则和实践方法，把敏捷宣传简单狭隘地等同于推广 XP 将会阻碍敏捷在我国得到更为广泛的认同和应用。

还有一种常见的偏见认为 XP（极限编程）带了“编程”二字，表明它是“咱们”程序员自己提出来的“草根”方法，具备此般的亲和力自然极容易自下而上地引起程序员的共鸣，而其他各种所谓的“传统”过程统统是管理者、“外行人”自上而下提出来的，离“咱们”程序员的实际很远。这种看法显然是幼稚和片面的。实际上，像 TSP、UP、XP 等等各类著名的过程方法均是由世界上开发不同应用的各类优秀程序员在软件工程历史上的不同发展阶段分别提出来的。这些过程方法各有各的适用性，无绝对的好坏之分，只有根据自己项目和团队的实际情况选择适用的方法才是明智之举。

我们还发现国内不少公开报道的 XP、UP 应用案例实际上采用的并不是真正意义上的 XP 或 UP。一方面许多自诩的敏捷实施者并没有真正理解 XP、UP 这些经典过程方法的含义，另一方面许多“软件原教旨主义者”又满腔热情地打着大师崇拜的旗号追求纯而又纯的 XP、UP 或 CMM 过程，认为它们都是钢板一块，断不可以修改定制。我们知道越是极限、极端的东西，其适用面往往也就越小。还有些人总是把 CMM、ISO 与敏捷对立起来，可为什么我们不能学习 Kent Beck，在实际过程中吸收 XP 的 TDD、重构、结对编程、持续集成等聪明的做法？当然可以。而且，说不定这种混合集成的、符合中国企业自身特点的敏捷统一过程比“纯洁、标准、绝对”的 XP、RUP 或 TSP 风险更小、收效更大。

在我国推广和实施敏捷面临着一些重要挑战。敏捷化进程是我国软件企业管理从过去的粗放模式转变为现代化精细模式的一个提升过程和发展契机，而软件开发的敏捷性也并不是任何人可以轻易获得的。敏捷的基础包括迭代递增式开发（IID）、面向对象的分析设计（OOAD）等核心技能，国际软件的领导企业 15 年来早已完成了相应的工艺升级和变革，而据我们观察，国内的软件开发目前仍然是以陈旧的类瀑布式过程为主，高于具体编程语言的 OO 技术也未得到深入、广泛和扎实的运用。所以敏捷企业要成功，能否很好地实施迭代过程、提升 OO 技能是关键。

此外，软件工程、过程的敏捷化也不仅仅是软件开发人员单方面的事情，敏捷过程实施的成功在很大程度上依赖于客户的支持与配合。国内不成熟的行业客户往往习惯于“瀑布”思维，在招投标阶段既固定项目的费用和工期，又固定项目的功能范围（笔者戏称其为“三固定”），结果往往导致项目质量的损失，而许多项目最终的真实状况往往是既延期又超支，费用、工期、范围实际上一个也确保不了。这种盲目的客户合同与合作方式不但明显违背科学规律，也给软件企业、行业的健康发展带来了严重障碍。

趋势与机会

假如问软件产品、系统的客户、软件企业的老总们，您欣赏什么样的软件开发过程？成熟、集成、敏捷、统一、先进 …… 可能没有人会拒绝这些美丽的话语，如此过程必然也是所有人（包括广大程序员在内）的追求。然而何谓“成熟”的软件过程？不同行业、不同领域的软件开发可能有各自不同的定义和评判标准。我们认为，软件过程的敏捷化、统一化（含集成化）是必然的趋势， 21 世纪的软件过程没有敏捷、统一的要素又怎能称之为“成熟”？

我国软件要不要走规模化的产业之路？没有规模化，中国软件就没有出路。规模化并不会必然导致官僚、臃肿、迟钝等大企业病。15 年来 CMM/CMMI、RUP、XP 等等经典过程模型方法的出现标志着国际软件工程、工艺的空前发展和高度成熟，遗憾的是我国民用软件工程在开发过程、工艺标准等方面似乎一直是乏善可成、鲜有成就，造成这一差距的原因可能就在于我们过去始终乐于忙忙碌碌，却没能及时很好地总结自己的经验教训。敏捷、统一是当代成熟软件过程发展的主旋律，我们认为参考 CMMI 框架、结合 RUP、XP、Scrum 等最佳实践的敏捷、统一、集成的过程之路更适合以中小企业居多的中国软件行业的现状，我国软件企业和产业迫切需要建立属于自己国家和地域的“审美标准”，应该而且有条件提出有中国特色的软件过程评价标准和参考模型。