“敏捷”还有未来吗？

现在的社区和企业里有很多人刻意对敏捷这个词避而不谈，甚至嗤之以鼻。几年前开始，就有人在大喊着“敏捷已死”、“我们被敏捷耽误了”。一说讲敏捷，就像要给人洗脑，找人谈理想，或者像在讲一个梗。

几年前我合作过这么一家银行，他们的业务很不错，科技部门也非常与时俱进，很早就引入了各种敏捷开发方法来提升交付速度和价值，但领导一直觉得“敏捷”这个词不太好，对银行的管理来说显得不够稳妥，于是给自己内部的一套管理体系取了个新名字叫“精益研发”。

回想08年，当我从美国来的培训老师那里刚刚学习到敏捷开发，那些观点和方法让我耳目一新，过去软件项目中经常困扰自己的很多问题好像一下都找到了解药。才知道代码不是写完就不碰了，还需要重构；可以用脚本让琐碎的构建、部署和测试任务自动化起来；可以通过短迭代方式降低大型项目的交付风险；还有，我们和客户之间不只是买卖关系，更要一起协作，创造用户价值才是软件项目的真正目标，而非交付上线。

那一刻，如同一个长年受苦之人遇佛陀教诲，有醍醐灌顶之感。随着对敏捷更深入的学习研究，对它所传达出来的管理理念先进性我深信不疑，个人也从中获益良多。

如今，看到人们对敏捷的种种误解和否定，是有些痛心的。何以至此呢？

一、体质不合，导致了消化不良

敏捷的第一波坏名声出现在10年左右。敏捷宣言进入中国，开始广为流传，很快就成了一个在软件行业很时髦的词。因为时髦，一些兴致勃勃的leader们就开始在自己团队里用起来，大部分是一些缺少成熟管理经验的小公司。

他们听到的是，敏捷倡导尊重个体，信任团队，让他们自己管理自己，不提倡写文档，不需要什么流程，简直是人民当家做主了… 这些认知非常契合那些缺少管理经验的技术负责人内心的声音，终于有人站出来告诉世人他们不用被管理了。

当大伙儿在敏捷佛光的普照下大干特干了一段时间后，结果软件到处都是bug，一句话和随时都在变的需求搞得开发团队精疲力尽，相互指责，继而对新工作方法的失望、否定接踵而来。更尴尬的是，当管理层想要管控进度和风险，更深入干预团队运作时，一不小心就被扣上不信任团队，不敏捷的帽子。可当给予信任，做出来的东西却一团糟，想想这时的管理者有多讨厌敏捷这个词。

一些本就管理不善的小公司，以敏捷团队不需要管理来自我麻醉，心安理得。但是当结果和预期严重不符的时候，他们也是跳出来对敏捷批评最狠的，批评敏捷那些方法都是搞形式，或者太理想，不切实际，并不能真正让项目成功。多年以后，仍有很多人对敏捷的观感就是“缺乏管理”。这样的批评其实没错，如果敏捷就等同于每日站会、双周冲刺或持续集成这些方法的话。这些方法显然决定不了项目成败，产品好坏，甚至都算不上一个关键因素，更不能让一个团队变得更好。

但是，我想说，真正的敏捷并不是这样，敏捷团队恰恰呼唤更强的协作纪律，更出色的管理能力，或领导力。

一个团队，要想按自己的计划快速迭代产品，就需要更合理地划分组织和系统架构，降低耦合，不然就会经常被周边团队各种牵制；要想实现跨职能高效协作，就需要先解决产品、开发、测试各自目标或KPI的问题，光人坐在一起没用；团队要实现自组织，前提是需要赋能，让团队核心具备引领和激励众人的能力，且能够不断自省和改进，而不是在一个混乱低效的水平上不断冲刺。

若进一步透过形式看本质，敏捷诞生于硅谷工程师文化，它强调对个体的重视，是人本主义管理理念的代表，这与大多数国内企业强控制型的文化和一言堂的氛围格格不入。公司对个人强调执行，缺少赋能，团队不能根据自己的实际能力制定计划，大家漠视规则，随意变更，但又要求快，每一到两周就要交付一批需求上线，这导致团队持续加班，疲惫不堪。从个体的感知上，只有不断冲刺的要求，却没有个体尊重、人才成长和利益分享的激励，敏捷有时候就像是老板压榨员工的一套话术，变成了一个充满恶意的标签。

其实敏捷并非一味地追求“快”，“快”只是为了尽早获得反馈从而学习并做出调整的必要非充分条件，以此来降低投入风险；敏捷讲的“快”不是追求交付更多的特性，而是追求缩短一个Idea从提出到成为产品交付给用户的周期。如果团队一味追求交付更多功能，但用户并不认可，有什么用呢？

