今天承蒙老朋友们抬爱，去DevOps社区2020峰会成都站讲了个开场。在这么不寻常的一年，这样热闹的大会总是让人感觉很有希望的事。我在演讲里说，DevOps（跟“规模化敏捷”一样），其实对大多数企业来说，无非就是一个立项的借口而已。软件开发的问题，从二十年前到现在，也并没有怎么变过，无非就是质量差速度慢。很多企业搞过敏捷，培训也做了，咨询也搞了，软件工具也买了，过两年一看，还是质量差速度慢，咋办呢，总不能再搞一轮敏捷，于是只好换个名目来立项，继续解决质量差速度慢的问题。其实我这几年做的工作跟DevOps关系不大，也就2010年的时候翻译了Wikipedia的“DevOps”词条，代表ThoughtWorks中国区出去学习了DevOps和持续交付的概念，算是跟这个社区有一点交集。从旁观者的视角，DevOps本来应该是一个斗争非常激烈的领域。如今中国的DevOps社区这么一片其乐融融的景象，也算是难得。用徐昊的话来说，DevOps运动从一开始就是个缝合怪，并且缝合的是几个强烈冲突的目标。一开始构成这个运动的主力，有一拨是软件开发者。从他们的优势技能出发，他们最关心的就是尽可能自动化，减少部署和运维过程中对人的依赖。他们说什么“infrastructure

然而，对于预期工作量2~3天的需求颗粒（正是用户故事一般而言比较适当的颗粒度），新手无法有效地将其拆分。更具体而言，新手无法对较大尺度的需求进行下列操作将其变成较小尺度的开发任务：

我在《敏捷中国史话》里面论证了一件事：中国的软件行业根本就没有什么「传统开发」。所谓「传统开发」什么具体的东西都没有教给人，只有一帮装模作样的骗子和一大片全凭本能的团队。

一切没有良好自动化测试与持续集成的软件开发都是瞎搞。

然后，是不是就开始自我怀疑了？我天天在一家不怎么有归属感的公司上班，跟一支没啥默契的团队一起工作，就为一份不太稳当的收入？这跟我年少时的梦想不一样啊。说好的工程师文化呢？说好的用技术改变世界呢？

这些问题，为数众多的团队从来就没有处理好，只不过他们靠人类本能——混沌的、自发的、随机的面对面交流——凑合着往前走。当人类本能的「有问题就赶紧找人聊」不再可行，基本功欠缺的问题就马上暴露无遗。

一定是不直面客户的。大佛爷最烦的就是面对客户，我要专心念经的，你成天给我改你那需求算怎么回事。所以大佛爷增加的层级一定得给自己盖个庙，让客户不能来烦我——有事儿找实施团队，弄死他们不偿命。

然而我一直有个疑惑：这个大家都在说的「传统开发」，到底是个啥？听起来好像学好了「传统开发」就应该掌握很多软件开发的纪律和基本功了，那这个「传统开发」应该是好东西啊。那这好东西，我怎么能学一下呢？

Martin），生于1952年，敏捷开发宣言17个奠基人之一，包括《整洁代码》等多本业界名著

本文内容选自我在「中国DevOps社区2019年会」上分享的《敏捷中国十八年目睹之怪现状》实录。

"第三期TDD实战营开始招生，前面没参加的同学抓紧报名，一起来练功了～".replace(/\r/g,"").replace(/\n/g,"").replace(/\s/g,"

练出来的效果在我来看很明显。第一期实战营最后一道题，有个一学员，第一次花了4、5个小时，到最后，他可以30分钟就把这道题做完。这就是10倍的效率提升。这些能力都是通过反复的练习得到的。

有个项目团队去给一家客户做项目启动，工作坊刚搞完第一天，回来说不行，这个客户不接受敏捷。然后一帮人就接着讨论啊，客户为啥不接受敏捷啊，是不是制造业不适合敏捷啊，是不是民营企业不适合敏捷啊，等等等等。

复用（Reuse）：如果一个表达式的值会不断变化（例如“当前的时间”），或者取得这个值的成本很高（例如需要调用网络接口），而你又需要多次使用同一个值，就应该将其保存在局部变量中，以便重复使用。