敏捷中国史

内容亮点

• 敏捷发展亲历者与推动者、资深程序员熊节作品
• 2000 — 2019 中国软件工程 20 年发展关键脉络
• 敏捷方法如何从草根流派到备受青睐，再到存有争议
• 无数资深老程序员上下求索突破技术瓶颈的编程岁月
• 首次集中呈现 IT 巨头阿里、腾讯、华为的敏捷之路

专家推荐

在我看来，软件研发人员大概可以分为四类：知道自己正在变得敏捷的践行者、知道自己并不敏捷的鼓吹者、不知道自己其实已经很敏捷的草根探索者，以及埋头搬砖茫然不知世事的开发者。

我大概是属于第三类：“圈外敏捷”吧。看到书中那些圈子里的风起云涌，间或还能看到自己的名字出现其中，颇有些山外看山的莫名趣味:)。推荐大家都来阅读《敏捷中国史》，相信大多数人，都能够在其中找到自己的那一段故事。

——庄表伟，华为内源架构师

我理解《敏捷中国史》不仅仅是对历史的记录和纪念，更是以史为鉴。文中一个个致力于改善工作成效的一线从业者，致力于推广新方法新工具的布道者，正是他们吸引了一批又一批热衷软件开发的人加入进来，一起推动行业的发展。

——张松，ThoughtWorks 中国区总经理

课程背景

敏捷是一种重视质量、追求快速反馈的软件开发方法。它对行业的影响远不止几个编程实践，说它影响了 Java 技术栈的变迁，说它引领了 DevOps 和持续交付的潮流，甚至，说它在中国 IT 发展史上是浓墨重彩的一笔，都不为过。

然而，敏捷在技术人士中具有很大的争议，有人将敏捷奉为圭臬，有人对敏捷嗤之以鼻。

大家对敏捷的态度为何有天壤之别今很多人所认识的敏捷跟 Martin Fowler、Kent Beck 等先驱主张的敏捷有何不同0 后与 80 后老程序员当年是如何突破自身技术成长困境，将敏捷引入中国的捷是如何从一个名不见经传的小流派，到如今，从自由职业者，到创业小团队，再到大型公司，无不接纳并大力应用它的T 领域最有影响力的巨头阿里、腾讯、华为的技术成长是如何深度融入敏捷方法的/p>

作为中国敏捷十余年发展历程的亲历者与推动者，资深老程序员熊节从整个中国 IT 发展进程审视敏捷，通过本课程带你一起重新经历一代程序员的青葱热血岁月，与你一起梳理中国软件工程领域 20 年发展的关键脉络。

不止于敏捷，你会切实感受到整个中国 IT 行业、乃至中国经济的发展。

作者介绍

作者：熊节，现任宝尊电商成都研发中心总经理，曾任 ThoughtWorks 总监咨询师、 CSDN 技术主编。

IT 行业打拼 18 年，在金融、零售、政府、电信、制造业、全球医疗等行业的信息化建设方面有着丰富经验。翻译了《重构》《软件工艺》《实现模式》等行业重要著作，是中国 IT 浪潮中敏捷发展的领航者之一。熊节拥有利物浦大学 MBA 学位。

插图：虎头锤，旅居墨尔本的老程序员，北邮博士、北大硕士，15 年编程经验。目前从事支付系统相关业务，曾转战区块链、通信行业。敏捷倡导者、手绘爱好者。

课程大纲

在行文中，我用了两种文体。在相对严谨的正文之间，我有意穿插了一些相关的故事（浅灰色小字号部分）。这些故事有的来自朋友之间未必精确的口述，有的还不乏我自己并无恶意的想象。

在我的设想中，会有这样一位好奇的读者，在了解到过去曾发生的“时事”之外，也会对“时人”的际遇报以两声慨叹，那么，我的记录就算得其所哉了。

从公司回到租住的小屋，孟岩打开电脑，拨号上网，习惯性地登录上了 CSDN 论坛。在这里，孟岩的 ID 是 “myan”，C++ 版和面向对象版的大侠。论坛里很多人在讨论问题时会请教他的意见，甚至引用他的话语。刚考上清华的才子王曦想办一份叫《C++ View》的电子杂志，也会询问他的建议。畅销书《深入浅出 MFC》的作者侯捷通过华中科技大学周筠编辑的关系联络到他，邀请他合译大部头的《C++ 标准程序库》。

