【摘要】虽然敏捷软件开发理念已为业界普遍接受，但敏捷的大规模落地应用仍然是一个非常大的挑战。敏捷开发模式的标准化是规模化应用的一个重要前提，很多组织和企业都已经在开展这方面的工作。市场的需求也催生出了如SAFe、LeSS这样的“规模化敏捷”框架，但本质上，规模化敏捷是一个伪命题，这样的“标准化”并没有帮助我们解决落地时的两个核心问题：即面向市场和商业模式变化的业务科技合作，及云时代的企业科技架构。
敏捷（Agile）是2001年由17位资深软件领域专家们一起发起的针对软件开发工作价值观的倡议。作为一种软件开发理念，与之伴随出现了很多实践框架和方法，如Scrum、Kanban和XP。而这些方法目前已经逐步成为了我们软件开发的事实标准，类似持续集成（ContinuousIntegration）这样10年前，被大家认为是“极限”的方法，现在也已经成了开发团队的一个标配。
值得一提的是很多开发组织里敏捷的大规模应用仍然是一个非常有挑战性的任务。软件自身的多样性和这个行业的高速发展，造成了敏捷方法落地的种种挑战。在过去10年时间里，笔者在这方面的咨询辅导工作或多或少跟适配团队和实践有关。相信在下一个10年，我们还需要持续去解决敏捷开发落地的问题。
市场的需求当然也催生出了一些所谓“规模化敏捷”框架，如SAFe和LeSS。很多需要解决敏捷大规模应用的组织，于是感觉有了框架和标准。也有很多企业，询问笔者支持什么样的规模化敏捷框架。
希望通过本文总结一下这两年来笔者所持续表达的观点：规模化敏捷是一个伪命题！所谓伪命题就是不要为一个不存在的问题，去寻找一把看似精美的战斧——敏捷这把锤子，遇到组织级灭霸，可能不好使了。
敏捷正走向生命周期的尽头
说这句话的时候笔者也带着一些伤感，这里并非是想哗众取宠地呐喊一句“敏捷已死”。敏捷作为一种开发理念，已经成为了现代软件开发的基础。然而，软件开发作为接下来这个数字化时代的基建行业，仍然有很多超越当年敏捷所谈及的事务。从时下爆款的区块链，我们就可以看到完全不一样的“开发团队”——形象代言人和挖矿小分队，都成为了这个开发团队里必不可少的成员。
什么标志着敏捷走向了生命周期的尽头？为什么不是持续演进成为敏捷2.0呢？
咨询行业对理念和方法的生命周期是有着最快感知和反馈的（如下图所示）。一旦一个理念和方法成为了事实标准，那么咨询公司需要做的事情就是体系化总结，通过标准化来帮助目标企业更快落地。一个我们都知道的案例，就是华为在IBM的帮助下，在上个世纪成功规模化应用了IPD。但即使有了华为这样的成功案例，IPD在后续中国企业落地时也是普遍失败的，原因是下一代的方法显然已经显现出了更大的优势。IPD有着完整的流程、方法和实践定义，当年的敏捷相比之下是混乱之极的，但仍然不可阻挡一波拥抱敏捷精神的互联网企业快速崛起。
（图示：开发方法随着行业成熟度提升而经历的生命周期。一种方法的成熟某种意义上只是为下一次创新做准备。当突变发生时，新方法将超越现行的主流方法，形成新的生命周期。）
当下的敏捷是何其相似！各大咨询公司蜂拥而至，都开始了“敏捷咨询”，资深的敏捷专家们开始总结大而全的框架，生怕遗漏了任何一个时髦概念——“价值流”大家都谈就加一个，“DevOps”火就先放里面。当你艳羡框架的完整时，往往需要警惕这个框架的时代价值，别忘了你做敏捷的初衷是什么？
在这个问题上，笔者在ThoughtWorks曾经纠结了好多年，每次有“写框架、卖咨询”的冲动时，都先后被老马（MartinFowler）和JimHighsmith这样的敏捷宣言签署者给拍了回来。确实也要感谢他们，能够站在行业发展的角度LetAgileGo。
早在10年前，华为给的命题是：用敏捷开发改造IPD。记得我们最后“成功”把大家痛恨的“软需”改造成了用户故事（UserStory），并构建起来了一条嵌入式系统的持续集成流水线。虽然现在看来，那是多么简单的任务，但当时大家还是激动地出了一本“葵花宝典”，记录了整个改造过程。听到这个名字大家可能都会笑而不语，XXX之后的IPD还是IPD吗？
同样的事情可能马上就会发生。有一天，中国的BATJ们可能会说：用XXX改造敏捷。笔者相信这个XXX不会是敏捷2.0，而我不希望成为那个在汇报中必须听到“敏捷改造成功”的管理者（即使团队写了另外一本“葵花宝典”）。
软件开发标准化的伤害
之前总是会顾忌得罪圈子里的老伙伴们，好在很多敏捷圈子的老一代们都已经去了各大知名企业做管理者（侧面印证了敏捷方法的成熟），敏捷顾问又是一波新人，所以今天才写这篇文章。再则最近几次关于AI的研讨和培训，着实让笔者觉得不能成为敏捷的“遗老遗少”，所以除了自省也希望鞭策更多的人。
企业里的很多管理者会说规模化敏捷框架至少给出了标准，让我们有章可循。很不幸的是这个“标准化”对目前的软件开发是有害的。标准化的基础在软件开发这个行业目前是不存在的，这个行业的基础知识积累还远不能支持有效的标准化，在未来很长一段时间软件开发都会是世界上最大的手工行业（可笑的现实~）。
谈标准化时我们必须跳出自身行业，看看别的成熟行业是怎么成功标准化的。程序员从心底是抵触“码农”这个可能未来的，所以暂且不说建筑行业。咱们看看临床医疗，算是一个标准化程度相当高的产业，但一个豪斯医生这样的天才也需要至少10年的培养，学习各个标准步骤；也没有人会写出《七天学会胆结石移除》或者《心脏起搏器的10种安装》这样的“速成”秘籍。从行业知识积累角度，临床已经是一个成熟的成年人，有着过去四五十代的知识积淀，尚且如此，何况软件开发仍然像个正在探索世界的小孩子，才经历了不超过四代人的知识积淀！
而显然，我们不应该以小孩子探索期得到的经验为依据，就开始进行行业范围大规模的标准化。CMM的失败在于软件学术业觉得软件开发就像算法论证一样，找到了nlog(n)的最佳算法就是普世的。但很可惜底层的运算环境，仍然会从单个冯诺依曼模型变成池化的云，再变成量子计算......
所以，让敏捷完成其历史使命，不要把敏捷标准化成另外一个CMM。软件开发行业需要下一个“敏捷”，下一个基于新知识积累的创新理念和方法！
不忘敏捷初心
当年的敏捷通过宣言的形式发表也是煞费苦心。在我们批判敏捷没有框架、没有标准的时候其实应该感谢17位参与者的克制和包容。我们很容易被自己十多年的经验所蒙蔽双眼，一边告诉别人要持续改进，一边却总认为自己这套是包治百病的。
他们的初心是值得学习的，我们每一代从业者都是在为这个行业的日益成熟积累经验。笔者经常拿开发和测试同事们开玩笑，“警告”他们未来不是成为“软件开发劳动力”，就是被AI所取代。但实际上软件开发的未来，包括职业的分工，都是一个未知数。持续学习的开放心态和着眼实践经验积累的学习方式，是软件开发在这个历史时代必须的。
另外一个值得提出的初心就是对软件开发“管理”的认知。由于软件开发并没有太多的先验知识，所以管理很多时候是会产生副作用；因为背后的标准并不具备普世性，随着生产工具的进步很快就成了畔脚石。用COBOL主机开发的方式去管理基于JavaScript的前端开发毫无疑问是偏执的。
这对我们的管理者提出了很高的要求，于是有一些企业高管开始要求全体管理者必须上手一线代码实践。当然这些做法都是不得已而为之，管理者的“初心”，是希望大家能深入理解这个年轻而高速发展的行业，直面缺乏标准化的现实，把自己日常的管理工作变成是去持续改进，做一个领导者，而不是所谓标准的监察者。
下一个“敏捷”长啥样？
那么，大家就会问下一个突破在哪里？未来的软件开发是什么样子的？很抱歉没有人可以准确预见发展的趋势，这个问题也可能不是大家目前最关心的。但既然写这个话题，笔者总还是要分享一些自己的思考，权且留作日后回顾的笑谈。
实际操作层面的标准化
随着老马即将出版的《重构第二版》，我们会发现实际代码层面的评判标准日益成熟。我们早已走过了代码能工作就是好的阶段，即使在过去最混乱的JavaScript领域（重构再版就是基于JavaScript的！）。在软件架构和代码结构方面，我们会逐步看到业界共识的质量标准。这两年基于GitHub等开源平台的兴盛为这个层面的标准化提供了契机。
当然这个层面的标准化也是最有可能被AI应用所颠覆的，毕竟全球最大的“手工业”必然会是AI技术应用最有利可图的行业之一。
行业层面的定制化
云已经是不争的软件开发基础设施，这样的水平切割已经形成了实际意义上的IaaS、PaaS和SaaS的分化。就笔者过去两年体验来说，各层软件在整个软件生命周期定义上还是存在明显差异的。比如构建一个IaaS层的基础服务，较之一个SaaS层的应用服务，在需求管理和发布上线领域就存在着显著不同。
在水平分层的基础上，我们越来越多地感受到了商业领域业务模式不同对软件开发的影响。前一段时间笔者写了一篇《银行业IT的敏捷转身》引起了行业的广泛关注，其原因就是金融行业在数字化时代越来越依赖软件，而从业人员发现他们的敏捷运用跟其它行业存在着很大不同。
这样的不同存在于方方面面，比如笔者经常挤兑同事吴雪峰的“抛弃型演进式架构”，也许在区块链这样的投机领域就是一个真命题。
在一横一纵的行业化背景下，软件开发本身还需要很多的经验积累，短期标准化的必要性不大。对于一些更为传统的产业，在中国也面领着“互联网+”的冲击，存在更多不确定性，尝试着去标准化一个定制的“XXX行业的规模化敏捷”模式，也可能是弊大于利的。
敏捷的规模化落地
希望看到这里你理解了为什么说“规模化敏捷”是一个伪命题。当大家在热议HBR关于敏捷的话题，认为敏捷就是真理的时候，需要理解我们现在的挑战是如何在一个大型开发组织里落地敏捷。而这个落地，不是靠套用一种“规模化敏捷”框架就能解决的。目前看，有这么三件事情是必须做的：
1.建立持续改进的内部力量
这是软件开发组织最重要的管理举措（没有之一）。在行业缺乏足够先验知识积淀的今天，作为从业者我们能做的，就是让组织持续积累经验，并且具备从经验中学习和改善的能力。如果说笔者希望参与一项标准化工作，那就是行业里对教练的标准化“定义”，因为我希望帮助整个行业明确这个角色或团队在组织里存在的必要性及重要性。
2.系统思考整个开发过程
软件开发不存在管理和技术的区分。由于立项、审计等多方面的传统制约因素，很多咨询公司人为地划分了所谓管理咨询和技术咨询，帮助刚开始合作的团队去理解如何落地敏捷。于是有了“只做管理”或“只关注技术”这样的说法。
事实上软件开发和很多工程制造业在这方面的差距是巨大的，即使Scrum这样的简单管理框架在落地时，也是受制于技术架构约束的；我们还没有办法让技术足够标准化，从而不约束管理。自从目睹了有人挥舞Kanban做“纯管理提升”产生的悲惨现场，再有任何团队说“这次只做管理”，我都坚决拒绝。
3.为创新建立安全试错环境
面对未知最好的方式就是探索，而探索意味着大多数时候都是失败的，毕竟从失败中我们学习到更多知识。很多组织和企业说我们一直在做啊，我们每年都会有创新项目，投资一两个小团队去做。这个数字化时代，软件行业的创新应该是中国改革开放式的，即使不能用“雨后春笋”这样的形容词，也应该是全员参与的。已经有很多的案例告诉大家为什么隔离出来一两个小团队“专职”创新是不可行的了。规模化创新意味着创新不仅仅是IT的事情，是组织各个部门、各个角色共同的愿景；也意味着我们承认创新是一个不停试错的领域，从错误中我们提升成功的可能（让统计学发挥作用）。
所以虽然笔者反对“规模化敏捷”，但我却站队了“规模化创新”！
最后，让我们摆正心态，让敏捷成为软件开发历史进程中的一块儿重要垫脚石；让我们持续探索，为软件开发领域的知识累积添砖加瓦，并共同期待新一代创新理念和方法的诞生！
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
