敏捷软件开发方法自 2001 年传入中国以来，历经十多年的发展变迁，目前已经成为国内 IT 企业主流的研发管理方法。敏捷方法的传播和发展历程，是中国 IT 行业发展的剪影。CODING 特邀敏捷顾问、MBA，CSD 认证讲师、XP工程派敏捷领熊节老师将在《敏捷中国史》课程中通过大量史实材料，用技术史的研究方法纵览敏捷在中国的传播、发展、演化，从一个侧面呈现 IT 行业、业内领先企业和从业者的成长历程，为后来者留下理解这段历史的脉络。
大家好，今天我来为各位同学梳理一下敏捷进入中国的过程和发展。首先来看一下招商银行的一项数据。过去讲科技创新是一个很神秘的事情，不知道应该怎样去创新从而得到一个好项目，这个数据讲的就是可以通过大量的失败、大量的试错，从中发现有效的项目。我觉得招商银行是这么多年来在这个行业里对敏捷理解最深刻的一家企业，它真正做到了用敏捷的方式去改变整个经营和创新的思路。在 2018 年至 19 年这个节点上，一家中国的大型银行能用这样一个截然不同的思路去看问题，这是一个非常了不起的里程碑，标志着敏捷在中国取得了很大的成绩。那么站在这个节点我们回顾一下敏捷到底是怎样进入中国的。
最初敏捷在 2000 年左右进入中国时，就像播种一样，一些技术杂志把敏捷最初的思想播种到了行业里。中国的正式出版物首次刊载与敏捷软件开发相关的内容，是《程序员》杂志 2001 年 12 月刊，当时我在程序员杂志担任技术编辑，刚好做了“代码重构”的技术专题，可以说是无心插柳，当时从我个人的角度来说只是觉得敏捷这个内容非常有意义，并没有意识到之后会成为这么宏大的一个潮流。之后在 2002 年，我又做了“极限编程”技术专题，不知不觉跟敏捷结下了十几年的缘分。
中国的软件行业其实不是自然生长出来的，并不是说经济发展到一定程度就一定会有高科技行业自然发展，实际上中国的软件 IT 行业是由政治、政策催生的。2000 年以后，全国软件产业市场规模超过 1.3 万亿人民币，连续十年的年均复合增长率都达到了 40% 以上，这是一个非常可观的数据，而源头就是 2000 年 6 月国务院颁发的《鼓励软件产业和集成电路产业发展的若干政策》（国发 18 号文），这项政策里有非常多具体的鼓励、补贴内容，整个扶持了中国软件行业大发展。但是在这么大的扶持之下，整个行业并没有做好准备，没有足够的能力去消化如此大的需求，从而催生出了一系列问题，下图就是 2000 年时一位广东的官员调研得到的情况。当时广东省的政府信息化项目中已经出现了这些软件开发过程中常见的问题，这反映出当时整个行业的能力，包括个人和企业的能力都是不足的。当时专家认为出现这些问题是因为社会化大生产尚未形成，当然这种观念本身存在一定的问题，因为这是从工业制造业的角度引申出来的。
说到行业整体能力不足，也就是说“应该具备哪些能力”，2000 年左右 CMM（能力成熟度模型）引进中国时对这个问题给出了一个比较好的答案，CMM 二级-可重复级就很好的定义了一个软件开发团队应该具备的基本能力：需求管理、项目管理、配置管理、质量保障。需求管理就是需要弄明白要做什么；项目管理控制的是以适当的进度完成项目；配置管理解决的是软件如何一步步达到最终状态的问题；质量保障解决的是软件能否符合要求的问题。这几项就是软件开发中最核心、最基本的能力。
CMM 虽然提出了整个行业“应该具备哪些能力”，却一直没有解决如何具备这些能力的问题。当时国内一线的工作者迫切想解决如何用有效的方式来工作的问题，所以开始在网络上搜索国外同行们的经验。林星是国内比较早关注敏捷的同行，他 2001 年的文章《需求分析-软件和需求的实践》就是关于我们现在说的“用户故事”，也是从极限编程中抽取出来的。石一楹也是国内最早引进重构相关内容的同行，当时他在 IBM 网站上写了一系列质量非常高的文章，我本人对重构的了解就是从他这里得来的，因为受到他的影响，我在《程序员》杂志上做了相关介绍并在之后翻译了马丁·福勒的《重构》。《解析极限编程——拥抱变化》这本书是在 02 年引进的，北京当时有一个软件工程组织叫 PKSpin，唐东铭是这个小组的成员，他给人民邮电出版社推荐了这本书并进行了翻译。之后 03 年引进了《敏捷软件开发》这本书，并由中兴的工程师邓辉进行了翻译，同年 8 月我翻译的《重构》也引进了国内，那时我们认为关于敏捷的理论体系已经基本搭建完成，接下来就是国内行业去接受、学习的过程，因为之前做敏捷都处于一个非常混沌的状态，采用了敏捷实践之后软件开发过程中应该怎么做、怎样做出一个好的软件就非常清晰了，所以大家都觉得前景十分乐观，应该在三五年左右能全面实现敏捷，能力会有一个明显的提升，整个行业会有很好的成长。当然事后证明当时我们过于乐观，敏捷并没有那么快被广泛接纳。
现在回头看看敏捷是如何尝试解决 CMM 提出的软件开发四项能力的。敏捷归根结底是一个关于怎样管理需求的问题，是如何以一种迭代的、渐进的方式去交付软件的问题，它与瀑布式软件开发最根本的区别在于，当你认为需要采用敏捷开发时，所交付的软件不是六个月才交付一次，而是以更小的粒度去交付。敏捷的一系列内容都是从需求管理开始，它改变了我们看待需求的方式，需求不再是一个大头，而是由很多小块组成。接下来就是项目管理，当我们希望需求以一种小颗粒的形式去逐渐交付时，接下来受影响的就是如何管理项目的问题，项目的整个生命周期都会改变，它不再像以前一样两个月分析、两个月设计、两个月编码，而是会完全变成快速的短迭代，不断生产出可用的软件，所以我们看待整个项目生命周期的方式会发生变化，会以迭代的周期来管理项目。接下来受冲击的就是配置管理的方式，配置管理讲的是软件如何被修改的问题：谁在什么时候以什么方式修改软件、如何提交修改、如何把修改分享给整个团队、如何把源代码变成可用的软件等等。因为我们的目的是要快速、频繁的交付可用的软件，那么配置管理一定会发生根本性的变化，会变成一种持续集成的方式，即每天、每个小时都在不断地集成可用的软件。于是紧接着会影响质量保证的方式，因为团队在不断的生产软件并且希望软件是随时可用的，所以不可能像以前一样整个项目做几次集中的人肉测试，必须加入大量自动化测试，确保每天、每个小时测试都在运行，确保软件始终处于一个良好健康的状态。所以没有大量的、可靠的、快速的测试用例，就一定是伪敏捷，这是一个非常容易判断的标准。
其实中国软件业当时并没有做好准备去迎接敏捷。一方面，在“18 号文”的政策引导下，政企信息化占据了很大市场比重，而这类项目预算周期长、用户话语权低，快速迭代式交付既不可能、也不必要。另一方面，被政府补贴快速加温的 CMM 认证市场乱象丛生，咨询、评估、政策补贴形成完整利益输送链，对于业界软件工程能力的提升效果并不明显。2006 年马丁·福勒在中国软博会做了一个演讲，说到给某投资银行做的项目，通过迭代式开发，两个月时已经有部分功能可以让用户使用，而且为客户带来了真正的经济效益，整个项目所有的投资在这一部分功能上线后的几个星期就收回来了。这个观念在当时的中国软件行业里是非常陌生的，一些学院派的软件工程专家认为中国软件业的现状大概落后于美国 20 年，这个观点我认同，但是他们认为补齐差距的办法是软件学院的教育应该更正规化，学习正统的软件工程，所谓学习“正楷”，也就是研究 CMM。这个观念事后证明是一个完全错误的选择。同时一些民间的草根社区也在积极活动推行敏捷，虽然不受主流待见。06 年左右草根社区开始逐渐汇集力量，连续开展了两年“敏捷中国”开发者大会并建立了线上社区。
直到 07、08 年环境逐渐有了一些转变。第一个方面，我个人认为中国的互联网行业大发展，与美国一些网络企业被排除出中国是有很大关系的，这里不谈争议，就当时的情况来说，国内的互联网企业比如 BAT，都还处于比较早期的阶段，如果这些巨头没有被排除出去，国内很可能不会有那么大的市场空间，所以至少从国内互联网行业的发展来说是创造了一个机遇。另一方面跟移动互联网的高速发展也密切相关，华为作为一家设备制造商在当时也开始感受到来自同行，比如诺基亚的压力，发觉以流程为中心很难应对不以公司为导向的市场环境，于是在 04 年开始研究敏捷，并在 2007 年下半年全面展开研究，08 年初开始全面进入试点阶段。而诺基亚当时在杭州的研发中心开展了一个试点项目，就是引入了 Scrum，尝试敏捷的做法，这个试点项目培养出了许多后来对中国敏捷社区产生巨大影响的人物，比如吕毅、徐毅、申健等等。所以之前提到的中国的极限编程这一分支，很大程度上是从民间生长起来的；而 Scrum 这一分支，基本上是从诺基亚这一项目传承下来的。还有一方面就是通信企业和互联网企业的大发展，开始有敏捷的诉求。06 年左右腾讯的研发规模开始膨胀，开发模式急需规范和标准化，在 IPD（集成产品开发）-CMM 和敏捷间摇摆不定，后来腾讯的研发管理部开始与 ThoughtWorks 公司接触，在参加了一次 3 天的敏捷入门培训后，决定沿着敏捷这条路向前走。历史充满了偶然性，在一些重要的节点上，其实并不清楚关键的决策者到底是受到了什么影响，最后把腾讯带到了敏捷的方向上。而阿里也紧跟其后，大概在 08、09 年左右开始试点敏捷，并且证明了技术的根基对于敏捷的实施非常重要。我调研过钉钉这个团队在当时是如何实施敏捷的，他们团队当时取得了比较好的效果，一个很重要的原因就是自行开发自动化测试，这就又回到前面讲的观点，判断一个团队到底是不是有效的敏捷，就是看有没有大量的、可靠的、快速的自动化测试。钉钉团队成功实施敏捷很大程度上得益于极强的技术能力，我认为这种能力在行业里是一个重要分水岭，有很多企业想学习敏捷，但最后都止步于没有过硬的技术能力，想要进行自动化测试、持续集成、重构都没有能力。一些能力不足的项目组长或者 QA（Quality Assurance）不知道如何操作，这时出现的 Scrum 联盟提供了一个学习考证机会，通过学习 3355 等课程获得 Scrum Master 认证，这些内容给他们的焦虑找到了一个非常好的出口，但其实敏捷的真伪最终还是要归结到基础的技术能力上。
时间来到 2015 年前后，敏捷在国内开始进入收获的季节。2016 年度中国软件开发者白皮书中统计有 64% 的团队使用了敏捷管理工具，当然这里不是指已经有 64% 的团队开始实践敏捷，只是可以理解为有六成的团队认为宣称自己使用了敏捷管理工具是一件有面子的事情。阿里云栖社区在 2017 年发布的数据中，45.6% 的团队在规模流程模式上采用了 Scrum 敏捷开发，同理也可以理解为有更多人认为 Scrum 敏捷开发是好的。这种数据描述的是一种观念，表达了当时的行业从业者怎样看待这些理念，反应的是一种认可。
15 年之后在敏捷的基础上又有了很多发展，当然国际和国内要分开来看。在美国、澳洲发展的脉络是开始思考软件架构怎样可以更适合小团队（微服务设计），怎样让软件的生命周期更加完善（DevOps），怎样将敏捷的快速反馈机制向上延伸到业务（精益、持续交付）等等。而在中国则出现了一些变体，因为国内行业不具备这些能力，在最开始没有打好基础，08、09 年一些企业实施的敏捷其实是在“补课”，虽然有一些成效但远远没有到位，变成了中国特色敏捷。由于没有到位，只好换个名目再立项，摇身一变成微服务，再过一年变成 DevOps，之后又叫精益，结果实际上每年做的都是同样的事情，还在做最基本的用户故事、持续集成、自动化测试等等内容。一个行业在刚开始发展时，因为规模还不大，全面提升行业能力比较容易，这样也利于以后的发展，但是中国软件业在刚开始起步的时候没有做到这一点，规模却越来越大，同行全凭本能在工作，没有套路和方法，一些大型企业和项目全部陷在泥潭里，人人都在加班又解决不了问题，那么既然解决不了问题，就解决提问题的人，于是 Scrum Master 应运而生。正常逻辑应该是代码写的不好就提升自身能力写好代码，Scrum Master 就是引导团队成员，给成员赋能，虽然能力依然没有提升，不过至少起到了心理安慰的作用，在泥潭中也要和自己友好相处嘛。
虽然前面说的有点丧，但这么多年来敏捷对中国的软件行业也有很大的贡献，比如对办公环境就有明显的影响。03 年左右我们的办公环境其实是非常糟糕的，都是廉价的隔板和座椅以及很小的空间，而现在可以看到越来越多的企业采用了开放式的办公环境，更加人性化，同事间会有更多的交流机会，这是正向的影响。
另一方面就要说到加班的问题。我采访过很多人，大多都认为跟 18 年前相比现在加班更严重，虽然从数据上来看加班的小时数并不算多，但实际上压力比以前更大。一个原因是有更多的通讯工具去控制大家的工作时间，比如说钉钉、腾讯会议、企业微信等；另一个原因我认为跟敏捷有很大关系，就是对任务更细的拆分、更细粒度的有效把控加大了劳动强度，这其实是一个不好的方向，违背了敏捷价值观。
最后说点题外话，去年可口可乐有一个项目也想用敏捷这种迭代的、快速反馈的方式去研发新的饮料，所以敏捷以后一定会延展至其他行业领域，同时它的边界也会越来越宽，内涵变得越来越稀薄，可能最后会模糊敏捷的定义，现在已经逐渐有这种趋势，人人都在说敏捷。我依然坚定地认为狭义的敏捷软件开发有明确的边界，至少需要拥有大量的、可靠的、快速的自动化测试套件才是真的敏捷。