对敏捷理念的一知半解，加上领导者风格、组织设计、目标与考核、遗留系统架构、监管这些各种因素叠加在一起，很多团队采用敏捷方法就像是人误食了一顿不合体质的大餐，结果导致消化不良，浑身不舒服，最后归结为敏捷无用。

二、教条化的敏捷背离初心

上个世纪最后的20年，软件开发的复杂度变得越来越高，从以前的个人创作变成一种大规模的集体协作式生产，需要管理的团队规模越来越大，动辄几十上百人。彼时的软件项目失败率非常高，大幅延期、超支，或者成果远不及用户预期，案例比比皆是。

最初提出敏捷宣言的那群人，意识到软件开发活动的不确定性有别于传统生产制造的确定性，认为需要传递一种新的管理理念、一套新的价值观让软件项目能适应变化，减少失败。

一种管理理念需要有实操性才有意义，于是，在那个时间点，一些符合敏捷原则的、已经存在的实践方法，比如Scrum、极限编程，就被归入了敏捷开发方法的范畴。其实这些方法的产生比敏捷理念的提出更早。

敏捷理念和它的方法要有效，非常依赖于组织文化和团队能力成长，这先天特质就决定了它很难快速推广。一个传统企业要真正得以敏捷，这意味着一场深刻的组织变革，但又有几家公司能够轻易地掀起触及文化的变革呢？不过，每个科技组织都切切实实面临一些相似的痛点，比如经常被业务部门抱怨响应太慢、系统难用，它们都希望自己变得灵活敏捷，这种变革的现实需求是普遍存在而且迫切的。

这里让我想到了另外一种理念学说，在几千年前，它也是应人们普遍存在的现实需求而诞生：佛学。佛学和敏捷理念有着相似的发展过程。

在因战乱而饱受苦难的古印度，佛陀深感人间疾苦，参悟了如何解脱痛苦的方法，然后向世人传道。佛陀所传，都是一些艰深的思想训练和个人修行之法，并且允许人们通过辩论找到更好的方法。但显然这对个人的认知要求很高，天生就不利于在大众中传播。虽然世人想要解脱痛苦的需求普遍存在，但原始佛教在佛陀之后200年就已经接近消亡了。

一个转折点是，阿育王通过残酷战争统一印度后，为了稳固他的统治，宣称皈依佛法，开始大力弘扬。

可老百姓啊大字不识一个，如何能让艰深难懂的佛法广为传播，让人们都自愿放下武力一心向善呢？那就需要对佛陀之说做一些修改。比如不再允许辩论和质疑，推行一套“正法”；宣传只要广修佛塔、坚持施舍和放弃杀生就能积累福报，避免死后下地狱。再后来，为了方便佛法的传播，吸纳信徒，布道者们又想出了各种新的积福修行之法，比如给寺庙烧香上供，或拨弄一串佛珠重复地念一句“阿弥陀佛”，都可以让人得佛眷顾。

当得道之法被标准化，当佛陀的理念和那些用泥土堆砌、披着金箔的形象，和每天的念经、拜佛、烧香、上供活动绑定在一起，那一刻“信佛”就被具像化和简单化了。这确实非常有利于老百姓理解和执行。

最初的佛陀理念与神话无关，更不提倡个人崇拜。但从这时起，它开始以一种宗教的形态从印度迅速传向东亚和东南亚。要知道老百姓的需求可不只是摆脱痛苦这一点，后来，人们想要升官、发财、得子，都可以通过信佛来获得，佛的力量开始变得无所不能。以至于，今天已经没有多少人关心和理解佛陀真正的意图和信条是什么。

“敏捷”和“佛”都是很抽象的词，难以言说。但有一群聪明的人却从现实存在的企业痛点里看到了商机，那就是咨询公司。敏捷理念背后的管理哲学太难让每个人理解，对多数人来说显得虚无缥缈，或者这些机构自己也不甚理解。于是，在大量的宣传和咨询生意里，给企业做敏捷变革开始等同于引入Scrum、精益看板、持续集成这些方法套路，或是引入Scrum Master、敏捷教练这样的标准角色。这对于敏捷咨询服务的推广很奏效，看得见摸得着的流程方法更容易被企业买单。

敏捷的本意是通过快速迭代来适应客观存在的变化，从而有更大概率实现业务成功。它并没有固定的形式。一个很好的例子是国内互联网公司。

在互联网兴起后，这类企业一直都面临很激烈的竞争，不得不持续创新。互联网企业天生就有追求快和抓住用户心智的基因。当这些互联网团队取得成功的时候，他们会说：我们没有搞什么敏捷，但比那些搞了敏捷转型的公司更成功，说明敏捷那些东西没那么重要。