孟岩彼时在网络上声名鹊起，重要的原因之一是他在 2001 年 2 月发布的一篇文章：《VC 不是梦想，C++ 需要自由的心》。在中文世界里用“梦想”、“自由”这样的词汇来描述一种编程语言，就算他不是第一个也差不太远。把当年如日中天的微软批评为“封闭”、并振臂疾呼“在我们程序员的心中，没有凯撒，我们可以把你当朋友，但是你别想做我们的主子”、“不自由，毋宁死”，这在当年看来是极具开创性和震撼力的观点。

在这篇满怀浪漫主义色彩的文章中，孟岩指出了“工具”与“技术”的分野。得益于盗版软件的横行，微软的 Visual Basic（VB）和 Visual C++（VC）这些本来昂贵的开发工具，突然变成连大学生也能承受的几张光盘。这些工具极大地简化了带有图形界面的 Windows 应用程序的开发，很多企业和程序员都趋之若鹜：企业招聘时要求掌握 VC（以及其中使用的编程框架 MFC 和 ATL ），程序员把 VC 作为“梦想”。

而在读研期间深入学习了 C++、钻研了开源的 C++ 标准库 STL 的孟岩，对于当时业界只重视单一工具、单一厂商的风气颇有微词。在他看来，掌握一种工具只是软件开发最初级的门径，在这扇大门背后还有“设计模式的精美与一致，面向模式编程范式的初现端倪，面向对象软件工程的成熟与巨大希望，TAO/ACE 的庞大与精致”等“目不暇接的珍宝”。

对于这些现象，业内人士的一种普遍解读是中国民族软件产业遭遇了“软件危机”。例如 1997 年《上海微型计算机》杂志的一篇短文称，经过市场竞争的检验，许多专家已达成了共识：中国软件设计与生产的弊端在于技术环节不过关，社会化大生产尚未形成³。而应对软件危机的对策则是，亟需提高全行业的软件工程水平。为了理解这其中的逻辑，我们需要首先了解“软件危机”这个词的来由。中国科学院软件研究所王青研究员这样描述软件危机与软件工程的关系⁴：

20 世纪 60 年代，随着第三代计算机的产生，计算机的硬件性能发生了翻天覆地的变化，运行大型的复杂软件系统已经成为可能。然而，相应的软件开发技术却难以满足大型软件系统的开发需要，因而造成：

1. 大多数大型软件开发项目的成本都超过预算，开发进度一再拖延；
2. 软件产品质量不可靠，大型软件系统存在 Bug 几乎成为不可避免的问题；
3. 软件产品难以维护；
4. 软件产品的开发成本过高；
5. 软件产品开发的效率跟不上计算机硬件的发展以及用户需求的增长。

软件技术跟不上硬件技术发展而造成的诸多问题被称为软件危机（Software Crisis）。为了解决软件危机，1968 年在德国召开的国际学术会议上，北大西洋公约组织（NATO）的计算机科学家第一次提出了软件工程的概念，希望通过系统化、规范化、数量化等工程原则和方法来实现复杂软件系统的开发和维护。

按照 Wikipedia 词典中的定义，软件工程是“研究如何开发大型应用系统的计算机科学学科。软件工程不仅覆盖构建软件系统的相关技术层面问题，还包括诸如指导开发团队、安排进度以及预算等管理层面问题”。

由这个定义可以看出，软件工程不仅仅包括编写程序代码所涉及的技术，它包括所有对软件开发能够造成影响的问题。Brook⁵ 在 1987 年指出，不存在任何一个单一的开发技术或管理技术能够解决软件工程所面临的所有问题。因而软件工程是一个包括一系列概念、理论、模式、语言、方法以及工具的综合性学科。

这样一个大而全的一揽子解决方案，无疑给起步不久的中国软件业提供了宝贵的理论依据。

突然之间，一些令从业者困扰已久的问题，似乎都可以从软件工程的缺失上找到答案。例如有人问道：一般大家认为中国人才智过人，很适合搞软件，据说硅谷软件人员中三分之一是中国人，但是在国内却没有把中国人搞软件的智力优势发挥出来，即使有几个很有名气的程序员做了几个受到欢迎的产品（特别是中文产品），这些产品还是处于个体户经营状态，未能形成产业。

