敏捷开发为何在中国难落地？

Posted 2021-04-25 敏捷之美

本文约3100字，建议阅读8分钟。

敏捷开发在国内难以落地基本上已经是行业共识了。有些公司花费重金请来“敏捷培训/咨询师”给自己的团队做指导，或送员工去参加敏捷培训班，期望使自己的团队“变得敏捷”，但是最终他们却发现自己学到的只是一堆形式主义的东西，无尽的会议和流程，生产效率不但没有提升反而降低了，团队士气也相应受挫。

另有一些公司，对敏捷开发总是表现出拒绝的态度，他们经常会说：“敏捷开发对人的要求很高的，我们公司/团队的人达不到要求”；“这一套就是老外搞出来忽悠人的，中国的国情不一样，在这里不适用”；“这些东西都是虚的，我们需要实际能解决问题的方案，这样才能带来价值”……

国内已经“敏捷”了，或正在“敏捷”努力中的企业，往往是行业领先的公司，如微信、腾讯、淘宝、京东、华为、通用电气、百度等。那么为什么大多数中国企业会对敏捷“水土不服”呢？

前段时间我翻译了一篇文章，《Scrum在亚洲难以实行》（详见“阅读原文”），文章讲得很好，主要列举了四个原因：

1. 亚洲文化中等级观念根深蒂固，人们习惯于遵循体制，与敏捷思想中的“自我组织”、“自我管理”背道而驰。

2. 亚洲人好面子，讲究和谐第一，很难像西方人一样坦率直白地交流，造成了沟通障碍。

3. 亚洲的教育思想排斥犯错，教育出来的人都怕犯错，很难理解敏捷思想里的“快速试错”理念。

4. 亚洲的软件开发是从外包起步的，习惯于节约成本，而想要学会敏捷开发往往需要投入额外的时间与金钱。

这四点刚好切中了要害，精确地概括了敏捷在亚洲难以落地的主要原因。今天，我想就个人一点不成熟的观察和体验，分析一下除了上面这四点，还有哪些具体因素导致敏捷开发在中国接不上“地气”。

勤于苦干，懒于思考

在国内，绝大部分公司都还没有认识到软件开发是一项知识性工作，普遍对软件开发的理解还很肤浅，以为可以通过加人、加班来加快软件开发的进度。更悲催的是，很多员工自己也没有认识到这一点，每当问到为什么项目进度落后的时候，他们的反应总是抱怨“人手不够”，而提出的解决方案就是“加班”。这种意图使用蛮力来达到目标的行为，恰恰体现出了国内不少软件开发人员的一大特点——“勤于苦干，懒于思考”。

如果一名员工完不成计划中的工作，第一反应总是想通过“加人”、“加班”来解决问题，那么他必然很少去思考如何通过改进自己的工作方法来提高效率。比如有人写出的代码总是有各种各样的问题，宁愿去加班加点反复改bug，也不愿意尝试多写单元测试提高代码质量；又比如不会调整任务优先级合理安排工作的人，不但自己长期加班，还不断向领导反映工作量太大要求加人。他们看似在勤奋地工作，实则是懒得动脑筋思考如何利用最小投入达到最大的产出，而后者才是一名优秀的知识工作者必须具备的素质。

 加班是必需还是“借口”，这是个问题……

在几十年前，管理学泰斗彼得·德鲁克就建议把知识工作者与劳动工作者区别开来，因为两者的工作性质是截然不同的。在劳动密集型企业的制造工厂里，你可以建立一条生产流水线，然后工人经过简单培训就可以上岗，就能生产出合格的产品，甚至可以通过延长工人的工作时间来获得更多产出，就像《摩登时代》里演的那样。

然而这个套路在知识性工作中是行不通的，你不可能指望把软件工程师放到流水线上就能产出高质量的软件产品。劳动工作者只需要正确地做事，而知识工作者需要做正确的事，还要做得更好。为了达到这个目的，知识工作者需要不断地学习、思考，开拓自己的思维，磨练自己的技术，提高自己的效率，改进自己的工作方法，精益求精……我们常常提到的“Kaizen（改善）”、“持续改进”，都是属于精益生产的范畴，也是敏捷开发的精要所在。所以如果想要敏捷开发落地，我们需要的不是勤于做事的员工，而是勤于思考的员工，因为他们才能创造更多的价值。

图中日文：“随时思考如何做到通过最小努力获得最大价值”

