现在回头看看敏捷是如何尝试解决 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 认证，这些内容给他们的焦虑找到了一个非常好的出口，但其实敏捷的真伪最终还是要归结到基础的技术能力上。