这是什么原因呢/strong>原来是少了软件工程：如今软件已从早期的程序概念上升到软件工程的概念，必须要按工程的规范来组织开发和生产，更多地强调标准和团队协调，并需要网络和工具的支持，那种靠个人才智打天下的时代已过去，中国软件发展必须走工程化、产业化、规范化和大团队的道路，将力量相对集中起来，将个人才智熔汇在群体之中，才能形成发展气势⁶。

从事后诸葛的角度来看，一个行业的发展，当然要靠自我奋斗，但是也要考虑到历史的行程。中国软件业新千年前后所短缺的，并不仅仅是如何开发大型应用系统的方法。

然而站在业内人士的角度，相比于宏观经济、国家政策、科技趋势等或许更重要的影响因素，方法论的缺失问题是从业者最有可能把控的。于是，软件工程缺失导致中国版软件危机，软件业振兴亟需软件工程，这一思路在 2000 年上下已经成为业内共识。在“软件工程”这顶大帽子之下，从业者们在积极探寻各种具体的方向。

对面向对象的美好冀望

面向对象（Object Orientation）是一种设计和开发软件的方法。

在计算机技术发展的早期，瑞士知名计算机科学家 Niklaus Wirth 对于“什么是程序”给出了一个明确的定义：程序 = 算法 + 数据结构⁷。面向对象方法的倡导者认为，初级水平的软件开发者会自然地用编程语言描述解决问题的过程（即算法），但经常会忽略被操作、被处理的对象（即数据结构）。当系统规模增大到一定程度，这种数据与操作的脱节会给软件的编写、维护和复用带来困难。

因此他们提议，应该将数据与操作放进同一个单元（即对象），系统的基本逻辑构建块不再是算法，而是对象。在这个理念基础上，发展出了面向对象编程（如何使用对象和类编写程序）、面向对象设计（如何分解和建模对象）、面向对象分析（如何用对象和类的概念分析需求）等一整套软件开发实践⁸。

国内高校和科研机构在 1990 年代就已经开始了对面向对象技术的研究。一般认为，面向对象方法突破了数据与操作的分离，较好地实现了数据的抽象和封装，体现了很好的信息隐藏特性，并以继承、消息传递等方式支持业务领域的概念抽象，因此能够提高软件的可复用性和可靠性，使软件更易理解和维护。在这些潜在收益中，“可复用性”这一条显得尤为诱人。

研究者们相信，给定一个业务领域，第一个面向对象的应用程序也许会比传统的应用程序难以设计，但一旦设计出来，以后的应用程序的设计就变得相对容易，因为以前所设计的对象是可以重复利用的⁹。这幅图景对于正在经历“软件危机”的从业者们而言，无疑是一个美好的应许。

不过落地到真实的软件开发活动中，情况远非如此乐观。要想在应用程序中使用别人开发的对象，开发应用程序的人也必须采用面向对象的编程技术，很多时候甚至必须使用同一种编程语言。

也就是说，虽然面向对象技术能通过对问题的分解更好地描述和组织系统中的复杂性，帮助软件开发者更有效地理解和开发复杂的软件系统，但其根本目的是为了使软件开发团队能够处理复杂度快速膨胀直至“超出人类智能范围”的复杂软件系统，并不必然降低对软件开发者的技能要求¹⁰。

而当时中国软件业面临的挑战不仅是需要越来越复杂的软件，同时能力过关的软件人才也相当匮乏。如果解决软件危机的必由路径是首先培养一大批具备面向对象软件开发能力的人才，听起来似乎是远水解不了近渴。

同时，C++ 等面向对象编程语言本身也并不足以完整解答软件复用相关的各种问题¹¹：如何选择和建立独立的组件件按什么方法组织起来对不同领域的特点，开发出来的软件系统能否有一个较固定通用的结构模型/p>

为了开发出真正可复用的软件单元，并且——更重要的是——为了大幅度降低使用这些软件单元的技能要求，一些研究者将眼光投向了组件（component，或称构件）的概念。例如 1997 年，武汉大学软件工程国家重点实验室这样描述基于构件的软件重用技术¹²：

