2006年，国内的一些科技大厂如腾讯、阿里先后向“敏捷”转型。人们看到了“敏捷”得天独厚的优势，从软件交付和维护、团队建设和管理到组织转型，为中国软件业打开了机遇之窗。
2017年，敏捷火了，成为了行业主流。俗话说“人红是非多”，传统的咨询行业、卖工具的、做培训的，无数人闻名而来，大量“伪敏捷”涌入软件行业，引发了不少负面。
无独有偶，在国际上“敏捷”也面临着同样的境地。这20年里究竟发生了什么？今天，我们一起来看看国内敏捷开发的艰难前行之路。
1 世纪之交的中国IT业
人物简介：
庄表伟，华为内源平台架构师，1997年毕业至今，始终战斗在编程的“第一线”，一直致力于推广并服务开源，热爱社区，热衷参与各种社区的交流活动。曾任盛大创新院高级研究员、印客网技术总监。
庄表伟从电脑前抬起头，左右活动自己僵硬的脖子，站起身来伸了个
这是2001年的9月，寂静的上海街道空无一人。
一年多以前跳槽加入这家公司的时候，老板给庄表伟描绘的是一幅关于互联网的宏伟蓝图。老板说，我们要做一个门户网站，给城市年轻人的网络门户，叫“My City”。老板说，只要我们把这个网站做出来，一定大受欢迎，我们有了流量，就可以去纳斯达克上市。
可惜，老板的纳斯达克梦，跟无数互联网创业者的纳斯达克梦一起，破碎了。到2000年下半年，公司的风险投资已经耗尽，门户网站创收也遥遥无期。
于是，老板把注意力更多地放在政府上网的项目上，终于接到了一个大单：上海市电子政务门户网站——“中国上海”。
还有几天就到国庆节了，这个网站必须在国庆节前上线，为国庆献礼。对这个时间节点，不管是客户、老板还是庄表伟的团队，大家既严阵以待，又满怀信心。
2000年，全国软件行业从业人数仅18万人，身处世纪之交的IT人，经历了政府“上网”给与IT的红利、企业信息化热潮以及电子商务的崛起。
他们隐约感觉到时代的召唤，他们渴望快速积累自己的能力，渴求传播分享技术知识的出版物和在线社区，当然，他们也在寻求一种更高效的开发模式。
与此同时，在大洋彼岸，一群IT人齐聚在滑雪度假村，他们商量着怎么克服软件危机、吐槽传统的瀑布流开发模式，推崇用做小事的小团队共同协作来做大事。
为了好记，他们给这个理念起了个名字——“敏捷”，并总结了4条“敏捷宣言”来规范行为。
2 中国版本的“软件危机”人物简介：
孟岩先生是数字资产研究院副院长、通证思维实验室发起人，全球最大的中文 IT 开发者社区 CSDN 副总裁，中国云体系联盟咨询专家、中关村区块链联盟专家。
从公司回到租住的小屋，孟岩打开电脑，拨号上网，习惯性地登录了CSDN论坛。2001年春天，一篇名为《VC不是梦想，C++需要自由的心》的文章，在CSDN火了。
文章率先用“梦想”“自由”这样的词汇来描述一种编程语言，指出掌握一种工具只是软件开发最初级的门径，在这扇大门背后还有“设计模式的精美与一致，面向模式编程范式的初现端倪，面向对象软件工程的成熟与巨大希望，TAO/ACE的庞大与精致‘等’目不暇接的珍宝”。
这极具开创性和震撼力的观点，让孟岩兴奋了一阵。
但当他每天清晨挤上开往浦东的公交车时，孟岩会清晰地认识到“我们都还是生活在现实世界中的人，精神上的快乐不足以填饱辘辘饥肠”。
他看到的还是粗放的、手工作坊式的工作方法：从需求分析到系统设计，到项目管理，再到发布流程，没有一件事是有章可循的，每个人都凭着自己在学校或之前工作的有限经验尽力完成任务，靠加班解决一切困难。
理想与现实的巨大反差让孟岩明白，即便学会使用先进的开发工具，掌握先进的编程语言，离顺利交付项目、开发出好的软件也还有一段很大的距离。
与20世纪60年代的美国一样，处于世纪之交的中国软件产业也遭遇了“软件危机”。
当软件技术跟不上硬件技术发展，当软件的旺盛需求与软件人才的相对短缺之间产生矛盾时，就会引发以下问题：
1. 大多数大型软件开发项目的成本都超过预算，开发进度一再拖延；
2. 软件产品质量不可靠，大型软件系统存在bug几乎成为不可避免的问题；
3. 软件产品难以维护；
4. 软件产品的开发成本过高；
5. 软件产品开发的效率跟不上计算机硬件的发展以及用户需求的增长。
软件业振兴亟须软件工程，这一思路在2000年上下已经成为业内共识。
3 未来的曙光
人物简介：
唐东铭，国内早期敏捷开发传播者，《解析极限编程——拥抱变化（Extreme Programing explained-Embrace Change）》一书的译者。
最近几个月里，唐东铭连续从几个渠道看到“极限编程”这个词，不禁让他生出了浓厚的兴趣。2002新年伊始，他又得知一个叫“敏捷中国”的网站新近发布，上去大体浏览一下，读了Martin Fowler和Kent Beck的几篇文章的译文，更添了几分对极限编程的好奇心。
看到一个运转良好的软件开发过程能给团队的效率和质量带来立竿见影的改变，让他对软件过程这个领域产生了浓厚的兴趣。
在这层兴趣的驱动之下，唐东铭在网上发现了名叫“PKSPIN”（北京软件过程改进社区）的线下组织，并很快加入其中。这个小组的成员几乎都是各家软件公司的项目管理者，好几个人跟程旭言一样，作为各自企业的SEPG成员推动着CMM认证工作。这些精力旺盛且又志趣相投的年轻人，每月都会组织一次聚会，以交流各自的学习心得。
在2001年之前，中国IT业内关于“敏捷”一词为数不多的应用，仅限于制造业的敏捷制造、敏捷供应链、敏捷企业概念，以及支撑这些概念的IT系统。至于软件本身的研发过程和软件组织的敏捷性，此时尚未进入行业的视野中。
不过，中国一些年轻的先行者已经通过网站、杂志、图书出版等形式完成了第一批敏捷基础材料的引进、本地化和传播，并在2003年陆续引进了包括《敏捷软件开发》、Highsmith的《自适应软件开发》、Fowler的《重构》等一批具有代表性的敏捷相关著作。
渴望知识与能力升级的中国软件业似乎已经敞开了胸怀，准备迎接敏捷带来的冲击与变革。
4 腾讯转型敏捷
2005年，腾讯员工由年初的1 100人激增至年底的2500人，翻了一倍多。在2006年，腾讯必须在不断下降的“每人每季度创造的收入”曲线上看到拐点。而当时腾讯对研发规范化、标准化、效能提升的目标，可选的路径不止一条。
其中一条显而易见的路径是模仿同城科技大厂华为，引入IPD模式。另一条路径则是敏捷，理论上敏捷方法更适合快节奏、直面用户的互联网企业，但如何在腾讯有效落地，内部的支持者同样缺乏信心。
在这个关键的分岔路口，ThoughtWorks于2006年11月给腾讯提供的一场敏捷入门培训可能成为影响天平的最后一颗砝码。这场培训脱胎于“ThoughtWorks大学”新员工入职培训的前两周课程，经过ThoughtWorks中国区的本地化和裁剪加工，最终压缩到3天，涵盖敏捷概述、迭代式开发、质量驱动的开发、需求及变更管理、迭代计划和管理、项目启动和迭代0、分布式敏捷、自动化Web测试等内容。
在为经过几年的实践，当时腾讯内部已经逐渐积累形成了一套比较成型的敏捷模型：采用特性驱动开发（Feature Driven Development，FDD）管理需求分析和建模，遵循Scrum研发过程，并结合极限编程的部分技术实践（主要是自动化测试和持续集成）。采用敏捷实践的团队在需求bug率、缺陷密度、bug遗漏率等指标上优于同类型其他产品团队，在开发效率、团队氛围、客户满意度等方面也取得了明显的提升。
腾讯在——或许有些偶然地——选择了敏捷的道路之后，再也没有回头。
2006年之后，百度、阿里、腾讯等互联网巨头相继尝试使用敏捷方法，并且从实际情况来看，成功的试点项目中不乏代码量上千万行、团队规模数百人、时间周期超过6个月的项目。
应用敏捷开发的企业
人们开始真正惊叹于敏捷管理思路的精妙，从软件交付和维护、团队建设和管理到敏捷落地与组织转型等。敏捷远远超过软件开发的范畴，同时深深的影响着他们的工作方式。
5 “变味”的敏捷
时间来到2012年，程旭言是公司的中层管理，他手里有个项目，已经确定了项目未来 6～12 个月所有的迭代和相应的用户故事。
项目开发过半，他意识到，如果一次迭代没能交付原计划中所有的用户故事点，就意味着开发团队需要在下一次迭代更努力地工作，以弥补上次的延迟交付。
正当程旭言为此发愁时，一位敏捷教练向他抛出了“救命稻草”。为了让软件能够更快交付，敏捷教练建议利用敏捷流程带来的充分透明性，对团队进行微观管理：
1.在每日站会上，开发人员必须向程旭言和敏捷教练汇报进展，详细说明自己正在做什么、什么时候能够完成。
2.不需要架构或设计，开发人员要求只管聚焦在产品待办列表中最高优先级的事项上，然后一个接一个尽可能快地完成。
3.如果管理者觉得开发人员浪费了太多时间在自动化测试、重构或结对编程等事情上，他们会直接叫团队停止这些实践。
虽然暂时解决了进度问题，但随之而来的技术债务让程旭言吃尽了苦头。
为了兑现承诺，他总是把团队逼得很紧，导致团队经常加班，尽管他会不时地自掏腰包请大伙吃饭来补偿，但团队士气并不高，流动性也比其他团队要大，大伙私下里都叫他“程扒皮”。项目交付后团队也会被各种质量问题缠身。
大型企业的敏捷转型无异于让“大象跳舞”。在敏捷转型上投入了几年时间与资源之后，这些公司意识到：他们以前存在的问题如今仍然存在。当然，他们把责任全都推到敏捷头上。
是开发者在远离敏捷，还是敏捷在远离开发者？答案似乎很明显。
敏捷“变味”，其中一个原因，是企业流于形式地追求敏捷认证：
2008年后国内兴起了Scrum Master认证，敏捷社区抱怨Scrum认证太容易获得，几乎参与认证课程的每个人都能拿到认证；成千上万的人获得CSM认证，却连Scrum最基本的规则都不知道。
然而企业对一个看得见摸得着的认证有着高涨的热情。试问一个中层管理者如何表现自己在行业大趋势面前有所作为？一个成本低（通常在5 000元以下）、耗时短（通常采用两天课程加线上考试的形式）、难度低（几乎不存在上了课考试不通过的情况）、知名度高（由敏捷宣言签署人、Scrum创始人发起）的认证完美回应了他们的诉求。
另一个重要的原因是，人们误解了敏捷。
敏捷只是一个框架，它可以帮助开发人员和管理人员进行务实的项目管理。但是，这种管理不是自动的，并不能保证让你做出恰当的决定。
在过去的20年里，原本简洁明了的敏捷概念已经变得含糊不清，精益、看板、LeSS、 SAFe、 现代化、技能提升……形形色色的概念都掺杂其中。这些掺杂进去的理念未必不好，但它们并不是敏捷原本的信息。
随着对技术能力逐渐失去关注，敏捷是否还能给软件项目带来显著的改善？敏捷是否还像当初《敏捷宣言》中所言，聚焦于身体力行同时帮助他人探寻更好的软件开发方法？
我不是很确定。
——Bob大叔
6 “去伪存真”的敏捷放眼国内，IT行业的劳动强度与工作压力似乎有越来越大的趋势。从“朝九晚五”，到“弹性工作制”，再到“996”，加班似乎已经被认为是IT行业的常规，并与“奋斗”“成长”等正面印象相关联。这种行业的舆论风气，再加上日益强大的通信工具，使从业者即使离开办公室也承受着工作的压力。
敏捷作为一种意在提升工作效率的软件开发方法，在减少加班、减轻劳动强度方面，似乎并未起到帮助，甚至可能因为迭代开发的广泛应用而导致全行业整体工作压力增大。此时的敏捷方法与2001年“敏捷宣言”中所描述的敏捷方法是否仍然抱持着价值观和理念的一致，恐怕起初的创始人们也需要重新审视了。
在距离敏捷宣言发布20个年头后，大家似乎遗忘了软件产品开发管理者应有的状态。而今，Bob大叔在《敏捷整洁之道：回归本源》中提出了“软件匠艺宣言”，给敏捷宣言加上了第五句——“匠心高于瞎写垃圾”( Craftsmanship over Crap)，而他的目的正是要为敏捷正本清源、清理门户。
有人认为，编程行业的新老更替开启了某种程度的黑暗时代。Bob大叔却深明其中的原因——整整30年，大家一直受困于“用大团队干大事”的观念，根本不知道成功的秘诀其实在于用很多小团队解决很多小问题。
你了解真正的敏捷是什么样子吗？
敏捷是将项目切分为迭代的过程。敏捷团队要测量每次迭代的输出，并用测量数据持续地评估时间表。他们按照业务价值排序来实施功能，以便优先实施最有价值的东西。他们尽可能地保持高质量，并主要通过变更范围来管理时间表。
那就是敏捷。
7 中国敏捷的未来
如果把软件开发当成一个谜题， 那么数代软件人在过去的50年里都在前赴后继地尝试解决这个谜题。迄今为止,全世界不管是码农还是码神，仍在这个谜题中痛苦挣扎。
而敏捷在中国十余年的发展历程，所经历的被推介、传播、漠视、抗拒、接纳、推崇、转变、淡化的过程，就像整个中国IT行业乃至中国经济发展的缩影。
中国用20年的时间迈过了西方50年的软件工程发展史。未来，“敏捷”之路该如何走，是每位编程人员值得思考的问题。我们不仅要回归敏捷的发展历史，更要有向前不断探索的精神，才能让“敏捷”成为更好的软件开发方式。
敏捷中国史话
作者： 熊节 ,虎头锤
《敏捷中国史话》用生动、翔实的语言，辅以情景描述，循序渐进地讲解了敏捷软件开发在中国的发展历程。本书从敏捷的发展背景讲起，延伸到描述世纪之交的中国软件业的发展状况、敏捷的传入、敏捷的低谷以及敏捷实践者为敏捷发展所做的艰苦奋斗，还介绍了敏捷在通信行业和互联网企业的实施状况、敏捷软件开发的发展和Scrum的流行。 本书既适合广大的敏捷方法的爱好者阅读，也适合对软件开发方法发展历程和对中国敏捷技术普及历史感兴趣的人员阅读。
敏捷整洁之道：回归本源
作者：[美] Robert C. Martin
译者：申健 何强 罗涛
《敏捷整洁之道：回归本源》首先概述敏捷的历史、敏捷的全貌；然后分析软件开发各角色之间的关系，说明敏捷出现的缘由；接下来分别讲解敏捷的业务实践、团队实践和技术实践；同时还介绍了成就敏捷的因素，其中还谈到敏捷转型中常见的问题与困难；最后提出软件匠艺理念。
-END-