其实，当你打开他们的团队运作细看的话，会发现产品频繁地在发版迭代，而不是几个月上线一次；他们可能没有太多正式流程，但成功的团队内部总有一种行之有效的协作纪律和默契；他们非常重视从用户反馈中为产品的下个版本提供输入，甚至让用户直接参与设计…… 这些都是敏捷理念所倡导的，完全不同于曾经的传统软件厂商。只是他们很务实，没有给自己的工作方式取个好听的名字。

当敏捷这个词和各种标准化的方法绑定在一起，加上那些野蛮生长的互联网成功对敏捷套路的否定，在多数人的眼里，敏捷越来越成为形式化和教条化的代名词。

更糟糕的是，当那些想要进行变革的企业碰到难以改变的组织文化和管理惯性，像那些不信任的文化、复杂的管理层级、冗长的决策链路，于是，兜售“敏捷转型”的咨询公司开始聪明地将企业文化现实和标准敏捷方法揉在一起，创立了所谓的“大规模敏捷框架”，给了那些希望变革的高管一个看上去可以落地的大饼。

我并不是说这些框架是错的或无用的，毫无疑问它们对一些特定的企业很合身。但是，这不等于它适用于所有场景，不等于它就能代表敏捷。可遗憾的是，今天这些框架被当做更成熟、更体系化的敏捷方法被大量复制，很多非常昂贵的敏捷转型最后实际效果不好，甚至带来了更多混乱，导致研发效能下降。当它们和敏捷画上等号，就像把一只自由翱翔的苍鹰关进了笼子，让敏捷变得越来越异化，失去了生命力。就像被正统之后的佛法，离佛陀的初心越来越远。

敏捷不是银弹，每一种方法都有适用场景，就像你不会用一把瑞士军刀去做开颅手术。

敏捷提倡快速迭代和试错，但是要改造银行核心系统，牵一发动全身，那还是宁可适当瀑布一些，各种合规审计比需求变更更加凶残；如果团队还是一群新兵蛋子，刚工作两年的产品负责人自己都说不清楚排优先级的逻辑，这时候让团队“自组织”就像让小孩儿自己规划高考复习，手把手的指导和评审检查是不可少的；如果团队需要快速模仿那些领先在前面的竞争对手，这时候再一步步基于市场反馈去迭代，反而可能错失商机。

真正的高手应该像“海盗”，有一颗取胜的心，掌握如何解决问题的元方法，然后掠夺各门各派的精华，根据战场随时切换武器；或者像风清扬，心中有剑，而手中无剑，万物皆可为我所用。在环境多变的今天，致力于通过持续成长，打造高效能组织并取得可持续的业务成功，才是唯一的目标。

三、逐渐异化的敏捷圈子

在商业利益的驱动下，敏捷不但被逐渐形式化和教条化，还衍生出来各种敏捷认证，和批量生产的敏捷教练，导致这个圈子越发偏离初心，非常可惜。

什么是一个团队的教练？我认为就像引导他人开悟的布道师，像那些带领一支球队成长和获胜的球队教练，应该是一个团队不断自我突破、持续改进的引导者。教练，可以是一个专门角色，也可以只是一种技能，放在任何人身上。我认为，对于一个追求能力卓越的企业，最理想的状况是，公司里的各级管理者本身就是教练，以启发成长的态度来带领团队成功。当然，不是每一个人都有成为教练式领导的心态和潜能。如果目前这做不到，那就设置一些专注于引领团队持续改进的教练岗位。

今天，在那些培训机构，只要花钱上几天课就能拿到敏捷教练认证，但是对敏捷理念却一知半解，毫无实践经验。现实的团队管理是复杂的，当这些拿着认证的教练在团队里肤浅、错误地照本宣科，机械地套用各种方法，在被人挑战没用时还美其名曰“仪式感”，团队问题没有真正得到解决，甚至变得更加糟糕，结果只会加速更多人对敏捷的厌恶。

另一方面，过去十年里，随着敏捷这个词越来越没有新鲜感，那些曾经把敏捷视为灯塔的从业者开始出现各种分流。

一类人刻意回避敏捷，转向了DevOps、云原生、平台工程这类新概念，好提供新的服务。咨询圈子从来就不缺少造新概念的能力。你可以看到DevOps、DevSecOps、BizDevOps、BizDevSecOps......这类不断冒出来的buzz word，就像念咒语一样。