构件软件强调以即插即用的方式重用不同开发人员的开发成果。基于构件库及构件组合的软件重用技术可以将软件开发活动分成两大部分：一是构件的设计与开发；二是构件的管理与重用。开发构件的活动与重用构件的活动不但在时间上和空间上可以互相分离，而且实施两者的主体也可以是完全不相关的开发人员。构件可以独立地进行开发，可以像软件系统那样成为独立的商品；构件的重用可以只是统一、灵活、简便地组合构件。

中科院院士杨芙清在 1998 年的一篇文章里将软件的生产与机械、建筑等传统行业进行了类比。在她看来，传统产业的发展，基本模式均是符合标准的零部件（构件）生产以及基于标准构件的产品生产（组装），这种模式是产业工程化、工业化的必由之路¹³。这是国内计算机学界较早将工程化、工业化理念引入软件产业的表述。

分享上面的《敏捷中国史》阅读卡片，跟朋友一起了解中国软件开发方法的进化和一代程序员自我突破的故事。

第3-1课　久旱甘霖：敏捷传入中国

当中国软件业满腔热情地向往“工业化”、“工程化”愿景，美国的制造业却在着眼快速、残酷与不确定的变化。对灵活性、响应性的追求，促成了敏捷在美国的诞生。万里之外的中国，也有一批年轻的 IT 从业者，受困于软件工程不能有效解决他们的实际问题，开始关注到敏捷，并在很短时间里翻译引进了敏捷的主要基础著作。

---

为侯捷举办的专家研讨会在《程序员》杂志社的二层小楼里进行。这是 2001 年 10 月，经营着 CSDN 网站和《程序员》杂志的百联美达美公司总共也只有 20 来人，控股的百联集团在位于北京亚运村西侧的利康饭店租了一栋独立的小楼，美达美和另一家公司共同在这里办公。这年夏天，北京成功申办 2008 年奥运会，利康饭店所在的这个位置正是未来奥运村的核心区域。7 年以后，这栋有些老旧的二层小楼将不复存在，在同一地点矗立着的将是被称为“鸟巢”的国家体育场。

第一次参加这种专家研讨会，旁听大家的发言，熊节感到有些费力、又非常兴奋。除了侯捷与孟岩等人围绕 C++ 的讨论让他大感兴趣之外，来自上海的王昕带来了一些新鲜的话题。王昕在 CSDN 论坛的账号是 “cber”，平日里在论坛发言相当尖锐，而且每每能跳出技术的框子，从业务和管理的角度给讨论引入一些新的观点。这天他跟熊节聊的话题就不完全是技术性的：

“你听说过 Refactoring 这个东西吗

“没有，”熊节连连摇头，“那是个什么来着

“是一种写出高质量代码的方法。你之前不是翻译过一系列关于设计模式的文章嘛！你看啊，设计模式社区的思路是，你先想好应该用哪些模式，然后照着模式的实现方式写出来，你的代码就是高内聚低耦合的。但是难就难在‘先想好’对吧

熊节点头。如何在开始编码之前先想好应该如何设计，这是他一直感到困难的一个点。之前孟岩与他讨论时曾经提醒他，“尽管当前软件界里几乎所有的人都为设计模式叫好，不过对于软件工程的发展方向，还是有不少批评意见的”。但这些批评意见是什么、对他熟悉的编程工作会产生什么影响，他并不了解。

“简单地说，Refactoring 这种技术，让你可以随时调整代码的结构，”王昕解释道，“把质量不好的代码修改好，在开发的过程中引入设计模式，那么你就不用担心一开始的设计做得不到位，可以一边编码一边完善设计。”

显然，这种看待制造业前景的视角，与当时的中国人，尤其是中国 IT 人对“制造业”的想象大相径庭。

在 2001 年前，只有少数研究者在关注相关话题，并且关注的视角是如何用 MRP II/ERP 等信息系统来管理敏捷企业⁴——此时 “Agile” 一词已经普遍地被翻译为“敏捷”。针对敏捷企业动态、开放的组织形态，当时上海交通大学计算机系有一组研究者致力于研究可以根据动态联盟的形成和解体而快速重构和调整的“敏捷供应链”，并提出“基于对象的软件代理技术”作为敏捷企业和敏捷供应链的技术支撑⁵。

