敏捷不是败了，是梦该醒了
The following article is from 大卫谈 Author 大卫张33
敏捷不是败了，是梦该醒了
1. 敏捷没有败，甚至还很成功
大量企业前赴后继的加入到敏捷转型中，组织对敏捷转型的投入还在持续增长中。敏捷这个词具有很强的行业影响力，大量咨询公司靠敏捷过活，如果你要在软件方面接单，不知道敏捷很容易被人鄙视，敏捷教练是极具招聘热度的热门岗位。大量软件开发人员开始学习敏捷实践，即便在实际的工作中用不起来。
Scrum依然是团队级敏捷的中流砥柱，SAFe领衔规模化敏捷。DevOps、数字化都与敏捷有直接关系，它们接过了敏捷的棒，继续流行，影响到了更多的人。
2. 不是敏捷败了，是敏捷造的梦败了
作为敏捷笃信者们的圣经，敏捷宣言制造了软件从业人员的幻梦，为软件从业者们描述了一个梦幻般的世界，如果我们能改变软件开发，我们就改变了世界。在这个新世界里，软件从业人员能够自主掌控软件开发的一切，世界会以我们为中心，被我们定义。他们把这称为敏捷起义，敏捷让管理者走开，敏捷是自组织的，软件从业者有了充分的自由。就像徐毅最初在诺基亚体会的梦幻般的敏捷一样，“回观自身，在诺基亚开始学习和实践敏捷是一种福气，但也是一种‘祸’，在后来的好些年里，我都无法理解本土企业里敏捷实践者所处的环境和所承受的压力。”（其实整个敏捷圈都误解并误用了自组织这个词，这在后来受到了复杂性科学家的挑战。）
敏捷宣言发布后，取得了远超敏捷宣言发起人们想象的成功，人们开始踊跃加入敏捷，敏捷软件开发也被证实，它真的有效。轰轰烈烈的敏捷运动开始了，大量软件从业者开始学习敏捷，自发的敏捷之旅席卷全球，我也受其影响，成为了敏捷之旅成都组织者，成为了敏捷之旅中国组织者的一员。越来越多的组织也开始接受敏捷，纷纷进行敏捷转型，敏捷专家们成为了企业的香饽饽和座上宾，敏捷教练大行其道。
但经历了轰轰烈烈的敏捷运动后，号召敏捷起义的人们才愕然发现，敏捷成功了，敏捷起义失败了。敏捷的确大获成功，但软件从业人员没能成为世界的主宰，他们甚至被他们想要推翻的人用他们自己发明的工具和口号压榨，敏捷宣言的初衷完全没有达成，这是何等可悲的现实。于是才有了这个感叹，“每个人都说他们采用了敏捷，但几乎没有人是敏捷的”。
3. 你很难唤醒一个装睡的人
在敏捷运动的井喷过程中，大量企业、人员涌入敏捷，敏捷相关的书籍、会议大量出现，新的敏捷方法实践层出不穷，企业组织纷纷开始敏捷转型。敏捷笃信者们欢呼雀跃，认为这是敏捷取得的巨大成功，敏捷起义很快就将席卷世界。很快，敏捷社区开始变得有利可图，咨询公司纷纷介入，实际上，包括敏捷宣言发起人们也各自开起了自己的敏捷咨询公司，大家开始为了敏捷的市场相互竞争，敏捷社区逐渐开始鱼龙混杂，商业化趋势明显。
但初始的话语权仍为敏捷笃信者们掌控，他们仍然想维持敏捷的初心，维持敏捷的纯粹性。他们说敏捷让管理者走开，不让团队自主管理的敏捷都是假敏捷，组织的文化价值观需要为了敏捷改变。他们说，迎合了管理者需要的规模化敏捷框架例如SAFe是假敏捷，是CMMI的复辟，PMO的反攻。他们认为敏捷转型，是因为他们进行的转型，是以他们为中心的转型。他们仍然说，不用TDD的敏捷都是假敏捷。
但市场并不那么在乎他们的声音。他们不管怎么正本清源，依然不能阻止SAFe成为最多企业采纳的规模化敏捷框架。绝大多数企业都在用没有TDD的敏捷，也没觉得有什么大不了。许多在进行敏捷转型的企业，其管理者甚至不能清晰说出敏捷是什么，但这并不妨碍他们进行敏捷转型。企业似乎更喜欢DevOps提供的工具和流程，胜过敏捷宣言提到的人与互动。许多人的敏捷，依然是要收集完所有需求、估算、排期，才能分迭代进行所谓的敏捷开发，软件开发人员依然被堆积如山的需求压到996.ICU。
最后他们发现，话语权没了，敏捷变样了，变成了管理层压榨员工的助攻手（编者注：当初敏捷是为了解放开发人员，最终成为剥削开发人员的、更加沉重的枷锁）。他们开始号召人们远离敏捷，称现在的敏捷是假敏捷、伪敏捷、黑暗敏捷，是做敏捷而并不真的是敏捷，是Scrum-but而不真的是Scrum，说敏捷已死、敏捷性长存，但无论怎么命名都无法改变话语权丧失的事实。就像Martin Fowler（17位敏捷宣言发起人之一）在其博客《2018年敏捷软件开发现状》中写的那样：“从表面上看，敏捷软件开发已经成为了主流，世界一片光明。但现实是令人不安的，因为其中大多都是假敏捷，无视敏捷的价值观和原则。”
敏捷幻梦，为什么会败？
误解1：敏捷全球大流行都是因为敏捷宣言
敏捷宣言是敏捷幻梦的根源，是软件从业者自嗨的源泉。敏捷笃信者们把敏捷的全球大流行归结于敏捷宣言的成功，归结于敏捷软件开发这一软件开发方法的优越性。特别是软件工程师，由于同样的背景（敏捷宣言发起人们都是软件工程师），他们更能认同敏捷宣言发起人们那无政府主义者的浪漫。
但敏捷运动的兴起，人们踊跃加入敏捷是因为这是更好的软件开发方法吗？从事后看，未必。敏捷以超乎想象的速度席卷全球，渗透并影响了除软件从业者之外的许多人，并不只是敏捷软件开发方法的成功。甚至有人说，敏捷宣言是软件界有史以来最好的营销。正如敏捷宣言发起人们在敏捷十周年的时候自己总结的那样，也许敏捷的成功是因为敏捷这个词太有煽动性，没有人不想自己敏捷，每个人都害怕自己被别人称作不敏捷。于是后来敏捷成为了软件开发中所有好实践的名字，每个实践、每个人都挂上敏捷的名号。就像极限编程从敏捷宣言发起时超80%的占有率快速降低到不到20%一样，人们并不是在真正追求更好的敏捷软件开发方法，而是渴望成为敏捷的一份子，他们可以毫不犹豫的抛弃了号称最好的敏捷软件开发方法，但依然认为自己是敏捷的，他们可以用了任何一个敏捷实践，然后宣称自己是敏捷的。市面上大量的图书也被冠以敏捷的名义，敏捷冠名的活动、会议纷纷出现，敏捷成为了热潮。
敏捷后来在企业界的大规模流行也不是因为敏捷宣言。而是管理咨询公司的介入，引进并炮制了业务敏捷的概念，并开始宣传敏捷转型。敏捷两个字的威力是如此之大，以至于管理者们都想在VUCA时代让自己的企业更加敏捷。这加深了敏捷笃信者们的误解，他们认为这全是敏捷软件开发的威力，你看，敏捷大流行就是因为我们的敏捷软件开发好。他们误会了，大量新的软件开发人员是因为公司的敏捷转型才知道的敏捷，而不是他们想象中软件开发人员主导的敏捷起义，许多软件开发人员甚至都没有读过敏捷宣言。
正是这种误解造成了敏捷笃信者们的笃信，敏捷宣言成为了他们的信仰。他们用敏捷宣言来正本清源，认为市面上充斥着假敏捷。
误解2：敏捷转型是软件开发的敏捷转型
敏捷转型是企业组织的敏捷转型，是企业组织希望自己变得更加敏捷的敏捷转型，企业组织希望通过敏捷转型获得自己想要的市场竞争力，获得自己想要的业务成功，这是管理者的真实期望。
但市场又给大家开了玩笑，由于只有软件开发的敏捷转型是相对成熟的，并且软件是企业组织更加敏捷的根本载体，所以敏捷转型往往被看做了软件开发的敏捷转型。大量企业在软件开发的敏捷转型上大额投入，但管理者们发现敏捷转型并不好搞。软件开发的敏捷转型让管理者走开，然后抱怨没有得到管理层足够的支持，抱怨我们软件开发敏捷了，组织并不敏捷，企业的中层管理层成为了最大的障碍，企业的文化价值观不支持敏捷转型，管理层的支持、文化价值观排在了多次敏捷状态报告中敏捷转型的障碍前列。各位自己想想，如果你们说的敏捷转型是敏捷起义的话，试想怎么可能得到管理者们的支持，让管理者们革自己的命，自己干掉自己的工作？
更何况，软件开发的敏捷转型并不能跟企业组织变得更敏捷、更有竞争力直接对齐，软件开发更关心交付，企业业务成功是管理者的职责。在这种错配下，管理者往往发现巨额的敏捷转型投入并不能带来他预期的业务成功，但软件从业者们似乎并不关注对齐这个问题，他们的答案是，你的敏捷实施不标准不到位，还有些好的敏捷实践没有引入，你需要继续在敏捷转型上投入。
误解3：只要技术好，没啥不能搞
技术人很推崇工程师文化，认为工程师可以搞定一切，这是软件工程师的浪漫，认为软件工程师发明的技术能够解决软件开发中的任何问题。因此，软件工程师有一个梦想，就是所有的问题都在软件开发这个封闭体系里面被解释、被解决，为此，他们发明了各种各样的方法和专业缩略语，把非技术人挡在门外。
但无论发明多少种方法，都不能解决两个问题，软件的输入问题和输出问题。到现在为止，软件需求优先级、估算、拆分需求问题无法在软件开发体系内完美解决。到现在为止，软件系统的业务成功无法在软件开发体系内完美解决，这导致了软件的度量难题。更不用说，软件开发团队的问题无法在软件开发体系内完美解决，虽然软件工程师们还在努力解决。甚至，软件的架构决策也不是单纯的技术问题，也不能只在软件开发体系完美解决。但软件开发被软件工程师们搞得过于专业了，发明了一系列只有专业人士才能交流的专业术语和缩略语，以至于他们不懂得用非技术人的语言来描述这些问题，很难与门外的人合作，最后他们发现软件专业出身的管理者才能有效驾驭软件，这助长了软件工程师的浪漫，果然，我们的问题只有我们自己人才能解决。
事实上，软件开发的关键决策往往来自非技术人。因此，非技术人如何有效理解技术，如何有效驾驭与技术相关的决策，成为了一个关键问题。
梦醒了，该怎么敏捷？
1. 敏捷转型，敏捷自己也要转型
敏捷号称能帮助软件适应变化，敏捷号称能帮助组织适应变化，那么敏捷自己能不能适应变化？就像Scrum三大支柱一样，透明、检视、适应。当我们不断维系敏捷起义的初心，不断用敏捷宣言来正本清源的时候，是不是也想想敏捷可否变化？而不是说SAFe是假敏捷，不用TDD的敏捷都是假敏捷，你们做的都是假敏捷。我们以为传递出来的信息是，原汁原味的敏捷才是正宗的，只有正宗的才好用。实际别人得到的信息是，敏捷是拒绝变化的。
当敏捷转型成为主流，当管理者积极加入敏捷，敏捷该怎么适应？是否继续用敌视的态度坚守敏捷让管理者走开？是否继续认为是管理者应该融入敏捷，而不是敏捷应该有任何改变和适应？也许至少应该做到积极拥抱他们，用他们的语言帮助他们理解敏捷，让他们对敏捷有把控力，让他们能够对敏捷转型的成功负责。
最终的敏捷为啥跟软件从业者的想法相去甚远，为啥成为新的压榨工具？敏捷大潮中，你不站出来引领，你成为了抗拒者，自然有人会站出来引领，引领敏捷去到一个你绝不想去的方向。
2. 识别敏捷幻梦，防止软件从业者的自嗨
企业组织的敏捷转型要的是整个系统变得更敏捷，而不只是软件敏捷。
需要防止软件从业者根深蒂固的误解，那就是敏捷转型是以软件从业者为中心的，敏捷转型的每件事情都要围着软件从业者转。真正需要做到的是，让更多人参与到敏捷转型中，让整个组织系统能够达成有效共识，一起围绕业务成功的目标，一起消除障碍，软件从业者也是敏捷转型的深度参与者，但不是敏捷转型的唯一中心。
防止敏捷转型无底洞的出现，避免陷入以软件敏捷为中心的无底洞、吞金兽、死循环。许多组织陷入了这样的死循环，把整个系统的敏捷等同于软件敏捷转型，大力投入软件开发的敏捷转型，发现达不到系统敏捷的效果，继续加强敏捷转型，继续加大软件敏捷转型的投入，可投入那么大系统敏捷的效果还是不明显，继续加大敏捷转型，继续加大软件敏捷转型的投入。
3. 管理者真正认识敏捷，真正从敏捷中获益
敏捷转型为啥离管理者的期望相去甚远。因为你不站出来引领，你成为了旁观者，自然有人会站出来引领，引领敏捷去到一个你绝不想去的方向。
敏捷需要管理者真正的参与，避免敏捷成为敏捷教练的敏捷，而管理者都成为了敏捷的旁观者。需要管理者把敏捷与业务成功有效关联，需要管理者能够理解业务决策与技术决策的关系，只有这样，管理者才能在敏捷的环境中依然做到对结果负责。管理者跟敏捷教练是深度绑定合作的关系，今天在跟某银行敏捷中心的负责人交流过程中，他们谈到了理想中的敏捷组织，管理者为结果负责，敏捷教练作为管理者的搭档，帮助管理者构建起敏捷的环境，推动敏捷的实施。
梦醒了，才能更好敏捷
这么多年过去了，敏捷两个字依然能打动人心。就像之前说的一样，在这个快速变化的VUCA时代，变得更加敏捷来更好适应变化、取得竞争优势，依然是每个组织的渴望。
以上是我对《敏捷20周年，一场失败的起义》和《敏捷败了，我没败》的回应，两篇文章的作者作为敏捷的代表性人物，看到了敏捷起义的失败，幻梦破碎的感觉并不好受。