这些新概念代表行业在进步，时代在向前发展，我们也都应该与时俱进。只是，我们不应该被混淆视听，被告诉敏捷已经过时了。所有这些新概念并没有在管理理念上有本质的颠覆，只是在敏捷的底层原理基础上结合新的工程技术，实现了战术层面的进步。比如BizDevOps，不过是将早期敏捷主要针对科技团队内部的跨职能融合，延伸到了业务与科技的融合。

在人工智能爆发的今天，这些概念也不新了，已经成为明日黄花，人们又开始继续造下一波概念。

圈子里还有另外一类人，另辟蹊径，走上了灵修的道路。

可以理解这一趋势的内在动机。敏捷的核心价值观强调“个体”，而灵修之法，就像正念，正是注重人的内在状态、自我觉察和人际关系。敏捷提倡拥抱变化，而灵修往往帮助人们培养对不确定性的自我接纳，减少焦虑。当那些撬动组织变革的人面对质疑和阻力，需要应对各种冲突，灵修实践也许可以帮助他们提升情绪管理和同理心。健康的灵修实践对个体我认为是有帮助的，特别对于一些每天承受重压的企业管理者。

但是当从业者有意地把它和敏捷挂钩，比如在研讨敏捷开发的大会上安排一场莫名其妙的冥想活动；把公司里的管理层、敏捷教练们拉出去参加几天户外灵修研习班，敏捷在人们心里的形象就开始玄学化了。

敏捷理念的提出，是源自于集体软件生产面临的现实管理问题、工程问题，它提供的是一套原则和系统性的解决方案。存在高不确定性和复杂性的企业创新和研发管理过程，不是简单的“能量场”问题，更不是一味“向内求解”就能让问题消失。我们不能逃避现实，用“灵性”来掩盖自己无法解决的现实问题。

有不少咨询公司或企业里的敏捷教练，开始热衷于灵修，对如何提升自我、调整内在状态头头是道，但一面临实际的研发管理问题就束手无策。这就有点走偏了，让敏捷教练这个岗位在很多普通员工心里就很虚，很不接地气，很无用，在企业里也活不下去。

到这里总结一下，我的感受是，这么多年来，由于敏捷在企业落地时与组织环境的不匹配，本身的形式化、教条化、玄学化，以及被层出不穷的新概念抢走流量，敏捷看上去真的是岌岌可危。

那么敏捷这一概念在未来会消亡吗？

可能会，可能不会，我想说其实这一点都不重要。当初敏捷宣言诞生时出生的小孩儿，现在都已经进入职场，一代人过去了，一切都在变化，一再去纠结敏捷是否会消亡、有没有未来的问题就显得过于执念了。

如果当初佛陀之说在200年后就完全消亡，后世也一定会有其他学说继续研究摆脱苦或与苦共存的法门。因为人生即苦，这就是每个人永远会面临的痛点，或需求。佛陀想让人们找到摆脱苦的涅槃之法，他分享了自己的心得，这并无定法，更没有神话。但后世的人为了各自的利益给它附加了太多善巧和故事，让人眼花缭乱。

同样，实现敏捷本无定法，它只是一套管理原则，但从业者为了各自需要给它穿上了不同的衣裳，五颜六色。

真正追寻敏捷之路的人，追寻的是如何适应变化的能力。不仅仅是研发团队，个体和企业都处在一个永恒变化的世界中，都需要更灵活地去适应。软件开发、产品创新、企业的组织变革或业务战略都具有一个共同的特征：不确定性。那么对这些过程的管理，都需要一种相同的心态：拥抱变化；都需要一套相似的策略：试探，学习，然后调整；都需要锚定一个共同的目标：创造真正的价值。这样的心态、策略和目标，以及具体的执行之法，一定要叫敏捷吗？

今天，行业里卓越的软件研发团队可以做到新特性随时发布，每天几十次生产变更，用多变量测试方法随时根据用户反馈调优系统；领先的人工智能算法团队采用MLOps方法将模型的训练、测试、部署和监控过程流水线化，实现小时级模型迭代；一些处于激烈竞争中的企业，开始让客户经理、解决方案专家、技术负责人组成“铁三角”，共同面对客户，灵活决策，共担业务成功的责任；还有一些企业，大胆抛弃几十年来的年度预算制度，对业务进行季度或月度的滚动规划，目标或KPI也跟着动态调整，资源按需分配...... 这些其实都是敏捷精神在实践中的应用。

就像禅宗所言：“指月之指，非月本身”。敏捷本是指引我们理解复杂性、提升适应性的那根手指，而不是我们真正想要看到的月亮。

真正的赢家早已超越名词之争。也许未来一些行业专家或咨询公司会找到一个更好听的词来替代“敏捷“，又或许找不到，仍然时而用到它，这都不影响我们在这个”变是唯一不变“的世界中对个人和组织适应能力的永恒追求。