现在回头来看，当时所谓的“软件代理技术”，尽管牵连谈到了人工智能等前沿技术，实际上真正成型的是构建在 CORBA 等中间件之上的一种企业信息集成技术，可以看作是后来更流行的 SOA（面向服务架构）的一种早期版本⁶。另外，诸如工作流等技术，因其可以加快供应链管理信息系统建设和调整的速度，也被视为敏捷供应链的支撑技术⁷。

简而言之，在 2001年之前，中国 IT 业内关于“敏捷”一词为数不多的应用，仅限于制造业的敏捷制造、敏捷供应链、敏捷企业概念，以及支撑这些概念的 IT 系统。至于软件本身的研发过程和软件组织的敏捷性，此时尚未进入到行业的视野中。

---

“Refactoring 这个词我知道的，”潘加宇说道，“我这里正好有一篇文章想请你翻译一下呢。”

“哦么文章熊节的好奇心被勾了起来。这是北京理工大学东门外的一家小餐馆，两人一边喝着小酒，一边聊着《程序员》和《非程序员》最近刊登的文章。从夏天开始，熊节连续翻译了十多篇关于设计模式的文章，在潘加宇办的《非程序员》电子杂志上发表。两人熟络起来，潘加宇每次到北京出差就会来理工大学请熊节吃顿饭。

“ Refactoring 是 eXtreme Programming 这种软件开发方法里面的一个实践，”潘加宇接着解释，“最近国外开始流行一类软件开发的方法，叫做敏捷，这个 eXtreme Programming 就是敏捷方法中的一种，简称 XP。我最近看到一篇文章，是讨论设计模式跟 XP 关系的，你要有兴趣的话，就看看这篇文章呗

晚上回到宿舍，熊节上网搜索关于 Refactoring、eXtreme Programming 和“敏捷”相关的资料，很快发现了一个叫 Martin Fowler 的人：这个大胡子美国人在 1999 年出版了一本题为 Refactoring 的书，好像还挺有影响力的。潘加宇塞过来的那篇文章，也是在谈 Refactoring 技术和设计模式之间的关系。联想到前两天和王昕的讨论，熊节感觉这本书貌似还真挺有意思的。

“正好明天杂志社要开选题会了，要不我就报这个选题好了。”一边这样想着，熊节拿出记事本，潦草地写下一行字：12 期技术专题：Refactoring。

在同一时期，另一些与极限编程相关的内容开始出现在中文互联网上。2001 年 10 月，IBM developerWorks 网站发表了厦门国际银行项目经理林星关于需求分析的文章，文中介绍了极限编程（当时林星将其译为“极端编程”）的核心价值观：沟通、简单、反馈、勇气⁸。

同样在 2001 年 12 月，浙江大学灵峰科技开发公司技术总监石一楹在 developerWorks 网站发表了 “Refactoring Patterns” 系列文章⁹，从较高层面概要介绍了重构技术的原理和实践原则。

除了重构以外，石一楹在文章提到的测试先行、结对编程等，都是极限编程的标志性实践。《非程序员》电子杂志于 2001 年 12 月邀请极限编程的创始人之一 Kent Beck 进行了在线交流¹⁰，又在 2002 年 1 月与 Martin Fowler 进行了在线交流¹¹。

在这些文献资料中，《非程序员》与 Kent Beck 的在线交流显得尤为有趣。发生在聊天室中、氛围轻松随意的交流，加上 Beck 直接犀利的言论（相比之下，Fowler 在交流中就显得更加字斟句酌、四平八稳），让这段文字记录成了一面镜子，清晰地映照出当时业界的情景。

Beck 在交流中提到，当时在极限编程的邮件列表中提及过 100 多个真实项目，他猜测全世界使用极限编程的软件项目不超过 1000 个。当时全世界有大约 20 个区域性的极限编程兴趣团体，主要在美国和欧洲，中国没有这样的团体。作为 1996 年才被发明出来、1999 年才有第一本著作的一种新的软件开发方法学，这个水平的热度并不意外。

Beck 对于极限编程的前景表达了谨慎的乐观态度。网友在交流中提到，众多主流的企业里，管理者们更倾向于使用重型的软件工程方法（例如 CMM ），因为这是更安全的选择。Beck 表示他相信，未来的软件组织会以频繁交付可工作的软件——而非严格定义的交付过程——作为关键的考核指标。