可惜在国内，除了少数互联网科技公司里的高级人才，大部分人还是更倾向于采用蛮力去解决问题，特别是底层的小公司。而在最近几年的全民创业大潮中也出现了一大批缺乏管理能力的老板，他们没有办法分辨员工的工作价值，只能通过工作时间长短来判断员工的“工作态度”。于是两边一拍即合，员工采取自己习惯的方式工作，不用思考，“加班”就好，还能博得老板欢心，收获勤奋刻苦的口碑，何乐而不为？老板也乐于见到员工下班以后自觉加班，有“奉献精神”的一定是好员工，还可以以他为榜样，要求更多员工加班。

崇尚技术，轻视方法

在国内，如果要形容一个程序员很牛，必然是说他懂得多少尖端技术，会哪些语言，参与了哪些项目……如果你跟人讲你了解敏捷开发的理念，精通哪些方法论，知道什么流程应该如何改进，不出意外你得到的反馈就是：“那些都是虚的，你懂哪些实实在在的技术？”或者引用Linus Torvalds的名言：“Talk is cheap，show me the code。”

这就尴尬了，在国内很多程序员眼里，技术的地位已经被无限拔高，甚至成了一种社会地位的衡量标准：你懂的技术多=你是牛人=你讲的话就是对的；（我懂的）这个技术你都不懂=你不如我=你讲的话我为什么要听？又或者成了一种解决问题的万能钥匙：这个版本的产品质量不好，是因为现在这个技术已经过时了，下个版本我们换种新技术。遇到什么问题都归因于技术，总是寻求换新技术以期望能解决问题，而不是真真正正踏踏实实去解决眼前的工作方法问题，已经成为国内程序员群体中一个普遍存在的现象。

我曾经在一家创业小公司见过这样的程序员，工作中写代码大部分靠百度加copy/paste，写出来的代码重复率可以达到60%多，做出来的产品呢，比起说他在专心写代码我宁愿相信他在专心写bug。即使是这样，当你要求他写完之后自己测试一下他都是表示拒绝的，理直气壮地说：“开发都测了还要测试干嘛？”每个版本发布基本上都可以听到他说：“这个版本只能这样了，下个版本我换个框架就好了。”像这样的程序员你很难相信他会主动去写单元测试，去实践TDD，去接受敏捷开发的各种理念，而这种程序员并不在少数。

急功近利，肆意浪费

我们都知道无论是敏捷开发还是精益创业里面都强调的一个原则是：通过不断地快速试错来做正确的事情。精益创业里提出的最小化可行产品（MVP，minimum viable product）就是这一点的充分体现——通过开发最小化可行产品，以最低的成本来达到快速试错的目的，找到一条正确的道路，最终做出符合用户期望的产品。

然而在国内这几年的创业浪潮中，一批批的创业公司出现，又一批批地死掉。仔细分析这些“昙花一现”的公司就会发现，它们的模式都很相似：一个点子加PPT就能拉来投资，然后招几个培训班速成的开发人员，按照需求说明书做出产品，然后继续拉风投，继续招人……直到哪天融不到钱了，资金链断裂，就作鸟兽散。CEO拍拍屁股走人，也没有任何损失，继续去开下一家公司。对他们来说，做一款产品几乎没有任何成本，失败也就失败了，根本不需要什么MVP试错，直接用产品试错好了。

在这种环境下，不会有人关注什么产品质量和效率，反正做出的东西能够继续忽悠投资人就行。换言之，融到钱才是最重要的，至于我这个产品质量如何？是不是可行的？如果不行会浪费多少资源？都不是问题。甚至有人曾经问我：“连生存都不能保证了谁还去管什么质量和效率？”我到现在都觉得他问得好有道理，竟无言以对，似乎我反而成了那个问他们“何不食肉糜”的人。

所以，在国内之所以敏捷开发难以落地，有文化的原因，有环境的原因，也有个人的原因。这些阻碍因素根深蒂固，短时期内难以期待明显的改变。当然，我们欣慰地看到，一些走在前沿的公司，包括文章开头提到的那几家，因为高瞻远瞩，资源丰厚，人、财、理念兼备，可以昂首阔步向敏捷转型。我们希望这些公司在实践成功以后能够成为榜样，带动更多的公司参与敏捷实践，从而提升国内软件开发行业的整体水平。

同时，我们也相信敏捷之花并非高山雪莲，或者领袖企业的专利，而是所有企业共同追求的能力和境界。

敏捷之美  ∣ 这里只有干货

感觉有用敬请关注，交流投稿后台留言。

深度切磋请发邮件至[e-mail]