他期望 “50 年之内，许多极限编程实践被当做’只是以正确的方式做事情’接受”，这些实践包括了测试先行、重构、快速迭代交付、全功能团队等。由 “50 年”这个随口说出的数字来看，即使 Beck 自己，对于极限编程的传播也没有太多信心。

参考文献

1　（美）史蒂文·L.戈德曼（Steven L.Goldman）等著,杨开峰等译.灵捷竞争者与虚拟组织[M].辽宁教育出版社,1998:3.
刘刚.后福特制[M].中国财政经济出版社,2010.
（美）史蒂文·L.戈德曼（Steven L.Goldman）等著,杨开峰等译.灵捷竞争者与虚拟组织[M].辽宁教育出版社,1998:4.
4　张旭.敏捷企业与敏捷的管理信息系统[J].中国计算机用户,1997(13):6-8.
段永强,张申生,高国军.基于对象的软件代理的设计和实现[J].计算机工程,2000(05):21-22+25.
段永强,张申生,高国军.基于代理的软件设计和软件重用[J].计算机工程,2000(01):43-45.
刘建勋,张申生.工作流技术支持的敏捷供应链管理系统研究[J].计算机工程,2001(03):11-12+153.
林星.需求分析-软件和需求的实践[EB/OL].
石一楹.refactoring Patterns:第一部分[EB/OL].
0　《非程序员》第9期，Kent Beck：只是一种正确做事的方法
1　《非程序员》第10期，Martin Fowler访谈

---

J2EE 新趋势：没有 EJB

中立于厂商的、纯分享性质的线下技术交流活动，在中国软件行业里最初的发起者可能是 CSDN。

2002 年春节后，CSDN 与北京软件行业协会（BSIA）共同发起了“优程—CSDN 技术沙龙”线下活动。在一次较小规模的试水后，这个技术沙龙在随后三个月里先后邀请了微软、Borland、Sun 的技术布道师进行分享交流，不偏不倚覆盖了当时在应用软件开发技术领域最重要的三家厂商¹。

在此之前，软件业内的技术会议都是厂商赞助、以宣传厂商产品为主。CSDN 的创始人蒋涛在发起这个活动时，希望改变厂商导向的价值定位，立足于服务广大从业者、尤其是软件开发者，为他们提供中立客观、有实用价值的信息。

这种价值定位在 4 月发生的第 3 次技术沙龙中体现得淋漓尽致：尽管演讲嘉宾李维是 Borland 的技术布道师，却是从行业角度客观讨论程序员的职业发展，并不宣传 Borland 的产品，甚至提出“程序员应该正确认识自己的发展方向，而不要把注意力集中于某种语言或讨论工具的优劣上”的建议。

CSDN 技术沙龙在行业里开了一股新风气。在随后 CSDN 主办和协办的一系列活动里，这种受众导向的定位继续得到发扬，再加上邀请了如“C++ 之父” Bjarne Stroustrup 这种技术人员眼中的“大神”²，受到了从业者、尤其是技术人员的广泛青睐，也被其他组织效仿。

杭州的 ERPTAO 组织模仿 CSDN 技术沙龙的形式，在浙江大学举办了软件技术讲座，主题既有与敏捷方法相关的“重构思想”，也有纯技术性的 “O/R Mapping 技术”³——后者的主讲人是最早在 IBM developerWorks 网站上连载重构相关文章的石一楹，此时他关注的技术热点之一，是在企业应用中使用 Hibernate 作为 O/R Mapping 实现工具，从而避免使用 EJB。

1998 年，发明了 Java 技术的 Sun 公司将 JDK（Java 开发包）的版本升级到 1.2 版。这次升级伴随着大量的新特性、新方向，尤其是在标准 JDK 的基础上提供了支持企业应用开发和移动应用开发的大量工具和类库，是 Java 历史上一个重要的里程碑版本。

从这个版本起，Sun 公司将 Java 定位为一个“平台”（而不仅仅是一种编程语言），使用了新名称“Java 2 平台”，并将其分为三个主要分支：用于一般编程任务的标准版（Standard Edition，J2SE）、用于移动应用开发的微型版（Micro Edition，J2ME）以及用于企业应用开发的企业版（Enterprise Edition，J2EE）⁴。经过几年的发展，到 2003 年发布其 1.4 版本时， J2EE 已经成为行业信息化领域中最重要的技术平台。

J2EE 在行业信息化领域独领风骚的原因有几个。

首先，因为采用了虚拟机架构，Java 语言具有“一次编写、到处运行”的可移植性，因此生产系统可以在 Linux 服务器上运行，而不必绑定微软的 Windows，给了甲方更大的采购灵活性。其次，Java 语言与当时大学编程教学所用的 C 语言在语法上有很大相似之处，从业者学习门槛较低，掌握该语言的人数很多，给了乙方更大的人员灵活性。最后，J2EE 为企业级运算的许多领域设立了标准，促使各家应用服务器厂商基于标准提供常用的软件组件，从而缩短企业应用开发周期、提高程序员生产力⁵。

例如，如何访问数据库、如何编写 Web 应用的逻辑与界面呈现、如何集成企业中已有的若干软件系统，这些在行业信息化浪潮中普遍存在的问题在 J2EE 中都有现成的标准和工具可以解决，这就使软件开发团队更有信心选择 J2EE 来实施项目。

在 J2EE 的若干标准中，EJB 处于核心的地位。作为 Java 平台上的组件技术，EJB 又细分为三大类：Session Bean 用于承载企业应用的业务逻辑，Message Driven Bean 用于处理企业应用的多系统集成，Entity Bean 则用于处理数据库存取。

于是，在随后的几个月里，范凯在解道论坛发起了一系列更有针对性的讨论，用大量实证的论据阐述 EJB、尤其是 Entity Bean 本身的设计缺陷，以及 Hibernate 相比于 Entity Bean 的优势。

彭晨阳也积极地回应了这些讨论。两人间的讨论很快变得火药味十足，从技术的探讨延伸到了对个人专业能力的怀疑。大约在 9 月左右，彭晨阳删掉了范凯一批帖子，并单方面总结“这个争论本身实际是毫无意义的……在 Java 世界，之所以是百家争鸣，显得乱，但是不失去章法，关键是有标准……标准在 Java 中是主心骨，非常重要的地位”。

显然范凯并不认为这个争论是毫无意义的。被彭晨阳删帖之后，范凯自己开了一个论坛，这就是当时的 “Hibernate 中文站”、后来的 Java 视线（JavaEye）。

建站之初，范凯颇有所指地在一个帖子里说“在 Hibernate 中文论坛里面提出批评 Hibernate 的帖子，是不会被删除的……只有不遵守《论坛提问的智慧》的帖子才会被删”⁸。后来的 JavaEye 的确坚守了这一原则，一方面强调讨论的高质量、另一方面鼓励观点的多样性⁹，在业内名声很好。

分享上面的《敏捷中国史》阅读卡片，跟朋友一起了解中国软件开发方法的进化和一代程序员自我突破的故事。

结束语　敏捷中国：筚路蓝缕，以启山林

2018 年 5 月的银行业例行新闻发布会上，招商银行的 CIO 陈昆德骄傲地宣布，此前一年招行金融科技创新项目“从提出创意，到落地上线，平均周期仅 128 天”，并提出招行在未来三年要“真正实现科技敏捷和业务敏捷”。

这一事件在中国 IT 业的敏捷历程上堪称里程碑，因为这是一向以保守闻名的大银行 IT 首次明确地将“缩短响应周期”作为自己的成绩来宣传，而这一点正是敏捷的要义所在。可以说，陈昆德的这次宣讲，客观而坚实地明确了敏捷在当今中国 IT 行业的主流地位。

回望过去的十多年里，敏捷在中国走过的历程，可谓筚路蓝缕。

2001、2002 年，彼此互不相识的几组人，几乎不约而同地向中文世界引进与敏捷相关的资料。

《程序员》杂志在 2001 年 12 月专栏介绍重构、2002 年 3 月专栏介绍极限编程，是中文出版物中有案可查的最早的先行者。

2002 年 10 月，人民邮电出版社出版了《极限编程丛书》。

到 2003 年，《软件研发》杂志的创刊号大篇幅介绍敏捷方法，《重构》《敏捷软件开发》《自适应软件开发》等一系列重量级著作引进。今日的风起云涌，即肇始于当年的青萍之末。

然而在短暂的闪光之后，敏捷在中国陷入了长达数年的低谷。究其原因，敏捷所强调的快速迭代、持续交付，对于植根政府和大企业内部信息化、仰赖“十二金”工程哺育的尚处幼年的中国软件行业而言，是太过超前了。对于其时的行业环境与技术环境而言，每两周一次迭代、每次迭代发布上线给用户使用，既不可能、也不必要。那时的中国 IT 业，还没有做好迎接敏捷的准备。

决定性的转机发生在 2008 年前后。

通信行业遭遇前所未有的竞争压力，诺基亚、爱立信、华为、中兴等通信大厂积极开展敏捷转型，这几家公司培养出的大量优秀敏捷教练与持续集成专家，为后来敏捷在行业里的广泛传播起到了推波助澜的关键作用。

ThoughtWorks、优普丰等一批咨询公司，也在通信业的敏捷转型浪潮中获得了大量咨询顾问业务，在这些咨询项目中打磨出一批理论与实战兼备的敏捷传道士，为后来敏捷的蓬勃发展做好了人才储备。

几乎在同一时间段，Web 2.0 的创业热潮从硅谷传到中国，不论小型初创互联网企业，还是百度、腾讯、阿里（BAT）为代表的互联网大厂，都面临前所未有的机遇与挑战。

与通信企业不同，互联网企业与敏捷方法有更深的基因相似性。在缩短交付周期、加速用户反馈的天然诉求倒推之下，众多互联网团队几乎自发地采用了敏捷的关键实践。几年积累下来，短迭代、持续交付、DevOps 等实践逐渐成了行业中普遍认可的标准，将敏捷的边际向前拓展到业务、向后拓展到运营。

随着互联网、数字化对传统行业的冲击，互联网企业的工作方式也受到各行各业的重视，遂将敏捷带入了主流视野。

然而在其内核处，敏捷强调的“可工作的软件”对于配置管理、质量保障相关的技术实践要求甚高，对于在 IT 人才争夺中本就落于下风的传统企业而言，落地难度很大。众多企业只得退而求其次，从 Scrum 的管理实践入手，冀望首先提升需求管理和项目管理能力。

这个无奈的“退而求其次”，一方面使 Scrum 这种敏捷方法深入行业、并且形成一个活跃的社群，另一方面也引发了对于 Scrum 认证培训有效性的不同观点。在扩散和下渗过程中的内涵流失，最终在很多企业变成只见其形不见其神的呆板管理手段，似乎是各种先进管理方法在中国难以绕开的难题。

与敏捷的变革浪潮同步发生的，还有 IT 企业办公环境的变迁。从早年间的格子间，到日益流行的开放式办公室，IT 从业者在感受到自己日益被企业重视的同时，肩上的工作压力也在日益加重。几家互联网大厂与华为取得的辉煌成功不仅让行业找到了学习的标杆，也让 996 成为无须掩饰、甚至理直气壮的要求。除了加班之外，追求沟通效率的办公环境、无限便捷的通信工具、以及敏捷开发方法，也都是加重从业者压力的因素。

作为中国敏捷十余年发展历程的亲历者与推动者，透过敏捷被引进中国、被推介、被传播、被漠视、被抗拒、被接纳、被推崇、被转变、被淡化的过程，笔者看到了整个中国 IT 行业、乃至中国经济发展的缩影。

今天敏捷成为业内最为广泛采纳的软件开发方法，背后折射出的是 IT 在国民经济生活中的地位提升、是技术人员从外包码农到企业核心竞争力的地位提升、更是中国经济在全球经济中的地位提升。

随着中国 IT 业乃至中国经济在全球地位的提升，来自美国的敏捷软件开发方法一边被广泛接纳、一边也开始日益显出其局限性。未来中国的 IT 行业应该用什么方法来指导，将是历史的崭新一页。

畅聊技术历史与人生

我们希望订阅课程的朋友们可以一起把酒言敏捷，分享技术世界的一切趣事，畅聊各自的技术人生。《敏捷中国史》是普通 IT 人形塑历史的故事，也是永远不会完结的技术旅程。你可以将自己的想法发表在评论区，也可以加入《敏捷中国史》交流群，小到我们一起完善这部作品，大到共同创造未来更好的 IT 世界。（入群请加 GitChat 小助手伽利略的微信，ID 为 GitChatty6，注明「敏捷」。）

第1-1课　腾飞原点：2000 年，一个 IT 行业的春天

来源：蔚1